If your ERC-4626 vault is about to accept deposits from other chains, this one is for you.
On October 8, Chainlink launched CCIP Vault Adapters. A standard ERC-4626 vault on one chain can now accept deposits from more than 80 others, while the accounting, governance and risk parameters stay on its home chain. Aave, Lombard, Veda and Venus are among the first users.
Four days earlier, S&P Global Ratings launched a Vault Risk Assessment. It scores a lending vault on six factors, and two of them are about code: protocol risk, and vault security and governance. "A strong score in one factor does not offset a material weakness in another," one of S&P's analysts told Cointelegraph.
And the money is there. Deposits in DeFi lending vaults passed $10 billion, up from about $4 billion at the start of 2025, according to the Financial Times, as reported by CoinDesk.
My read
A vault is becoming something an outside party scores, and part of that score is your code. I think that's a good thing. A depositor reading a risk score asks better questions than a depositor reading an APY.
One-click deposits are good for users too. But they move the hardest question in cross-chain finance out of the user's wallet and into your vault: did the full amount actually arrive? Before, the user bridged, waited, and deposited whatever landed. Now your contract mints shares for a deposit that started on another chain. Chainlink is clear about where its part ends. Its own disclaimer says it "does not deploy, control or operate any vault or vault adapter." The transport is theirs. The accounting is yours.
What breaks when a vault goes cross-chain
My team reviewed this kind of system in September. Yieldcoin v2 is a five-chain stablecoin vault built on Chainlink CCIP and CRE: a parent vault keeps the books, and child vaults on other chains put the money to work in Aave and Compound. It built its own CCIP flows before the new adapters existed, so none of this is about Chainlink's product. These are the three findings I'd check in any cross-chain vault:
-
A successful send is not a delivery. CCIP token pools can charge a transfer fee. The code minted shares from the amount sent and treated a successful
ccipSendas proof that the full value arrived. With a fee on, the destination received less, every call still succeeded, and the shares were backed by less than the books said. Nothing reverted, so nothing alerted. The fix: reconcile shares to the amount that actually arrived. - A signed command has to name its receiver. The signatures covered the report, but not which contract received it. A valid withdrawal meant for one child vault could be replayed through another. That was the Critical. The fix: sign the target chain and the router too.
- A retry only helps if the failure can change. Netting could shrink a deposit to one base unit of USDC. Aave v4 rounds that to zero shares and rejects it. The vault stored it for a retry, and the retry could never work, so later epochs and rebalancing stayed blocked. The fix: preview the conversion first, and keep amounts that can't be deposited tracked instead of retried.
The adapters do come with failed-message handling, designed to give stuck funds a path back to the owner. Asynchronous vaults and cooldowns are next on Chainlink's list, and that's where these state machines get really hard. If you're heading there, ERC-7540 (the request-and-claim pattern for async vaults) is the standard to read first.
If you're opening your vault to other chains in the next three months
Three things I'd have done before the first cross-chain deposit:
- Test with the fee switched on. Run your deposit flow on a fork against a token pool that charges a fee, and assert that shares match what arrived, not what was sent.
- Write down every failure and its exit. For each revert you catch, ask: can waiting fix this? If not, does it abort, reconcile or reroute? A stored retry for a condition that never clears is a frozen vault with extra steps.
- Get the single-chain basics right first. The first-depositor inflation attack is still the first thing I'd check in any ERC-4626 vault. Virtual shares or dead shares at deploy, and an invariant that a deposit above zero never mints zero shares.
S&P hasn't scored a single vault yet. The first assessments come "in future announcements." When they do, protocol risk and vault security sit on the list next to curator and credit risk, and a strong score on one doesn't cover a weak one on another.
If you're building one of these, I'm curious: how are you testing the cross-chain leg today, forks, mocks, or testnet?
Sources: Chainlink CCIP Vault Adapters, S&P Global Ratings press release, Cointelegraph, CoinDesk.
Originally published in my newsletter, DeFi Protocol by code.
I wrote this with help from AI for drafting and editing. The opinions and the audit experience are mine.
