yearnyCRV Yearn Boosted Staker Launch: All You Need to Know
All the details you'll need to be fully prepared
yearnUpcoming yPRISMA YBS Staking Launch: All You Need to Know
All the details you'll need to be fully prepared
yearnEverything Must Go
Participating in Yearn Oracle-Free & Permissionless Dutch Auctions for fun and profit
Subscribe to yearn
Share Dialog
This is part 3 of a 3 article series. The 1st article is here and the 2nd article is here.
Most yield vaults operate on a single chain. The capital a user deposits stays on that chain, and the yield opportunities available to them are limited to protocols deployed there. If a better rate exists on a different chain, a single-chain vault can't tap into it.
yvUSD is a multichain vault that removes this constraint. Users deposit their USD stablecoins into one vault on Ethereum mainnet, and the vault can deploy capital to yield sources on other chains. The user holds a single token on mainnet, yvUSD, and never has to manually bridge assets.
This article explains how the cross-chain mechanics work, the trust model behind the design, and how it handles edge cases gracefully.
Every cross-chain deployment in yvUSD involves a pair of contracts: an origin strategy on Ethereum mainnet and a remote strategy on the destination chain.
From the vault's perspective, the origin strategy looks identical to any other Yearn V3 strategy. It accepts capital, reports a total asset value, and participates in the vault's allocation. The difference is entirely in what happens behind the scenes: instead of deploying funds into a local protocol, the origin strategy bridges assets to its paired remote strategy contract on another chain.
The remote strategy receives the bridged assets and deposits them into a local yield source in an ERC-4626 vault. It periodically reports its total asset value back to the origin strategy via a cross-chain message (no tokens are transferred, just data). The origin strategy uses this reported value for the vault's total asset accounting.
This is part 3 of a 3 article series. The 1st article is here and the 2nd article is here.
Most yield vaults operate on a single chain. The capital a user deposits stays on that chain, and the yield opportunities available to them are limited to protocols deployed there. If a better rate exists on a different chain, a single-chain vault can't tap into it.
yvUSD is a multichain vault that removes this constraint. Users deposit their USD stablecoins into one vault on Ethereum mainnet, and the vault can deploy capital to yield sources on other chains. The user holds a single token on mainnet, yvUSD, and never has to manually bridge assets.
This article explains how the cross-chain mechanics work, the trust model behind the design, and how it handles edge cases gracefully.
Every cross-chain deployment in yvUSD involves a pair of contracts: an origin strategy on Ethereum mainnet and a remote strategy on the destination chain.
From the vault's perspective, the origin strategy looks identical to any other Yearn V3 strategy. It accepts capital, reports a total asset value, and participates in the vault's allocation. The difference is entirely in what happens behind the scenes: instead of deploying funds into a local protocol, the origin strategy bridges assets to its paired remote strategy contract on another chain.
The remote strategy receives the bridged assets and deposits them into a local yield source in an ERC-4626 vault. It periodically reports its total asset value back to the origin strategy via a cross-chain message (no tokens are transferred, just data). The origin strategy uses this reported value for the vault's total asset accounting.
Subscribe to yearn
yearnyCRV Yearn Boosted Staker Launch: All You Need to Know
All the details you'll need to be fully prepared
yearnUpcoming yPRISMA YBS Staking Launch: All You Need to Know
All the details you'll need to be fully prepared
yearnEverything Must Go
Participating in Yearn Oracle-Free & Permissionless Dutch Auctions for fun and profit
Share Dialog
The dual-contract architecture is bridge-agnostic. Each strategy pair uses whatever native bridge is considered appropriate for the destination chain. Circle's CCTP is a common choice for USDC transfers, Katana's native bridge can be used for its chain, and so on. The vault treats cross-chain capital the same as local capital regardless of which bridge carries it. Adding a new chain is a matter of deploying a new strategy pair with the right bridge integration, not modifying the vault. The cross-chain strategy code is available on GitHub.
When the vault allocates capital to a cross-chain strategy, the outbound capital flow has three distinct phases: send, receive, and deploy.
The origin strategy sends assets through the native bridge to its paired remote strategy on the destination chain. This process is inherently asynchronous because cross-chain bridges don't offer atomic execution or callbacks. The origin strategy increments its remote asset counter at the time of sending and trusts that the assets will arrive. For CCTP-based strategies, this means USDC is burned on Ethereum and minted on the destination after Circle's attestation service confirms finality. Other bridges have their own delivery mechanisms, but the pattern is the same.
Once received, the assets sit idle in the remote strategy contract until a keeper explicitly deploys them into the local yield source using the pushFunds() function. Why not auto-deploy funds on receipt? Because not all bridging protocols support a bridge-and-call pattern. Even CCTP, which allows sending data alongside a transfer, does not guarantee execution of an attached call on the destination chain. Separating receipt from deployment ensures the design works with any bridge, regardless of its callback capabilities. This separation also means the strategy never deposits into a vault that might be paused or in a degraded state.
The origin strategy on Ethereum needs to know how much the remote position is worth. But it can't query a contract on another chain. So the system uses a push model: the remote strategy periodically sends its total asset value back to the origin via a cross-chain message.
This is a design choice with significant implications. The remote side sends an absolute value, not a delta. Each message says "I'm currently worth X," and the origin overwrites its previous understanding entirely. This "overwrite, don't accumulate" model means there's no ordering dependency between messages. If message #3 arrives before message #2, no state is corrupted - the origin just has a slightly stale view, which the next message will correct. If a message is lost or never relayed, the system doesn't drift further and further from reality; the next successful message snaps it back to the current state.
Before accepting a message, the origin strategy validates that it came through the expected path: the correct bridge transmitter, the correct source domain, the correct remote counterpart, and with sufficient finality. This prevents spoofed messages from overwriting the accounting.
Once the origin's remote asset value is updated, a keeper triggers a report on the origin strategy itself. The vault compares the strategy's reported total value (local assets plus the remote value) against its last known value, computes profit or loss, and updates the share price.
When the vault needs to reclaim capital for a user to withdraw or rebalance, a keeper triggers a withdrawal on the remote strategy using processWithdrawal(). The remote strategy redeems shares from the local yield vault, bridges the freed assets back to the origin strategy on Ethereum, and immediately sends an accounting message so the origin strategy's view of remote assets reflects the reduced position.
The withdrawal is best-effort by design. If the underlying vault has withdrawal limits or liquidity constraints, the remote strategy bridges whatever it could actually free rather than reverting. This means a single withdrawal request might only partially fill. Multiple keeper calls may be needed to fully unwind a large position. The system favors partial progress over all-or-nothing failures. This design choice keeps the withdrawal pipeline moving even when the underlying yield source is constrained.
Both the origin and remote strategy factories use deterministic deployment schemes (CREATE on Ethereum, CREATE3 on remote chains) with salts derived from the same inputs: the vault address, the domain, and the counterpart address. This means each factory can compute the other's deployment address before either contract exists, so a new cross-chain strategy pair can be set up without any cross-chain communication during deployment.
Putting it all together, here is the complete lifecycle of capital deployed cross-chain:
The full round trip spans multiple transactions and bridge relays across two chains. This architecture unlocks yield opportunities across chains while keeping accounting bounded and self-correcting. Every remote report and withdrawal sends a fresh total asset value, the health check on the origin catches implausible jumps, and the remote asset value is overwritten rather than accumulated, so a single valid report resets the accounting to the current state of the world.
From the user perspective, all the complexity is abstracted away, so users can deposit and withdraw without leaving everyone's favorite chain: Ethereum mainnet.
yvUSD makes its trust model explicit and layers defenses at each boundary. Here's how each component is secured.
CCTP is the bridge used in the initial deployment, and this is a deliberate choice: since the yvUSD vault's underlying asset is USDC, it is already fully exposed to Circle and all of its risks. Using CCTP as the bridge introduces no new trust assumptions beyond what the underlying asset already carries. A third-party bridge like LayerZero would add an entirely new trust dependency on top of Circle's. The same principle applies to Katana's native bridge: a native bridge relies on the same trust assumptions as trusting the chain itself when deploying strategies there, so a native L2 bridge has significantly reduced risks compared to any third-party alternative. Each strategy is configured to only accept messages that the bridge considers finalized, mitigating reorg risks (for example, it is set here in BaseCCTP.sol to the CCTP specified value).
Keepers are authorized by governance via setKeeper() and have a well-scoped role with built-in safety constraints:
Keepers can't steal funds. The remote strategy's rescue() function explicitly blocks withdrawing the strategy asset or vault shares. Keepers can only push and pull funds between the strategy contract and its designated vault, or bridge back to the designated origin counterpart.
Keepers trigger reports. They call report() to send accounting updates to the origin. The isReady modifier (requiring block.timestamp > lastReport) prevents multiple reports in the same block.
Keepers coordinate withdrawals. processWithdrawal() is a keeper-only function that bridges capital back to Ethereum when needed.
If a bridge experiences a temporary outage mid-transfer, the origin's health check automatically detects the discrepancy when the next remote report arrives. Once the bridge resumes normal operation, the next successful report snaps accounting back to the correct state without any need for manual intervention.
Between keeper reports, the origin's view of its remote position is frozen. The overwrite model ensures this is always self-correcting: every new message replaces the old value entirely, and a health check on the origin rejects reports that show implausible profit or loss (beyond a configured threshold, e.g. 10%). The system bounds staleness and ensures recovery is automatic with each report cycle.
When the origin bridges USDC to a remote chain, it immediately records the increase in remote assets. If a remote report fires before the assets arrive, the remote side reports a total value that doesn't include the in-flight amount. The health check catches this: if the apparent discrepancy exceeds bounds, the origin's report to the vault is rejected, preventing any accounting inconsistency from affecting the share price. Once the assets arrive and the next report is sent, the accounting self-corrects automatically.
Shutdown blocks new capital from flowing outward while keeping the withdrawal path fully operational. Keepers can still pull funds from the remote vault, bridge them back, and make them available for user withdrawals on Ethereum. This asymmetry, blocking inflows while allowing outflows, ensures users can always unwind their positions.
The overwrite model eliminates the need for nonce or sequence validation on incoming messages. If a bridge delivers messages out of order, the health check gates whether the resulting value is plausible, and the next report cycle overwrites with fresh data. This is simpler and more robust than strict ordering, which would add complexity and introduce new failure modes like stuck queues.
The dual-contract architecture is bridge-agnostic. Each strategy pair uses whatever native bridge is considered appropriate for the destination chain. Circle's CCTP is a common choice for USDC transfers, Katana's native bridge can be used for its chain, and so on. The vault treats cross-chain capital the same as local capital regardless of which bridge carries it. Adding a new chain is a matter of deploying a new strategy pair with the right bridge integration, not modifying the vault. The cross-chain strategy code is available on GitHub.
When the vault allocates capital to a cross-chain strategy, the outbound capital flow has three distinct phases: send, receive, and deploy.
The origin strategy sends assets through the native bridge to its paired remote strategy on the destination chain. This process is inherently asynchronous because cross-chain bridges don't offer atomic execution or callbacks. The origin strategy increments its remote asset counter at the time of sending and trusts that the assets will arrive. For CCTP-based strategies, this means USDC is burned on Ethereum and minted on the destination after Circle's attestation service confirms finality. Other bridges have their own delivery mechanisms, but the pattern is the same.
Once received, the assets sit idle in the remote strategy contract until a keeper explicitly deploys them into the local yield source using the pushFunds() function. Why not auto-deploy funds on receipt? Because not all bridging protocols support a bridge-and-call pattern. Even CCTP, which allows sending data alongside a transfer, does not guarantee execution of an attached call on the destination chain. Separating receipt from deployment ensures the design works with any bridge, regardless of its callback capabilities. This separation also means the strategy never deposits into a vault that might be paused or in a degraded state.
The origin strategy on Ethereum needs to know how much the remote position is worth. But it can't query a contract on another chain. So the system uses a push model: the remote strategy periodically sends its total asset value back to the origin via a cross-chain message.
This is a design choice with significant implications. The remote side sends an absolute value, not a delta. Each message says "I'm currently worth X," and the origin overwrites its previous understanding entirely. This "overwrite, don't accumulate" model means there's no ordering dependency between messages. If message #3 arrives before message #2, no state is corrupted - the origin just has a slightly stale view, which the next message will correct. If a message is lost or never relayed, the system doesn't drift further and further from reality; the next successful message snaps it back to the current state.
Before accepting a message, the origin strategy validates that it came through the expected path: the correct bridge transmitter, the correct source domain, the correct remote counterpart, and with sufficient finality. This prevents spoofed messages from overwriting the accounting.
Once the origin's remote asset value is updated, a keeper triggers a report on the origin strategy itself. The vault compares the strategy's reported total value (local assets plus the remote value) against its last known value, computes profit or loss, and updates the share price.
When the vault needs to reclaim capital for a user to withdraw or rebalance, a keeper triggers a withdrawal on the remote strategy using processWithdrawal(). The remote strategy redeems shares from the local yield vault, bridges the freed assets back to the origin strategy on Ethereum, and immediately sends an accounting message so the origin strategy's view of remote assets reflects the reduced position.
The withdrawal is best-effort by design. If the underlying vault has withdrawal limits or liquidity constraints, the remote strategy bridges whatever it could actually free rather than reverting. This means a single withdrawal request might only partially fill. Multiple keeper calls may be needed to fully unwind a large position. The system favors partial progress over all-or-nothing failures. This design choice keeps the withdrawal pipeline moving even when the underlying yield source is constrained.
Both the origin and remote strategy factories use deterministic deployment schemes (CREATE on Ethereum, CREATE3 on remote chains) with salts derived from the same inputs: the vault address, the domain, and the counterpart address. This means each factory can compute the other's deployment address before either contract exists, so a new cross-chain strategy pair can be set up without any cross-chain communication during deployment.
Putting it all together, here is the complete lifecycle of capital deployed cross-chain:
The full round trip spans multiple transactions and bridge relays across two chains. This architecture unlocks yield opportunities across chains while keeping accounting bounded and self-correcting. Every remote report and withdrawal sends a fresh total asset value, the health check on the origin catches implausible jumps, and the remote asset value is overwritten rather than accumulated, so a single valid report resets the accounting to the current state of the world.
From the user perspective, all the complexity is abstracted away, so users can deposit and withdraw without leaving everyone's favorite chain: Ethereum mainnet.
yvUSD makes its trust model explicit and layers defenses at each boundary. Here's how each component is secured.
CCTP is the bridge used in the initial deployment, and this is a deliberate choice: since the yvUSD vault's underlying asset is USDC, it is already fully exposed to Circle and all of its risks. Using CCTP as the bridge introduces no new trust assumptions beyond what the underlying asset already carries. A third-party bridge like LayerZero would add an entirely new trust dependency on top of Circle's. The same principle applies to Katana's native bridge: a native bridge relies on the same trust assumptions as trusting the chain itself when deploying strategies there, so a native L2 bridge has significantly reduced risks compared to any third-party alternative. Each strategy is configured to only accept messages that the bridge considers finalized, mitigating reorg risks (for example, it is set here in BaseCCTP.sol to the CCTP specified value).
Keepers are authorized by governance via setKeeper() and have a well-scoped role with built-in safety constraints:
Keepers can't steal funds. The remote strategy's rescue() function explicitly blocks withdrawing the strategy asset or vault shares. Keepers can only push and pull funds between the strategy contract and its designated vault, or bridge back to the designated origin counterpart.
Keepers trigger reports. They call report() to send accounting updates to the origin. The isReady modifier (requiring block.timestamp > lastReport) prevents multiple reports in the same block.
Keepers coordinate withdrawals. processWithdrawal() is a keeper-only function that bridges capital back to Ethereum when needed.
If a bridge experiences a temporary outage mid-transfer, the origin's health check automatically detects the discrepancy when the next remote report arrives. Once the bridge resumes normal operation, the next successful report snaps accounting back to the correct state without any need for manual intervention.
Between keeper reports, the origin's view of its remote position is frozen. The overwrite model ensures this is always self-correcting: every new message replaces the old value entirely, and a health check on the origin rejects reports that show implausible profit or loss (beyond a configured threshold, e.g. 10%). The system bounds staleness and ensures recovery is automatic with each report cycle.
When the origin bridges USDC to a remote chain, it immediately records the increase in remote assets. If a remote report fires before the assets arrive, the remote side reports a total value that doesn't include the in-flight amount. The health check catches this: if the apparent discrepancy exceeds bounds, the origin's report to the vault is rejected, preventing any accounting inconsistency from affecting the share price. Once the assets arrive and the next report is sent, the accounting self-corrects automatically.
Shutdown blocks new capital from flowing outward while keeping the withdrawal path fully operational. Keepers can still pull funds from the remote vault, bridge them back, and make them available for user withdrawals on Ethereum. This asymmetry, blocking inflows while allowing outflows, ensures users can always unwind their positions.
The overwrite model eliminates the need for nonce or sequence validation on incoming messages. If a bridge delivers messages out of order, the health check gates whether the resulting value is plausible, and the next report cycle overwrites with fresh data. This is simpler and more robust than strict ordering, which would add complexity and introduce new failure modes like stuck queues.
Ross
Ross
>2.7K subscribers
>2.7K subscribers
No activity yet