What this prompt does
This prompt drives the AI to design a DeFi protocol where economic design gets as much rigor as the code. You set [protocol_type], [target_chain], [supported_assets], and a [tvl_target], and it architects the core mechanics — a mathematical model for [pricing_model] with interest, collateral, and liquidation formulas — alongside contract separation into [contract_separation] and the call flow for [primary_user_flow].
The structure works because most DeFi failures are economic, not syntactic. By forcing oracle integration via [oracle_solution] with staleness checks rejecting prices older than [max_price_age], deviation circuit breakers at [max_deviation], and a [fallback_strategy], plus explicit risk parameters ([collateral_factor], [liquidation_threshold], [liquidation_penalty]), a [liquidation_type] mechanism, [governance_model] with a [timelock_duration], and named [attack_scenarios], the prompt surfaces the manipulation vectors that have drained real protocols before any code is written. The [tvl_target] and [supported_assets] keep the risk settings grounded, since a protocol holding volatile assets at scale needs more conservative parameters than a stablecoin-only pool.
When to use it
- You are sketching protocol mechanics and need the math spelled out, not assumed
- You want oracle staleness and deviation protections designed in from the start
- You need risk parameters explained in terms of solvency and user experience
- You are deciding contract boundaries across
[contract_separation] - You want named
[attack_scenarios]like flash-loan oracle manipulation addressed up front - You need a governance and timelock model before parameters can change
- You want the
[primary_user_flow]traced through the contract interfaces
Example output
Expect a layered architecture document: the [pricing_model] with formulas, a contract diagram showing [contract_separation] and interfaces, an oracle section detailing [oracle_solution] with [max_price_age] staleness checks and a [max_deviation] circuit breaker, a risk-parameter table explaining how each value affects solvency, a [liquidation_type] design with incentive structure, a governance section with [timelock_duration] and [quorum_requirement], and a threat model walking through each of the [attack_scenarios] with mitigations. It typically also traces the [primary_user_flow] end to end so the call sequence between contracts is explicit rather than implied.
Pro tips
- Treat the output as a design draft to scrutinize, never something to deploy — economic models need real simulation and review
- Be specific with
[supported_assets]and per-asset[collateral_factor]values, since stablecoins and volatile assets warrant very different settings - Push on
[oracle_solution]: a single price feed without a[fallback_strategy]is a known single point of failure - Make
[attack_scenarios]exhaustive — flash-loan manipulation, governance capture via borrowed tokens, and cascading liquidations are the classics - Set
[max_deviation]and[max_price_age]deliberately; too loose invites manipulation, too tight causes false pauses during real volatility - Keep
[liquidation_threshold]above[collateral_factor]with a sensible buffer, or positions liquidate the instant they are opened - Stress-test the
[liquidation_type]incentives separately, because under-incentivized liquidators leave the protocol insolvent in a crash
