Claims

A claim is a signed slip that says: "This channel may pay out this much in total."

The word total matters. Claims do not add up. Each new claim replaces the last one with a bigger number.

Say a stream costs 1 XRP per song.

1. After song one, you sign a claim for 1 XRP.
2. After song two, you sign a claim for 2 XRP.
3. After song three, you sign a claim for 3 XRP.

The seller keeps only the newest claim. When they want their money, they send that one claim to the ledger and receive 3 XRP. Three payments, one transaction.

Before playing each song, the seller checks two things:

• The signature is real. It was made with the key named on the channel.
• The channel can pay. It is still open, it is not about to expire, and it holds at least as much XRP as the claim says.

If both hold, the seller has not been paid yet. But they know they can be, as long as they redeem before the channel closes.

The seller can also cash in along the way. Redeem at 3 XRP, keep selling, redeem again at 10. The second time pays the 7 that is new.

A claim can never be for more than the channel holds. If the tab runs out, the payer adds XRP to the channel and keeps going.

Claims travel outside the ledger. The two sides pick how: a web request, a message, anything. xrpl.org recommends a secure connection. Only the payer or the payee can redeem a claim, so a stolen slip is of no use to a third party.

Signing. The signed message contains the channel ID and the cumulative amount in drops. The key is the one whose public key is stored as PublicKey on the PayChannel. A server's channel_authorize method creates the signature.

A claim, as passed to the payee, needs three values: the channel ID, the amount in drops and the signature. The payee also needs the channel's public key, which never changes.

Verifying. channel_verify checks a signature against a channel ID, amount and public key. Then the payee reads the channel with account_channels on the payer's address, in a validated ledger, and confirms:

• destination_account is the payee's address.
• settle_delay leaves enough time to redeem.
• cancel_after and expiration, if present, are not too soon.
• The channel's amount is at least the claim's amount.
• The channel's balance matches what the payee has already received.

Redeeming. The payee sends PaymentChannelClaim:

Balance may be less than Amount. The payee is not required to redeem the full authorized sum.

The payer can also send PaymentChannelClaim to pay from the channel directly, with or without a signed claim.

CredentialIDs is optional. It lets a claim deliver to a destination that uses Deposit Authorization with credentials.

Bookkeeping. xrpl.org lists reasons a payee's records can disagree with the ledger. Two of them: the payer delivered XRP from the channel and the payee missed it, or the payee recorded a tentative result that was not the validated one. Record only validated results.

Related: Credentials, Wallets, keys and safety.