Acting as
Use Acting as to select the participant whose data and authority the Console uses for your next operation.
A participantA participant lets every role grant, claim, audit row, and delegated action point at one stable subject, so a person's history never splits.Read the concept, here, means the person, organisation, or wallet whose books you are looking at: your own account, or one you have been entitled to work for. That entitlement is delegated authorityDelegated Authority lets a signed-in operator work inside another party's account. One check decides who may enter; the party's own roles decide the rest.Read the concept, and Acting as is the control that exercises it: the same signed-in account can administer more than one organisation, or operate more than one wallet, without switching logins between them.
Reach for Acting as whenever the screen you need shows a different participant's data than the one currently active. This happens most often when you administer several organisations or hold several wallets and need to see one specific participant's portfolio, pending work, or management area. The platform checks whether you may act for the selected participant and whether that participant has the role required for each operation. Switching changes the participant and scope; it does not add roles to that participant.
Finish work in progress before switching. It clears in-progress browser state: a pending organisation deployment, an unfinished instrument draft, and any in-progress onboarding are all discarded, so finish or abandon that work before you switch, not after. If a settlement creation has not saved its secret, switching clears that pending browser value. Record or finish the settlement before switching. Every operation you run afterward also leaves two separate records rather than one you might expect. The platform's own trail names you, the role you held at that moment, and the outcome; the ledger itself names the party's account, not yours, as the transaction's sender. Neither record alone answers who did this for whom; an auditor needs both.
A participant of kind Person carries a real role, Owner, whether that row is you or a person you have been entitled to work for; an organisation row carries Admin or Identity manager depending on your grant there. An EOA wallet or single-sig account row carries no role of this kind at all, so the Console falls back to Admin there, and it reads exactly like a genuine organisation administrator's role. A multisig account never appears in this list at all: you operate one through its own signers, each acting as themselves, not through Acting as.
Open the Acting as control
Select the Acting as control in the Console header. It carries your own name or avatar when you are acting for yourself, and an amber Acting as pill naming the participant when you are not. This control is part of the shared page frame, so it stays reachable on every screen, not only this one.
Acting as keeps the signed-in account visible while it names the participant used for scoped reads and operations.
Expand the participant list
Select Switch, then review each participant's kind and role, and confirm its availability.
Kind renders as one of Person, Organisation, EOA wallet, or Single-sig account; a multisig account is never one of the rows, for the reason above.
Role renders as Owner on every Person row, whether it is yours or one you have been entitled to work for, and as Identity manager or Admin on an organisation row. On an EOA wallet or single-sig row, role also renders as Admin; read the note above before trusting that value there, since it is a fallback label, not a real one.
Your own row is named for you, not for the word You: it shows your participant name if one is set, otherwise the kind label Person.
The list can differ by network: a participant's wallet presence is checked per active chain, so the same participant can be selectable on one network and unavailable on another.
Select the participant
Choose the person or organisation you intend to operate. The Console clears cached client state for whichever of these exist: a pending organisation deployment, an unfinished instrument draft, any in-progress onboarding, and an unrecoverable pending settlement secret. It then returns to the Dashboard and reloads every view under the new context.
Return to yourself
Open the control and select Return to yourself when you no longer intend to operate for another participant. This option only appears while you are acting for someone else, even when your own row is not in the loaded list.
Integrations can select a participant for an individual request. The participants reference documents participant selection and its authorization rules.
Troubleshooting
A participant's role line shows Admin unexpectedly
Signal: an EOA wallet row or a single-sig account row shows Admin in its kind and role line. Cause: this is not a data error to report. A real role exists only for a Person participant, where it is Owner, and for an organisation participant, where it is Admin or Identity manager. No such role exists for an EOA wallet or a single-sig account, so each falls back to Admin and becomes indistinguishable from a real organisation administrator. Fix: do not read Admin as proof of authority on either of those two kinds. Use the participant's name, and confirm what it actually is on the participants screen, where its wallet type and identity are listed directly. A Person row and an organisation row are the two places this label can be trusted.
A participant is unavailable
Signal: the row is present but cannot be selected, with a reason stated beside it. Cause: the participant lacks a wallet its kind requires. Fix: what is missing decides what fixes it, and it differs by kind. A person is actable with either an EOA wallet or a smart wallet, and the smart-wallet path only counts while account abstraction is enabled and ready for the organisation on the active network. An organisation participant needs a smart wallet under that same condition, and needs its own EOA wallet whenever account abstraction is not both enabled and ready. An EOA-wallet participant always needs its own key account; no smart wallet substitutes for it. A single-sig participant always needs its own smart wallet, regardless of whether account abstraction routing is on. Provision the wallet the participant's kind requires on the participants screen, or wait for account abstraction to come ready, rather than assuming any wallet type will do.
The participant list cannot load
Signal: the control reports that the list is unavailable instead of showing rows. Cause: the assumable-participant list needs an active organisation to resolve at all, so this failure is common right after switching organisations or on a session that has not finished loading one. Fix: retry once the Console can read your active organisation. Treat the current list, not a prior session's list, as the authority boundary.
An operation remains blocked after switching
Signal: you switched to the participant you believe should be able to run an operation, and it is still unavailable. Cause: switching only relocates scope; it never grants a role or an approval. The platform still checks the participant's own roles on every operation, independent of the entry check that let you into its context. Fix: confirm the active participant's required role directly, on the screen where that operation lives, rather than assuming the switch itself should have unlocked it.
Frequently asked questions
Can I act as a multisig account?
No. Acting as only ever lists participants you administer directly: yourself, an organisation you hold a role in, an EOA wallet, or a single-sig account you have been granted access to. A multisig account is deliberately excluded because direct acting would bypass its signing threshold: entering its context as one actor would let you do alone what its signer set requires several people to authorise together. An operation a multisig refuses points to its signer set and threshold rather than to anyone's Acting as context.
What happens if my access to the active participant is revoked while I am using it?
The Console does not drop you back to your own context the moment access is revoked. It first has to finish reloading your participant list and confirm the participant is genuinely gone before it collapses the active context back to yourself; until that finishes, it treats the situation as unresolved rather than guessing. Reload the page if you need the corrected state right away instead of waiting for the next background refresh.
Can I act as different participants in two browser tabs at once?
No. The Console stores one active context for the whole browser session, so every tab shares it, and a switch in one tab reaches the others on their next navigation. Work that genuinely needs two contexts at the same time belongs on the Platform API instead, where each request names its own participant directly and two concurrent calls can use two different ones.
Why does an organisation row show Identity manager instead of Admin?
It reflects the specific role grant behind your access to that organisation rather than a fallback. A grant that names the identity-manager role renders as Identity manager; every other organisation grant renders as Admin. Unlike the same Admin text on an EOA wallet or single-sig row, this one is read directly from your actual role on that organisation, not substituted in because no real role exists.