Custom Contract Design & Threat Modeling
I will design custom smart contracts with threat modeling and invariant tests
About this gig
You shouldn't have to know every way a smart contract can fail before you hire someone to write it. Finding those cases is my job.
I design custom contracts for ideas that don't fit a template. Before writing code, I map every actor and state, then list the contingencies: a party who disappears, a price feed that freezes, a front-run transaction, a griefer, an admin key that leaks, a needed upgrade. Each gets a design answer you can read in plain language. Then I implement the contract and write invariant and fuzz tests that try to break its promises.
What you get:
- A written specification of actors, states and permissions
- A threat model of the contingencies and how the design handles each
- Contracts in Solidity or Cairo, built to that spec
- Invariant and fuzz tests with Foundry or Starknet Foundry
- Timeouts, pause and recovery paths, and an upgrade strategy
- Audit-ready documentation
My Bilateral Escrow contract on Starknet holds both a buyer's payment and a merchant's return bond, with timeouts so neither side can stall a deal forever.
Tell me what the contract is for. I'll come back with the cases you haven't thought of yet.
Use cases
The party who vanishes
Every deal gets a timeout and a default outcome, so funds never sit locked waiting for someone who left.
The frozen price feed
Stale oracle data pauses the actions that depend on it instead of settling at the wrong price.
The leaked admin key
Admin powers sit behind a timelock and a multisig, with a narrow pause role for emergencies.
The griefer
Spam and dust deposits cost the attacker more than the damage they can cause.
What changes
Today
- Your idea doesn't match any template, and copied code assumes a different world
- Edge cases appear after launch, when the contract can't be patched quietly
- Nobody asked what happens if an oracle stops, a party disappears or a key leaks
- Auditors bill for weeks because there's no spec to check the code against
After
- A written spec: every actor, every state, what each can and can't do
- A threat model listing the contingencies, and the design answer to each
- Invariant and fuzz tests that try to break those promises
- Pause, timeout and recovery paths designed in from the start
How it works
- 01Map actors and states
- 02List what can go wrong
- 03Write the spec
- 04Implement and fuzz
- 05Hand over audit-ready docs
Compare packages
| Package | Starter$350 | Business$1,500 | Scale$4,800 |
|---|---|---|---|
| What it is | Spec and threat model for your contract idea, with a design recommendation | Spec, threat model and up to 3 contracts with invariant and fuzz tests | Full protocol design, implementation, fuzzing campaign, audit prep and launch plan |
| Written specification | ✓ | ✓ | ✓ |
| Threat model of contingencies | ✓ | ✓ | ✓ |
| Design recommendation | ✓ | ✓ | ✓ |
| Contract implementation | – | Up to 3 | Up to 8 |
| Invariant and fuzz tests | – | ✓ | ✓ |
| Pause, timeout and recovery paths | – | ✓ | ✓ |
| Upgrade strategy | – | ✓ | ✓ |
| Audit-ready documentation | – | – | ✓ |
| Fixes during external audit | – | – | ✓ |
| Launch and monitoring plan | – | – | ✓ |
| Delivery | 5 days | 16 days | 30 days |
| Revisions | 2 | 3 | 4 |
Add-ons
- Faster delivery+30% of the package
- Internal security review with written findings+$250
- Testnet deployment and verified contract+$90
- 90 days of support and small changes+$240
Built before
Who it's for
- Founders with a novel protocol
- Fintechs moving logic on-chain
- Teams preparing for an audit
- Marketplaces with unusual settlement rules
What I'll need from you
- What the contract is for, in your own words
- Who uses it and what each party wants
- Target chain and tokens
- Any rules that must never be broken
Questions, answered
Do I need to tell you all the edge cases?
No. Tell me what the contract is for. Finding the edge cases is the job, and you review them in plain language before anything is built.
What's in a threat model for a contract?
Everyone who touches the contract, what they want, and every way the rules could be bent: a party who never shows up, a price feed that freezes, a front-run transaction, an admin key that leaks. Each gets a design answer before code exists.
Is this an audit?
No. It's design and testing that make an audit faster and cheaper. For contracts holding significant funds, I still recommend an independent audit.
Who owns the code and accounts when we finish?
You do. Code goes to your repository, and services run on accounts in your name, so you are never locked to me. I hand over logins, keys and a short guide.
What if my project doesn't fit a package?
Send a message describing what you need. I reply with a custom offer priced to the actual scope, often after a short call.
The thinking behind it
Tools and tags
- Solidity
- Cairo
- Foundry
- Starknet Foundry
- Echidna
- Slither
- OpenZeppelin
- #customcontract
- #threatmodeling
- #solidity
- #cairo
- #fuzztesting
