Building a Strong Security Framework for Stablecoins

By Riyaz Faizullabhoy, Engineering Lead, Security Engineering at Anchorage Digital; BSSC Board Member

Stablecoins combine two systems with very different operating assumptions. Onchain transactions can settle in seconds and run 24/7. But stablecoins connect the onchain systems with offchain systems that integrate with traditional finance systems. For fiat-backed stablecoins, that may include banks, custodians and other financial institutions.

That connection creates security risks that extend well beyond the smart contract. A stablecoin can have well-audited code and strong key management and still face serious problems if its reserves are inaccessible, redemption processes fail, administrative keys are compromised or a critical counterparty goes offline.

For organizations issuing or integrating stablecoins, security needs to cover the entire system, from smart contracts and keys to reserves, banking relationships, compliance, redemption and distribution. The most important controls are often found at the points where those systems meet.

Start with the entire system

Stablecoins inherit the security risks of other blockchain assets: smart contract vulnerabilities, compromised keys, blockchain outages, custody failures and, increasingly, risks associated with bridges and multiple chains.

They also introduce additional dependencies.

For a reserve-backed stablecoin, for example, security depends on whether the reserve exists, how they are held, whether they are segregated from other assets, who controls them and how quickly they can be accessed when a holder wants to redeem.

A problem with a bank, custodian, compliance process or redemption mechanism can affect the token even when the blockchain itself is operating normally. Stablecoin reserves held as bank deposits at just a few banks are a clear example: in March 2023, USDC briefly lost its peg with $3.3 billion stuck at Silicon Valley Bank.

The boundary between systems deserves particular attention. A blockchain transaction might finalize within seconds, while moving fiat can take considerably longer. A stablecoin framework needs a clearly defined process for managing that difference rather than assuming the two sides will behave in the same way.

Design controls around the way the stablecoin works

Different stablecoin models create different security and operational risks.

• Fiat-backed stablecoins have significant dependencies on reserve management. Organizations need evidence that the reserves exist, that they correspond to outstanding tokens and that they cannot be used for unrelated purposes in a way that puts holders at risk. Redemption should also occur within a predictable timeframe.
• Crypto-collateralized stablecoins add more onchain dependencies, which also can add additional attack vectors. They may rely on price oracles — systems that provide external pricing information — as well as smart contracts that determine collateral requirements and rebalancing. Security teams need to understand what happens if those inputs are wrong, unavailable or manipulated.
• Algorithmic stablecoins can have even less room for error. When the mechanism depends heavily on market incentives, a single software flaw or failure in the underlying assumptions can rapidly affect the value of the entire system.

Operationally, both crypto-collateralized and algorithmic stablecoins are less accepted in regulatory frameworks. They are effectively barred by Europe’s MiCA (Market in Crypto-Assets Regulation). Under the GENIUS (Guiding and Establishing National Innovation for U.S. Stablecoins) Act that recently became law in the United States only US dollar, backed stablecoins or “payment stablecoins” as they are called in the law are federally regulated. The GENIUS Act is silent on the federal regulation of crypto-collateralized stablecoins and algorithmic stablecoins, other than making it clear they are not payment stablecoins.

The security program should therefore begin with a simple question: What exactly maintains the stablecoin’s value, and what systems must continue working for that mechanism to function?

Make minting a controlled process

One of the most important controls is preventing unauthorized or excessive issuance.

The issuer should not be able to act as an “infinite money printer.” Minting needs clearly defined authorization, limits and controls, with the administrative keys protected accordingly.

The same principle applies to other privileged functions such as burning, freezing and upgrading a smart contract. These actions may be necessary for the stablecoin to operate and comply with legal requirements, but they also create concentrated points of risk.

I would recommend:

• Separate permissions for sensitive functions rather than giving one key every administrative capability.
• Hardened key storage, with secure infrastructure or institutional grade custody where appropriate.
• Quorum approval so no single person can authorize a critical action.
• Policy enforcement that checks predefined conditions before a transaction can be signed.
• Clear limits on the amount or type of activity that can be authorized.
• Regular review and testing of the entire administrative process.

Traditional financial institutions use similar principles through separation of duties and “maker-checker” controls. Blockchain systems can enforce those principles cryptographically.

The important difference is that an onchain transaction is generally irreversible. Once funds move, there may be no practical way to claw them back. That makes preventive controls particularly important.

Prove that your controls actually work

A recovery procedure that exists only on paper is not a security control.

Organizations should periodically demonstrate that they still control their administrative keys without performing sensitive operations. For example, they can use specially structured messages to verify that signing systems and keys remain functional.

Recovery also needs to be tested.

If a quorum requires five of seven keys and one key is lost or compromised, the organization should already know how to remove that key, add a replacement and restore the quorum. That process should be tested before an emergency makes testing difficult or impossible.

The same principle applies to reserves. Regular attestations can provide evidence that required assets are present, but organizations also need appropriate accounting, segregation and controls to establish that those assets remain available to support the tokens.

Protect the reserve from more than theft

Reserve security is not simply a question of whether someone can steal the assets.

Organizations need to consider what happens if a bank, custodian or issuer encounters financial or operational problems. Client or token-holder assets should be clearly separated from other assets, with records that establish what belongs to whom and protections against those assets becoming entangled with an intermediary’s own estate.

This is an area where traditional financial controls are particularly relevant. Asset segregation, accurate books and records, independent audits, regulatory examinations, anti-money laundering (AML) and sanctions controls, and tested business continuity processes all have a place in a stablecoin security program.

The goal is not simply to demonstrate that reserves exist today. It is to build a well-supported basis for confidence that those reserves can remain available when holders need them.

Monitor redemption as a security signal

Redemption deserves its own monitoring.

A stablecoin may operate perfectly onchain while the process for converting it back to fiat is slowing down or becoming concentrated in a small number of accounts or counterparties.

Operators should monitor:

• Redemption processing times.
• Balances in accounts used for redemption.
• Delays or failures in fiat transfers.
• Reserve balances relative to outstanding tokens.
• Availability of banks, custodians and other redemption counterparties.
• Whether AML and sanctions controls continue to operate on both the crypto and fiat sides.

This monitoring should feed directly into incident response and business continuity plans. If a bank, custodian, exchange or other critical intermediary becomes unavailable, the organization should already know how it will continue operating or how it will safely restrict activity.

Treat the surrounding infrastructure as part of the attack surface

Stablecoin security does not end with the issuer.

Exchanges, custodians, banking partners and other distribution or infrastructure providers can become critical dependencies. An outage or security incident at one of these organizations can cause delays, disrupt access to funds or create direct losses for users.

This is particularly important as stablecoins operate across multiple chains and services. Before adding support for another blockchain, organizations should perform a specific assessment of that chain and its associated infrastructure rather than assuming that existing controls transfer automatically.

The same principle applies to the traditional security perimeter. Developer environments, production infrastructure, authentication, access controls, monitoring and incident response remain important. Blockchain-specific controls should supplement those practices, not replace them.

Use scale as a reason to strengthen controls

Scale does not fundamentally change the underlying principles of key management, but it changes the attractiveness of the target.

A stablecoin with significant transaction volume or total value locked (TVL) is a more attractive target than a smaller asset. That makes strong controls around key access, transaction authorization and monitoring increasingly important as adoption grows.

At scale, policy controls become particularly valuable. Rather than simply asking whether a transaction has been approved, the signing system can enforce conditions such as who can authorize it, what type of action it is and whether the requested amount falls within an established limit.

Make transparency work for security

One advantage of most blockchain systems is that their ledgers are public and transactions are traceable.

That creates some obvious concerns: attackers can see where significant balances are held, and suspicious activity can be visible to everyone. But the same transparency can help operators and authorities identify and trace illicit or anomalous movements in real-time.

Security teams should treat that visibility as an asset.

Monitoring should be designed to make use of the information available on-chain — not simply to react after funds have moved, but to establish expected behavior and identify deviations quickly.

Build hard limits into the system

Good rules can be security controls.

As stablecoins become more interconnected, there is a risk that a failure at one institution or counterparty could spread beyond that organization. Well-designed requirements around reserves, issuance, permissions and operational limits can reduce that risk.

That includes thinking carefully about hard caps and other constraints that prevent one component of the system from accumulating an outsized exposure. The experience of a bank run impacting availability of reserves for a stablecoin in 2023 is a useful reminder that rules governing concentration and exposure can have consequences beyond an individual institution.

This is also where industry standards can help. Common expectations around reserve transparency, custody, smart contract governance, new-chain assessments and administrative controls would make it easier for organizations to evaluate stablecoins consistently. As stablecoins cross borders, a common baseline would also reduce the risk of materially different security expectations being applied to connected systems.

Think in terms of failure, not just prevention

The strongest stablecoin security programs do more than ask, “How do we stop this from happening?”

They also ask:

• What happens if a key is lost?
• What happens if a bank or custodian fails?
• What happens if the blockchain is congested or unavailable?
• What happens if redemption slows dramatically?
• What happens if an exchange or distribution partner is compromised?
• What happens if reserves become temporarily inaccessible?
• What happens if an administrative function is compromised?

Some blockchain failures cannot be reversed after the fact. That makes prevention, limits, quorum controls and tested recovery procedures particularly important.

Stablecoin security is ultimately a systems problem. The token, smart contract and blockchain are only part of the system that users rely on.

The strongest approach combines established cybersecurity and financial controls with blockchain-specific safeguards — then pays particular attention to the edges between them. Those edges introduce additional risk, but they are also where thoughtful controls, monitoring and clear rules can prevent a local failure from becoming a much larger one.