Actions lists the scheduled, pending and completed operations of the active participant, meaning the person or organisation selected in Working as, and runs the one control each row offers. A row does not by itself mean you can act on it: whether the page offers a control depends on the row's type, whether it is still pending, and whether it names a usable target. Once an operation has finished, Activity holds its indexed on-chain record.
A pending row ends in the “Execute” column, and the row's type decides what that column shows. The Pending tab holds two tables while something waits on someone else. “Needs you” lists the rows whose next step is yours, and only it has the “Execute” column. “Waiting on others” lists the rows that wait on other people: it shows who each row waits on and when it is due, and it has no control except “Review” on an “Add-on approval” row. Once the signed weight meets the threshold, the approval returns to “Needs you” and reads “Executing” until it runs. When nothing waits on others, the tab shows one table.
The “Pending” tab of “Actions” lists the pending actions of the active participant, one row for each action.
The tab bar holds “Pending”, “Upcoming” and “Completed”, each with a count badge. Above the table, the toolbar holds the “Search actions” field, filters, export and the column picker. Each row shows the action, its parties, when it is due, and an “Execute” cell with the control for that row. When rows wait on someone else, a “Waiting on others” table follows with its own count, and the first table takes the heading “Needs you” with the count the “Pending” tab shows.
Steps
Confirm Working as
Confirm the participant shown after Working as before you read or act on anything. When the top bar is narrow, the account menu button shows only an avatar, so open the menu to see the participant. In the account menu, “Working as” is a submenu. It shows only when you can work as at least two participants, and the top-bar button then shows your organisation's name over your own. While you work as someone else, the button reads “Working as” followed by that participant's name, takes a violet tint, and a “Working as” bar under the top bar offers “Return to yourself”. To pick another participant, open the account menu, point at “Working as”, and choose a participant, or select “View all participants” there to open My participants. Switching participant changes the whole queue.
Choose the status tab
Open the tab that holds the work you want:
- Pending holds active work.
- Upcoming holds scheduled work that is not active.
- Completed holds history: executed operations and rows that expired before anyone acted on them. An expired row is not retryable from this page. Treat it as closed.
A Cast vote or poll ballot row shows under “Upcoming” before the vote opens and under “Pending” while you can act on it. If you held voting power and did not vote, it ends under “Completed” as expired. If none of your wallets held voting power at a vote's or poll's record date, the row appears on no tab once that date has passed, and the “Pending” count leaves it out. A vote or poll you already voted on stays under “Completed”.
Read what the row offers
Before you look for a control, find the row in “Needs you” or “Waiting on others”, then read its Execute cell against the Execute table. A row in “Waiting on others” has no control, except “Review” on an “Add-on approval” row. A row whose type this Console version does not recognise shows “Execute” greyed out and reading “Unavailable”.
An Add-on approval row tells you that you or a colleague proposed a change to an add-on, such as a custody gateway, and that the change runs only after it has the approvals its rule needs. The row names the change in words, such as “Release a frozen withdrawal”, or “Unrecognized call” when the Console cannot read it, and reads from the wallet that proposed it to the contract it changes. Its status reads “Waiting for your approval”, “Can't be approved here” or “Ready to run” in “Needs you”, and “Waiting for other approvers” in “Waiting on others”, with how many of the required approvals the proposal has.
Review opens the add-on's “Approval request” sheet on this page. This sheet is separate from the “Approval request” row type, which holds an administrative change.
In the sheet an approver selects Approve, a holder of the requester's role selects “Run change” once the approvals are met, and the proposer or an approver selects “Cancel request”. Each asks for your PIN. A call the Console cannot read has no “Approve” button.
You see one row for each proposal. If you proposed the call from one wallet and hold the approver role on another, the row reads “Waiting for other approvers”, because nobody approves their own proposal. See Add-ons and add-on approvals for the whole flow and its errors.
A held price row tells you that a price from a price source moved past its tolerance, or corrects a price already published, and that it waits for a second person. The row's type reads “Review held price”, and its name reads <ISIN> from <source>, or Correction to <ISIN> from <source> when the price corrects one already published. Only a feeds manager or the governor of the token sees it, and never a person who set up the source or requested its delivery. Review held price opens the “Held prices” tab of that source with the price open in a review sheet. You approve or reject it there, with your PIN, and the row leaves “Pending”. See Price sources.
A Checker approval row is a transaction from a wallet that names you as its checker, and it waits for your decision. Its name is the operation, or for a multisig co-signature, Co-, and its “Parties” read from the signing key to the multisig wallet. “Approve” lets the transaction run, and “Reject” fails it. Only the named checker sees the row, and it leaves “Pending” once you decide or the approval window closes. A transaction you started from a wallet you check never reaches you: it fails at once, because another person must start it. If the named checker leaves the organisation, a transaction waiting for them fails and does not run.
A named button on a recognised row usually opens a sheet right here. Besides the link rows in the Execute table, five types leave the page instead:
- A Multisig signer invite row, whose button reads “Accept invite”, normally goes to a dedicated accept screen. It is a different multisig row from a multisig approval: an invitation to join a wallet as a new signer rather than a request to co-sign an existing one.
- Cast vote normally goes to that token's own governance page, and opens a sheet here only when this Console cannot resolve that page for the token involved.
- Activate voting power also normally goes to that token's own governance page, and opens a sheet here only when this Console cannot resolve that page for the token involved.
- Claim parked amount goes to the settlement it belongs to.
- An Approval request for a corporate action goes to that action on its token page.
On a narrow screen the row keeps what tells it apart and folds it under the action's name instead of dropping it:
- On Completed, the “Completed”, “Executed by” and “Outcome” columns fold there.
- On Upcoming, “Opens” folds there.
- On Pending, “Due” folds there.
A button that acts on the row names what it does: “Approve”, “Execute”, “Claim”, “Update”, or a short verb of its own, with the action and its subject as its accessible name.
Act only where a control exists
Follow the control offered by the row:
- For a recognised row that submits in place, select the named button and confirm the sheet.
- For a Multisig signer invite, “Cast vote” or “Activate voting power” row, select the button and follow wherever it opens: the accept screen for a signer invite, where you choose which of your keys signs for the new wallet, or the token's own governance page for a vote.
- For a multisig approval, the row shows the collected weight against the threshold, such as
1 / 2 weight, and the time left before the approval expires. Co-signing a Smart Wallet multisig starts from the row: select “Sign”, check “Counted weight” against the threshold and the “Deadline” in the “Co-sign approval” sheet, select Co-sign, and confirm with your wallet verification. The sheet calls each of your own keys “You”, in “Started by” and in the signer list alike. While you work as the multisig wallet, an approval that waits on your own seat shows here too, and the sheet offers that seat as “You”. Once the signatures reach the threshold, the row stays in “Waiting on others” and says the signature threshold is reached and the platform submits the transaction to the chain next. When your signing wallet pays its own gas and holds none, “Co-sign” stays disabled with the reason “Top up gas to co-sign.” - For a checker approval, select Approve or “Reject” in the row.
- For an Approval request row on a corporate action, the button reads “Review” when you decide it and “Open request” when you proposed it, and it opens that action on its token page, where you approve or reject it.
- An administrative change you may decide has no such button: follow Decide an administrative change. The row stays in Pending until someone decides it, the request expires, or the plan is previewed again.
- For a custody approval, wait for your custody provider to act on it.
Before confirming, check the participant and operation. An active button means the Console can open the operation. The platform still checks permission when you submit it.
Decide an administrative change
An organisation turns on maker-checker approval for administrative changes by protecting the groups of changes it wants held, under Administration in the Approvals section of General. An organisation with no group protected runs these changes directly. The groups are Role management, Compliance configuration, Approval policy, Freezing, Pausing, Forced transfers, Recovery, Token administration, System administration, Custody administration, Venue administration and Platform settings. Once a group is protected, each v2 write in that group waits as a pending approval until a second person decides it. This holds for a write from a session and for a write from an API key. A change to the protection list is held as well. The frozen v1 API cannot hold a request, so it refuses a v1 write in a protected group and names the v2 route that holds it. Platform-wide administrator routes and decisions on other approvals are never held. The bank rail credit, recall, reserve adjustment and cash-out operations sit outside these groups, because each goes through the bank rail's own approval request.
The person who submitted the change, the maker, cannot approve it. Another organisation owner or platform administrator decides it from their own session. When the approval policy names approver roles for administrative changes, only a member who holds one of them approves or rejects, and an owner or platform administrator who holds none of them is refused. A change to the approval policy itself is still decided by an owner or a platform administrator. An impersonated session, in which a platform administrator acts as another user, cannot decide it. Open the row details to read what the change targets and sets, with secret values hidden, and the digest, a fingerprint of the full request. Approve from the details: the approval carries that digest, and the platform refuses it if the held change differs. The row itself offers “Reject”, which needs a reason that stays visible in the row details. Approval runs the stored change once, with the standing the submitter holds at that moment. If the submitter was removed, banned, demoted below the needed role, or lost the API key, the platform refuses the approval with APPROVAL_REFUSED and runs nothing. Expiry closes the request without changing state.
For a pending administrative approval, open the row's details first. They show four things:
- The method and path the maker called, as the Operation.
- The record it targets, as the Target.
- The values it sets, under Changes, with secret values replaced by
[REDACTED]. - The Digest of the full request.
Those secret values are stored encrypted until the approved change runs, so a pending approval never holds a password or credential as plain text. Request headers are never shown. A change to the approval policy reads as one row per family, exception or protection list, from the setting as it stands now to the setting the change asks for, for example Second person required → Not required, Approvals required: 1 → 2 or Freezing → None. The setting before the change is read when you open the page, so a rule another change moved since the request was made shows its current value. The row itself reads “Open the details to review the change before approving.” and offers only Reject, under a text box that reads “Explain why this change should not be applied”. “Reject” works only once the box holds text.
Select Approve in the details only when the current state still supports the original request. The details sheet closes once your decision is recorded.
Select Reject when the change should not proceed. A rejection leaves the underlying asset or organisation unchanged.
When the organisation asks for more than one approval for the change's family, the row shows the progress under the change name, for example 1 of 2, and the detail sheet repeats it under Approvals. The change goes ahead only after that many different owners or platform administrators have approved, and the maker never counts. A platform administrator counts through the platform role on their account, whatever their role in the organisation. Each person approves once. After you approve, the row moves to “Waiting on others” and reads “You approved this. Waiting for other approvers.” in place of “Approve” and “Reject”, and its detail sheet shows the same line. It no longer counts toward “Pending”. A second “Approve” or “Reject” from you, for example from another open tab, is refused and changes nothing. See General.
Review an assistant finding
Assistant finding rows come from a watcher that an organisation owner or a platform administrator switched on in the assistant settings, or from an AI app. A watcher's row shows only while the assistant and that watcher are on. The row names what the watcher found, such as “Payout not funded”, “Filing not submitted”, “Verifications expiring” or “Unmatched bank credit”. Only organisation owners and the members whose system role owns that work see a watcher's finding: asset managers for payouts, auditors for filings, compliance managers and identity managers for verifications, and bank rail managers for credits.
Review opens a sheet with the brief: what the watcher found, each check it ran with its verdict, and the figures behind each check. The watcher builds the brief from DALP data in fixed wording. Below the two act levels, it signs and submits nothing.
What the sheet offers depends on the finding:
- Open draft opens the asset page with the prepared control and its values filled in, such as “Fund schedule” for a bond coupon. You check the values and confirm with your wallet verification, as for any other change.
- Record choice records the option you pick for an unmatched bank credit. It moves no funds. You then do the step in the bank rail. The watcher does not post that credit again until its condition clears.
- Save answer gives the one date the watcher could not read, such as the date the treasury is funded. The date must be after the current date and within 366 days. The watcher holds the finding back until that date.
- Snooze hides the finding for one day, three days or one week.
- Dismiss closes the finding with a reason and an optional note. The watcher does not post the same finding again until its condition clears.
The Payout funding watcher can also run the treasury transfer itself, under the organisation's agent principal: an agent identity of the organisation, whose key the platform holds, acting within a mandate. Only the organisation owner raises a watcher to “Act with veto window” or “Act”, and only while the organisation has an active agent principal and its kill switch is off.
At “Act with veto window”, the sheet of the finding also shows Scheduled transfer. It says when the agent principal runs the transfer, four hours after the finding is posted, and that it does so unless a member vetoes it first. At “Act”, the agent principal runs the transfer within its mandate with no veto window.
Veto transfer stops the transfer, a toast reads “Vetoed. The transfer will not run.” and the watcher does not post the finding again until its condition clears.
Once the agent principal has acted, the same place shows the outcome instead:
- Done by an agent reads “Done by
<agent>” with the transaction, or “Queued” or “On chain” before a hash is known, and says “This transfer cannot be undone.” - Not run gives the reason the transfer did not run, such as “The mandate has expired.” or “The organisation's kill switch is on.”, and says “Nothing was transferred. You can still open the prepared draft.”
Assistant explains the watcher levels.
A finding also closes without you when a later run of its watcher no longer finds the condition, for example once the payout is funded or the filing is submitted.
The “Assistant finding” type also carries two other rows:
- Request from an app is a change that an AI app prepared for you through the hosted MCP server, and only the member whose app prepared it sees it. “Review” opens its sheet, and “Open draft” opens the control with the values filled in. Opening the draft closes the request as accepted, whether or not you then sign. A request from an app shows only while the assistant is on.
- Watcher run failed appears when a watcher run fails, for example because a read did not answer or the organisation has no active system on its default network. It names the failure and says when the watcher runs again, and the next successful run closes it.
Read the columns and tabs
This page organises work into three tabs, each with its own sort order:
- Pending holds active work, soonest first.
- Upcoming holds scheduled work, also soonest first.
- Completed folds in both finished and expired rows, sorted most recent first.
Each tab's label carries a live count next to it, and the page's URL reflects the tab you are on, so a link to a specific tab reopens on that tab directly. The count on “Pending” and the Actions badge in the sidebar include only the rows in “Needs you”, never the rows in “Waiting on others”. While both tables show, each heading carries its own count, so “Needs you” repeats the number on the tab and “Waiting on others” holds the rest. Pointing at the “Pending” count shows what it counts, for example “3 actions waiting for you”, and a screen reader reads the tab the same way.
The list itself updates live as events arrive. If the live connection drops, the page reconnects on its own. If reconnecting fails, the page says “Live updates stopped” above the list and offers Reconnect, which opens the connection again. An expired session asks you to sign in again.
Each tab shows its own columns by default:
- Pending shows “Action”, “Parties”, “Due” and “Execute”.
- Upcoming shows “Action”, “Parties” and “Opens”.
- Completed shows “Action”, “Outcome”, “Decision”, “Decided by”, “Decided at”, “Completed” and “Executed by”.
Decision reads “Approved” or “Rejected” for an approval someone decided, “No second approval (approval off)” for a change that went ahead without a second approval, and a dash otherwise. Every row also has a “View details” menu.
Some columns start hidden, and the column picker shows them:
- Type starts hidden on every tab.
- Status starts hidden on “Pending” and “Upcoming”.
- Waiting since starts hidden on “Pending”.
- Expires starts hidden on “Completed”.
The expiry column always shows on “Pending”, where it is “Due”. On “Upcoming” and “Completed” it reads “Expires” and appears only when a row has an expiry. “Amount” appears only when a row carries an amount. A narrow table also hides its lower-priority columns, and the View button counts them.
A row waiting on a custody approval sits in “Waiting on others”. Its type reads Custody approval, its name is the operation, and its “Waiting on” column names the custody provider with “Signing the transaction with your custody provider” instead of a control. The “Waiting on” column, and the line that says why a row cannot run yet, read in the language you chose for the Console.
Search matches the action's stored name, its type key, such as ClaimYield, or its target address, not the translated labels on screen, and the Type filter counts the rows of each type on the tab. The counts stay the same when you pick a type, so you can see how many rows each other type holds before you switch.
Export downloads the current list through “Export as CSV” or “Export as JSON”.
On “Pending” you can tick several rows and approve or reject them together when every ticked row is a Checker approval. Otherwise the page reads “Only pending checker approvals can be decided together. Deselect the other actions.” Each tab keeps its own saved views, so a view saved on “Completed” does not show on “Pending”. Tables explains selection and saved views. Rows that arrive while you read wait behind a “2 new” pill instead of moving the list.
What each Execute cell does
The “Execute” column of a pending row shows a named button, a decision in the row or no working button, and rows waiting on others have no controls.
What a row's Execute cell shows depends on its type:
The control describes the row. It does not change with your role on the asset, and an active button is not confirmation that you are permitted to run the operation. Authorisation is decided only after you confirm, by the platform and the contract behind the operation. Selecting a button and confirming it submits the operation immediately for a row whose sheet opens here. You cannot undo it from this page. The Submissions tray offers Undo or “Cancel” while that is still possible.
How a row waits on others
A Custody Approval always waits in Waiting on others, because your custody provider, the service that holds your signing keys, signs outside the Console. A multisig approval waits there when you have no signature to give, for example after you signed and other signers still need to sign, or when your co-signature waits for your checker to approve it. An add-on proposal waits there when other approvers must approve it first.
An administrative change you requested does not appear on this page while it waits. Once it is decided, it shows under Completed with its decision. The exception is an approved corporate action that you still have to run: it stays in “Needs you” with an “Open request” button. A Smart Wallet multisig co-signature request that still needs your signature stays in “Needs you”, with a “Sign” button that opens the co-sign sheet on this page.
Relay permit rows
A Relay permit row is a signed permit that waits to be put on the chain. A permit is a message that a token holder signs to let another address, the spender, move up to a set amount of the holder's tokens until a deadline, without the holder sending a transaction. The holder signs it on the Permit tab of the asset's page, and the row then appears for each wallet that has the custodian role on that asset.
The Relay permit button opens a sheet that names the asset, the holder, and the spender. The sheet does not show the amount or the deadline, so check both in the signed permits list on the same Permit tab before you confirm. Confirm with your transaction PIN or transaction code, the second check you set up for actions that sign on your behalf. You set it up under Security. The platform then sets the spender's allowance on the holder's tokens to the amount the holder signed, and it replaces any allowance that the spender already had from that holder. An allowance is the amount a spender may move. Once the relay is confirmed the spender can move up to that amount, and the relay itself moves no tokens. To take an allowance back, the holder signs a permit for 0, and a custodian relays it like any other. The holder sends nothing.
Each permit has a nonce, a counter that the token's permit feature keeps for each holder and raises by one whenever one of that holder's permits is used. A permit works only when its nonce equals the holder's counter, so a holder's permits relay in the order they were signed, and a signed permit becomes a row only after the one before it is used. For example, a holder whose counter reads 3 signs two permits, for 500 and for 200 units. The permit for 500 has nonce 3 and becomes a row at once. The permit for 200 has nonce 4 and becomes a row after a custodian relays the first. The row moves to Completed for every custodian wallet as soon as one custodian relays the permit. Unlike other expired rows, a permit that nobody relays before its deadline disappears from every tab, including “Completed”, and the holder signs a new one.
When no network serves the scope
The page header names the network you picked in the “Network” submenu of the account menu at the top right. When the network scope you picked has no active network, the page shows no tabs or tables. If the organisation has no active network at all, it reads “No network is active”. An organisation owner or platform administrator also reads “Add a network, or retry one that failed to deploy, on Networks in Organisation settings.” with an Open Networks button that opens Networks. Anyone else reads “Ask an organisation owner to add a network.”
If other networks are active, the page reads “No network serves this scope” and “Pick a network under Network in the user menu.” with a Pick network button, which opens the account menu on its “Network” submenu. The account menu shows that submenu only when multi-network support is on and more than one network is active. Without it, ask an organisation owner to add a network for this scope on Networks.
Where else waiting work shows
The Actions entry in the sidebar and the “Submissions” button in the top bar both show the “Pending” count, which counts the rows in “Needs you” and never the rows that wait on others. A screen reader reads the number as, for example, “3 actions waiting for you”. With work waiting, a link above the tabs of the Submissions sheet reads the same and offers “Open actions”, which opens this page on “Pending”. Submissions describes the tray.
An asset's Overview carries a Needs you card with the pending rows for that asset that you can run now, with the same control each row has here. The card shows at most six rows. With more than six, or with rows the card does not list, a link such as “View all 8” opens the asset's own pending queue. Rows that wait on someone else sit under “Waiting on others” on the card, closed until you open it. “Upcoming” and “Completed” links open the same tables this page uses, filtered to the asset, with “Back to Overview”. With nothing waiting on you, no assistant finding and no failed read, the card is not shown.
Read Outcome, Decision and Due
On “Completed”, Outcome is the row's final state. “Completed” means the operation ran. “Expired” means nobody acted before the row ended, and an expired row cannot be run from this page. An approval request that someone rejected reads “Not applied”, because the change it asked for never ran.
Decision answers a different question: how a second person decided an approval. It reads “Approved, confirm next” when the approval is recorded and the operation still has to be run, “Approved”, “Rejected”, “Expired” when nobody decided before the approval lapsed, “Rejected, release custody next”, “Expired, release custody next” or “Cancelled, release custody next”, “Cancelled” when the maker cancelled a corporate action before anyone decided, or “No second approval (approval off)” when the organisation's policy let the change go ahead alone. It stays a dash for rows that needed no approval. “Rejected, release custody next”, “Expired, release custody next” and “Cancelled, release custody next” mark a rejected, lapsed or cancelled corporate action whose custodian contracts still carry its freeze. Its maker and everyone with the token's supply management role see “Release frozen custody” on the row, and nobody else sees it as pending.
On “Pending”, Due shows the time left before the row ends, such as “in 3 hours” or “tomorrow”, and “Overdue” once that time has passed. On “Upcoming” and “Completed”, the same value sits in the “Expires” column. The Console shows the time and does not lock the row: a button stays active after the time passes until the platform records the row as expired and moves it to “Completed”. Run a row before its “Due” time, and treat “Overdue” as a row that may already be closed.
Roles and effects by row type
Each row type is run by the person its own feature names, and the effect on holders is described on that feature's page. This table gives the role and the effect for the types a reader asks about most. Use the linked page for the full rules.
The role column describes who can complete the operation. What each Execute cell does explains when a button is active.
How each kind of action ends
For a direct execution, confirm the row now appears under Completed with its “Completed” and “Executed by” columns filled. That is the only confirmation this page gives, and it can take a moment to move tabs.
For a custody approval, watch the toast instead of this page. While the provider decides, a toast reads Awaiting custody approval, with an “Open actions” button that opens this page, and it stays until no custody approval is pending.
When the provider decides, the toast says how the request ended:
- Custody approval completed on success.
- A named ending when the request ends without a signature, such as Rejected by an approver, “Blocked by an approval policy”, “The approval window closed” or “The gas sponsorship expired”. The toast also says that nothing was sent.
- The custody provider reported an error when it is not known whether the request took effect. Check it in the provider's approval console before you try again.
- Custody approval failed for any other failure.
For a Multisig signer invite, the accept screen itself confirms the outcome: it tells you the join succeeded. The wallet's creator still has to finalise the draft before the wallet is active, so there is nothing further to check on this page for that row. For a multisig approval, the status line above the button and the co-sign sheet show the signed weight against the threshold. The sheet re-reads signed weight each time it opens, so trust it over anything remembered from this page.
For an administrative approval, the row moves to Completed after approval or rejection, with “Decision”, “Decided by” and “Decided at” filled in. An approved change runs through the original operation, and its Audit trail record links the maker, checker and transaction. A rejected or expired request has no on-chain change. An expired request leaves the page without a row. Open a rejected row's details to read the rejection reason.
Troubleshooting
A button is greyed out
Signal: a named button appears greyed out on a row you expected to run. Cause: this page enables the button only under four conditions together: the row's type is recognised, its status is Pending, it names the record it applies to, and, for a dividend, the issuer has funded it. Your role is not one of the conditions, so a greyed-out button never means a missing permission, and an active button can still be refused after you confirm. Fix: read the reason the button gives. “This version cannot run this type of action.” and “Only a pending action can be executed.” have no fix on this page. A row that reads “This action does not name the record it applies to, so it cannot open.” lacks data that this page cannot supply. “Cast vote” needs the governor and the proposal, “Cast poll ballot” needs the poll, “Claim dividend” needs the token, the dividend and the feature it claims from, “Claim yield” needs the token and the feature or schedule it claims from, and “Relay permit” needs the stored permit with its token, owner and spender. “Awaiting funding: the issuer has not funded this dividend yet.” clears once the issuer funds the dividend.
A custody approval has no Approve or Deny button
Signal: a Custody approval row shows no button anywhere, and it sits in “Waiting on others”. Cause: the decision happens in your custody provider's own system, outside the Console, so the row has no control here. Fix: ask an approver to approve or reject the transaction in your custody provider. The row leaves “Waiting on others” once the provider decides. A toast tells you how it ended: “Custody approval completed”, a named ending such as “Rejected by an approver”, or “Custody approval failed”.
A multisig approval has no Sign button
Signal: a multisig approval row shows no Sign button, or a button that reads “View”. Cause: “Sign” shows only in “Needs you”, while you are a signer who has not signed yet and the threshold is not met. After you sign, the row moves to “Waiting on others”, which has no button, while other signers still need to sign. Once the threshold is met, it returns to “Needs you”. In “Needs you”, once the approval is executing, executed, expired, cancelled, or failed, the button reads “View” and opens the same co-sign sheet read-only, with a line above it that gives the state, for example “Executing”, “Executed”, “Expired”, “Cancelled”, or “Failed”. Fix: open “View” to read the signed weight against the threshold. If you already signed, wait for the other signers. If a row reads “Waiting for your checker to approve your co-signature”, your checker has to approve before your signature counts.
Accept invite does nothing, or opens a screen that does not let you join
Signal: selecting Accept invite on a “Multisig signer invite” row either does nothing at all, or opens the accept screen without letting you join. Cause: a silent click means the row's stored invite link no longer matches a shape this Console can open. Nothing on screen reports that failure. Once the accept screen does open, several states can block you there instead. “Your wallet already signs here” means every wallet you can sign with already holds a seat on this multisig or is waiting to join it. “No wallet to sign with” means none of your accounts can sign for this multisig yet. “Address already in use” means one of your keys took a seat on that draft after the page loaded, for example from another tab. “Key already a signer” means the key you picked already signs for the wallet. Any other terminal screen, “Invitation expired”, “Invitation revoked”, “Already accepted”, “Invitation void” or “Invitation not found”, means the invitation can no longer be used. The row leaves “Pending” once the invitation is accepted, revoked or expired, or once the draft is no longer open. Fix: for a silent click, reload the page and select “Accept invite” again. For “No wallet to sign with”, select “Add a wallet”, create your wallet, then open the invitation again. For “Address already in use” or “Key already a signer”, open the invitation again and pick another key, or add a wallet: the seat is still open. For every other terminal state, you cannot retry or accept from either screen. Ask the wallet's creator to send a new invitation if you still need to join.
I already signed, but the operation hasn't executed
Signal: you signed in the co-sign sheet, but the multisig operation has not run. Cause: the threshold is met and the operation awaits execution. The sheet shows only “The threshold is met. This action is awaiting execution.” and not the later execution steps. Fix: do not sign again. The sheet does not let you, and it shows your signature as read-only once recorded. Check this page's Completed tab or Activity for the result, because the sheet does not update to a final state.
An administrative change is waiting for approval
Signal: a role, policy, compliance, freeze, pause, transfer, or recovery change appears as a pending approval and no chain state has changed. Cause: the platform holds the validated request until a different eligible owner or platform administrator decides it. Fix: open the row from your own session as an eligible approver, not an impersonated one. Approve only if the current state still supports the request. Otherwise reject it with a reason. The maker cannot approve their own request, and the request expires without applying the change.
An add-on approval has no Approve button
Signal: Review on an “Add-on approval” row opens the “Approval request” sheet, but the sheet offers no “Approve”. Cause: one of four states. The row reads “Can't be approved here” because the Console cannot read the call, and the sheet shows the raw call data instead. A wallet of yours proposed the change or already approved it, and the sheet reads “You approved this. Waiting for other approvers.” or offers only “Cancel request”. The proposal has its approvals, and the sheet reads “Approved. Someone with the requester's role can now run it.” Or the window ended while the sheet was open, and the sheet reads “Expired”. An expired proposal then leaves this page. Fix: ask another approver, or a holder of the requester's role to select “Run change”. An expired proposal cannot be revived: raise the change again.
Frequently asked questions
Can you run something from the Upcoming tab before it becomes Pending?
No. The Upcoming tab has no “Execute” column. It shows “Action”, “Parties” and “Opens” by default, plus “Expires” when a row has an expiry, and the column picker adds “Type” and “Status”. A control appears once the row's status moves to “Pending”. Check back after the row's scheduled time passes.
What happens when an operation I run from a row fails?
The failure shows in the Submissions tray, which names the next step as “Try again”, “Edit and retry”, “Top up and retry”, “Top up and edit”, “Check status” or “Contact support to resolve.” The row stays under “Pending”, because this page reads the platform's record and a failed write changes none of it. When the tray reads Outcome unknown, do not run it again until the tray confirms what happened. Submissions describes each phase and failure.
Why did a Pending row you were about to act on disappear?
Most often someone else acting for the same participant already executed it, or it expired and folded into “Completed”. The list updates live, so a row can leave “Pending” between your last look and your click. Check Completed: an executed row shows its “Executed by” column, and an expired row sits there too, sorted most recent first. Neither state is retryable from this page.
Can you narrow the queue down to one row type when it gets busy?
Yes. The Type filter on the toolbar lists every row type the Console can show, so “Multisig approval” and “Custody approval” are their own named options alongside every type this page can run. Combine it with the search box, which matches the stored action name, type key or target address, or with the tab you are already on, to cut a long “Pending” list down to the handful of rows you came to work through.