Statuses and errors

Every Request status and Operation status on Ledger Enterprise, the error messages, and Workspace maintenance: what each means, and what to do about it.

Request statuses

A Request has one status at a time. The API returns a state. The interface shows a label, and the label depends on where you look:

• The Requests list and the Request details use one set of labels.

• The Request status filter on the Requests list uses another set. Four of its labels differ from the list and details labels.

Both sets and the API state are given here.

List and details label	Filter label	API state	Meaning	Reached the blockchain?
Initiating...	Initial	INITIAL	Created, and still being prepared for review	No
To review or Awaiting approval	Pending	PENDING_APPROVAL	Collecting approvals. The only status where approve and reject are possible. To review means you can approve it now	No
Processing...	Executing	EXECUTING	Fully approved, and being carried out	In progress
Completed	Executed	EXECUTED	Complete. For a transaction, the operation was broadcast	Broadcast
Rejected	Rejected	ABORTED	An Approver rejected it, or the Creator declined on the Ledger device while creating it	No
Blocked	Blocked	BLOCKED	Another Request canceled it. See Blocked	No
Expired	Expired	EXPIRED	It reached its expiry before full approval	No
Failed	Failed	FAILED	Execution was attempted and did not succeed	No
Stuck	Stuck	STUCK	The platform could not finish the cleanup after a failure, a rejection, an expiry or a block. Contact Support with the Request ID	Unclear

In the list, the Approvals column does not show To review or Awaiting approval. For a pending Request, it shows the approvals granted against those required, and the time to expiry. The Request details show the label, with a count such as "2 of 3 approved".

For the state values in an API response, see the API documentation.

Important: Only Processing... (EXECUTING) and Completed (EXECUTED) mean anything has reached the blockchain. A pending Request has not moved value, however long it has been there.

Completed means broadcast, not confirmed. The network decides when an operation confirms. The On-chain status of the Request shows the Operation status. See Reviewing operation history.

A pending Request past its expiry shows as Expired. Its Review and Reject buttons disappear. The API state changes to EXPIRED up to one hour later.

During Workspace maintenance, the platform does not expire Requests. See Requests during maintenance.

How the status filter works

The Request status filter on the Requests list offers all nine statuses as separate options, with the filter labels above. Select one or more of them. A Request appears when its API state matches one of your selections.

The filter reads the API state. So for up to one hour after its expiry, a Request still matches Pending and not Expired.

Blocked

Only a Request that is not fully approved can be blocked. A Revoke user Request blocks others. As soon as it is created, it blocks every Request that the user being revoked created. It also blocks every pending Request that this user approved at an earlier step.

The blocked Request is canceled and cannot be approved. A Revoke user Request blocks these Requests even if it is later rejected.

Nothing moved. Create the operation again if it is still needed.

Operation statuses

A Request that sends a transaction creates an Operation. The Operation has its own status, which follows the transaction on the network. The interface shows a label, and the API returns a status.

The status badge shows the label in the On-chain status column of the Requests list, and in the Request details. The Operation status filter and the Operation history in the Request details use the same labels, with two differences:

• SUBMITTED reads Confirming on the badge, and Submitted in the filter and the Operation history.

• The filter has no Replaced option. A replaced Operation matches Dropped.

Label	API status	Meaning
Queued	SCHEDULED	Accepted by the broadcast system but not submitted to the network
Confirming on the status badge. Submitted in the filter and the Operation history	SUBMITTED	Submitted to the network, and waiting for chain inclusion
Confirming	ON_CHAIN	Included on-chain and waiting for the required confirmation threshold
Confirmed	CONFIRMED	The required confirmation threshold was reached
Dropped	DROPPED	No longer progressing on-chain
Replaced	DROPPED	Replaced by another transaction, for example after a speed-up or a cancellation
Failed	FAILED	Failed before submission to the network
Failed on-chain	FAILED_ON_CHAIN	Failed after submission to the network
Unknown	UNKNOWN	The status is inconsistent and needs investigation

A replaced Operation and a dropped Operation have the same API status. The interface shows Replaced when a replacement transaction took its place.

When an Operation fails

The Operation history shows one of two reasons:

Reason shown	What happened	What to do
The transaction was stopped by a security check.	Transaction Check stopped the transaction before signature	Review the recipient before you create the transaction again
The transaction failed during processing.	Any other failure	Read the status, then follow the guidance below

The second reason covers every other cause. The interface does not show the network's own error. To get it, send the Request ID to Support.

• Failed: the network did not accept the transaction. Nothing moved. You can create the transaction again. If it fails again, contact Support before a third attempt. On Bitcoin, see If a transaction fails because of unconfirmed incoming transactions.

• Failed on-chain: the network received the transaction and rejected it. The network can charge a fee. Find the transaction hash in a block explorer to see the network's reason.

• Unknown: do not create the transaction again until Support confirms its status. A second transaction can send the funds twice.

Why an action is unavailable

What you see	Reason
A section missing from the navigation	Your role does not give access to it, or it is not enabled for your Workspace
A greyed-out action with the tooltip "You don't have the permission to send". For other operations, the tooltip shows stake, delegate, unstake, undelegate, sign-message, interact-with-contract or deploy-contract in place of send	No Rule on the Account lets you create that operation. A Master Administrator must add you to the first step of a Rule
A greyed-out action with the tooltip "Insufficient balance to Send" (or another operation)	The available balance of the Account is zero. Message signing is not affected
A greyed-out action with the tooltip "You cannot perform transactions while this account has a pending edit request."	A Request to edit the Account is pending. Wait until it is reviewed, rejected or expired
A greyed-out Edit with the tooltip "A request is already pending"	Another edit Request for this Account is pending
A greyed-out Edit with the tooltip "You cannot edit this account while there are pending operations."	Transactions from the Account are not complete yet. Wait for them to finish
A Hedera Account with an Action needed badge in the Accounts list. Its Send is greyed out with the tooltip "You cannot send from an inactive Hedera account". Its Edit is greyed out with the tooltip "An inactive Hedera account cannot be edited"	The Account is not activated. An Administrator activates it from the Account page
No Review on a pending Request	You are not an Approver in the current approval step, or you reviewed already
No Reject on a pending Request	You are not an Approver in the current step or in an earlier step
Rules that cannot be edited on an Account	The Account uses a shared Policy. A Master Administrator can edit the Policy. A Master Administrator can also edit the Account and select Manual to give it its own Rules
In the send form, the banner "No matching rule found for the provided amount & send." and a greyed-out Review with the tooltip "No matching rule found for the given amount and recipient"	No Rule lets you send that amount to that recipient. Check the amount thresholds and the Whitelists of the Rules
Anonymized in place of an Approver's name	Only Administrators see the names of other users. Other users see only their own name
A banner that starts with your Workspace name and "is in read-only maintenance", and every change fails	Ledger has put the Workspace in read-only maintenance. See Workspace maintenance

Messages and error screens

These messages stop a sign-in, a device step or a Request in the interface. The tables give the title of each message.

Sign-in and device messages

A Personal Security Device (PSD) user can get these messages at sign-in, during pairing for single sign-on (SSO), or during registration. Device is locked, No device selected and Update required on your device can also show at any other device step.

Title	Cause	What to do
Stax not recognized	The platform finds no Workspace where this Ledger device belongs to a user	Contact an Administrator of your Workspace
Login interrupted	The sign-in was declined or canceled on the Ledger device	Select Retry, then confirm the sign-in on the device
Device is locked	The Ledger device is locked	Unlock the device, then select Retry
No device selected	The browser prompt that lists devices closed with no device selected	Connect and unlock the device. Select Retry. Then select the device in the browser prompt
Update required on your device	The Ledger Vault app is missing, or its version is not the version that the platform requires	Select Start update. When the update is complete, select Retry. See Your device
PSD does not match your SSO session	During SSO pairing, your identity provider names a different PSD from the one you connected	Contact your IT service
PSD already linked to another user	During SSO pairing, your SSO identity or this PSD user is already paired	Contact your IT service
Device already connected to another partition	During registration, the Ledger device is already set up with a different partition	Disconnect the device in the app settings, as the message says, or contact an Administrator

Request messages

Title	Cause	What to do
Request approval interrupted	You declined the Request on the Ledger device during Review. No rejection is sent, and the Request stays pending	Select Retry to review it again. To stop the Request, select Reject. See Declining on the Ledger device
Approval canceled	You declined on the Ledger device while you created the Request. The platform rejected the new Request	Select Create request again to create a new Request with the same details
Could not cancel request	You declined on the device while you created the Request, and the platform could not confirm that it canceled the Request. The Request can still be pending	Select Cancel and create again. The interface cancels the first Request, then creates a new one
Could not reject request	The platform did not accept your rejection. The Request is not rejected	Select Retry to send the rejection again
Could not confirm rejection	The platform accepted your rejection, but the Request does not show Rejected yet	Select Check again to read the status again. It does not send a second rejection
Request creation failed	The new Request reached a status other than pending before your approval, or it expired before a retried approval	Find the Request in Requests and read its status. Create the operation again if it is still needed
Risk detected, Threat detected or Transaction Check unavailable	Transaction Check flagged an EVM transaction, or the check could not complete	Select Proceed to continue to your Ledger device, or Cancel to stop. See Transaction Check results
Transaction can't be replaced	You selected Speed-up or Cancel transaction, and the transaction ended before its network hash became available	Return to Requests and read the status of the Request
No permission to sign	A dapp asked for a message signature, and no Rule on the Account lets you sign messages	Ask a Master Administrator to add you to the first step of a Rule for message signing
No permission to execute	A dapp asked for a contract interaction, and no Rule on the Account lets you interact with contracts	Ask a Master Administrator to add you to the first step of a Rule for contract interaction

Error reports for Support

Most error screens have a Copy error report button. On some screens, it is an icon with the tooltip Copy error report. It copies a technical report of the error, in JSON format.

When you contact Ledger support about an error, paste this report into your support request. For an error on a Request, also give the Request ID.

The report contains:

• the error and its technical cause;

• the address of the page that showed the error;

• the user agent of your browser;

• your user details;

• the date and time of the report.

These screens have no Copy error report: Device is locked, No device selected, Request approval interrupted, Approval canceled and Transaction can't be replaced.

Workspace maintenance

Ledger can put a Workspace in maintenance. Ledger sets the maintenance mode and ends it. No user of the Workspace can change it. There are two modes.

Full maintenance

The Workspace is closed. Every page of the interface opens the maintenance page instead. Its title is your Workspace name, followed by is under maintenance. Try again reloads the page. The maintenance page stays until maintenance ends.

Over the API, every call fails with HTTP status 503 and the message "Workspace is in maintenance mode. Please try again later."

Read-only maintenance

A banner shows at the top of every page: "Workspace name is in read-only maintenance. You can view Workspace data, but business changes and device-backed operations are temporarily unavailable."

You can read Workspace data, and you can sign out. The platform refuses every change. That includes creating, approving and rejecting Requests. Over the API, a read works, and a change fails with HTTP status 403.

Requests during maintenance

These rules apply in both modes:

• Nobody can approve or reject a Request.

• A fully approved Request does not progress. It continues after maintenance ends.

• The platform does not expire Requests. A Request that reaches its expiry keeps the API state PENDING_APPROVAL. It expires after maintenance ends.

In the interface, a pending Request still shows Expired when it reaches its expiry.

Related

• How governance works

• Requests and approvals

• Reviewing operation history