AEX 9 - Fungible Token

This is a draft proposal for creating a standard for fungible tokens. It is based on the ERC20 standard which has proven to be working one.

There are few implementations of similar functionality (fungible token) across various repositories, but they all lack a thing or two.

So here we are proposing a standard and an example working implementation which includes logging on-chain events, token properties such as name, symbol, etc.

We will be glad to receive more feedback on this.

cc @piwo


Hey, nice idea. I think it’s time to actually agree on a token standard, as we are soon releasing the decentralized exchange.

Food for thought: Is it possible to avoid 3rd party dAepps to always perform approve and then transferFrom
Can we have some kind of callback so 3rd party contracts (e.g. an exchange) would know that they’ve received a token? There is a standard in Ethereum for that (ERC827 => but last year vulnerability was found =>

Maybe we can think of something similar that does not have such vulnerabilities?

1 Like

Thanks for the feedback @kraykov! Will check the attack vectors found in 827 and get back to you.

Sounds good. I was trying to use the fungible token as a representation of shares, as such it woudk be beneficial to my use case to have a place where I can store the value at a point in time. isn’t this useful for the use case too? Besides having a fungible token that represents btc one to one for example, or son other esta el coin. what if a token represented a percentage of an unknown amount and that amount got updated idk every 100 key-blocks?

“fungible token that represents btc one to one”

This is called a wrapped token, but using this (after standardized) or similar interface you can achieve the functionality as you mentioned.

what if a token represented a percentage of an unknown amount and that amount got updated idk every 100 key-blocks?

This is a question of a particular token implementation. The proposed draft here is about the standard interface e.g. What functions and properties a token will need to have etc.

Not really specific, I am giving you use cases that - if they make really good sense - should be in the draft. I am not going out of my way making use cases that will be useful for 1 specificand unique token. The example I gave works for anyone creating shares of anything that is either any sort of shares, stock or participation. This would make the platform usable in a way that ethereum tokens are not used as right now.

Just like they asked you about the dex and triggers for that, that’s way more specific than my example was.

Do you have something specific in mind, how to implement this?

I think first we aim to create a simple fungible token interface, but for a later standard this would be a nice idea!


I agree with @kraykov if we can skip the approve process that would be great. There is/was a proposal for this as a standard in but it had some issues, but we can try to be better and resolve them. (I can try to find what exactly the standard was)

Also, if we can’t skip the approve, we can add an additional parameter to the approve function. Something like approval time. The idea is that if you had approved some amount of tokens, but they were not transferred in quite some time, for example, 1 year, they are still approved and can be transferred after two years also, but at that moment the user may don’t want to approve this transfer for some reason. Or we can have something like unapprove.


Maybe I don’t make it clear enough. The standard that resolved the approve functionality is but they found an security vulnerability (link included in my original answer)

This is about callbacks right?

What about a specific proposal for what @MartinG and you are referring to?

The approveAndCall functionality which is part of the ERC827 (an ERC20 extension) standard gives you the opportunity to call a function after the approve is executed. This means that you can call a 3rd party contract inside the approveAndCall

Therefore you can perform approve and transferFrom in a single transaction.

However as mentioned above security issue was found, so the standard was deprecated. If you can look at the vulnerability and see if this would also be applicable to Sophia, then we can also forget about it.


We will try implementing this in Sophia and test for the provided vulnerability to see if it is an issue in aeternity vm and if it is feasible to implement such token architecture in Sophia.

Also, feel free to submit a PR for this if you already have put thought and effort trying to make this work.

1 Like

approveAndCall aims for callback functions for exchanges, but the idea of combining approve and transferFrom seems different to me.

Please check the updated draft before todays aexpansions call.