What is Betoken's upgrade governance process?
In order to provide a simple user experience while maintaining a high decentralization level for Betoken, we use a governance system called opt-out governance to handle its smart contract upgrades.
Governance process
Betoken upgrade governance will be activated at the end of November, 2019. First vote will be allowed on December, 2019.
For each upgrade, there will be roughly four stages:
Decide whether or not an upgrade is needed
Decide which upgrade to accept
Investors withdraw funds if they don't like the upgrade
Migrate to upgraded contract
How does an upgrade governance occur?
There are three possible ways an upgrade may occur:
1. Developer-initiated upgrade
The developer of Betoken, who is specified by the existing smart contract, may unilaterally decide to initiate an upgrade.
During the Intermission phase of each cycle, the developer may decide to initiate an upgrade, and provide the new smart contract's address at the same time.
The managers may review the new contract during the cycle's Manage phase, after which investors may withdraw their funds if they don't approve of the upgrade.
Given that the managers do not object, Betoken will migrate to the new smart contract after the next cycle's Intermission phase has ended.
2. Manager-initiated upgrade
The manager community may collectively decide to initiate an upgrade, without the need for the developer's approval.
The quorum for all votes mentioned below is 10%
During the Intermission phase of each cycle, the manager community may decide to initiate an upgrade via a simple majority vote using their Kairo.
If the vote passed, then during the Manage phase managers may use their Kairo to vote on which smart contract should be accepted as the new version.
When voting for the upgrade target, the 27-day Manage phase is divided into nine 3-day chunks.
The first chunk is reserved for letting the news of the upgrade spread sufficiently.
In the second chunk, on the first day, the manager with the most Kairo (among managers who want to propose upgrades) proposes the candidate smart contract to vote on. During the remaining two days, managers other than the candidate's proposer may use Kairo to vote on whether or not to accept this candidate as the upgrade target.
If a super-majority (>75%) voted yes, then the candidate is accepted as the upgrade target. No further voting is needed.
If <=75% voted yes or the quorum was not reached, then we repeat the same process in the next chunk, where the manager with the most Kairo, excluding previous proposers, gets to propose the candidate.
Proposers may not participate in the current and future votes.
If no vote has passed after 5 votes (15 days), the upgrade is aborted. The last 3 chunks (9 days) are reserved for reviewing the upgrade target's code in the case where the 5th vote was successful.
After the unhappy investors withdraw their funds, Betoken will migrate to the new contract.
3. Managers override developer's upgrade
After the developer initiates an upgrade, if the manager community decides that the upgrade is bad/malicious, they may override the developer's decision by proceeding with the manager-initiated upgrade process during the Manage phase.
If the managers decided on an upgrade target after the Manage phase, then that target will be used. If not, then the developer's upgrade will continue normally.
Advantages of the opt-out governance system
Given that the developer behaves honestly, this system would have minimal disturbance on Betoken's normal operations. This ensures that Betoken's user experience, for both managers and investors, will be unaffected by smart contract upgrades, which is crucial for any consumer-facing product.
If the developer behaves dishonestly/maliciously, the community would be able to override the developer's decisions, and the investors can simply withdraw their funds if even that fails, so the security of the system and of the funds would still be maximally guaranteed.
While the developer is important to the governance system, they are not required for updates to occur. This means Betoken does not need any centralized authority to function, which ensures Betoken's robustness against attacks on the developer.
Last updated