Developing a fractional-reserve stablecoin
Client wants a stablecoin that doesn't require 150% overcollateralization like DAI in CDP mode, but maintains peg. Fractional reserve is not design flaw, it's a compromise between capital efficiency and stability. Problem is most teams underestimate bank run mechanism in on-chain context: unlike traditional banks, smart contracts let you withdraw everything in one transaction.
Why fractional-reserve stablecoins break — and how not to
Algorithmic part kills peg faster than expected
FRAX v1 launched with CR (Collateral Ratio) 100%, then algorithm lowered CR as demand grew. Theory: if market trusts protocol, replace part of backing with governance token FXS. Practice: March 2023, after SVB collapse, CR fell below 90%, recovery took weeks of volatility. Not failure — but clear example that algorithmic part is nonlinear under pressure.
Key invariant to protect: redemption always possible at par. If user can't burn 1 stablecoin and get $1 in collateral (or equivalent), arbitrage mechanism breaks, peg holds only on psychology.
Contract construction: three layers
Layer 1 — Minting/Redemption. User deposits collateral (USDC, ETH via Chainlink price feed) and gets stablecoin. At mint with CR=80% — 80 cents in USDC + governance tokens worth 20 cents. At redeem — opposite. This layer must be atomic and independent of on-chain governance token liquidity.
Layer 2 — PID-controller for CR. Algorithm that raises CR on depeg down and lowers on stable peg. Critical: don't do it instantly. Changing CR by 1% per day is typical. Sharp change creates MEV opportunities for arbitrageurs attacking the moment of change.
Layer 3 — AMO (Algorithmic Market Operations). Free reserves work in Curve/Aave/Convex, generating returns. AMO contracts must have strict limit on maximum deployment: if AMO can deploy more than (1 - CR) of total supply, system becomes vulnerable to simultaneous withdrawal.
Flash loan as oracle attack vector
Typical scheme: attacker takes flash loan for 50M USDC, pushes governance token price down 40% through thin Uniswap v2 pool, contract instantly recalculates CR via short-window TWAP oracle (5 minutes) — CR falls, protocol technically undercollateral. Attacker simultaneously opens redemption and gets USDC from reserve at unfavorable rate.
Protection: TWAP minimum 30 minutes for governance token as collateral component. For USDC and ETH, Chainlink with 0.5% deviation threshold enough. Separate oracles for different components, not aggregated price feed.
How we build such systems
Development starts with economic model, not code. Must define:
- Target CR range (e.g., 80-90%)
- PID parameters: CR change speed, trigger thresholds
- List of allowed collateral assets and their weight coefficients
- Mechanism to incentivize peg maintenance (stability fees, bond mechanism)
Stack: Solidity 0.8.x, OpenZeppelin for access control and pausability, Chainlink for price feeds, Curve Finance SDK for AMO integration. Tests in Foundry with mainnet fork — mandatory, because AMO logic depends on actual state of Curve pools.
For governance token — standard ERC-20 with burn mechanics on stablecoin mint. Important: governance token shouldn't have infinite mint — this killed projects like Iron Finance (IRON/TITAN, June 2021, $2B → $0 in 24 hours).
Testing bank run scenario
In Foundry can simulate 80% supply redemption simultaneously in one block. Contract must either handle this correctly (distribute USDC from reserve, freeze governance-token portion) or activate circuit breaker. Circuit breaker is pausable module with timelock that introduces cooldown on redemption when threshold volume exceeded per block.
Property-based test via Echidna: invariant "total_collateral_value / total_supply >= min_CR" must hold in any minting and redemption scenario.
Working process
Economic design (1-2 weeks). Parameterize model, simulate in Python/Jupyter, stress-test bank run scenarios. Determine thresholds where system becomes unstable.
Contract design (1 week). Storage layout, interfaces, interaction diagram. Special attention to operation order in mint/redeem (Checks-Effects-Interactions).
Development (3-6 weeks). Core contracts + AMO + oracle integration. Fork-tests against mainnet Curve/Aave.
Audit. For financial protocols of this level — mandatory external audit. Prepare codebase: Slither clean, 95%+ test coverage, NatSpec on all public functions.
Deployment. First testnet (Sepolia) simulating market stress via Foundry scripts. Mainnet deployment via Gnosis Safe multisig with timelock minimum 48 hours on parameter changes.
Timeline estimates
Minimal system without AMO: 6-8 weeks. With AMO modules and full test coverage: 2-3 months. Timeline strongly depends on number of collateral types and governance mechanic complexity.