Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Bonded Fungible Tokens #1671
Bonded Fungible Tokens
A bonded fungible token is an ERC20 standard compliant token with a price and supply controlled by an automated market maker known as a bonding curve.
The bonding curve is a smart contract which holds a
From a user perspective, it is a method of buying or selling a token directly from a smart contract and which the price of purchase or reward for sells follows a pre-defined and determined price path.
Although the concepts of an automated market maker and bonding curve to control the price and supply of tokens is not new, it has been used most notably in the Bancor protocol, it has yet to be given a standard interface that developers can follow in implementations.
Bonding curves are a promising mechanism for the tokenized future. By standardizing the interface, we can begin to allow community tools such as Etherscan and other block explorers to integrate information about these tokens automatically. Since the token is traded through the contract, we should be able to pull details such as the market cap of the token or the current price to display on UIs. A standard interface will further allow developers to build bonding curve tokens into more complex systems such as nested curves.
Imagine using Dai as the reserve asset for an example bonded fungible token, EXP. Community tools such as block explorers could include the current price of EXP straight in their interface by keeping up to date with the return value of the
Besides front-end conveniences, there are also low-level interoperability constraints that we should keep in mind as more developers start to build systems which use bonded tokens and bonding curves.
Example source code and some test cases have been implemented in milky-way
Copyright and related rights waived via CC0.
I have a few thoughts on the spec:
I agree with the previous comments. Some other things to consider:
P.S. nice work on kick-starting this EIP!
Thanks for the comments! It's good to see more people here :)
I have thought about this! One point this brings up is whether the bonding curve should be separate from the token. That is, should a bonded fungible token be permanently bonded, or can it be unbonded? If it was ERC777 operator then it would imply that one could remove the operator and "unbond" the token.
This is a good point.. but one issue @acrdlph and I have discussed is the UX hurdle of sending value without knowing the amount of tokens that they are getting back for it. From a technical perspective it can be more "fair" to the user (especially in the case of batch transactions) but how do we communicate this to the end user?
I agree about this. Do you think
I intended the 'reward' to be the amount of the
@lsaether Yeah, that's a fair point and I'm unsure how to best solve it. The reason I'm very opinionated in this is that I've implemented it in the way you are suggested and played around with it in a UI that allowed you to specify the # tokens you buy. It happened frequently that two people would buy some tokens in the same block and for one of the users the tx would fail. This is really bad UX and only one buy tx per block is not going to work for popular tokens.
I'm actually leaning towards not talking about the number of tokens you have in the bonding curve to the user. Instead the UX would be something like "Invest
I just think specs should contain the bare minimum that is required. There are a number of ways this could be implemented based on the use case. I just don't think this is so critical to the definition of a bonding curve that it must be hardcoded in to the spec for every implementation.
Alternative ways to solve the slippage issue would be have the user optionally set some
I also think for many use cases that users would rather just accept some slippage than have their transaction fail. If the transaction fails, it's like they lost their spot in line and they might have to try again at an even higher price than they would have if they just took the slippage on the first transaction, if the price is going up. In the reverse case, of one or more sells happening right before them, they likely would not mind receiving more tokens than they expected.
That's what I'd use.
I can't think of a concise name for this. When I come across this situation in my own code, I usually jam many words together, for better or for worse. So, my inclination is something like