[AIP-73][Discussion] Dispatchable token standard

[thepomeranian]

AIP Discussion

Summary

Right now the Aptos Framework defines one single fungible_asset.move as our fungible asset standard, making it hard for other developers to customize the logic they need. With this AIP, we hope that developers can define their custom way of withdrawing and deposit for their fungible asset, allowing for a much more extensible way of using our Aptos Framework.

Read more about it here: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-73.md

[alnoki]

Compilation of my comments thus far from elsewhere

@thepomeranian I've provided some commentary on this topic in several places but it's gotten disjointed so I'll start with a compilation of relevant posts, mostly in conversation with @davidiw and @runtian-zhou

On aptos-labs/aptos-core#12490:

1. [Feature Request] Dispatchable Fungible Asset Standard aptos-labs/aptos-core#12490 (comment)
2. [Feature Request] Dispatchable Fungible Asset Standard aptos-labs/aptos-core#12490 (comment)
3. [Feature Request] Dispatchable Fungible Asset Standard aptos-labs/aptos-core#12490 (comment)
4. [Feature Request] Dispatchable Fungible Asset Standard aptos-labs/aptos-core#12490 (comment)
5. [Feature Request] Dispatchable Fungible Asset Standard aptos-labs/aptos-core#12490 (comment)

On aptos-labs/aptos-core#12635:

1. [aptos-framework] Dispatchable Token Standard aptos-labs/aptos-core#12635 (review)
2. [aptos-framework] Dispatchable Token Standard aptos-labs/aptos-core#12635 (comment)

Summary

Generally, I am concerned with how behaviors like tax on transfer will affect DeFi accounting and break correctness guarantees currently offered by existing standards. Generally, however, these concerns are alleviated so as as there exist two APIs related to transfers:

1. A transfer API that enforces a fixed amount is withdrawn from the sender
2. A transfer API that enforces a fixed amount is deposited to the receiver

Questions on current implementation

Per Telegram discussion with @davidiw:

Withdraw must withdraw exactly the expected amount from the users balance

Question 1. Is it correct to assume that this can be used in a transfer context with the condition fixed amount is withdrawn from the sender?

There's a dedicated deposit function transfer_assert_minimum_deposit for ensuring that a minimum is deposited.

Question 2. Could this be extended for the case transfer_assert_exact_deposit, to meet the condition fixed amount is deposited to the receiver?

[davidiw]

@alnoki ,

Question 1. Is it correct to assume that this can be used in a transfer context with the condition fixed amount is withdrawn from the sender?

Yes. All calls to withdraw have the assertion on fixed amount withdrawn. Of course, that doesn't mean the output amount of withdraw is guaranteed.

Question 2. Could this be extended for the case transfer_assert_exact_deposit, to meet the condition fixed amount is deposited to the receiver?

The window for the first release, 1.12, is likely missed. I think my concern here is that if there is any dynamics in the call, this may be hard to guarantee, while minimum is likely more easily guaranteed. We could add the API, but figured it would be good to discuss if both are needed.

[alnoki]

We could add the API

@davidiw Please do! Looking forward to it :)

FYI one implementation could be a version that just uses the minimum deposit under the hood, and "refunds" any extra back to the sender

[davidiw]

We could add the API

@davidiw Please do! Looking forward to it :)

FYI one implementation could be a version that just uses the minimum deposit under the hood, and "refunds" any extra back to the sender

Ahh, this could be done, there's a tradeoff, of course, that the user could be double taxed... not sure that's better but maybe in some cases it is.

[alnoki]

that the user could be double taxed

@davidiw could this be avoided by doing some kind of forced direct transfer for the refund portion? E.g. in current implementation I've seen all kinds of admin-level permissions to do things like this, seems doable

Just flagging that for such a case then events should only be emitted after the refund