How governance works
The Request lifecycle behind every action on Ledger Enterprise: approval steps, quorum, which Rule applies, and what expires.
Read this page once and every guide gets shorter.
What a Request carries
The operation
What it does, with its full details
Approval steps
Ordered stages, each needing a set number of approvals
Quorum
How many approvals a given step requires
A note
Optional free text from whoever created it, visible to Approvers
An expiry
If full approval is not reached in time, the Request lapses and does nothing
Steps are collected in order. Approvers at step two cannot act until step one has met its quorum. Every Request shows how many approvals it has out of how many it needs.
Note: An approval step in a Rule names either one group or a list of Operators, never both and never several groups. When a person approves at one step, their reviews at later steps become obsolete. So each person counts once in the whole Request, and a later step needs Approvers who did not approve at an earlier step.
Creating a Request
In the interface, you fill in a form, then review it on your Ledger device. The device shows the operation's real details, read from the secure hardware rather than from your browser. What you approve is therefore what executes.
An API user creates the same Request over the API, and signs it with its own key.
Your approval as the Creator is the first approval, and it completes step one.
If you decline on the Ledger device at this point, the platform rejects the new Request. See Declining on the Ledger device.
After you approve:
If yours is the only approval needed, you get a confirmation and the operation proceeds.
If others must approve, you see how many approvals remain and can copy a link to the Request to share with them.
Approving and rejecting
Open Requests to see what is waiting on you.
Approving is signed with your own key. In the interface you confirm on your device, the same details the Creator did. An API user signs the approval challenge instead.
Rejecting ends the Request permanently. It cannot be revived, so the operation must be created again. In the interface, rejecting needs no device confirmation. Over the API, most Request types accept a rejection without a signature.
Declining on the Ledger device is not rejecting. An Approver who declines on the device only interrupts their approval. No rejection is sent. The Request stays pending, and other Approvers can still approve it. To stop the Request, select Reject in the interface. See Declining on the Ledger device.
You can only approve at the step you belong to, and only while that step is the current one. See Request statuses for more details.
Which Rule applies
Governance is defined per operation type. The Rule governing a transfer is not the Rule governing a smart contract interaction, and each Account carries its own set.
In the interface, every Account must define who may send. Rules for staking, message signing, contract interaction, contract deployment, and other specific cases are optional. They appear only where the asset supports them.
Canton Accounts also need a receive Rule, because receiving on Canton is an action somebody has to approve. See Canton.
In the interface, an Account can hold up to four Send Rules. They are evaluated in order, and the first Rule that matches applies. This is what makes tiered approval work: modest amounts under a light Rule, large amounts under a heavier one. Every other operation type allows a single Rule in the interface.
The API enforces neither limit. It accepts any number of Rules for an operation type, and an Account without a Send Rule.
When you create a transaction, the form names the matching Rule. That is the Rule your Request falls under. The Account supplies the Rules. The platform takes the first of them, in order, that passes every check:
The operation type is the Rule's operation type.
If the Rule has an amount threshold, the amount is within it.
If the Rule has Whitelists, the recipient is in one of them.
You are in the Rule's first step, labeled Request initiator in the Rule editor. There is no other list of permitted Creators.
The matching Rule states how many approvals this transaction needs.
If no Rule covers what you are attempting, the Request cannot be created. That is a governance outcome rather than a fault. Only a Master Administrator can change the Rule set.
Where Rules live
An Account is governed either by its own Rules, used nowhere else, or by a shared Policy that other Accounts also use. A Policy is a reusable, named Rule set, so editing one changes the governance of every Account that adopted it at once. See Policies and Whitelists.
Related
Last updated