Skip to content

Latest commit

 

History

History
247 lines (201 loc) · 10.1 KB

cap-0036.md

File metadata and controls

247 lines (201 loc) · 10.1 KB

CAP-0036: Claimable Balance Clawback

Preamble

CAP: 0036
Title: Claimable Balance Clawback
Working Group:
    Owner: Tomer Weller <@tomerweller>
    Authors: Leigh McCulloch <@leighmcculloch>
    Consulted: Nicolas Barry <@MonsieurNicolas>, Jon Jove <@jonjove>, Dan Doney (Securrency, Inc.), Bartek Nowotarski <@bartekn>
Status: Rejected
Created: 2020-12-16
Discussion: https://groups.google.com/g/stellar-dev/c/hPhkXhrl5-Y/m/ZF6eJcqKAgAJ
Protocol version: TBD

Simple Summary

This proposal provides the Issuer with a means to claim assets stored in claimable balances in order to support regulatory requirements. This function can be used to:

  1. recover assets that have been fraudulently obtained
  2. respond to regulatory actions, if required
  3. enable identity proofed persons to recover an enabled asset in the event of loss of key custody or theft.

The proposal does not involve shared custody of the person’s account and does not affect custody of bearer assets in the persons account.

Working Group

This protocol change is being developed in conjunction with CAP-35 which was initially by Dan Doney and Tomer Weller. The working group include other authors and the consulted persons include key individuals familiar with the implementation of the core protocol and maintainers of Horizon and its SDKs.

Motivation

This protocol change shares the same motivations as CAP-35.

Goals Alignment

This CAP is aligned with the following Stellar Network Goals:

  • The Stellar Network should be secure and reliable.

  • The Stellar Network should enable cross-border payments, i.e. payments via exchange of assets, throughout the globe, enabling users to make payments between assets in a manner that is fast, cheap, and highly usable.

Abstract

This proposal introduces a new ClawbackClaimableBalanceOp operation. The AUTH_RECOVERABLE flag on the issuing account must be set to authorize a ClawbackClaimableBalanceOp operation submitted by the Issuing account. The ClawbackClaimableBalanceOp operation results in the claiming of a specific ClaimableBalanceEntry. The ClawbackClaimableBalanceOp operation only applies to assets issued by the source account. Assets that are revocable can be easily distinguished from traditional blockchain assets (bearer instruments) so that asset owners are aware of rights. The transaction results in revocation of all of the specified asset from the claimable balance and the claimable balance is destroyed as if it had been claimed by a claimaint.

Specification

XDR changes

This patch of XDR changes is based on the XDR files as they are after the XDR changes from CAP-35 are applied.

--- a/src/xdr/Stellar-transaction.x
+++ b/src/xdr/Stellar-transaction.x
@@ -47,7 +47,8 @@ enum OperationType
     BEGIN_SPONSORING_FUTURE_RESERVES = 16,
     END_SPONSORING_FUTURE_RESERVES = 17,
     REVOKE_SPONSORSHIP = 18,
-    CLAWBACK = 19
+    CLAWBACK = 19,
+    CLAWBACK_CLAIMABLE_BALANCE = 20
 };
 
 /* CreateAccount
@@ -346,6 +347,17 @@ struct ClawbackOp
     int64 amount;
 };
 
+/* Claws back a claimable balance
+
+    Threshold: med
+
+    Result: ClawbackClaimableBalanceResult
+*/
+struct ClawbackClaimableBalanceOp
+{
+    ClaimableBalanceID balanceID;
+};
+
 /* BeginSponsoringFutureReserves
 
     Establishes the is-sponsoring-future-reserves-for relationship between
@@ -475,6 +487,8 @@ struct Operation
         RevokeSponsorshipOp revokeSponsorshipOp;
     case CLAWBACK:
         ClawbackOp clawbackOp;
+    case CLAWBACK_CLAIMABLE_BALANCE:
+        ClawbackClaimableBalanceOp clawbackClaimableBalanceOp;
     }
     body;
 };
@@ -1193,6 +1207,27 @@ default:
     void;
 };
 
+/******* ClawbackClaimableBalance Result ********/
+
+enum ClawbackClaimableBalanceResultCode
+{
+    // codes considered as "success" for the operation
+    CLAIM_CLAIMABLE_BALANCE_SUCCESS = 0,
+
+    // codes considered as "failure" for the operation
+    CLAIM_CLAIMABLE_BALANCE_DOES_NOT_EXIST = -1,
+    CLAIM_CLAIMABLE_BALANCE_NOT_ISSUER = -2,
+    CLAIM_CLAIMABLE_BALANCE_NOT_REVOCABLE = -3
+};
+
+union ClawbackClaimableBalanceResult switch (ClawbackClaimableBalanceResultCode code)
+{
+case CLAWBACK_CLAIMABLE_BALANCE_SUCCESS:
+    void;
+default:
+    void;
+};
+
 /* High level Operation Result */
 enum OperationResultCode
 {
@@ -1251,6 +1286,8 @@ case opINNER:
         RevokeSponsorshipResult revokeSponsorshipResult;
     case CLAWBACK:
         ClawbackResult clawbackResult;
+    case CLAWBACK_CLAIMABLE_BALANCE:
+        ClawbackClaimableBalanceResult clawbackClaimableBalanceResult;
     }
     tr;
 default:

Semantics

An issuer clawing back a ClaimableBalanceEntry operates similar to auth revocation and the ClawbackOp operation introduced in CAP-35. Account auth recovation freezes the full balance of an asset in an account, clawback from an account provides fine grain control and allows an issuer to take out of an account and destroy a specific amount of an asset, and clawback of a claimable balance entry performs the same logical operation on amounts of an asset stored in a claimable balance.

In order to execute a clawback on a claimable balance, an issuer account must have its AUTH_REVOCABLE flag set. Once set, the issuer submits a ClawbackClaimableBalanceOp operation in the same way a claimant can submit a ClaimClaimableBalanceOp. No predicates on the ClaimableBalanceEntry impact the success of the clawback.

This operation does not require the signature of any claimaint accounts, or the signature of the account that created the claimable balance. The amount of the asset clawed back is burned and is not sent to any other address since the return of an asset to the . The issuer may reissue the asset to the same account or to another account if the intent of the clawback is to move the asset to another account.

Account

This proposal uses the existing AUTH_REVOCABLE flag in the issuer account AccountFlags. Existing behavior and meaning of the flag is unchanged.

ClawbackClaimableBalance Operation

The ClawbackClaimableBalanceOp operation destroys a claimable balance effectively returning the asset to the issuer, and burning the asset stored within.

The clawback operation requires a medium threshold signature to authorize the operation.

Possible return values for the ClawbackClaimableBalanceOp are:

  • CLAWBACK_CLAIMABLE_BALANCE_SUCCESS if the clawback is successful.
  • CLAWBACK_CLAIMABLE_BALANCE_DOES_NOT_EXIST if the claimable balance does not exist.
  • CLAWBACK_CLAIMABLE_BALANCE_NOT_ISSUER if the sourceAccount is not the issuer account of the asset stored in the ClaimableBalanceEntry.
  • CLAWBACK_CLAIMABLE_BALANCE_NOT_REVOCABLE if the AUTH_REVOCABLE flag is not set on the sourceAccount.

Design Rationale

The rationale for this proposal extends the rational as described in CAP-35. Claimable balances store value on the network and the same events of regulatory action, erroneous transaction, or loss of custody of a claimaint account, can result in an issuer needing to reissue an asset stored within a claimable balance. CAP-35 adds this capability to assets stored in accounts, and this proposal provides the same functionality to claimable balances.

CAP-35 allows an issuer to clawback specific amounts within an account but this proposal limits clawback to the full amount within the claimable balance. Claimable balances are immutable and there would be massive downstream impacts to changing the amount within a claimable balance.

Claimable balances cannot be recreated after they are destroyed with clawback because their claimable balance ID is generated from the transaction that creates them, and to recreate the same claimable balance would duplicate events in downstream systems. Issuers can reissue the asset in a new claimable balance configured with the same claimaints and predicates to recreate the claimable balance, but the claimable balance ID will not be identical.

Reusing the AUTH_REVOCABLE flag

The account AUTH_REVOCABLE flag allows the issuer to indicate that it has control over the use of the asset on the network. By including the AUTH_REVOCABLE flag in account flags, account owners may review the revocability of an asset issued by the issuer and have the choice to avoid this type of asset if they object to the implied trust in the issuer. Clawback is another form of an issuer revoking use of an asset with fine control over the exact amount that the issuer is taking out of active circulation.

Threshold

The clawback operation requires a medium threshold signature because it is changing the balance of an account and is more aligned with impact of a payment operation than an allow trust operation.

Protocol Upgrade Transition

Backwards Incompatibilities

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

The change does make it possible for claimable balances to be destroyed, and claimable balances could form an important part of series of transactions that form a logical contract. The use of a clawback could break existing contracts that did not consider the possibility of clawback. Issuers today who use the AUTH_REVOCABLE flag get the same capability by freezing claimaint accounts. Auth revocation is reversable meaning an accidental auth revocation if reversed would have no impact on a planned series of transactions that form a logical contract. However, a clawed back claimable balance recreated would have a new claimable balance ID and would not be claimable with pre-signed or pre-authorized transactions.

This backwards incompatibility could be avoided if claimable balances were mutable. If instead of destroying the claimable balance its amount was altered, it would be possible to reissue an amount to a claimable balance and the impact of an accidental or temporary clawback would be identical to that of a clawback of an asset from an account, or temporary auth revocation. Mutability of claimable balances has not been proposed because when they were introduced they were intended to be immutable.

Resource Utilization

No substantial changes to resource utilization.

Test Cases

None yet.

Implementation

None yet.