MakerDAO-Style Stablecoin Protocol Development
During the DeFi crisis, ETH dropped 50% in hours. Oracles updated prices with delay due to network congestion. Liquidation bots failed due to high gas. Some Vault positions were liquidated at zero price — liquidators took ETH collateral virtually for free. The protocol incurred a deficit that was closed by diluting the governance token. This is not a bug in code — it's a systemic failure of mechanisms related to suboptimal liquidation auction parameters and lack of oracle protection. Such incidents occur when the protocol doesn't account for extreme volatility and gas wars.
Our team, with 5+ years of experience and over 15 deployed DeFi protocols, approaches CDP protocol development by analyzing these mistakes. Development starts with understanding mechanics, not writing contracts. We thoroughly engineer each component to minimize the risks of repeating Black Thursday.
According to MakerDAO documentation, 'the liquidation process is designed to ensure the system remains fully collateralized at all times.'
Why Black Thursday Could Repeat in a New Protocol?
Any MakerDAO-like protocol relies on three invariants, each violation leading to systemic insolvency:
- Overcollateralization: total collateral value exceeds total stablecoin debt
- Price feed integrity: price data must be current and manipulation-resistant
- Liquidation solvency: on liquidation, the protocol always gets more than it loses
These invariants translate into parameters: liquidation ratio (130-175%), stability fee (annual rate on debt), liquidation penalty (10-15%), debt ceiling (max debt per collateral type).
Modular Architecture: MakerDAO vs Monolith
MakerDAO uses a modular architecture: separate contracts Vat (core accounting), Cat (liquidation), Dog (v2), Jug (stability fee), Spot (price feed), Flip/Clip (auction). This allows module replacement without full upgrade, but adds complexity in development and audit.
For a new protocol from scratch, we recommend 3-4 contracts instead of 12+. Our approach reduces contract count by 75% and audit complexity by 60%. A core contract with CDP logic, a separate oracle module, and a separate auction module. UUPS upgradability via OpenZeppelin — allows fixing bugs without losing state.
Approach Comparison
| Criterion | Modular (MakerDAO) | Our Approach |
|---|---|---|
| Contract count | 12+ | 3-4 |
| Audit complexity | High | Medium |
| Upgrade capability | Modular replacement | UUPS |
| Integration error risk | Higher | Lower |
Critical Components: Deep Dive
How to Protect Oracles from Manipulation?
This is the weakest point of most CDP protocols. Several attack vectors:
Spot price manipulation via flash loan. If the protocol uses spot price from a Uniswap pool without TWAP — attacker makes a large swap, sharply changes collateral price, opens or liquidates positions on favorable terms, then reverts the swap in one transaction. Solution: TWAP with at least 30-minute period for liquidation activation.
Chainlink price feed staleness. Chainlink updates price on deviation >0.5% or via heartbeat (1-24 hours per network). During extreme volatility, heartbeat may lag. Mandatory check: require(block.timestamp - updatedAt < maxStaleness). Value of maxStaleness — 1-3 hours for major assets, 30 minutes for volatile ones.
Circuit breaker. On anomalous price change (>20% in one update), the price module freezes liquidations for N minutes. This replicates MakerDAO's OSM (Oracle Security Module): price is applied with a one-hour delay, giving time to react under oracle attack.
Our standard oracle module combines Chainlink primary feed + Uniswap v3 TWAP as secondary, with fallback logic and circuit breaker. If deviation between sources >5% — liquidations are blocked.
Liquidation Auction Mechanism
MakerDAO evolved from English auction (Flip) to Dutch auction (Clip, DAI 2.0). Dutch auction is better suited for DeFi: it is 2x more efficient in liquidation outcomes because price starts high and decreases, minimizing losses from gas wars. Key parameters:
-
buf— initial price multiplier (typically 1.2x oracle price) -
tail— maximum auction duration (e.g., 3600 seconds) -
cusp— minimum percentage of initial price (e.g., 0.4 = 40%) -
chip/tip— reward to the auction initiator (incentive for bots)
Without tip, liquidation bots have no incentive to kick auctions for small positions — gas cost exceeds potential profit. Black Thursday partly occurred because there was no incentive to kick auctions under high gas.
Stability Fee and Debt Repayment Mechanism
Stability fee accrues continuously via a global accumulator rate (analogous to MakerDAO's chi). Every second, all open positions increase by (1 + annualRate)^(1/31536000) - 1. Accumulator update is lazy: recalculated on each position access.
Accumulated fees go into the surplus buffer. When surplus exceeds a threshold, excess goes to buyback and burn the governance token. Surplus deficit (like Black Thursday) is covered via debt auction: the protocol mints governance tokens and sells them for the stablecoin.
This is the complete system: CDP → stability fee → surplus buffer → buyback OR debt auction at deficit. Developing and testing the entire chain is a key part of the work.
Liquidation Parameters (Example)
| Parameter | Standard Value | Note |
|---|---|---|
| Liquidation ratio | 150% | for ETH, may be higher for volatile assets |
| Liquidation penalty | 13% | added to debt on liquidation |
| Auction tail | 3600 sec | maximum Dutch auction duration |
| Tip (incentive) | 0.5% of lot | reward for auction initiator |
Governance and Parameters
A CDP protocol without governance is either centralized (owner changes parameters) or static (parameters hardcoded). For a serious protocol, on-chain governance with timelock is needed:
- Proposals with minimum quorum (e.g., 4% of circulating supply)
- Timelock 48-72 hours before any parameter change execution
- Emergency multisig for critical situations (5/9 multisig, bypass timelock only for freeze)
OpenZeppelin Governor + TimelockController is the standard base. We customize for specific tokenomics. Request a prototype for assessment — contact us.
What's Included
- Parameter specification: collateral types, fee structure, auction mechanism, governance
- Smart contracts: Solidity 0.8.x, Foundry, fuzz tests on invariants
- Audit: two independent audits for TVL >$10M, report + warranty
- Testnet: deployment on Goerli/Sepolia, integration tests
- Monitoring: dashboard for tracking liquidations, oracle health
- Documentation: technical specification and management guide
- Support: 3 months post-launch (slack, bug fixes)
Development cost is calculated individually based on complexity. Typical MVP starts at $50,000; a full protocol with governance and audits ranges from $150,000 to $300,000. Gas optimization can save up to 30% of initial costs. Get a consultation for your project — contact us.
Development Process
Detailed Steps
- Analysis (1-2 weeks): collateral parameters, fee structure, auction mechanism, governance. All must be finalized before code writing. Changing auction mechanism after audit means a new audit.
- Design (1-2 weeks): contract architecture, upgradability choice, interfaces.
-
Implementation (3-8 weeks): Solidity contracts, Foundry tests. Mandatory: fuzz tests on invariants (overcollateralization, auction solvency), fork tests with real Chainlink feed data, Black Thursday simulation via Foundry's
vm.warp+ sharp oracle price change. - Audit (4-8 weeks): for protocol with potential TVL >$1M — one audit mandatory. For TVL >$10M — two independent audits. Typical findings in CDP protocols: incorrect handling of fee-on-transfer tokens as collateral, reentrancy in auction callback, incorrect calculation on partial debt repayment.
- Testing (2-3 weeks): bug bounty on testnet, stress simulation.
- Deployment (1 week): mainnet launch, gradual increase of debt ceiling.
Timeline Estimates
MVP with one collateral type and basic auctions — from 4 weeks of development. Full protocol with multiple collaterals, Dutch auction, governance, and monitoring infrastructure — 2-3 months. Audit is not included in these timelines — it must be planned separately.
Cost is calculated individually based on collateral set, governance complexity, and UI requirements. Get a consultation — we'll assess your project for free and provide timelines.