The Great Migration
Solving Protocol Upgrades in an Immutable World
Another important aspect is to future proof the protocol - how can one do that with an immutable infrastructure and staying true to the core of its ethos? Upgradeability is a no-go in fully decentralized platforms and for good reason - apart from introducing limitations and disadvantages using such proxy systems. At the same time the current shenanigans in existing protocols donβt do its decentralized beauty any justice by making upgrading a laborious process, forcing the user to manually migrate the locked liquidity to the new version. For this, we propose a new system, introducing actual future proofing and making any future upgrades simple and automated: We call it βUpdateableβ contracts.
They differ significantly in its makeup to βupgradeableβ contract, in that when updated, the underlying tokens, functions, etc. are not simply changed to a completely new, separate set, but rather βupdatedβ (hence the term) pointing to a new contract, but with the pre-existing infrastructure intact - All controlled by an admin contract. One keen-eyed observer might now postulate the same problems, that plague upgradeable contracts, however there is a main difference: the access keys to the admin contract can easily be relinquished by the initial admin and awarded to a DAO, that now has granular control over the protocol, and only enacts changes through the collective power of the community henceforth.
This makes it a much more enjoyable experience for any user, as finally this cumbersome element of decentralization would move into the background and can always enjoy the most up-to-date product, without worrying about keeping an upgrade calendar and moving around their liquidity manually and without compromising the integrity and decentralization of the project.
Last updated
Was this helpful?