You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 11, 2019. It is now read-only.
Design: A bonding curve token would be bonded to a curve for a limited amount of time. The owner of the curve would designate the time on deployment and it would be stored in the contract as a uint256 bondPeriod or if being implemented in Vyper, a timedelta. The token would be only bonded to this curve for the length of time specified, be it one week, six months, or three years.
At the end of the bondPeriod there are a few options to consider:
The ether held in reserve is sent to an address target. This scenario may be used for fundraising campaigns where a "refundable" property is desired for a trial period of time. The curve in this case can be slope = 0, and therefore just a continuous release mechanism where the price remains a constant uint256 price. The slope can also be any shape allowed by the Arc library.
The ether in reserve is equalized among all token holders where poolBalance / totalSupply will determine the withdrawal amount equal to one token. This scenario could play out in the case a community wants to pool funds while limiting the number of later participants, then make the system exit-able in equanimity. The tokens could represent the vote of how the pooled funds should be employed. Not convinced about this use case at all and I think the game theory would say that it's easily capturable.
The token could remain bound to a curve, but at the end of uint256 bondPeriod the curve function could be switched out for a new one retaining the old function for the <=totalSupply at the block where finalized is called. This one could be interesting.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
AKA the "ticking bomb" 💣
Design: A bonding curve token would be bonded to a curve for a limited amount of time. The owner of the curve would designate the time on deployment and it would be stored in the contract as a
uint256 bondPeriod
or if being implemented in Vyper, atimedelta
. The token would be only bonded to this curve for the length of time specified, be it one week, six months, or three years.At the end of the
bondPeriod
there are a few options to consider:address target
. This scenario may be used for fundraising campaigns where a "refundable" property is desired for a trial period of time. The curve in this case can be slope = 0, and therefore just a continuous release mechanism where the price remains a constantuint256 price
. The slope can also be any shape allowed by the Arc library.poolBalance / totalSupply
will determine the withdrawal amount equal to one token. This scenario could play out in the case a community wants to pool funds while limiting the number of later participants, then make the system exit-able in equanimity. The tokens could represent the vote of how the pooled funds should be employed. Not convinced about this use case at all and I think the game theory would say that it's easily capturable.uint256 bondPeriod
the curve function could be switched out for a new one retaining the old function for the<=totalSupply
at the block wherefinalized
is called. This one could be interesting.The text was updated successfully, but these errors were encountered: