Last updated
Edit

Payment Channels

Payment Channels are an advanced feature for sending "asynchronous" XRP payments that can be divided into very small increments and settled later.

The XRP for a payment channel is set aside temporarily. The sender creates Claims against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by consensus. (This is an asynchronous process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can redeem a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims.

Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based on the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECDSA signatures. Research has demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over 70,000 per second on commodity hardware in 2011.

Why Use Payment Channels

The process of using a payment channel always involves two parties, a payer and a payee. The payer is an individual person or institution using the XRP Ledger who is a customer of the payee. The payee is a person or business who receives XRP as payment for goods or services.

Payment Channels do not intrinsically specify anything about what you can buy and sell with them. However, the types of goods and services that are a good fit for payment channels are:

  • Things that can be transmitted near-instantly, like digital items
  • Inexpensive things, where the cost of processing a transaction is a non-trivial part of the price
  • Things normally bought in bulk, where the exact quantity desired is not known in advance

Payment Channel Lifecycle

The following diagram summarizes the lifecycle of a payment channel:

LegendChannel is expiredChannel is closed andremoved from ledger.Unclaimed XRP is returned to payerMutableExpiration("Expiration" field)ImmutableExpiration("CancelAfter" field)Business transactioncompletePayment confirmedPayment initiatedPayer is ready to payBoth parties are ready to use the channelChannel is createdTransaction effect(happens as partof a previous step)XRP Ledger transaction(needs 3-5 seconds for consensus)Off-ledger step(happens as fast as can be calculated)Payer: Add more XRP to channel(PaymentChannelFund transaction)7. Repeat as desired(Mutable expiration can be updated byPaymentChannelFundtransaction)Payee's PaymentChannelClaim transactionused tfClose flagChannel is out of XRP10. Anyone: close channel(PaymentChannelClose or PaymentChannelFundtransaction)Channel has XRP left;sets Expiration9b. Payee: request to close channel(PaymentChannelClaim transaction with tfClose flag)9a. Payer: request toclose channel(PaymentChannelClaim transaction with tfClose flag)Payee's PaymentChannelClaim transaction did notuse tfClose flag(Immutable expiration is defined by PaymentChannelCreate transaction)8. Payee: Redeem claim(PaymentChannelClaimtransaction)Payee receives XRPif channel isn't expired.6. Payee: Provide goods and services5. Payee: Verify claim's signature and amount(channel_verify and account_channels method)4. Payer: transmit signed claim to payee(using any communication method)3. Payer: sign claim(s)(channel_authorize method)2. Payee: check channel state(account_channels command)1. Payer: create channel(PaymentChannelCreate transaction)

See Also