Strategies are the contracts that determine action state.
In this section we will take a look at the different parameters and ways we can configure strategies and use them in various ways.
There are two categories of strategies provided by Llama,
absolute. First we will look at the parameters that they have in common, then look at some of their differences.
Strategies are composed of entirely view functions (besides the initialize function which acts as the constructor).
To view the state of an action, strategies should never be queried directly since the state returned by the strategy functions in isolation can be out of date.
getActionState method on
LlamaCore is the only method that should be used for this purpose.
The approval period is the length of time that policyholders can approve an action.
At action creation time, this number is added to the current
block.timestamp to get the last timestamp that a policyholder can approve at.
Setting the approval period to 0 in tandem with the
minApprovalPct parameters (in absolute and relative strategies respectively) can be used to enable "Optimistic" strategies that are automatically approved.
The queuing period is the inverse of the approval period and can also be thought of as the disapproval period. It defines the amount of time that policyholders have to disapprove an action. The queuing period can be disabled if set to 0, which would mean actions cannot be disapproved after they pass the approval period. Setting the queuing period to 0 enables immediate execution after the approval period.
The expiration period is the length of time an action has to be executed before it expires. It can be adjusted to suit the nature of the action and how time sensitive it is. Some actions must be executed immediately, while others might not have strict timing requirements. Setting this value too low can make for a more difficult UX, and setting the value too high means stale actions that have been forgotten about may be suddenly executed.
A boolean value that determines if an action can be queued as soon as the action reaches the approval threshold, or if it users must wait the duration of the approval period before queuing the action.
Setting this to false is useful for scenarios where it's ok to queue an action as soon as the approval quorum is met.
Each strategy has a single approval and disapproval role that enables policyholders with these roles to cast approvals and/or disapprovals. The supplies or quantities of these roles are used to calculate quorums for certain strategies.
Each strategy can optionally have one or more "force roles", which can cast an approval or disapproval that instantly approves or disapproves the action, regardless of quorum. An example use case for force roles is a grants committee that leverages an optimistic strategy to allow anyone to propose small transfers of value without an approval period, which gets queued for the grants committee to veto. In this scenario each policyholder with the grants committee role can instantly disapprove an action using their force role; this allows for much faster and iterative approach to governance.
Relative and absolute strategies differ in the way they determine if an action has been approved or disapproved.
Relative strategies use
minDisapprovalPct to define the quantity needed as percentage, while absolute strategies use
minDisapprovals to define the quantity needed as a concrete value.
To learn more about the differences between strategies and how they calculate the thresholds, see the strategy comparison table below.
Llama instances can create new types of strategies by authorizing additional strategy logic contracts. Below is a table comparing the key features of the recommended strategy logic contracts.
Relativeif the (dis)approval threshold is a relative percentage of the supply and
Absoluteif it's an absolute value.
- Supply: This only matters for relative strategies. It is the number that the minimum percentage is multiplied by to arrive at the threshold. This can be the total quantity of the (dis)approval role at action creation or the total number of role holders at action creation.
- Policyholder weight: The weight of an eligible policyholder's cast. This is either hardcoded to 1 or the policyholder's role quantity.
|Action creator can cast?
|Total role quantity
|Total role holders
|Total role holders