Proposals in a governance system are necessarily going to perform some actions or alter some parameters (otherwise, what's the point?). Due to script size limitations on Cardano, it is difficult to encapsulate all of a proposal's effects alongside other necessary information, such as vote counts. Rather than be constrained by such limitations, Agora decouples proposals from their effects.
Effects will exist as their own scripts on the blockchain and proposals will simply include a list of an effect's hashes. This way, users are still able to identify the changes a given proposal would make to the system and thereby assess the proposal's desirability.
A proposal's effects will be initiated by the community, whom we assume will have sufficient incentive to pay the required transaction fee. However, if these effects are independent scripts, sitting there waiting to be initiated, how can we trust community members to only activate the effects of passed proposals?
We don't. Effects will be unable to alter the system without burning Authority Tokens. These are bestowed upon an effect, via the Governor, if their associated proposal has been passed by the community.
All 'governable' components of a system must be able to interface with effects and allow them to make necessary changes, so long as they are in possession of a GAT.
In order for effects to be identifiable through some off-chain metadata and verification of source code, it helps for effects to be reusable, their varied functionality being dependent on their datum. This allows for effects to be given names, be audited, and to be tracked. The datums are more easily inspected because of human-readable representations of their underlying encoding in CBOR (See plutus_data in alonzo.cddl)
The range of powers an effect may have is at the discretion of the protocol maker. For usability purposes, Agora might offer a buffet approach as an option for proposals and effects.
In this model, a proposal is defined by the combination of effect templates, in much the same way a diner's meal at a buffet is defined by which dishes they choose.
Conceiving of proposals this way makes them only marginally less powerful, as users will be able to combine effects in such a way as to render the desired effect. It does however prevent a user wishing to issue a proposal from having to construct their effects from whole cloth.
Whilst Agora may offer this functionality, there is nothing stopping DAO members from writing their own effect code.
An anticipated problem with this model is the danger of 'partial execution'. The model relies on the assumption that desired effects will be processed by community members, as they are seen as desirable. There could however be an issue, if users deem some effects as more desirable than others. If the effects of a proposal are not executed in their entirety, this may lead to unanticipated and undesirable outcomes.
This should not be a major limitation in the system, as community members should recognise the necessity to implement the proposal in its entirety. However, one might consider incentivising effect execution to prevent such an occurrence.
The primary safety consideration for handling GATs with proposal effects should be that the GAT doesn’t leave the effect script unlawfully. The effect should check that whenever it is spent (“run”) the GAT’s auth script must be run, and it must be the specific auth script that the effect script was written with in mind.
Furthermore, an effect could require that no funds are sent to the effect within the spend transaction. This prevents issues with residue datums leaking into future uses of the same script (reuse of scripts is a requirement for correct tagging, implementation safety, etc).