Users
Manage organisation participants with login credentials, wallets, on-chain identities, roles, and invitations, and review a user's holdings and eligibility.
Users lists every organisation participant who has login credentials: a person or a service account that can sign in to the Console. Reach for this page when you need to see who can log in, add a new one, or open a record to check what a specific login controls.
Two neighbouring jobs belong elsewhere. If the counterparty has no login of its own, such as a wallet address you send tokens to, that belongs in Contacts, the address book that never grants access. If the participant is a token, a system identity, or another actor that must hold a regulated asset but never signs in, that belongs in Entities. Users is specifically the login roster; a user's wallet and On-Chain IdentityAn On-Chain Identity lets a subject's verification serve every asset that accepts it, so a screened wallet skips re-onboarding for the next regulated asset.Read the concept are the things that login is allowed to control, and they stay meaningful even if the login itself is later removed.
A login and an identity answer different questions, and the Console treats them as two separate records for a reason. The login controls who can sign in and what they can see and do in the Console, governed by roles such as administrator, trusted issuer, or investor. The identity is a smart-contract record on the chain that regulated tokens actually check before they let a wallet hold or move value. A brand-new user can log in immediately after creation, but its identity is not automatically registered on-chain: a person can exist as a Console user for weeks with no registered identity, unable to hold anything, until someone completes registration. This page shows both halves side by side so you can tell the difference between "cannot log in" and "can log in but cannot yet hold tokens", which have entirely different fixes.
The two tabs on this page, "Users" and "Invitations", split people who already have access from people who are still on the way. A registered user already has a login; an invitation is a promise of one, sent by email or shared as a link, that has not yet been accepted.
Both lists are audit surfaces as much as management ones: every user record traces back to how it was created. An invitation keeps its status, pending, accepted, rejected, or cancelled, until the recipient responds or you cancel it; an expired invitation can still display Pending, but that status does not make an expired link valid. The place to see that trace is the user's own detail page, described below, which keeps an activity log of the on-chain events tied to that wallet; nothing on this list view itself opens that history directly.
Creating, inviting, or removing a user changes login access only, never anything already moving on-chain. Removing a member removes access to the active organisation. The Console also attempts to revoke the account's sessions; removal can still proceed if that revocation fails. The wallet and identity remain. A transfer or settlement already submitted against that wallet still completes or fails on its own terms, exactly as it would have before the removal; the membership change does not delete the account or its access to other organisations. Creating or inviting a user has no effect on anyone else's holdings or in-flight activity either, since nothing about an existing token, holder, or counterparty reads the Users list to decide what it does next.
Steps
Open Users
Open "Organisation participants", then "Users". Select "Users" for registered participants or "Invitations" for pending access.
Screen equivalent: the Users tab lists each registered participant's name, email, wallet, and status when your account can list users. The Invitations tab lists every invitation's email, expiry date, and status (pending, accepted, rejected, or canceled), whatever that status is, when your account can manage invitations; an invitation is addressed by email alone, so the tab has no name column. Neither tab renders when your account holds neither permission; the page shows an access-restricted message instead of an empty table.
Create or invite a user
Select "Create or invite user". With "Send invitation email" on, the default, enter the recipient's email, then choose from "On-chain permissions", protocol-level roles that reach the invitee once they accept and complete onboarding; leave it empty to invite with none at all. Turn the toggle off to create the account directly instead. The dialog then swaps the roles picker for a name field, capped at 255 characters, a limit the form enforces before submission, since you are creating the wallet and identity now rather than sending an invitation for someone else to accept. The email field itself stays on either path: an invitation needs it to send the message, and a direct creation needs it to reach the login you just created. A directly created user starts with no on-chain permissions and gets them later from Admins & roles, not from this user's own detail page.
Submit the request
Select "Send invitation" or "Create user". The Console asks you to enter your PIN code whenever the request writes on-chain: direct creation provisions a managed custody account, so it asks for verification. An invitation asks only when you attached on-chain permissions to it, because granting a protocol-level role is itself an on-chain write; a plain invitation with no permissions needs no PIN. When email is not configured, the Console skips the invitation email and shows a link to copy and share manually instead. Direct creation never sends email in the first place, so this fallback does not apply to it.
The user detail page
Opening a user record shows more than a profile. The header always carries a participant-type badge (Admin, Trusted issuer, or Investor, decided by the roles held). On a ledger with an EVM identity contract, it also carries a registration-status badge (Registered or Pending registration, decided by whether that identity is registered). The tabs sit below the header. At the top of the Overview tab, a details box lists the user's email, account, member-since date, and last login. The account is the wallet address this user signs transactions from. On the same EVM-identity ledgers, the box also holds the identity address, the on-chain identity contract that regulated tokens check. It reads "None" until registration completes. The other tabs do not repeat these details. On a deployment with smart-account wallets enabled, the wallet line becomes two addresses instead of one: a signing address and a separate transaction address. A smart account executes through a distinct on-chain account from the key that authorises it, so the Console shows both addresses, letting you tell an authorisation problem from an execution problem.
The participant-type badge follows a fixed check order, not a snapshot of every role at once.
The first matching role wins: Admin is checked before Trusted issuer, and a user with no special role at all falls through to Investor.
A guidance checklist above the tiles tracks what is still missing for this user to be fully operational. An unregistered identity, a KYC profile not yet started, or a required verification not yet issued each appear as an open step until resolved.
Guidance checklist and tiles
Below the checklist, up to seven tiles gather everything else. Which ones you see depends on your role and this user's state.
| Tile | What it shows | Who sees it |
|---|---|---|
| Basic info | Name, email, account-created date, last login, and a "Remove member" control | Always present; "Remove member" needs an account that can manage security |
| Security | Multi-factor status and active session count | Accounts with the identity-manager role |
| Identity claims | Verification records tied to this identity, linking to Verify a participant | Shown once this user has an identity |
| KYC status | This identity's know-your-customer record, linking to the KYC workflow | Always present |
| Global eligibility | Whether this participant is blocked at the organisation level, regardless of any single token's own rules | Identity managers and trusted issuers |
| Holdings | Current token balances for this user's wallet, linking to a fuller table | Shown once the user has a wallet |
| Activity log | The on-chain event history for that wallet, linking to a fuller table | Shown once the user has a wallet |
The identity control
The identity control sits above the tiles and is visible more broadly than Security. It shows one of two actions, and which one depends on what the Console's identity lookup returned for the wallet. Two things must settle before it shows at all: the network must support an EVM identity contract, and the lookup must have answered. While the lookup is still pending, or when it failed for any reason other than not found, the control shows for no one, the same silence as before creation.
A lookup that answers not found means the wallet has no identity contract yet. The control then reads "Create identity". It deploys the contract for that wallet on the network in view, and it is enabled when your account holds the create-identity permission on that network, which the identity-manager role grants; other accounts see it disabled with a tooltip explaining why. While the queue settles the deployment and the indexer picks it up, the control stays disabled, and the page moves on its own to the next state without a reload.
A lookup that answers with an identity contract that is not yet registered means the wallet is one step from holding value. The control then reads "Register identity" and opens the registration sheet, which writes the wallet and its country into the identity registry. It is enabled for identity managers and disabled with a tooltip for other accounts. Once the identity is registered, neither action shows.
The control is the bridge between "created" and "can hold". Until registration completes, the user can sign in and be assigned roles but cannot hold or receive a regulated token, because every token checks the identity registry before it moves balances, and there is nothing there yet to check. Onboard an investor runs the same sequence through the API, including the case where the wallet has no identity contract to register.
Troubleshooting
Access restricted
Ask an administrator for user-management access. The page does not show user data when your account cannot list users or manage invitations, and it never falls back to a partial or empty table.
The Send invitation email choice is missing
Your account can invite or create, but not both, so the Console runs the one path it permits without asking. Ask an administrator for the other permission when you need the choice between the two.
Turning off Send invitation email did not leave anything half-done
Turning the toggle off does not create a partial record. It runs a full, permission-gated direct-creation path that creates the user and provisions custody through several stages. If the result is pending or an error occurs, check whether the user already exists and whether custody is still settling before starting another creation request.
The confirm button in the resend dialog is disabled
Resending an invitation can regrant the on-chain roles it originally carried, so the Console checks first. The confirm button in the dialog that opens after you choose "Resend invitation" stays disabled while that check runs, and again whenever a resend is already in flight.
Once the check itself finishes, that first reason drops away, and whether the button asks for your PIN depends on what the check found. If it found on-chain roles on the invitation, or the check itself failed, resending routes through your PIN first. Otherwise, resending goes straight through, no PIN needed.
An overdue invitation still shows Pending
Pending, accepted, rejected, and canceled are the only statuses an invitation ever carries; no separate expired state exists. One that has passed its listed expiry date keeps showing "Pending" until you act on it. Resend it to reset the clock, or cancel it and send a fresh one.
Removing a user cannot be undone
Removal ends membership in this organisation and attempts session revocation. The underlying user account, wallet, identity, and other organisation memberships remain. Invite the existing account again if it needs access restored; do not create a duplicate account or assume on-chain roles were revoked.
Cancelling an invitation is final
A cancelled invitation cannot be reopened or resent. If the recipient still needs access, send a new invitation; the old one stays in the list marked "Canceled" for the audit trail.
Frequently asked questions
How does the Console decide whether a badge reads Admin, Trusted issuer, or Investor?
The fixed check order shown above decides the badge: system admin or system-manager roles first, then claim-issuer or trusted-issuer-registry roles, and investor when the account holds neither. The badge reflects the roles the account currently holds, not whether it was invited or created directly, and this order decides only the detail page's header, which has exactly those three outcomes.
The "Users" list adds a fourth value the header never shows. On a deployment with smart-account wallets enabled, the list reads "Pending" in place of any of the three while this account has a signing address but no transaction address yet, because role lookups run against that second address. Once the transaction address exists, the list badge settles into whichever of the three outcomes the check order above now finds.
Why does the toast say a new user's custody account is still settling?
Direct creation can return while the managed custody account is still being provisioned. The toast tells you the account exists but is not usable yet. Wait for it to finish before expecting to see holdings, or before the guidance checklist's identity step clears on its own.
Does removing a user also remove their Contacts or Entities record?
No. Users, Contacts, and Entities are three separate record types, and removing a member changes access to the active organisation. A wallet address you also track as a Contact, or a token or system identity you track as an Entity, is untouched, because those records were never tied to the login you just removed. Manage a Contacts or Entities record for the same counterparty separately, if you need one.
Organisation participants
Manage everyone the organisation tracks an identity for: users with a login, entities without one, saved contacts, and the verification records a token checks.
Contacts
Save counterparty names and wallet addresses for reuse during issuance and settlement, and learn what editing or deleting a saved contact does not affect.