Active Discussions

💬 This week on the dev mailing list there is a Final Comment Period for CAP-0023: Two-Part Payments.

It’s been a while since we’ve talked about CAP-0023 so I’ll recap here. The technical summary is as follows:

Payments can fail depending on the state of the destination account. This proposal introduces new operations that separate sending a payment from receiving the payment. Then the success of sending depends only on the state of the sending account and success of receiving depends only on the state of the receiving account.

So what does this mean? Basically, CAP-0023 introduces a claimable balance entry, which helps anchors get around the chicken/egg trustline conundrum. It’s a protocol-level solution to the problem SEP-0025 tries to address, and makes it so that an anchor can give a user access to a token even if the user doesn’t have an account or a trustline.

CAP-0023 achieves this by introducing three new operations — CreatePreparedTrustLineOp, CreateClaimableBalanceOp,and ClaimClaimableBalanceOp. An example of these in practice would be:

CreatePreparedTrustLineOp allows Account A to created a ‘prepared’ trustline for Account B.

allows Account A to created a ‘prepared’ trustline for Account B. CreateClaimableBalanceOp then allows Account A to add a claimable balance, say 5 USD, to that trustline for Account B.

then allows Account A to add a claimable balance, say 5 USD, to that trustline for Account B. ClaimClaimableBalanceOp allows Account B to actually claim the 5 USD on the prepared trustline sent by Account A, avoiding the hassle of handling trustlines manually.

👉 If this is a topic that interests you or if you have any final questions, comments, or concerns we’d love to hear from you (by the end of the week)! Leave your thoughts here.