If fund seizure and permissions for the funds in question are available as actions off-chain, too much power is vested in subjective individual authority and away from mediated consensus. While in general we prefer to abstain from engaging politically as a DAO, any text-only proposal will receive a principled ‘No’ vote simply because on its face, it is a security risk, as well as an opening for deviation from community consensus to creep in ∨ a single point of failure for threat actors seeking to corrupt.
While Proposal 18 as written is NGMI, it is entirely possible following the execution of Proposal 17 to have the desired outcomes be represented as code and put forth for community consideration. Indeed, in the same manner as cw-unity-prop helps to very precisely clarify and implement the intent of Prop 16, a smart contract implementing the CCN proposal could be put forth, at which point our role would be to ensure that the contract does what it claims and while voting to ‘Abstain’, let community decide on its fairness.
While individually our DAOists have their own viewpoints on issues set forth, everything in our DAO — from soft consensus to the validator token being beholden to a multisig — is designed so as to ensure that as a group, we are set up to fulfill our mission — to secure the integrity of consensus, whatever it may be, and preserve the value locked in Junø and ultimately Interchain as a whole.
We (secdao) will vote no on every non-smart contract proposal going forward…
There is no rational explanation to continue to allow or vote for text proposals when community developers are willing to formalize proposals as smart contracts.
The process we would outline would be that the community formalize expectations that a commonwealth text proposal author partner with Juno developers and 3rd party auditors like secdao for all proposals going forward prior to submission as on chain governance proposal. This code shall be uploaded to mintscan and verified before use.
If a proposal can be done in a smart contract it should be done in a smart contract.
- Text proposals without code often lack the specificity of a smart contract or don’t think about crucial features that the developer needs to write a smart contract. The process of writing the code will likely change something in the smart contract code and then the community who voted for the text proposal feels upset that the code doesn’t do their interpretation of the text proposal
- Public disputes involving off chain actions will inherently draw attention to bad actors who will target those involved in off-chain custody of funds
- Voting twice on effectively the same thing draws out the governance process excessively
- The community has developers and auditors who are willing to work with community members to transform commonwealth text proposals to smart contracts
- Given the use of pseudonyms in the community and lack of legal organizations, there is no secure path to doing off-chain actions ; code is the only law that can be relied upon to settle disputes within the Juno community
If you appreciate this sentiment, please delegate to our validator at ping.pub or Keplr. We’d also like to hear your thoughts in our chat space on element.
Standby,
secdao
