In the spirit of extensibility, a governance system should be able to readily expand the effects proposals can have on their protocol. With smart contracts built on Ethereum this is often done with untyped data and references to specific contract hashes. Compound encodes an array of the contracts' addresses (address[] Proposal.targets) and the data to be passed to them (bytes[] Proposal.calldatas). This approach does not translate to Cardano's EUTXO model, so we require an alternative approach to allow encoding ad-hoc polymorphic effects in proposals. This document outlines the approach Agora takes, its trade offs, and the risks attached.

Agora’s approach relies on two core assumptions:

• We trust the stakeholders to thoroughly assess the effects of a proposal. This ensures that the effects are safe and will work as intended.
• The effects of a proposal may only alter the system after their associated proposal has been passed by the stakeholders.

The first assumption is justified by the fact that any proposal stores the hash of its effects, and these effects are available for any user to inspect. The GT-holders will be able to verify a proposal's purported benefits. Additionally, individual effects may be audited if they involve significant surface area for exploitation.

To ensure the latter assumption holds true, we introduce 'governance authority tokens' (GATs). Any effect that wishes to alter the system will be required to burn a GAT, when it is enacted. These GATs will be issued to a proposal's effects via the governor component, which has the responsibility of ensuring that a proposal passed in a correct and valid manner. Conceptually, the ownership of a GAT by an effect is a way of demonstrating to a component: 'the DAO (decentralised autonomous organisation) has granted me permission to alter your parameters'.

This model naturally requires that any component of the system, desired to be adjustable via governance is aware of the existence and significance of GATs. For example, a Liqwid market may be subject to the effects of a successful proposal to alter its parameters. The following diagram shows how such an update could occur:

https://viewer.diagrams.net/?border=0&tags={}&highlight=0000ff&edit=_blank&layers=1&nav=1&title=Authority tokens %26 GATs&open=Uhttps%3A%2F%2Fraw.githubusercontent.com%2FLiqwid-Labs%2Fdiagrams%2Fmain%2Futxo-diagrams%2FAuthority%2520tokens%2520%2526%2520GATs

<aside> 1️⃣ A proposal is “executed”, minting a GAT and sending it to the effect script. Remarks:

• The governor is involved in order to allow such minting.
• A user wallet provides the ADA in order to create the minimum required ADA in the effect UTXO.
• The datum created at the effect utxo must be the one encoded in the proposal, too.

</aside>

<aside> 2️⃣ The effect script’s UTXO with the GAT is burned as proof to allow changing the market datum. Remarks:

• The GAT policy is called in order to allow burning.
• The MinADA is retrieved to another user wallet.
• The market ST stays within the same script.

</aside>

This approach has a number of benefits but some important details must be kept in mind.

Handling multiple effects in a single proposal

Cardano script sizes are restricted to 16KB and previous proposal/effect models have had difficulties generating scripts which keep under this limit. By decoupling proposals and their effects, a proposal can have a far greater number of effects, as all it contains is a list of hashes for said effects. Effects themselves can make any number of changes to the system, as long as the resulting script is kept to an allowable size.

It is essentially impossible for the system to prevent conflicting effects taking place in short order and harming the system but the likelihood of this occurring is sufficiently reduced by all effects first having been passed by the DAO. There is scope for adding a notion of 'expiration', after which effects will no longer be able to enact their changes.

Writing effect code requires a lot of care

The ability to alter large swathes of the system being conferred by the ownership of a single token poses the risk of (purposeful or inadvertent) harm. There are steps one can take to lessen this risk:

• All validators for an effect transaction are specified in full. In comparison to the normal writing of validators, where one only specifies what they must, one must do all they can to avoid undesired behaviour being permitted by the validator.
• All transactions are only executed by one of a few 'trusted' DAO members. This would necessarily have to be encoded in the effect.

This should be sufficient to prevent loopholes. Delegating authority through validation or spending of tokens is often a necessary risk in blockchain systems and this problem is no more complex than others of its kind.