Smart contracts
Solidity or Rust contracts written to a spec, with unit tests, fuzzing and invariant tests, plus a documented upgrade and pause strategy.
Services / Web3
Ship on-chain.
Sleep at night.
Smart contracts, wallets and on-chain products built security-first — because on-chain code is public, permanent and usually holding someone’s money. Tested, audit-ready, and designed so a person who has never opened a wallet can still get through.
Start a project- Smart contracts
- Audit preparation
- Wallet UX
- Tokens & NFTs
- dApp front ends
- Chain integrations
Where we win
Deployed is
for ever.
You can patch a web app on a Friday afternoon. You cannot patch a contract holding funds — you can only migrate off it, publicly, while everybody watches. So the tests, the invariants, the upgrade path and the key management are settled before the first deploy, not after an auditor hands you a list.
What we build
Six things
we do here.
Audit preparation
We get code, tests and documentation into the state an auditor needs, run the static analysis first, and handle remediation when findings come back.
dApp front ends
Wallet connection, transaction states, gas estimation and the error paths — the parts that decide whether a first-time user finishes or leaves.
Tokens & NFTs
Standards-compliant tokens, minting, royalties, vesting and distribution, with the economics implemented as specified rather than improvised late.
Chain integrations
Indexers, subgraphs, event pipelines and oracles connecting on-chain state to the ordinary backend that has to report on it.
Wallets & custody
Multisig, account abstraction and key management set up so that no single laptop is a single point of failure.
The toolkit
What we
work with.
Chains
- Ethereum
- Base
- Arbitrum
- Polygon
- Solana
Contracts
- Solidity
- Rust & Anchor
- Foundry
- Hardhat
- OpenZeppelin
- Slither
Front end
- viem
- wagmi
- RainbowKit
- Next.js
- The Graph
What you get
In your hands,
not ours.
- A written spec of what the contracts do, before they’re written.
- Test coverage, fuzzing and invariant tests you can run yourself.
- A deployment runbook with addresses, roles and key custody documented.
- Audit-ready code, and support through remediation.
- A front end that explains what a transaction will do before it’s signed.
- Monitoring on contract events after launch.
Questions
The awkward
ones.
Do you audit contracts?
We prepare for audit and fix what comes back, but we don’t sign off our own code. Anything holding meaningful value should be audited by an independent firm, and we’ll help you choose one and run the engagement.
Which chain should we build on?
Whichever your users and liquidity are already on — usually Ethereum or an L2 like Base or Arbitrum, sometimes Solana when throughput and fees decide it. It’s a distribution question more than a technical one.
Can you make it usable for people who’ve never held crypto?
That’s most of the work. Account abstraction, sponsored gas, email or passkey sign-in and honest transaction previews turn a five-step ordeal into something ordinary. We design for that user by default.
We need the on-chain part to talk to our normal systems.
Standard request. We index events into a conventional database so reporting, support and finance all see the same truth as the chain does.
Is web3 even the right answer for us?
Often it isn’t, and we’ll say so. If the only thing the chain buys you is a press release, a database will be cheaper, faster and far easier to fix.
What happens if a vulnerability is found later?
That’s what the pause switch, the upgrade path and the monitoring are for — decided at design time. We also agree upfront who gets called, and how fast, if something goes wrong at 3am.