Cross-chain Deals and Adversarial Commerce

1. INTRODUCTION

• Cross-chain deals require safety and liveness notions that protect against cheating, prolonged asset lockup, and double-spending.Classical transaction atomicity cannot be guaranteed against malicious parties; cross-chain commerce instead relies on liveness to prevent assets being locked indefinitely.Source: §1 · pp. 1–2

1.1 System Models

• The paper presents a decentralized timelock protocol for synchronous communication and a more centralized certified blockchain protocol for other communication conditions.Semi-synchronous models avoid explicit timeouts but require greater centralization; the authors sketch that tolerating asynchrony requires a shared ledger.Source: §1 · p. 2, §1.1 · p. 2

1. INTRODUCTION

• Adversarial commerce challenges crash-only assumptions and global all-or-nothing guarantees, motivating a deal abstraction for exchanges among autonomous parties.Deals exchange assets, unlike transactions that perform distributed state changes, and parties may deviate arbitrarily from the protocol.Source: §1 · pp. 1–2

1.2 Other Approaches

• Cross-chain swaps support only simple unconditional transfers, while trusted crypto exchanges provide no guarantees, according to the paper.Swaps cannot express indirect transfers or conditional exchanges such as auctions.Source: §1.2 · p. 2

1.3 Example

• The ticket-broker example asks a protocol to transfer tickets and coins across separate blockchains while ensuring honest parties are no worse off if something goes wrong.Alice brokers tickets from Bob to Carol and receives a commission from the coin transfer.Source: §1.3 · p. 2

1.4 Cross-Chain Deals vs. Cross-chain Swaps

• Cross-chain deals can express brokered, conditional, and arbitrage-like exchanges that unconditional cross-chain swaps cannot support.Examples include relaying assets a broker does not initially own and auctions whose outcome depends on submitted bids.Source: §1.2 · p. 2, §1.4 · p. 3

2.1 Specifying the Deal

• A deal’s payoff is represented as a matrix whose rows list outgoing transfers and columns list incoming transfers, allowing parties to assess their proposed exchanges.Source: §2.1 · p. 3, Table 1 · p. 3

2.2 Correctness

• The model distinguishes compliant from deviating parties and assumes no bound on how many parties may deviate.Source: §2.2 · p. 3
• Every compliant party must receive an acceptable payoff despite arbitrary deviations; acceptable outcomes can include application-defined partial transfers.Source: §2.2 · pp. 3–4
• Weak liveness requires that no asset belonging to a compliant party remain escrowed forever.Source: §2.2 · p. 4
• Strong liveness requires that all transfers occur when every party complies, accepts the proposed payoff, and communication is synchronous.Source: §2.2 · p. 4

• Each independent blockchain publicly records ownership of fungible or non-fungible assets, and the model assumes value transfers are represented on-chain.Source: §3 · p. 4
• Contracts can escrow assets and either transfer them to a counterparty or refund the original owner, but cannot directly access outside data or call contracts on other blockchains.Source: §3 · p. 4
• Contracts are public and deterministic, whereas parties are active, autonomous, and potentially dishonest; messages use signatures and nonces.Source: §3 · p. 4

4. HOW CROSS-CHAIN DEALS WORK

• The deal state tracks asset owners under both commit and abort outcomes; escrow makes the contract the current owner while preserving the intended ownership for either outcome.Source: §4 · pp. 4–5

4.1 Phases

• Execution proceeds through clearing, escrow, tentative transfers, validation, and commit, with each party checking that its payoff is acceptable before voting.Source: §4.1 · p. 5
• Unlike classical two-phase commit, adversarial commerce requires application-specific checks because each party alone decides whether its incoming assets and payoff are acceptable.Source: §4.1 · p. 5
• Escrow and commit must work together to prevent double-spending, protect compliant parties’ assets from indefinite locking, and resist maliciously inconsistent outcomes.Source: §4.1 · p. 5
• The protocols integrate escrow management with commit and make different trade-offs between decentralization and fault tolerance across synchronous and semi-synchronous models.Source: §4.1 · p. 5

5. TIMELOCK PROTOCOL

• A vote’s allowed arrival time grows with its forwarding path, and path signatures record the signers so contracts can verify forwarded votes.A vote with path signature p must arrive within |p| · ∆ of the commit start time.Source: §5 · p. 6

5.1 Running the Protocol

• Contracts release escrow after accepting every party’s commit vote; if votes are missing by t0 + N · ∆, they refund the original owners.Source: §5.1 · p. 6

5.2 Well-formed Deals and Decentralization

• Compliant parties send votes to contracts for incoming assets and forward other parties’ votes, so no single blockchain must be accessed by everyone.Source: §5.2 · pp. 6–7

5.3 What Could Possibly Go Wrong?

• When Alice stops communicating with Bob but continues with Carol, Bob can recover his coins while Carol completes her exchange; Alice, the deviator, pays without being paid.Source: §5.3 · p. 7

5.4 Correctness

• The protocol satisfies safety and weak liveness; it also satisfies strong liveness when all parties comply and the deal is well-formed.Well-formed deals have strongly connected digraphs, allowing commit votes to reach all contracts in time.Source: §5.4 · p. 7
• If parties are driven offline before forwarding votes, another party can claim both sides; the paper recommends sufficiently large ∆ or watchtowers as countermeasures.Source: §5.4 · p. 7

6. CBC PROTOCOL

• The CBC records and orders deal-wide commit or abort votes; its shared-log design is not decentralized, and the paper argues asynchrony tolerance makes that loss inevitable.A party presents a proof of commit or abort to an asset contract, which checks it before transferring assets or issuing refunds.Source: §6 · p. 7

6.1 Running the Protocol

• The protocol starts the deal on the CBC, escrows outgoing assets, makes tentative transfers, validates payoffs, and records each party’s commit or abort vote.Parties may vote to abort if validation fails or too much time has passed.Source: §6 · p. 7, §6.1 · p. 8

6.2 What Could Possibly Go Wrong?

• Even when all parties vote to commit, deviating behavior can prevent an all-or-nothing outcome; both protocols ensure only that compliant parties cannot end up worse off.For example, a deviating party can send more than the expected amount, leaving a compliant party with an intermediate outcome.Source: §6.2 · p. 8

6.3 Correctness

• CBC safety follows because compliant parties agree on commit or abort; weak liveness lets parties eventually abort when assets remain locked too long, while strong liveness holds during synchronous periods.During synchronous periods, every party votes to commit before any party votes to abort.Source: §6.3 · p. 8

6.4 Cross-Chain Proofs

• Passive asset contracts need a verifiable CBC history to determine the deal outcome, such as a block sequence ending at the decisive vote.A contract must establish that presented blocks really belong to the CBC.Source: §6.4 · p. 8

6.5 Byzantine Fault-Tolerant Consensus

• With BFT consensus, validator signatures certify blocks, but full proofs can be costly to check; status certificates can shorten proofs unless validator reconfiguration requires a chain of validator sets.The described certificate uses at least f + 1 validator signatures, with an initial validator set supplied to the asset contracts.Source: §6.5 · pp. 8–9

6.6 Proof-of-work (Nakamoto) Consensus

• Proof-of-work CBC proofs lack finality and can be contradicted; confirmation requirements make contradictory proofs more expensive but slow and complicate resolution, unlike final BFT certificates.The required difficulty should track deal value, so high-value deals take longer to resolve.Source: §6.6 · p. 9

7.1 Gas Costs

• Escrow costs O(m), transfers cost O(t), and validation is local and incurs no gas cost.The analysis uses an Ethereum-inspired model, and costs for non-proof-of-work blockchains are described as likely similar.Source: §7.1 · p. 9, §7 · p. 9
• Timelock commit incurs O(mn2) global gas cost, with O(n2) signature verifications per contract in the worst case; CBC incurs O(m(f + 1)) signature verifications plus a constant number of storage writes.In the worst case, aborting can cost almost as much as committing.Source: §7.1 · p. 10

7.2 Time Costs

• When all parties conform, escrow takes at most ∆ and transfers at most k · ∆, or ∆ if transfers run concurrently; validation is immediate.These bounds apply to both protocols.Source: §7.2 · p. 10
• Timelock commit duration is bounded by n∆, while CBC votes arrive quickly under BFT consensus and contracts need at most another ∆ to transfer or refund assets.The timelock bound applies when votes are sent only to blockchains managing incoming assets.Source: §7.2 · p. 10

8. RELATED WORK

• Cross-chain swaps lack the expressive power for brokerage deals, auctions, and other conventional financial transactions.Herlihy’s generalized swap protocol covers multi-party swaps on strongly connected directed graphs, while deals let parties specify whether partial outcomes are acceptable.Source: §8 · p. 11
• Zakhary et al.’s proof-based commitment protocol supports unconditional swaps, not full deals, because intended transfers must be registered at the start.Source: §8 · p. 11
• Off-chain payment networks and state channels use hashed timelocks for repeated off-chain transactions, but their applicability to cross-chain deals remains open.Arwen is specialized to currency trading and does not appear to support non-fungible assets.Source: §8 · p. 11
• Sharded-blockchain transactions support cross-shard atomicity but treat a transaction as one trusted party, not a transaction among untrusted parties.Channels extends this setting to atomic single-step multi-party UTXO transfers, but not multi-step deals or non-fungible assets.Source: §8 · p. 12
• BAR-tolerant systems assume a bounded number of Byzantine faults, unlike adversarial deals, which allow any number of parties to be Byzantine.Source: §8 · p. 12
• Federated databases coordinated transactions across autonomous, mutually untrusting, heterogeneous stores, but did not tolerate arbitrary Byzantine behavior.Source: §8 · p. 12

9. DISCUSSION

• A party may escrow a deposit that it loses if it is first to cause deal failure, though incentive design remains ongoing research.Source: §9 · p. 12
• A too-small ∆ in the timelock protocol can let an extended denial-of-service attack cause parties to lose incoming assets.An attack on the CBC may instead lock deal assets for the attack’s duration, rather than lose them forever.Source: §9 · p. 12
• CBC validators can censor deals by selectively ignoring them, causing aborts where the deals otherwise could have committed.Source: §9 · p. 12
• With few participants, CBC commit costs more, but with many participants it may cost less than timelock commit.The cited signature-verification costs are O(m(f + 1)) for CBC and O(mn2) for timelock; CBC works under a more demanding timing model.Source: §9 · p. 12

10. CONCLUSIONS

• Adversarial commerce concerns commerce among autonomous parties who do not know or trust one another, while prior atomic transactions and cross-chain swaps are unsuitable for that trust model or limited in expressive power.Source: §10 · p. 12
• In adversarial commerce, each party decides whether to participate, and compliant parties must end no worse off despite arbitrary misbehavior by others.Correctness is local and selfish rather than an enforced common outcome.Source: §10 · p. 12
• Cross-chain deals address adversarial-commerce demands and should not be conflated with atomic transactions or cross-chain swaps.Source: §10 · p. 12