How the layers connect

The system at a glance#

The app reads existing balances, obtains route data, and asks the connected wallet to sign transactions. SplitLayer does not operate a pooled stablecoin vault or mint a universal receipt token in this release.

Wallet balances → SplitLayer workspace
                         ↓
              Chain + token registry
                         ↓
                 LI.FI route quote
                         ↓
        Wallet approval → Source transaction
                         ↓
              Bridge / swap execution
                         ↓
       Destination settlement → Wallet balance

The registry defines the surface#

Every enabled network has a chain ID, RPC configuration, native currency, and explorer. Tokens are identified by chain ID and contract address, with the decimals required for exact amount conversion.

Adding an entry is a configuration change, not an interoperability guarantee. A useful chain integration also needs reliable reads, recognized token contracts, routing liquidity, execution support, and settlement monitoring.

Quotes turn an intent into a route#

A transfer request specifies the source chain, destination chain, source and destination tokens, input amount, recipient, and slippage tolerance. LI.FI returns a route estimate and transaction data when one is available.

The interface displays those terms before asking for signatures. It must discard obsolete quotes when any user-controlled transfer input changes. Amounts use integer base units during validation and transaction construction.

Inspired by the interchain#

Cosmos illustrates how separate chains can be approached as connected environments. IBC provides a protocol for authenticated communication between compatible blockchains. That is an architectural reference for the experience we want to create.

This release executes EVM routes through LI.FI. It does not implement IBC clients, Cosmos SDK modules, or its own cross-chain verification protocol. Its security properties are those of the chosen chains, token contracts, and route providers.

A future intent layer#

• Account layer: smart accounts and scoped permissions so a user can request a destination action.
• Solver layer: independent operators quote a fulfillment price and destination deadline.
• Settlement layer: explicitly defined proof, escrow, timeout, and dispute rules prevent double settlement.
• Risk layer: per-route limits, monitored liquidity, supported-asset policies, and incident controls.
• Operations layer: documented network admission, monitored provider health, and bounded risk parameters.

The asset layer and the spend layer#

The asset layer tracks ownership and the conditions under which an asset can produce liquidity. Stablecoins, transferable RWA tokens, and claims that require issuer eligibility must retain separate risk and redemption policies.

The proposed spend layer would accept a bounded budget in a supported settlement asset. A future solver could pre-fund the destination and settle later against collateral locked at origin. A wrapped representation could instead consume a preallocated destination budget. Both approaches require conservation of liabilities, finality handling, and recovery paths. Neither is deployed in the current wallet application.

State and persistence#

The wallet and blockchains remain the sources of truth for funds. The workspace stores interface preferences and account-bound transfer records in the browser. Restored activity requires a valid transaction hash and remains separate from current onchain balances. Clearing site data can remove that local history, but it does not change onchain balances or transactions.

The server acts as a narrow proxy for external data. There is no user database or server-held signing key. A future shared indexer should use PostgreSQL and retain transaction identifiers rather than wallet secrets.