AEX 9 - Fungible Token

[bruteforce.chain]

@marco.chain Thank you for the feedback.

We want to standardize how tokens should be created and interfaced on a smart contract level (similar to ERC20, ER827 etc.)

can we propose a migration path for AEX 9 so that all of these tokens can be “transformed” into native tokens at a later point of time?

If we can agree on a token interface that satisfies the needs and the basic functionality for tokens on top of AE, I think we can work towards incorporating this into the state channels implementations (I think it wouldn’t be so hard to accomplish as you should be able to execute contracts inside state channel).

Before we can have the ability to have different tokens more flexible interaction (multiple token transfers and so on) with them we first need to agree on what a single token should be looking like and what features should it has. This standard is what we are proposing here in AEX 9.

We’ve planned and are working on several implementations of the token interface which are:

• swap-able token
• token with callback / approveAndCall
• mint/burn token with allowances
• standard token with fixed supply and allowances

there is also the https://itsa.global initiative which aims to define global token standards if I haven’t missunderstood something here. what is the role of aeternity there?

Regarding this - its one of those “organizations”, “alliances” and “associations” which you can guess what are doing since there is a membership fee involved.

[marco.chain]

@bruteforce.chain

If we can agree on a token interface that satisfies the needs and the basic functionality for tokens on top of AE, I think we can work towards incorporating this into the state channels implementations (I think it wouldn’t be so hard to accomplish as you should be able to execute contracts inside state channel).

well I think we need to distinguish the smart contract inside state channels from the “native token standard” because transferring tokens to (core) state channels would only be possible if there is a token standard integrated in the core protocol. otherwise it would “only” be possible to create the tokens inside the channel but it wouldn’t be possible to use these tokens on the main-chain. at least this is my understanding here.

[bruteforce.chain]

otherwise it would “only” be possible to create the tokens inside the channel but it wouldn’t be possible to use these tokens on the main-chain. at least this is my understanding here.

There is a way of transferring tokens from the state channel to the main-chain and this could be accomplished and implemented similar to how atomic swaps work or having lock and mint/burn mechanisms in the state channel implementation. Similar to what we’ve proposed in the swappable fungible token.

From what I understand your concern is about using fungible tokens inside state channels in a way how AE tokens are being used now. I think it wont be hard to implement this in the core, as inside the state channel you are dealing with signed messages and locked balances.

Nevertheless this proposal here is for on-chain fungible tokens. We are all aware that in an off-chain solution everyone is able to implement whatever they need or want, so I think there wont be a single generalized solution that works for everything.

Lets start with this, further on we can improve it with other standards or work towards implementing this in the core.

Lets involve some more people here to get their opinion on this: @ssh, @hanssv.chain

[philipp.chain]

@Kryztoval

Now that you read that text, does it seem good to return “None” when you are 100% expecting a Possitive float? It would make more sense to me to return a negative number to define a state like this address does not even have a record of this coin instead of returning None as a balance.

@NikolayAngelov

My suggestion is to have balance() and allowance() to always return a Number e.g. 0 (In case of Zero Balance or None ) and Actual balance. That way many newbie mistakes will be avoided for not checking or understanding that one case of returning None or Numbers.

Getting back to these comments, it is incorrect that the return value is either None or a non-negative integer. The return value is always strictly typed with type option(int) which is either None or Some(int) this will have to be handled by any implementation, e.g. as either Promise.resolve(number) or Promise.reject() in case of the JS-SDK.

[philipp.chain]

@marco.chain

IMO the goal should be to have at least 1 token standard that is integrated in the core protocol and usable within (core) state channel implementation.

There is a plan and idea how we might implement tokens on protocol level to be way cheaper and usable as first class citizens easily from contracts and in channels. These tokens are planned to be flexible, so they can be fungible, non-fungible and a hybrid of both.

They should be very simple and save in their default behavior, without the need for any lines of code as smart contracts, but also highly flexible in a fashion similar to generalized accounts, where some protocol default functions may be overwritten by attaching a smart contract.

This token standard would also be atomic swappable against any other tokens if both holders agree, making DEXs very simple and save to implement.

But with current planned features and maintenance topic this can’t be implemented until the last planned hardfork and thus will have to be community-governed afterwards.

[philipp.chain]

@marco.chain

• can we propose a migration path for AEX 9 so that all of these tokens can be “transformed” into native tokens at a later point of time?

with implementation of AEX-9 where we were thinking of a “swap-able” token extension and a not to complex mitigating smart contract it should be possible to swap AEX-9 to native tokens when existent. But a token contract developer will have to think of this ahead of time to make the token swap-able to be able to do this.

[ssh]

@marco.chain

can we propose a migration path for AEX 9 so that all of these tokens can be “transformed” into native tokens at a later point of time?

This seems like a good point for an informational AEX, proposing best practices for upgradability of smart contracts.

[philipp.chain]

Exactly, if you or @marco.chain have any input on how to do this best, we are happy to hear, but we thought of some way to that still needs refinement and discussion.

[bruteforce.chain]

I’ve updated the proposal, please take a look and give your feedback so we can move it forward.

[robert]

@kraykov

Can we have some kind of callback so 3rd party contracts (e.g. an exchange) would know that they’ve received a token?

This is a very valid use-case and it’s absence in erc20 is considered as a mistake.

[robert]

@martingrigorov.chain

Or we can have something like unapprove .

unapprove is not needed. Instead we should use approve(<address>, 0)

[robert]

@bruteforce.chain

I’ve updated the proposal, please take a look and give your feedback so we can move it forward.

Hi,
Thanks for a great work.
With one project we are thinking about doing a PoC with aeternity. Hence I would like to contribute a bit into this work and spec.

Just to add few cents:
Copy-pasting legacy Ethereum interfaces is not a solution, we should get the learning in order to provide better, bulletproof standards.

I will try to find some time this week to do a PR on the proposal based on my experience (I was working with many tokens in the Ethereum ecosystem).

[bruteforce.chain]

We already have change_allowance allowing you to modify the allowance however you want.

[philipp.chain]

@robert

we should use approve(<address>, 0)

keep in mind there is no 0 address in aeternity, as its not a valid address.

[robert]

the call here means 0 approval for address <address>. In other words, <address> can spend max 0 (so nothing).

[bruteforce.chain]

@robert Good proposition, here is an example implementation in the proposed referenece implementation.

Despite I think this is should be used based on the custom implementation of the token. We want to focus more on the interface itself in order to finalize it and accept it as the final fungible token standard for tokens on aeternity blockchain.

mradkov/aeternity-fungible-token/blob/93d109e49c157cb9439a87c129af51eacf7c8183/contracts/fungible-token.aes#L202-L211

[bruteforce.chain]

The standard proposal is moved to Review here:

Update AEX 9 - Fungible token proposal

Please give your feedback in the next following week if you have any so we can move it to final.

P.S. Also any help on the test coverage of the reference implementation is more than welcome.

[robert]

Great work with AEX-9

Following up with my talk at the Universe One conference, here is the proposal for a token which provides more “complete” functionality to be adopted in the real world.
AEX-9 is great for a generic stuff, but for anything related to value / money we need more.

1. We should be aware that to be compliant with a financial world, we have to add more

2. 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.

We already learned this in a hard way with ERC-20 and it’s legacy.

AEX-11 for compliant tokens.

Here is the proposal (work-in-progress) for token to be used whenever they have a mean of value storage and payment or to be used in exchanges:

AEX-11: Compliant Fungible Token Standard

[robert]

@philipp.chain - in my comment for aex-9 approve function, 0 is the amount (not an address).

[Kryztoval]

Will compliant tokens be transferable in the base aepps natively?

I mean, if you are already following the standard, and you do follow it directly, this should be a given, correct?