AEX 9 - Fungible Token

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

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.

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.

2 Likes

But we an agree that knowing your balance and transferring tokens are standard operations that are included into the standard function definition and, as such, could be generically included in the base aepps just like it was included for the ae token (ethereum one) in any ethereum wallet that supports erc20 tokens.

Any customization, extension or extrapolation of functionality that deviates from the standard is precisely that, non standard. but for standard ones I think this is a must. Again this has been in ethereum for quite some time.

The waellet supports fungible tokens currently and you are more than welcome to experiment with those - see Utilities and features · waellet/waellet Wiki · GitHub

Base aepp and other wallets do not support this currently as it is not finalized yet AFAIK, but I understand what you mean.

I was gonna try, but I found out i can’t import the private key i use for testing from the sdk into the waellet because it generates a different address. So I created an issue in the project.

2 Likes

HI r0b0t0! I’m trying to experiment with fungible tokens utility in the waellet, but I have some doubts…
Should I first deploy a token smart contract, and the use its addres to add tokens? or to mint tokens? Maybe the problem is that I’m not sure about what is “add token”. I thought it was for adding a new token, but there is no place to add name and symbol of a token. I just can “search” a token.
Thanks!

1 Like

Hey @Horacio,

You need to deploy a token first.

I already deployed a contract, but for any reason I am not able to call it and add the token.
When I click “add token”, it hangs loading (or takes too much time, I’ve been waiting for two minutes aprox and nothing).
Also, I cannot choose any token for minting. Please someone check that all the utilities works rightly. Thanks!

The goal is to have minimum functional coverage.
If you are creating a token which in any jurisdiction could require some compliance then it’s better to have a look at AEX-11.

One idea could be to use two different transfer functions to avoid confusions and had a better wallet support. At this moment AEX-9 and AEX-11 collide on transfer function. So maybe I will change it’s name to spend.

@bruteforce.chain - what do you think? Either we make a transfer compatible otherwise I’m ok to change a function name in AEX-11.

3 Likes

hello @robert, I’ll sit down together with @bruteforce.chain to discuss AEX-11 the next days, we’ll ping you if we have some answers or questions here.

1 Like

@philipp.chain Great, what are you going to discuss? I suggest to make a decision about the transfer function. Rest can stay separated.

@robert We discussed this option together with @philipp.chain and decided that it will be best if the compliant tokens are proposed as a separate standard.

1 Like

The proposed standard was updated and we request to move it to Review.

Ref implementation: GitHub - mradkov/aeternity-fungible-token: Aeternity blockchain Fungible Token reference implementation. The implementation is based on the proposed AEX9 standard for creating and usage of Sophia smart contract-based fungible tokens.

4 Likes

OK.
What do you think about the transfer function - should I keep the same name? Can a wallet handle that that there will be 2 interfaces with same function name but different type?

1 Like

You can keep the transfer function name if you like. The wallets will need to have the interface for the contract anyways so this won’t introduce vector for confusion in anyway. :slight_smile:

2 Likes

Congrats on this achievement! Is there a full stack example that i could use for teaching purposes?

1 Like

There is an fungible-token-full.aes smart contract implementation here in github which you can use.

Currently, there is no front-facing app that allows you to visualize your interactions with the contract though, besides the example token-sale app we published yesterday - Tokensale example application - #5 by albena.chain

4 Likes

Thanks for your fast response!