Why a CDP stablecoin breaks on collateral volatility
A CDP stablecoin breaks not at the moment the collateral price sharply falls, but at the moment the protocol loses the ability to honestly revalue the backing.
The classic scenario: collateral dropped 15-20% within a short window, the price oracle reports a value with a delay, and the collateral ratio in the system still shows a healthy position.
Users and liquidators see an outdated picture, the first liquidation transactions go through at the wrong price, and then cascading risk kicks in.
The mechanics of the cascade are simple and therefore dangerous. The first wave of liquidations dumps collateral onto the market, the price falls further, the next wave hits positions that a second ago were safe.
If the protocol has no mechanism to break this loop — for example, fixed-window auctions or limits on liquidation volume per block — the system drowns itself.
A separate problem is the accounting mismatch: the debt is denominated in a stablecoin, the collateral is in a volatile asset, and when the price moves quickly, the protocol's internal balance stops reconciling with reality.
Oracle delays make all of this worse. While the price updates once every few minutes, liquidators with a faster data source take the collateral at an undervalued price, and the protocol is left with bad debt.
Below we break down how this is closed at the architecture level: the choice of price sources, collateral ratio thresholds and buffers, the logic of collateral liquidation, and protection against cascading risk.
What managed emission and collateral accounting provide
Managed emission is when the issuance of new stablecoin units is possible only through opening a position against collateral, and each such action is immediately reflected in the overall accounting.
The protocol knows at any moment how much stablecoin is in circulation and what collateral backs it, so emission ceases to be a manual operation and becomes a consequence of demand for loans.
Collateral accounting is built on continuous recalculation of the value of collateral and debt for each position.
When the price of the collateral asset changes, the system updates the collateral ratio and either allows further debt management or triggers liquidation of part of the position.
There are no discrepancies between the issued volume and the recorded collateral, because both values are calculated from the same state.
The protocol's resilience during sharp market movements rests on three things: a buffer in the collateral ratio, liquidation thresholds, and parameters that can be changed without stopping the system.
This reduces the class of failures in which the protocol loses the ability to repay debt — instead of an avalanche-like collapse, partial liquidations kick in, and emission remains predictable.
Debt management gives the borrower a clear set of actions: add collateral, partially repay the position, close it entirely. Each action changes the accounting state atomically, so there are no intermediate states in which the protocol's balance does not reconcile.
For the system owner, this means that reporting on emission and collateral is assembled from the protocol itself, rather than reconstructed after the fact.
CDP Models: Isolated Positions and Shared Pool
The choice of CDP model determines how the protocol survives collateral drawdown and how predictably liquidation behaves.
In an isolated position, each collateral services only its own debt: a drop in one asset does not drag the others down, and risk is confined to the bounds of a specific position.
In a shared pool, collaterals are combined, and the borrower can use cross-collateralization — one asset backstops the debt on another, which increases capital efficiency but ties together the risks of all participants.
Below is a comparison of architectural options by applicability and limitations.
| Model | When it fits | Limitations |
|---|---|---|
| Isolated collateral | Volatile or new assets where it is important to limit risk contagion | Lower capital efficiency: each debt requires separate collateral |
| Shared pool | Stable assets with correlated dynamics, a bet on capital efficiency | A drawdown in one collateral pressures the entire pool, liquidations are harder to manage |
| Cross-collateralization | Borrowers with a diversified collateral portfolio | Requires correct weights and correlations, otherwise risk is underestimated |
In practice, mature protocols combine approaches: isolated markets for risky assets and a shared pool with cross-collateralization for the core of the portfolio. Such a hybrid gives the borrower flexibility and the protocol a manageable risk class.
The CDP model is chosen not by fashion, but by the profile of the assets and the acceptable pool drawdown.
We have designed CDP architectures on MakerDAO-like principles and know where isolation saves the day and where a shared pool wins on capital efficiency. Describe your set of collateral assets — we will come back with an assessment and a recommended model.
How we implement a CDP stablecoin: project phases
Implementing a CDP protocol starts not with code, but with formalizing the collateral economy: which assets we accept, what coefficient limits the debt, and at what threshold liquidation is triggered.
The stability of the entire system depends on these parameters, so we put them in writing and agree on them before the first line of implementation — changing them on a live system is expensive.
- Requirements and collateral model audit. We analyze target scenarios, acceptable types of collateral, and behavior during sharp market movements. The output is a specification of risk parameters and issuance limits.
- Position accounting scheme. We design the structure of debt obligations, the accrual of a stability fee, and the separation of protocol and user balances. We separately describe how debt repayment and collateral release are accounted for.
- Oracle setup. We connect several independent price sources with aggregation and protection against manipulation on a thin market. We determine how the protocol behaves when quotes diverge and one of the channels becomes unavailable.
- Liquidation setup. We define thresholds, the penalty, and the procedure for auctions or fixed buyouts. We verify that partial liquidation closes the debt without zeroing out the position entirely.
- Scenario testing. We run sharp collateral price drops, liquidation cascades, rate spikes, and oracle manipulation attempts. Each scenario includes the expected and actual behavior of the system.
- Protocol handover. We deploy the contracts, hand over access, documentation on parameters, and instructions for changing risk settings.
This sequence makes it possible to launch a CDP stablecoin without surprises at the moment of the market's first stress. Describe your task — we will come back with an estimate and a project plan.
Access policies and protocol parameter management
The CDP protocol does not exist in a vacuum: any change to collateral ratios, asset limits, or the stability fee rate is a governance decision with consequences for all positions.
That is why we deliver to the client not a "set of contracts" but a working governance loop: who can change what, within what bounds, with what confirmation, and with what trail in the log.
We separate access roles according to the principle of least privilege and fix them in a matrix: protocol administrator, parameter operator, oracle service, treasury module, auditor-observer.
Each role has its own set of calls, limits, and mandatory second-signature confirmation for critical operations. This way, a compromised operator key does not open access to the collateral pool.
- Role and permission matrix: who calls which functions, which operations require multisig, where timelocks on execution are in place.
- Protocol parameter registry: collateral ratios for each asset, emission ceilings, fee rates, liquidation thresholds — with the allowable corridor and current value specified.
- Change procedure: the sequence of steps from proposal to execution, the public disclosure period, justification requirements, and the rollback procedure.
- Emergency stop procedure: who initiates it, which modules are frozen, how operations resume, and what happens to open positions.
- Incident documentation: the post-mortem template, event classification, responsible parties, response timelines, and the procedure for notifying holders.
- Change and access log: an immutable history of calls tied to role, time, and justification.
- Instructions for the client's team: how to carry out a scheduled parameter change and how to act when the oracle deviates.
We hand all of this over as living documents alongside the code, not as a one-off report.
The parameter change procedure and the role matrix are updated together with the release — when the project is handed over, the client's team can carry out a change on its own without waiting for us.
Case: stabilizing accounting during sharp market movement
The project is a CDP stablecoin with collateral pools in several volatile assets.
At the market peak, the price oracle updated less frequently than the rate managed to move, and liquidation auctions went negative: some positions closed below the collateral threshold, and the discrepancy between internal debt accounting and the actual pool balance accumulated to several percent of the emission.
What it was like before the changes
- The share of successful liquidations during a volatility spike fell to 71%: some auctions were canceled, some closed with a collateral shortfall.
- The discrepancy between debt accounting and actual collateral reached 3.4% of the total emission volume.
- Recovery after a spike took 40+ hours of manual reconciliations and position adjustments.
- Liquidators left for competitors: without a guaranteed bonus payout, the auction did not justify the risk.
What was changed
The oracle was switched to aggregation of several independent sources with median smoothing and a strict freshness window — a stale price no longer passes into the liquidation loop.
Auctions received a fixed liquidator bonus and front-running protection: the order is executed at the price fixed at the moment of start, not at the moment of inclusion in the block.
A reconciliation loop was added: every few minutes the system compares internal debt accounting with the pool balance and, if the discrepancy exceeds the threshold, halts new loans until alignment.
This turns the discrepancy from an accumulated problem into an incident with a clear owner and response time.
Metrics after
| Indicator | Before | After |
|---|---|---|
| Share of successful liquidations | 71% | 98.6% |
| Accounting discrepancy | up to 3.4% | < 0.1% |
| Recovery time after a spike | 40+ hours | 2-3 hours |
| Canceled auctions per spike | 1 in 4 | < 1 in 50 |
The protocol went through two sharp market movements without manual intervention in positions: the reconciliation loop triggered twice, and both times alignment took less than an hour.
Liquidators returned — the guaranteed bonus made auctions predictable, and order depth grew so much that large positions close without a drawdown in the collateral price.
Chainlink was used as one of the price sources at the aggregation stage — but the key was not the source itself, but the rule for discarding stale values and the reconciliation loop, which catches the discrepancy before it becomes a loss.
How does the CDP model differ from synthetic debt?
The CDP model is collateralized debt: to issue a stablecoin, the borrower locks collateral in a smart contract, and the issuance volume is rigidly tied to the value of that collateral through the collateralization ratio.
Synthetic debt works differently: a position is created against a basket of assets or a settlement index, rather than against specific collateral, and its backing is recalculated according to the protocol's rules, not by the fact of locking.
The difference shows up in a moment of stress: a CDP has an unambiguous answer as to whose collateral and in what volume covers the issuance, while synthetics have only a calculation model.
The key engineering difference lies in how the debt's backing is calculated. In a CDP system, every token issued is traceable to a specific position: the collateralization ratio, liquidation threshold, and auction mechanism are set in the contract and verified on every block.
In synthetics, issuance relies on the aggregate value of the basket, so when prices diverge between sources, the question arises of which oracle to treat as the truth. For a client, this is a choice between predictability of liquidations and flexibility of basket management.
Issuance also behaves differently. A CDP issues a stablecoin only against new collateral — supply grows along with the inflow of backing, and this limits the risk of unbacked issuance.
The synthetic model can scale supply faster, but pays for this with more complex debt accounting and greater dependence on external price feeds.
If the goal is a stable settlement instrument with transparent backing, the CDP model offers a narrower and more understandable class of failures.
Choosing a model is choosing which failures you are prepared to service. A CDP system requires well-thought-out liquidation parameters, robust oracles, and auction audits: an error in the threshold zeroes out positions faster than the market can react.
Synthetics require discipline in basket management and protection against price manipulation. We analyze the client's task, calculate stress scenarios for both approaches, and come back with an estimate and a plan — for a specific economy, not for a fashionable template.
Common technical concerns about CDP stablecoin
The protocol is already deployed, and the question is not "where to start" but "what can be changed without stopping it." We answer the technical concerns that most often come up during the evaluation stage.
We already have a protocol deployed — will migration break user positions?
Migration is done in stages: first, new modules (rate calculation, oracle adapter, liquidation logic) are deployed alongside the old ones and run in comparison mode. While both circuits compute the same thing, we compare the results and make sure the discrepancies are zero.
The switch is done via an administrative call that changes the module address rather than rewriting storage: positions, collateral, and debts stay in place. Rollback is a reverse call to the previous address, and no state is lost in the process.
If the contracts are immutable, there is a second path: a new instance of the protocol and transferring positions via a migration contract, where the user confirms the transfer themselves. This takes longer and requires communication with holders, but it does not depend on admin rights.
How do you verify oracles — what happens during a sharp price move?
The oracle is the only point where external data enters collateral calculation, so we check not "whether it works" but "how it behaves during gaps." We set up a circuit with several independent sources and a median instead of a single feed, and add freshness and deviation-from-previous-value checks: if the price moves beyond the threshold within a single interval, the update is not accepted until confirmed.
Separately, we run scenarios with delayed publication and with diverging sources — the protocol should pause liquidations rather than trigger on a broken price.
How do you test liquidations if they cannot be "touched" in production?
Liquidation is a rare and costly event, so we test it on a fork of the mainnet with real contract state and impersonated addresses.
Scenarios: collateral falling below the threshold, partial liquidation, auction in a falling market, and a situation where liquidation is unprofitable and the position remains uncovered.
We record each run by metrics — how much collateral was taken, what debt remained, how much the borrower lost. Separately, we test resistance to attempts to manipulate the price before liquidation.
If you already have code or an audit for your protocol, we will review the current scheme and come back with a change plan and an estimate.
Let's discuss your CDP stablecoin task
To come back with a protocol estimate and a work plan, we need a minimum of input from you — otherwise the calculation turns into guesswork. Below is a list of what removes 80% of the uncertainty at the start.
If some points aren't formulated yet — send them as they are, we'll clarify the rest in correspondence.
- Collateral requirements. Which assets we accept as collateral (native token, liquid pairs, tokenized assets), whether different collateral factors and limits per each type are needed.
- Target peg and stability mechanism. What the stablecoin is pegged to, what serves as the source of stability, how we react to price deviation.
- Risk parameters. Target collateral ratio, liquidation threshold, liquidation penalty size, allowable price deviation from the peg.
- Roles and access. Who manages the protocol parameters, whether multisig is needed, whether there are external auditors and how the rights are distributed.
- Liquidation scenarios. Who acts as the liquidator, whether an auction is needed, how we protect against cascading liquidations during sharp market moves.
- Environment and integrations. Deployment network, whether a custom interface is needed, integration with wallets, price oracles, external services.
- Constraints and timelines. Whether there are regulatory requirements, a launch deadline, the expected volume of operations at the start.
Based on this data we assemble a protocol estimate: we calculate the economics of collateral and liquidations, check the model's resilience to drawdowns, and fix the contract architecture and scope of work.
We come back with a phased plan, team composition and risks — no generalities, with concrete forks where your decision is needed.
Describe the task in free form or send answers point by point — we'll come back with an estimate and a plan.