AEX 9 - Fungible Token

[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?

[robert]

Today, unfortunately not.
Compliant token transfer requires a reference parameter (as described in AEX-11), so the function signature is not compatible.
We can either request update of the AEX-9 or extend the wallet to support two types of tokens (as a variant).

[Kryztoval]

But isn’t this the whole idea behind ethereum tokens?
that you can basically input a contract number and transfer tokens that are dsigned with the standard?

So how come this is not part of the standard of aeternity if aeternity is trying to do things in a better way than ethereum did?

Ummm, I’ll have to think about this deeply.

[bruteforce.chain]

The goal of AEX-9 was to have a basic token standardized (interface) so later on people can build on top of it.

There is no way to know what people will be using tokens for beforehand, nor how they will want to extend the basic token functionality.

This is the aim of AEX-9.