Alleviation for centralization risks of calling "setOpSigner" and "setTreasury" in contract
For sake of some security issues consideration, we have to remain some functions to alter "signer" or "treasury" state of contract in some circumstances.
To alleviate the centralization risks of those functions of contract "BasicCoin.sol", we add "DAO"-like concept to prevent arbitarily call "setOPSigner" and "setTreasury()" even though the caller must be the owner of the contract.
The main strategies contains the following consideration:
Functions setTreasury() and setOPSigner() now require the tags set by accounts which set on deploy in array m_DAOList and not the owner as well.
The accounts in m_DAOList are required to be distinct addresses, and must be different than the address set as the owner on deployment. Even if the owner is later updated to one of these addresses, there are still three distinct addresses in use m_DAOList as there is no way to update these addresses.
To modify the m_Treasury or m_OPSigner address, here's the steps are taken:
The owner raise a proposal with 24 hours timelock for confirming by "DAO" member's setting. Only the accounts in m_DAOList can setting a proper value for the proposal in that period(in 24 hours from the proposal raising).
The owner sets the new address to be updated for the m_Treasury and the m_OPSigner, and at least 2 of the 3 addresses in the m_DAOList must have approved of the change within 24 hours of the proposal in order to execute the proposed update in functions setOPSigner() and setTreasury().
No operation is allowed including setOPSigner, setTreasury and setPrivilegeTag when the current timestamp exceed 48 hours from the time of proposal until a new proposal is raised.
Addresses in the m_DAOList can only verify one proposal at a time.
Also we provided a view funcion "viewDAOinfo" in contract for public reference of proposal. Heres's the explaination for the return values of that funcions:
”TAG“ is a uint value for a proposal: 0 - Disaggre 0x20 - Approval for “setOpSigner” 0x40 - Approval for “setTreasury“
proposal is the sturct stored a proposal:
struct proposal {
uint256 timeLock; // timestamp of the proposal raised
address newAddress; // proposed new address for Signer or Treasury
}
process of the setting functions calling
The Contract owner can raise a proposal (for calling setOpSigner or setTreasury) to change "Signer" or "Treasury", in the next 24 hours the EOAs in DAO list will vote for the proposal (approve or reject, or do nothing), the owner can't do setting function during the "lock" time period. If 2 of 3 approvals are set, the owner can call setting functions (setOpSigner or setTreasury), but it must be done in 24 hours, after that time a new proposal is required.
important information for DAO & Contract
You can get some information (view functions) of SWEET through the following link: https://views.candydao.io/candy/