Account Settings

Explanation about Super Accounts configuration and settings

Different Tier of membership

When adding a member to a Super Account, there is a weight parameter that can be used to define different level/tier of member vote weight. Different value of weight of member means different voting power.

From the factory, when creating an account, we pass a cw4::Member, it s defined like below:

pub struct Member {
    pub addr: String,
    pub weight: u64,
}

And on the membership contract, it uses c4::Member. The value of weight will be integer numeric.

Voting duration

We support to have an account with voting duration.

The duration is defined by cw_utils::Duration with struct definition like below:

Duration in cw_utils - Rust (docs.rs)

pub enum Duration {
    Height(u64),
    Time(u64),
}

Duration is a delta of time. You can add it to a BlockInfo or Expiration to move that further in the future. Note that an height-based Duration and a time-based Expiration cannot be combined so user must choose one type of duration.

The real value will be seconds, but to make it easy, UI provide slider range in days .

In the Nomos V2 Demo UI, Voting Duration looks like this.

Note: For now Demo UI only provide option for voting duration in time.

Multiple voting choice

We support multiple voting choices.

On voting the proposal, Vote module contract accepts cw3::Vote (Vote in cw3 - Rust (docs.rs))

pub enum Vote {
    Yes,
    No,
    Abstain,
    Veto,
}

The meaning of the Vote choices:

  • Yes Marks support for the proposal.

  • No Marks opposition to the proposal.

  • Abstain Marks participation but does not count towards the ratio of support / opposed

  • Veto Veto is generally to be treated as a No vote. Some implementations may allow certain voters to be able to Veto, or them to be counted stronger than No in some way.

In the Nomos V2 Demo UI when voting, user can vote like below:

Passing threshold & Quorum

There are 3 kinds of threshold to decide whether proposal status is passed or not.

  1. Absolute Count

Declares that a fixed weight of Yes votes is needed to pass. The value of weight will be numeric/integer

  1. Absolute Percentage

Declares a percentage of the total weight that must cast Yes votes in order for a proposal to pass. The value of percentage will be decimal value like 0.1, 0.3.

  1. Threshold Quorum

There are 2 parameters of this threshold: quorum and threshold

a. Quorum

Declares a quorum of the total votes that must participate in the election in order for the vote to be considered at all

b. Threshold

As additional criteria after pass the quorum, also need to include threshold in calculation to determine whether proposal is passed or not. It will only count “participant” which is only voters who voted yes, no or vote, so abstain is not included (It is not counted).

ADVANCED SETTINGS

Proposal deposit

Our factory can accept proposal deposit as parameter. On vote contract, the InstantiateMsg accepts proposal_deposit :

It utilizes standard UncheckedDepositInfo in cw3 - Rust (docs.rs)

pub struct UncheckedDepositInfo {
    pub amount: Uint128,
    pub denom: UncheckedDenom,
    pub refund_failed_proposals: bool,
}

pub enum UncheckedDenom {
    Native(String),
    Cw20(String),
}

We can configure whether we refund failed proposal or not, but as default the executed proposal will refund the deposit to proposer.

We can support Cw20 token also for denom, but for current Nomos Demo V2 UI we set to use untrn as native denom.

Allow Revoting

Super Accounts support “re-voting” so participant/member can vote again if it is configured to allow revoting.

Automatic Execution

Accounts also support automatic execution of proposal if the proposal status is passed already. When is not set as automatic, participant/member need to execute the Passed proposal manually from the UI.

Open Proposal Submission policy

This determines who is allowed to submit proposals to the Super Account. The values will be used as “open_proposal_submission” parameter on creation, the options are:

  • Only members

  • Anyone

If the setting is false (default) then Only members can submit proposal, if true then anyone can submit proposal.

Signed off-chain voting

To understand how this feature works under the hood, please check the following articles related to digital signatures with public keys:

Currently, this feature might also be called a “Meta transaction”, only for voting. The flow goes like this:

  • The frontend app creates a message that requests the user to vote on a certain proposal.

  • User signs this message using their keplr wallet. A signature from account A can only be performed by the wallet holding the private keys of that account. This means that signatures cannot be impersonated and only members will have valid signatures.

  • This message is stored on a database. Subsequent vote requests signed are also stored on that db.

  • Once the Backend knows that there are enough voting signatures to execute or reject the proposal, it (or anyone) can pick these messages and send them to the contract.

  • The contract then verifies each signature. The verification steps are the following

    • The message sent contains 3 things. The signature (bytes), the message that was signed without modifications (this message is a “SignDoc” object) and the public key of the signer.

    • The contract creates the correct hash of the message, this hash is what was signed by the user. The hash of the message is then verified against the signature using the API for signature verification in cosmwasm.

    • If the signature is correct and was made by the claimed public key, then the verification passes and the vote execution continues. If not the call is reverted.

This is the diagram of a standard meta transaction. In our case the “Relayer/Proxy” and the “Contract A” are the same, the Super Account voting module. The module verifies the signature and executes its content.

PreviousStructureNextFactory

Last updated