AEX-11: Compliant Fungible Token Standard

Sophia Smart Contract Development AEXpansion Proposals
1

Hi,

At æternity Universe I gave a talk about regulated tokens / compliant tokens and created the AEX-11. The motivation is to have solid foundation for handling tokens which face any kind of legal regulations (payments, securities…) and make sure there is a first class tooling support. Hence we need a standard.

Few addons to what AEX-9 proposes:

  • dapps require more functionality for managing someones else tokens.
    Eg: simple “allowance” can’t restrict how the funds are used. This can be an issue for exchanges.
  • handling transfer reference
  • atomic respond to transfers - we need to handle a callback on transfer in the same transaction.

More details are here: AEX-11: Compliant Fungible Token Standard by robert-zaremba · Pull Request #95 · aeternity/AEXs · GitHub

3 Likes
2

Update here:
The AEX got merged as a draft. If anyone will like to share an opinion please do so.
I will have a bit more time next week to catch up.

1 Like
3

AEX-9 and AEX-11 collide on transfer function definition.
If we will keep it as is, then wallet will need to know if token is AEX-9 or AEX-11 in order to make a right call.
Maybe it’s worth to consider a following idea: changing a function name in this standard (AEX-11) transfer to spend.
Any feedback?

Reference: AEX 9 - Fungible Token - #51 by robert

1 Like
4

AEX-11 is much better for the semi-decentralized onchain applications, I like it!

AEX-9 and AEX-11 could be prepared for different scenario?

2 Likes
5

@LiuYang.chain AEX-9 is focussed to be a very simple token, the AEX-11 currently has way more functions for the motivation it follows, e.g. operators.

@robert what is the current status and plan of AEX-11?

1 Like
6

@robert I have a few questions/comments regarding AEX-11.

  1. What does the interface of init look like? (How is the first operator set?)
  2. You reference Call.caller being used to identify origin, which may be another contract, is this intended?
  3. There is no 0x0 address in sophia, as its not a valid address type, I’d add a specific burn function instead of missusing addresses for burn.
  4. Do I understand correctly that operators may transfer from any account?
7

It’s a Draft.

Ad 1. Depending on implementation. In the most basic version it assigns an owner, name etc…
Ad 2. Yes
Ad 3. Fair point - I didn’t finish the implementation.
Ad 4. Yes.

3 Likes
8

Interesting news from the Tezos camp:

Tezos ecosystem evolves: The NYX Standard. Equisafe, Nomadic Labs and OCTO Technology join forces and build the most sophisticated smart contract package ever developed.

I’m working with a lawyer on another project and we are discussing how we can create a value with Aeternity. Having a regulated and verified standard is only one part of it (others are related to legal / business frameworks).

As soon as we will have a grant for this project, we will be able to connect the standard with a legal prose and finish it.

2 Likes
9

Hi,
Recently, in Switzerland I was writing a bond token (security) for a client. There is a framework on how to leverage existing, legacy, Ethereum ecosystem of tokens, but we don’t have a good solution for wallet. No doubts that there are tokens coming up with support to ERC-1404.

I would like to see more validation on waellet and aeternity side. Can anyone share some comments? I’ve contacted the foundation to see if there is interest to move forward with AEX-11 but we need more feedback.

2 Likes
10

Yes, this needs to be a bit more specific and it would also help to divide it into milestones. If the project gets too big or too expensive it will be a bit “out of scope” for the foundation. The current focus is to maintain the core protocol and essential components.

1 Like
11

Hi Emin,

I think I split it down into milestones. Don’t have it at hand but it was something like:

  1. Reference implementation + tests
  2. Tutorials / blog posts
  3. integrations.