Enhancements to Claimable Balance

[Igor Natanzon]

Could I propose following enhancements to Claimable Balance ledger entry, to allow for a bit more flexibility in how they are used?

1. Addition of an optional memo field.
   1. To me, CB acts a bit like a personal check. It can be created and cashed in two independent events. And when source account makes multiple payments to the claimant, it would be nice, like in a personal check, for the payment to have some information about purpose. 
   2. This could be similar to a transaction memo field, or maybe something akin to  Data field on account entry.
   3. While it is possible to store the memo in transaction entry itself, it has several drawbacks:
      1. It will not be possible for a single transaction to create Claimable Balance entries with different purpose/memos.
      2. There is no direct link (that I know of) that leads from CB into Transaction, requiring several hops of queries to get there.
2. Allow for ability of Source account to reclaim the balance before it is picked up by the claimant - either with a flag on the balance(allow_reclaim=true), or implied. Right now this is done by adding source account as an additional claimant, but it seems like a confusing workaround, and adds unnecessary data into the ledger.

Thank you.

[Leigh McCulloch]

Claimable balances are intended to be two-part payments. With a single payment it is very easy to identify the memo of the payment by looking at the transaction, so this seems important to me that it should be equally simple to identify the memo associated with a claimable balance.

The addition of adding a memo directly to claimable balances (CB) would be useful but I think it would require a new operation for providing the memo field because operations cannot be extended. Some of the comments you made suggest there could be other solutions to this problem that might be simpler or more holistic.

>It will not be possible for a single transaction to create Claimable Balance entries with different purpose/memos.

Ordinary payments suffer the same issue you described because all payments in a transaction must share a memo. Maybe we should address this problem holistically for all operations? Operations are not extendable but we could allow specifying a memo for each operation in something like the form below (although in a way that omits operationMemos fields if operations do not have the memo set for space efficiency). It raises the question though: how should a wallet interpret a payment or CB from a transaction that has a memo on both the transaction and operations.

```diff

diff --git a/src/xdr/Stellar-transaction.x b/src/xdr/Stellar-transaction.x

index 7f08d757..efc8f5aa 100644

--- a/src/xdr/Stellar-transaction.x

+++ b/src/xdr/Stellar-transaction.x

@@ -531,6 +531,8 @@ struct Transaction

     {

     case 0:

         void;

+    case 1:

+        Memo* operationMemos<MAX_OPS_PER_TX>;

     }

     ext;

 };

```

>There is no direct link (that I know of) that leads from CB into Transaction, requiring several hops of queries to get there.

We could address this in Horizon by adding a link from a CB to the Transaction that created it. This would simplify use without expanding the functionality and wouldn't require any changes to Core.

>2. Allow for ability of Source account to reclaim the balance before it is picked up by the claimant - either with a flag on the balance(allow_reclaim=true), or implied. Right now this is done by adding source account as an additional claimant, but it seems like a confusing workaround, and adds unnecessary data into the ledger.

The creator of the CB is not actually stored on the claimable balance in the ledger in any field so to add it would increase ledger space used. The sponsor is stored, but that may not be the creator/sender of the CB if a third party is sponsoring the ledger entry. This is another example of why Horizon needs to include the creating/sending account in its API. It is not intuitive that the sponsor is not always the creator/sender, and it is not trivial to find out who the creator/sender is. This change would make CB less useful in agreements or contracts where the sender is intending to guarantee the claimant can claim the CB for a period of time. A sender may wish to guarantee to the claimant that for 2 days the claimant is the only person who can claim the CB.

In summary, I think if the following things were implemented, they would address these problems, without needing to add a new operation, and without adding memo directly to CB.

- Horizon had the creating transaction of a CB as a field and/or link on the CB API responses.

- Horizon had the creator/sender of a CB as a field and/or link on the CB API responses.

- Any operation could be given their own memo.

[Leigh McCulloch]

Eric just reminded me we have an open issue discussing adding one of these things to Horizon. I created a new issue for the other:

https://github.com/stellar/go/issues/3305 – Add link to transaction/operation in CB response

https://github.com/stellar/go/issues/3380 – Add creator in CB response.

[Igor Natanzon]

Leigh, I agree that at least being able to identify creator and transaction as links would address most of the issue, possibly together with Memo field on operation that creates the CB. As far as a guarantee that claimant can grab the CB for a period of time, my ability to add sender as claimant still allows working around it. But this was only a suggestion to reduce some extra clutter in blockchain. Current functionality certainly is sufficient, and its possible to use a predicate to prevent source from reclaiming the balance for certain amount of time.

[Jonathan Jove]

There is a feature called multiplexed accounts--often referred to as muxed accounts--which was introduced in https://github.com/stellar/stellar-protocol/blob/master/core/cap-0027.md. This feature lets you attach a 64-bit integer called an "id" to (almost) any account that appears in an operation. Specifically, you can always attach an id to the source account. There isn't a lot of ecosystem support for this feature right now, but it might be able to help with your request to have "some information about purpose".

Using this feature requires some kind of application support, because the id doesn't mean anything to stellar-core. But you can use it as the basis for a memo or invoicing system. For example, your application could record what the id actually means by mapping the 64-bit integer to a string in your database, and then you can use the id from the stellar operation to match up against the underlying meaning. You could then display this to your users.

This sounds a little roundabout, but to me that is a feature not a bug. In most cases, I wouldn't want to announce to the world what the purpose of a specific payment is. But the integer is opaque, and this means your application can restrict who has access to the underlying meaning.

I'm very interested to hear if an approach like this would work for you, or if there is something else that you would require.

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/517e425e-2d50-4ca2-8d56-2562946f1b5cn%40googlegroups.com.