Intrepid Development logo - astronaut cat mascot
IntrepidDev
OPEN SOURCE // INTREPID-DEV PUBLISHED · MIT

Open source we ship. The same code we deploy.

Net-give-away from the studio's working code

Four MIT-licensed packages. Solidity tooling we run on every audit-readiness engagement. Elm libraries we use to ship type-safe dApp frontends. All distilled from production work on Ethereum and PulseChain.

// SOLIDITY TOOLING · AUDIT-READY BY DESIGN

What we run on every engagement.

Two repos that back the studio's audit-readiness practice. The Hardening Pack is the universal scaffolding; the Solidity Notes are the PulseChain-specific domain knowledge. Drop both into a fresh project and you're meaningfully ahead of where most pre-audit codebases land.

// PKG · 01 · v0.2.0

intrepidshape/pre-audit-hardening-pack

What an auditor wants to see on day one — in a forkable Foundry repo.

GitHub Latest release

Drop your contracts in. The scaffolding does the rest. Foundry-based template that bakes in the conventions a senior security auditor silently expects: pinned compiler, NatSpec on everything, an invariant-test handler that actually finds bugs, threat-model template, deployment script with post-deploy invariant checks, CI gates that block merges on coverage drops or static-analysis findings, 70-item readiness checklist.

// HIGHLIGHTS
  • 70-item pre-audit readiness checklist (7 sections × 10 items)
  • Three-page threat-model template (trust assumptions, attacker capabilities, invariants)
  • Working invariant-test handler — closed actor set, ghost variables, the load-bearing pattern most teams skip
  • Deploy script with explicit constructor args + post-deploy invariant assertions
  • CI: forge build/test, fmt --check, ≥90% coverage gate, Slither fail-on-medium, nightly 10k-run invariant pass
  • Pinned solc 0.8.30, optimizer 1M runs, deterministic bytecode (cbor off, bytecode_hash none)
// INSTALL · CLONE OR FORK v0.2.0 · MIT 
git clone https://github.com/IntrepidShape/pre-audit-hardening-pack
// PKG · 02 · v0.1.0

intrepidshape/pulsechain-solidity-notes

Porting EVM contracts to PulseChain — the differences that matter.

GitHub Latest release

Operational handbook for engineers shipping Solidity on PulseChain in 2026, plus production-grade reference implementations of the patterns. Six topical docs (~5,000 words) covering gas pricing, oracle availability, bridge risk, fork-block quirks, tooling gaps, and pre-deployment ops. Two reference contracts with 19 tests including a manipulation-resistance assertion.

// HIGHLIGHTS
  • 30-min PulseX V2 TWAP oracle — UQ112x112 cumulative-price math, manipulation-resistance assertion in tests
  • Bridge-aware AssetWhitelist registry — per-asset cap, oracle binding, bridged flag, risk tier
  • Long-form notes on Chainlink absence, oracle alternatives, bridged-asset risk stack, fork-block quirks
  • Post-deploy invariant-runner script (CheckDeployment.s.sol) — exits non-zero on failure
  • Foundry pulsechain profile with chain ID 369 + RPC default; CI with coverage gate + Slither
  • Companion to the Pre-Audit Hardening Pack — drop both into a fresh PulseChain project
// INSTALL · CLONE OR FORK v0.1.0 · MIT 
git clone https://github.com/IntrepidShape/pulsechain-solidity-notes
// ELM dAPP LIBRARIES · TYPE-SAFE EVM IN ELM

Frontends that don't crash on edge cases.

The dApp problem most JS frameworks solve badly: what does your UI do when the wallet rejects, when the chain reorgs, when the user pastes a malformed address, when an oracle returns negative price? In Elm, the compiler refuses to build until every state is handled. These two packages put that guarantee on wallet, transaction, and contract-call surfaces.

// PKG · 03 · v1.0.0

intrepidshape/elm-web3

Type-safe EVM blockchain interaction for Elm. Zero runtime exceptions.

GitHub Elm registry

Wallet connection, transaction lifecycle, and contract calls modelled as explicit state machines. Opaque validated types — Address, TxHash, ChainId, BigInt — that the compiler enforces. The JS port bridge is ~500 lines with no npm runtime dependencies. No ethers, no viem, just window.ethereum and Elm pattern matching.

// HIGHLIGHTS
  • EIP-6963 multi-wallet discovery built in
  • Transaction lifecycle from AwaitingSignature → Confirmed with revert reason decoding
  • Typed contract reads, writes, gas estimation, and multicall batching
  • EIP-712 typed signing with structured-data validation
  • ABI code generator from Foundry/Hardhat JSON output
  • Lean 4 proofs and TLA+ specs for core invariants
// INSTALL · CLONE OR FORK v1.0.0 · MIT 
elm install intrepidshape/elm-web3
// PKG · 04 · v1.2.0

intrepidshape/elm-web3-ui

Modular DeFi UI primitives for elm-web3. No internal Msg, no subscriptions.

GitHub Elm registry

Twenty-four view primitives that pair with elm-web3: wallet picker, transaction status, address display, balance, typed inputs, signing, amount input, price display, gas estimate, pending overlay, chain gate, plus DeFi-flavoured primitives (supply bar, lock period, hold clock, trend indicator, fee breakdown, slippage input, stake card, relative time, stat cell, trade tabs, token search, progress ring, bonding curve, activity row). Every component returns plain Html msg. They render what you pass in and call back with whatever msg you provide.

// HIGHLIGHTS
  • 24 modular UI primitives across wallet, transaction, DeFi-shape, and analytics
  • Every element has a semantic class — bring your own CSS
  • Attribute passthrough on every primitive, merged onto the root element
  • Validation feedback via a valid : Bool field on every input
  • Four ready-to-use stylesheets: vanilla, dark, shadcn, brutalist
  • Pairs with intrepidshape/elm-web3 — both ship together
// INSTALL · CLONE OR FORK v1.2.0 · MIT 
elm install intrepidshape/elm-web3-ui
// ELM dAPP QUICKSTART

Connect a wallet, send a transaction, render the result. In Elm.

A complete walkthrough lives in each repo's README. The shape of a working app is small enough to fit on this page. (Solidity packages are forkable repos — read their READMEs for setup.)

1. Wire the JS port bridge

Copy js/elm-web3-ports.js into your project and load it after your compiled Elm bundle. It listens on two ports — outgoing commands and incoming events — and translates between Elm and window.ethereum. 

<script src="elm.js"></script>
<script src="elm-web3-ports.js"></script>
<script>
  var app = Elm.Main.init({ node: document.getElementById('app') });
  setupPorts(app);
</script>

2. Declare the two ports

One port module, two ports. The bridge speaks JSON in both directions — the package handles encoding and decoding for you. 

port module Ports exposing (..)

import Json.Encode as E
import Json.Decode as D

port web3Out : E.Value -> Cmd msg
port web3In  : (D.Value -> msg) -> Sub msg

3. Connect a wallet

Web3.Wallet.connect returns a Cmd msg. The result arrives back through the subscription as a wallet-state transition. The type system enforces that you handle every state. 

import Web3.Wallet as Wallet exposing (State(..))

type Msg = WalletEvent Wallet.Event | Connect

update msg model =
    case msg of
        Connect ->
            ( model, Wallet.connect web3Out )

        WalletEvent ev ->
            ( { model | wallet = Wallet.update ev model.wallet }
            , Cmd.none
            )

view model =
    case model.wallet of
        Disconnected     -> button [ onClick Connect ] [ text "Connect" ]
        Connecting       -> text "Connecting…"
        Connected info   -> text ("Connected: " ++ Address.short info.address)
        WrongChain info  -> text ("Switch to Ethereum to continue.")
        Errored err      -> text ("Wallet error: " ++ Wallet.errorToString err)

4. Send a transaction

Build a transaction, submit it, and let the package track its lifecycle through AwaitingSignature → Pending → Confirmed (or the revert path with a decoded reason). 

import Web3.Transaction as Tx exposing (Status(..))
import Web3.Units as Units

sendTip : Address -> Cmd Msg
sendTip to =
    Tx.send web3Out
        { to = to
        , value = Units.parseEther "0.01"
        , data = Nothing
        , gasLimit = Nothing
        }

view model =
    case model.tx of
        Nothing                      -> text "(no tx)"
        Just AwaitingSignature       -> text "Sign the transaction in your wallet…"
        Just (Pending hash)          -> text ("Pending: " ++ TxHash.short hash)
        Just (Confirmed receipt)     -> text "Confirmed."
        Just (Reverted reason)       -> text ("Reverted: " ++ reason)

5. Drop in the UI primitives

elm-web3-ui renders the wallet state, transaction status, addresses, balances, and inputs without owning any state of its own. You pass in data, you receive plain msg callbacks back. 

import Web3.Ui.Wallet as WalletUi
import Web3.Ui.Transaction as TxUi
import Web3.Ui.Address as AddrUi

view : Model -> Html Msg
view model =
    div []
        [ WalletUi.statusBar [] model.wallet
            { onConnect = Connect, onDisconnect = Disconnect }
        , case model.tx of
            Nothing -> text ""
            Just s  -> TxUi.statusHashLink []
                        { explorerUrl = Just "https://etherscan.io" } s
        , AddrUi.short [] model.someAddress
        ]
// WHY WE PUBLISH

Probative content beats pitch decks.

// VALUE 01

The same code we deploy

The Hardening Pack is what we run on every audit-readiness engagement. The PulseChain Notes are what we wrote down porting our own contracts. The Elm packages are what powers our dApp frontends. Nothing on this page is a marketing artefact — every repo solves a problem we hit ourselves first.

// VALUE 02

No gating, no email walls

Everything is MIT, on GitHub, with the full README and code on day one. If the work is good, you don't need to extract value from prospects in exchange for it — they extract value from it directly, decide whether the studio's judgement is worth their trust, and reach out when ready.

// VALUE 03

Code can't claim, only demonstrate

Every page on the site claims expertise. These four repos prove it — auditable commit history, runnable tests, published versions tagged, public release notes. If the claims don't match the code, it's visible to anyone who looks. That's the bar.

// IF YOU'RE USING THESE IN PRODUCTION

We can pair on the rest. Contracts, audits, dApp UX.

The Hardening Pack tells you what's audit-ready. The 5-Day Diagnostic runs the same checklist against your repo, names the top ten gaps, writes the threat model with you, and produces the three-option engagement proposal. If you're shipping with elm-web3 and want help on either side of the bridge, the door is open.

// 01

Pair on a deployment

5-Day Diagnostic on your contracts and the dApp wiring around them. A$1,800, credit-forward. We tell you what's audit-ready and what isn't.

Open the brief // 02

See how we engage

Diagnose first, then price. Every engagement starts with the 5-Day Diagnostic — A$1,800 fixed, credited forward.

Open engagement path