Participant

A participant lets every role grant, claim, audit row, and delegated action resolve to one stable compliance subject, so a person's history never splits across their sessions, wallets, or organisations.

The subject a participant represents is checked against a closed list at creation, covering people, organisations, and platform-internal subjects such as claim issuers and assets. An unlisted kind is refused. How an account-based participant's own controlling account signs is a separate, three-value axis: a single external key, a single-signer smart account, or a weighted multisig.

A role grant, a claim, an audit row, and a delegated action all carry a participant id. Assuming one, called Acting as in the Console, never edits the record or grants a role. It only picks which subject a check evaluates.

One subject, one recordCopy Anchor Link

A participant answers a simple problem: the same compliance subject shows up in many places. A person logs in through several sessions, holds more than one wallet, and might act for an organisation on some days and for themselves on others. Without one anchor record, the KYC history, the role grants, and the audit trail would each need their own idea of who that subject is, and the three would drift apart. The participant is that anchor. Every kind of subject, human, organisational, or account-shaped, uses the same record type, so downstream systems never have to ask what kind of subject they are looking at before they can look it up.

The payoff shows up at review time. A reporting obligation, an 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 row, and a Role GrantA role grant turns an institution's segregation-of-duties policy into a check the ledger itself runs before every privileged call.Read the concept can all be traced to the same participant id, which is what lets an institution answer who this is once and reuse the answer everywhere. The participant record itself never grants a permission. What it does is give every other record a stable subject to point at, so permission and history stay attributable to one thing instead of scattering across whichever wallet or session happened to be active.

The platform keeps one participant anchor in a single owning domain, and every other domain reads it through a contract rather than repeating the lookup. Asset Lifecycle is one consumer of that anchor: it runs coupons, freezes, and fee collection for identity-verified participants whose ids come from here, not from a per-domain guess.

Creating and stepping into a participantCopy Anchor Link

The platform creates a participant once, and how depends on its kind. For a person, it creates the participant alongside the login user at signup, though a failed signup step can leave a user without one until their next session repairs the link. For an organisation, it creates the participant when it creates and finalizes the organisation's system during bootstrap. Account-shaped participants follow a different path. A single-key participant comes from a wallet-creation flow and reaches its owner's control through a dedicated access list. A weighted multisig participant comes from finalizing a multisig draft, which will not deploy while any invite is still pending.

Day to day, you do not edit a participant. You step into one. The Console calls this Acting as: the identity switcher shows which participant you may act as and lets you change context. Behind it, the platform can only offer a participant your own authority already covers, the same authority a request checks when it names a participant directly. If a selected participant stops being actable, the switcher falls back to your own participant rather than leaving a stale selection in place.

A thin parent, kind-specific childrenCopy Anchor Link

The platform keeps the participant record thin. It holds an id and a kind, and almost nothing else, no organisation reference, no KYC profile reference, no wallet data. Everything specific to a kind lives on a separate record, linked back to the parent so that a person record can never masquerade as an organisation record. This is why the platform can add a new kind, such as a fund or a joint account, without ever widening the participant record itself.

One consequence of keeping the parent thin: a participant is not the same thing as an on-chain identity. A single participant can hold more than one identity contract, one per chain, tracked separately from the participant record. Asking what this participant's identity is, is therefore already the wrong question on a multi-chain deployment. The right question names a chain first.

Selecting a participant on a requestCopy Anchor Link

A request names the participant it wants to act as with an X-Participant header. The platform resolves that header against your own authority for the named kind. For a person, the caller must own the participant and be able to use it in the active organization. Organization entry checks the required organization role. Single-key account entry checks a use-key grant. Multisig contexts are blocked. A kind the resolver does not recognize is denied by default rather than passed through. Single-key participants are the one case with a real access list, since their authority cannot be derived from an existing login link, organisation role, or signer set.

Every denial returns the same generic forbidden response, whatever the underlying reason. A caller who could distinguish wrong kind from not your participant from no such participant could enumerate participants by probing the header. The uniform response closes that path. Resolving a participant decides only which subject a request acts as. It never touches what the executing account is permitted to do on chain, which stays a separate check against that account's own Role GrantA role grant turns an institution's segregation-of-duties policy into a check the ledger itself runs before every privileged call.Read the concepts.

What a participant record survivesCopy Anchor Link

A participant is created casually and turns out to be permanent.

The kind is fixed at creation. Every kind-specific record is bound to a participant of that kind, so a participant cannot be converted from one kind into another. Correcting a wrong kind means creating a new participant, and the history already attached to the old one stays there.

The organisation path is stricter still. Nothing on the platform detaches an organisation participant from its organisation, and the organisation itself cannot be removed while that link stands. An organisation participant is permanent from the moment its system is bootstrapped, with no unwind sequence to work through first.

Removing an account does not remove the participantCopy Anchor Link

A participant outlives the account that created it: removing a person's login does not remove the record behind it. The platform blocks the removal outright while any of three conditions holds.

• the person is the last owner of an organisation.
• any participant they hold still has an on-chain identity bound to it, on any chain.
• any participant they hold still has a wallet registered to it, whatever that wallet's balance.

Each block names its own reason, so the removal is an ordered unwind rather than a single step: hand the organisation to another owner, retire the on-chain identity, remove the wallet, then remove the account.

When the removal does go through, the wallets and the active verification profile go with it. The participant record itself stays, and so does the verification history and the documents attached to it, which are removed only through their own path. Authorship on a registration the person requested also survives, with the requester cleared rather than the record deleted.

You cannot delete your way out of a participant. The record is what a later audit resolves against, and an account is only a way in: the participant is the compliance subject that outlives it.

What the participant record does not yet guaranteeCopy Anchor Link

The off-chain audit trail records a participant id on every row, but that id names the session's own participant, not necessarily the one whose context the actor was acting inside. A delegated action executes from the assumed participant's account on chain, so the chain records the true principal, but the audit row's participant field currently does not confirm that on its own. When establishing attribution, treat the audit trail's participant field as who was logged in, not as proof of who a delegated write was acted for.

A second caution concerns which kinds exist at all. Participant kinds are not limited to person and organisation: a claim issuer, an asset, and a platform add-on are participants in exactly the same sense a person is, though no one assumes them as a context. The identity switcher is not that catalogue. It shows the participants your own authority lets you step into, a smaller set by design. Reading the switcher as the list of participant kinds understates the record's reach, and that matters when you are reconciling a compliance subject that never appears in it.

Neither caution changes what a participant is. Both change what you should verify before relying on a participant record as complete evidence.

Frequently asked questionsCopy Anchor Link