Delegated Authority
Delegated 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.
Entry is one decision. What the operator may do inside is a second decision, against the party's own roles.
A party is an organisation or an account other than the operator's own. Entering its context and acting inside it are separate decisions, and the first grants no role.
A delegated operation is never anonymous. The platform trail names the operator; the ledger names the party's account as sender.
Organization entry uses existing on-chain role grants. Account entry uses an explicit grant to the user.
One person, many entities
Delegated Authority lets one named person operate for more than one legal entity without any of them sharing a login. An operations lead who administers three issuing entities works under their own account throughout, and every instruction they send for an entity stays attached to their name.
The usual alternative is a shared service account per entity, and it destroys attribution. An auditor asking who moved a position gets an account name rather than a person, and one leaver means rotating a credential the whole desk knew. A regulator reviewing that same movement needs a named individual on the platform side, not a desk-wide login, and the platform's on-chain writes still have to settle from the entity's own account rather than the operator's.
Stepping into an entity's context changes what an operator can see and which account their instructions come from. It changes nothing about what that entity may do. The platform denies an instruction the entity's own roles forbid, whether or not an operator stands in its context. That boundary lets an institution widen who may operate an entity without reopening what the entity may do.
Widening entry is not free, though. The organisation identity-manager role, the role that lets an operator in, also lets them add or remove keys on the organisation's own on-chain identity and issue claims from it. Granting it hands over real authority over the organisation's identity, not just a door into its context. The organisation's administrator role opens the same door and adds broader operational authority besides. Grant the identity-manager role when the operator's job is entity administration and organisation-identity changes from them are acceptable; reserve the administrator role for operators who need that broader scope too.
Nothing extra needs maintaining. Entitlement comes from grants that already exist, chiefly an administrator or organisation identity-manager role the entity has already granted to the operator in its own registry on the ledger. Revoke that role and the ability to act for the entity goes with it, leaving no delegation list behind to fall out of step.
One control marks, enters, and leaves a context
Delegated Authority appears in the Console as Acting as. The identity control in the header shows both names at once, your own and the party you are operating, and it turns amber while you work in another party's context. Nothing else marks the state, so that control travels with you on every screen.
The Acting as guide walks the control end to end: opening it, reading a row's kind and role, choosing a party, and returning to yourself.
A party you cannot operate right now still appears, disabled, with the reason on its row: no smart wallet, no EOA wallet, or no registered identity on the ledger network you have selected. Creating a party provisions its wallet and deploys its on-chain identity together, so a row stalled partway through that setup shows one of these missing, not a fault in the switcher. Finishing that setup, or waiting for it to finish, is the fix; switching to a different party is not. Learning the reason before you commit costs less than discovering it part-way through a workflow.
Switching clears work the browser was holding, including a pending deployment and an unfinished instrument draft, so switch before you start rather than during. The network you selected survives.
Switching never unblocks an operation. When the platform declines one, changing context will not change the answer: look to the party's own role, or, for a multi-signature account, to its signer set and its threshold.
Two decisions, two accounts
Delegated Authority is two separate decisions on one request. The first asks whether this operator may work inside this party's context. The second asks whether the account that executes holds the role the operation requires. The platform keeps them apart deliberately, so widening the first never widens the second.
The first decision reads authority that already exists rather than a delegation table. For an organisation, the operator's own account must hold that organisation's own identity-manager role or its administrator role, the grant scoped to that one organisation's identity. This is not the platform's separate identity-manager role, which manages the shared identity registry. The platform reads the organisation-scoped role from the organisation's own registry on the ledger, the same place its other role grants live, and it reads it on the ledger network the request names. Entitlement is therefore per network, worked through below for the same organisation on two networks:
Network A
The organisation runs a registry here, and the operator's account holds an entitling role in it. Entry into the organisation's context is allowed on this network.
Network B
The same organisation, a different network. Either it runs no registry here, or the operator holds no role in the one it runs. Entry is blocked on this network, and the role held on network A means nothing here.
An organisation that runs no registry on the selected network cannot be entered at all, on that network, whatever roles it has granted elsewhere.
A party that is an account rather than an organisation works differently. The platform holds one grant naming one user, and that grant alone lets them use the account's key. Removing it removes the entitlement. The platform rejects every other kind of party.
The second decision belongs to the account that executes. The platform resolves the party's own account and sends the instruction from it, so the role checks that decide the operation run against that account on the ledger. The operator's own credential still unlocks the submission. Before the instruction queues, the platform asks the operator for the second factor enrolled on their own account, a code or a personal identification number, and checks it against their enrollment rather than the party's.
Refusals are uniform. A context the operator may not enter, a party inside an organisation they do not belong to, and a party that does not exist all return the same response.
The context lives on one request header
Delegated Authority reaches the Platform API as one request header. Send the party's participant identifier in X-Participant and the request runs in that party's context. Omitting the header uses the session's current participant. Send an explicit participant identifier when a request must use a specific authorized context. Concurrent requests can name different participants.
An explicit header selects the participant for one request. Requests can run concurrently for different authorized participants. Without the header, the session participant applies.
Build the switcher from the assumable participants endpoint rather than from your own model of who may act for whom. The API explorer documents its request and response shape under the v2Participants tag. That endpoint returns exactly the set the entry check would allow on the selected network, and its identifier for each party is the value to send in the header. Each entry also lists the party's kind, the qualifying role for an organisation, and an availability flag whose reason tells you why the caller cannot use that party yet.
Handle the response carefully. Every refusal returns the same DALP-0524 error, whether the party is one the caller may not enter or one that does not exist. That is deliberate: the response must not disclose which participants exist in this tenant or any other. It is therefore not evidence about existence, and retrying it changes nothing. Re-read the assumable list instead: revoking a role on the ledger drops a party from that list with no other signal.
The check runs before the platform queues any ledger operation, so a denied context leaves no partial submission to reconcile. A request that passes the check can still fail later, when the party's own roles are checked against its account on the ledger. The fix there is a role grant on the party's own account, not the operator's, since the operator already cleared the entry check.
Attribution needs both records
A delegated operation leaves two records, and attribution needs both. The platform's own trail names the person who acted, the role they held at that moment, the route they called and how it ended. The ledger names the party's account as the sender of the transaction. Neither record answers who did what for whom on its own. That completeness holds for delegated operations. Authentication uses a separate mechanism, audit hooks that fail open, an exception the Audit TrailAn audit trail lets you show a regulator or an auditor who did what, under which role, without relying on the requester's own account of the request.Read the concept, the append-only log of platform activity, describes.
Entitlement is itself evidence. For an organisation, the operator's own role in that organisation's registry is the record of who could work for it. That role sits with the organisation's other grants and follows the same grant and revocation path. Answering who could act for an entity last quarter therefore means reading role history, not a delegation log.
Delegation stops at decisions that must name one individual. A support session is a session a platform administrator opens as a named user, rather than the user signing in themselves, and the platform records which administrator opened it. Inside one, the administrator can do what that user can do, with one class of exception carved out along three lines. A support session may not stand in as the second signature on a two-person sign-off, because then both signatures trace to one person. It may not turn on a published attestation the institution cannot later withdraw. And it may not record a compliance rule that admits any contract. That decision needs a written rationale from anyone who makes it, and the platform denies a support session even when the rationale is there, because the record has to name the person who decided. Each denial names that reason rather than a generic permission error.
Frequently asked questions
Can I keep a different party's context open in a second browser tab?
No. The Console stores the active context once for the whole browser session, so every tab shares one context, and a switch in one tab reaches the others on their next navigation. Work that must run in two contexts at the same time belongs on the Platform API, where each request names its own context in its X-Participant header and two concurrent calls can differ.
Can I enter a multi-signature account's context?
No. The entry check admits an organisation through a role in its registry and an account party through a grant naming you, and it rejects every other kind of party, a multi-signature account among them. You operate a multisig through its signers, each acting as themselves, and an operation it blocks points to its signer set and its threshold rather than to anyone's context.
Does acting for a party give me more permission than I have as myself?
The effective permissions can differ because the instruction executes from the party's account. Your entitlement permits you to enter that context; the party's roles authorize the operation. Entry grants no additional role to the party.
What happens if my entitling role is revoked while I am working in a context?
Your next request in that context is denied. The entry check runs on every request rather than once when you switch, so the entitlement dies with the role as soon as the platform reads the revocation from the ledger. The Console does not eject you; you see it the next time you act. The assumable list itself is cached in the browser for a few minutes, so it can keep showing the party briefly after the role is gone; the next request is the boundary that actually holds.
Does switching context let me approve my own work?
No. A two-person sign-off compares the people behind the two signatures, not the contexts they worked in, so a maker who re-enters as another party is still the same person, and the second signature does not count.
Can an integration using an API key act for a party?
Yes. Delegated Authority reads the session's user and participant identity, and an API-key session has both the same way a signed-in session does. A request authenticated with a key can therefore send X-Participant and run in a party's context, provided the key's underlying user holds the entitling role. The key decides who is calling; the context decides whose books the call works in.
Role Grant
A role grant turns an institution's segregation-of-duties policy into a check the ledger itself runs before every privileged call.
Smart Wallet
A Smart Wallet lets a tenant require several signers to agree before an instruction moves assets, with the rule enforced on chain, not by one private key.