-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bonded Fungible Tokens #1671
Comments
The |
I wonder if there is value in using #777 as a base... the operator functionality could be very useful. |
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 |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Bonded Fungible Tokens
Simple Summary
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
reserve
asset and increases or decreases the supply of a token, always determining the price based on the total supply and the amount held of the reserve asset.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.
Abstract
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.
Motivation
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.
Specification
Rationale
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
currentPrice
function.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.
Test Cases
Example source code and some test cases have been implemented in milky-way
Implementation
milky-way
Please suggest others.
Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: