A risk assessment framework for stablecoins and crypto treasuries

Stablecoin and crypto protocol risk breaks into four layers: settlement, issuance, application, and user. Within each layer, risk splits further into technical, operational, and governance and regulatory domains (plus market risk where it applies), each scored 0 for low risk, 1 for medium, or 2 for high, and averaged into a category score. When the underlying data isn't transparent enough to answer a question confidently, the framework defaults to high risk rather than assuming the best case.

Settlement layer

The blockchain foundation the token depends on to actually move and finalize: the base chain's finality guarantees, bridge security if the asset exists on multiple chains, and the operational maturity of any cross-chain messaging involved. A token that's rock-solid on its native chain can pick up serious risk the moment it crosses a bridge with a short security track record.

Issuance layer

Where coins are created, collateralized, and redeemed, and who controls that process. Take USDC as a concrete example: the contract has a designated "blacklister" role that can call a blacklist() function to add an address to a registry. A notBlacklisted modifier then checks that registry before allowing transfer() or transferFrom() to proceed, and reverts the transaction if either party is flagged.

That's a real, callable code path controlling a real transfer function, exercised under the issuer's own access-deny policy to freeze accounts or block redemption. It holds regardless of how permissionless or censorship-resistant the underlying blockchain claims to be, which is exactly why issuance risk needs to be scored on its own terms, not assumed away because a chain markets itself as decentralized.

Application layer

Wallets, exchanges, DeFi protocols, and bridges built on top of the asset, and the risk they add independent of the token itself. An otherwise well-run stablecoin can still expose a treasury to real loss through a poorly collateralized lending integration or a thinly audited bridge, so this layer scores integration depth and each integration point's own audit and incident history, not just the base asset.

User layer

Individual behavior, wallet security, and how well a holder actually understands what they're exposed to: who holds the keys, what the signing and approval process looks like, and what happens when a signer leaves or a device is compromised. This is often the weakest layer in practice. The asset and protocols underneath can be sound while the operational process around them is not.

Risk domains within each layer

Each of the four layers is scored across three to four domains: technical risk (protocol and infrastructure security), operational risk (custody, redundancy, incident response), governance and regulatory risk (oversight, transparency, compliance), and, where relevant, market risk (collateralization, liquidity). Splitting a layer this way keeps a strong technical score from masking a weak governance score, or vice versa.

Putting the score together

Individual questions within a domain score 0 (low risk: strong controls and transparency), 1 (medium risk: partial controls with acceptable visibility), or 2 (high risk: real vulnerabilities or opacity, and the default whenever data isn't available at all). Averaging question scores into a category score lands it in a Low (0.0-0.6), Medium (0.7-1.3), or High (1.4-2.0) band.

Score each layer independently rather than collapsing to a single number. A high settlement score and a low issuance score point to a genuinely different remediation plan than the reverse, and treasuries need to know which lever to pull, not just how worried to be overall.

Further reading

The full methodology and scoring questions are maintained as an open-source framework on GitHub. The reasoning behind it is written up across a five-part series on Medium: The Stablecoin Payments Stack: an Introduction, Stablecoin Risk Management, Towards a Framework for Stablecoin Risk Analysis, Stablecoin Risk Assessment Framework, and Circle USDC Blacklist Implementation.

FAQ

Why separate settlement risk from issuance risk?

They fail differently. A settlement failure is a chain, bridge, or infrastructure problem: the token can't move or finalize correctly. An issuance failure is a governance problem: the entity that can mint, freeze, or blacklist the token makes a decision that affects your holdings, independent of any code bug. Blending them into one score hides which lever actually matters for a given risk.

What does blacklist risk actually look like at the code level?

In USDC's contract, a blacklister role can call a blacklist() function that adds an address to a registry; a notBlacklisted modifier then checks that registry before allowing transfer() or transferFrom() to proceed, and reverts the transaction if either party is flagged. That's a real, callable function controlling a real transfer path, not a theoretical risk, and it holds regardless of how permissionless or censorship-resistant the underlying chain claims to be.

How does the scoring actually work?

Each layer breaks into risk domains (technical, operational, governance and regulatory, and market where relevant), each made up of individual questions scored 0 for low risk, 1 for medium, or 2 for high. Question scores average into a category score, which lands in a Low (0.0-0.6), Medium (0.7-1.3), or High (1.4-2.0) band. When the data needed to answer a question isn't available, the framework defaults to High rather than assuming the best case, because a lack of transparency is itself a risk.

Who is this framework actually for?

Treasuries and funds deciding which stablecoins to hold, protocols deciding which assets to integrate, and DAOs or companies setting internal risk policy for on-chain holdings. It's built for repeatable, defensible risk decisions, not a one-time yes/no verdict.

I use this framework directly in stablecoin and treasury risk engagements. Happy to walk through how it'd apply to your holdings or protocol. Get in touch.