The Amaru maintainer committee ensures direct administration of its budget, assisted with an on-chain smart contract. Off-chain, the fund management, responsibilities and remuneration of contributors follow PRAGMA's Maintainer Committee Framework. In addition, the smart contract's role is to ensure that the expenditure of funds is done in accordance with the scope defined in this budget and authorized by the relevant scope owners.
We recognize the following capabilities of this contract:
- Standard withdrawal: A scope owner initiates money withdrawal from their treasury, with another scope owner approval.
- Contingency withdrawal: A scope owner asks all other scope owners to withdraw an amount from the contingency funds.
- Scope reconciliation: A scope owner asks other scope owners for a change of ownership (or a reallocation of budget).
- Contingency refund/closing/failsafe: any leftovers from scopes or from the contingency budget can be sent back to the Cardano treasury after an ageed-upon delay.
- Credential rotation: In case of lost credentials or the departure of a scope owner, a mechanism allows the rotation of credentials to a new scope owner upon approval by all (5 out of 5) PRAGMA members.
We keep a journal transactions happening around this treasury setup.
Each Amaru treasury contract comprises of 4 validators, each with specific role. One of them, the scopes, is shared across all treasuries. Others are specific to each scope. We have summarized the setup and flow in a high-level diagram (PDF). We use a few symbols and arrows in the diagram, refer to docs/README.md#legend to understand their meaning.
Each treasury validator (one per scope) re-uses Sundae's treasury management setup and define a single permissions script (detailed below) for all supported operations: sweep, reorganize and disburse. The fund action is disabled and never used. Amaru will use the disburse action to pay vendor with the addition of the off-chain legal framework.
See also docs/treasury.md.
Permissions scripts are executed as withdrawal actions (using the withdraw-zero pattern) for each action of the treasury. They provide additional restrictions on the execution of each action. With the exception of the contingency scope, permissions ensure that the actions sweep anddisburse are authorized by the scope owner and an additional scope owner. The action reorganize can and must only be authorized by the scope owner.
In the case of the contingency budget, sweep and disburse must be authorized by everyone; whereas reorganize can be authorized by any scope owner.
See also docs/permissions.md.
To avoid circular dependencies in validators, we must store references to the treasury contract address at a datum on-chain, identified by a specific NFT. The minting policy and management of that NFT is guarded by the registry validator. Burning is authorized only after the expiration date.
See also docs/traps.md.
To allow dynamically changing the scope owners for each scope (in case of a key loss or actual change of owner), we must store scope owners credential at a datum on-chain, identified by a specific NFT. The minting policy and management of that NFT is guarded by the scopes validator, overseen by PRAGMA. Burning is authorized only after the expiration date.
See also docs/traps.md.
- aiken >= v1.1.17
- cardano-cli >= 10.4.0.0
- jq >= 1.5
- basenc (GNU coreutils) >= 9.1
- (optional) ogmios >= v6.10.0
Note
The scopes (ledger, consensus, mercenaries, marketing, contingency) are pre-defined and not configurable.
| What | Where |
|---|---|
| PRAGMA's admin keys | aiken.toml |
| On-chain scopes asset name | aiken.toml |
| Network | Makefile |
| Seed UTxO for scopes NFT | Makefile |
| Seed UTxO for registry NFT | Makefile |
| Initial scopes owners | Makefile |
Tip
At any time, to get a friendly reminder of the configuration and commands, just run:
make help-
make scopesThis initialize the scope owners (from the Makefile's configuration) and prepare a minting transaction to publish them on-chain.
The transaction must be signed and submitted through your own means.
-
make permissionsBuild each permissions validators, each used to manage a treasury. Once all the permissions scripts have been prepared, the command will offer to build a transaction to register them on-chain as stake credentials.
This is necessary to make them usable in the treasury but, it is NOT necessary in order to setup the treasury so you may ignore this step for now.
-
make treasuryBuild each treasury validators as well as their corresponding registries.
-
make registryPrepare a minting transaction to publish all registries on-chain. Note that the registry and the treasury are bound to each other, and the treasury is parameterized by the permissions. If you change any of those, you must rebuild the entire sequence.
The transaction must be signed and submitted through your own means.