WASM Upload Whitelist – Adding addresses for operational flexibility
Description
The proposal expands the current whitelist of addresses allowed to upload CosmWasm byte‑code to the Axone mainnet. It adds three individual addresses that can submit new Wasm contracts via axoned tx wasm store.
axone1w9lfv8y7tl3596a8jjxg0rmcdjj98yy50uateh
axone1ewx6pp5la84t4vrgz5fce7fz0r9pd353c4kf99
axone1z3u0h7836app9jdcj5el7ntj0lfuwkrge9vwru
These accounts are only granted upload rights. They cannot instantiate contracts, access the treasury, or perform any other privileged actions.
Goal
Provide developers with day‑to‑day flexibility while preserving overall network security by keeping upload permissions separate from instantiation and treasury controls.
Context and motivation
In the coming weeks, several Axone‑specific smart contracts will be deployed to enable resource description,
zone creation, and zone management. In addition, the core team intends to deploy the DAO DAO smart contracts, which consist of a suite of interdependent contracts that provide more flexible and granular DAO governance within the Axone ecosystem.
Currently, only a 2/3 multisignature account can submit new Wasm contracts. Requiring a multisig for each upload would slow down iteration, increase operational overhead, and hinder rapid responses to bugs or upgrades.
Risks
We identified three risks related to this change:
-
Misuse of upload privilege
-
Key compromise
-
Governance concentration
Risk Assessment Matrix
| Risk | Overall Rating | Likelihood | Impact | Rationale |
|---|---|---|---|---|
| Misuse of upload privilege | Medium | Possible - Developers regularly use the upload function so that mistakes can happen. | Moderate - A bad upload won’t execute until it is instantiated, but it creates extra review work and could delay upgrades. | The probability is non‑trivial, but the impact is limited because execution still requires a separate instantiation step. |
| Key compromise | High | Unlikely - Only a few keys are exposed, and best‑practice key management is expected. | Major - An attacker could flood the chain with unwanted code, increasing audit load and potentially introducing attack vectors. | Even though the chance is low, the potential damage to the network’s reputation and operational workload is significant. |
| Governance concentration | Low | Possible - The whitelist will be small, but any addition changes the decision‑making balance. | Minor - The whitelist does not grant treasury or instantiation rights, so the core governance power remains largely unchanged | The effect on overall governance power is limited; the risk is mostly about perception rather than concrete loss of control. |
Conclusion on Risks
Overall, the additional upload permissions introduce only modest incremental risk compared to the existing 2/3 multisig setup.The most serious concern, a potential key compromise, is mitigated by limiting the whitelist to just three well‑managed addresses, enforcing strict key‑handling procedures, and continuously monitoring upload activity.Because uploading code does not confer execution or treasury rights, any inadvertently uploaded contract still requires a separate, governed instantiation step before it can affect the network.
Consequently, the likelihood and impact of each identified risk remain low to medium, and the benefits of faster development cycles and smoother DAODAO deployments outweigh these manageable exposures. With proper operational safeguards in place, the proposed changes are considered an acceptable and prudent evolution of the Axone governance model.
Governance Voting Options
Below are the voting choices for this proposal and what each option means:
-
Vote YES – You support adding the specified addresses to the WASM upload whitelist.
-
Vote NO – You oppose adding the addresses to the WASM upload whitelist.
-
Vote NO WITH VETO – This indicates that you consider the proposal irrelevant to Axone, harmful to minority interests, or in violation of (or encouraging violation of) Axone’s code of conduct. If “No with Veto” votes exceed one‑third of the total votes, the proposal is rejected and all deposited funds are burned.
-
Vote ABSTAIN – You participate in reaching quorum but choose not to take a position for or against the proposal.