A claimable balance on Stellar looks like a payment, but it is really three separate events folded under one label. The protocol proposal behind it, CAP-0023, introduced operations that split sending an asset from receiving it, so a sender can start a transfer even when the destination account is not yet ready to accept the asset. The trade-off is that evidence of one event does not establish the other two.
Three events, three questions
Creation is the first event. A CreateClaimableBalanceOp writes a ClaimableBalanceEntry to the ledger carrying the asset, amount and a list of claimants. The entry is its own ledger object rather than a sub-entry of any account, so a sending account can even be merged while an entry it created is still unclaimed. Eligibility is the second event: an account appears on that list and its predicate, the condition attached to its claim, is satisfied. Receipt is the third: a successful ClaimClaimableBalanceOp credits the asset to the claim’s source and deletes the entry. In a missing-payment dispute, the useful question is which of these events has evidence behind it, not whether “the payment” happened.
Predicates grant permission, not payment
Each claimant carries a predicate. The specification names six kinds: unconditional, AND, OR, NOT, before-absolute-time and before-relative-time. A relative-time condition is anchored to the ledger close time recorded at creation, not to the moment a wallet user first notices the transfer, and a value that would overflow the 64-bit integer is capped at INT64_MAX. A satisfied predicate answers a permission question; it does not confirm that a claim operation ran.
What a claim actually checks
A claim runs through an ordered list of checks. It fails with DOES_NOT_EXIST when no entry matches the balance ID, and with CANNOT_CLAIM when the claim’s source account is not a listed claimant or its predicate is unsatisfied. The native reserve is then routed back: to createdBy, which the specification defines as the transaction’s source rather than the operation’s, if that account has enough capacity; otherwise to the claim’s source as a fallback. For a non-native asset, the destination must hold a trustline carrying the AUTHORIZED_FLAG and enough available capacity, or the claim fails with NO_TRUST, NOT_AUTHORIZED or LINE_FULL. Creation uses the medium threshold because it can move funds, while a claim needs only the low threshold because it transfers value from the entry to a trustline.
Why the distinction matters
Collapsing these steps causes concrete errors. An entry existing does not mean the intended recipient can claim it. A claimant becoming eligible does not consume the entry; only a successful claim deletes it. And returning the native reserve to createdBy is not the same as recovering the asset. The claimant list is a fixed set of accounts rather than public keys, a choice the proposal says would otherwise make it easier to route funds around an asset’s authorization restrictions. CAP-0023 is a specification with Final status and a recorded protocol version, which describes the document rather than guaranteeing what any particular wallet implements today. When investigating a transfer, keep “entry created,” “claimant eligible” and “asset received” as separate findings and check each against its own record.
Adapted from Stellar Claimable Balances: Creation, Eligibility and Receipt in CAP-0023.