Behavior of clawback function in SEP41

[orbitlens]

The semantics of the clawback function is not properly defined in the standard. While the classic clawback operation returns tokens to the issuer account (and therefore effectively always burns the entire clawbacked amount), the SEP41 standard does not define what should happen in this situation - whether tokens should be burned or deposited to the issuing contract balance. It also does not define events that have to be logged in such case, opening the field to wide range of interpretations.

If the clawback implies burning tokens, should the contract emit the burn effect after clawback effect? Or if it transfers tokens to the issuing contract address, should it also emit the transfer event in addition to clawback?

Such ambiguous definition leads to confusion for token issuers and indexers.

[leighmcculloch]

+1, thanks for highlighting this gap, the standard should gain greater clarity about these things.

If I recall correctly some of these elements were discussed during the planning and implementation of CAP-67, this is what I remember:

• clawback must reduce the amount of issued tokens (although if we think about this from observable behaviour, a non-compliant token that didn't actually burn the amount and instead shifted it somewhere would probably not break integrations)
• clawback must not emit the burn event, because:
  • the clawback event is intended to communicate the issuer/admin has burned the token, where-as the burn event indicates the holder or a party authorised by the holder has burned the token
  • to emit both would require lookahead/behind processing of multiple events to identify what a burn meant which can be challenging in stream processing systems where an event is the unit of work being streamed

I believe what I'm stating is consistent with CAP-67 also, or at the least its implementation.

[orbitlens]

clawback must reduce the amount of issued tokens (although if we think about this from observable behavior, a non-compliant token that didn't actually burn the amount and instead shifted it somewhere would probably not break integrations)

I think this notion kind of contradicts itself. The tokens are either burned or not. It directly affects balances and total token supply calculations. If the decision is shifted to the developer's side, then the contract must emit either burn (if the tokens were burned) or transfer event (if the tokens moved somewhere, e.g. to the issuing contract address) in addition to the clawback.

It's impossible to correctly index events for the tokens with unspecified behavior.

lookahead/behind processing of multiple events to identify what a burn meant which can be challenging in stream processing systems where an event is the unit of work being streamed

Looks pretty straightforward to me. If the SEP says that the clawback should be always accompanied either by burn or transfer event, the indexer can use the standard behavior of these events and use clawback only as notion of admin action, without adding duplicating asset burn logic inside it. So even if an event stream is ingested in the backward order, an indexer would be able to correctly work with the event. It's the question of semantics and clear standardization.

[leighmcculloch]

I think this notion kind of contradicts itself. The tokens are either burned or not. It directly affects balances and total token supply calculations. If the decision is shifted to the developer's side, then the contract must emit either burn (if the tokens were burned) or transfer event (if the tokens moved somewhere, e.g. to the issuing contract address) in addition to the clawback.

Yeah that's a good point. I think the clawback must reduce the amount of issued tokens and the account balance (burn).

[leighmcculloch]

If the SEP says that the clawback should be always accompanied either by burn or transfer event, the indexer can use the standard behavior of these events and use clawback only as notion of admin action, without adding duplicating asset burn logic inside it. So even if an event stream is ingested in the backward order, an indexer would be able to correctly work with the event. It's the question of semantics and clear standardization.

The issue is if a burn occurs without a clawback. When processing a stream of events you have to lookahead/back to look for if a clawback had proceeded or followed a burn. Having events stand on their own and be understandable on their own simplifies stream processing imx.

I think if SEP-41 is updated to reflect implementations like SAC and note that clawback event indicates a burn and no burn or transfer event is expected, we resolve the ambiguity without any need to rewrite event history for SACs or other tokens.

[orbitlens]

As someone who've been doing ledger processing for years, I don't see the issue. But maybe I'm biased.

Agree, the explicit note that the clawback event indicating a burn would be the best way to address this ambiguity. If a token issuer really needs to implement some other behavior (e.g. transferring clawbacked tokens to some address), they can issue mint event following the clawback. This will be consistent across SAC and SEP41 implementations.

[leighmcculloch]

Some prior conversation about clawback also emitting a burn event:

• SAC clawback should also emit a burn event #1589

[leighmcculloch]

Would this change clear up the ambiguity?

• SEP-41: Clarify mint and clawback effects on total supply #1859

[orbitlens]

Yes, looks way better, thanks @leighmcculloch!

[leighmcculloch]

@dmkozh @sisuresh Thoughts? ☝🏻