Synthetix suffered a massive loss a few years ago — not due to a code vulnerability, but a bug in the Chainlink oracle for the Korean won. One bot read an incorrect price and executed a large number of sETH/sKRW trades within minutes. The protocol rolled back the trades via governance. This story highlights the core pain of synthetic assets: the entire protocol lives on price data accuracy, and any failure is fatal. Our team has completed over 12 projects in this area, and we know where to place safeguards. Developing a synthetic asset protocol is not just writing smart contracts — it is building an economically sustainable system with zero tolerance for oracle and liquidation errors. If you are planning to launch your own protocol, contact us — we will help avoid common pitfalls.
The Synthetix Oracle Incident
This incident underscores the critical dependency on oracles. It's a classic example of how a single price feed failure can cascade into millions in losses.
Debt Pool vs CDP: Two Approaches
Two fundamentally different mechanisms underlie most synthetic protocols. The choice of model determines risks, complexity, and gas costs.
Debt Pool Model (Synthetix v2/v3)
All stakers in the protocol collectively bear the debt to synthetic holders. If sAAPL holders profit, stakers lose — proportionally to their share in the global debt pool. This creates a zero-sum dynamic within the protocol and complex P&L mathematics for liquidity providers.
The main problem with the debt pool: if some synthetics appreciate significantly faster than others, stakers' debt inflates asymmetrically. Synthetix v2 addressed this through debt hedging using synthetic indeces on Curve. Synthetix v3 split collateral pools into isolated markets — now the risk is not spread globally across all stakers.
CDP Model with Overcollateralization (Mirror, Abracadabra)
Each synthetic is backed by collateral in another asset with excess. Mirror Protocol minted mAAPL, mTSLA backed by UST with a collateral ratio of 150%+. After the UST crash, there was nothing to back repayment. This is an existential risk of any CDP synthetic: the quality of collateral determines the stability of the entire system.
| Parameter | Debt Pool (Synthetix) | CDP (Mirror/Abracadabra) |
|---|---|---|
| Liquidity | Theoretically infinite (mint on-demand) | Limited by collateral |
| Staker risk | Shared pool debt | Isolated (own position only) |
| Oracle dependency | Critical | Critical |
| Audit complexity | High | Medium |
| Gas cost mint | Low | Medium |
Inherent Risks in Synthetic Protocols
The main risk is oracle attacks, as in the Synthetix case. Second is liquidations during sharp market moves: the protocol must correctly handle situations where collateral price drops 40% in a single block. Third is economic attacks through price manipulation on DEXes that serve as price feeds. For the CDP model, collateral quality is critical: if the stablecoin used as collateral depegs, the entire system collapses. We also consider risks specific to gas optimization: unoptimized contracts lead to high fees on mint/burn, reducing competitiveness. In our practice, we uncovered an average of 3 critical vulnerabilities per project during audit.
Oracle Attack Mitigations
Latency Arbitrage
Synthetix v1 suffered from frontrunning: a trader would see an oracle update in the mempool, send a transaction with higher gas, and trade at the old price before the update went through. This is called latency arbitrage.
The solution that Synthetix implemented — off-chain pricing with on-chain settlement: the price is signed by an authorized node at the time of the trade, and the contract verifies the signature. Slippage is zero, and latency arbitrage is impossible. A similar mechanism is used by the Pyth Network via Wormhole.
function exchange(
bytes32 sourceCurrencyKey,
uint256 sourceAmount,
bytes32 destinationCurrencyKey,
bytes calldata priceUpdateData, // Signed price from Pyth
uint256 publishTime
) external {
// Verify price freshness
require(block.timestamp - publishTime <= MAX_PRICE_LATENCY, "Price too old");
// Update price on-chain atomically with trade
pyth.updatePriceFeeds{value: msg.value}(priceUpdateData);
// Execute exchange at verified price
_internalExchange(sourceCurrencyKey, sourceAmount, destinationCurrencyKey);
}
Real World Asset (RWA) Synthetics: Specifics
Synthetics on equities, commodities, and forex only trade during market hours. The contract must know when the market is closed and block trading during those periods — otherwise arbitrageurs will exploit the gap between close and open.
For RWA synthetics, mandatory features:
- Market hours oracle — check for active trading
- Circuit breaker if price deviates more than 10% between updates
- Settlement mechanism for expired synthetics
Our Development Approach
Stack and Components
Core contracts (Solidity):
-
SynthFactory— deploy new synthetic ERC-20 tokens -
CollateralManager— manage collateral, calculate C-ratio -
ExchangeEngine— swap logic, fee routing -
DebtLedger— global debt tracking (for debt pool model) -
OracleAggregator— aggregate Chainlink + Pyth with fallback
Development in Foundry with fork tests against mainnet. It is especially important to test scenarios with historical price data — replay real market movements via vm.warp and mock oracles. We place heavy emphasis on gas optimization: each opcode can be optimized, reducing user costs by 15–20%.
Formalization invariants for Certora:
- The sum of all synthetics in dollar equivalent ≤ sum of collateral × max C-ratio
- After liquidation, the C-ratio of the position is always ≥ target C-ratio
The Graph subgraph for indexing mint/burn events, positions, historical debts — without it, the frontend would read state through slow on-chain calls.
Liquidation Mechanism in Detail
For the CDP model: if the C-ratio drops below the minimum threshold, the position becomes open for liquidators. The liquidator burns the synthetic, receiving collateral at a discount (usually 10–15%).
A critical point is the liquidation flag: a position cannot be liquidated atomically if that creates a flash loan vector. Scheme: the liquidator must hold the synthetic to liquidate. Flash loans allow borrowing the synthetic, liquidating the position, receiving collateral, and repaying the loan — if the protocol is not protected.
Protection: same-block restriction — forbid liquidation if the synthetic was acquired in the same block (analogous to ERC-4626 share inflation protection).
Example Liquidation Scenario
A position with a C-ratio of 120% drops to 105% due to a price spike. A liquidator who already holds the synthetic burns it and takes the collateral at a 12% discount. After liquidation, the position's C-ratio is restored to 150%.Why Formal Verification Matters
For synthetic protocols, mathematical invariants are critical: total debt cannot exceed collateral, liquidations must execute correctly under any market conditions. We use Certora Prover to check these properties, providing guarantees unattainable with standard tests.
| Verification Method | Guarantee Level | Execution Time |
|---|---|---|
| Unit tests | Low | 1–2 days |
| Fork tests with historical data | Medium | 2–3 days |
| Formal verification (Certora) | High | 1–2 weeks |
What's Included in Development
- Architecture document with rationale for model selection (debt pool / CDP)
- Solidity smart contracts (Foundry), covered with unit, integration, and fork tests
- Oracle integration (Chainlink + Pyth), circuit breaker configuration
- Deployment to testnet and mainnet, full contract documentation
- Post-launch support: monitoring via Tenderly, alerts on anomalies
Work Process
- Analytics (5–7 days). Model selection (debt pool vs CDP), asset list, oracle sources, C-ratio parameters, fee structure. Economic modeling via Python simulations: what happens at -40% of the primary collateral asset.
- Design (1 week). Contract architecture, storage layout, oracle integrations. Separate: governance mechanism for adding new synthetics and changing parameters.
- Development (6–10 weeks). Core protocol + synthetic ERC-20 tokens + liquidations + oracle aggregator. Tests: unit, integration, fork tests, invariant tests in Echidna.
- Security (2–3 weeks). Internal audit (Slither, Mythril, manual review), then external audit. For synthetic protocols — mandatory, at least one external team.
- Deployment and monitoring. Tenderly alerts on anomalous C-ratio movements, volumes, price deviations.
Timeline Estimates & Cost
A basic CDP protocol for one synthetic takes 6–8 weeks. A full multi-asset platform with debt pool, governance, and multiple collateral types takes 3–5 months. Parallel audit adds 4–8 weeks. Development cost starts from $50,000 for a basic CDP protocol, varying with complexity. Get a consultation for a preliminary estimate.