Depositing into a vault across chains: how far should you read “Success” on the receipt?
On October 8, Chainlink introduced CCIP Vault Adapters, which send cross-chain assets and deposit instructions to the chain where the vault is located, so the vault can handle its accounting on that chain. What’s worth examining is what happens to funds after a failure.
According to the official adapter documentation, if the target vault call, minimum output check, or return transfer fails, the adapter saves the failed message and tokens. At that point, CCIP Explorer may still show Success, so you need to check the MessageFailed event separately. This process does not automatically retry or refund the transaction.
This means that delivery of a cross-chain message does not mean the user has received vault shares. The documentation also specifies that cross-chain refunds go back to the original sender, not the deposit beneficiary. If a relayer is used or the refund address differs, the interface should explain where the refund will go before the transaction is sent.
My view: To evaluate the “one-click deposit” experience, you need to consider both successful delivery and how failures are handled. Clearly showing failure records, where the funds are, and available recovery options is more useful than simply displaying a successful bridge transfer. This discusses the mechanism described in the documentation; it does not mean that any particular vault is experiencing a failure, nor does it imply anything about returns or fund safety.
Sources:
https://chain.link/blog/introducing-ccip-vault-adapters
https://docs.chain.link/solutions/cross-chain-vault-adapter
On October 8, Chainlink introduced CCIP Vault Adapters, which send cross-chain assets and deposit instructions to the chain where the vault is located, so the vault can handle its accounting on that chain. What’s worth examining is what happens to funds after a failure.
According to the official adapter documentation, if the target vault call, minimum output check, or return transfer fails, the adapter saves the failed message and tokens. At that point, CCIP Explorer may still show Success, so you need to check the MessageFailed event separately. This process does not automatically retry or refund the transaction.
This means that delivery of a cross-chain message does not mean the user has received vault shares. The documentation also specifies that cross-chain refunds go back to the original sender, not the deposit beneficiary. If a relayer is used or the refund address differs, the interface should explain where the refund will go before the transaction is sent.
My view: To evaluate the “one-click deposit” experience, you need to consider both successful delivery and how failures are handled. Clearly showing failure records, where the funds are, and available recovery options is more useful than simply displaying a successful bridge transfer. This discusses the mechanism described in the documentation; it does not mean that any particular vault is experiencing a failure, nor does it imply anything about returns or fund safety.
Sources:
https://chain.link/blog/introducing-ccip-vault-adapters
https://docs.chain.link/solutions/cross-chain-vault-adapter