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.
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 => ERC827 Token Standard (ERC20 Extension) · Issue #827 · ethereum/EIPs · GitHub) but last year vulnerability was found => Why ERC827 can make you vulnerable to reentrancy attacks — and how to prevent them | by Leonard von Kleist | ChainSecurity | Medium
Maybe we can think of something similar that does not have such vulnerabilities?
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!
Hey,
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.
Martin
Maybe I don’t make it clear enough. The standard that resolved the approve functionality is ERC827 Token Standard (ERC20 Extension) · Issue #827 · ethereum/EIPs · GitHub but they found an security vulnerability (link included in my original answer)
This is about callbacks right?
What about a specific proposal for what @martingrigorov.chain 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.
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.
Hey guys,
I have some concerns on the balance() and allowance() returning None.
The problem that it introduces is that afterward in case some other Contract or App uses this function they must implement additional Logic to specifically check if None is returned instead of just getting 0
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.
From my understanding, the only reason of having it return None is to actually give better UX in some cases and showcase that the user has None of the tokens, but this tracking can be very easily be implemented outside of this functions in case of such case is needed.
In summary, I think that the UX improvement should be left outside of the Standart and be the responsibility for the Apps that are built on top of it instead of having this in the Standart and forcing everybody to do additional Logic in their Apps.
It was implemented this way, but honestly I personally don’t think is a big of an issue, you only get to add an additional case if the balance() returns you None instead the typical 0 or a positive balance.
The None is not only showcasing that you don’t have tokens but also that you never had tokens in this particular contract.
If you have a balance of 0 this means you already had tokens sometime in the past.
This is adding an additional UX improvement for wallets or other software since you get additional info about user’s tokens balance.
If I understood you correctly:
I ask you if it is Day or Night and you say it’s 7pm. Which doesn’t really solve my question of whether it is day or night but, if I add a few lines of logic I can predict with enough accuracy that in the location i am at at that exact time it would be night today (but maybe not other day)
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.
Also, this totally breaks strict static type validation and is prone to several rookie mistakes and headaches debugging. Remember JavaScript and python? not surprising that those two languages have now strictly typed variants. I believe it is specially important in a proposal to make the returns consistant and predictable. Also moving the logic out of the network and into the visualization layer
I do believe it is important to tell that an address has have no such token, but returning something other than a number for a balance seems just wrong.
I agree with you on the point here on the strict return type. But on the other hand returning -1 balance is not a logical value to me as the handling of this would be almost the same as handling None.
What is the purpose of having optional types in Sophia if we aren’t going to use them?
P.S. I’m happy that this proposal is getting some attention now. Thanks
Yeah, what i was saying is that if they return an object you can actually return better states than just returning a mutable object that is to be cross checked. But idk, as I said, most languages that had no strict stating typing are going back to strict static typing.
regarding the AEX`s for tokens → what is the path of aeternity here?
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 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?
generally I think it would be great to have these things possible:
approveAndCall (already mentioned above)