An experience, backed by settlement
The objective is to let a user hold assets in a balance layer and request a destination action through a spend layer. A contract on the destination could receive local liquidity immediately while the protocol handles the cross-chain settlement afterward.
Immediate execution requires somebody to have already placed usable funds on the destination. A wrapped token alone does not make remote collateral synchronously available. The latency can be financed or moved behind the interface; it cannot be assumed away.
One collateral pool. One global obligation.
A reservation that is already represented by an outstanding wrapped token must not be added a second time. An accounting transition replaces one obligation with another atomically. Fees and safety reserves reduce available capacity; they do not count as backing.
If 1,000 USDC is escrowed, a system could allocate 600 USDC of capacity to Base and 400 to Arbitrum. It cannot give each network independently spendable rights to 1,000 USDC. A user interface may show the same aggregate balance everywhere, but spending consumes a shared obligation or a bounded local budget.
For each collateral asset, in the same base units:
sum(outstanding wrapped liabilities across chains)
+ sum(unrepresented reserved spend obligations)
≤ finalized eligible escrow collateral
Available budget = eligible collateral − existing obligationsTwo possible execution models
A hybrid could combine small standing budgets with on-demand solver quotes. The protocol must specify which model funds a transfer and which party bears timing and failure risk. The current LI.FI route integration is not evidence that a SplitLayer solver or wrapped-token protocol exists.
| Model | How execution works | Tradeoff |
|---|---|---|
| Preallocated budgets | Finalized collateral authorizes capped mint or spend rights on each destination | Fast within local capacity; reallocation requires settlement and revocation |
| Pre-funded solvers | A solver pays the destination from its inventory, then claims origin collateral on proof | Capital-efficient user flow depends on solver liquidity, pricing, and verifiable claims |
An intent can be settled only once
- Bind every intent to the source and destination chain IDs, contract domains, sender, recipient, asset, maximum debit, minimum output, and deadline.
- Use a unique nonce or intent ID with replay protection in every execution and settlement domain.
- Reserve the input capacity before admitting execution and prevent concurrent obligations from exceeding it.
- Require proof of the intended destination effect before releasing the solver's origin payment.
- Make terminal transitions mutually exclusive: settled, refunded, or expired-and-released; never several at once.
- Domain-separate signatures so a quote or permission cannot be replayed on another chain, deployment, or protocol version.
Timeouts do not prove non-execution
A destination transaction may succeed while its proof is delayed. Releasing the source reservation merely because a timer expired could then create two claims against the same funds. A safe timeout path needs a protocol-defined proof of non-execution, an invalidated destination right, or a dispute window that resolves the ambiguity.
Chain reorganizations and sequencer downtime affect when an execution can be considered final. The specification must define finality per chain, quote expiry, proof deadlines, solver replacement, and who pays for recovery. Local UI timers are not settlement proofs.
Native redemption is part of the product
A wrapped claim must have an explicit way to recover the underlying native asset. The design must state where redemption occurs, which obligations are burned or canceled, which finality is required, how fees are paid, and what happens during a network pause.
A destination app may not accept the wrapper. In that case, the spend layer needs local native-token liquidity and a conversion path before invoking the app. Token compatibility and available liquidity are essential dependencies.
RWA value is not stablecoin collateral
The stablecoin-only invariant cannot treat a displayed RWA market value as cash backing. Tokenized real-world assets have price changes, issuer and transfer constraints, market hours, redemption delays, and potential liquidation gaps.
An RWA-backed version needs asset-specific eligibility, conservative valuation, haircuts, concentration limits, stale-price protection, liquidation mechanics, and funded liquidity. A $1,000 portfolio estimate cannot authorize $1,000 of guaranteed instant spending. The first product keeps RWA portfolio reads separate from live USDC transfer capacity.