Having now written a few smart contracts (rainbow tokens, token master list) I have been trying to settle on a model for ownership and management. I am sure that other more experienced programmers here have worked through similar questions and I propose that it is worth codifying a recommended practice.
Considerations on my mind:
In most cases a "God" level of control over contract code should be retained (rather than burning the contract keys) in accordance with
the governance principle that all protocols are subject to change by a suitable voting process, and
the benefits of having a "rapid reaction" capacity in case of unanticipated contract behavior
"God" control is implemented as the constitutional guardians (c.g.) multisig
During active development, the c.g. may create a subsidiary permission allowing code updates and assign it to developers. When code is considered stable, the permission is revoked and only the c.g. can act. Possible implementations:
direct assignment of developer individual accounts to the code update permission (probably as multisig)
maintain a dedicated dev.seeds account (or perhaps a similar account per-project), authorized to execute code updates, with individual developers authorized to act for this account.
Contracts which have parameters needing routine updating, or table updates that need authorization, should have a separate account (not the developers or c.g.) designated as "manager". The manager account is set during a one-time init action after the contract code is loaded. (For example, the tmastr.seeds account is managed by tokmgr.seeds.)
It should be possible to link the management account authorization to the holder(s) of a DAO-issued badge
It should be possible to link the management account authorization to a DAO proposal (e.g. the proposal includes a clause to "execute transaction XYZ as contract manager M" and if the proposal is adopted the transaction is automatically executed).
I believe this is comparable in intent to the governance-controlled parameters in some of the SEEDS contracts.
Having now written a few smart contracts (rainbow tokens, token master list) I have been trying to settle on a model for ownership and management. I am sure that other more experienced programmers here have worked through similar questions and I propose that it is worth codifying a recommended practice.
Considerations on my mind:
dev.seedsaccount (or perhaps a similar account per-project), authorized to execute code updates, with individual developers authorized to act for this account.initaction after the contract code is loaded. (For example, thetmastr.seedsaccount is managed bytokmgr.seeds.)