Chapter 6: Cross-Chain

The bridge facade makes cross-chain fund movement a backend concern — invisible to the user, swappable by provider, and integrated with the existing financial document, indexing, and routing infrastructure.

Design Principles

• Token-agnostic. Handles USDC, USDT, DAI, or any token the bridge provider supports.
• Facade pattern. Same as fiat ramp. Providers are abstracted. Convex is the source of truth.
• Separate from off-ramp. Bridge and fiat ramp are parallel but separate systems with different failure modes (stuck funds on a bridge vs. bank processing delays).
• Pull-based invariant preserved. All funds flow through the smart account (employees) or Safe (orgs).

Three Flows

Flow 1: Outbound — Org Pays Recipient on Another Chain

The org initiates a payment from the Safe on Base to an address on another chain. The backend gets a bridge quote, the org admin confirms, the Safe executes a transaction to the bridge contract on Base, and the bridge provider delivers tokens on the destination chain.

Flow 2: Outbound — Employee Routes Claimed Funds to Another Chain

An employee’s salary splitting configuration includes a destination wallet on another chain (e.g., 40% to a Solana wallet). After claim, auto-routing triggers the bridge facade to send the configured portion through the bridge provider. Uses session keys, same pattern as off-ramp routing.

Flow 3: Inbound — Org Receives Funds on Base from Another Chain

An org receives stablecoins on a non-EVM chain (e.g., USDT on Tron) and wants those funds in their Safe on Base. This flow is partially TBD. See Inbound Bridging from Non-EVM Chains.

Provider Evaluation

For a payroll platform moving salaries and treasury funds, security dominates. Reliability and predictability matter more than finding the cheapest route.

deBridge (Recommended Launch Provider)

An intent-based cross-chain protocol. Instead of locking tokens in liquidity pools (the attack vector behind $2.8B+ in bridge exploits), deBridge uses competing “solvers” who fulfill cross-chain orders. No pooled liquidity means no honeypot to drain.

Criterion	Assessment
Security	Zero exploits since 2022 launch. 30+ audits. $200K bug bounty unclaimed. 0-TVL model eliminates the largest class of bridge attacks.
Chain coverage	26+ chains including Base, Ethereum, Arbitrum, Optimism, Polygon, Solana, Tron
Token support	Arbitrary token pairs. USDC on Base to USDT on Tron in one operation. Native tokens delivered, not wrapped.
Developer experience	REST API and TypeScript SDK. Server-side integration. Quote/execute/status endpoints.
Fees	Flat ~0.001 ETH on source chain + ~4 basis points on input amount. 1,000 USDT Base-to-Tron costs ~$1-3 all-in.
Speed	10-45 seconds for most stablecoin corridors.

Hyperbridge (Phase 2 Addition for EVM Corridors)

A Polkadot parachain built as an interoperability coprocessor by Polytope Labs. Uses ZK-enhanced light clients instead of multisig committees. The strongest security model of any bridge evaluated — no new trust assumptions beyond the chains themselves.

• Chain coverage: 14+ networks, all EVM. Does not yet support Solana or Tron.
• Assessment: Best security for EVM-to-EVM corridors. Cannot be the sole provider (no non-EVM support). Natural ecosystem alignment with Capxul (Lagos origin).

LI.FI (Phase 3 Addition for Rate Optimization)

A bridge and DEX aggregation protocol. Aggregates 14+ bridge protocols to find optimal routes. Not a bridge itself — a routing layer over bridges.

• Chain coverage: 60+ chains including Solana. No Tron.
• Assessment: Value is rate optimization at scale. Not critical at launch volume. Recommended when transaction volume on EVM corridors justifies cost optimization.

Circle CCTP V2

Circle’s burn-and-mint protocol for USDC transfers. Zero bridge risk, zero slippage, zero bridge fee on Standard Transfer. Not integrated directly — deBridge and LI.FI use CCTP under the hood for USDC routes.

Provider Selection

Phase	Provider	Coverage
Phase 1 (launch)	deBridge	All chain pairs (EVM, Solana, Tron)
Phase 2	+ Hyperbridge	EVM-to-EVM corridors (superior security)
Phase 3	+ LI.FI	Rate optimization on high-volume EVM corridors

The bridgeTransactions Table

Separate from financialDocuments and fiatTransactions. Same patterns: provider facade, lifecycle state machine, polling-as-fallback, Convex as source of truth.

Schema

Transaction ID, direction (outbound/inbound), status, org ID, initiator ID/type, source chain/address/token/amount, destination chain/address/token/amount (estimated and actual), provider ID, provider transaction ID, quote data (JSON), source tx hash, destination tx hash, bridge fee, gas cost, timestamps, error message, related financial document ID.

Outbound Lifecycle

quote_requested -> quoted -> executing -> source_confirmed
    -> bridging -> destination_confirmed -> complete

Failure states: quote_failed, expired, tx_failed, source_failed, bridge_failed -> refunding -> refunded, delivery_failed.

Key moment: source_confirmed is the point of no return. Tokens have left the smart account or Safe and are in the bridge contract. From here, the bridge provider is responsible for delivery.

Inbound Lifecycle

detected -> bridging -> destination_confirmed -> complete

Simpler because Capxul is the recipient.

Bridge Provider Interface

Methods

• getQuote(request) — source/destination chain/token/amount/address. Returns estimated destination amount, fee breakdown, delivery time, quote expiry, and provider quote ID.
• getTransactionData(quoteId) — returns contract address, calldata, value, and any approval transactions needed. The smart account or Safe executes this.
• getTransactionStatus(providerTxId) — maps to lifecycle states.
• getSupportedChains() / getSupportedTokens(source, dest) — capability discovery.

Routing Logic

At launch: deBridge for everything. As providers are added:

1. Filter by chain pair support (Tron: only deBridge qualifies)
2. Apply preference (Hyperbridge for EVM-to-EVM, deBridge for non-EVM)
3. If multiple qualify and no preference: quote from all, select by configurable priority (security tier, then fee, then speed)

Routing runs in Convex. The user sees a single quote.

Session Key Extension

The bridge facade extends the same session key model used for off-ramp.

Scope

The session key authorizes the smart account to:

1. Approve a token to a bridge provider’s contract (ERC20 approve)
2. Call the bridge contract with the transaction data from getTransactionData

Restricted to: a whitelist of bridge provider contract addresses, a maximum amount per transaction, and tokens the employee has explicitly enabled.

When a new bridge provider is added, its contract address is added to the whitelist — a backend configuration change, not a session key re-grant.

Org Safe Bridge Authorization

Org-initiated bridge payments use the Safe module system, not session keys. Same spending limits and approval flows as other Safe payments.

Destination Address Registry

Recipient-Provided Addresses

Recipients can add cross-chain wallet addresses to their Capxul profile:

• Chain ID, address (format-validated: EVM hex, Solana base58, Tron base58check), label, preferred token

Address format validation at input time prevents typos in cross-chain transfers (which are unrecoverable).

Routing Rules Extension

Auto-routing rules extend to include chain_wallet destinations alongside bank_transfer, mobile_money, and retain:

An employee’s rules might look like: 50% to GTBank (off-ramp via fiat facade), 30% to Solana wallet (bridge via bridge facade), 20% stays in smart account on Base. The claim event triggers both flows in parallel.

How the Indexer Tracks Bridge Completions

Source Chain Detection

The source transaction (sending tokens to the bridge contract on Base) is a normal ERC20 Transfer event. The existing indexer detects this and updates treasury/smart account balance. No modification needed.

Destination Chain Detection

The destination completion cannot be detected by the Base-only indexer. Two approaches:

Approach A (selected): Provider status polling. A Convex scheduled function runs every 15 seconds scanning bridge transactions in source_confirmed or bridging status. For each, it calls getTransactionStatus on the provider. This avoids running indexers on every destination chain.

Approach B (future): Multi-chain indexer. When volume on specific corridors justifies it, extend the indexer to watch destination chains. Faster detection (2 seconds vs. 15 seconds) and independent verification.

Inbound Detection

For inbound bridge transactions, the existing indexer handles detection natively. A Transfer event to the Safe on Base triggers the indexer.

Inbound Bridging from Non-EVM Chains

The Problem

On EVM chains, the Safe has the same address everywhere. Zodiac modules allow cross-chain governance. On non-EVM chains (Tron, Solana), there is no Safe. The address format is different. Zodiac does not support non-EVM chains.

Yet the use case is real: organizations receive USDT on Tron from clients and need those funds in their Safe on Base.

Options

Option A: Custom non-EVM contract controlled via cross-chain messaging. Deploy a contract on the non-EVM chain that accepts transfers and releases funds only when instructed by a cross-chain message from the Safe on Base. Most decentralized. Requires custom development per non-EVM chain.

Option B: Capxul-managed wallet. Capxul holds keys for a Tron/Solana wallet per org. Governance enforced at the Convex application layer. Simpler but introduces custodial risk.

Option C: Ephemeral deposit addresses via bridge provider. Provider generates destination-specific deposit addresses. External sender sends tokens to a provider address, which automatically bridges to the Safe on Base. No custodial risk but breaks the “persistent receiving address” expectation.

Recommendation

This decision is deferred. It has security, compliance, and engineering implications beyond the bridge facade. The provider interface is defined such that any option can be implemented behind the adapter.

Next steps: Research deBridge/Hyperbridge cross-chain messaging for Option A. Evaluate compliance implications of Option B. Investigate provider deposit address capabilities for Option C. Make the decision in the context of the broader governance model.

Refund Handling

If a bridge transaction fails after funds left the source:

• deBridge: If a solver does not fulfill within the timeout, the user triggers an on-chain refund via the SDK. Returns original tokens to the source address.
• Hyperbridge: Permissionless on-chain refunds. Anyone can trigger via proof if an intent is not filled.

The backend monitors for refund eligibility and triggers automatically. The bridge transaction transitions to refunding -> refunded when tokens arrive back (detected by the indexer as a normal Transfer event).

Stuck Transaction Detection

A Convex scheduled function runs every 5 minutes scanning for bridge transactions in intermediate states longer than expected:

• source_confirmed for more than 10 minutes
• bridging for more than 30 minutes
• refunding for more than 2 hours

Stuck transactions trigger alerts and detailed status fetches from the provider.

Cost Projections

Per-Transaction (Provider Costs)

deBridge: Flat ~$0.10 on Base + ~4 basis points. 1,000 USDT Base-to-Tron costs ~$1-3. 10,000 USDC Base-to-Solana costs ~$8-15.

Infrastructure Costs

Status polling (15-second Convex function), stuck detection (5-minute function), provider API calls (free). No additional services at launch. Dominant cost is the provider’s per-transaction fee. At 100 bridge transactions per month, provider costs are under $300/month.