regulated assets claw-back

685 views
Skip to first unread message

Tomer Weller

unread,
Mar 2, 2020, 6:11:04 PM3/2/20
to Stellar Developers
Some regulated asset issuers are interested in the ability to claw back assets unilaterally to comply with various regulations.

The Stellar protocol allows revoking ("deauthorizing") trustlines. However, that doesn't completely solve the problem. First, the balance remains in the unauthorized trustlines. Second, there's no way to claw back a partial balance.

One potential solution: add an "AUTH_CLAWBACKABLE" (or better name) account flag. If an asset is clawbackable then the issuer can authorize payments from all trustlines to their assets. 

Would love to hear your thoughts on this

Tom Quisel

unread,
Mar 2, 2020, 6:17:44 PM3/2/20
to Tomer Weller, Stellar Developers
I like it! One idea is to simply add a clawback feature to the existing AUTH_REVOCABLE flag, since it's arguably a lesser power over the user than completely revoking their trustline.

Tom

--
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/CALTyOpEYtUTekAkCdoCx-hxH0%3DoyNy8UOn0R0ZVX7eR%2BweRmQw%40mail.gmail.com.

Ishai Strauss

unread,
Mar 2, 2020, 6:25:09 PM3/2/20
to Tom Quisel, Tomer Weller, Stellar Developers
What is the difference between a clawback and a revocation? I mean, if I as an anchor revoke a user's trustline then all I need to do is make sure I never credit the user if they send back to the issuing address, isn't that essentially a clawback?



--
Ishai Strauss
Founder/CEO Stellarport

Tomer Weller

unread,
Mar 2, 2020, 6:29:02 PM3/2/20
to Ishai Strauss, Tom Quisel, Stellar Developers
Ishai, that's an acceptable (though a bit hacky) solution for the first problem - we can just agree that unauthorized balances don't count towards the circulating supply. But what about a partial clawback (only a part of the account's balance)?

Ishai Strauss

unread,
Mar 2, 2020, 6:35:09 PM3/2/20
to Tomer Weller, Tom Quisel, Stellar Developers
If an anchor revokes a trustline, then the user needs to send the entire balance back to the issuing account. The anchor can send back whatever fraction it does not want to clawback and then reauthorize the trustline. I'm not really against the clawbackable flag, just playing devil's advocate really.

Another question, if a clawback flag is introduced, is revocable still necessary? What are the use cases where I want to revoke but not clawback?

Tyler van der Hoeven

unread,
Mar 2, 2020, 8:16:22 PM3/2/20
to Tomer Weller, Ishai Strauss, Tom Quisel, Stellar Developers
A good use case for revokable is in the case of unauthorized access. Locking up an account so funds can’t be removed to a hackers account. Once the account is stable again the flag can be removed. 

I do think it’s a bit nervous to live underneath clawback. At any moment you could have your assets reclaimed. I would want time or amount or both restraints added to that. 

Tyler

Corey Ballou

unread,
Mar 3, 2020, 9:01:17 AM3/3/20
to Tyler van der Hoeven, Tomer Weller, Ishai Strauss, Tom Quisel, Stellar Developers
I'm all for this feature as I believe it opens the doors for more regulated players to utilize the Stellar ecosystem. They have a different set of requirements than your average asset. If also used in good faith, it would help deter attempted hacks on a given coin if the attacker knows it's a fruitless effort. AUTH_REVOCABLE doesn't achieve this same effect as you essentially burn tokens in the process if you have a fixed supply, and burning money out of thin air is really not the net effect a regulated asset would be looking for.



--
Corey Ballou
CTO  TERNO

Michael Feldstein

unread,
Mar 3, 2020, 6:48:05 PM3/3/20
to Stellar Developers
I like the cleanliness of actually clawing it back vs just revoking it.  It keeps the ledger more clear about what assets are out there, it seems a bit confusing for the ledger to show that someone has a balance in their account but its 'revoked' so it should be treated as 'not in their account'.  It also makes the partial clawback story a million times more simple.

On Tuesday, March 3, 2020 at 6:01:17 AM UTC-8, Corey Ballou wrote:
I'm all for this feature as I believe it opens the doors for more regulated players to utilize the Stellar ecosystem. They have a different set of requirements than your average asset. If also used in good faith, it would help deter attempted hacks on a given coin if the attacker knows it's a fruitless effort. AUTH_REVOCABLE doesn't achieve this same effect as you essentially burn tokens in the process if you have a fixed supply, and burning money out of thin air is really not the net effect a regulated asset would be looking for.

On Mon, Mar 2, 2020 at 8:16 PM 'Tyler van der Hoeven' via Stellar Developers <stell...@googlegroups.com> wrote:
A good use case for revokable is in the case of unauthorized access. Locking up an account so funds can’t be removed to a hackers account. Once the account is stable again the flag can be removed. 

I do think it’s a bit nervous to live underneath clawback. At any moment you could have your assets reclaimed. I would want time or amount or both restraints added to that. 

Tyler
On Mar 2, 2020, 6:35 PM -0500, 'Ishai Strauss' via Stellar Developers <stell...@googlegroups.com>, wrote:
If an anchor revokes a trustline, then the user needs to send the entire balance back to the issuing account. The anchor can send back whatever fraction it does not want to clawback and then reauthorize the trustline. I'm not really against the clawbackable flag, just playing devil's advocate really.

Another question, if a clawback flag is introduced, is revocable still necessary? What are the use cases where I want to revoke but not clawback?

On Mon, Mar 2, 2020 at 5:29 PM Tomer Weller <to...@stellar.org> wrote:
Ishai, that's an acceptable (though a bit hacky) solution for the first problem - we can just agree that unauthorized balances don't count towards the circulating supply. But what about a partial clawback (only a part of the account's balance)?

On Mon, Mar 2, 2020 at 3:25 PM Ishai Strauss <is...@stellarport.io> wrote:
What is the difference between a clawback and a revocation? I mean, if I as an anchor revoke a user's trustline then all I need to do is make sure I never credit the user if they send back to the issuing address, isn't that essentially a clawback?

On Mon, Mar 2, 2020 at 5:17 PM 'Tom Quisel' via Stellar Developers <stell...@googlegroups.com> wrote:
I like it! One idea is to simply add a clawback feature to the existing AUTH_REVOCABLE flag, since it's arguably a lesser power over the user than completely revoking their trustline.

Tom

On Mon, Mar 2, 2020 at 3:11 PM 'Tomer Weller' via Stellar Developers <stell...@googlegroups.com> wrote:
Some regulated asset issuers are interested in the ability to claw back assets unilaterally to comply with various regulations.

The Stellar protocol allows revoking ("deauthorizing") trustlines. However, that doesn't completely solve the problem. First, the balance remains in the unauthorized trustlines. Second, there's no way to claw back a partial balance.

One potential solution: add an "AUTH_CLAWBACKABLE" (or better name) account flag. If an asset is clawbackable then the issuer can authorize payments from all trustlines to their assets. 

Would love to hear your thoughts on this

--
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 stell...@googlegroups.com.

--
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 stell...@googlegroups.com.


--
Ishai Strauss
Founder/CEO Stellarport


--
Ishai Strauss
Founder/CEO Stellarport

--
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 stell...@googlegroups.com.

--
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 stell...@googlegroups.com.

Eric Saunders

unread,
Mar 3, 2020, 6:55:39 PM3/3/20
to Michael Feldstein, Stellar Developers
What is the partial clawback story? Would be great to have a use case for that made explicit.

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/dee593a8-606c-45eb-bf53-3aa37dbd0be7%40googlegroups.com.

Tomer Weller

unread,
Mar 3, 2020, 7:03:15 PM3/3/20
to Eric Saunders, Michael Feldstein, Stellar Developers
Eric, let's say that TOMER is a regulated asset and you have a balance of 1000 TOMERS issued by me (Tomer). The government can decide that no one should own more than 10 TOMERS and ask me, as a licensed broker dealer, to reclaim (or claw back) 990 TOMERS.

Leigh McCulloch

unread,
Oct 1, 2020, 1:58:00 PM10/1/20
to Stellar Developers
RE: https://github.com/stellar/stellar-protocol/pull/736

>In order to execute a clawback, the Issuer submits a a `CLAWBACK` operation
>from the account containing the asset to be clawed back to the desired
>destination.

If the issuer of the asset must be the source account of the operation, this means the issuer keys can never be discarded. This would make this feature incompatible with assets where the asset issuer wishes to prove definitively that the asset has a finite supply by locking the issuing account. Maybe that makes sense in that situation? Would clawback still be useful on assets that have a finite supply? I would think so, but I'm not sure.

Leigh

Suat Özgür

unread,
Oct 1, 2020, 3:25:37 PM10/1/20
to Leigh McCulloch, Stellar Developers
Am Do., 1. Okt. 2020 um 19:58 Uhr schrieb 'Leigh McCulloch' via Stellar Developers <stell...@googlegroups.com>:
RE: https://github.com/stellar/stellar-protocol/pull/736

>In order to execute a clawback, the Issuer submits a a `CLAWBACK` operation
>from the account containing the asset to be clawed back to the desired
>destination.

If the issuer of the asset must be the source account of the operation, this means the issuer keys can never be discarded. This would make this feature incompatible with assets where the asset issuer wishes to prove definitively that the asset has a finite supply by locking the issuing account. Maybe that makes sense in that situation? Would clawback still be useful on assets that have a finite supply? I would think so, but I'm not sure.

Leigh

I think clawback implies so much control for the issuer that it also seems contrary to me for someone to use this feature but also give up control by limiting their supply. However it could work like allowTrust: If it was a low security operation you could still use it after locking the issuing account for medium/high operations. Although the feature itself does not "feel" like low security. As far as I see the threshold is also not mentioned yet in the CAP?

Dan Doney

unread,
Oct 2, 2020, 2:45:35 PM10/2/20
to Stellar Developers
Thanks Corey. You are exactly right! This also fundamentally changes custody since users have recourse if they lose their wallet. Ironically, bearer instruments encourage centralization as users (and institutions) don't trust their own ability to safeguard assets - and instead deposit them with custodians. With clawback, the trust is in the issuer (or transfer agent), an accountable party if trust is abused which is actually consistent with the concept behind trustlines. As a result, users can more confidently self custody because they have recourse if value is lost or stolen.

Dan Doney

unread,
Oct 2, 2020, 2:45:35 PM10/2/20
to Stellar Developers
I'm not sure that anyone should ever own more than 1 Tomer at a time!

Thanks team for considering the case! I submitted the requirement as a necessary function to get regulatory approval from the SEC for tokenized ETFs (though it applies to many other types of assets). The SEC (and FINRA) are very concerned about the business continuity case (especially for broker dealers). They don't see a case like the Canadian exchange where a broker (entity custodying assets on behalf of customers) goes out of business (or supposedly dies) leaving no recourse for customers to regain their funds. The requirement goes much broader than this - but this is the essential point: there must be a mechanism to pull back lost or stolen assets (not just freeze them) even if the party is unwilling or unable to participate in recovery.

The case for a partial CLAWBACK is if the holder has gained some of the assets due to a mistaken or fraudulent transaction - or if a court orders a distribution of assets as part of a settlement (think divorce - or try not to).

This may sound harsh, but based on our experience with regulators here and abroad (Europe, MENA), many types of securities will not receive regulatory approval unless this feature can be demonstrated.

As I mention in the request, a related function (for later, if desired) is a rollback (reversal of transaction). Several overseas jurisdictions require this capability for regulatory approval. Rollback has (mostly negative) implications for settlement time that we'll discuss when the time is right.

Jonathan Jove

unread,
Oct 2, 2020, 3:00:19 PM10/2/20
to Dan Doney, Stellar Developers

Thanks for submitting this proposal! I posted some corrections on the PR, but I will share some discussion points here.


> The account CLAWBACK_ENABLED flag allows the issuer to designate the asset as a non-bearer instrument asset. By including the CLAWBACK_ENABLED flag in Asset flags, Account owners may review the revocability of an asset and have the choice to avoid this type of asset if they object to the implied trust in the issuer.


I think this exaggerates how easy it will be for users to determine that an issuer can clawback. As long as AUTH_IMMUTABLE is not set, it would be possible for the issuer to set CLAWBACK_ENABLE whenever they like. A “sandwich” transaction like


1. Set CLAWBACK_ENABLE

2. Clawback

3. Clear CLAWBACK_ENABLE


would even be possible, in which case the CLAWBACK_ENABLE flag never remains in the set state.


> The change does not have an affect on previous assets, accounts, or transaction structure. It should not cause a breaking change in existing implementations.


Using the same argument as above, this does impact existing assets. Any asset that does not have AUTH_IMMUTABLE set is now effectively non-bearer. Perhaps this doesn’t matter, because accounts that hold these assets could already have their authorization revoked.


> In the future, we expect that this flag may also be used to support transaction compliance rollback. While under this specification a rollback (reversing a transaction) can be achieved with the issuer executing a clawback from a transaction’s beneficiary and subsequent payment to the originator, we believe it may be beneficial to explicitly support a rollback transaction. In any case, this transaction is not covered here.


Perhaps this is outside the scope of this proposal, but I believe it is not generally possible to design a mechanism to rollback a transaction. Even a simple payment cannot necessarily be rolled back. Imagine I send a payment to you, and the issuer later wants to roll this back. You have potentially made payments to many accounts since then, and may not hold any of the funds. In order to roll this back, you would have to rollback the entire tree of transactions. Perhaps this can be done, but this is assuming that only simple payments happened. If asset exchange is involved, then this may be completely impossible because you may not be the issuer of the assets for which your asset was exchanged. You will not be able to unilaterally rollback those operations under any circumstances. What do you desire in terms of rollback, given these practical constraints? Or am I missing some important detail?


> Clawback will cancel as many pending orders as necessary, in order of creation, to ensure that account liabilities are maintained.


From an implementation perspective, this is a bit of a pain. Would it be acceptable to take the stance that authorization must be revoked before CLAWBACK? Then we wouldn’t have to implement any new logic to remove orders, because this is already done when revoking authorization. The main difference is that all orders for that account involving the asset would be cancelled, instead of just a subset. Since I don’t expect CLAWBACK to be a regular occurrence, this seems okay to me but perhaps others disagree.


In general, I believe that anyone trying to use CLAWBACK would want to revoke authorization first anyway. Otherwise the account could consistently reduce their balance by a random amount in order to prevent the CLAWBACK from succeeding due to CLAWBACK_UNDERFUNDED.


Dan Doney

unread,
Oct 5, 2020, 4:02:45 PM10/5/20
to Stellar Developers
Great feedback! Thanks Jonathan. 

>> The account CLAWBACK_ENABLED flag allows the issuer to designate the asset as a non-bearer instrument asset. By including the CLAWBACK_ENABLED flag in Asset flags, Account owners may review the revocability of an asset and have the choice to avoid this type of asset if they object to the implied trust in the issuer.

>I think this exaggerates how easy it will be for users to determine that an issuer can clawback. As long as AUTH_IMMUTABLE is not set, it would be possible for the issuer to set CLAWBACK_ENABLE whenever they like. A “sandwich” transaction like

>1. Set CLAWBACK_ENABLE

>2. Clawback

>3. Clear CLAWBACK_ENABLE

>would even be possible, in which case the CLAWBACK_ENABLE flag never remains in the set state.

This is a good point. I sympathetic to this issue and believe that transparency is best for: the 1) protection of those who like the censorship free aspects of bearer instruments, and 2) convenience of those who require/desire revocable instruments. There are 2 ways we could address this issue: 1) require the flag to be set at issuance - it can't be toggled. 2) have an additional flag CLAWBACK_DISABLED, that once set, cannot be unset. Setting this flag, disables CLAWBACK_ENABLE. This is the equivalent of AUTH_IMMUTABLE, but only for the CLAWBACK parameter. 


>> The change does not have an affect on previous assets, accounts, or transaction structure. It should not cause a breaking change in existing implementations.
>Using the same argument as above, this does impact existing assets. Any asset that does not have AUTH_IMMUTABLE set is now effectively non-bearer. Perhaps this doesn’t matter, because accounts that hold these assets could already have their authorization revoked.
You could automatically set CLAWBACK_DISABLED to true for existing assets or allow issuer to choose to set the CLAWBACK_DISABLED to retain assured bearer instrument status.

>> In the future, we expect that this flag may also be used to support transaction compliance rollback. While under this specification a rollback (reversing a transaction) can be achieved with the issuer executing a clawback from a transaction’s beneficiary and subsequent payment to the originator, we believe it may be beneficial to explicitly support a rollback transaction. In any case, this transaction is not covered here.

> Perhaps this is outside the scope of this proposal, but I believe it is not generally possible to design a mechanism to rollback a transaction. Even a simple payment cannot necessarily be rolled back. Imagine I send a payment to you, and the issuer later wants to roll this back. You have potentially made payments to many accounts since then, and may not hold any of the funds. In order to roll this back, you would have to rollback the entire tree of transactions. Perhaps this can be done, but this is assuming that only simple payments happened. If asset exchange is involved, then this may be completely impossible because you may not be the issuer of the assets for which your asset was exchanged. You will not be able to unilaterally rollback those operations under any circumstances. What do you desire in terms of rollback, given these practical constraints? Or am I missing some important detail?

Let's table this for a future proposal. One comment though, the funds could be locked until rollback time period expired or compliance entity issues a release. 


>> Clawback will cancel as many pending orders as necessary, in order of creation, to ensure that account liabilities are maintained.

>From an implementation perspective, this is a bit of a pain. Would it be acceptable to take the stance that authorization must be revoked before CLAWBACK? Then we wouldn’t have to implement any new logic to remove orders, because this is already done when revoking authorization. The main difference is that all orders for that account involving the asset would be cancelled, instead of just a subset. Since I don’t expect CLAWBACK to be a regular occurrence, this seems okay to me but perhaps others disagree.

You are probably right. Let's keep it simple. All orders should be disabled.

> In general, I believe that anyone trying to use CLAWBACK would want to revoke authorization first anyway. Otherwise the account could consistently reduce their balance by a random amount in order to prevent the CLAWBACK from succeeding due to CLAWBACK_UNDERFUNDED.

I'd prefer one transaction. But I don't have a strong opinion here.

Dan Doney

unread,
Oct 14, 2020, 5:06:45 PM10/14/20
to Stellar Developers
Suat,
I agree. It would be very unusual for an asset that could be clawed back to not have the ability to issue or destroy. I suppose there may be a scenario where that would be the case - but rather than adding complexity to handle the outlier, the implementation should be a simple as possible to meet the core requirement. As a user of the feature, we're open to suggestions as long as the base case is met. 

We don't mention thresholds in the proposal. I agree that this is not a low security transaction. Requiring a high threshold opens the possibility of requiring multiple signatures (issuer and transfer agent, regulator and issuer, etc)

Dan Doney

unread,
Oct 14, 2020, 5:10:05 PM10/14/20
to Stellar Developers
A simple example of partial clawback is the case of divorce (or other court order - there are lots of them in bankruptcy, etc). The court may order 50 percent of the assets from party A be allocated to party B. Party A may conveniently "lose" the ability to move the assets. A transfer agent (issuer or other designee) needs to be able to step in. There are lots of variations on this theme

Dan Doney

unread,
Oct 14, 2020, 5:10:43 PM10/14/20
to Stellar Developers
Thanks Corey!

On Tuesday, March 3, 2020 at 9:01:17 AM UTC-5 Corey Ballou wrote:

Anthony BARKER

unread,
Oct 15, 2020, 10:23:18 AM10/15/20
to Stellar Developers
This could be quite useful for an asset split... For example a 1 for 3 split or reverse split.

Nicolas Barry

unread,
Dec 7, 2020, 2:00:27 PM12/7/20
to Anthony BARKER, Stellar Developers

Reviving this thread so that we keep things moving.


I took a look at the current CAP.


# semantics

 

## Relationship with authorization

 

It looks like the feedback from JonJove above was not incorporated into the CAP? I suspect that in order to "clawback" from a trustline, a prereq is that the trustline must first be set into "not authorized" state so that it's easy to understand what happens when a clawback happens/is in process.

 

## Interaction with the order book

 

From JonJove: the CAP still describes some arbitrary order cancellation. At the core layer I'd expect all offers related to an asset to be cancelled during the "clawback" flow, to avoid this kind of problems (I think addressed by requiring to de-authorize first).

 

## Interaction with `BalanceEntry`

 

NB: most of the issues described here also apply to any "smart contract" type of setup with an escrow account of sorts.

 

The CAP as described creates an incentive for people to "stash" their balance in a `BalanceEntry` as there is no way to clawback from a `BalanceEntry`.

 

I am not 100% sure what the right solution in this situation is yet.

 

One way can be to just not allow accounts that can be the target of a "clawback" to create a `BalanceEntry` or to limit the amount stored in those (with the understanding that those could be "lost"). The big downside is that such accounts may have limited interop with interesting smart contracts, in particular Layer 2 payment infrastructure and are just "stuck" with on chain transactions.

 

Allowing to clawback from `BalanceEntry` in some way is probably not viable:

    * we want to keep `BalanceEntry` immutable

    * we could make it that the issuer can "claim" those, but

         * this may break certain smart contracts

         * we're now shifting the problem to conditions on claimants and as those can be arbitrary, we'd have to allow bypassing conditions (or we're back to cooperating/waiting), which again potentially breaks smart contracts..

 

Above, the reason I am focusing on "breaking smart contracts" is that the breaks can have implications way beyond the asset being clawed back: we do not want side effects of a clawback to impact other assets and other accounts.

 

# Unspecified behavior

 

## flags

 

It looks like the CAP is missing the expected behavior wrt `SetOptions`. In particular, are there any invalid flag combinations or transitions? When can the flag be set? Should there be a way to express something like "this asset will never be clawback" (that should be the default). I saw a response earlier that started to discuss something like `CLAWBACK_DISABLED` which may not meet the "backward compatibility" requirement for existing assets.

 

## threshold

 

The threshold is not defined in the CAP, the choice and justification needs to be incorporated for further discussion. I see arguments for "high" or "low" in this thread, even though "medium" is the threshold typically used for sending assets (including issuing).

 

# Minor points

 

## general CAP structure

 

The CAP uses the "old" template, you may want to update it to use the new template that has some additional questions/sections to help move things along.

 

## naming/cleanup

 

(should probably be done when draft is getting close to final quality)

We may want to extract the "issuer less" asset definition, it looks like this is a copy/paste from `AllowTrustOp`.




Leigh McCulloch

unread,
Dec 17, 2020, 2:30:54 PM12/17/20
to Stellar Developers
I have addressed the feedback and discussion shared on CAP-35 so far, making some assumptions. The current version of CAP-35 is here:
https://github.com/stellar/stellar-protocol/blob/a60d936/core/cap-0035.md

The main changes are:
 - New CAP template adopted.
 - Remove AUTH_CLAWBACKABLE and require AUTH_REVOCABLE to be set on the issuer account to use the ClawbackOp. It was agreed above that clawback should be used in conjunction with revocation and since clawback is a finer grain form of revocation of asset circulation it makes sense to bundle it into the existing account flags. Any account with a trustline to a revocable asset can already lose control of the asset if the trustline's authorization is revoked, and so clawback in practice doesn't change the level of control that either the account or issuer has.
 - Specify that the CallbackOp requires medium threshold. While we discussed low and high, I believe medium is more appropriate because it moves an amount out of an account which is similar to payment operations that also require medium threshold. I could see argument for low also though because auth revocation requires low threshold.
 - Include discussion about how to use the ClawbackOp with the AllowTrustOp to close all selling liabilities.
 - Include discussion about limitations in regards to claimable balances.

I believe the main points of discussion are:

1. Does anyone see any blocking problems with using AUTH_REVOCABLE?

2. How to proceed regarding claimable balances. I am aware of three general approaches we could take with claimable balances:
a. Leave claimable balances as they are, a mechanism intended for temporary transition of assets that are immutable and cannot be clawed back.
b. Allow claimable balances to be clawed back in whole by destroying the claimable balance. I've opened CAP-36 that independently explores this approach. This approach has a subtle difference to CAP-35 because claimable balance clawback cannot be reversed with a re-issue to the same claimable balance ID, which could impact contract-like arrangements. https://github.com/stellar/stellar-protocol/blob/a60d936/core/cap-0036.md
c. Allow claimable balances to be clawed back in part. This approach would be identical to CAP-35, and allow reissuing amounts to a claimable balance and not impact contracts, but would require making claimable balances mutable.
d. Allow an issuer to prevent the creation of claimable balances for an asset with the user of another new account flag.

Nicolas Barry

unread,
Dec 17, 2020, 10:02:31 PM12/17/20
to Leigh McCulloch, Stellar Developers
Thanks Leigh

Before diving into balance entries, I guess it would probably be helpful to understand why they are potentially a problem:
From what I see, accounts can keep their actual balance in a balance entry that they can claim, and when they need to use it, they can sandwich the operation that they want between a claim/create balance entry.
The net effect for issuers in that case is that they can only freeze that account's activity (freezing also stops the account from claiming a balance entry) but not clawback whatever that account controls (so we're back to a world with no clawback).
Note that the same type of thing can be achieved by sending the balance to a different account, the difference is that in another account, the balance can be recovered by the issuer.

I suspect that the solution here is going to behave in a way similar to what happens in traditional banking with the "analog loophole" that is cash (where the analogy is that cash is equivalent to balance entries). The game at that point for issuers, is to limit exposure to balance entries.
With that said, I would not consider 2b and 2c viable solutions as they break too many desirable properties that we get out of balance entries especially when multiple parties are involved; instead controlling the flow create/claim of balance entries is probably a better alternative.
The simplest version of that with (2a) can be achieved with the help of `AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG`, which puts a lot of restrictions on the account.

I don't know if other people have a strong opinion on that topic though.

Nicolas



--
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.

Leigh McCulloch

unread,
Dec 18, 2020, 7:01:52 PM12/18/20
to Stellar Developers
I've added mention of `AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG` in discussion that they are considered out-of-scope of CAP-35. The current version of CAP-35 with that change is here:

Siddharth Suresh

unread,
Jan 5, 2021, 2:38:42 PM1/5/21
to Stellar Developers

Reusing AUTH_REVOCABLE for clawback will subject existing trustlines and claimable balances to clawback semantics, which will be an added burden for developers who only deal with "non-clawbackable" assets. It would be simpler and less invasive if the ability to clawback from trustlines and claimable balances were explicitly added on to the trustline.


Our proposed changes-

  1. Add AUTHORIZED_TO_CLAWBACK_FLAG to TrustlineFlags.

  2. Add a DEFAULT_TO_CLAWBACK_FLAG account flag, which will operate similar to AUTH_REQUIRED_FLAG (side note - the name of this flag is not ideal. While it is enabled, any trustline created will not have AUTHORIZED_FLAG set by default). If DEFAULT_TO_CLAWBACK_FLAG is enabled on an issuer when it creates a trustline, that trustline will have AUTHORIZED_TO_CLAWBACK_FLAG enabled.

  3. AUTHORIZED_TO_CLAWBACK_FLAG can only be set on the trustline when it is created. It can never be set on an existing trustline.

  4. A clawback from a trustline will work like it does in the CAP-0035 proposal, with the only difference being that the trustline flag AUTHORIZED_TO_CLAWBACK_FLAG will be checked instead of the issuer accounts AUTH_REVOCABLE flag.

  5. Clawbacks will work differently for claimable balances. If an account tries to create a claimable balance for an asset that has AUTHORIZED_TO_CLAWBACK_FLAG enabled, the operation will fail unless the issuer is a claimant on the claimable balance with a CLAIM_PREDICATE_UNCONDITIONAL predicate. This will ensure that an issuer can always claim a claimable balance that is subject to clawbacks.


These changes would allow existing trustlines and claimable balances to not be affected by clawbacks. The clawback implementation for claimable balances is also simpler.

Nicolas Barry

unread,
Jan 6, 2021, 1:55:53 PM1/6/21
to Siddharth Suresh, Stellar Developers
I like those updates as the behavior is more in line with what the protocol does today, and is more future proof (while basically allowing to do the same thing for people that want to use clawback enabled assets):
* unchanged semantics for existing assets
    * in particular we don't have to rollback CAP30 https://github.com/stellar/stellar-protocol/blob/master/core/cap-0030.md
* we're leaving the door open to future changes to assets with clawback enabled
   * We can add later a new operation to "clear" the `AUTHORIZED_TO_CLAWBACK_FLAG` on a trustline - this would be useful if an issuer wants to give special privileges to certain accounts that can then participate in normal smart contracts without any restrictions.
   * We can easily revisit 5 later if we decide that we want to do something more advanced with balance entries in the future (depending on smart contract needs).

Nicolas


Leigh McCulloch

unread,
Jan 11, 2021, 3:09:26 PM1/11/21
to Stellar Developers
Hi Siddarth, Nicolas,

I think the changes to move back to a new flag and snapshot it onto the trustline do a solid job of preserving existing trustlines and to make it clear to an account holder whether they hold an asset which can be clawed back or not. This makes the change more backwards compatible for non-auth-immutable assets.

I propose we use slightly different names for the flags:
DEFAULT_TO_CLAWBACK_FLAG => AUTH_CLAWBACK_ENABLED_FLAG, because it fits the pattern of existing flags whilst communicating essentially the same meaning, and it is established in the XDR that the AUTH_IMMUTABLE_FLAG causes all AUTH_* flags to be immutable.
AUTHORIZED_TO_CLAWBACK_FLAG => AUTHORIZED_WITH_CLAWBACK_ENABLED_FLAG, because alongside the other AUTHORIZED_TO_* flag that already exists the party who is authorized to do the action is confusing. The existing AUTHORIZED_TO_MAINTAIN_LIABILITIES_FLAG authorizes the account, where-as the AUTHORIZED_TO_CLAWBACK_FLAG authorizes the issuer. This distinction isn't obvious, and so by changing the TO to WITH means the new flag can follow similar naming conventions but indicate that clawback is enabled for the trustline.

Requiring clients to include the issuer account as a claimant on every claimable balance created for the asset has some downstream consequences that will be burdensome:
1. Wallets must care about clawback enabled assets to support creating claimable balances for them. Wallets will need to lookup the flags for a trustline probably via Horizon and determine if the issuer account must be included as a claimant. This may reduce interoperability of wallets with clawback enabled assets. This is likely to be minimal to other functionality a wallet supporting regulated assets needs to implement like SEP-8, so this should be okay I think.
2. Issuers who are also anchors use claimable balances for routine operations. Whilst it is very clear when the issuer uses a ClawbackOp to clawback an amount from an account balance it will be harder to distinguish when an issuer is clawing back a claimable balance vs just performing routine operations. An issuer claiming back a claimable balance has no way to transparently indicate if they were conceptually allowed to claim it back under normal business operations or if they were clawing it back on some exceptional basis. It will be very difficult for users of the network to assess whether an asset issuers frequently claws back claimable balances or not.

I am working on updates to CAP-35 to incorporate Siddarth's proposal with the name changes above, albeit I have concerns in point 2 above and look forward to thoughts on that.

Leigh

Jonathan Jove

unread,
Jan 11, 2021, 3:26:10 PM1/11/21
to Leigh McCulloch, Stellar Developers
Hi Leigh,

I think there are some interesting questions here about naming:
  • I don't feel great about AUTH_CLAWBACK_ENABLED_FLAG because it perpetuates the same ambiguity already present in AUTH_REQUIRED_FLAG. AUTH_REQUIRED_FLAG determines the _initial_ state of the authorization flags on a trust line and I really wish that the name reflected that. In an ideal world, we would give both AUTH_REQUIRED_FLAG and the analogous flag for clawback names that correspond to the actual behavior. I do agree that it should start with the word AUTH in terms of its correspondence with AUTH_IMMUTABLE_FLAG.
  • I don't think the word AUTHORIZED should be in here at all. In terms of trustline flags, clawback is orthogonal to authorization.
I don't have much to say about (1) except that perhaps we can provide functionality for this in SDKs to reduce duplication of effort throughout the ecosystem. As for (2), I would think it is generally surprising if an issuer is regularly claiming claimable balances that
  • Have the issuer UNCONDITIONAL while other claimants exist
  • Were not created by the issuer
I'd see this as a general red flag that the issuer intervened. Perhaps there is some case that I'm missing, but I think a priori this is a good indicator. I agree it might not be too easy to query for this though.

Thanks,
Jon

Jonathan Jove

unread,
Jan 11, 2021, 4:22:10 PM1/11/21
to Stellar Developers
While working on implementation planning with Siddharth, it came to our attention that the following segment of the proposal doesn't cover all cases anymore:

Similar to other operations the clawback operation will fail if the account balance is less than the amount specified when account for selling liabilities. If clawback is required of asset amounts locked up with selling liabilities then the issuer may use the AllowTrustOp operation to revoke authorization of the trustline, which will cancel any existing ledger entries creating selling liabilities, such as offers, and issue the ClawbackOp in the same transaction. If the issuer wishes to allow the from account to continue utilizing the asset it can include another AllowTrustOp after the ClawbackOp to authorize the account once again.

The problem is that it will be possible to enable clawback without enabling revoke. Should we allow this combination in recognition that perhaps there is some unusual case where this is desired? Or should we disallow this combination in order to prevent issuers from making an inadvertent error? Or should we take some other course of action entirely?

Leigh McCulloch

unread,
Jan 11, 2021, 4:35:55 PM1/11/21
to Stellar Developers
I think part of the issue here is that clawback is revocation of the asset, which is why we explored reusing the existing revocable flag before. If we were building clawback and auth revocation together I would lean towards using a single flag. If we need a separate flag now because it's a new feature I don't think we should introduce arbitrary rules on flag combinations as that may be complex to maintain.

Would it be feasible to avoid this problem by continuing to reuse AUTH_REVOCABLE in the proposal, but have it cause the flag to be set on the trustline as in Siddarth's proposal?

Leigh McCulloch

unread,
Jan 11, 2021, 7:48:54 PM1/11/21
to Stellar Developers
I opened a PR against CAP-35 that adds the flags and logic that Siddarth shared.
I talked to Jon offline and kept AUTH_CLAWBACK_ENABLED_FLAG for the account flag to keep consistency with existing flags because introducing inconsistency makes the existing ambiguities in AUTH_REQUIRED and other flags even harder to reason about. I abandoned thoughts about reusing AUTH_REVOCABLE because it would impact backwards compatibility with existing assets.

I changed the trustline flag to CLAWBACK_ENABLED, removing the AUTHORIZED prefix.

I have also added a new operation, ClawbackClaimableBalanceOp, and a new claimable balance predicate UNCONDITIONAL_CLAWBACK, which must be used together to clawback a claimable balance rather than reusing the existing ClaimClaimableBalanceOp and UNCONDITIONAL. This makes it very explicit when a user has created a claimable balance that can be clawed back, and makes it transparent and distinguishable when an issuer claims or claws back a claimable balance. I think having a separate operation for all clawback operations is important for transparency and for tracking issuer clawbacks on the network. It's similar to why we didn't make the ClawbackOp a PaymentOp.

Thoughts?

Nicolas Barry

unread,
Jan 12, 2021, 7:56:23 PM1/12/21
to Leigh McCulloch, Stellar Developers
I think the biggest thing to close on from this thread seems to be on how we want clawback to work when dealing with `BalanceEntry`.

## Do we need a dedicated condition on balance entries to provide clawback capability?
This thread started with just requiring the presence of a condition for the issuer to clawback.
In the latest draft, this morphed into a special "clawback" condition (`CLAIM_PREDICATE_UNCONDITIONAL_CLAWBACK`) so that issuers can distinguish "routine" (as in non-clawback) claims, vs clawback ones.

I think making it easier to use for issuers is the right thing to do, but using a dedicated flag ` CLAWBACK_ENABLED_FLAG` (or similar) in the `ClaimableBalanceEntry` for this makes more sense:
* `ClaimableBalanceEntry` should behave more like a trustline - it's sad that we didn't leave a placeholder "flags" there (I think there used to be one in early drafts for `ClaimableBalanceEntry`), but it's easy to add. The flag would be inherited from the trustline from which the funds come from to create the balance entry.
* it's simpler to enforce proper use than ` CLAIM_PREDICATE_UNCONDITIONAL_CLAWBACK` - so there is no need to add new checks that the claimant matches the issuer of the asset
* for code that wants to avoid dealing with such balance entries, it's simpler code because they don't need to scan for that condition
* it's smaller (small win for the network) and doesn't require the additional reserve for whoever is sponsoring the balance entry (small win for the issuer)

## Do we need a dedicated `ClawbackClaimableBalanceOp` operation?
I think the case to do so is even stronger than for `ClawbackOp`.
It would be a usability problem for both the issuer and claimants.

For claimants:
`ClawbackOp` could instead be implemented by allowing to send a "negative balance" to a trustline - but such operation would still be easily distinguished from a normal payment, so would be easy to flag in wallets.
For a balance entry, if the balance entry has both the issuer as a standard (potentially conditional) claimant and the ` CLAWBACK_ENABLED_FLAG` and the issuer uses `ClaimClaimableBalanceOp` it would be ambiguous: wallets/apps for the other potential claimants would not be able to flag their owner that something extraordinary is happening.

For issuers:
only having access to clawback means that issuers cannot participate in contracts that place conditions on claimants, as conditions would always be bypassed by the `CLAIM_PREDICATE_UNCONDITIONAL_CLAWBACK` condition.

Nicolas

Leigh McCulloch

unread,
Jan 12, 2021, 8:42:44 PM1/12/21
to Stellar Developers
CAP-35 has been updated with the following changes.


- New operations `ClawbackOp` and `ClawbackClaimableBalanceOp`
- New account flag `AUTH_CLAWBACK_ENABLED_FLAG`.
- New trustline flag `CLAWBACK_ENABLED_FLAG` that inherits from the issuer account flag at the moment of trust.
- New claimable balance flag `CLAWBACK_ENABLED_FLAG` that inherits from the trustline of the account that creates it at the moment of creation.
- AllowTrustOp is changed to only operate on AUTHORIZED_* trustline flags.

@Nicolas, I agree the use of a flag on the claimable balance is simpler and straight-forward. The separate operation brings so much clarity and transparency to account history.

Leigh McCulloch

unread,
Jan 14, 2021, 8:15:53 PM1/14/21
to Stellar Developers
In the Open Protocol Meeting today we agreed on a few changes to CAP-35.

1. Move extensions at top of new ledger entry structs to top rather than bottom.
Moving the extensions to the top of new ledger entry structs gives greater freedom to how extensions are applied in the future.

2. Define shared non-native asset code type to use in AllowTrustOp and new ops.
Defining a shared asset code definition simplifies the existing `AllowTrustOp` and the new `ClawbackOp`.

3. Require that both are set auth revocable and auth clawback.
Requiring that `AUTH_REVOCABLE_FLAG` is set whenever `AUTH_CLAWBACK_ENABLED_FLAG` is set makes it harder for issuers to configure issuer accounts in such a way that they would be unable to clawback assets held by the selling liabilities of offers.

4. Make it possible for the issuer to unset the CLAWBACK_ENABLED_FLAG for a trustline.
Defining a way for an issuer to unset the clawback enabled flag from a trustline is a simple extension that rounds the feature out. It is possible to do this with the issuer and account participating in a co-signed transaction, but there is no known downside to the account holder and so the issuer should be able to take this action without coordination.

Items 1, 2, and 3 are updated in CAP-35. Siddharth is updating CAP-35 with item 4 soon.


Leigh

Bartek Nowotarski

unread,
Jan 15, 2021, 11:31:26 AM1/15/21
to Leigh McCulloch, Stellar Developers
Hey all!

I've opened a PR with minor changes: https://github.com/stellar/stellar-protocol/pull/829.

I also wanted to ask some questions. Sorry if already asked, I briefly checked this thread and could see similar questions:
  • I'm not sure if the proposal really solves the theft/fraud issues for liquid assets. Stolen funds can be easily exchanged to "non-clawbackable" assets. Maybe we should just remove from/rephrase in this CAP motivation list?
  • Do we really need amount in ClawbackOp? Alternatively, we can clawback entire amount and send smaller amount back in the same transaction. It can simplify the implementation.
  • Maybe we should explain what happens to sponsored claimable balances when clawed-back? I guess, the funds are just returned.
Bartek

--
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.

Leigh McCulloch

unread,
Jan 15, 2021, 1:53:12 PM1/15/21
to Stellar Developers

>Renamed CLAWBACK_CLAIMABLE_BALANCE_MALFORMED to CLAWBACK_CLAIMABLE_BALANCE_DOES_NOT_EXIST to be consistent with ClaimClaimableBalanceResultCode.
I think this makes sense. Let's merge it.

Responding to your comments:

>I'm not sure if the proposal really solves the theft/fraud issues for liquid assets. Stolen funds can be easily exchanged to "non-clawbackable" assets. Maybe we should just remove from/rephrase in this CAP motivation list?
The intention is to provide functionality to recover assets in those and other cases, but as you say doesn't necessarily solve all theft/fraud issues. The CAP doesn't claim to prevent stolen funds from being exchanged. Which phrase do you suggest being removed?

>Do we really need amount in ClawbackOp? Alternatively, we can clawback entire amount and send smaller amount back in the same transaction. It can simplify the implementation.
The amount is required to provide for minimum impact to the account that the asset will be clawed back from. If the amount to clawback is less than an account's selling liabilities the issuer does not need to interrupt the accounts offers if it can clawback a specific amount. If the issuer must clawback the full balance and reissue then the issuer must revoke the trustline to cancel offers which would probably be unnecessary in many cases.

>Maybe we should explain what happens to sponsored claimable balances when clawed-back? I guess, the funds are just returned.
Sponsored reserves never leave the account sponsoring them so there are no funds to return. Sponsorship of ledger entries is generic and sits outside of the claimable balance's own logic. I don't think anything is changing here with regards to that, and so we don't really need to discuss it in the CAP. I'm adding a paragraph to CAP-35 in https://github.com/stellar/stellar-protocol/pull/830.


Leigh McCulloch

unread,
Jan 29, 2021, 10:31:06 PM1/29/21
to Stellar Developers
Jon raised an interesting question on a PR implementing the ClawbackClaimableBalanceOp operation that I think is worth discussing here.

An issuer account can create claimable balances for an asset it issues, but it has no trustline to copy the clawback enabled flag from onto the claimable balance. The question becomes: what should the clawback enabled flag state be on a claimable balance created by the issuer? Should it be based on the issuer account flag, or always on. Should it be always off and rely on an issuer using a distribution account that has a trustline that has clawback enabled as true.

My thoughts are that it should be based on the account flag, because that is the most intuitive, it is also backwards compatible. New ledger entries in the form of trustlines on new accounts are based on the account flag, so it seems consistent in that regard. If an issuer needs to create a claimable balance that is clawback disabled it can change the account flag to off and on in the same transaction with the claimable balance create in the middle. This option doesn't defer any decisions though and it doesn't give us much room to change anything about this behavior in the future.

I don't think it is worth a second account flag, such as AUTH_CLAWBACK_ENABLED_ON_CLAIMABLE_BALANCE_FROM_ISSUER that controls whether issuer created claimable balances are clawback enabled because it could create confusion, but that is another option.

We could make issuer created claimable balances never clawback enabled, and if the need becomes clear we could add a second flag in a separate CAP, which would be backwards compatible. Or a distribution account can be used for all claimable balance creation.

I favor the account flag approach, but it doesn't defer any decisions.

Jon, Siddharth, there you have any other ideas I missed?

Justin

unread,
Feb 1, 2021, 9:51:01 AM2/1/21
to Stellar Developers
Hello all,

CAP-35: Asset Clawback is now in Final Comment Period pending acceptance.  At this point, anyone with remaining questions, comments, or suggestions has one week to bring them up on this thread.  If it turns out there is more to discuss, we will move the CAP back to Draft.  If not, we will mark it Accepted and move on.

In addition to this thread and the proposal itself, which is linked to above, you can also check out the two recent Open Protocol Discussions to find out more about the proposal:
Exciting stuff!

Nicolas Barry

unread,
Feb 1, 2021, 1:37:30 PM2/1/21
to Leigh McCulloch, Stellar Developers
> My thoughts are that it should be based on the account flag, because that is the most intuitive, it is also backwards compatible

I think this makes sense.

As for creating a balance entry without that limitation: I imagine that the better flow for an issuer would be to just use an auxiliary account that doesn't have the flag enabled (which avoids making changes to the issuer flag) as only a medium threshold is needed in that case.

Nicolas


--
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.

Siddharth Suresh

unread,
Feb 1, 2021, 2:11:03 PM2/1/21
to Stellar Developers
I think Leigh's solution makes sense. Changing the issuer flags only requires a medium threshold. I do agree with Nico though that the better path for issuers to take is to delegate creation of claimable balances to another account.

Jonathan Jove

unread,
Feb 1, 2021, 5:30:51 PM2/1/21
to Stellar Developers
When I had originally discussed the account flag approach with Siddharth, I had been opposed to it because I thought SetOptions requires HIGH threshold for account flags (this is wrong, it's MEDIUM). This would have been a big issue because it would have required HIGH to support issuer creates a clawback-disabled claimable balance while clawback is enabled. Upon reviewing the implementation and seeing my error, I think this is a reasonable solution Leigh.

--
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.

Leigh McCulloch

unread,
Feb 2, 2021, 3:07:00 PM2/2/21
to Stellar Developers
CAP-35 has been updated to reflect that the claimable balance created by an issuer account for an asset it issues derives its clawback enabled status from the account flag.
Reply all
Reply to author
Forward
0 new messages