This article presents a sample payment channel that uses to support efficient revocations. It can be easily extended to function as a state channel and support Hash-Time Locked Contracts (HTLCs) for lightning-like routing. However, we aim to keep it simple so that it serves as a clear example of BitVMX’s capabilities and how it can be integrated as a subcomponent of other Bitcoin protocols. In this example, BitVMX is used to handle state revocations and enable efficient watchtowers that store only O(1) data per payment channel.

Each state of our toy payment channel has a sequence number i, which increments with every state update. When the parties agree to move to the next state (e.g., rebalance the shared account), they must co-sign three transactions. They can use a multisig or MuSig2 scheme to reduce the on-chain footprint. Then, they create two revocation messages—one for each party—signed with Schnorr signatures. A revocation message contains the new state sequence number i and represents the message: “I revoke all states prior to i.” In practice, the message is simply the number i, signed with a private key designated solely for this purpose.

When Alice wants to unilaterally close the channel, she can only do so by signing the sequence number i using a one-time signature (OTS) scheme. This sequence number defines the state that Alice claims should determine the final balance distribution between her and Bob. If Alice uses an outdated state—say she signs j, with j < i—a dispute mechanism is triggered to penalize her. Bob simply needs to present the OTS-signed value j and the Schnorr-signed message “I revoke all states prior to i,” which Alice previously issued and which Bob has stored. A Bitcoin script verifies the OTS signature, while a RISC-V program executed via BitVMX verifies the Schnorr signature and checks whether j < i. If this condition holds, Bob wins the dispute and can claim all funds in the channel.