Requests and approvals
How to find, approve, reject, and track Requests on Ledger Enterprise, and how to chase one that is not progressing.
Role: Operators and Administrators.
Requests lists every Request in the Workspace that you have visibility on, at any status. That includes the ones waiting on you, and the ones you initiated yourself.
For the underlying model, read How governance works.
Finding what needs you
The list shows every Request you have visibility on. Under Type, each row shows the Request type and the object it acts on, such as the Account. The row also shows the creation date, the approval progress with the time to expiry, the On-chain status of a transaction, and the actions. The row does not show the amount. Open the Request to see it. A Request that you can approve now has a Review button in its row.
The search box finds a Request by its ID. The filters are Date range, Request type, Request status and Operation status. The Whitelist filter appears when the Request type filter holds only Whitelist Requests. The Portfolios filter appears when Portfolios are enabled for the Workspace. There is no Account filter. You can sort the list by Created or by Approvals. Filters are held in the page address, so a filtered view can be shared or kept for audit.
The count on Requests
A red number on Requests in the navigation counts the Requests that wait for your approval now. Each of them is pending, its current step includes you, and you have not approved it yet. When no Request waits for you, no number shows. The tooltip on Requests shows the same count, for example "Requests (3)".
Requests in progress on list pages
The Accounts, Groups, Whitelists, Policies and Users pages show a section above the list when Requests that change that list are not complete. The section title gives the count, for example "2 requests in progress".
Accounts
Create or edit an Account
Groups
Create, edit or revoke a group
Whitelists
Create or edit a Whitelist
Policies
Create or edit a Policy
Users
Create or revoke a user
The section holds Requests that are not complete: Initiating... (INITIAL), pending (PENDING_APPROVAL) and Processing... (EXECUTING). A Stuck (STUCK) Request does not appear there. Find it in Requests.
The section has the columns Type, Created and Approvals. It shows the 5 newest Requests first. Load more shows 5 more. The filters of the page do not apply to the section. Select a row to open the Request. Select the section title to collapse or expand the section.
The section shows only the Requests that you can see in Requests.
Approving
An approval is a signature made with your own key. The platform cannot produce one for you.
In the interface, open the Request and read it. Then select Review. Your Ledger device displays the operation, and you confirm it on the device. The device reads the operation from the secure hardware, not from the browser. If you decline on the device, the Request is not rejected. See Declining on the Ledger device.
Over the API, an API user signs the same approval challenge with its own key. Which path applies to you depends on your user type. A Personal Security Device (PSD) user approves in the interface. An API user approves over the API.
Approval is possible only while the Request is pending (PENDING_APPROVAL), and only at a step you belong to. If you belong to a later step, you cannot act until the earlier steps complete. An Operator in a later step does not see the Request at all until then. Administrators see every Request.
The Request's History records each approval under Approved by.
Transaction Check results
Transaction Check screens EVM transactions for risk, except contract deployments. The Request details of a checked transaction show a Transaction checks section, with the latest result level in brackets. The section has one row for the check At creation. It has a second row for the Pre-signature re-check after that check runs. The title reads Transaction checks: escalated when the second result is worse than the first.
The levels are No issue, Risk, Threat and Unverified. Unverified means that the check could not complete.
In the interface, each Approver acknowledges a flagged result before the device step. If the result at creation is not No issue, Review opens a dialog first. The dialog reads Risk detected, Threat detected or Transaction Check unavailable.
To continue to your Ledger device, select Proceed.
To stop without approving, select Cancel.
To open the screening report, select Full report. The link shows only when a report exists.
Your approval does not run a new check. The platform checks the transaction again before signature. If that result is worse than the level that the Creator accepted, the transaction stops. The Operation then fails with the reason "The transaction was stopped by a security check." See When an Operation fails.
Rejecting
One rejection ends the Request. It cannot be revived, and the operation has to be created again.
There is no state between approve and reject. A Request cannot be returned to its Creator for changes.
A PSD user
Reject, then a confirmation in the interface. No Ledger device confirmation
An API user
On most Request types, the platform does not check a signature
To reject a Request in the interface:
Open the Request.
Select Reject.
In the Reject this request? dialog, select Reject.
The dialog shows Rejecting the request..., then Request rejected.
If a rejection does not complete
Could not reject request
The platform did not accept the rejection. The Request is not rejected
Select Retry to send the rejection again
Could not confirm rejection
The platform accepted the rejection, but the Request does not show Rejected yet
Select Check again to read the status again. Check again does not send a second rejection
Declining on the Ledger device
Declining on the Ledger device and rejecting a Request are different actions. Only Reject in the interface rejects a pending Request. The result of a decline depends on your role in the Request.
As an Approver
When you select Review, your Ledger device displays the Request. If you decline it on the device, the approval stops. The interface shows Request approval interrupted.
No rejection is sent. The Request stays pending, and other Approvers can still approve it.
To review the Request again, select Retry.
To stop the Request, close the dialog. Then select Reject, as described in Rejecting.
Important: If the details on your Ledger device do not match the Request, decline on the device. Then select Reject in the interface. A decline alone leaves the Request open to other Approvers.
As the Creator
When you create a Request in the interface, the platform creates the Request first. Then it asks for your approval on the Ledger device.
If you decline on the device at this point, the platform rejects the new Request. The interface shows Canceling approval, then Approval canceled. The Request shows Rejected in Requests.
To create the operation again, select Create request again. The interface creates a new Request with the details you entered. Then it asks for your device approval.
If the interface shows Could not cancel request, the first Request can still be pending. Select Cancel and create again. The interface cancels the first Request, then creates a new one.
The interface does not create a second Request while the first one can still be approved.
If the device step fails for another reason, such as a lost connection, the new Request stays pending with no approvals. Select Retry to continue with the same Request. Retry does not create a new Request. If you close the dialog, the Request stays pending until it expires or somebody rejects it.
Tracking a Request
A Request shows its approvals granted against those required, and its full History. Anyone involved can copy a link to it.
The Request details show the status as a label. In the list, the Approvals column shows the approval count and the time to expiry while the Request waits for approvals. For every other status, it shows the label.
Awaiting approval, no approvals
Waiting for the Creator's own approval. That approval completes the first step
Awaiting approval, part approved
A step is still short of its quorum
To review
Waiting for approvals, and you can approve or reject it now
Processing...
Fully approved, being carried out
Completed
Complete. For a transaction, the On-chain status shows its progress on the network
Rejected, Blocked, Expired, Failed, Stuck
The Request status filter uses other labels for some of these statuses. Statuses and errors gives both sets of labels and the API state.
Expiry
A Request expires 7 days after it is created. The Request shows the time remaining.
During Workspace maintenance, the platform does not expire Requests. See Requests during maintenance.
An expired Request does nothing. The operation has to be created again.
If a Request is not moving
Check which step is current, and how many approvals it still needs.
Check the note. It is the only context an Approver has on the Request.
Share the Request link with the Approvers of the current step. An Operator in a later step cannot open the Request before that step starts.
Each step needs its own Approvers. A multi-step Request takes as long as its slowest step.
Note: Approver names are not visible to everybody. An Administrator sees every name. An Operator sees their own name, and Anonymized in place of the others.
What a pending Request locks
A Request locks the object that it changes, from its creation until it ends. While the lock holds, the platform refuses a Request that would change the same object. This applies in the interface and over the API.
An Account edit
The Account
A transfer, a staking operation, a contract operation or a message signature on the Account. Another edit of the Account
A transfer, a staking operation, a contract operation or a message signature
The Account, against edits only
An edit of the Account. Other operations on the Account stay possible
A Speed-up or a Cancel of a transaction
The transaction that it replaces
A second Speed-up or Cancel of that transaction
A group edit
The group
Another edit of the group
A Whitelist edit
The Whitelist
Another edit of the Whitelist
A Policy edit
The Policy
Another edit of the Policy
A Master Administrator quorum change, an edit of the API admin rules, or the revocation of a Master Administrator
The Workspace governance
Another of these changes. The creation of an Administrator
The creation of an Administrator
The Workspace governance, against changes only
A Master Administrator quorum change. Other Administrator creations stay possible
A user revocation
The user
A second revocation of the user
A Request does not lock the objects that it only uses. For example, a pending group edit does not block a transfer from an Account whose Rules use that group.
In the interface, the edit actions and Send are unavailable while a lock holds. The tooltip names the reason, for example "A request is already pending".
Related
Last updated