Solvency and accounting
Where value enters and leaves, how every balance is computed, which way each division rounds and who absorbs the difference.
DeFi protocol design review, before the design is locked into code
The most expensive bugs are design bugs. A rounding direction, an oracle assumption or a liquidation path decided early is hard to change once the code exists, and impossible to change once it is deployed immutably. We review your architecture while it is still cheap to change.
01 / WHO THIS IS FOR
Who this is for
- Teams with a whitepaper, a specification or an early codebase who want an outside view before committing to it
- Founders who need to understand the risks in a design before raising funds or hiring
- Teams preparing for an audit who want the design questions settled first
02 / WHAT WE REVIEW
What we review
Oracles and pricing
Which prices the system trusts, what happens when a feed is stale, uncertain or wrong, and how far a bad price can spread.
Liquidations and bad debt
Whether positions can be closed when they need to be, who has the incentive to close them, and where bad debt ends up when they cannot.
Emergency controls
What can be paused, who can pause it, and whether users can still exit while it is paused.
Roles and upgrades
Admin powers, upgrade paths and key management, and what each role could do if its key were compromised.
Economic edge cases
Incentives, parameters and the cases that break naive designs, such as empty pools, first depositors and extreme utilization.
03 / HOW IT WORKS
How it works
- 01KickoffA call, access to your documents and code, and the questions the review must answer.
- 02ReviewOne to two weeks of analysis, with questions to your team as they come up.
- 03ReportWritten findings ranked by impact, each with a concrete recommendation.
- 04WalkthroughA call to go through the report and the options with your team.
04 / WHAT YOU GET
What you get
| DELIVERABLE | FORM |
|---|---|
| A written report with findings ranked by impact and concrete recommendations | Document |
| The list of invariants the system must hold, ready to be turned into tests | Document |
| A walkthrough call with your team | Call |
| Answers to follow-up questions for two weeks after delivery | Async |
06 / FAQ
Questions about design reviews
Is a design review the same as an audit?
No. An audit checks the code line by line for vulnerabilities. A design review looks at the architecture and the economics, ideally before or while the code is written. They complement each other.
What do you need from us?
Whatever exists, from a whitepaper or specification to diagrams or code. If the design is still in your heads, a call is enough to start.
Can the review cover existing code?
Yes. If the design lives mostly in the code, we review it from there. For a line-by-line hardening pass before an audit, see Pre-Audit Hardening.
What happens after the review?
Your team implements the changes, or we can help through Smart Contract & Protocol Development.