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.
AKA the "ticking bomb" :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 bondPeriodor 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
bondPeriodthere 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 / totalSupplywill 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 bondPeriodthe curve function could be switched out for a new one retaining the old function for the<=totalSupplyat the block wherefinalizedis called. This one could be interesting.