I would like to propose some of the following suggestions to Centrifuge to kickstart governance on Altair. A lot of these considerations were lessions learned in launching Polkadot and Kusama governance (a process that a lot of parachains are now starting to emulate). Since Centrifuge still holds the Sudo key, these are things that can be more easily set up now and can avoid some trouble in the future.
Appoint a Centrifuge Registrar
The coming Runtime Upgrade enables call filters for the following pallets:
- Democracy
- Council
- Elections
- Treasury
- Identity
- Proxy
- Utility
The addition of the Identity pallet will be great for various things of interacting on-chain, but if Altair launches like the Centrifuge Mainnet has (which still doesn’t have a registrar), identities cannot inherently be trusted. As soon as the runtime upgrade hits, anyone can reserve an identity. I can reserve the name lucasvo or cassidy the second the runtime upgrade hits and start to run for council with that. Once someone reserves an identity another person cannot reserve the same one. Call filters for the identity pallet should have probably been enabled prior to this (on Polkadot they were enabled much before council filters were). I would imagine verifications might be manual at first, but Centrifuge can deploy an automated verification service similar to what the Web 3 Foundation operates.
I would encourage anyone voting to back any council members to not vote for people unless they have a verified identity. The role of a registrar is to ensure that an identity and it’s fields (email, twitter, etc) actually belong to the person submitting a request for judgement. This can be done through cryptographic challenges sent to those accounts, whereby the person setting an identity them signs and submits those challenges with their account private key. Registrars can also issue a “bad judgement” to those who try and fake their identity (ie set lucasvo as their identity when that’s actually not who they are).
Eventually the treasury should be used to fund community centric registrar services.
AIR Injections
Key management and account management (especially prior to transfers being enabled) is extremely tough. I helped set up all of this for Polkadot prior to transfers being enabled and it would have been extremely painful had The Web 3 Foundation not done “DOT injections”, which basically were requests for small amount of DOT done as transfers using the Sudo account. There were hundreds of manually approved requests for DOT in order to properly set up validator stash/controllers (for the numerous independant validators in the network), council members accounts, custodians, exchanges, identities, etc.
Centrifuge should open up a form for the community to receive some AIR as a Sudo transfer on a scrutenized case by case basis.
There are numerous considerations for why this applies to this next particular runtime upgrade, in particular council elections.
Council members should ideally have:
- An on-chain identity (which costs at least 100 air as a deposit, potentially more with more fields or using a subidentity)
- A verification on the identity
- Enough free balance for numerous governance related transactions.
The last point in particular is extremely important, as you don’t want to have the case where people cannot spend AIR on transactions if their accounts are not properly set up. Given the various locks currently in place (team / employee vesting, crowdloan vesting, deposits for identity, council bond, etc), not every council member or candidate may have enough free AIR to adaquetly serve the network. Proposing runtime upgrades and various other proposals can require a good chunk of deposit as well, as some things scale with the size of runtime upgrade wasm being proposed for example. If there needs to be an emergency runtime upgrade proposed and a handful of council members don’t have a proper amount of AIR to vote and complete transactions, it can be disasterious.
Additionally, given that AIR holders mostly have AIR from things like Crowdloans, employee allocations, or otherwise, without transfers enabled this is a current dox vector for people’s accounts. Not everyone wants their council address and account to be known with their main bags. Currently most AIR addresses will dox a user’s Kusama holdings as well.
It also can be useful to set up multisigs, proxy accounts, and more kinds of layered accounts, as this is good practice for custody. Injecting AIR to people like council candidates can help them set up proper op sec and custody. Once someone’s account is elected into the council, it becomes very hard to change this. You don’t want to be in the case where you need to continually sign transactions with vesting funds,w here your council address needs to become a hot wallet (not entirely by choice).
This will become important as well when community collators are needed.
(Also the Sudo account kAKUdMBcjaYuTFSYdgqnkw5f1T9AjGqAFg4ct15g4VD76mqq1 still needs funds itself for transactions before the next runtime upgrade 
)
Block Explorer Integration
Not having a block explorer will make it extremely hard to diagnose things if any runtime upgrade goes wrong for example. Even for trying to assess things like voting for council members, trying to do due dilligence by looking at varous on chain activities is very hard unless you can query indexed state. Ideally in the future contineud support for block explorer integrations should be funded by the treasury.
Solidifed Community Process for Runtime Upgrades
A community oriented process for making and proposing runtime upgrades should be solidified and made more transparent. The currently process for making releases and runtimes is fairly opaque - it’s not very clear what is in a new runtime and what changes it contains. A thorough list of changes per release should be made clear, and for each runtime upgrade proposed it should independantly verified by the community via something like srtool.
The process that Polkadot and Kusama goes through is something that should be emulated. Ie a new client release is made. Then after a bit a runtime upgrade is proposed (usually for Polkadot all critical changes in the runtime upgrade are audited by an independant auditing firm before the runtime upgrade is proposed). The runtime upgrade is usually independantly verified to ensure that what’s being proposed and uploaded to the chain matches with what the release contains (via things like srtool). The council then will usually vote on it, and then there is a period of time that community also votes on it. The community should be well informed about releases and have sufficient knowledge to vote on them.
Schedules for when runtime upgrades happen and are scheduled to enact are usually fairly well coordinated, as runtime upgrades can break things like UIs, wallets, or ledger support. Coordination with exchanges, node operators, custodians, and sdk/api providers are often made in advance. There are also multiple communication channels where these things are made (including announcements made on the chain itself via remarks).
I would love to see some of these things fleshed out more, as this will help ensure a smooth continued launch.
