SubDAO Proposal Models

Proposal Models

A Model serves as a template for creating a Proposal. When a Proposal is created, it takes the parameters from a model, defined when the subDAO was initialized.

A SubDAO can have multiple Models and so multiple Proposals regarding different things with different rules.

A Proposal model, no matter which type, is represented by a SubDAOProposalModel struct, composed as follows: 

struct SubDAOProposalModel {
    address source;
    string uri;
    bytes[] presetValues;
    bytes32[] presetsProposals;
    address creationRules;
    address proposalTriggeringRules;
    uint256 votingRulesIndex;
    address[][] canTerminateAddresses;
    address[][] validatorsAddresses;
}

  • address source -> this is the address of the smart contract that contains the Proposal code that will be executed if the Proposal passes.

  • string uri -> this can contain metadata for the Proposal being created.

  • bytes[] presetValues -> this is the list of values of a governable parameter, e.g. the rates of inflation (3%, 8%, 10% etc.) for the Organization governance token, the source the code to execute to enact a successfully voted for value change.

  • bytes32[] presetsProposals -> this parameter is automatically populated by the contract, pertaining in particular to Proposals with a presetValue; they become Surveyless Proposals.

  • address creationRules -> this is the contract that defines the rules for who can propose Proposals via the subDAO. When someone attempts to propose one, the contract performs a check of the creationRules contract.

  • address proposalTriggeringRules -> this is the contract that defines the rules for who can finalize a Proposal, and thus give them permission to execute its Proposal code if the Proposal passes. When someone tries to terminate a Proposal, this contract performs a check of the proposalTriggeringRules contract.

  • uint256 votingRulesIndex -> this defines which canTerminateAddresses and which validatorsAddresses should be selected as governance rules when creating Proposals of this model. The canTerminateAddresses and validatorsAddresses are in fact arrays of arrays; the votingRulesIndex selects which specific array to use within the model.

  • address [][] canTerminateAddresses -> these are one or more contracts that define the rules for whether a Proposal can still be voted on, and therefore if the Proposal can end; e.g., the rule can be that a Proposal can only be voted on for a specified number of blocks.

  • address [][] validatorsAddresses -> these are one or more contracts that define the rules for whether a Proposal is passed or not, i.e in accordance with the parameters they establish; e.g., whether it passes via majority rule, or a customized quorum etc. canTerminateAddresses and validatorsAddresses must be of the same length.

To create a Surveyless Proposal, a model must have:

  • presetValues -> populated with the value choices.

  • canTerminateAddress -> not populated.

All other parameters are populated normally.

To create an Survey Proposal, a model must have:

  • presetValues -> bytes(0), as a Survey Proposal doesn't have preset defined options.

All other parameters are populated normally.

Surveyless Proposals are Perpetual

Surveyless, or presetProposals, are Proposals created with a presetValue. They are perpetual; they will remain active for the subDAO's entire life, and can be triggered at any moment, and executed if a sufficient number of votes are cast as per the governance rules defined by validatorsAddresses.

Why Perpetual?

So that they don't have to be redeployed every time they are required.

Recall the example of the subDAO that defines the annual inflation % rate of the governance token. As clones of a presetValues model, the Proposals for changing the rate will be already deployed and ready to go at any time.

For example, there will be:

  • Proposal 1: 2% inflation

  • Proposal 2: 6% inflation

  • Proposal 3: 8% inflation

  • etc.

If one Proposal is voted in, the inflation rate will update to reflect it, but the others will remain active, so that if and when, for example, the 8% choice acquires enough votes, the inflation rate will be updated once more.

Survey Proposal (non-preset), on the other hand, are typically only executed, after they pass, when the terminate function is called; after this, they can never again be voted through; they are not perpetual.

Vertical Permission Layer

As previously stated, the Vertical Permission Layer is defined by combining the four contracts that define the governance rules:

  • creationRules

  • triggeringRules

  • canTerminate

  • validators

At the Governance Layer, it is possible to define a Vertical Permission Layer for each Proposal Model of each subDAO.

Take as reference this page for more information and practical examples of Vertical Permission Layer.

Change Proposals settings

As previously stated, a sub-DAO differs from a Root in that at the sub-DAO level, Proposals can be created and voted for pre-fixed established things and according to a model with predefined rules without being able to propose new code.

Models, containing also the governance rules, can be defined when the subDAO is initialized or later.

Then they can be modified by the Root ( by Proposal) or by a subDAO Proposal if there is a subDAO model that allows to change the rules of the subDAO itself.

Look at the Methods page to learn more.

One or Multiple subDAOs ?

As said before, each subDAO can have multiple Proposal models. In this way, each Proposal model could be used to manage a specific thing. For example, a Proposal model could be used to manage Inflation rate another one to manage a specific fee, and so on. Each Proposal model can have its specific governance rules.

For this reason, you can choose to have a single SubDAO with multiple Proposal models or multiple SubDAO with a single Proposal Model.

Last updated