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
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.
The text was updated successfully, but these errors were encountered:
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).
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.
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?
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).
Feature Description
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.
The text was updated successfully, but these errors were encountered: