# Account 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](https://github.com/chelofinance/nomos_V2/blob/e3b2fc385091fef7c70d30105349fb55c901f46c/contracts/factory/src/msg.rs#L106), it s defined like below:

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

And on the membership contract, it uses [c4::Member](https://github.com/chelofinance/nomos_V2/blob/e3b2fc385091fef7c70d30105349fb55c901f46c/contracts/membership/src/msg.rs#L10). 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)](https://docs.rs/cw-utils/latest/cw_utils/enum.Duration.html)

```
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.

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/voting-duration.png" alt=""><figcaption><p>Voting duration option in days</p></figcaption></figure>

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)](https://docs.rs/cw3/latest/cw3/enum.Vote.html))

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

The meaning of the [Vote ](https://github.com/chelofinance/nomos_V2/blob/e3b2fc385091fef7c70d30105349fb55c901f46c/contracts/vote/src/msg.rs#L40)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:

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/voting-choices.png" alt=""><figcaption><p>Vot choices</p></figcaption></figure>

### 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

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/absolute_count.png" alt=""><figcaption></figcaption></figure>

2. 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.

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/absolute_percentage.png" alt=""><figcaption></figcaption></figure>

3. 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).

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/threshold_quorum.png" alt=""><figcaption></figcaption></figure>

## **ADVANCED SETTINGS**

### Proposal deposit

Our factory can accept proposal deposit as parameter. On vote contract, the InstantiateMsg accepts [proposal\_deposit](https://github.com/chelofinance/nomos_V2/blob/e3b2fc385091fef7c70d30105349fb55c901f46c/contracts/vote/src/msg.rs#L20) :

It utilizes standard [UncheckedDepositInfo in cw3 - Rust (docs.rs)](https://docs.rs/cw3/latest/cw3/struct.UncheckedDepositInfo.html)

```rust
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.

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/require_proposal_deposit.png" alt=""><figcaption></figcaption></figure>

### Allow Revoting

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

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/allow_revoting.png" alt=""><figcaption></figcaption></figure>

### 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.

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/automatic_execution.png" alt=""><figcaption></figcaption></figure>

### 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:

* [What is a digital signature](https://www.geeksforgeeks.org/what-is-digital-signature/)
* [Meta transactions](https://www.alchemy.com/overviews/meta-transactions)

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.

<figure><img src="https://github.com/chelofinance/documentation/blob/main/v2/.gitbook/assets/signed-offchain-voting-diagram.png" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://nomos-docs.gitbook.io/nomos-1/v2/contracts/multisig-settings.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.