Progress On Atomic Swaps With Bitcoin Cash

We now have a working offline prototype for atomic swaps between EarthBucks (EBX) and Bitcoin Cash (BCH). The prototype constructs and signs transactions for both chains, completes swaps by revealing a shared secret, and exercises refunds when a swap does not finish. It uses simulated chains and test coins, not live networks or real funds. This is a substantial step toward EarthBucks Swap, but it is not a feature you can use in the app yet.

The goal is to let two people exchange EBX and BCH without handing their funds to an exchange operator. A service can help them find each other and agree on a price, while their wallets handle signing and settlement. The recent work establishes the transaction machinery and tests how that machinery behaves when things go wrong.

How the prototype swaps EBX for BCH

Suppose Alice has EBX and wants BCH. Bob has BCH and wants EBX. They agree on the amounts before committing funds.

Alice creates a secret and calculates its SHA256 hash. She shares the hash, but keeps the secret to herself. Both sides use that same hash in contracts that specify who can claim the funds and when a refund becomes possible. These are hash time-locked contracts, usually shortened to HTLCs.

The prototype follows this sequence:

1. Alice locks EBX in a contract that Bob can claim with the secret and his signature. Alice has a refund path after a deadline.
2. Bob checks Alice’s funding and waits for the required confirmations. He locks BCH in a corresponding contract that Alice can claim with the same secret and her signature. Bob’s refund deadline is earlier than Alice’s.
3. Alice checks Bob’s funding, then claims the BCH. Her claim transaction reveals the secret.
4. Bob’s wallet extracts the secret from Alice’s validated BCH claim and uses it to claim the EBX.

The important connection is that Alice reveals what Bob needs when she claims his BCH. Bob does not have to trust a message saying that she has paid him. His wallet can obtain the secret from the transaction itself.

The deadlines leave time for the other participant to respond. If the swap stops before settlement, refund paths allow the participants to recover their respective funds once the relevant deadlines mature, provided those funds have not already been spent. Refunds are transactions that must be submitted and confirmed; they are not automatic reversals.

Adding a shared hash function

The first implementation step was adding SHA256 to the EarthBucks TypeScript script interpreter. The swap contracts need a way to check the same secret commitment on both chains. SHA256 gives us that common operation.

This does not replace EarthBucks’ existing BLAKE3 transaction IDs or signature hashing. The change adds an operation that a script can use. The two chains keep their own transaction formats and signature rules.

I considered more complicated alternatives, including adaptor signatures and proofs connecting commitments made with different hash functions. Those approaches introduce additional cryptography and protocol work. For this first implementation, adding SHA256 and using explicit HTLCs was the more direct choice.

The next step was adding EarthBucks helpers for constructing the contracts and signing claims and refunds. The BCH library already supplied the corresponding building blocks. A separate swap library now coordinates the two sides while keeping each participant’s private keys and state separate.

Real transactions, simulated chains

The prototype uses native EBX and BCH transactions. Both libraries construct, sign and validate complete transactions against supplied test outputs and chain context. The successful swap extracts the secret from the actual serialized BCH claim transaction and uses it on the EBX side.

The simulation supplies the surrounding world: coins, blocks, confirmations, transaction delivery and network observations. That lets us advance the two chains independently and reproduce failures precisely.

This distinction matters. Local validation is useful evidence, but it does not prove that live nodes will accept a transaction or that a wallet has an accurate view of the network. The simulated EarthBucks chain explicitly admits the swap contracts. Admission by the real network remains work to qualify.

“Offline” here means a local simulation. It does not mean a payment channel or a way to settle the eventual swaps without blockchain transactions.

Testing the failures

The completed prototype qualification covered 29 deterministic scenarios, including more than the successful exchange. We tested abandonment before and after both sides fund, refunds before and after their deadlines, incorrect secrets, unauthorized signatures, mismatched terms and competing spends.

We also tested rejected broadcasts and uncertain broadcasts, where a wallet does not know whether its transaction reached the network. Those are different states from confirmation. A wallet must preserve enough information to retry or reconcile what happened without treating a missing response as proof that nothing happened.

Restart and reorganization scenarios test another important distinction: transaction history can change, but a revealed secret cannot become secret again. Once a participant learns it, the protocol must remember that knowledge even if the revealing transaction disappears from the accepted chain.

One scenario deliberately demonstrates loss. Bob goes offline after both sides fund. Alice claims the BCH, revealing the secret, but Bob remains offline until Alice can refund the EBX. Bob returns too late to claim it.

That result is part of the progress. It makes the availability requirement explicit. An atomic-swap wallet must monitor the chains and act within its recovery window. Calling a protocol “atomic” does not remove deadlines or guarantee safety through an arbitrarily long outage.

Bringing this into EarthBucks

EarthBucks Swap is intended to bring this process into the app: find a counterparty, review the amounts and conditions, commit funds, and follow the swap through settlement or recovery. The interface must make it clear when funds are committed and when action is required.

The architecture separates matching from custody. A centralized service can help match offers without holding the users’ funds. Wallets still need to check the agreed contracts and actual funding independently. The exact offer interface, identity presentation and relationship to messaging remain open product decisions.

The next work includes integrating the BCH wallet, obtaining reliable network observations, protecting recovery state across restarts, and qualifying the EarthBucks validation and network support needed for these contracts. The prototype can serialize participant state, but that alone does not provide durable, encrypted storage for a real wallet.

We also need to qualify the complete flow on real networks, including fees, confirmation timing and recovery. The offline test settings are tools for reproducible experiments, not recommended production deadlines.

The next milestone is a wallet-integrated swap flow that we can qualify against real networks. The working prototype gives us a concrete foundation for that work, along with a clearer understanding of the failures the finished product must handle.