{"id":"89473f91-39a1-4313-b2f2-43ae6e99f3bf","arxiv_id":"2607.06525","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":3,"one_line_summary":"Crossroads unifies cross-chain assets as ERC-20 tokens on a single backend blockchain using threshold-signature custody and pluggable oracles, with a formal soundness proof guaranteeing users can always withdraw their net balance.","lead":"Crossroads is a system that represents assets from any blockchain as ERC-20 tokens on a single backend chain, enabling cross-chain smart contracts. A smart generalist might read it to understand how fragmented blockchain ecosystems could be unified under one programmable layer.","discovery_kind":"unclear","skeptic_critique":{"model":"glm-5.2","headline":"The soundness proof's Part 2 discharge assumes all spends from the encumbered address go through CanSign, but the Bitcoin integration (§6.3) introduces a consolidation signing path with a separate authorization check not covered by the proof, creating a gap between the proven base construction and t","rationale":"The reader correctly identifies committee liveness as a load-bearing assumption and the CONDITIONAL verdict is appropriate. However, the liveness concern is explicitly assumed in §5.1 and is standard in threshold cryptography literature—it represents a practical limitation rather than a formal gap in the proof. I identify a more specific concern: the proof's Part 2 discharge relies on the claim that 'every honest signer checks CanSign before producing a share,' but the Bitcoin integration (§6.3) introduces a consolidation signing path with a different authorization predicate that the proof does not cover. This creates a formal gap between the proven base construction (§3, Figure 3) and the implemented Bitcoin system. The paper is honest that optimizations 'do not require modification of the core Crossroads protocol,' but consolidation for Bitcoin is presented as necessary rather than optional, blurring the line between core protocol and optimization. The concrete test—formally verifying the consolidation check preserves the on-chain balance invariant—would determine whether this gap is merely an omission in the proof's scope or an actual soundness vulnerability. If the consolidation check is sound, the proof can be straightforwardly extended; if not, Theorem 3 does not apply to the Bitcoin integration as described. Either way, the CONDITIONAL verdict stands: the system is well-designed with a structurally correct proof for the base construction, but the gap between proof and implementation, combined with the liveness assumption and the DoS mitigations being outside the proven construction, justifies conditional rather than full acceptance. The paper's independent support—public code, working proof-of-concept across three heterogeneous chains, and concrete cost evaluations—counts as real evidence, but does not discharge the formal gap.","tokens_in":25147,"tokens_out":10699,"duration_ms":774318,"concrete_test":"Formally specify the consolidation authorization check for the Bitcoin asset contract (the 'net deposit to encumbered account' predicate referenced in §6.3) and verify that any transaction satisfying this check preserves OnChain(chain) ≥ Σ N_acct. Concretely: enumerate all valid input/output combinations for a consolidation transaction spending the current encumbered UTXO, and confirm that none can result in a net decrease of the encumbered address's balance while passing the consolidation check. If a combination exists where the encumbered address's output value is less than its input value (net withdrawal disguised as consolidation), Part 2's invariant breaks and Theorem 3 does not extend to the Bitcoin integration as described.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The proof of Theorem 3 (Appendix B, Part 2) discharges its key assumption—that every spend from the encumbered address corresponds to a ConfirmWithdrawal—by arguing: 'In Π_TSS_SC, every honest signer checks CanSign before producing a share, so no honest share on an unauthorized transaction is ever issued by the signing committee.' This holds for the base construction specified in Figure 3, where the Sign operation's only authorization path is crsrds.CanSign. However, the Bitcoin integration (§6.3) requires a consolidation signing path: '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 check, distinct from CanSign (which verifies PW ≥ amt+fee and RW ≥ r). The proof does not address this path. If the consolidation authorization can be satisfied by a transaction that net-decreases the encumbered address balance (e.g., through a crafted input/output combination that passes the net-deposit check but still extracts value), then an unauthorized spend could occur without EUF-CMA forgery, breaking the Part 2 invariant OnChain(chain) ≥ Σ N_acct. This is not a hypothetical optimization: the paper states consolidation is necessary for Bitcoin ('We remedy this by requiring depositors to perform the UTXO consolidation'), making it part of the deployed system rather than an optional add-on. The reader's liveness concern (§5.1) is also valid but is explicitly assumed and standard in threshold cryptography; the consolidation-path gap is a more specific formal omission between what is proven and what is implemented.","agreement_with_reader":"partial"},"referee_report":{"model":"glm-5.2","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.","tokens_in":25912,"tokens_out":1334,"duration_ms":321328,"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":[{"comment":"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 ","section":null}],"minor_comments":[{"comment":"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.","section":null},{"comment":"§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.","section":null},{"comment":"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.","section":null},{"comment":"§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.","section":null},{"comment":"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).","section":null},{"comment":"§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.","section":null},{"comment":"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.","section":null},{"comment":"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.","section":null}],"recommendation":"major_revision","confidential_remarks":"The stress-test concern about the Bitcoin consolidation path (§6.3) creating a gap in the soundness proof is well-founded and is the primary reason for the major revision recommendation. The proof in Appendix B is correct for the base construction (Figure 2 + Figure 3), but the Bitcoin integration introduces a second signing authorization path that is not covered. This is fixable: the authors need to either (a) extend the proof to cover the consolidation path, showing that the net-deposit check preserves the on-chain balance invariant, or (b) clearly scope the theorem to the base construction and treat the consolidation path as an implementation detail requiring separate analysis. Option (a) is preferable. The reader's concern about committee liveness (§5.1) is also valid but less load-bearing: the paper does state the liveness requirement explicitly, and the soundness definition only guarantees valid broadcast, not inclusion. However, the authors should clarify that liveness is an assumption, not a derived property."},"author_rebuttal":{"model":"glm-5.2","summary":"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.","responses":[{"response":"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_made":"no","referee_comment":"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)"}],"tokens_in":24609,"tokens_out":715,"duration_ms":75374,"standing_objections":["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."]},"desk_editor":{"model":"glm-5.2","letter":"Crossroads is a genuinely new composition: a backend-chain-enforced key encumbrance policy that makes cross-chain asset custody programmable and permissionless to extend. The individual pieces (threshold signing, ERC-20 wrapping, hub-and-spoke, intent-based fills) are all known, but the specific composition—where the signing committee's authorization is driven by an on-chain contract's CanSign check—is not something I've seen elsewhere, and it's a meaningful design contribution. The paper ships a working proof-of-concept across Bitcoin, Ethereum, and Solana with public code, concrete cost tables, and signing latency measurements. The soundness proof (Theorem 3, Appendix B) is structured cleanly: the invariant bal+PW = Net by induction on the transcript is correct for the contract as specified in Figure 2, and the constructive withdrawal sequence in Part 3 is sound under the stated assumptions. The proof is parameterized by standard primitives (EUF-CMA secure TSS, DKG from Boneh-Shoup) and doesn't reduce to a self-defined result, so there's no circularity concern. Credit where it's due—this is real formal work backed by a real implementation, not just a position paper. The reader's liveness concern (Section 5.1: if the committee goes offline, users can't withdraw) is valid but standard in threshold cryptography. The paper states the assumption explicitly, and it's the same assumption every MPC custody system makes. I wouldn't weight this heavily. The more substantive issue is the stress-test point about the Bitcoin consolidation path. In §6.3, the paper introduces a second signing authorization for Bitcoin: anyone can request signatures spending the encumbered UTXO, provided the transaction results in a net deposit to the encumbered account. This is a distinct authorization check from CanSign, which is what the proof's Part 2 discharge relies on. The proof argues that every spend from the encumbered address goes through CanSign, but the consolidation path violates that assumption. The net-deposit requirement probably preserves the on-chain balance invariant in practice, but the proof doesn't establish this. Since the paper says consolidation is necessary for Bitcoin—not optional—this is a gap between the proven system and the deployed one. It's addressable: either extend the proof to cover the consolidation path, or argue the net-deposit check preserves the Part 2 invariant. The other concern worth flagging is that the Section 4 optimizations (intent-based fills, parallel addresses) change the withdrawal flow, and the paper doesn't explicitly state whether Theorem 3 extends to the optimized system. This is minor—the optimizations bypass the encumbered address entirely or add parallel addresses, so they don't obviously break the invariant—but it should be stated. Overall: this is a well-executed paper with a real implementation and a correct proof for its base construction. The consolidation-path gap is the main thing a referee should push on. The paper is for researchers and practitioners in cross-chain interoperability and threshold custody. It deserves a serious referee.","headline":"Solid systems paper with a clean soundness proof for the base construction, but there's a real gap between what's proven and the Bitcoin integration.","tokens_in":25970,"tokens_out":1689,"would_cite":false,"duration_ms":154457,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"glm-5.2","headline":"Crossroads: Any blockchain asset becomes a programmable ERC-20","keywords":["chain abstraction","cross-chain bridge","threshold signatures","key encumbrance","ERC-20","smart contracts","blockchain interoperability","non-custodial"],"falsifier":"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.","tokens_in":25093,"feed_emoji":"🌉","tokens_out":1287,"duration_ms":151637,"temperature":0.7,"pith_summary":"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.","feed_headline":"Threshold committee lets any chain's assets trade as ERC-20s","feed_subtitle":"Crossroads unifies cross-chain assets on one programmable backend, with a proof that users can always withdraw — if the committee stays live","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["Key encumbrance splits chain logic from threshold signing in Crossroads","Crossroads: threshold committee signs only what backend ERC-20s authorize","Encumbered-key committee keeps chain-abstracted assets withdrawable","Crossroads proves withdrawals hold if signing quorum stays honest","Backend ERC-20s govern assets; threshold committee signs on authorization"],"cache_read_input_tokens":0,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Key encumbrance splits chain logic from threshold signing in Crossroads","Crossroads: threshold committee signs only what backend ERC-20s authorize","Encumbered-key committee keeps chain-abstracted assets withdrawable","Crossroads proves withdrawals hold if signing quorum stays honest","Backend ERC-20s govern assets; threshold committee signs on authorization"]},"model":"glm-5.2","effort":"high","cost_usd":0.0,"raw_usage":{"total_tokens":765,"prompt_tokens":675,"completion_tokens":90,"prompt_tokens_details":null},"tokens_in":675,"tokens_out":90,"duration_ms":14628,"temperature":1.0,"reasoning_tokens":null,"cache_read_input_tokens":0,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-08T02:51:09.638037+00:00","model_set":{"reader":"glm-5.2"},"falsifier":"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.","supporting_citations":[],"review_version":1}