Not all atomic swaps are created equal
May 07, 2026
Zenith allows EVM applications to atomically compose with Canton-native assets and applications, and for this it relies on true, consensus-based atomicity: Zenith EVM uses Canton's consensus mechanism to coordinate and settle transactions as a single, indivisible operation.
In contrast, Hashed Timelock Contracts (HTLCs), the mechanism behind many cross-chain "atomic” swaps, deliver something fundamentally different. HTLCs provide economic atomicity enforced at the smart contract layer, with settlement still dependent on distinct consensus mechanisms.
In this article, we break down the differences and bring clarity to what "atomic" actually means in these different contexts.
Two flavors of "atomic"
The term "atomic" is often used quite flexibly, describing different mechanisms, and blurring the distinctions that matter most.
Economic atomicity, implemented using hashed timelock contracts, operates at the smart contract layer. It guarantees that a swap either completes in full or not at all, but both legs of the transaction still settle on their respective chains, through their own consensus mechanisms and at their own finality times.
Consensus-level atomicity operates at the protocol layer. Both legs of a transaction are processed within the same single consensus mechanism, and committed (or rejected) as a single, indivisible operation. There is no reliance on timelocks or cryptographic escrow to enforce the outcome. The protocol itself guarantees it.
This is not a minor semantic distinction. It has significant implications for finality, latency, security, and composability.
How HTLCs work
Hashed timelock contracts are the foundational mechanism behind many cross-chain atomic swaps. The concept was proposed by early Bitcoin developers who combined hashlocks and timelocks into a conditional payment. This has since been widely adopted, and Chainlink, for instance, provides a detailed explainer on how they enable peer-to-peer asset exchange across separate blockchain networks.
Here is how a typical HTLC-based cross-chain swap works:
Alice (on chain A) and Bob (on chain B) agree to swap tokens.
Alice generates a secret and computes its cryptographic hash, and then deploys a timelock smart contract on chain A and deposits her tokens into it. The contract is locked with the hash, only someone who knows the original secret can claim the funds. If unclaimed, the tokens return to Alice after a set timeout.
Bob sees Alice's hash (but not the secret) and deploys a matching timelock contract on chain B (with a shorter timelock than Alice), depositing his tokens into it. His contract uses the same hash. Both parties have now locked their assets into their contracts on their respective chains.
Alice claims Bob's tokens on chain B by revealing the secret. This reveal is now visible on-chain.
Bob uses the revealed secret to claim Alice's tokens from the contract on chain A.
If either party fails to deposit or claim within their respective timelock window, the contracts revert and all tokens return to their original owners.
Swaps through hashed timelock contracts are "atomic" only in the economic sense: if the protocol is followed honestly, both parties receive their tokens or neither does. It is an all-or-nothing outcome at the application layer.
But the settlement of this swap is not atomic. Alice's claim transaction settles on chain B’s consensus. Bob's claim transaction settles on chain A’s consensus. These are two entirely separate finalization processes. At no point does a single consensus mechanism process both legs of the operation. The "atomic" guarantee is a property of the smart contract logic, not of the underlying settlement.
The disadvantages and attack vectors of HTLCs
While HTLCs provide useful economic guarantees for cross-chain exchange, they carry significant structural weaknesses that stem from their reliance on timelocks, independent consensus mechanisms, and game-theoretic assumptions.
Finality is gated by the slowest chain
An HTLC-based swap is only as fast as the slowest network involved. Both parties must wait for sufficient confirmations on both chains before the swap can be considered final. If one chain has slow block times, high congestion, or probabilistic finality (as Ethereum does under certain conditions), the entire swap's finality timeline stretches accordingly. This makes HTLCs poorly suited for any interaction that requires tight timing or rapid settlement.
Timelocks create impractical latency
Timelock durations must be set conservatively to account for network delays, block time variance, and the need for sufficient confirmations. In practice, this means timelock windows are often measured in hours. For trading, DeFi interactions, or any workflow requiring responsiveness, this latency makes HTLC-based swaps effectively impractical. The time between initiating and completing a swap is dominated by waiting, not by execution.
Chain reorgs undermine finality assumptions
On chains with probabilistic finality, including Ethereum, block reorgs can retroactively alter transaction history. A claim transaction that appeared confirmed may be unwound by a reorg, even after the counterparty has already acted on the assumption that the swap completed. HTLCs have no built-in mechanism to handle this. The timelock may have expired, the secret may have been revealed, and yet the settlement on one chain could still be reversed. This creates a window of genuine settlement risk that no amount of smart contract logic can close.
Griefing attacks lock capital without cost
One of the most studied attack vectors against HTLCs is the griefing attack. A malicious party initiates a swap, locks the counterparty's capital, and then deliberately refuses to complete their side. The honest party's tokens remain frozen until the timelock expires. The attacker pays nothing beyond the gas cost of the initial transaction.
Denial-of-service attacks can trigger timeouts
If an attacker can prevent a party from submitting their claim transaction, through network-level DDoS or flooding the RPC endpoint, the timelock will expire and the swap will fail. The honest party loses no tokens (they revert), but the swap itself is sabotaged. In high-value or time-sensitive contexts, the failure to swap can cause significant damage as well.
The free option problem
HTLCs create an inherent asymmetry in favor of the party who generated the secret, who in our example is Alice. After both parties have locked their assets, Alice has the full duration of Bob’s timelock window to decide whether to reveal the secret and complete the swap. If the price moves unfavorably, she simply does nothing, both timelocks expire, both sides revert, and Alice walks away. Bob, having already locked his tokens, has no such optionality. He is committed from the moment he deposits and can only wait. In volatile markets, this effectively gives Alice a free option at Bob's expense.
True atomicity across Canton and Zenith EVM
Zenith takes a fundamentally different approach. Zenith embeds EVM execution within Canton's consensus, achieving true atomic composability at the protocol level.
The external_call() primitive
Atomic interaction, including swaps as well as multi-leg DFi operations between Zenith EVM and Canton is enabled by the external_call() primitive, implemented by Zenith in Daml. This function allows Daml contracts to invoke the EVM execution environment deterministically within the same Canton transaction.
Here is how a cross-environment transaction flows:
Submission: A user submits a native Canton transaction that includes a wrapped EVM transaction payload alongside the corresponding Daml operations.
Invocation: The Daml contract processes the transaction, invokes external_call(), and forwards the EVM payload to the locally running Reth-based EVM runtime.
Native EVM execution: The Canton participant operates in a dual role, as a Canton node and as the Zenith EVM operator. The EVM transaction is natively executed with sequential, single-threaded semantics consistent with Ethereum, and a new EVM state root is produced.
Deterministic validation: Zenith relies on Canton's native two-step validation model.
The submitter executes the external_call() during interpretation and includes the result in the transaction view.
Every other Canton validator in the domain independently re-executes the same call.
If any validator obtains a different result, the entire transaction is rejected.
Atomic settlement: Because both the Canton leg and the EVM leg are part of the execution tree of the same Canton transaction, either both succeed or the entire transaction fails. Finality is confirmed back to the user once the combined transaction is validated.
What this means in practice
The external_call() primitive follows Canton's native validation model and introduces no additional trust assumptions. There is no timelock. There is no window where one leg has settled and the other hasn't. The outcome doesn't depend on both parties acting rationally or honestly, the protocol itself guarantees that both legs either commit together, or not at all.
The EVM execution adds only a few hundred milliseconds of latency to the overall Canton transaction, a negligible overhead compared to the potentially long timelock windows of HTLC-based swaps.
Summary
The differences can be summarized as follows:
Closing thoughts
As we’ve seen, not all atomic swaps are created equal. When someone says "atomic", it’s worth asking: atomic at what layer?
The answer determines whether you're getting a promise that depends on both parties behaving rationally within a set of timelock-enforced rules, or a genuine, protocol-level guarantee that your transaction either fully executes or never happens at all.
