Liquidity Bridging
Liquidity bridging moves the strategy's capital between the Machine on the Hub Chain and its Calibers on the Spoke Chains. It is how an Operator deploys fresh deposits to a spoke, and how funds are brought back to Hub to settle redemptions.
Adapters abstract the bridges
Transfers ride on external bridge protocols. The protocol ships a dedicated bridge adapter for each supported bridge (Across, CCTP, and LayerZero). On the Hub side the adapters are managed by the Machine, and on a spoke by the Caliber Mailbox. Each adapter exposes a standardized interface, so the rest of the system doesn't need to know which bridge is in use. Which routes (chain + token + bridge) are allowed is governed configuration.
A deliberate four-step transfer
Bridging is intentionally not a single fire-and-forget call. It is a four-step handshake, executed by the Operator, and it works the same in both directions (Hub → Spoke and Spoke → Hub):
- Schedule the outgoing transfer on the sender side, which produces a unique message hash committing to the transfer's details.
- Authorize the incoming transfer on the recipient side by pre-registering that message hash. The recipient will only accept a transfer it has explicitly expected.
- Send the funds through the bridge protocol.
- Claim on the recipient side to finalize delivery into the Caliber or Machine.
Requiring the recipient to pre-authorize the exact message hash means it only ever accepts transfers it has explicitly expected. An incoming transfer that was not authorized in advance is rejected.
Loss limits
Each transfer carries a minimum output amount, and bridging is bounded by a governance-set maximum bridge loss (in basis points): a scheduled transfer whose expected output falls outside the allowed band is rejected. This caps the value that bridge fees or slippage can consume, and the per-bridge outgoing-transfer-enabled switch lets governance pause a route entirely.
In-flight value is never lost
Between send and claim, capital is in transit and belongs to neither side's balance. The protocol tracks these pending transfers and counts them in AUM, so the share price stays correct even while funds are crossing chains. See Cross-Chain Accounting.
For Spoke → Hub transfers there is an additional ordering rule: the spoke's accounting snapshot recording the outbound transfer must reach the Machine before the transfer can be claimed on the Hub. The Machine rejects the claim until the reported outbound amount covers it, so the value leaves the spoke side of the accounting view before it is added on the hub side, and is never counted on both at once.
In Recovery Mode
During Recovery Mode, bridging is restricted to the Spoke → Hub direction. The Hub can no longer send transfers out to spokes, and spokes can no longer authorize incoming transfers from the Hub, so an emergency can only pull capital to Hub, never push it out to a spoke.