Custom tokens should emit clawback events

[chowbao]

Proposal

Custom tokens (non SAC) should define token clawback where it should emit a clawback and burn event similar to SACs

Changes

Clawback Event

The `event` event is emitted when an amount of the token is clawed back.
Clawbacks should also emit a `burn` event for the amount burned.

The event has topics:

- `Symbol` with value `"clawback"`
- `Address` the admin address.
- `Address` The address holding the balance from which the clawback will take tokens.

The event has data:

- `i128` the amount clawed back.

Reasoning

CAP-46-06 defines how SAC should do clawbacks. It would make tracking custom tokens and SAC tokens balances through contract event streams much easier if both had at least the same events defined. Adding the clawback event will create complete contract event parity

[chowbao]

Note that distinction between a separate clawback and burn event and the existence of a distinct clawback event is being discussed here

[leighmcculloch]

If we think distinguishing clawback is important, then why not say that the token may be removed from supply either via burn, or via clawback?

👍🏻 After more thought I'm changing my opinion and think this is reasonable, that SEP-41 can get a clawback event, but no function to perform it similar to the mint proposal, and that clawback event should can be described in a way that is optional (without necessarily using that word, since most elements of the standard are ultimately optional). It can say that the event should be interpreted by external systems as a burn with a different cause, and that the event is intended to be useful to tokens that allow for burning by some action that is outside the control of the token holder, where there is value to signal to the community that token value has been reclaimed by the contract or token. Token implementations do not need to use it, but can if it improves the semantics and transparency of the contract's behaviour.

This pattern of continuing to heap on SEP-41 doesn't scale, but the SAC is the default SEP-41 token, so we should avoid significant divergence in their semantics and behaviours. And clawback is a reasonably generic behaviour that custom tokens that don't support it can just never generate an event for.

-- #1589 (reply in thread)

In addition to ☝🏻 I'd add the admin field in the event should be dropped.

Why: SEP-41 has no concept of a single admin address, for good reasons, it's outside it's lane to define the permission / auth system for the operator or operator-like component of the token.

While that will be incompatible with the SAC, I think that should be changed in the SAC too.

[chowbao]

Discussion never really picked up for adding the clawback event to SEP-41.

With that said are we in favor of adding an (optional 🤫) clawback event to SEP-41?
This does NOT define a clawback() function but rather requires the SEP-41 compliant contracts to emit a clawback event whenever a token is clawbacked.

contract: asset, topics: ["clawback", to:Address], data: amount:i128