Crossroads: A Smart Contract Layer for Chain-Abstracted Assets

• •

  Crossroads: We introduce Crossroads, a smart-contract layer for chain-abstracted assets. Crossroads can represent assets from any chain as ERC-20s on its unified smart-contract platform (Section 3).

• •

  Optimizations: We present key optimizations to Crossroads’ core design: per-user deposit addresses to enable broad wallet compatibility; optimistic deposits and withdrawals to reduce settlement latency; and parallelized withdrawals to increase throughput (Section 4).

• •

  Security: We prove system soundness by showing that at any point a user can unilaterally withdraw their full net balance to an externally owned account. We also propose modular security enhancements to strengthen the security model (Section 5).

• •

  Implementation: We implement a proof-of-concept of Crossroads and integrate it with Bitcoin, Ethereum, and Solana (Section 6), available at https://github.com/trate3/crossroads.

• •

  Applications: We identify a broad range of applications for Crossroads, from chain-agnostic wallets and cross-chain decentralized exchanges to cross-chain staking and lending, privacy payments, and universal stablecoins (Section 7).

We review related work in LABEL:sec:related-work and conclude in LABEL:sec:conclusion.

Blockchains cannot natively observe events outside their own ledger; oracles are systems that make external events available to smart contracts. A cross-chain oracle lets a contract on a destination chain verify that an event—for our purposes, the inclusion and finality of a transaction—occurred on a source chain.

Oracle constructions differ primarily in their trust model: committee-based oracles rely on an honest majority of external attesters [wormhole, axelar], light-client oracles verify the source chain’s consensus on the destination chain, possibly via zero knowledge proofs [xie2022zkbridge], and TEE-based oracles run prove transaction finality via their attestation capabilities. Crossroads requires a unidirectional oracle of finalized asset-chain transactions into its backend chain, and any such system can serve that purpose, each with its own security guarantees.

Most major blockchains have a single native asset which is required to pay for transaction fees and protect against unbridled resource consumption or denial of service. Many assets, however, do not require their own blockchain. These can be represented as tokens, and on EVM chains, they are smart contracts which adhere to the ERC-20 standard [erc20standard].

The popularity of ERC-20 tokens gave rise to decentralized finance (DeFi), a term encompassing financial services implemented on smart contracts, such as token-exchange, lending, and derivative-asset platforms.

Nearly all blockchains use public-key cryptography for account authentication and transaction signing. Usually, individual users directly control their private key material. Under key encumbrance, a policy, rather than an individual user, governs a key’s usage. The policy acts as a proxy through which authenticated parties may obtain signatures from the key, and it decides who is authorized to obtain signatures for particular messages. The parties themselves never learn the key.

Key encumbrance can be used to construct a shared blockchain account in which parties who do not trust each other individually control their own portions of the account balance [austgen2025liquefaction]. Furthermore, a single key encumbrance platform can sign transactions for separate blockchains. Practically, a TEE application or MPC protocol is used to generate keys securely and enforce encumbrance policies over them.

We require a $(t,N)$-threshold signature scheme comprising four algorithms $(\mathsf{KG},\mathsf{Sign},\mathsf{Verify},\mathsf{Combine})$:

• •

  $\mathsf{KG}(1^{\lambda},N,t)\to(\mathsf{pk},\mathsf{pk}_{c},\mathsf{sk}_{1},\ldots,\mathsf{sk}_{N})$: a probabilistic key generation algorithm that generates a $t$-out-of-$N$ shared key, outputting a public key $\mathsf{pk}$, a combiner public key $\mathsf{pk}_{c}$, and $N$ signing key shares $\mathsf{sk}_{1},\ldots,\mathsf{sk}_{N}$.

• •

  $\mathsf{Sign}(\mathsf{sk}_{i},m)\to\sigma^{\prime}_{i}$: a (possibly) probabilistic signing algorithm that takes a key share $\mathsf{sk}_{i}$ and a message $m$, and outputs a signature share $\sigma^{\prime}_{i}$.

• •

  $\mathsf{Verify}(\mathsf{pk},m,\sigma)\to b$: a deterministic verification algorithm that takes a public key $\mathsf{pk}$, a message $m$, and a signature $\sigma$, and outputs $b\in\{\mathsf{accept},\mathsf{reject}\}$.

• •

  $\mathsf{Combine}(\mathsf{pk}_{c},m,J,\{\sigma^{\prime}_{j}\}_{j\in J})\to\sigma$: a deterministic combiner algorithm that takes the combiner public key $\mathsf{pk}_{c}$, a message $m$, a subset $J\subseteq[N]$ with $|J|=t$, and signature shares $\{\sigma^{\prime}_{j}\}_{j\in J}$, and either outputs a combined signature $\sigma$ or outputs $\mathsf{blame}(J^{*})$ for some nonempty $J^{*}\subseteq J$, indicating that the shares $\{\sigma^{\prime}_{j}\}_{j\in J^{*}}$ are invalid.

We require the scheme to satisfy correctness, robustness, and existential unforgeability under chosen message attack (EUF-CMA) against an adversary corrupting up to $t-1$ signers, as defined in [boneh2023applied].

A trusted execution environment (TEE) is an isolated execution environment enabled by hardware design that protects applications running inside it from inspection or tampering by the host operating system, and in some designs from the machine owner as well. Programs executing within a TEE can produce outputs accompanied by a remote attestation: a cryptographic statement, signed by a hardware-rooted key, that binds the output to the specific program that produced it. Any external party can then verify, against the manufacturer’s attestation key, that the output was produced by an honest execution of the attested program without trusting the host machine.

Several commercial TEE implementations are widely deployed, including Intel SGX [intel_sgx], AMD SEV-SNP [amd_sev_snp], and AWS Nitro Enclaves [aws_nitro]. They differ in threat model, performance, and exposure to side-channel attacks. Recent work has demonstrated hardware-level vulnerabilities in deployed TEEs, including confidentiality leakage [wilke2024tdxdown, gast2025counterseveillance, yuan2025ciphersteal] and integrity attacks that enable forged attestations [RMPocalypse2025, chuang2026tee]. Crossroads’ core security guarantees, however, do not rest on TEEs and we employ them only as an optional defense-in-depth layer.

Crossroads must solve several problems to achieve our goal of general cross-chain support. It must (1) hold assets on heterogeneous asset chains, some without smart contracts; (2) support a representation of these assets on a programmable EVM backend blockchain; and (3) maintain consistency between balances on the asset chains and the backend blockchain. Additionally, it must not require special permission to integrate new chains. New integrations must therefore add little additional overhead to the platform, and Crossroads itself must not be opinionated about the validity of a particular chain.

The first issue is how to control assets on separate chains. Nearly every blockchain handles spending the same way: a transaction is valid only if it carries a signature verifying under the account’s key. So to custody a user’s funds, Crossroads holds it in an account on the asset chain, and spending from that account requires its signing key. Rather than entrust that key to any single party, Crossroads splits it into shares held by a signing committee that threshold-signs transactions or other messages.

We place all chain-specific logic in the backend blockchain, where each asset is represented as an ERC-20 asset contract, ultimately constructing a hub-and-spoke cross-chain topology. The signing committee responds to signing requests sent over the network but only signs transactions if an asset contract has authorized the requester to obtain a signature for the requested message. This simple policy keeps the signing committee’s logic small and separately auditable. This signing style is known as key encumbrance—when meeting the requirements of the asset contract, a requester may request transaction signatures from the committee and broadcast the signed transactions directly, as if the owner of the (encumbered) account.

Crossroads keeps the backend balances blockchain consistent with the asset chain with the help of per-chain transaction finalization oracles. Notably, these oracles only must report the state of the asset chain to the backend chain, so smart contracts are not required on asset chains. Crossroads instead relies on asset chains’ own double-spending protection and transaction validity rules.

We now expand on the five main components within Crossroads. The three drawn in blue in Figure 1 are specific to Crossroads, while the asset chains and backend blockchain are existing systems.

The high-level architecture of Crossroads and the associated data flow for users are depicted in Figure 1.

Each asset represented in Crossroads contains its own blockchain-specific deposit and withdrawal mechanisms. As Crossroads aims to be widely permissive in the blockchains it supports, we make few assumptions about blockchain architecture. In the following sections, we detail these assumptions and explain how deposits into and withdrawals from the Crossroads network operate.

Crossroads is compatible with nearly any blockchain, but there are several requirements for a particular integration to take full advantage of our design. All the chains that we have explored meet these requirements, though historically some chains (e.g., Bitcoin) previously have not.

For users to deposit assets on an asset chain into Crossroads, they must transfer them to a Crossroads-controlled encumbered account on the asset chain. Each deposit transaction into Crossroads must include a transaction binding to the account to which the deposit is credited.

After a deposit transaction has been finalized on its asset chain, its sender provides a proof of transaction inclusion to Crossroads. Crossroads validates the proof using the chain-specific oracle, ensures the transaction beneficiary is an account Crossroads controls, and ensures the deposit had not previously been processed. If the checks pass, Crossroads mints a wrapped representation of the deposited tokens to the Crossroads account bound to the deposit and marks the transaction as processed.

To withdraw the underlying asset from Crossroads, a user must first burn an amount of tokens needed to cover the withdrawal on the backend blockchain; this establishes the maximum asset-chain transaction cost, which includes both the value being transferred and the transaction fee. The user may then obtain signed transactions from the signing committee spending up to this maximum. Since all withdrawals originate from the same encumbered address, included transactions must be attributable back to the spender. This is achieved by requiring the chain-specific transaction binding in withdrawal transactions, which embeds the spender’s backend account into the signed transaction.

It is possible to use, rather than transaction bindings, simply a commitment (on the backend blockchain) from the spender to pay for a particular transaction hash. However, we propose transaction bindings because they do not require the spender to make additional transactions (fresh commitments) if a different party’s withdrawal is included instead. In this way, transaction bindings are more resistant to frontrunning and denial of service attacks, since the time when a user requests a signature gets revealed only to the signing committee rather than to the public backend chain.

The spender may choose the transaction fee and hold onto signed transactions indefinitely. Crossroads does not guarantee that a particular transaction it has signed will be included on an asset chain, but it can guarantee that the transactions it signs are valid transactions. Multiple spenders may, in fact, compete to broadcast their transactions from the same asset chain account. After a transaction does land on an asset blockchain and finalizes, a transaction inclusion proof must be provided to Crossroads for accounting purposes. Anyone may submit the proof to receive a small reward. The spender must reserve some tokens in advance to cover this fee.

We anticipate that Crossroads depositors will not always control their spending key to the extent that they can modify the fields needed to embed a binding in their deposit transaction. Some Crossroads deposits will originate from a centralized exchange or from a wallet which only permits vanilla transfers without embedded transaction data.

We address this with custom deposit addresses, each bound to a single Crossroads account to which deposits are credited (the deposit beneficiary). These require two asset-chain transactions to complete a deposit: one sending assets to the custom deposit address, and another consolidating those funds into the main encumbered address.

To do so, we employ a novel auction mechanism selling a sub-balance of the custom deposit address representing the new deposit in exchange for equivalent Crossroads tokens. The auction’s reserve price is equal to the deposited amount minus the cost the deposit beneficiary would have paid in transaction fees to send the consolidation transaction herself.

This auction is enabled by key encumbrance. The auction winner gains encumbered control over the custom deposit addresses it bid on, allowing it to consolidate them at any later time. Bidders are incentivized to participate: the winner can delay broadcasting the consolidation transaction until transaction fees fall, profiting from the difference. In effect, the auction winner assumes the role of performing the same type of asset consolidation optimization that centralized exchanges perform [coinbasebatching].

We can improve deposit times by transferring the risk of double spending from Crossroads to a third party willing to take it for a fee. A small extension to the asset contract lets a depositor reassign an unfinalized deposit, enabling a separate fast-deposit contract to atomically swap a pending deposit claim for already-issued Crossroads tokens owned by the third party. Suppose, for example, that Alice deposits 10 ETH to Crossroads but does not want to wait for finality (approximately 15 minutes). Bob already has Crossroads ETH tokens and is willing to accept Alice’s deposit in exchange for his tokens, for a small fee, after it gets one block confirmation (under 12 seconds). Alice atomically swaps her deposit claim for 9.999 Crossroads ETH tokens from Bob. Once the deposit finalizes, Bob submits the deposit proof and is issued 10 Crossroads ETH tokens for a profit of 0.001 ETH. This mechanism mirrors the fast fills of intent-based bridges such as Across [across], where relayers provide quick access to bridged funds for a fee; in Crossroads, however, the third party is repaid through the standard deposit flow.

On most account-based blockchains, deposits to Crossroads can happen in parallel, since each deposit transaction is independent of all other deposits and all withdrawals. In our Section 3 construction, however, withdrawals from the same chain all originate from the same encumbered address, so the system can only execute one withdrawal at a time per chain, after which it must wait for finalization and inclusion proof before signing the next.

We address this bottleneck with an intent-based withdrawal contract on the backend chain. To withdraw, a user locks the desired amount plus a small reward in Crossroads tokens in the contract. Any party, called a filler, may then send the equivalent native asset to the user’s destination address on the target chain from their own address. The filler then submits an inclusion proof to claim the locked tokens. If no filler claims the intent within a timeout, the user reclaims the locked tokens and falls back to the standard withdrawal path. As the asset transfer happens from the filler’s own address, it does not conflict with the encumbered account’s transactions, and many withdrawals can be served in parallel.

Without coordination, however, two fillers may race to fulfill the same request, with only one being reimbursed. To prevent this, fillers commit to a request by staking collateral on the backend chain; the contract accepts at most one commitment per intent, so any filler that commits is guaranteed to be the sole eligible claimant. If the committed filler fails to complete the transfer within the timeout, the stake is forfeited to the user as compensation for the delay.

A second route to higher throughput is to use multi-payment contracts on asset chains that support them, executing many transfers in a single transaction. Users wishing to withdraw in the next epoch lock the corresponding tokens and specify their destination addresses; the signing committee then signs a single transaction transferring all locked funds since the last epoch.

Finally, withdrawal throughput can also be increased by having Crossroads control several encumbered addresses per chain rather than one. Since the per-chain bottleneck in Section 3 stems from every withdrawal originating from a single address, distributing the chain’s liquidity across multiple encumbered addresses lets the signing committee sign withdrawals from each in parallel, one per address per epoch. The trade-off is that liquidity becomes fragmented across addresses, so withdrawals must be routed to an address holding sufficient funds, and occasional rebalancing is needed when balances drift.

Let $\mathcal{U}$ be the set of registered accounts to the Crossroads system, and $\mathcal{B}$ the set of asset blockchains which fulfill the requirements of 3.2. We model the system’s evolution as an ordered sequence of operations, where each operation is either a call to the Crossroads asset contract $\textsf{crsrds}(\mathcal{O},\mathcal{T}_{\mathcal{B}})$, a message in the signing-committee protocol $\Pi^{\mathsf{TSS}}_{\mathsf{SC}}$, or the broadcast of a transaction to an asset chain. A transcript $\vec{\sigma}$ is a finite, ordered sequence of operations. We say an operation is $\mathsf{acct}$-issuable if it can be performed using only $\mathsf{acct}$’s backend signing key; in particular, it requires no cooperation from any other backend account, oracle, or external party.

We assume each asset chain $\mathsf{chain}$ defines a validity predicate $\mathsf{Valid}_{\mathsf{chain}}(\mathsf{tx},\mathsf{st})$ on transactions and chain states, capturing the chain’s inclusion checks: well-formedness, signature verification under the sender’s key, epoch validity (or non-conflict with prior spends), and assurance the sender’s native balance covers $\mathsf{value}(\mathsf{tx})+\mathsf{fee}(\mathsf{tx})$.

Fix an account $\mathsf{acct}\in\mathcal{U}$, a blockchain $\mathsf{chain}\in\mathcal{B}$, and a transcript $\vec{\sigma}$, and consider the operations of $\vec{\sigma}$ that call $\mathsf{chain}$’s asset contract $\textsf{crsrds}(\mathcal{O},\mathcal{T}_{\mathcal{B}})$ and execute successfully, i.e., that pass the contract’s assertions and so update balances. Among these, let $\mathsf{Dep}(\mathsf{acct})$ be the Deposit calls credited to $\mathsf{acct}$ and $\mathsf{With}(\mathsf{acct})$ the ConfirmWithdrawal calls attributed to $\mathsf{acct}$ via the transaction binding, and let $\mathsf{Rcv}(\mathsf{acct})$ and $\mathsf{Snd}(\mathsf{acct})$ be the Transfer calls in which $\mathsf{acct}$ is the recipient and the sender, respectively. For each such operation, $\mathsf{amt}$ denotes the amount deposited, withdrawn, or transferred; for $\mathsf{tx}\in\mathsf{With}(\mathsf{acct})$, $\mathsf{fee}$ additionally denotes the on-chain withdrawal fee reported by $\mathcal{O}$. We define the net balance of $\mathsf{acct}$ for $\mathsf{chain}$ with respect to $\vec{\sigma}$ as:

Intuitively, soundness captures the end-to-end guarantee that no sequence of valid operations can deprive a user of their assets: whatever value a user has deposited into Crossroads, adjusted for internal transfers and prior withdrawals, remains recoverable.

Soundness thus guarantees a valid broadcast, not inclusion. All withdrawals spend from the same encumbered address, so signed transactions for the same epoch are mutually exclusive, and a competing withdrawal may be included first. Losing such a race costs latency, never funds. By single-choice inclusion (Section 3.2), the superseded transaction becomes permanently invalid, while the user’s pending-withdrawal balance is untouched, so the user may request a fresh signature for the next epoch and rebroadcast.

Moreover, soundness is a property of the Crossroads protocol, not of the applications built on it. It guarantees that whoever holds a net balance can withdraw it, not that a faulty application won’t take that balance from you. If a flawed AMM or lending contract drains your tokens, soundness still holds (the new holder can withdraw), but your assets are gone. As on any smart-contract platform, application-layer security is orthogonal to soundness of the underlying system.

We now prove that the Crossroads functionalities satisfy this property under the threat model presented in 5.1.

The proof is deferred to Appendix LABEL:appdx:proofs. The assumption on the bound of adversarial resources limits the number of withdrawals the adversary can finalize to compete with an honest user’s, and hence the number of times it can deny any single withdrawal; we discuss denial-of-service attacks, along with mitigations, in Appendix LABEL:subsec:dos.

Committee-based protocols that custody large volumes of funds are frequent attack targets [krause20251, chainalysis2026kelpdao, zhang2024cross], so we now present several mechanisms that strengthen the security guarantees of Crossroads beyond the threshold assumption.

We instantiate the signing committee using the threshold-signatures library by NEAR [near_threshold_signatures_2026]. Committee members participate in threshold signing under MPC to compute signatures—specifically, threshold ECDSA using a two-phase signing protocol [damgrard20fastthreshold] and FROST-Ed25519 [komlo2020frost]. ECDSA and Ed25519 cover the majority of signing algorithms used in current blockchains.

Ethereum’s account-based address system is well suited for Crossroads; deposits into an encumbered Ethereum account never not impose additional costs on withdrawals.

Bitcoin follows the unspent transaction outputs (UTXO) model: transactions consist of at least one input (a previous unspent output) and at least one output. This affects our deposit model. If Crossroads were to accept payments from depositors as a typical Bitcoin wallet does, it would accumulate a set of spendable UTXOs. Bitcoin transaction fees are charged by the size of a transaction, so spending a large number of small UTXOs, each of which must be referenced in the transaction, adversely affects withdrawal costs.

We remedy this by requiring depositors to perform the UTXO consolidation (similar to the custom address deposits of Section 4.1). Rather than collecting new UTXOs, the Bitcoin asset contract instead maintains a single UTXO per encumbered account. The asset contract permits anyone to request transaction signatures with the current encumbered UTXO as an input—but only if the requester combines it with another input resulting in a net deposit to the encumbered account. When inclusion is proven for a Bitcoin transaction spending the encumbered account’s UTXO, the asset contract updates the current UTXO to the newly created one and increments the epoch number.

Like Ethereum, Solana is an account-based blockchain and accepts deposits into a Crossroads encumbered account without requiring interaction with the signing committee. Solana transactions are composed of a series of instructions to programs (equivalent to smart contracts).

We evaluated our implementation to assess the feasibility of running our system.

Although we used a free local Ethereum devnet as the backend blockchain for most of our testing, in practice Crossroads would be deployed on a public EVM blockchain. In Table I we report the cost of using Crossroads to deposit, transfer, and withdraw each of the three assets we integrated on five compatible backend blockchains. Unsurprisingly, L2 blockchains—Optimism, Base, and Arbitrum—offer better fee rates than Ethereum, as does Oasis Sapphire, a TEE-based blockchain used for privacy applications described in Section 7. Moreover, as shown in LABEL:appdx:signing-latency, Crossroads deposits and withdrawals cost little more than ordinary native transfers on each asset chain.