Cross-chain Architecture

Blend’s current public cross-chain architecture is split into two layers:

• account-scoped APIs for discovery, reads, and deposit quotes
• server-built withdrawal execution payloads for Safe-side fund exits

​

Architectural split

​

Why the split exists

Deposit routing needs account context so Blend can determine the destination Safe and account-type configuration before generating a quote. Withdrawal execution needs the Safe-side position context, but the public SDK no longer builds action plans in the client. Instead, the server returns ordered calldata payloads that the integrator submits through its own relay or transaction orchestration layer.

​

Public interfaces

​

Account-scoped APIs

Use these namespaces for:

• account creation and lookup
• balance, position, return, and yield reads
• chain and token discovery (including EOA wallet holdings)
• deposit quote generation

Primary namespaces:

• client.safe
• client.balance
• client.positions
• client.returns
• client.yield
• client.deposit

​

Withdrawal execution

Use client.withdraw.getCalldata() when the user wants to exit funds from Blend. Each payload contains a steps array with ordered steps. Each step has a kind discriminator:

• liquidityReset - flush vault positions (submit as delegatecall)
• approve / withdraw / approveReset - vault exit transactions
• bridge - relay bridge when funds must move cross-chain

​

Key design details

client.deposit.getQuote() depends on accountId, not just the EOA address. That requirement scopes the quote to a specific Blend account and account type. client.withdraw.getCalldata() depends on accountId and destination chain. The server resolves the Safe, chooses source chains, and returns execution payloads. When isMaxWithdraw is true, the final withdrawn amount is not known before settlement, so bridge payloads may be omitted and fetched post-settlement by the integrator.

​

How Cross-Chain Routing Works

Blend deploys a Safe for each user on each chain where they have positions. When a user deposits, the server picks the optimal route based on cost, speed, and liquidity.

• Deposits route through bridge protocols. The server computes the best path and returns a quote payload for your relay layer to execute.
• Withdrawals can pull from multiple chains. The server figures out which chains to unwind from and returns ordered calldata.
• Rebalances may move capital between chains when the Risk Architect’s Basket targets positions on multiple networks.

See AcrossXChainAdapter in the contracts page for the on-chain component that handles cross-chain transfers.

​

Bridge Selection

Blend uses Across V3 for cross-chain transfers. Bridge selection happens server-side. Integrators receive opaque quote payloads and don’t need to interact with bridge contracts directly. Bridge fees are shown to users before they confirm. The fee depends on the route, token, and current bridge liquidity.

​

Failure Isolation

If a bridge goes down, deposit routes through that path fail gracefully. Money stays in the user’s wallet. Existing positions on any chain remain accessible directly through the user’s Safe. No funds are ever locked behind a bridge. Users maintain full control on every chain where they have positions. Because each user has their own Safe on each chain, there’s no pooled liquidity that could create a bank-run scenario. Your assets on Chain A are yours regardless of what happens to the bridge connecting Chain A to Chain B. See Scenario 4: Cross-Chain Bridge Failure for the full threat model.