Closed pabloruiz55 closed 6 years ago
I prefer to go with pause feature and it is much better than self-destruct feature. We can read the data later if we want. @adamdossa @Everhusk views?
We could have a decommission / pause function - ideally we would use a layer of indirection over the top of our contracts to allow us to upgrade seamlessly, but this would be a big enhancement (similar to the way Aragon allow upgrades) so probably a future enhancement rather than something for now. Self-destruct is cleaner IMO, but dangerous if the contracts hold ETH or tokens (or permissions linked to ETH or tokens).
Yeah I think we should leave this at the Polymath.js/Front end layer, no need to bake it into the contracts and risk adding a potential attack vector.
Leaving it at the Polymath.js/front end layer would not be enough. Someone could still use the old contracts to create their ST/STO either inadvertently or on purpose. Given that we are going to release something on mainnet that will have minimal testing and 0 usage on a testnet, I'd insist on adding a failsafe.
Having a break-glass freeze (pause) function seems sensible to stop people generating additional STs in case of a major bug being found post-mainnet deployment. The function can be simple and controlled by a PolyMath multi-sig, so limited potential for misuse. It would not need to impact any existing STs / STOs, just prevent the generation of new ones.
Yes but then this leaves the control of the network up to Polymath, it should be up to the community to decide. In the case that nothing needs to change, there will always be an attack vector to shut the thing down forcing a required fork on the network.
Given that we are going to release the contracts on Mainnet only to have them decommissioned in a few weeks/months, I think we should add the possibility of pausing them so they can't be used anymore when we deploy v2 contracts. This will prevent people inadvertently interacting with older contracts.
We could do this or add the possibility of a selfdestruct.