Authority Tokens provide a means to defer effect validation from a common script like the governor or proposal validators to a specialized effect script. This has the limitation that GATs are limited in the scope of their authority: a single transaction. This document describes a method for using authority tokens in order to allow effects to run over multiple transactions.

This could be beneficial for use cases involving large amounts of UTXOs, such as for example the Safety Pool implementation, or for example allowing “upgrading” of stakes altogether.

This method doesn’t use any functionality from V2 plutus and instead uses the witnessing pattern. It does however require modification to scripts that previously used the check for GAT burns.

Reusable Authority Tokens (RATs)

The idea is simple: we simply have a second layer of authority tokens that can only get minted on GAT burn. We require them to never leave the script they are put into originally, by encoding it in their token name, similar to GATs. Additionally, the script must be implemented with extra care in order to scope their use: it could for instance have a particular time frame when they can be used or it could keep track of a maximum number of uses.

Now, scripts that want to enable this functionality to be also deferred to, need to check for both GAT burns and RAT burns. This is as simple as a GAT check, but instead of burn, we simply check for spend.

Generalizing GATs and authority scripts: A new way to check for authority.

The solution to the optimization problem is relatively simple: we always defer to an “authority script”. The authority script itself will then determine whether or not the GAT needs to be spent. This means that from the perspective of the script that is deferring validation we reduce the code a lot! This solution, using authority scripts can actually be used in single use GATs as well. When it comes to single use GATs, the authority script can just itself check for GAT burn. So, we create a more flexible approach that supports all types of temporary authorities we need:

Goal	Solution
Single use authority token	Check for burn of a GAT in the authority script
Multiple (counted) uses of the authority token	Check for spend changing a counter datum in decreasing fashion. Burn on no uses left
Time-locked authority token	Check for time range.

Proposals and the authority check

In order for the proposal to encode what sort of authority is the right one to be used in the effect, we must carefully encode that in the effects field.

type Effects =
  AssocMap
    -- Effect validator hash
    ValidatorHash
    -- We add a ScriptHash that encodes the authority script.
    (DatumHash, ScriptHash)

Now, on finishing the proposal, the proposal validator can check that this is correctly transferred over to the UTXO wherein the RAT lives. The actual checking for spend is out of scope for a proposal, as the effect execution happens in a separate transaction.

Effect receivers and actually performing the authority check

When a script needs to check that DAO-approved authority is present, it now needs to perform a slightly different check. Instead of simply checking for authority token burning, it must instead check for the authority script’s execution. This shouldn’t leave much larger of a script-size footprint than the burn check does, though the actual authority script may have a larger impact overall transaction cost, depending on its complexity.

Diagram illustrating the workflow of a simple one-shot GAT spend.

A mechanism for using “reference scripts” as a non-contentious deferred check.

<aside> 🚧 This entire section has not been tested on-chain or worked out in more detail. The approach shown here may not work.

</aside>