Vertical Permission Layer

This page describes how the Vertical Permission Layer works and is valid for both the Root Layer and the Governance Layer.

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

  • creationRules

  • triggeringRules

  • canTerminate

  • validators

At the Root Layer, it is possible to define a Vertical Permission Layer valid for all the proposals of the Proposal Manager.

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

The combinations of the four contracts should be consistent with creating an effective Vertical Permission Layer.

The following are some examples; each project can create its ad hoc Vertical Permission Layer.

Example 1

  • Root Layer -> Host + Holders

  • Governance Layer -> Holders only

Root Layer Host + Holders configuration example:

  • creationRules -> BySpecificAddress contract (look here for the code). It allows a specific address, i.e. the host address, to create Proposals. All other addresses cannot create Proposals.

  • triggeringRules -> address(0). In this way, everyone can terminate Proposals.

  • canTerminate -> CanBeTerminatedAfterBlockLength and/or CanBeTerminatedWhenHardCapReached contracts (look here for the code). The first contract defines a Proposal duration; users can vote on Proposals for the duration defined by the contract and the Proposal can only end after reaching the defined duration. The second contract defines a hard cap, i.e. a fixed or percentage (calculated on the token total supply) accept votes amount. If the amount is reached, Proposals can terminate. Remember that canTerminate contracts follow an or logic; if you use multiple contracts if even one contract returns true then the Proposal can end. In this case, the Proposal, if it reaches the hard cap, could end even before the defined duration.

  • validators -> ValidateQuorum contract. It defines a minimum number of votes (accpet + refuse) that the proposal must receive in order to pass and be considered valid or to execute the code.

Using this configuration you have a Root Layer where only the host, and so the core team developing the project, can propose changes (addition/replacement/removal) to the architecture of the Root Layer and what is hosted by the Root Layer but must necessarily also have the consent of the holders.

Governance Layer Holders only Surveyless configuration example:

  • creationRules -> address(0). In this way, everyone can propose Proposals starting from the predefined Proposals of the Proposal models.

  • triggeringRules -> address(0). In this way, everyone can terminate Proposals.

  • canTerminate -> empty. Surveyless Proposals are perpetual.

  • validators -> CanBeTerminatedWhenHardCapReached contract. It defines a hard cap, i.e. a fixed or percentage (calculated on the token total supply) accept votes amount. If the amount is reached, Proposals can be triggered and executed.

As you can see, the CanBeTerminatedWhenHardCapReached contract is used as a validator in this subDAO surveyless Proposal Model while it is used as a canTerminate contract in the Root layer and in the subDAO survey Proposal Model below.

It is in fact possible to use different contracts in different ways as long as it is consistent. In this case, since surveyless cannot have canTerminate contracts, the CanBeTerminatedWhenHardCapReached contract is used as a validator.

Governance Layer Holders only Survey configuration example:

  • creationRules -> address(0). In this way, everyone can propose Proposals starting from the predefined Proposals of the Proposal models.

  • triggeringRules -> address(0). In this way, everyone can terminate Proposals.

  • canTerminate -> CanBeTerminatedAfterBlockLength and/or CanBeTerminatedWhenHardCapReached contracts (look here for the code). The first contract defines a Proposal duration; users can vote on Proposals for the duration defined by the contract and the Proposal can only end after reaching the defined duration. The second contract defines a hard cap, i.e. a fixed or percentage (calculated on the token total supply) accept votes amount. If the amount is reached, Proposals can terminate. Remember that canTerminate contracts follow an or logic; if you use multiple contracts if even one contract returns true then the Proposal can end. In this case, the Proposal, if it reaches the hard cap, could end even before the defined duration.

  • validators -> ValidateQuorum contract. It defines a minimum number of votes (accpet + refuse) that the proposal must receive in order to pass and be considered valid or to execute the code.

In subDAOs, these rules are defined at the individual Proposal Model level. You can decide to use the same rules for all proposal models or have each proposal model have different rules.

Using this configuration you have a Governance Layer where holders can take financial and practical decisions in a totally independent way from the core team and in general from the Root Layer.

Last updated