What does it actually take to ship a DeFi protocol?
Contracts are the visible part and rarely the largest. On the protocols we deliver, Solidity is typically a third of the effort. The rest is the system that makes it usable and operable: a frontend that handles wallet state and failed transactions honestly, indexing infrastructure so the UI can show positions without hammering an RPC, keeper or automation services for liquidations and settlement, price feeds and their failure behaviour, and monitoring that tells you something is wrong before your users do.
The parts teams consistently underestimate are indexing and keepers. A lending market needs liquidations executed reliably, at speed, under exactly the network conditions where everything else is also degraded. A perpetuals venue needs funding applied on schedule regardless of RPC health. These are backend systems with uptime requirements, not scripts.
For a first protocol we would expect roughly this shape of team: two smart contract engineers, one or two backend engineers on indexing and automation, one or two frontend engineers, a designer, and QA — running 3–5 months to a mainnet launch that has been audited.
How much does DeFi protocol development cost?
A focused MVP — an AMM, a single-asset lending market, a staking or vault product — typically runs $75K–$150K over 2–4 months. This assumes a proven pattern, one chain, and a scope you are willing to hold still.
A full DEX or perpetuals venue with custom mechanics, incentive systems, an indexer, and a production frontend generally runs $150K–$300K over 4–7 months. Protocols with novel mechanism design — derivatives, insurance, structured products, anything where the economics have not been proven live by someone else — run $250K–$450K, and the extra is mostly modelling and testing rather than additional features.
Third-party audits are a separate line item and are not ours to mark up. Budget $30K–$100K depending on scope and firm, and book the slot early — good auditors are booked out months ahead, and a launch date set without an audit slot confirmed is a launch date that will move.
We quote fixed-price per milestone after a paid scoping phase, with payments aligned to delivery rather than hours logged.
Should you fork an existing protocol or build from scratch?
Fork when a proven protocol already does substantially what you want. You inherit battle-tested code, audit history, and mechanics the market already understands — which shortens both the build and the trust-building. Most of our recent DEX work started from Algebra, Aerodrome, Symmio, or Gondi for exactly this reason.
The trap is treating a fork as a shortcut. Every protocol encodes assumptions — about oracle behaviour, fee accrual, tick or tranche mechanics, liquidation ordering — and the changes that make it yours are usually the changes that violate one of them. The failure pattern is a small, reasonable-looking modification that quietly breaks an invariant the original design depended on, and nobody notices until it is exploited.
Build from scratch when your mechanism genuinely has no precedent, or when the closest fork would need such extensive surgery that you inherit the maintenance burden without the safety. That is a real decision with a real cost, and it should be made explicitly rather than by default in either direction.
How do you keep a protocol from getting drained?
Security is a process across the whole build, not an audit at the end. Ours has four layers.
First, design. Reentrancy-safe patterns, checks-effects-interactions, minimal upgradeability, explicit access control, and oracle designs that assume the oracle will at some point be wrong or stale rather than assuming it will not.
Second, testing. Full unit coverage, fuzz testing against stated invariants, and fork tests running against real mainnet state and real integrations — because the interesting bugs live in the interaction between your protocol and the ones it depends on, not inside a clean unit test.
Third, independent audit. Our contracts have been audited by Sherlock, PeckShield, and Obsidian. We prepare for audit properly: documented invariants, a threat model, and a codebase frozen before the engagement starts. Auditors find more when they are not reading a moving target.
Fourth, operations. Monitoring on protocol health and anomalous flows, alerting that reaches a human, timelocks on privileged functions, multi-signature control of admin actions, and a documented pause-and-respond path. Most protocol losses become catastrophic during the response, not the exploit — the difference between a bad day and a fatal one is usually how fast someone competent can act.
Which chain should you launch on?
Follow liquidity and users, not benchmarks. A protocol on a technically superior chain with no users is a technically superior protocol with no users.
In practice: Ethereum mainnet when your users hold assets there and transaction sizes make gas irrelevant. L2s — Arbitrum, Base, Optimism — for most consumer-facing DeFi, where cheap frequent interaction is the product. App-chains and newer L1s when there is an active ecosystem incentive programme and a community you can actually reach; we have shipped on HyperEVM, Blast, Berachain, Sonic, and Base, and in several of those cases network-level support was a meaningful part of the launch.
Multi-chain deployment is worth doing when each deployment has its own liquidity and users, and worth avoiding when it just splits the liquidity you already have across three places. Cross-chain messaging adds a trust assumption and a failure mode, so it should be answering a real need rather than a roadmap slide.
What happens after launch?
A DeFi protocol is an operated system, not a delivered artifact. Positions accrue, oracles drift, integrations change under you, and incentive programmes need adjusting against live data rather than a spreadsheet built before launch.
What we hand over: monitoring and alerting on protocol health, TVL, and anomalous flows; runbooks for the operations your team will actually perform; documented upgrade and emergency procedures; and an incident path with named responsibilities. Where a client wants us to stay on we do — several protocols we built are still maintained by us — but the system is built so your team can run it without us.
The handover is deliberate. An agency that leaves you unable to operate your own protocol has produced a dependency, not a delivery.
