1 Introduction↩︎

Cross-chain bridges are the main path today towards blockchain interoperability. Current bridges, though, generally only support a handful of high-liquidity chains or chains within a single family (EVM, Cosmos, Solana, Bitcoin, etc.). Swaps between two cryptocurrencies often have to traverse several cross-chain exchanges, e.g., an exchange of StarkNet ETH to Solana SOL, might involve three or more bridge operations and several intermediary token swaps [1].

The challenge is that a single bridge connects exactly two chains. Full pairwise connectivity is impractical, as supporting \(N\) chains would require \(N^2\) bridges, each separately deployed and operated. Practical designs today therefore employ a sparse graph of bridges between high-liquidity chains, where transfers between unconnected chains must hop through intermediaries and pay fees at each step.

A hub topology avoids such hopping: \(N\) connections make every pair of chains reachable through the hub, and \(N\) bridges are easier to audit than \(N^2\). Existing hub-and-spoke systems, however, fall short of this potential in three ways: integrating a new chain is a permissioned decision of the hub’s operators or governance; the hub’s functionality is fixed at the protocol level, typically transfers or swaps, rather than open to third-party applications; and integration generally requires verification logic on the connected chain itself, leaving chains without smart contracts, such as Bitcoin, behind.

Crossroads. In this work, we present Crossroads, a smart contract layer for chain-abstracted assets. Crossroads adopts a hub-and-spoke topology but, unlike existing hubs, supports permissionless integration of any chain and enables a programmable layer that lets arbitrary smart contracts operate on the assets within the hub. Crossroads works with nearly any blockchain, even non-EVM chains and chains without smart contracts. It abstracts all blockchain assets as ERC-20 tokens existing on a single EVM-based chain (the backend chain). On this backend chain, the exchange and transfer of cross-chain assets operate as ordinary on-chain transactions.

To interact with Crossroads-enabled cross-chain applications, users deposit assets into a committee controlled address on the asset’s native chain; a per-chain oracle then attests on the backend chain that the deposit transaction is finalized, after which the corresponding ERC-20 tokens are minted on the backend chain. The committee holds the keys to these addresses under key encumbrance [2]: keys are generated and stored under a threshold signature scheme, so no party ever learns them, and signatures are produced only as authorized by the asset contracts on the backend chain.

Concretely, to withdraw an asset from the Crossroads system, a user first burns its corresponding ERC-20 tokens on the backend chain. The committee verifies the burn against the asset contract and signs a transaction transferring the corresponding native assets to an address chosen by the user, with the user setting the fee and deciding when to broadcast.

Compared to existing cross-chain interoperability platforms, this design gives Crossroads three novel properties. First, cross-chain functionality is programmable: any smart contract deployed on the backend chain (an AMM, a lending market, a stablecoin issuer) operates on assets from every integrated chain. Because each ERC-20 token carries the right to withdraw its underlying asset, transferring tokens also transfers that right with them; a single backend transaction, such as an AMM swap, thus settles an exchange of native assets atomically. Second, integration is permissionless: integrating a chain amounts to deploying its ERC-20 asset contract on the backend chain and an oracle relaying the chain’s finalized transactions, so anyone can add a chain or asset without the approval of a developer or system operator. Third, the requirements on integrated chains are minimal: because Crossroads needs only a unidirectional oracle from the asset chain to the backend chain, any chain with eventual, verifiable finality can be integrated, with no contracts, deployed logic, or protocol changes on the chain itself. This is what brings chains without smart contract support, such as Bitcoin and XRPL, within reach.

Crossroads’ security rests on the standard trust assumption of threshold cryptosystems: an adversary corrupts fewer signing committee members than the signing threshold. Under this assumption, we prove that Crossroads is sound: any user can redeem their Crossroads-issued ERC-20 tokens for the underlying asset and transfer them to an externally owned account (EOA) on the asset’s native chain. Soundness implies that an adversary in our threat model cannot steal or lose user funds. In view of committee compromises in practice [3]–[5], however, we present modular security enhancements that provide defense in depth should our corruption assumption fail. These include use of secure hardware (TEEs), security councils with freeze authority, and accountable threshold signatures that identify misbehaving signers.

Crossroads’ design ideas have already seen industry adoption. Oasis Sapphire, a TEE-based blockchain, has integrated many of Crossroads’ components into its multi-chain programmable wallet SDK, Privana [6].

Applications. Because Crossroads represents assets from arbitrary chains as ERC-20 tokens on a single programmable backend, any ERC-20 compatible smart contract on the backend automatically becomes a cross-chain application. This can turn systems which otherwise would require bridging infrastructure into ordinary single-chain smart contracts.

One direct application of Crossroads is a chain-agnostic wallet, a single key pair that controls assets across every integrated chain, with the user’s full portfolio visible on a single ledger and tokens spendable on any integrated chain without the need to hold native accounts there. Crossroads also allows standard exchange contracts, such as AMM, order book, or RFQ contracts, to be deployed onto the Crossroads platform. Lending and borrowing applications are similarly possible: collateral deposited from one chain can back loans denominated in assets from another, making cross-chain shorts and arbitrage practical with existing lending platforms such as Morpho [7] or Euler [8].

Crossroads also enables applications that existing bridges cannot offer at all. A universal stablecoin can be issued natively on the backend and spent on any integrated chain, removing the centralized issuer’s role in deciding which chains to support. Cross-chain staking via Crossroads offers a new, highly flexible, multi-chain means for emerging chains to bootstrap their security with established assets such as ETH or BTC, rather than just their native liquidity [9], [10]. When the backend blockchain is itself privacy-preserving (e.g. Oasis Sapphire [11], [12]), Crossroads further enables private payments and private institutional management of public-chain assets, with smart-contract-enforced disclosure and compliance policies layered directly onto exchange transactions.

Contributions↩︎

We provide background to Crossroads in 2. Subsequently, our contributions are as follows:

• 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 (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 (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 (5).

• Implementation: We implement a proof-of-concept of Crossroads and integrate it with Bitcoin, Ethereum, and Solana (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 (7).

We review related work in 8 and conclude in 9.

2 Building Blocks↩︎

We introduce the cryptographic and systems primitives that Crossroads builds on.

2.1 Cross-chain oracles↩︎

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 [13], [14], light-client oracles verify the source chain’s consensus on the destination chain, possibly via zero knowledge proofs [15], 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.

2.2 Cryptocurrency and DeFi↩︎

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 [16].

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.

2.3 Key encumbrance↩︎

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 [2]. 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.

2.4 Threshold signature scheme↩︎

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'_i\): a (possibly) probabilistic signing algorithm that takes a key share \(\mathsf{sk}_i\) and a message \(m\), and outputs a signature share \(\sigma'_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'_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'_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'_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 [17].

2.4.0.1 Distributed key generation.

Rather than relying on a trusted dealer to execute \(\mathsf{KG}\) and distribute shares, Crossroads instantiates key generation through a secure distributed key generation (DKG) protocol \(\Pi_{\mathsf{DKG}}\) jointly run by the \(N\) signing committee members, as defined in [17].

2.5 Trusted execution environments↩︎

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 [18], AMD SEV-SNP [19], and AWS Nitro Enclaves [20]. 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 [21]–[23] and integrity attacks that enable forged attestations [24], [25]. Crossroads’ core security guarantees, however, do not rest on TEEs and we employ them only as an optional defense-in-depth layer.

3 Crossroads Architecture↩︎

In this section, we present the Crossroads architecture: its design goals and the components that fulfill them (3.1), requirements for asset support (3.2), and the deposit and withdrawal flows ([subsec:architecture-deposits,subsec:architecture-withdrawals]).

3.1 Protocol↩︎

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 1 are specific to Crossroads, while the asset chains and backend blockchain are existing systems.

Asset chains. Crossroads can integrate any blockchain that provides eventual, verifiable finality, including blockchains without smart contracts such as Bitcoin and XRPL, using a per-chain asset contract. The signing committee derives the signature for an encumbered address \(\textsf{chain}_\textsf{addr}\) linked to that asset contract. Users deposit the assets into Crossroads by transferring them into \(\textsf{chain}_\textsf{addr}\). While assets remain custodied at \(\textsf{chain}_\textsf{addr}\) on the asset chain, all exchange and transfer activity takes place on the backend blockchain.

Backend blockchain. The backend blockchain is the programmable EVM chain where the Crossroads asset contracts are deployed alongside any other third-party smart contracts. Smart contracts compatible with ERC-20 tokens can therefore operate on assets from every integrated asset chain. For instance, an AMM contract such as Uniswap [26] would allow Crossroads tokens from one asset chain to be exchanged atomically for those from another. The backend blockchain can similarly host lending markets, staking platforms, and privacy-preserving payments, all built using standard tooling without any awareness of the underlying asset chains.

Asset contracts. Every blockchain asset integrated into Crossroads is represented by a dedicated asset contract on the backend blockchain. These contracts follow the ERC-20 standard and track each user’s holdings of wrapped tokens. Each asset contract mediates all operations that affect user balances within Crossroads, including deposits, transfers, and withdrawals. It also exposes a view function called canSign to the signing committee, allowing transaction signing requests to be checked against recorded balances. The full asset contract functionality is presented in Figure 2.

Oracles. A transaction finalization oracle informs the backend blockchain when a transaction is finalized on the asset chain, letting the asset contracts verify a deposit or withdrawal. Crossroads supports flexible oracle designs, including zkBridges, TEE-based oracles, and hybrid approaches. The choice of oracle determines the security guarantees for each asset contract (5); a single chain may even be served by multiple asset contracts each backed by different oracles.

Signing committee. The signing committee jointly holds the keys controlling Crossroads assets on each asset chain under key encumbrance. Shares of each key are distributed across committee members via a threshold signature scheme, so no party ever learns a key. Users communicate with the signing committee off-chain, and spending from a Crossroads-controlled address requires a threshold of members to cooperate. The encumbrance policy is read from the asset contract: members produce signature shares only for requests the asset contract authorizes, so withdrawal transactions are only signed when the corresponding tokens are locked. We specify the committee protocol in Figure 3.

The high-level architecture of Crossroads and the associated data flow for users are depicted in 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.

None

None

3.2 Asset chain requirements↩︎

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.

3.2.0.1 Fee replacements.

Transactions whose fee payments are too low to be included on the target chain must be replaceable by transactions carrying higher fees. This is to prevent a denial-of-service attack in which low-fee transactions are broadcast but never get included in a block.

3.2.0.2 Single-choice transaction inclusion.

The chain must allow a set of valid, signed transactions containing every potential valid spend from the same account to remain valid until a transaction in the set is selected by the chain’s consensus algorithm, after which all the others become invalid forever. On Ethereum, the transaction nonce fills this purpose; on Bitcoin, it can be a UTXO spent in the transaction.

3.2.0.3 Measurable finalization.

There must be a method for measuring confidence in the finality of a particular transaction using an oracle contract on the backend chain.

3.2.0.4 Transaction signing support.

The signing committee must support the signature scheme of the chain. Since the committee holds each key under a threshold scheme and never reconstructs it, the scheme must admit a threshold signing protocol whose outputs are accepted by the chain’s native verifier.

3.2.0.5 Transaction binding.

The chain must support a mechanism for attributing transactions in the asset chains to backend blockchain addresses. For deposits, this attribution determines which Crossroads account is credited; for withdrawals, it identifies the spender so that accounting can be applied correctly. We capture this attribution mechanism as an interface implemented per asset chain.

Concrete bindings are specific to their respective chains. For example, on Bitcoin, \(\textsf{Embed}\) might add an OP_RETURN output containing \(a\). On Ethereum, \(\textsf{Embed}\) can append \(a\) to the transaction calldata or the access list. We describe these instantiations in Section 6.

3.3 Deposits↩︎

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.

3.4 Withdrawals↩︎

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.

4 Optimizations↩︎

The Crossroads construction in 3 is functionally complete, but several practical concerns may limit its adoption. On the deposit side, embedding transaction bindings in transaction fields restricts which wallets and applications can produce valid deposits, and the wait for source-chain finality delays deposit times. On the withdrawal side, all withdrawals in the base Crossroads construction from a given chain originate from a single encumbered address, capping throughput at one withdrawal per epoch.

In this section we describe Crossroads optimizations that mitigate these concerns by means of two ideas: use of multiple encumbered addresses on a given asset chain and facilitating fast transactions using third parties. The optimizations we propose can be deployed selectively and do not require modification of the core Crossroads protocol.

4.1 Deposits↩︎

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 [27].

Speeding up deposits. Before issuing tokens, Crossroads needs to wait until a deposit transaction is finalized on the asset chain in order to protect against multiple claims to the same deposit (i.e., a double spend). On some chains this finalization is slow, taking up to 30 minutes or longer [28].

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 [29], where relayers provide quick access to bridged funds for a fee; in Crossroads, however, the third party is repaid through the standard deposit flow.

4.2 Withdrawals↩︎

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 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 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.

5 Security of Crossroads↩︎

The main security property of Crossroads relates to asset ownership. We define the system as sound if and only if any user can, at any point, unilaterally withdraw their Crossroads net balance to externally owned accounts (EOAs) of their choosing. The net balance is calculated as the sum of all deposited assets, adjusted for the net value of internal transfers, minus any assets that have already been withdrawn. We show that this result implies both correctness and soundness of the system: under the threat model outlined below, no matter the circumstances, a user is always able to withdraw the assets it owns and no adversary can mint or burn tokens deliberately.

Crossroads makes several trust assumptions to achieve soundness, beyond the threshold assumption on the signing committee discussed in 5. We articulate them here.

5.1 Threat model↩︎

Backend blockchain. We assume the backend blockchain provides standard execution guarantees: transactions are executed correctly, finalized transactions are permanent, and the chain remains available. A compromise of the backend blockchain (for instance, through a successful attack on its consensus) could lead to corruption of contract state, allowing an adversary to double spend withdrawals. We therefore recommend deploying Crossroads on a backend blockchain whose security guarantees match or exceed those of the asset chains it serves.

Signing committee. Crossroads relies on a \((t,n)\)-threshold signing committee. We assume an adversary corrupts strictly fewer than \(t\) committee members. Beyond this baseline, we present additional mechanisms (5.3) to mitigate the impact of committee compromise. To achieve soundness we also require the signing committee to be live and acting strictly under \(\Pi^{\mathsf{TSS}}_{\mathsf{SC}}\).

Oracles. Crossroads relies on per-chain oracles to relay finalized transaction information from asset chains to the backend blockchain. We assume each oracle only confirms transactions that have been finalized on the source chain. We additionally assume oracles are live, meaning that any party can obtain a confirmation for any finalized transaction at any point. A compromised oracle could falsely confirm deposits that never occurred, causing the asset contract to mint unbacked wrapped tokens, or fail to confirm withdrawals, freezing user funds. Different oracle constructions satisfy oracle soundness under different trust assumptions: zkBridge-based oracles rely on the soundness of zero-knowledge proofs and the source chain’s consensus, while TEE-based oracles trust the integrity of the hardware enclave. This makes this trust assumption application specific. However, the impact of an oracle compromise is contained to its own integration: each asset contract mints tokens only against attestations from its designated oracle, so a faulty oracle for one chain can inflate or freeze only the wrapped assets of that chain.

5.2 Crossroads soundness↩︎

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:\[\begin{align} \mathsf{Net}(\mathsf{acct}, \mathsf{chain}, \vec{\sigma}) \;=\; \sum_{\substack{\mathsf{tx} \in \vec{\sigma} \\ \mathsf{Dep}(\mathsf{acct})}} \mathsf{amt}(\mathsf{tx}) \;+\; \sum_{\substack{\mathsf{tx} \in \vec{\sigma} \\ \mathsf{Rcv}(\mathsf{acct})}} \mathsf{amt}(\mathsf{tx}) \\ -\; \sum_{\substack{\mathsf{tx} \in \vec{\sigma} \\ \mathsf{With}(\mathsf{acct})}} \big(\mathsf{amt}(\mathsf{tx}) + \mathsf{fee}(\mathsf{tx})\big) \;-\; \sum_{\substack{\mathsf{tx} \in \vec{\sigma} \\ \mathsf{Snd}(\mathsf{acct})}} \mathsf{amt}(\mathsf{tx}). \end{align}\]

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 11. 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 12.

5.3 Modular security enhancements↩︎

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

5.3.0.1 Heterogeneous TEE committee.

A first mechanism is to require (and enforce via attestation) that all committee nodes run within TEEs. Using a diverse mix of hardware architectures—such as Intel SGX, AMD SEV, and AWS Nitro Enclaves—further ensures that a hardware-level vulnerability specific to one manufacturer cannot compromise all committee members at once.

Security Council. Another layer of security would be to have an emergency council with the power to freeze Crossroads contracts. This council could act as a decentralized governance layer designed to intervene during technical failures that automated systems might not catch. While the signing committee provides cryptographic security, the Council provides oversight to protect user capital from unforeseen exploits.

Hybridization. When Crossroads is integrated with a blockchain that has smart contract capabilities, it is possible to introduce an additional layer of security that remains effective even in the event of a TEE and committee compromise. In this scenario, funds can be stored within a smart contract on the native blockchain. This allows the smart contract to enforce programmatic security measures, such as limiting withdrawal throughput to prevent mass drainage, or providing a freeze functionality that can be activated by an external security council via a threshold signature.

Accountable threshold signing. Standard threshold signatures conceal which committee members contributed to a given signature, limiting the system’s ability to hold misbehaving signers accountable. Accountable-subgroup multisignatures [30] instead produce signatures that cryptographically reveal the signing subgroup to any verifier, with no reliance on off-chain transcripts or trusted logs. Adopting such a scheme in Crossroads would allow any signature produced outside the authorized withdrawal flow to be traced back to the participating signers, enabling on-chain slashing or removal from the committee.

6 Implementation↩︎

We provide a complete prototype of Crossroads with three blockchains currently integrated: Bitcoin, Ethereum, and Solana. Others may be integrated permissionlessly. The prototype uses a local EVM devnet as the backend blockchain as well as a simple MPC signing committee consisting of three signers. We make the source code of our prototype publicly available at https://github.com/trate3/crossroads.

6.1 Setup↩︎

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

6.1.0.1 Bootstrap phase.

The signing committee requires a bootstrap phase for establishing the initial membership of the committee as well as generating the committee’s MPC root key. During the bootstrap phase, a smart contract is posted on the backend blockchain. Each member of the signing committee registers its identity to the smart contract. In our prototype, the committee members must be approved by a coordinator of the bootstrap contract (who has no other authority in the system) but in practice this step could require additional certification, such as a remote attestation of the committee members’ node software.

Once all the committee members are registered, the bootstrap coordinator distributes connection information (e.g. network addresses) to the committee members, who then begin distributed key generation and create the root secret key material.

6.1.0.2 Asset contracts.

We cleanly separate the Crossroads asset contract into two components: a chain-agnostic ERC-20 contract which is reused across all Crossroads tokens, and a contract responsible for the chain-specific implementation. The chain-specific contract must decode deposit/withdrawal transactions and transaction bindings, prove transaction inclusion (often with a separate oracle), and decide how much a serialized transaction costs or spends on its asset chain.

6.2 Ethereum↩︎

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

6.2.0.1 Epochs.

Ethereum transactions contain a natural gating mechanism, the nonce, as all transactions from the same signer must be included in nonce order. When a withdrawal transaction is proven included, the asset contract then allows signatures using the next nonce. For simplicity, only typical type-2 transactions may be signed, which prevents newer transaction types from interfering with our accounting.

6.2.0.2 Transaction binding.

As described in 3.4, deposits and signed withdrawal transactions must be attributable to a Crossroads account, and this is accomplished through a transaction binding. Although Ethereum transactions have a data field, this field is used for smart contract interactions. Fortunately, extra data appended after the required transaction data is often ignored by smart contracts. Therefore, we use the final 20 bytes of the transaction calldata as the transaction binding.

6.2.0.3 Oracle.

Ethereum is secured through proof of stake, which cannot be verified succinctly in smart contracts, so we rely on an external block hash oracle. Transactions and their receipts are checked through Merkle proofs to their respective roots in the block header.

6.3 Bitcoin↩︎

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 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.

6.3.0.1 Epochs.

The asset contract’s single UTXO is initialized using a deposit transaction with the transaction binding, but all future deposits must use the encumbered account’s last UTXO. UTXOs from deposits made to the encumbered account which do not conform to the binding can be handled as separate deposit accounts as described in 4, but this is not part of our prototype.

6.3.0.2 Transaction binding.

The transaction binding we choose for Bitcoin transactions is a zero-value OP_RETURN output in the transaction, which contains a Crossroads address. For deposits, the address is where deposited funds should be issued, and for withdrawals, it is the spender account (enforced by the smart contract).

6.3.0.3 Oracle.

Our transaction oracle for Bitcoin validates a Merkle proof of transaction inclusion within the Bitcoin block in which it was mined. The block header can be verified using Bitcoin’s simplified payment verification scheme, i.e., a light client of Bitcoin which runs directly on the backend blockchain.

The requirement for signatures from the signing committee during the consolidation step of a deposit, spending the same Crossroads UTXO a withdrawal would spend, introduces an additional bottleneck not present in deposits on account-based blockchains. We note that combining multiple deposits or withdrawals into a single transaction would further increase throughput and reduce fees. Furthermore, multiple encumbered accounts can be used in parallel to account for this limitation (similar to how centralized exchanges maintain multiple hot wallets on each blockchain).

6.4 Solana↩︎

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).

6.4.0.1 Epochs.

Solana does not have a native per-account nonce by default, but it does support one, called the “durable nonce” [34]. A one-time payment initializing a durable nonce account must be made to cover the cost of storing the nonce. This requires an initialization step of two System Program instructions calling CreateAccount and InitializeNonceAccount on a fresh public key derived from the committee, separate from the primary account which holds deposited SOL tokens. The authority of this nonce account is set to the primary account during this step.²

6.4.0.2 Transaction binding.

All signed Crossroads withdrawals contain three instructions: (1) AdvanceNonceAccount, (2) Transfer, and (3) Memo, which includes the transaction binding (the spender’s Crossroads account). If a signed transaction with an incorrect nonce is sent to the network (e.g., when a different transaction containing the same nonce has already been included), the transaction is considered invalid and is dropped without penalty.

6.4.0.3 Oracle.

Solana does not have a transaction Merkle tree, so we instead integrate a TEE-based transaction oracle service. This service aggregates the responses of a quorum of independent Solana RPC providers to the finalization state of a given transaction and, if they agree, produces a response signed by a key that itself is bound to the program’s attestation. The oracle smart contract verifies the attestation and adds the transaction hash to a set of finalized transactions.

6.5 Evaluation↩︎

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 ¿tbl:tab:impl-transaction-costs? 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 7. Moreover, as shown in 13, Crossroads deposits and withdrawals cost little more than ordinary native transfers on each asset chain.

6.5.0.1 Throughput.

The base Crossroads design is constrained by withdrawals: there is one withdrawal per epoch per encumbered address, and each epoch is as long as the transaction finalization oracle requires. Under maximum security oracles that wait for six confirmations on Bitcoin and full finality on Ethereum and Solana, this means one transaction per encumbered account every 60 minutes, 15 minutes, and 13 seconds, respectively. Nonetheless, as described in 4.2, withdrawal throughput can easily be scaled across multiple encumbered accounts associated with that asset.

6.5.0.2 Latency.

If an encumbered account does not currently have a withdrawal waiting to finalize, it is immediately available for withdrawal use; otherwise, a user must wait for the existing transaction to finalize. We report the latency of signature requests using our prototype in 13.

6.5.0.3 Signing committee resources.

We measured the resources required to run an individual signing committee member under multiple committee sizes. Even with a committee size of 15, each node used under 20 MB of memory to run the signer application (on top of OS memory) and at 20 signing requests per second used approximately 637.6 KB/s of network bandwidth, split equally in both directions. Thus, a committee node would fit in most small-sized cloud compute instances at low cost.

7 Crossroads Applications↩︎

Crossroads enables many different applications that interact with assets across multiple chains. We present a range of these applications, summarized in 4, each falling under one of three headings: (1) Wallets and liquidity, (2) Universal assets, and (3) Privacy and compliance. We have implemented one application in each category, which we describe in this section. We defer the discussion of the others to 10.

7.1 Wallets and liquidity↩︎

Crossroads’ most immediate application lies in how users hold, send, and exchange tokens once all chains’ assets share the same programmable backend. Today, this generally requires a separate wallet and/or gas token per chain. Crossroads’ representation of each asset in the backend chain as ERC-20 tokens, however, yields a chain-agnostic wallet from a single key pair, enables universal receive addresses that auto-convert received funds to a recipient’s asset of choice, and enables the use of standard decentralized exchange (DEX) smart contracts to enable fast, cheap, and transparent cross-chain exchange.

Cross-chain decentralized exchange. The current cross-chain exchange landscape remains heavily centralized. Some decentralized services offer cross-chain exchange but are typically opaque, permissioned, and not fee-efficient. This leaves many smaller blockchains excluded from major interoperability frameworks and forces users onto inefficient or custodial pathways to move assets between them.

Crossroads provides a transparent, permissionless, and fee-efficient alternative. Since exchanges within Crossroads are equivalent to atomic swaps between the corresponding native assets, any standard DEX contract on the backend blockchain can serve as a cross-chain exchange for the cost of a single backend chain transaction. This includes AMMs such as Uniswap [26], on-chain order books, RFQ systems, batch auctions, and off-chain order matching systems, such as 0x Protocol [35] or Airswap [36].

In our implementation, we ported Uniswap V2 to a backend chain and launched liquidity pools between Crossroads assets. If Crossroads is deployed on a backend chain that is already well integrated with major assets, Crossroads tokens can route through those existing pools.

7.2 Universal assets↩︎

A second class of applications explores how cross-chain assets can enable applications previously constrained to one chain, such as staking, lending or stablecoin issuance.

Of these, we have implemented a universal testnet faucet, which converts proof-of-work from one chain directly into testnet funds from any integrated testnet.

Universal testnet faucet. Existing testnet token faucets are frequently rate limited, depleted, or gated behind existing reputation or identity. This adds friction for developers to test their applications and makes it difficult for privacy-conscious users to obtain test funds. Moreover, AI coding agents are increasingly used to develop and test applications autonomously, yet they cannot clear the identity proofs that faucets require, forcing a human back into the loop.

We have implemented a faucet in Crossroads that converts user-supplied proof-of-work directly into funds on a target testnet. To obtain testnet tokens, a user or agent directs hashpower toward a proof-of-work chain. In our implementation, this is Monero, which supports CPU-based mining with its use of the RandomX hash function. The resulting coins are deposited into Crossroads and automatically swapped for the desired testnet tokens through a backend DEX. Because the only requirement is compute, our faucet provides funds without rate limits, reputation, identity requirements, or other anti-Sybil protections.

Crossroads’ permissionless integration of new chains allows anyone to add new testnets. Testnet token liquidity is ensured through arbitrage: arbitrageurs are incentivized to refill testnet tokens into the DEX if its reserves run low.

7.3 Privacy and compliance↩︎

Users of centralized exchanges enjoy privacy that public blockchains lack: their balances and trades are visible only to the exchange. Crossroads aims to match this guarantee in a decentralized setting. By choosing a private backend blockchain, transfer transactions within Crossroads remain fully private and withdrawal details are visible only to its signing committee, enabling private payments and private asset management. To balance the concerns such privacy raises, compliance policies such as KYC whitelisting can be enforced transparently by smart contracts on the same transactions (on-chain compliance).

We have realized such privacy in Crossroads through implementation with a private backend blockchain, namely Oasis Sapphire [11], [12].

Private payments. Oasis Sapphire uses TEEs to conceal contract state and calldata, exposing them only to parties the contract itself authorizes. In a Sapphire-based Crossroads deployment, therefore, internal activity is concealed: where transfers and exchanges never leave the backend chain, the asset contract might disclose an account’s balance only to its owner; then, external observers of the backend chain would learn only metadata (a transaction’s timing, destination address, and fee payment). Deposits and withdrawals on the asset chains are public, which ties each such transaction to a backend account identifier. Because backend accounts are pseudonymous, public observers can link these transactions to an account but learn little about its internal activity.

Beyond what is public, the Crossroads signing committee sees each withdrawal request it signs, including the requesting account, even if those are not submitted on chain. However, that leakage can itself be minimized by requiring committee nodes to run within trusted enclaves, in which case operators would learn at most that a signature was issued. Our implementation realizes the first guarantee: with Sapphire as the backend, transfers and exchanges within Crossroads are more private, and the committee runs as plain MPC signers (Section 6). A TEE-based committee node implementation remains future work.

8 Related Work↩︎

8.0.0.1 Cross-chain messaging protocols and bridges.

Cross-chain messaging protocols deliver arbitrary messages from a contract on one chain to a contract on another. Asset bridges are cross-chain messaging protocols specifically for sending assets from one chain to another. We give a non-exhaustive overview of representative ones. Wormhole [13] and Axelar [14] use validator set committees to attest to cross-chain messages. Wormhole’s Token Bridge and Axelar’s Satellite (and aggregator Squid) sit on top of these messaging layers to provide token bridging functionality. Hyperlane [37] and LayerZero [38] both let applications configure their own verification logic (i.e. applications can swap in different verifiers, including other cross-chain protocols)—Hyperlane via their Interchain Security Modules, and LayerZero V2 via their Decentralized Verifier Networks. Hyperlane’s Warp Routes and LayerZero’s Stargate are the canonical asset bridges built on top of these messaging layers Polyhedra Network [39] instantiates the zkBridge protocol [15] for both EVM-based chains and Bitcoin.

Cross-chain exchanges. While bridges transfer a given asset across chains, cross-chain exchanges allow users to swap between assets on different chains. Atomic swaps via Hash Time Locked Contracts (HTLCs) [40] are one technique, with subsequent work extending it to arbitrary signature schemes and removing the dependence on on-chain scripting [41]. Cross-chain AMMs eliminate the need for matching counterparties altogether by pooling liquidity: THORChain [42] and Chainflip [43] each operate a dedicated consensus layer that records balances and prices, while threshold-signature-controlled vaults custody the native assets. These systems share Crossroads’ backend chain approach but fix a single application at the protocol level: their validators must run nodes for every supported chain, and integrating a new chain is a permissioned protocol decision. Despite the existence of decentralized cross-chain exchanges, centralized exchanges such as Binance, Bybit and Coinbase Exchange dominate the exchange landscape [44].

MPC-based custody. Threshold signing, used by Crossroads’ signing committee, is already widely deployed for digital asset custody. Commercial platforms such as Fireblocks [45] secure institutional wallets by sharding signing keys across parties using threshold-ECDSA protocols [46], often hardened with TEEs; ZenGo [47] applies two-party ECDSA [48] to consumer wallets. In all these systems, however, the signing policy is enforced by the provider’s off-chain policy engine, opaque to users and not programmable. Crossroads adds a layer of programability via the use of the backend blockchain: signatures are issued only for withdrawals the backend asset contract has authorized, making the custody policy transparent and programmable.

Account abstraction. Account abstraction is today’s dominant route to wallet-layer interoperability: ERC-4337 [49] and EIP-7702 [50] make account logic programmable, and chain-abstraction systems build on this to let a single wallet control funds across multiple chains. Particle Network [51], for instance, deploys a smart account for the user on each chain, all tied to one key pair. NEAR chain signatures [52] uses an MPC network holding the users keys across multiple chains and, at the account’s request, produces the signatures to spend from them. Both give the user a single account, but its assets stay scattered on their native chains, and moving them still requires per-operation bridging. Crossroads achieves the same abstraction with one account on the backend chain, but additionally enables cross-chain operations as ordinary contract calls.

9 Conclusion↩︎

We presented Crossroads, a smart contract layer for chain-abstracted assets that unifies cross-chain asset management on a single backend blockchain. While this presents a step forward towards a more transparent and flexible interoperability framework, it also gives rise to a number of future research directions:

Asset-specific policies. Crossroads currently focuses on cross-chain asset transfers. Many assets, however, carry capabilities tied to their source chains beyond their value: DAO tokens grant voting rights, NFTs unlock token-gated sites or events, etc. As shown in Liquefaction [2], key encumbrance can preserve these capabilities for the current owner via per-asset access policies. Extending Crossroads with such policies in a general way remains an open problem.

Responsible and fair upgrades. Crossroads relies on the security of its oracles to safeguard assets. However, an asset chain might hard fork, and its oracle implementation must be upgraded. Designing governance mechanisms that handle oracle upgrades both responsibly and securely is also an open problem.

Ethics Considerations↩︎

We acknowledge that it is possible to deploy Crossroads in a privacy-preserving manner such that user transactions cannot be easily tracked across chains. We have not deployed Crossroads this way ourselves, but we have considered how this could be done responsibly. In particular, our use of TEEs on top of the signing committee members can be extended to allow for conditional release of information to regulators in special circumstances according to a policy (as opposed to broad access to all activity).

10 Other Applications↩︎

This section describes additional applications for Crossroads.

10.1 Wallets and Liquidity↩︎

Chain-agnostic wallet. Any asset from any blockchain integrated into Crossroads can be managed from a single backend blockchain wallet. When making purchases in an asset the wallet doesn’t already own, frontend software can abstract away the swap step to provide a payment experience denominated in the user’s asset of choice. Because every user’s holdings across all integrated chains are recorded in a single backend ledger, wallets and block explorers can display a user’s complete cross-chain portfolio and activity from one source, rather than querying and aggregating a separate full node for each chain.

Universal receive addresses. Crossroads can support receiving assets from arbitrary integrated chains and automatically converting the payments to the asset of the recipient’s choice. Most donation recipients and merchants only accept a few different blockchain asset types. Using custom deposit addresses as described in 4.1, a recipient can instead designate a preferred asset (e.g., Ether). Crossroads can derive receive addresses for all integrated blockchains, binding these addresses to a contract that automatically swaps received funds for the recipient’s preferred asset.

10.2 Universal Assets↩︎

Universal stablecoins. Stablecoins are a class of cryptocurrencies designed to maintain a stable value relative to a reference asset, typically USD. The market has grown rapidly, with aggregate capitalization exceeding $300 billion, of which roughly $250 billion is concentrated in USDC and USDT, the two largest stablecoins [53]. Although both are deployed on multiple chains, chain support is determined by a centralized issuer and therefore remains selective: USDT, for example, is only available on 13 blockchains despite the existence of over 150 active ones [54].

Crossroads enables the construction of a universal stablecoin: a stablecoin issued on the backend blockchain that can be spent on any smart-contract-enabled chain integrated with Crossroads. To extend support to a new chain, anyone can deploy a smart contract on that chain that mints stablecoins to a user upon presentation of a valid withdrawal signature from the Crossroads address.

Cross-chain staking. Over $34 billion is currently staked on on-chain protocols [55], but this capital only secures protocols on the chain where it is held. Large-liquidity chains benefit, while emerging chains struggle to attract stake sufficient to secure their protocols. Babylon addresses this problem by enabling use of BTC for staking against equivocation on other chains [9], [10]. Crossroads offers an alternative, enabling a cross-chain staking model using assets from any integrated chain for any malfeasance observable by an oracle.

Concretely, a staking contract on the backend blockchain holds a user’s wrapped assets as collateral and receives oracle updates from the target chain. When the oracle relays evidence of misbehavior, the responsible actor’s collateral is slashed.

Cross-chain lending and borrowing. Lending and borrowing protocols are widespread in blockchain settings, commonly used to short assets or arbitrage price differences across markets. Crossroads enables assets from any integrated chain to serve as collateral to borrow any other integrated asset, making atomic cross-chain shorts and arbitrage practical. Standard lending contracts such as Aave [56] or Euler [8] can be deployed on the backend blockchain to enable this functionality.

10.3 Privacy and Compliance↩︎

Private management of public assets. Institutional asset management requires confidentiality: portfolios, trade timing, and counterparty relationships are commercially sensitive. Yet most crypto liquidity lives on public blockchains, where every transaction is visible. Today, institutions rely on off-chain custodians or centralized exchanges, exposing themselves to custody fees and losing access to smart contract functionality.

Crossroads instead enables institutional management of public blockchain assets using a fully-featured private backend blockchain. Additionally, Crossroads enables deployment of funds in decentralized finance protocols even while they are custodied in Crossroads, allowing institutions to take advantage of the pooled liquidity of public blockchains while privately enforcing access controls and ownership changes.

On-chain compliance. Compliance policies in Crossroads can be implemented as smart contracts and layered directly onto exchange transactions, for example by enforcing KYC-based whitelisting that restricts participation to vetted counterparties. Adherence to these policies is then publicly verifiable on-chain, rather than enforced by an opaque centralized authority, and the policies compose with the private applications described above.

11 Additional Proofs↩︎

12 Denial-of-service attacks↩︎

Since Crossroads withdrawals on a given chain originate from the same encumbered address, an adversary can attempt to throttle the system by repeatedly initiating withdrawals. By submitting back-to-back withdrawal transactions carrying high fees, the adversary forces honest users to either match those fees to compete for inclusion in subsequent epochs or to wait until the adversary runs out of money. With a sufficiently funded adversary, this can stall withdrawals or make them prohibitively expensive.

We mitigate this attack with two of the mechanisms introduced in 4.2. First, with an intent-based withdrawal framework, users do not have to go through the encumbered address at all: when a third-party filler is willing to advance funds on the destination chain in exchange for the user’s Crossroads tokens, the user’s withdrawal completes via the filler’s address rather than competing for the encumbered account’s epochs. Second, where the chain supports it, parallelizing withdrawals removes the single-epoch bottleneck altogether. UTXO-based chains naturally support parallel spends through multi-output transactions, while smart-contract-enabled chains can multiplex withdrawals through a dispatcher contract.

13 Signing Latency Evaluation↩︎

1 compares Crossroads deposits and withdrawals to ordinary native transfers on each asset chain. The overhead of the transaction binding adds an extra 31 virtual bytes on Bitcoin and 320 extra gas on Ethereum, with no additional cost on Solana.

 2 reports the threshold ECDSA signing latency in our prototype by committee size and round-trip latency. We emulate the network latency between processes on the same machine to give precise answers, and these measurements use all \(n\) members (\(t = n\)). Threshold ECDSA is the slower of the two signature schemes.

References↩︎

---

1. ^*These authors contributed equally to this work.↩︎

2. In Solana, the nonce account’s “authority” is the public key authorized to advance the nonce.↩︎