Your Vault Risk Assessment is a forward-looking, relative opinion, not a credit rating and not a comment on yield. What gap does it fill for people who allocate to vaults?
We are providing insight on risks for the entire vault, not just the assets. So we are looking from underlying lending markets to smart contracts and everything in between. I think transparency and a consistent and comparable way to assess risk is useful in this space.
"The risk for a vault isn't just a point in time. It is what it could hold."
Your approach looks at what a vault is permitted to hold, not only what it holds today, so loosening an allocation cap may weaken an assessment even if nothing has moved. Why did you choose that approach?
The risk for a vault isn't just a point in time. It is what it could hold. So, if a vault can move into a significantly riskier market tomorrow without anything preventing it, that flexibility is part of the risk an investor is taking today. The assessments are intended to be structural and capture the boundaries within which a vault can change over a short time horizon.
A Vault Risk Assessment is periodic, but onchain risk moves in real time. How should a protocol combine the two, and where does an "under review" designation fit in?
I don't think the two are substitutes. The assessment provides a structural view of risk, while real-time monitoring can identify a rapidly changing market, liquidity or technical condition within that structure.
We do monitor in real time and would adjust an assessment ad hoc if necessary. We can act outside a periodic review cycle when developments warrant it. In the Vault Risk Assessment framework, for example, an "under review" designation tells the market that new information or an event may be material to our opinion and we're actively evaluating it.
"A lending market may look liquid under normal conditions, but if there are large suppliers that want to withdraw, that liquidity can disappear very quickly."
Your FAQ says that when one supplier provides more than 20% of a lending market's assets, the market risk assessment is generally no better than a '3'. Why does concentration matter that much, and which vault risk do you think is the most underestimated?
Concentration matters because liquidity is what will likely be stressed when there is a pressured condition. A lending market may look liquid under normal conditions, but if there are large suppliers that want to withdraw, that liquidity can disappear very quickly.
More broadly, I think liquidity mismatch is an important one. It's not simply about how liquid the collateral is in a regular market. You also need to ask who else depends on that liquidity and whether several large withdrawals could occur at the same time.
Vaults that lend against tokenized real-world assets are in scope, but those tokens often can only be sold to approved participants. How does that change the liquidation picture compared with crypto collateral?
In a scenario with liquid crypto collateral, you can have a broad permissionless market and economic incentives for liquidators to participate. A tokenized RWA may only be transferable to approved participants, so we would look at how it will be liquidated. Whether someone is contractually committed to purchase liquidated collateral, how strong that commitment is, and the counterparty risk created by relying on that party would all be considerations.
Your June FAQ rates tokenized money market and bond funds within your existing fund methodologies instead of a new one. What do you look at for a tokenized fund that you would not for a traditional one?
We start with the same fund methodology. Tokenization introduces some different operational risks that still fit within the same methodology. We look at things like smart-contract security and audits, wallets and administrative controls, oracle dependencies, the subscription and redemption process, blockchain resilience, bridging or multichain risks, and what the contingency planning is, if needed.
Since S&P Global Ratings partnered with Chainlink in October 2025 to bring Stablecoin Stability Assessments onchain, where do you see protocols using them inside their smart-contract logic?
Smart contracts can have built-in parameters. It is possible to envision contracts that build risk parameters in, one of which could perhaps be an assessment. Portfolios could be created based on different risk levels stated in the smart contract.
"Assets are the starting point, so a stablecoin backed by very strong assets starts from a stronger position."
Six of the 11 stablecoins you assess are now adequate or above, and two assessments were revised to a weaker level over the past three quarters. What separates the stronger ones from the weaker ones?
Stablecoin Stability Assessments assess the likelihood of a depeg. Assets are the starting point, so a stablecoin backed by very strong assets starts from a stronger position. For example, some of the stablecoins we assess are backed by high-quality, highly liquid dollar- or euro-denominated reserve assets held with strong counterparties.
We then consider other factors, including governance, the legal and regulatory framework, liquidity and redeemability, technology and track record, which can weaken that starting point. But fundamentally, strengths in those areas don't eliminate weaknesses in the assets backing the stablecoin.
Within what you are able to share, where could independent assessments add value next?
Beyond our new Vault Risk Assessment, I think we can add value where there are information asymmetries or where frameworks can facilitate an understanding of risks.
"Keep an eye out for concentration, which is true for who holds the asset as well as who holds the keys."
Where are the biggest remaining risk-transparency gaps in DeFi, and what is the one thing institutions should start or stop doing when they assess onchain risk?
I think a major area to keep an eye on is operational security and who controls the process. Keep an eye out for concentration, which is true for who holds the asset as well as who holds the keys.


.jpeg)













%201.png)
%201.png)









%201.png)


