DeFi smart contract work is different from general dApp development because the contracts hold pooled funds that anyone can attack, and mistakes are usually permanent. When you hire for it, judge the team on testing depth, security habits and restraint, not on how many features they promise.
For general contract engineering, see smart contract development; this page focuses on what changes when the contracts are financial.
What makes DeFi contracts harder
- Adversarial composability. Any contract can call yours, in any order, inside one transaction, with flash-loaned capital. Your code must be safe against callers who control huge temporary balances.
- External dependencies. Oracles, other protocols' pools, tokens with non-standard behavior (fee-on-transfer, rebasing, missing return values, blocklists, pausable transfers).
- Math precision. Fixed-point arithmetic with rounding that must always favor the protocol. Small errors compound into exploitable leaks.
- Economic invariants. "Total shares map to total assets", "the sum of user balances equals the contract's holdings", "no healthy position can be liquidated". These must hold after every possible sequence of calls.
Engineering practices to insist on
| Practice | What it catches | What to ask for |
|---|---|---|
| Written spec and invariant list | Design flaws before code exists | The document, reviewed by you |
| Unit tests | Functional bugs | High branch coverage report |
| Fuzz and invariant tests | Edge cases and broken invariants under random call sequences | Foundry invariant suites or Echidna/Medusa campaigns |
| Mainnet fork tests | Integration surprises with real tokens and oracles | Tests running against forked state |
| Static analysis | Known bug patterns | Slither or similar output with triage notes |
| Formal verification (where justified) | Proof that critical properties always hold | Scope and properties proven |
| Independent audit | What the authors cannot see | Report from a firm the developers do not control |
Design decisions a good team will raise
Upgradeability
Proxies (transparent, UUPS, beacon) let you fix bugs but also let a compromised admin replace the logic and take funds. Strong teams minimize what is upgradeable, keep core accounting immutable where possible, use storage layouts that avoid collisions (ERC-7201 namespaced storage is now common), and put upgrades behind a multisig and timelock.
Admin powers
Every privileged function should be listed with who can call it, what it can change and what bounds apply. "Owner can set fee" should become "governance can set fee between 0 and 1% after a 48-hour delay". An emergency pause should stop deposits and borrows but never block withdrawals of healthy positions without a clear reason.
Reuse over invention
Good DeFi engineers fork audited code and well-known libraries (OpenZeppelin, Solmate/Solady, established math libraries) rather than rewriting them. Be wary of a team eager to write their own token, math or proxy code without a strong reason.
Deliverables you should receive
- A specification and threat model, including the attack categories considered: reentrancy, oracle manipulation, rounding, access control, flash-loan governance, denial of service.
- Source code in a repository you own, with reproducible builds and pinned compiler versions.
- The full test suite, including fuzz and invariant tests, runnable in CI.
- Deployment scripts and a deployment checklist (constructor arguments, role assignments, ownership transfers, verification on block explorers).
- Audit reports and a remediation log showing how each finding was handled.
- Operational documentation: monitoring, keeper requirements, emergency procedures.
How to vet a contract team
- Read code they have shipped. Ask for deployed, verified contracts and the audits of them. Check whether audit findings were high-severity and how they were fixed.
- Ask about past incidents. An honest answer about a bug they caught or shipped is a good sign; claiming none ever is not.
- Test their threat modeling. Ask how they would make a vault safe against the first-depositor inflation attack, or how they would price a liquid staking token as collateral. Vague answers are a red flag.
- Check independence. The auditor should not be the same team or a sister company.
- Watch for scope creep promises. A team that agrees to add tokenomics, NFTs and cross-chain bridging to a v1 lending protocol is not protecting your users.
Cost and timeline
As a reasoned estimate, a small, well-specified contract system (a staking contract or a vault with one strategy, a few hundred lines) takes one or two senior engineers two to six weeks including tests. A full protocol takes months. Expect audits to add both cost and calendar time, and leave room for a second review after fixes. The audit guide covers what drives audit pricing, and the DeFi development overview places contracts in the wider product.
Frequently asked questions
Solidity or Vyper for DeFi?
Solidity has the larger ecosystem, tooling and auditor pool, so most teams use it. Vyper is used by Curve and others and is deliberately simpler. Either is fine if the team and auditors know it well; the 2023 Vyper reentrancy-lock bug shows compiler versions matter in both.
How much test coverage is enough?
Line coverage is a weak metric. What matters is whether invariants are tested under random call sequences and against real forked state. Ask what the invariant suite checks, not just the coverage percentage.
Should contracts be upgradeable?
Only the parts that genuinely need to change, behind a timelock. Immutable core contracts with replaceable periphery are often the safer design.
Is one audit enough?
For small, simple contracts it may be. For protocols holding significant value, many teams use two independent audits or an audit plus a public contest, followed by a bug bounty.