Skip to main content

Xythum Instant: A 2-Party Co-signed Channel for 0-Confirmation Bitcoin Swaps

Created:2025-07-26

Abstract​

This specification proposes "Xythum Instant," a 2-party state channel protocol designed for 0-confirmation atomic swaps between Bitcoin and EVM-compatible chains. The protocol leverages a simple 2-of-2 Taproot multisignature address for holding channel funds. State transitions (swaps) are conducted off-chain by creating and exchanging signatures for Settlement Transactions. Each Settlement Transaction, if broadcasted, moves the channel funds into a secondary script that enforces the outcome of that specific state.

This script contains two branches: a relative timelocked path allowing the rightful owner to claim funds after a delay, and a punitive revocation path allowing the counterparty to sweep the funds if an outdated state is broadcast.

By exchanging revocation secrets before finalizing each state update, the protocol ensures that only the most recent state can be enforced on-chain without penalty, thus enabling the service provider (Xythum) to securely honor swaps instantly.

Motivation​

Bitcoin’s slow block times and six‑confirmation finality (about an hour) make BTC swaps clunky and risky, locking users into long waits and market volatility. Lightning is great for payments but not for instant DeFi swaps. Xythum Instant fixes this with a two‑party state channel: your pre‑signed, unbroadcasted BTC transaction lets us trigger the ETH swap immediately, while timelocks and penalty‑enabled revocations keep everyone honest combining exchange‑style speed with DeFi’s non‑custodial security.

Definitions​

  • User: The end-user wishing to perform a BTC-to-ETH swap.
  • Xythum:  protocol backend acting as the counterparty and facilitator for the swap.
  • Xythum Instant Wallet: A 2-of-2 multisignature Taproot address, where one key is controlled by the User and the other by Xythum. This is the primary address holding the user's funds.
  • Channel State: The agreed-upon balance distribution of the funds within the Instant Wallet. Each successful swap creates a new, numbered channel state.
  • Commitment Transaction (CT): A pre-signed but unbroadcasted Bitcoin transaction that spends the UTXO from the Instant Wallet. Each CT corresponds to a specific channel state. If broadcast, it sends the funds to a Commitment Address.
  • Commitment Address: A temporary Bitcoin address with a complex script. This script allows the User to claim funds after a timelock, but also allows Xythum to claim the funds immediately if it can provide a revocation secret.
  • Revocation Secret: A random 32-byte value (S). The User must reveal the secret Sk for a given state k in order to progress to state k+1. This arms Xythum with the ability to penalize the user if they attempt to broadcast the old CTk.
  • Justice Transaction: A transaction broadcast by Xythum that spends the funds from a Commitment Address using a revealed Revocation Secret. This transaction sweeps the entire channel balance to Xythum as a penalty against a fraudulent user.
  • Watchtower: A service run by Xythum that constantly monitors the Bitcoin blockchain for any broadcasted Commitment Transactions from its users.

Core Protocol Flow​

The protocol operates in three main phases: Initialization, Swapping (State Updates), and Exit.

  1. Initialization & Deposit:
    • The User's wallet and Xythum generate keys. They combine their public keys to create a 2-of-2 Taproot address for the Instant Wallet.
    • The User deposits BTC into this address. Let's call the resulting UTXO the funding_UTXO.
    • Immediately after the deposit is confirmed, the User and Xythum create and co-sign the first Commitment Transaction (CT0). This transaction spends the funding_UTXO and sends the full balance (minus miner fees) to a Commitment_Address_0. This address is locked with a 24-hour timelock for the User and a hashlock H(S0) for Xythum. The User holds onto the signed CT0. Xythum does not yet know the secret S0.
  2. Performing a Swap (State Update):

    • The User decides to swap X BTC for Y ETH. They send a signed SWAP_REQUEST to Xythum's backend.

    • To authorize this swap (which represents State 1), the User's client must first reveal the secret S0 to Xythum.

    • Xythum's backend verifies that H(S0) matches the hashlock from CT0. It now has the "key" to penalize the user if CT0 is ever broadcast.

    • Upon receiving S0, Xythum's backend:

      a. Instantly processes the Ethereum side of the swap, sending Y ETH to the user's specified address.

      b. Creates a new Commitment Transaction (CT1) reflecting the new balance (User Balance - X). This CT1 spends the same funding_UTXO.

      c. This new transaction's output is a Commitment_Address_1, which is locked with the same 24-hour timelock for the user but a new hashlock, H(S1), where S1 is a new secret only the user knows.

      d. Xythum co-signs CT1 and sends it to the user. The user's wallet stores CT1 and discards CT0.

    • The channel is now in State 1. This process repeats for every subsequent swap, with the user revealing Sn to get a signed CTn+1.

  3. Exit Mechanisms:
    • A) Cooperative Close (The Happy Path):
      • The User requests a withdrawal via an EXIT_REQUEST.
      • Xythum and the User collaboratively create and sign a final transaction that spends the funding_UTXO and sends the correct latest balances to the User's personal wallet and any remainder to a Xythum wallet.
      • This transaction is broadcast immediately, and the channel is closed. This is the fastest and cheapest exit method.
    • B) Unilateral Close (Forced Exit):
      • The User decides to exit without Xythum's cooperation (or Xythum is offline).
      • The User broadcasts their latest known Commitment Transaction, CTn.
      • Xythum's Watchtower detects CTn on-chain. It checks its database and confirms it does not possess the secret Sn. Therefore, this is a legitimate, non-malicious forced exit.
      • A 24-hour timelock begins. During this time, Xythum cannot claim the funds.
      • After the timelock expires, the User can broadcast a second transaction to claim their BTC from the Commitment_Address_n.
    • C) Malicious Close (Fraud Attempt):
      • A malicious User attempts to cheat by broadcasting an old Commitment Transaction, e.g., CTk, where k < n, to claim more funds than they are entitled to.
      • Xythum's Watchtower detects CTk on-chain.
      • The Watchtower checks its database and finds that it possesses the secret Sk (which the user revealed to get to state k+1).
      • The Watchtower immediately constructs and broadcasts a Justice Transaction. This transaction uses the secret Sk to satisfy the hashlock in the script of Commitment_Address_k, allowing Xythum to sweep 100% of the funds to its own wallet before the User's 24-hour timelock expires. This economic penalty secures the protocol.

Architectural Diagram​

image.png

Key & Address Generation​

To ensure security and manage countless user channels, all keys must be derived using a Hierarchical Deterministic (HD) wallet structure as defined in BIP-32.

  • User Keys: The user's wallet will generate a master seed. A dedicated derivation path should be used for the Xythum channel, for example: m/86'/0'/c', where 86' signifies Taproot (BIP-86), 0' is the Bitcoin coin type, and c' is the channel index, incrementing for each new channel a user might open. From this path, the user derives a private key (user_privkey) and corresponding public key (user_pubkey).
  • Xythum Keys: Xythum will maintain a master seed and use a similar derivation path to generate a unique key pair (xythum_privkey, xythum_pubkey) for each user channel. This prevents key reuse and isolates risk between channels.

The Xythum Instant Wallet (Funding Address)​

The address where a user deposits their initial funds is a Pay-to-Taproot (P2TR) output, defined in BIP-341. Its security relies on a 2-of-2 multisignature scheme implemented via the key-path spend.

  • Key Aggregation: The user's public key (user_pubkey) and Xythum's public key (xythum_pubkey) are aggregated into a single internal public key (internal_key) using a protocol like MuSig2.
    • internal_key = MuSig2.Aggregate([user_pubkey, xythum_pubkey])
  • Address Generation: The Bitcoin address is derived directly from this internal_key according to P2TR rules.
  • Script Path: Critically, this address has no script path. There are no scripts in its Taproot tree. This makes it indistinguishable from a standard single-owner Taproot address, providing maximum privacy and efficiency.
  • Spending Condition: Any transaction spending from this address requires a 64-byte Schnorr signature that is a valid aggregate signature from both the user and Xythum. This enforces the 2-of-2 multisig rule for all cooperative actions. This is the mechanism used for the Cooperative Close.

The Commitment Transaction (CT)​

A Commitment Transaction is the pre-signed "escape hatch" that allows a user to unilaterally exit the channel. A new, updated CT is created and signed for every state change (i.e., every swap).

  • Version: 2
  • Input(s):
    • Exactly one input: the funding_UTXO from the Instant Wallet.
    • nSequence: Set to 0xFFFFFFFF to disable any legacy timelocks.
  • Output(s):
    • Exactly one output: sending the entire balance of the funding UTXO (minus estimated miner fees) to a Commitment Address.
  • Locktime: 0

At any given time n, the user holds a valid, co-signed CTn, and Xythum holds the revocation secrets for all previous states (S0...Sn-1).

The Commitment Address & Script Tree​

This is the core of the protocol's security model. The Commitment Address is a P2TR address where the spending logic is contained entirely within its script path. The internal key for this address should be a NUMS (Nothing-Up-My-Sleeve) point, rendering the key-path unspendable.

The Taproot tree contains two scripts (leaves), representing the two possible ways to spend the funds sent by a Commitment Transaction.

image.png

Revocation Path (For Xythum's Justice Transaction) - LeafA​

This script allows Xythum to sweep all funds immediately if a user broadcasts a stale (revoked) Commitment Transaction.

# Witness Stack: <xythum_sig> <secret>
OP_HASH160
<H(secret_n)>  # The hash of the secret for state 'n' is hardcoded here
OP_EQUALVERIFY
<xythum_pubkey>
OP_CHECKSIG

• How it works: To spend via this path, Xythum's Watchtower must provide its signature and the correct secret_n. OP_EQUALVERIFY ensures the provided secret matches the one locked in the script. If it matches, the signature is checked, and the transaction is valid. There is no timelock on this path.

Leaf B: Timelock Path (For User's Forced Exit)​

This script allows the user to reclaim their funds after a pre-defined waiting period, giving Xythum's Watchtower time to detect fraud.

# Witness Stack: <user_sig>
<144>  # Relative timelock of 144 blocks (~24 hours)
OP_CHECKSEQUENCEVERIFY
OP_DROP
<user_pubkey>
OP_CHECKSIG

• How it works: The OP_CHECKSEQUENCEVERIFY opcode enforces a relative timelock. The input's nSequence field in the spending transaction must be >= 144. This means the user can only broadcast this spending transaction after the Commitment Transaction has been included in a block for at least 144 subsequent blocks.

The Justice Transaction​

This transaction is created and broadcast by Xythum's Watchtower in response to a malicious broadcast.

  • Input(s): One input, spending the UTXO created by the stale CTn.
  • Witness: The witness must satisfy the Revocation Path script:
    1. xythum_sig: A valid Schnorr signature from Xythum.
    2. secret_n: The revealed secret for the stale state n.
    3. The Taproot control block proving the existence of the revocation script in the tree.
  • Output(s): Sends the entire channel balance to a wallet controlled exclusively by Xythum.

The Timelocked Exit Transaction​

This transaction is created by the user to claim their funds after broadcasting the latest CTn and waiting for the timelock to expire.

  • Input(s): One input, spending the UTXO created by CTn.
    • nSequence must be set to 144 (or whatever the timelock value is).
  • Witness: The witness must satisfy the Timelock Path script:
    1. user_sig: A valid Schnorr signature from the user.
    2. The Taproot control block proving the existence of the timelock script in the tree.
  • Output(s): Sends the entire channel balance to a wallet controlled exclusively by the user.

Message Types & Structures​

Messages are presented here in a JSON-like format for clarity.. Every message requiring authorization MUST be signed. The signature is created over the canonical representation of the message payload.

8.1. MSG_INIT_CHANNEL (Client -> Server)​

Sent by the User Wallet to initiate the creation of a channel.

{
  "type": "MSG_INIT_CHANNEL",
  "payload": {
    "timestamp": 1753495200, // UTC seconds
    "user_pubkey": "02...", // User's BIP-32 derived pubkey for this channel
    "initial_deposit_sats": 5000000 // Proposed deposit amount in satoshis
  },
  "signature": "..." // User's signature on hash of payload
}```

8.2. ACK_INIT_CHANNEL (Server -> Client)​

Sent by Xythum to acknowledge the request and provide its public key and the final funding address.

{
  "type": "ACK_INIT_CHANNEL",
  "payload": {
    "user_pubkey": "02...", // The user's pubkey from the init message
    "xythum_pubkey": "03...", // Xythum's BIP-32 derived pubkey for this channel
    "funding_address": "bc1p...", // The final 2-of-2 P2TR funding address
    "channel_id": "ab34..." // A unique identifier for this channel
  }
}

No signature is needed as the user can independently verify the funding_address by combining the two public keys.

8.3. MSG_SWAP_REQUEST (Client -> Server)​

The core message to perform a swap. This message initiates the state update process by providing the next commitment's hashlock while simultaneously revealing the previous state's revocation secret.

{
  "type": "MSG_SWAP_REQUEST",
  "payload": {
    "channel_id": "ab34...",
    "state_number": 1, // The new state number we are proposing (n)
    "amount_btc_sats": 100000, // Amount of BTC user is swapping
    "dest_eth_address": "0x...", // User's destination Ethereum address
    "next_commitment_hash": "a1b2...", // H(Secret_n) for the *new* state
    "prev_revocation_secret": "c3d4..." // Secret_n-1 for the *previous* state
  },
  "signature": "..." // User's signature on hash of payload
}

8.4. ACK_SWAP_SIGNED (Server -> Client)​

Sent by Xythum after it has processed the ETH side of the swap. It contains the co-signed Commitment Transaction for the new state.

{
  "type": "ACK_SWAP_SIGNED",
  "payload": {
    "channel_id": "ab34...",
    "state_number": 1, // The state number being acknowledged (n)
    "signed_commitment_tx_hex": "0200...", // The fully signed CT_n, ready for broadcast
    "eth_tx_hash": "0xabc..." // The transaction hash of the fulfilled ETH swap
  }
}

8.5. MSG_COOPERATIVE_CLOSE (Client -> Server)​

Sent by the user to request a fast, cooperative close of the channel.

{
  "type": "MSG_COOPERATIVE_CLOSE",
  "payload": {
    "channel_id": "ab34...",
    "final_btc_destination_address": "bc1q..." // User's final address for their funds
  },
  "signature": "..." // User's signature on hash of payload
}

9. Channel State Machine​

The state machine defines the lifecycle of a single channel. Both the User Wallet and Xythum Backend must adhere to this logic.

9.1. States​

  • START: The initial state before any interaction.
  • AWAITING_FUNDING: Channel parameters have been agreed upon (ACK_INIT_CHANNEL received/sent). The system is waiting for the user to broadcast the deposit transaction to the funding_address.
  • AWAITING_LOCKIN: A deposit transaction has been detected in the mempool. The system is waiting for a sufficient number of confirmations (e.g., 3 confirmations) to consider the funds secure.
  • ACTIVE: The channel is fully funded and confirmed. The initial CT0 has been created and exchanged. The channel is now ready for instant swaps. This is the primary operational state.
  • AWAITING_REVOCATION: A MSG_SWAP_REQUEST has been sent/received. The protocol is paused, waiting for the counterparty's acknowledgment and the signed next-state Commitment Transaction. The user has revealed their previous secret.
  • COOPERATIVE_CLOSING: A MSG_COOPERATIVE_CLOSE has been agreed upon. The final settlement transaction has been broadcast. The system is waiting for it to be confirmed.
  • UNILATERAL_CLOSING: A Commitment Transaction (from any state) has been detected on the Bitcoin blockchain. This triggers the watchtower's main duty. The 24-hour contestation period begins.
  • CLOSED: The channel is terminated. Funds have been settled on-chain either cooperatively, via a successful unilateral close, or via a justice transaction. The channel_id is now defunct.

[DISCARDED DESIGNS]

image.png

image.png

image.png