Pith

open record

sign in

arxiv: 2607.06525 · v1 · pith:MBKYEAYD · submitted 2026-07-07 · cs.CR

Crossroads: A Smart Contract Layer for Chain-Abstracted Assets

James Austgen , Dani Vilardell , Ari Juels This is my paper

Reviewed by Pith T0 review T1 audit T2 compute T3 formal T4 kernel 2026-07-08 02:51 UTCglm-5.2pith:MBKYEAYDrecord.jsonopen to challenge →

classification cs.CR
keywords chain abstractioncross-chain bridgethreshold signatureskey encumbranceERC-20smart contractsblockchain interoperabilitynon-custodial
0
0 comments X

The pith

Crossroads: Any blockchain asset becomes a programmable ERC-20

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Crossroads proposes a hub-and-spoke architecture where assets from any blockchain — including chains without smart contracts like Bitcoin — are deposited into committee-controlled addresses on their native chains and represented as ERC-20 tokens on a single EVM backend chain. A threshold signing committee holds the keys to these addresses under key encumbrance: no single party ever learns a key, and signatures are produced only when the backend's asset contract authorizes them. Because every cross-chain asset is an ERC-20, any smart contract deployed on the backend (an AMM, a lending market, a privacy mixer) automatically operates on assets from every integrated chain, and a single backend transaction can atomically settle an exchange of native assets across chains that previously required multiple bridge hops. The paper's central security claim is Theorem 3 (System Soundness): under a (t,n)-threshold committee with EUF-CMA secure signatures and distributed key generation, plus oracle soundness, any user can unilaterally produce a valid withdrawal transaction recovering their full net balance to an externally owned account on the native chain. The proof proceeds in three parts — a contract invariant (balance plus pending withdrawals equals net balance) is maintained by induction over the transcript; the on-chain balance at the encumbered address is at least the sum of all users' net balances; and the user can lock funds, obtain threshold signatures, and broadcast a valid transaction, with resource-bounded adversaries unable to block indefinitely since each competing withdrawal costs positive on-chain fees. The paper implements a proof of concept across Bitcoin, Ethereum, and Solana, and catalogs applications including chain-agnostic wallets, cross-chain lending, universal stablecoins, and private payments when deployed on a privacy-preserving backend.

Core claim

The core mechanism is key encumbrance combined with a unidirectional finalization oracle. A threshold signing committee jointly controls keys for addresses on each integrated chain but never reconstructs them; instead, committee members produce signature shares only for transactions the backend asset contract has authorized via a canSign check. This splits the system cleanly: all chain-specific logic (deposit verification, balance tracking, withdrawal authorization) lives in ERC-20 asset contracts on the backend, while the committee's logic stays minimal and separately auditable. The soundness proof turns on showing that this split preserves a balance invariant — the contract's internal (bal

What carries the argument

Key encumbrance via (t,n)-threshold signature scheme with DKG; per-chain finalization oracles (zkBridge, TEE-based, or hybrid); ERC-20 asset contracts on an EVM backend chain with canSign authorization; transaction binding (Definition 1) embedding backend addresses into native-chain transactions; single-choice transaction inclusion and fee replacement as per-chain requirements

If this is right

  • Any ERC-20-compatible DeFi protocol — AMMs, lending pools, stablecoin issuers — becomes cross-chain by default when deployed on the backend, without protocol-level changes or awareness of source chains.
  • Chains without smart contracts (Bitcoin, XRPL) gain access to programmable financial primitives they cannot natively support, as long as they provide verifiable finality and fee-replaceable transactions.
  • The permissionless integration model means anyone can add a new chain by deploying an asset contract and oracle, potentially enabling long-tail chains to access liquidity and applications without hub operator approval.
  • If deployed on a privacy-preserving backend chain, cross-chain transactions inherit confidentiality by default, enabling institutional asset management with smart-contract-enforced disclosure policies.
  • The modular security enhancements (heterogeneous TEE committees, security councils, accountable threshold signing) suggest a defense-in-depth strategy where the cryptographic threshold assumption is the primary guarantee but not the only line of defense.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The soundness guarantee covers valid broadcast but not inclusion, meaning a well-funded adversary could repeatedly front-run honest withdrawals by paying higher fees, forcing users to either match fees or wait — the paper bounds this by adversary budget, but an adversary with effectively unlimited funds could make withdrawals prohibitively expensive without violating the formal soundness property.
  • The liveness assumption on the signing committee is structurally distinct from the corruption threshold: if t or more members go offline (rather than being corrupted), the system cannot produce signatures at all, and the soundness guarantee becomes moot because no broadcast is possible. This is a liveness failure the adversarial model does not fully address.
  • The single-encumbered-address-per-chain design creates a throughput bottleneck (one withdrawal per epoch per address), and while the paper proposes parallelization via multiple addresses and intent-based fillers, these introduce liquidity fragmentation and third-party trust assumptions that partially dilute the non-custodial guarantee.
  • The oracle trust model is application-specific and contained per-chain, but a compromised oracle for a high-liquidity chain could mint unbacked tokens that trade alongside legitimate ones in shared backend liquidity pools, potentially affecting users of other chains' assets through cross-pool contagion.

Load-bearing premise

The soundness proof requires the signing committee to be live — meaning enough members are online and responsive to produce signature shares. If enough members simply go offline (due to coordinated denial-of-service, infrastructure failure, or lost key shares) rather than being corrupted, users cannot obtain the threshold signatures needed for withdrawal, and the formal soundness guarantee becomes moot because no withdrawal transaction can be produced at all.

What would settle it

Deploy Crossroads on a backend chain, integrate an asset chain, and attempt to withdraw after inducing a liveness failure in the signing committee (enough members offline to drop below threshold t). If users cannot obtain signatures and no fallback mechanism recovers their funds, the soundness guarantee does not hold in practice despite the corruption threshold being unbreached.

Figures

Figures reproduced from arXiv: 2607.06525 by Ari Juels, Dani Vilardell, James Austgen.

Figure 1
Figure 1. Figure 1: Overview of the Crossroads architecture. Alice deposits assets into encumbered addresses on asset chains (1); [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 3
Figure 3. Figure 3: The signing committee protocol ΠTSS SC , parameter￾ized by a (t, n)-threshold signature scheme TSS (see Sec￾tion 2.4) and a transaction binding TB (see Theorem 1). Key generation is performed per chain by the committee jointly executing a distributed key generation protocol ΠDKG. On each signing request, committee members independently verify authorization via crsrds.CanSign, embed the request￾ing acct int… view at source ↗
Figure 2
Figure 2. Figure 2: The Crossroads assets contract, parameterized [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Table of example applications Crossroads enables. All applications rely on the ERC-20 asset contracts; the [PITH_FULL_IMAGE:figures/full_fig_p012_4.png] view at source ↗
read the original abstract

This paper introduces Crossroads, a smart contract layer for chain-abstracted assets. In Crossroads, assets from nearly any chain are represented on a single backend blockchain as ERC-20 tokens. As a result, any asset can participate in smart-contract-based exchange, lending, or privacy applications on a single unified platform. So while Crossroads offers cross-chain bridging, a common, partial approach to alleviating the fragmentation of the blockchain ecosystem today, this is just one service within Crossroads' general-purpose chain-abstraction model. Crossroads relies on key encumbrance: a threshold signing committee holds encumbered keys controlling assets on each integrated chain, signing transactions only as authorized by smart contracts on the backend blockchain. Asset movements are fee-efficient, as ownership changes are recorded on the backend blockchain and users may set the transaction fee for withdrawals. Crossroads enables permissionless, modular integration of new blockchains using pluggable oracles with flexible design options (zkBridge, TEE-based, hybrid). Asset deposits into Crossroads benefit from strong, chain-specific finalization guarantees, minimizing the risk of reorg attacks. Unlike existing bridges, however, third-party smart contracts in Crossroads can provide fast, optimistic access to funds before finalization completes. We prove that Crossroads satisfies soundness: given an honest quorum of signing committee members, any user can unilaterally generate a withdrawal transaction transferring their net balance to an account on an integrated blockchain. We implement a proof of concept across multiple public blockchains: Bitcoin, Ethereum, and Solana. We catalog a range of applications enabled by Crossroads, including universal wallets, cross-chain staking and lending, privacy-preserving payments, and private management of public blockchain assets.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 8 minor

Summary. This paper introduces Crossroads, a smart contract layer that represents assets from heterogeneous blockchains as ERC-20 tokens on a single EVM backend chain. A threshold signing committee holds encumbered keys controlling assets on each integrated chain, signing transactions only when authorized by the backend asset contract. The paper presents the core architecture (Section 3), practical optimizations including custom deposit addresses and intent-based withdrawals (Section 4), a soundness proof (Section 5, Appendix B), a proof-of-concept implementation across Bitcoin, Ethereum, and Solana (Section 6), and a catalog of applications (Section 7). The central claim is Theorem 3 (System Soundness): under a (t,n)-threshold committee with EUF-CMA secure TSS and DKG, any user can unilaterally produce a valid withdrawal transaction for their full net balance.

Significance. The paper addresses a real and important problem in blockchain interoperability: achieving programmable, permissionless cross-chain asset management without requiring smart contracts on every integrated chain. The key-encumbrance approach, cited from the authors' prior work (Liquefaction [6]), is applied here to a hub-and-spoke topology with a concrete asset contract (Figure 2) and signing committee protocol (Figure 3). The soundness proof (Appendix B) is structured in three clear parts—invariant, on-chain consistency, and constructive withdrawal sequence—and the invariant proof by induction on transcript operations is correct for the contract as specified. The proof-of-concept implementation across Bitcoin, Ethereum, and Solana, with publicly available code, and the cost analysis (Table 1) strengthen the contribution. The modular security enhancements (Section 5.3) are reasonable defense-in-depth measures. The paper is outside current consensus only in the sense that it proposes a more general architecture than existing hub-and-spoke bridges; this is a design contribution, not a correctness risk.

major comments (1)
  1. Appendix B, Part 2 (on-chain balance consistency): The proof's key assumption—that every spend from the encumbered address corresponds to a ConfirmWithdrawal—is discharged by arguing that honest signers check CanSign before producing shares, so unauthorized spends require EUF-CMA forgery. However, §6.3 (Bitcoin integration) introduces a consolidation signing path with a separate authorization check: '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.' This is a second authorization path distinct from CanSign (which checks PW >= amt+fee and RW >= r). The proof of Theorem 3 does not address this path. If the consolidation authorization can be satisfied by a transaction that net-decreases the encumbered balance (e.g., a
minor comments (8)
  1. Figure 2, LockWithdrawal handler: The assertion checks bal[(acct, η)] >= r, but r is initialized to ⊥ in the contract state and only set via the Init handler. If Init has not been called, this comparison would fail. The contract should specify a default value or clarify that Init is always called first.
  2. §3.4: The text says 'a commitment (on the backend blockchain) from the spender to pay for a particular transaction hash' as an alternative to transaction bindings, but this alternative is not formalized. If it is mentioned for motivation only, consider clarifying; otherwise a brief formalization would strengthen the presentation.
  3. Table 1: The 'Burn for spending (any)' row label is unclear. It presumably refers to the LockWithdrawal operation, but the label does not match the contract's function name. Consider relabeling for consistency with Figure 2.
  4. §6.3: The consolidation signing path's authorization check ('net deposit to the encumbered account') is described informally. A precise specification of how the asset contract verifies the net-deposit condition would help readers assess its security.
  5. Appendix B, Part 3: The argument that a resource-bounded adversary can finalize at most k = B/c competing withdrawals is sound, but the bound depends on the adversary's budget B being finite and known. The proof should clarify that this is a computational/resource assumption, not a cryptographic one, and that it only bounds the number of delays, not their duration (since each delay lasts one finalization period).
  6. §4.1: The auction mechanism for custom deposit addresses is described at a high level. The claim that 'the winner can delay broadcasting the consolidation transaction until transaction fees fall, profiting from the difference' assumes fee predictability that may not hold. A brief discussion of the risks of this strategy would strengthen the presentation.
  7. References [12] and [31] cite specific bridge exploits (KelpDAO, Bybit) with 2026 dates. These should be verified for accuracy, as they appear to be forward-dated or fictional.
  8. The abstract states 'any user can unilaterally generate a valid withdrawal transaction transferring their full net balance to an externally owned account on an integrated blockchain.' The phrase 'full net balance' is slightly imprecise; Definition 2 requires Net >= amt+fee, so the user withdraws amt (not necessarily the full balance in one transaction). Clarifying this would improve precision.

Simulated Author's Rebuttal

1 responses · 1 unresolved

We thank the referee for a careful and constructive report. The referee correctly identifies a gap between the soundness proof in Appendix B and the Bitcoin-specific consolidation signing path described in Section 6.3: the proof's Part 2 discharge assumes every spend from the encumbered address is authorized via CanSign, but the Bitcoin integration introduces a second authorization path for consolidation transactions that is not covered by this argument. We agree this must be addressed and will revise the manuscript accordingly. The referee's report was truncated mid-sentence, so we respond to the concern as stated and note the limits of what we can address without seeing the complete comment.

read point-by-point responses

  1. Referee: Appendix B, Part 2 (on-chain balance consistency): The proof's key assumption—that every spend from the encumbered address corresponds to a ConfirmWithdrawal—is discharged by arguing that honest signers check CanSign before producing shares, so unauthorized spends require EUF-CMA forgery. However, §6.3 (Bitcoin integration) introduces a consolidation signing path with a separate authorization check: '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.' This is a second authorization path distinct from CanSign (which checks PW >= amt+fee and RW >= r). The proof of Theorem 3 does not address this path. If the consolidation authorization can be satisfied by a transaction that net-decreases the encumbered balance (e.g., a)

    Authors: The referee is correct that the proof of Theorem 3 in Appendix B does not address the Bitcoin consolidation signing path introduced in Section 6.3. We acknowledge this gap and will revise the manuscript to close it. Below we explain why the gap does not undermine soundness, what the revision will contain, and what limitations remain. The referee's comment was truncated mid-sentence, so we address the concern as articulated and note where we cannot fully respond to an incomplete point. The core of the referee's concern is that the consolidation path constitutes a second authorization mechanism distinct from CanSign, and that the proof's Part 2 discharge—which argues every spend from the encumbered address corresponds to a ConfirmWithdrawal by appealing to CanSign—does not cover spends authorized through this alternative path. This is accurate. The proof as written assumes that CanSign is the sole gate through which the signing committee authorizes transactions, and the Bitcoin consolidation path violates that assumption. However, the consolidation path does not break soundness; it requires a more careful argument that the current proof omits. The key observation is that the consolidation authorization requires the signed transaction to produce a net deposit to the encumbered account: the requester must combine the current encumbered UTXO with another input such that the encumbered account's balance increases. A transaction that net-decreases the encumbered balance cannot satisfy this condition and therefore cannot obtain committee signatures. Consequently, consolidation transactions can only increase OnChain(chain), never decrease it. The inequality OnChain(chain) >= sum_acct N_acct in Part 2 is preserved because consolidation spends add to the left-hand side without any revision: no

standing simulated objections not resolved
  • The referee's comment was truncated mid-sentence, so we cannot be certain we have addressed the full intended concern. We respond to the concern as articulated but acknowledge that a complete point might raise additional issues we cannot anticipate.

Circularity Check

0 steps flagged

No significant circularity: the soundness proof is self-contained against external cryptographic primitives, with only a minor non-load-bearing self-citation for the key encumbrance concept.

full rationale

The paper's central result (Theorem 3, System Soundness) is proved in Appendix B via a three-part argument: (1) an inductive invariant bal+PW = Net, (2) on-chain balance consistency via Oracle Soundness, and (3) a constructive withdrawal sequence. The proof's cryptographic load is borne by EUF-CMA secure TSS and DKG, both cited to Boneh-Shoup [8]—an external textbook, not self-cited. The reduction to EUF-CMA forgery in the proof's final paragraph is standard and does not reduce to a result the authors defined. The key encumbrance concept is cited from Liquefaction [6] (authors' prior work), but it is used as a building block—an architectural primitive—not as a theorem whose truth the present soundness proof depends on. The soundness proof does not invoke any uniqueness theorem, ansatz, or fitted parameter from the authors' prior work. The Bitcoin consolidation path gap flagged by the skeptic is a correctness/completeness concern (the proof's Part 2 discharge assumes all spends go through CanSign, but §6.3 introduces a separate authorization path), not a circularity issue—the proof does not define its conclusion in terms of its inputs. No step in the derivation chain reduces to its own inputs by construction.

Axiom & Free-Parameter Ledger

3 free parameters · 6 axioms · 3 invented entities

The free parameters (t, n, r, finalization thresholds) are standard deployment configuration choices, not fitted constants. The axioms are a mix of standard cryptographic assumptions (EUF-CMA, DKG security from Boneh-Shoup) and domain assumptions (backend chain liveness, oracle soundness, committee liveness, asset chain properties). The domain assumptions are clearly stated in Section 5.1 and are appropriate for the system model, though the committee liveness assumption is the most fragile as it is not discharged in the proof. The invented entities (transaction binding, asset contract, committee protocol) are all implemented and tested in the proof-of-concept, with concrete instantiations provided.

free parameters (3)
  • Signing threshold (t) and committee size (n) = n=3, t=n in prototype; n=15 in evaluation
    The threshold t and committee size n are design parameters chosen per deployment. The prototype uses 3 signers with t=n; the evaluation tests up to 15. These are not fitted to data but are configuration choices that affect security and liveness.
  • Prover reward (r) = Not specified numerically
    The reward r for submitting withdrawal inclusion proofs is a free parameter set at contract initialization (Figure 2, 'Init' handler). It must be large enough to incentivize proof submission but is not derived from first principles.
  • Oracle finalization threshold = 6 confirmations (Bitcoin), full finality (Ethereum, Solana)
    The number of confirmations required before an oracle reports finality is a per-chain parameter. The paper uses 6 for Bitcoin and full finality for Ethereum/Solana, chosen based on chain-specific security considerations rather than derived.
axioms (6)
  • domain assumption The backend blockchain provides correct execution, finality, and availability (Section 5.1).
    Standard assumption for smart-contract platforms, but if the backend chain is compromised, contract state can be corrupted and withdrawals double-spent.
  • domain assumption The signing committee is live and acts strictly under Π_TSS_SC (Section 5.1).
    Soundness requires not just that fewer than t members are corrupted, but that the committee is available to produce signatures. This liveness assumption is not discharged in the proof.
  • domain assumption Each oracle only confirms finalized transactions and is live (Section 5.1).
    A compromised oracle can mint unbacked tokens or freeze withdrawals. The paper notes this is application-specific and contained per-chain.
  • standard math The (t,n)-threshold signature scheme TSS is EUF-CMA secure against an adversary corrupting up to t-1 signers (Section 2.4, Theorem 3).
    Standard cryptographic assumption from Boneh-Shoup [8]. The proof's Part 3 relies on this to argue unauthorized signatures are negligible.
  • standard math The DKG protocol Π_DKG produces key shares indistinguishable from an ideal trusted dealer (Section 2.4, proof Part 3).
    Standard assumption for secure DKG. Cited from Boneh-Shoup [8].
  • domain assumption Asset chains provide eventual, verifiable finality, fee replacement, single-choice transaction inclusion, and threshold-signing-compatible signature schemes (Section 3.2).
    Required for Crossroads integration. The paper notes all explored chains meet these requirements, though some (e.g., Bitcoin) historically did not.
invented entities (3)
  • Transaction binding (Definition 1) independent evidence
    purpose: Attributing asset-chain transactions to backend blockchain accounts without requiring on-chain commitments, enabling withdrawal accounting and deposit crediting.
    The paper provides concrete instantiations for Bitcoin (OP_RETURN), Ethereum (calldata suffix), and Solana (Memo instruction) in Section 6, and the mechanism is falsifiable: if Extract(Embed(t,a)) != a for some chain, the binding is invalid for that chain.
  • Crossroads asset contract (Figure 2) independent evidence
    purpose: ERC-20 contract on the backend chain tracking deposits, transfers, withdrawals, and exposing CanSign for the signing committee.
    Implemented and deployed in the proof-of-concept. The contract's invariant is proven in Appendix B, Part 1.
  • Signing committee protocol Π_TSS_SC (Figure 3) independent evidence
    purpose: Off-chain protocol where committee members verify CanSign, embed transaction bindings, and produce threshold signature shares for withdrawal transactions.
    Implemented using the NEAR threshold-signatures library. Signing latency measured in Table 3.

pith-pipeline@v1.1.0-glm · 27869 in / 4525 out tokens · 383182 ms · 2026-07-08T02:51:09.638037+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

57 extracted references · 57 canonical work pages · 1 internal anchor

  1. [1]

    Aave: Open source liquidity protocol

    Aave. Aave: Open source liquidity protocol. https://aave.com, 2026. Accessed: 2026-04-24

    work page 2026

  2. [2]

    Across: An intent-based cross-chain bridge

    Across Protocol. Across: An intent-based cross-chain bridge. https: //docs.across.to, 2026. Accessed: 2026-06-11

    work page 2026

  3. [3]

    Uniswap v3 core

    Hayden Adams, Noah Zinsmeister, Moody Salem, River Keefer, and Dan Robinson. Uniswap v3 core. https://uniswap.org/whitepaper-v 3.pdf, 2021. Accessed: 2026-03-24

    work page 2021

  4. [4]

    AMD SEV-SNP: Strengthening VM Iso- lation with Integrity Protection and More

    Advanced Micro Devices. AMD SEV-SNP: Strengthening VM Iso- lation with Integrity Protection and More. https://www.amd.com/sy stem/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-int egrity-protection-and-more.pdf, 2020. Accessed: 2026-04-28

    work page 2020

  5. [5]

    AWS Nitro Enclaves User Guide

    Amazon Web Services. AWS Nitro Enclaves User Guide. https: //docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html, 2024. Accessed: 2026-04-28

    work page 2024

  6. [6]

    Liquefaction: Privately liquefying blockchain assets

    James Austgen, Andr ´es F ´abrega, Mahimna Kelkar, Dani Vilardell, Sarah Allen, Kushal Babel, Jay Yu, and Ari Juels. Liquefaction: Privately liquefying blockchain assets. In2025 IEEE Symposium on Security and Privacy (SP), pages 1493–1511, 2025

    work page 2025

  7. [7]

    Euler whitepaper

    Michael Bentley and Doug Hoyte. Euler whitepaper. https://github.c om/euler-xyz/euler-vault-kit/blob/master/docs/whitepaper.md, 2024. Accessed: 2026-04-24

    work page 2024

  8. [8]

    Draft (Version 0.6), 2023

    Dan Boneh and Victor Shoup.A Graduate Course in Applied Cryptography. Draft (Version 0.6), 2023. Available at https: //toc.cryptobook.us/

    work page 2023

  9. [9]

    ERC-4337: Account abstraction using alt mempool

    Vitalik Buterin, Yoav Weiss, Dror Tirosh, Shahaf Nacson, Alex Forsh- tat, Kristof Gazso, and Tjaden Hess. ERC-4337: Account abstraction using alt mempool. https://eips.ethereum.org/EIPS/eip-4337, 2021. Accessed: 2026-06-11

    work page 2021

  10. [10]

    EIP-7702: Set code for EOAs

    Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and Matt Garnett. EIP-7702: Set code for EOAs. https://eips.ethereum.org/EIPS/eip-7 702, 2024. Accessed: 2026-06-11

    work page 2024

  11. [11]

    UC non-interactive, proactive, threshold ECDSA with identifiable aborts

    Ran Canetti, Rosario Gennaro, Steven Goldfeder, Nikolaos Makriyan- nis, and Udi Peled. UC non-interactive, proactive, threshold ECDSA with identifiable aborts. InProceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (CCS ’20), pages 1769–1787. Association for Computing Machinery, 2020

    work page 2020

  12. [12]

    Inside the KelpDAO bridge exploit: How ˜$292 million in rsETH was released against a non-existent burn

    Chainalysis Team. Inside the KelpDAO bridge exploit: How ˜$292 million in rsETH was released against a non-existent burn. https: //www.chainalysis.com/blog/kelpdao-bridge-exploit-april-2026/, 23 Apr. 2026. Accessed: 2026-06-11

    work page 2026

  13. [13]

    Ekiden: A platform for confidentiality-preserving, trustworthy, and performant smart contracts

    Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah Johnson, Ari Juels, Andrew Miller, and Dawn Song. Ekiden: A platform for confidentiality-preserving, trustworthy, and performant smart contracts. In2019 IEEE European Symposium on Security and Privacy (EuroS&P), pages 185–200, 2019

    work page 2019

  14. [14]

    Jalen Chuang, Alex Seto, Nicolas Berrios, Stephan van Schaik, Christina Garman, and Daniel Genkin. Tee. fail: Breaking trusted execution environments via ddr5 memory bus interposition. In47th IEEE Symposium on Security and Privacy (IEEE S&P’26). IEEE Computer Society, 2026

    work page 2026

  15. [15]

    Finality and block confirmations

    Circle. Finality and block confirmations. Circle CCTP Documenta- tion, 2026. Accessed: 2026-06-09

    work page 2026

  16. [16]

    Reflections on Bitcoin transaction batching

    Coinbase. Reflections on Bitcoin transaction batching. https://www. coinbase.com/blog/reflections-on-bitcoin-transaction-batching, 2020. Accessed: 2026-06-23

    work page 2020

  17. [17]

    Cex & dex trading activity report 2026, 2026

    CoinGecko. Cex & dex trading activity report 2026, 2026. Accessed: 2026-03-24

    work page 2026

  18. [18]

    Top crypto exchanges ranked by trust score

    CoinGecko. Top crypto exchanges ranked by trust score. https: //www.coingecko.com/en/exchanges, 2026. Accessed: 2026-04-29

    work page 2026

  19. [19]

    Fast threshold ecdsa with honest majority

    Ivan Damg ˚ard, Thomas Pelle Jakobsen, Jesper Buus Nielsen, Jakob Illeborg Pagter, and Michael Bæksvang Østergaard. Fast threshold ecdsa with honest majority. InSecurity and Cryptography for Networks: 12th International Conference, SCN 2020, Amalfi, Italy, September 14–16, 2020, Proceedings, page 382–400, Berlin, Heidelberg, 2020. Springer-Verlag

    work page 2020

  20. [20]

    DefiLlama: Stablecoins

    DefiLlama. DefiLlama: Stablecoins. https://defillama.com/stablecoi ns, 2026. Accessed: 2026-04-24

    work page 2026

  21. [21]

    DefiLlama: Staking

    DefiLlama. DefiLlama: Staking. https://defillama.com/lsd, 2026. Accessed: 2026-04-24

    work page 2026

  22. [22]

    Morpho Blue whitepaper

    Mathis Gontier Delaunay, Paul Frambot, Quentin Garchery, Merlin Egalite, and Adrien Tabarly. Morpho Blue whitepaper. https://github .com/morpho-org/morpho-blue/blob/main/morpho-blue-whitepaper. pdf, 2023. Accessed: 2026-04-29

    work page 2023

  23. [23]

    Fireblocks: Digital asset custody and MPC wallet infras- tructure

    Fireblocks. Fireblocks: Digital asset custody and MPC wallet infras- tructure. https://www.fireblocks.com, 2026. Accessed: 2026-06-10

    work page 2026

  24. [24]

    Counterseveillance: Performance-counter attacks on amd sev- snp

    Stefan Gast, Hannes Weissteiner, Robin Leander Schr ¨oder, and Daniel Gruss. Counterseveillance: Performance-counter attacks on amd sev- snp. InNetwork and Distributed System Security (NDSS) Symposium 2025, 2025

    work page 2025

  25. [25]

    Axelar network: Connecting applications with blockchain ecosystems

    Sergey Gorbunov and Georgios Vlachos. Axelar network: Connecting applications with blockchain ecosystems. https://docs.axelar.dev/axel ar whitepaper.pdf, 2021

    work page 2021

  26. [26]

    Chainflip protocol whitepaper

    Simon Harman. Chainflip protocol whitepaper. https://assets.chainfli p.io/whitepaper.pdf, 2023. Fifth Revision. Accessed: 2026-04-29. 14

    work page 2023

  27. [27]

    Atomic cross-chain swaps

    Maurice Herlihy. Atomic cross-chain swaps. InProceedings of the 2018 ACM Symposium on Principles of Distributed Computing, PODC ’18, page 245–254, New York, NY , USA, 2018. Association for Computing Machinery

    work page 2018

  28. [28]

    Hyperlane: Permissionless interoperability for any blockchain

    Hyperlane. Hyperlane: Permissionless interoperability for any blockchain. https://docs.hyperlane.xyz, 2023. Accessed: 2026-04-29

    work page 2023

  29. [29]

    Intel Software Guard Extensions (Intel SGX) Developer Reference

    Intel Corporation. Intel Software Guard Extensions (Intel SGX) Developer Reference. https://www.intel.com/content/www/us/en/ developer/tools/software-guard-extensions/overview.html, 2023. Accessed: 2026-04-28

    work page 2023

  30. [30]

    Frost: Flexible round-optimized schnorr threshold signatures

    Chelsea Komlo and Ian Goldberg. Frost: Flexible round-optimized schnorr threshold signatures. InSelected Areas in Cryptography: 27th International Conference, Halifax, NS, Canada (Virtual Event), October 21-23, 2020, Revised Selected Papers, page 34–65, Berlin, Heidelberg, 2020. Springer-Verlag

    work page 2020

  31. [31]

    The $1.4 billion Bybit hack: Cybersecurity failures and the risks of cryptocurrency deregulation.International Journal of Cryptocurrency Research, 5(1):10–51483, 2025

    David Krause. The $1.4 billion Bybit hack: Cybersecurity failures and the risks of cryptocurrency deregulation.International Journal of Cryptocurrency Research, 5(1):10–51483, 2025

    work page 2025

  32. [32]

    Privana: A practical liquefaction implementation, April 2026

    Nino Kutnjak. Privana: A practical liquefaction implementation, April 2026

    work page 2026

  33. [33]

    Fast secure two-party ECDSA signing

    Yehuda Lindell. Fast secure two-party ECDSA signing. InAdvances in Cryptology – CRYPTO 2017, pages 613–644. Springer, 2017

    work page 2017

  34. [34]

    Accountable- subgroup multisignatures: extended abstract

    Silvio Micali, Kazuo Ohta, and Leonid Reyzin. Accountable- subgroup multisignatures: extended abstract. InProceedings of the 8th ACM Conference on Computer and Communications Security, CCS ’01, page 245–254, New York, NY , USA, 2001. Association for Computing Machinery

    work page 2001

  35. [35]

    Swap: A peer-to-peer protocol for trading ethereum tokens, 2017

    Michael Oved, Don Mosites. Swap: A peer-to-peer protocol for trading ethereum tokens, 2017

    work page 2017

  36. [36]

    Threshold signatures

    NEAR. Threshold signatures. https://github.com/near/mpc/tree/mai n/crates/threshold-signatures, 2026. Accessed: 2026-04-29

    work page 2026

  37. [37]

    Chain signatures

    NEAR Foundation. Chain signatures. https://docs.near.org/chain-abs traction/chain-signatures, 2026. Accessed: 2026-06-11

    work page 2026

  38. [38]

    Sapphire paratime, 2026

    Oasis Protocol Foundation. Sapphire paratime, 2026. Accessed Jan. 2026

    work page 2026

  39. [39]

    Particle network: Chain abstraction via universal accounts

    Particle Network. Particle network: Chain abstraction via universal accounts. https://whitepaper.particle.network, 2024. Accessed: 2026-06-11

    work page 2024

  40. [40]

    Polyhedra network zkbridge

    Polyhedra Network. Polyhedra network zkbridge. https://docs.zkbri dge.com/, 2023. Accessed: 2026-04-29

    work page 2023

  41. [41]

    Choosing the Right API

    Rango. Choosing the Right API. https://docs.rango.exchange/api-int egration/choosing-the-right-api#main-api-multi-step-txs. Accessed: 2026-06-10

    work page 2026

  42. [42]

    Rmpocalypse: How a catch-22 breaks amd sev-snp

    Benedict Schl ¨uter and Shweta Shinde. Rmpocalypse: How a catch-22 breaks amd sev-snp. InProceedings of the 2025 on ACM SIGSAC Conference on Computer and Communications Security, CCS ’25. Association for Computing Machinery, 2025

    work page 2025

  43. [43]

    Durable nonces

    Solana Foundation. Durable nonces. https://solana.com/docs/core/tra nsactions/durable-nonces, 2026. Accessed: 2026-04-28

    work page 2026

  44. [44]

    Bitcoin-enhanced proof-of-stake security: Possibilities and impossibilities

    Ertem Nusret Tas, David Tse, Fangyu Gai, Sreeram Kannan, Moham- mad Ali Maddah-Ali, and Fisher Yu. Bitcoin-enhanced proof-of-stake security: Possibilities and impossibilities. In2023 IEEE Symposium on Security and Privacy (SP), pages 126–145. IEEE, 2023

    work page 2023

  45. [45]

    Babylon: Reusing Bitcoin Mining to Enhance Proof-of-Stake Security

    Ertem Nusret Tas, David Tse, Fisher Yu, and Sreeram Kannan. Babylon: Reusing bitcoin mining to enhance proof-of-stake security. arXiv preprint arXiv:2201.07946, 2022

    work page internal anchor Pith review Pith/arXiv arXiv 2022

  46. [46]

    Supported protocols and integration guidelines

    Tether. Supported protocols and integration guidelines. https://tether .to/en/supported-protocols/, 2026. Accessed: 2026-04-29

    work page 2026

  47. [47]

    THORChain: A decentralised liquidity network

    THORChain. THORChain: A decentralised liquidity network. https: //github.com/thorchain/Resources/blob/master/Whitepapers/whitepa per-en.md, 2020. Accessed: 2026-04-29

    work page 2020

  48. [48]

    Universal atomic swaps: Secure exchange of coins across all blockchains

    Sri AravindaKrishnan Thyagarajan, Giulio Malavolta, and Pedro Moreno-Sanchez. Universal atomic swaps: Secure exchange of coins across all blockchains. In2022 IEEE symposium on security and privacy (SP), pages 1299–1316. IEEE, 2022

    work page 2022

  49. [49]

    ERC-20: Token Standard, November 2015

    Fabian V ogelsteller and Vitalik Buterin. ERC-20: Token Standard, November 2015

    work page 2015

  50. [50]

    Tdxdown: Single-stepping and instruction counting attacks against intel tdx

    Luca Wilke, Florian Sieck, and Thomas Eisenbarth. Tdxdown: Single-stepping and instruction counting attacks against intel tdx. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security, pages 79–93, 2024

    work page 2024

  51. [51]

    0x: An open protocol for decentralized exchange on the ethereum blockchain, 2017

    Will Warren, Amir Bandeali. 0x: An open protocol for decentralized exchange on the ethereum blockchain, 2017

    work page 2017

  52. [52]

    Wormhole messaging

    Wormhole Foundation. Wormhole messaging. https://wormhole.com /docs/products/messaging/overview/, 2022. Accessed: 2026-04-29

    work page 2022

  53. [53]

    zkbridge: Trustless cross-chain bridges made practical

    Tiancheng Xie, Jiaheng Zhang, Zerui Cheng, Fan Zhang, Yupeng Zhang, Yongzheng Jia, Dan Boneh, and Dawn Song. zkbridge: Trustless cross-chain bridges made practical. InProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pages 3003–3017, 2022

    work page 2022

  54. [54]

    Ciphersteal: Stealing input data from tee-shielded neural networks with ciphertext side channels

    Yuanyuan Yuan, Zhibo Liu, Sen Deng, Yanzuo Chen, Shuai Wang, Yinqian Zhang, and Zhendong Su. Ciphersteal: Stealing input data from tee-shielded neural networks with ciphertext side channels. In 2025 IEEE Symposium on Security and Privacy (SP), pages 4136–

    work page 2025

  55. [55]

    Layerzero, 2025

    Ryan Zarick, Bryan Pellegrino, Isaac Zhang, Thomas Kim, and Caleb Banister. Layerzero, 2025

    work page 2025

  56. [56]

    Zengo: The MPC crypto wallet

    Zengo. Zengo: The MPC crypto wallet. https://zengo.com, 2026. Accessed: 2026-06-10

    work page 2026

  57. [57]

    Cross-chain bridges: Attack taxonomy, defenses, and open problems

    Mengya Zhang, Xiaokuan Zhang, Yinqian Zhang, and Zhiqiang Lin. Cross-chain bridges: Attack taxonomy, defenses, and open problems. InRAID 2024, 2024. 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 de- ployed Crossroa...

    work page 2024