Bruno: Bruno: Well my suggestion is migrate to a new token that has no controller and no mint/burn at all

We considered this initially, there’s a certain level of idealism that is quite appealing with this approach, and a goal we’re working towards. Unfortunately there’s more considerations that require a more pragmatic and tempered perspective which comes from having skin in the game.

This course of action has put other token projects, such as OMG, at a serious disadvantage in the uncertain socio-technical landscape of our industry, they cannot add functionality to their token. At the same time, it’s unreasonable to treat it like a base coin, because in that context there is recourse in changing by making upgrade suggestions in the form of soft/hard forks, as you know, erc20’s and smart contracts don’t have that option.

Hopefully you can see why having the ability to administer a token is favourable in such a young, temperamental technology, the next question is usually some variant of “why isn’t this governed better than a multisig?”.

That’s pretty easy to answer, I am not aware of any mature governance project that is simple, robust and risk-free enough that can be deployed that can be responsibly used to manage locked capital. We are quite close with Aragon, as you have astutely pointed out they are on the multisig. When the risk of moving to a DAO is minimal, we will.

As for distributing multisig signatories further, we had looked into distributing responsibilities of signatories for parameter updates on other smart contract components of the application, and it was found out that it was not favorable for exposing our contributors to the legal risks when it includes loss of capital. Given the failure in that scenario, it’s even more unreasonable to attribute the exposure to loss of value on the token.

The other issue here is that Carl and I control the salaries of the contributors, therefore I would be surprised if the community viewed these signatories to be considered more trustworthy, they should be people that are well reputed in the community and independent of Status.

The signatories that were chosen because they have very little social overlap and we find them all ideologically aligned and responsible. They certainly wouldn’t appease neither Carl or Myself unless they thought it was in the best interest of the greater community and for their reputation.

Citations for the owners of the keys are to be found here, and the outline of responsibilities have been publicly available since the beginning:

github.com status-im/status-network-token/blob/master/MULTISIG.md#signers # Status Community Multisig [0xbbf0cc1c63f509d48a4674e270d26d80ccaf6022](https://etherscan.io/address/0xbbf0cc1c63f509d48a4674e270d26d80ccaf6022) Required signatures: 3/5 ## Signers - Jordi Baylina, [Giveth](http://www.giveth.io/). [Address](https://etherscan.io/address/0x6b9ef02657339310e28a7a9d4b5f25f7c1f68d61). - Joe Urgo, [district0x](https://district0x.io/), [Sourcerers](http://sourcerers.io/). [Address](https://etherscan.io/address/0x904Ef6ff8E82478c5604d99884EB9Bcd7F73Cc36). - Hudson Jameson, [Oaken Innovations](https://www.projectoaken.com/). [Address](https://etherscan.io/address/0x02E3F16cA21cf0508835B190933ECbdE2f7f14DF). - Jorge Izquierdo, [Aragon](https://aragon.one/). [Address](https://etherscan.io/address/0x4838eab6f43841e0d233db4cea47bd64f614f0c5). - Status Research & Development Multisig. [Address](https://etherscan.io/address/0xa646e29877d52b9e2de457eca09c724ff16d0a2b). ## Responsibilities - The Status Community Multisig will serve SNT holders and the broader crypto community to ensure Status' stated mission is carried. - The Status Community Multisig manages the 29% reserve SNT allocation. - The Status Community Multisig can be used to solve hypothetical deadlock problems in the Status Research & Development Multisig to ensure resources won't get locked and the project will continue its course. This file has been truncated. show original

To have access to any of the functions discussed here, we would first have to update controller, which is the real concern, I suggest you setup a monitor for a contract call to this function to dump all your SNT holdings when triggered:

github.com status-im/status-network-token/blob/master/contracts/SNTPlaceHolder.sol#L61 owner = _owner; snt = MiniMeToken(_snt); contribution = StatusContribution(_contribution); sgtExchanger = _sgtExchanger; } /// @notice The owner of this contract can change the controller of the SNT token /// Please, be sure that the owner is a trusted agent or 0x0 address. /// @param _newController The address of the new controller function changeController(address _newController) public onlyOwner { snt.changeController(_newController); ControllerChanged(_newController); } ////////// // MiniMe Controller Interface functions ////////// // In between the offering and the network. Default settings for allowing token transfers.

Understand that this a burden of risk & responsibility that I do not want for myself nor would wish to impose on anyone else, and one I suspect we will shed ourselves of within the next 2 years.

And of course, there is the ultimate recourse for you, if you are not satisfied with the current setup and reasoning, then you do not have to hold SNT.