search

windranger-io / windranger-treasury

Apache License 2.0
16 stars 7 forks source link

[Feature] Initialise a Bond from another Bond #65

Open CjHare opened 3 years ago

CjHare commented 3 years ago

Feature Description

Individual bonds can be upgraded by depositing the derivate (receipt) bond token into another bond that accepts it.

Upgrading a bond is done by creating another bond contract and migrating the previous version across.

Support this by adding another init function, that accept an existing bond contract

From the deprecated Bond contract: Extract the debt tokens (ERC20). Extract the collateral (ERC20)

Additional Information

The new version may benefit from creating a separation between the bond and debt tokens (the bond no longer extend ERC20), but there would be more external call & gas cost. A quick analysis to compare each of the ops may be warrented.

CjHare commented 3 years ago

@shahankhatch Does the issue description align with your ideas on the upgradability for bond contracts?

shahankhatch commented 3 years ago

A couple of approaches to consider:

  1. the above init from another bond implies new bond2(bond1instance), initializing the new bond with the bond1instance's erc20 registry. Note that collateral is maintained in the erc20 token's contract (so bond1instance needs to update the address or transfer).
  2. Allow the execution logic of the bond to be upgraded in the case of a blanket bond upgrade (maybe as simple as a proxy-based upgrade). This could potentially be similar to (1), where the constructor sets the proxy for the updated execution logic.
  3. A separate tool for claiming an upgraded bond token by submitting their existing bond token. This implies bond2 is instantiated, the user then submits their bond1tokens and obtain bond2tokens (perhaps at a different ratio), and the claim tool itself updates erc20 addresses and amounts.

It may be the case a bond will go through all of these approaches thoughout its lifetime. wdyt?

CjHare commented 3 years ago

The description definitely leans towards 1.

Option 2 is likely to require altering the Bond contract we have today (create the separation of logic), which means implementing a feature we don't need today in a contract we do. Also here's the currently unknown variable of whether cloning will be used and how that affects the mix 🤔 ...actually creating the bond via cloning may provide the mechanism you're describing the Option 2.

Option 3 does have a scalability risk (potentially costly), as the gas increase has a linear relationship to the number of holders (initially only a few holders, but if we're aiming for a generic toolset for others it could be a concern for others).

The Option 3 description muddles together an upgrade with dilution ...was that intentional? (As the intent of this ticket was a straight upgrade without dilution).