Developing a MakerDAO-Style Stablecoin Protocol
In March 2020, "Black Thursday" at MakerDAO: ETH collapsed 50% in hours. Price oracles lagged due to network congestion. Liquidation bots couldn't keep up with high gas costs. Some Vault positions went into liquidation at zero price — liquidators captured ETH collateral essentially for free. The protocol suffered a $5.4M deficit, eventually covered through MKR dilution auctions. This wasn't a code bug — it was a systemic failure in the mechanics.
Developing a CDP protocol starts with understanding these mechanics, not with writing contracts.
CDP Protocol Architecture
Core: Three System Invariants
Any MakerDAO-like protocol is built around three invariants, breaking any one of which leads to systemic insolvency:
- Overcollateralization: total collateral value > total stablecoin debt
- Price feed integrity: price data must be current and manipulation-resistant
- Liquidation solvency: during liquidation, the protocol always gains more than it loses
These invariants translate into specific parameters: liquidation ratio (minimum collateralization, typically 130-175%), stability fee (annual debt interest rate), liquidation penalty (liquidator bonus, 10-15%), debt ceiling (maximum debt per collateral type).
Modular Architecture: MakerDAO vs Monolith
MakerDAO uses extremely modular architecture: separate contracts for Vat (core accounting), Cat (liquidation), Dog (v2 liquidation), Jug (stability fee), Spot (price feed), Flip/Clip (auctions). This allows module replacement without full upgrades, but creates complexity in development and auditing.
For a new protocol from scratch, we recommend less aggressive modularity: 3-4 contracts instead of 12+. A Core contract with CDP logic, a separate oracle module, a separate auction module. UUPS upgradeability via OpenZeppelin — allows fixing bugs without state loss.
Critical Components: Detailed Breakdown
Price Oracles and Manipulation Protection
This is the weakest point in most CDP protocols. Several attack vectors:
Spot price manipulation via flash loan. If the protocol uses Uniswap pool spot price without TWAP, an attacker makes a large swap, dramatically changes collateral price, opens or liquidates positions at favorable terms, returns the swap in one transaction. Solution: TWAP with a minimum 30-minute period before liquidation activation.
Chainlink price feed staleness. Chainlink updates on >0.5% deviation or through heartbeat (1-24 hours depending on chain and feed). During extreme volatility, heartbeat may lag. Mandatory check: require(block.timestamp - updatedAt < maxStaleness). Set maxStaleness to 1-3 hours for major assets, 30 minutes for volatile ones.
Circuit breaker. On anomalous price changes (>20% in one update), the price module freezes liquidations for N minutes. This reproduces MakerDAO's OSM (Oracle Security Module): price applies with 1-hour delay, giving time to react to oracle attacks.
Our standard oracle module combines Chainlink primary feed + Uniswap v3 TWAP as secondary, with fallback logic and circuit breaker. If source deviation exceeds 5% — liquidations are blocked.
Liquidation Auction Mechanism
MakerDAO evolved from English auction (Flip) to Dutch auction (Clip, DAI 2.0). Dutch auction works better for DeFi:
- Price starts high (above market collateral price) and decreases by formula to minimum
- Any participant can take part or all of the lot at any auction moment
- If price drops below minimum, the protocol's creditor (surplus buffer) covers the difference
- Flash loan friendly: buy collateral, immediately sell on DEX, return stablecoin in one transaction
Dutch auction parameters:
-
buf— initial price multiplier (usually 1.2x oracle price) -
tail— maximum auction duration (e.g., 3600 seconds) -
cusp— minimum percentage of starting price (e.g., 0.4 = 40%) -
chip/tip— reward for auction initiator (incentive for bots)
Without tip, liquidation bots won't initiate auctions on small positions — gas cost exceeds potential profit. Black Thursday partly due to this: no incentive to kick auctions at high gas prices.
Stability Fee and Debt Repayment Mechanism
Stability fee accrues continuously through a global accumulator rate (analogous to MakerDAO's chi). Every second, all open positions increase by (1 + annualRate)^(1/31536000) - 1. Accumulator updates are lazy: recalculated on each position access, not every block.
Accumulated fees flow into surplus buffer. When surplus exceeds a threshold, excess is redirected to governance token buyback and burn. Surplus deficit (as in Black Thursday) is covered through debt auction: the protocol mints governance tokens and sells them for stablecoin.
This is a complete system: CDP → stability fee → surplus buffer → buyback OR debt auction on deficit. Developing and testing the entire chain is key.
Governance and Parameters
A CDP protocol without governance is either centralized (owner changes parameters) or static (hardcoded parameters). For a serious protocol, you need on-chain governance with timelock:
- Proposals with minimum quorum (e.g., 4% of circulating supply)
- Timelock of 48-72 hours before executing any parameter changes
- Emergency multisig for critical situations (5/9 multisig, bypass timelock only for freezing)
OpenZeppelin Governor + TimelockController is the standard foundation. Customize for your tokenomics.
Development Process
Specification (1-2 weeks). Collateral parameters, fee structure, auction mechanism, governance. All must be fixed before coding. Changing auction mechanism after audit requires a new audit.
Development (3-8 weeks). Solidity contracts, Foundry tests. Mandatory: fuzz tests on invariants (overcollateralization, auction solvency), fork tests with real Chainlink feed data, Black Thursday scenario simulation via vm.warp + sharp oracle price change.
Audit (4-8 weeks). For protocols with potential TVL >$1M — one audit is mandatory. For TVL >$10M — two independent audits. Typical CDP protocol findings: incorrect fee-on-transfer token handling as collateral, reentrancy in auction callback, incorrect calculation on partial debt repayment.
Bug bounty and gradual launch. Initial debt ceiling is minimal, grows as protocol is tested in production.
Timeline Estimates
MVP with one collateral type and basic auctions — 4-6 weeks of development. Full protocol with multiple collateral types, Dutch auctions, governance and monitoring infrastructure — 2-3 months. Audits not included in these timelines — plan separately.
Cost depends on collateral set, governance complexity, and UI requirements.