Open ipatka opened 5 years ago
The verified Token Controller code has been added to the controller contract.
https://etherscan.io/address/0xfcc9774d0498b2ab2e53988bcb7c5860dcd3ceb4#code
pragma solidity 0.4.15;
import "./MiniMeToken.sol";
import "./BLT.sol";
import "zeppelin/ownership/Ownable.sol";
/* Temporary controller for after sale */
contract PlaceholderController is TokenController, Ownable {
BLT public token;
function PlaceholderController(address _blt) public {
token = BLT(_blt);
}
function changeTokenController(address _newController) public onlyOwner {
token.changeController(_newController);
}
// No buying tokens
function proxyPayment(address) public payable returns (bool) {
require(msg.value == 0);
return false;
}
function onTransfer(address, address, uint) public returns (bool) {
return true;
}
function onApprove(address, address, uint) public returns (bool) {
return true;
}
}
The owner of the PlaceholderTokenController
contract is the Bloom Multisig.
https://etherscan.io/address/0x9d217bcbd0bfae4d7f8f12c7702108d162e3ab79
While the current Token Controller contract does not implement functions to mint or burn tokens the Bloom Multisig could change the controller to a contract that does have those functions. Therefore the key holders of the Bloom Multisig should relinquish admin control of BLT through one of the following options.
PlaceholderTokenController.transferOwnership(0x0)
to make it so the controller can never be updated to a contract that mints/ burns tokens.These two options are probably equivalent. Some analysis is needed so see if one is more efficient or has some gas savings.
Simple Summary
Remove privileged keys from BLT contract. Bloom currently holds keys which enable the holder to have administrative control over some token functionality. These privileges should be revoked by relinquishing ownership.
Abstract
Remove privileged keys from BLT contract. Bloom currently holds keys which enable the holder to have administrative control over some token functionality. These privileges include granting vested tokens, minting tokens, burning tokens and freezing transfers. These privileges are commonly found in dApps with ERC20 token as they allow project creators to respond to discovered vulnerabilites. However in order to be a truly decentralized protocol these privileges must be revoked. This BLIP proposes a procedure to revoke admin privileges from the Bloom Company over the BLT ERC20 token.
The
Token Controller
may not be able to be self destructed or burned by transferring control to the0x0
address. This is becase theToken Controller
is a smart contract that implements certain methods which are called during allBLT
actions like transfers. If the controller is disabled improperly it will freeze all ERC20 functionality.Motivation
Make Bloom's token trustless and decentralized in support of the company's mission.
Specification
Relinquish Token Controller keys
First, the code at the
Token Controller
address needs to be analyzed. The controller may have been implemented a number of ways as long as it implements the interfaces below. Some of the administrative features may be disabled by default.Relevant Addresses
BLT
MiniMe Vested ERC20 Token: 0x107c4504cd79C5d2696Ea0030a8dD4e92601B82e
Vesting Whitelister
Bloom Token Sale Contract: 0xB547CC51CE58293E6945bA08d664ce051563d9Ac
Token Sale Owner
Bloom Multisig: 0x9d217bcBD0Bfae4D7f8f12c7702108D162e3Ab79
Controller
Unknown Token Controller Contract: 0xfCc9774d0498b2Ab2e53988bCb7c5860DCD3CEb4
Token Factory
Contract Address: 0xF418Eed07958f018d484B8D43e1af1249CCe0B6E
Configuring
Only the
Controller
has the ability to change theController
address. Since the controller is a contract this will only be possible ifchangeController
is implemented by the controller implementation.Minting
The
Controller
has the ability to mint tokens via thegenerateTokens
method. This privilege can be removed by disabling this functionality in the controller contract. This, along with removing the burn method will keep the BLT total supply constant at this implementation address (See Cloning).Burning
The
Controller
has the ability to burn tokens via thedestroyTokens
method. This privilege can be removed by disabling this functionality in the controller contract.Freezing
The
Controller
has the ability to freeze token transfers via theenableTransfers
method. This privilege can be removed by disabling this functionality in the controller contract.Cloning
Any user can call
createCloneToken
to deploy a new token based on the token balances of theBLT
contract at the specified block. This process requires no special privileges so it is unaffected by this proposal.Granting vested tokens
There may have been addresses that were given the ability to grant vested tokens. Bloom does not plan to use the integrated vesting methods of the BLT smart contract in the future so these privileges should be revoked before burning the
Vesting Whitelister
privilege. The grant whitelisting function does not emit an event so the only way to see if an address has token granting privileges is to scan through all BLT transactions.The
Vesting Whitelister
is still set to theBloom Token Sale
contract, which is owned by theBloom Multisig
. The token sale contract only appears to have used thegrantVestedToken
function in theallocatePresaleTokens
function.Revoking granted tokens
The
Vesting Whitelister
has the ability to revoke a token grant. This is only enabled if the grant was specified asrevokable
on creation and if theVesting Whitelister
is also the listed granter. The tokens can either be burned or sent to the receiver specified by the revoker. This functionality will be unavailable once theVesting Whitelister
key is burned.Managing active grants
If there are any active token grants, they should not be affected by this change. When tokens are granted they are immediately transferred from the granter to the recipient. Then each time the user tries to transfer some of their token balance, a calculation is performed to determine if the granted tokens have vested and may be released. This calculation does not require the
Vesting Whitelister
to exist or for the granter to exist. Therefore any active grants will not be interrupted by burning all privileged keys.Claiming Tokens
If tokens or ether are sent directly to this contract address the
Controller
has the ability to recover the funds. If the controller key is burned there will be no way to recover tokens or ether mistakenly sent to this contract.Rationale
All BLT contract code was reviewed and the relevant state variables were read from etherscan.
The actions outlined in the specification section are motivated by the desire to make BLT entirely trustless while being cautious to ensure we do not accidentally disable the token functionality.
Backwards Compatibility
This change is fully backward compatible with all third parties that interface with the BLT token. The contract address and ERC20 function interfaces are not changing.
Test Cases
No core ERC20 features are affected. Modifying the
Token Controller
contract must be done carefully. If a newToken Controller
contract is implemented that fails to implement the required methods all BLT functionality will be frozen. We will do a test run of the intended action both on a local testRPC and on a public testnet such as Rinkeby.Implementation
Implemenation will be outlined upon review of this draft. This proposal will be updated with implementation plans prior to execution.