BEP-3 Atomic Swap Standard

BEP-3 defines a protocol for atomic swaps on BNB Chain, allowing two parties to exchange native or BEP-2 assets across different blockchains without a centralized intermediary. The standard specifies the exact mechanics of a Hash Time-Locked Contract (HTLC), which uses a cryptographic hashlock and a timelock to guarantee that the swap either completes fully for both parties or refunds both parties after a timeout. This eliminates counterparty risk in cross-chain trading.

The specification mandates a strict sequence of actions: one party initiates the swap by creating an HTLC containing a hash of a secret, the other party claims the funds by revealing the secret, and if the secret is not revealed before the deadline, the original depositor can reclaim their assets. For builders, implementing BEP-3 correctly requires precise handling of the sha256 preimage, the absolute timelock, and the cross-chain message format defined in the standard. A mismatch in any of these parameters between the two chains can lead to a permanent loss of funds or a failure to complete the swap.

Wallets, DEXs, and cross-chain application developers integrating native atomic swap functionality must implement BEP-3's HTLC interface. The standard's security model depends entirely on the correctness of the timelock and hashlock logic, making it a critical target for formal verification and security review. Chainscore Labs can review HTLC implementations for edge cases in timelock validation, secret management, and cross-chain compatibility to prevent fund-locking vulnerabilities.

BEP-3 defines a Hash Time-Locked Contract (HTLC) as the foundational primitive for trustless cross-chain asset exchanges on BNB Chain. The mechanism binds two parties across independent ledgers without requiring a centralized intermediary. An initiator locks assets into a contract on BNB Chain, generating a cryptographic hash of a secret s. A counterparty on the other chain can then lock their assets using the same hash. The swap completes atomically: if the initiator reveals the secret s to claim the counterparty's assets, the counterparty can extract s from that transaction and use it to claim the BNB Chain side. If either party abandons the swap, timelocks ensure assets are refundable after a predefined expiry, preventing permanent capital loss.

The contract logic enforces two critical constraints. The hashlock requires the claimant to provide a preimage that hashes to the agreed-upon value, ensuring only the secret holder can unlock the funds. The timelock creates a race condition where the claim must occur before a block height or timestamp deadline. On BNB Chain, the HTLC implementation uses SHA-256 for hashing and supports both native BNB and BEP-2/BEP-20 tokens, with the contract address acting as an escrow. Operators must carefully configure the timelock delta between the two chains to account for block time variance and confirmation latency, ensuring the initiator has sufficient time to reveal the secret on the counterparty chain before the BNB Chain refund window opens.

Builders integrating BEP-3 HTLCs must handle several operational edge cases. If a contract is deployed with an insufficient timelock delta, the initiator risks losing the secret without claiming the counterparty's assets—a partial-fill scenario that breaks atomicity. Wallets and DEX interfaces must monitor both chains for Claimed and Refunded events to correctly update user balances and prevent double-spend attempts. Chainscore Labs can review HTLC implementations for timelock parameter safety, hashlock collision resistance, and cross-chain event monitoring logic to ensure atomic swap integrations remain secure under mainnet conditions.