BIP-0004: Staking contract update
Author: dharkmattr
Status: Final
Introduction:
The BabelFish staking contract was paused due to a security vulnerability that allowed for voting power theft. Specifically, a small amount of FISH could be staked at the same time and date as an existing stake, with a new delegate address passed as a parameter. This new delegate address would then receive the complete voting power of the stake. To fix this vulnerability and other issues, this BIP proposes several changes, including code refactoring and bug fixes, to the BabelFish staking contract.
The BabelFish staking and Bitocracy are a fork of Sovryn, with the initial intention of developing them further. However, it was later decided that this would be a waste of time and resources. Thus, it was concluded that the best way to move forward is to update and keep the staking contract up to date with the current version used by Sovryn. Updating the BabelFish staking contract to be compatible with Sovryn’s version was a big effort and very complex due to the changes required.
Due to logistical requirements for starting the vote on this proposal, the staking contract has been updated by the BabelFish multisig according to the changes specified below. This proposal seeks to retroactively approve this update. Should this proposal be approved, the update will remain in effect and the staking contract will be unpaused so that Bitocracy can resume normal operations. Should this proposal be rejected, the update will be rolled back/and or a new proposal will be put forth to address any community concerns.
Changes:
- Updating BabelFish staking contract to the version used by Sovryn, as updated staking contract code base will be easier to maintain going forward.
- Applying fixes to the discovered vulnerabilities:
- The staking contract was vulnerable to voting power theft, which allowed a user to delegate voting power associated with a specific stake by staking an arbitrarily small amount of FISH for the user at the same date and time, and passing a new delegate as a parameter. As a result, the complete voting power of this stake was delegated to the passed delegate address.
- The guard against multiple manipulations of the same stake on a single transaction can be circumvented because it is checking for the message sender address instead of the address to which the stake actually belongs.
- Separating the staking contract code into multiple modules, which can be deployed individually - due to the contract reaching the maximum possible EIP-170 solidity contract size.
Details:
The previous version of the contract, which was until recently on mainnet, can be found at:
The updated version, which has been deployed to testnet and mainnet, can be found at:
Additional reference:
Although not all changes were required by BabelFish, having the same base code was important to maintain compatibility and enable further updates if needed. For more detailed information on all the changes implemented by Sovryn, please refer to SIP-0049 and SIP-0058:
