Centralised vs decentralised stablecoins: what backs them and how they fail

Stablecoins can look alike in a wallet while relying on very different assets, promises and control systems.

The useful way to compare centralised vs decentralised stablecoins is to ask what supports the target price and what must keep working. A centralised token commonly depends on an issuer, reserve assets, custodians and a redemption process. A decentralised design may depend on crypto collateral, smart contracts, price data and liquidation rules.

Neither label guarantees stability. A stablecoin is a crypto-asset that aims to track a reference value, but its market price can still move away from that value. The term describes a target, not a guarantee.

The short version

• Centralised stablecoins usually rely on an issuer holding reserves and operating a redemption process.
• Some decentralised stablecoins use crypto collateral, automated rules and liquidations.
• Each structure moves risk to different places instead of removing it.
• Check the backing, conversion route, control arrangements and technical dependencies.

Centralised vs decentralised stablecoins: how the backing differs

Fiat-based centralised stablecoins place an identifiable company between the token and its supporting assets. The issuer creates and redeems tokens under its process. Cash, bank deposits, short-dated US Treasuries or related instruments may sit with banks and other custodians. Users therefore rely on the reserves and on the organisations that hold, manage and report them.

Many centralised designs aim to make one token worth one unit of a reference currency. Redemption can help connect the market price to the reserve value. Yet this connection still depends on working operations and available funds. It can weaken when the issuer, a custodian or a payment route faces trouble.

The MIT Digital Currency Initiative discussion of stablecoin analogies explains that issuers may hold liquid, high-quality assets such as short-dated US Treasuries. It also identifies counterparty exposure when reserves sit in commercial bank deposits.

A reserve can look strong on paper but still be difficult to use at speed. A valuable asset may be unavailable if a custodian is disrupted. It may also need to be sold before its proceeds can be used. The issuer must keep token supply, reserve records and redemption duties aligned while confidence is under pressure.

Crypto-collateralised decentralised stablecoins use another route. In one design family, a user locks crypto-assets in a smart contract and creates stablecoins against that position. The supporting collateral and the rules applied to it are part of the mechanism intended to keep the token near its target.

Some designs use automated liquidation when collateral loses value. This describes one crypto-collateralised model, not every decentralised stablecoin. The academic survey of stablecoin designs and risks finds that designs can be collateralised, algorithmic or hybrid. The decentralised label therefore does not establish one universal backing or stabilisation mechanism.

The backing is more than a list of assets. It includes the process that turns those assets into support for the peg. An issuer-led token centres on custody, reserve management and redemption. An on-chain collateral design centres on programmed rules, market conditions and the handling of collateral.

This distinction matters because two tokens targeting the same currency can expose holders to different chains of dependency. With a reserve-backed token, a holder may need the issuer and its financial partners to function. With an on-chain token, the important links may include contracts, data inputs and participants willing to act under the protocol’s rules.

Why a stablecoin peg can hold

A peg is often defended by conversion, market incentives or both. A price below the target may attract buyers if they trust the route back to the reference value. A price above the target may encourage new supply. Those actions can move the market price towards the target.

These forces are not guarantees. They require confidence, liquidity and working operational or technical routes. The academic survey describes stability as an emergent and fragile state rather than an inherent feature. Stability is therefore an outcome produced by a system, not a permanent property attached to a token.

A token may trade near its target for a long time and still lose the peg. Confidence may fade, liquidity may dry up or the conversion process may stop working. A calm price history does not reveal which part of the system will absorb the next shock.

Market price and backing are related, but they are not identical. A token can trade below its target while supporting assets retain value if access to those assets is delayed or uncertain. Conversely, a market price can remain close to the target for a period even while doubts about the mechanism are growing.

Recovery depends on the particular design. A reserve-backed token needs its financial and operating chain to function. A crypto-backed token needs its programmed rules and relevant markets to keep operating. In either case, a credible route between the token and its reference value can encourage trading that narrows a discount. If that route becomes doubtful, the discount may persist.

How centralised stablecoins can fail

The first failure path concerns reserve quality or availability. Reserve assets can have different settlement times, liquidity levels and counterparties. A bank or custodian problem may put an issuer under pressure even if the assets appear adequate in total.

The second path is a redemption bottleneck. Heavy requests can test the issuer’s available funds, records and payment routes at the same time. A delay can weaken confidence and push the market price below its target. A widening discount may then encourage more holders to sell.

There is an important gap between an asset’s stated value and its immediate usefulness. A Treasury security may still require a sale and settlement. A bank deposit may be liquid in ordinary conditions but unavailable during disruption. The issuer needs usable funds when they are required, not merely assets with an adequate reported value.

Reserve composition also affects how a shock travels through the system. Assets held with financial counterparties create exposure to those organisations. Assets that must be sold create reliance on functioning markets and settlement. Concentration can matter because a disruption at one important link may affect a large part of the operating chain.

The third path concerns administrative control. Stablecoin smart contracts can include special administrative functions, including the ability to halt transactions or upgrade contract code. These functions create dependence on the systems and cryptographic keys used to exercise them. The exact powers differ by product, so they must be checked rather than inferred from the centralised label.

Administrative functions may be useful for operating or changing a system, but they also create a security boundary. A failure involving a controlling key or process could affect the contract. The relevant questions are what powers exist, who can exercise them and what safeguards surround their use.

The fourth path is confidence. Doubt about reserves, custody or redemptions can prompt holders to sell. A wider discount may encourage further selling. Clear reporting can help people assess the position, but reporting cannot make an unavailable asset liquid or repair a broken payment route.

The evidence supplied for this article does not establish the direct-redemption eligibility or terms of any particular issuer. Those details should therefore be checked in the current documentation for the specific product rather than assumed from the centralised label.

This is also why stablecoins should be separated from nearby forms of digital money. Our guide to tokenised deposits, stablecoins and CBDCs explains how similar interfaces can hide different issuers, claims and settlement structures. The substance matters more than the token’s appearance.

How decentralised stablecoins can fail

Crypto-backed systems face collateral volatility. A sharp market fall can shrink several safety buffers at once. Positions may then move towards liquidation where the particular design uses that mechanism. The result depends on the system’s rules and on conditions in the relevant markets.

Liquidation is intended to protect a system when collateral loses value. It still depends on the mechanism functioning as designed. Conditions during congestion or a sudden price gap may differ from ordinary trading. Different designs can react differently, so liquidation should not be treated as either an automatic cure or an inevitable failure.

Decentralised stablecoin designs may depend on smart contracts, price oracles and liquidation mechanisms. Code defects, price manipulation or oracle failure can undermine token issuance, collateral pools or the peg. A contract can apply a programmed rule exactly even when its logic is flawed. Open access also means vulnerabilities may be found and exploited.

An oracle is a dependency because a blockchain needs a method for receiving information about an outside market price. A protocol must determine which inputs to use and how those inputs affect its rules. Incorrect or manipulated price data can therefore disrupt a mechanism that relies on it.

The Chainalysis overview of stablecoin security risks identifies smart-contract and oracle weaknesses among the risks faced by decentralised issuers. Bridges are also smart contracts and can add vulnerabilities when stablecoins move between blockchains.

A bridge can introduce a separate contract and control system beyond the stablecoin’s core design. This means a token used on another network may depend on more than the original issuance mechanism. The risks of the connected route should not automatically be attributed to, or ignored because of, the stablecoin itself.

Governance also needs attention. A system may use votes, committees, delayed upgrades or special permissions to change its settings. These arrangements affect who can alter important rules or contract code. A decentralised label does not answer those questions by itself.

On-chain activity can make some balances and transactions visible. Visibility is not the same as complete transparency. Readers may still need specialist knowledge to understand permissions, collateral and linked systems. The useful question is whether the major dependencies can be identified and understood.

Risk is shifted, not removed

Centralised and decentralised designs shift risk rather than eliminating it. Fiat reserves can reduce exposure to crypto price swings while adding custodial and counterparty risk. On-chain designs add software, market and mechanism dependencies. A strength in one area can create reliance in another.

Cash-like reserves may be less volatile than crypto collateral, but they introduce institutions that must safeguard and return assets. Automated execution can reduce reliance on a company making each routine decision, while increasing reliance on correct code, suitable inputs and functioning mechanisms.

Decentralisation is therefore a description to investigate, not a complete risk score. A protocol can place routine actions on-chain while keeping important change powers in a small group. A centralised issuer can publish useful information while retaining administrative control. The details matter more than either label.

Transparency also has several meanings. Reserve reporting may provide information without proving that every asset is immediately available. On-chain records may expose transactions without making contract logic, governance or connected applications easy to assess. Neither form of visibility settles every risk question.

The applicable regulatory position may depend on the issuer, product, activity and jurisdiction. The research supplied for this article does not establish current UK legal requirements or protections for these products. A broad category should therefore not be treated as an answer about the legal position of a particular service.

Network design can add further risk. Fees and congestion may affect a user’s ability to trade, repay debt or add collateral during stress. Our guide to what a crypto rollup is and why networks use rollups explains why activity can span connected layers. Such a route may involve contracts and bridges beyond the stablecoin’s core system.

Worked example: following a shock through two designs

Imagine two fictional tokens that both target £1. Neither represents a real product. Token C is issued by a company that holds reserve assets through financial counterparties. Token D belongs to a design family in which users lock volatile crypto collateral and the protocol applies programmed rules to those positions.

A market rumour pushes both tokens to 96p. Token C can recover if confidence returns and its reserve and redemption chain continues to work. The issuer needs usable reserves, accurate records, active custodians and working payment routes. A problem at any point can slow the route back to £1.

The headline value of Token C’s reserves does not settle every question. Some assets may take time to sell. A custodian may suffer an outage. Payment routes may slow when many requests arrive together. Each delay can add doubt even when reserve assets retain value.

Token D has a different route. Buyers may purchase it at 96p if they trust its mechanism and expect the price to recover. At the same time, the collateral market falls and positions approach any liquidation conditions specified by the fictional design. The protocol now depends on its price inputs, contracts and stated mechanism.

If each relevant part works, both tokens may recover through different routes. Token C relies mainly on its reserve and operating chain. Token D relies mainly on collateral and programmed incentives. Either token may remain below £1 if a critical link fails.

The shock could also expose more than one weakness at once. Token C might face a custodian delay while selling pressure grows. Token D might face falling collateral values while a network is congested. A design that can tolerate one isolated problem may behave differently when several dependencies are under strain.

The example shows why the current price is only one part of the comparison. Better analysis maps the chain from backing to conversion. It asks where delay, discretion, technical error or market stress can enter. It also avoids assuming that every product follows either fictional structure exactly.

What this means for you

Start with the job you expect the token to perform. A short transfer, a long holding period and use as loan collateral create different exposures. Then trace how the position could be closed during stress, not only during normal trading.

• Backing: Identify the assets or process intended to support the target value.
• Liquidity: Ask how quickly the supporting assets can become usable funds.
• Redemption: Review the product’s published process, fees, timing, eligibility and possible interruptions.
• Control: Check documented contract permissions, administrative functions, upgrade routes and governance arrangements.
• Price data: For oracle-based designs, examine how prices are supplied and used.
• Liquidation: Understand the stated conditions and process for the particular design.
• Dependencies: Include custodians, banks, bridges and connected applications where relevant.
• Rules: Do not assume one regulatory position applies to every product, activity or jurisdiction.

These checks do not produce a universal winner. They show whether a design’s dependencies fit the intended use. They can also reveal reliance on an organisation, market or technical system that is not obvious from the stablecoin label.

Read product-specific material carefully. General descriptions of centralised and decentralised designs cannot establish a particular token’s reserve composition, redemption terms, contract powers, governance arrangements or collateral settings. Those details can determine how the token behaves during stress.

Administrative control deserves close attention when a token is used in several applications. A contract halt or upgrade can have effects beyond a simple transfer. Our guide to what a multisig wallet is and why crypto teams use multisig describes one way authority can be shared. It does not establish the permissions or safeguards of any particular stablecoin.

Consider connected systems as well as the token itself. Holding a stablecoin in a separate application or moving it through a bridge can introduce additional contracts and controls. A problem in that surrounding route may affect access even when the stablecoin’s core mechanism continues to operate.

Compare the strength of the whole chain, not one attractive feature. Good reserves do not remove custody risk. Open code does not remove software or governance risk. Collateral does not guarantee a peg. A useful review asks what happens when more than one dependency is under pressure.

In plain English

Think of a stablecoin peg as a door marked “£1”, not as a £1 coin sealed inside each token. A centralised design needs a company and its financial partners to keep the route through that door working. A crypto-backed design needs its code, inputs, collateral and specified mechanism to do the job. Either route can jam. The label tells you the goal, while the backing and conversion process tell you how the token may behave under pressure.

Related reads

• Why stablecoins are becoming the plumbing of crypto