A wallet, an identity, a role grant, a claim, an audit row, and a delegated action all resolve to one participant record.
A participant is the platform's one record of a compliance subject. Every role grant, claim, audit row and delegated action resolves to it, so one subject's history stays together across sessions and wallets.
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. An account-based participant signs in one of three ways: a single external key, a single-signer smart account or a weighted multisig.
Assuming a participant, called Working as in the Console, never edits the record or grants a role. It picks which subject a check evaluates and which wallet executes the request, so that wallet's roles decide what the request can do.
One subject, one record
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 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 record. Every kind of subject, human, organisational or account-shaped, uses the same record type, so other parts of the platform never ask what kind of subject they are looking at before they look it up.
A participant is not the login user. The user is how a person signs in. The participant is the subject records point at, and one user can hold several. Participant kinds are not limited to person and organisation either: a claim issuer, an asset and a platform add-on are participants in the same sense a person is, though no one assumes them as a context.
At review time, a reporting obligation, an Audit Trail row and a Role Grant trace to the same participant, so an institution answers who this is once and reuses the answer everywhere. A role grant resolves through the wallet that holds it, a claim through the identity it sits on, and an audit row through its participant field. The participant record itself never grants a permission.
The platform keeps one participant record, and every other part of the platform reads that record rather than keeping its own copy. Asset Lifecycle is one reader: it runs coupons, freezes and fee collection for identity-verified participants whose ids come from here.
A participant is created once
How the platform creates a participant depends on its kind.
- A person created by an Identity manager. When an identity manager creates a user directly, the platform creates the login, the person participant, a managed wallet and an on-chain identity in one request.
- A person who arrives through the Investor portal. The portal's “Wallet setup” wizard opens when an invited investor signs in with no participant in the organisation, when the participant they act as has no wallet the organisation can act through, or when its wallet setup is unfinished. The wizard first resumes a participant that still waits for its key proof. Otherwise it asks them to pick another participant they own that the organisation can act through, or, when they have none, to create one on a wallet the organisation holds or one they prove they control.
- An organisation. The platform creates the participant when it creates and finalises the organisation's system during bootstrap.
- A single-key account. It comes from a wallet-creation flow and reaches its owner through the wallets that sign for it.
- A weighted multisig. It comes from finalising a multisig draft, which does not deploy while any invite is still pending.
Onboard an investor follows a person from first sign-in to a verified holder: identity registration, KYC review and the claim a token checks.
Day to day, you step into a participant instead of editing it. The “Working as” submenu of the account menu at the top right shows which participants you may act as and lets you switch between them. The submenu offers only participants your own authority already covers. A request checks the same authority when it names a participant directly, so the submenu is a smaller set than the list of participant kinds. If a selected participant stops being actable, the Console falls back to your own participant. Delegated Authority explains which participants you may enter.
A thin parent, kind-specific children
The participant record stores an id and a kind and holds no kind-specific facts: 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. A new kind therefore gets its own record and never widens the participant record.
A participant is not the same thing as an on-chain identity. A single participant can hold more than one identity contract, one per network, tracked separately from the participant record. On a multi-network deployment, ask for a participant's identity on a named network.
The participant record fixes an id and a kind, and kind-specific facts and on-chain identity binding live off it.
Selecting a participant on a request
A request names the participant it acts as with an X-Participant header, and the platform resolves that header against your own authority. The platform accepts a person participant in two cases. You own it and the active organisation can act through it, or a wallet under your control signs for it, such as a multisig in which that wallet holds a current signer seat. A multisig participant you own is accepted only through such a seat, never on ownership alone. Organisation entry checks that the wallet of your acting participant holds Organisation identity manager or Permission manager in the organisation's system on the request's network. Every other kind of participant is refused. Without the header, the platform uses your stored Working as choice, and otherwise your own participant. When the stored choice is no longer reachable, a read falls back to your own participant and the response marks the stored one as dropped, while a write is refused with DALP-0524.
A write that names a participant you cannot use is refused with DALP-0524, the same error for every reason. A read that names one runs as your default participant instead, and the response records that the named participant was dropped. A read is forbidden only when that default is refused too. A caller who could tell a wrong kind, a participant that is not theirs and a participant that does not exist apart could enumerate participants by probing the header.
Resolving a participant picks the subject and the wallet that executes. It never changes what that wallet may do on the network, which stays a separate check against the wallet's own Role Grants. Acting as an organisation therefore runs your request with the roles the organisation's wallet holds.
A participant outlives its account and its kind never changes
A participant cannot change kind or be deleted once created, so create one only for a subject you intend to keep on record.
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 platform offers no route that detaches an organisation participant from its organisation, and the organisation cannot be removed while that link stands. An organisation participant is permanent from the moment its system is bootstrapped.
Removing a person's login does not remove the participant behind it. The platform blocks the removal outright while any of four conditions holds:
- The person is the only owner of an organisation.
- Any participant they hold or act as still has an on-chain identity, on any network.
- A wallet of any of those participants still holds a token balance.
- The person approves transactions for a wallet as its named checker.
Each block names its own reason. Give the organisation another owner, move the tokens out and replace the person as checker, then remove the account. An account whose participant has an on-chain identity cannot be removed. Ban it instead: banning stops sign-in and keeps the record.
When the removal goes through, the account, its sign-in methods, its sessions and the person record that tied the participant to the login go. The participant record stays, and so do the KYC records, the participant names and the audit entries tied to it. Authorship on a registration the person requested also survives, with the requester cleared rather than the record deleted. Check your retention and erasure policy before you rely on that.
What the participant record does not guarantee
The off-chain audit trail records two subjects for a request. The actor field names the signed-in user. The participant field names the participant the request resolved to act as, so a request sent while acting as another participant records that participant. A request that resolved no participant leaves the field empty, so read the actor field as well before you attribute a write. A delegated action also executes from the assumed participant's wallet on chain, so the chain records the same principal independently.
The Working as submenu is not the catalogue of participant kinds. Reading it as that list understates the record's reach, which matters when you reconcile a compliance subject that never appears in it.
Frequently asked questions
Is a participant the same as the user who logs in?
No. A person participant links to one login user, and a user can hold more than one person participant. The participant is the compliance-facing record that a role grant, a claim and an audit row point at. The login user is how you sign in. An organisation participant has no login user, since nobody logs in as an organisation directly.
Can one participant hold more than one wallet?
Yes. A participant's wallets, key accounts and smart accounts alike, are resolved separately from the participant record, which is why the record stores no wallet data. A person can pair a key account with a smart account, or add several smart accounts over time, without changing the participant record. A request still names one wallet to act through, so holding more than one only means choosing which.
Can more than one person act as the same participant at the same time?
Yes. Each request names its participant in its own X-Participant header, so authorised users can make concurrent requests for the same organisation or account, and each request still passes its own access and operation checks. Acting as a multisig never lowers its threshold: every operation it starts still waits for its signers' weight, and the Working as submenu leaves it out.