Entities
Review and register organisation participants without login credentials, act on incoming registration requests, and see which data feeds each one publishes.
Entities is the organisation registry for participants that have no login credentials: a token contract, a smart account, or another system identity that must be able to hold value or issue data but never signs in to the Console. Reach for this page when you need to check whether such a participant is registered, find its identity address to compare against an approved source, or add a new one. This registry is the wrong place for a person or a service that logs in; that record belongs on Users. A "participant" is the general term the Console uses for anything the platform tracks an 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 for, whether or not it can log in. An entity is a participant without login credentials, and this page is one of two rosters, alongside Users. The same identity mechanism, and the same verification and eligibility rules, apply to both, which is why Insights and verification workflows often treat the two rosters as one combined population even though they live on separate pages.
Every row connects an entity's contract or wallet address to its on-chain identity address, and the two addresses answer different questions. The contract or wallet address is where the entity's value actually sits and where a transaction would send or pull funds. The identity address is a separate on-chain contract that regulated tokens check before they let that contract or wallet hold or move a balance. This address plays the same role a user's identity plays, just for a participant that has no login to attach it to. A "Registered" status means this identity contract exists and is wired to the entity; it does not by itself mean any specific token will accept the entity as a holder, because each token still evaluates its own configured rule set independently.
Registration alone unlocks nothing on any specific token. Registration only makes the entity visible to the identity check every regulated token runs on its own schedule, the same point-of-transfer check described on Verify a participant. A token does not scan the registry and pre-approve a newly registered entity, and no counterparty or existing holder is notified when a new entity registers. The entity operator does not request per-token approval either; the first time it matters is the moment someone attempts an operation naming that entity, and the token's own rule set decides then. An operation naming an entity that is still "Pending registration" does not block or wait for that registration to finish. It runs the same point-of-transfer check as any other operation, and fails the same way it would for an entity with no identity wired at all. A pending entity has no accepted identity yet for a token to find. Registration has no undo in the Console. Neither this page nor the entity's detail page offers a way to remove or replace an identity once it is registered. If the wired identity address is wrong, you cannot correct it from here. The entity's detail page keeps an activity view of the on-chain events tied to its account, including the registration transaction itself. That record is the audit trail for what happened to this entity and when, and it carries no separate approval or notification log beyond that.
The registry also groups entities by type: Token, Asset, Bond, Equity, Fund, Deposit, Stablecoin, Real Estate, Precious Metal, Wallet, Smart Account, System, and plain Contract. These are not cosmetic labels. A token-family type marks a contract that a Primary Offering or Trading venue can actually reference as tradable. A Smart Account or Wallet type marks a controlling account with no asset semantics of its own. System marks infrastructure the platform itself relies on. Knowing which type you are looking at tells you what kind of operation the entity can be a party to before you open its detail page.
Steps
Open Entities
Open "Organisation participants", then "Entities". Review registered entities and pending registrations.
Screen equivalent: the registry table lists each entity's name, contract address, identity address, type, and status. A row with no resolvable name shows a placeholder rather than a blank cell; a row with no contract or identity address shows the same. When at least one participant has asked to register here, a separate "Pending registrations" panel appears below the table. Each request gets its own row, with an Accept button and a Reject button; the panel is absent entirely when nothing is waiting.
Add a participant, if you are creating one
Select "Create participant" from your account's own Participants page, not from this registry directly; this opens the "Add participant" sheet and keeps entity creation tied to the account that provisions the controlling wallet. Enter a display name and select an available custody configuration. If account abstraction is enabled, also choose the wallet type. A self-custody configuration requires the owner to prove control of the wallet.
| Wallet type | Choose it when |
|---|---|
| EOA | The participant uses a standard wallet controlled through the selected custody configuration. |
| Single-sig smart account | The participant needs smart-account features with one controlling signer. |
| Weighted multisig smart account | Execution requires an approved signature weight to reach a threshold. |
A managed EOA or single-sig choice asks for verification before provisioning. A self-custody choice can create a participant that is waiting for its owner's proof of control. Follow the pending instruction in the sheet before expecting a usable identity. A failed attempt preserves the entries and its retry identity while the sheet remains open; check the result before closing it and starting another attempt.
A multisig choice opens a draft instead of submitting immediately.
- Pick the signing account. Whichever account you select becomes the draft's first signer automatically.
- Add every other signer, either a platform participant by invite link or an external address directly, and set each signer's weight as you add them. An invite link is shown once only: if you move on before copying it, recovering it means revoking that invite and creating a new one, which resets whatever progress that signer had made toward accepting.
- Set a threshold no higher than the total weight of every signer added so far, since the Console blocks a threshold it cannot satisfy. An invited signer's weight only counts toward that total once they accept, and finalizing stays blocked while any invite is still outstanding.
- Once every invite has resolved and the threshold is achievable, finalize the draft with a second verification code; this is the step that actually creates the participant, not the draft itself.
Closing the sheet before finishing does not discard the draft.
Register an identity directly, or act on an incoming request
Select "Register existing identity" directly on this registry when you already know the on-chain identity address to register. Enter it, choose the country every wallet on that identity will register under, review the summary, provide your verification code, and confirm; registering activates that participant in your organisation immediately, along with every wallet on the identity.
The "Pending registrations" panel from the previous step covers the reverse direction: a participant that already exists in a different organisation has asked to register in yours. Selecting Accept on a request opens the same registration sheet, pre-filled with that request's identity address, so you still choose a country and provide your verification code before anything activates. Rejecting removes the request outright; the participant can send it again later, so rejecting is not a permanent block. Both need the identity-register permission, the same permission "Register existing identity" needs on its own.
Find the entity and judge its status
Use the table filters or search, then select the entity row to open its detail page, which shows basic information, the available identity records, and separate views for verifications, activity, and data feeds. Confirm the status shown there first. For a "Registered" entity, use the identity and verification views to confirm it holds what a specific token requires before you treat it as eligible for that token's operations. A "Pending registration" entity can have an identity contract while its registration is still unaccepted, so treat any operation naming it as not eligible until registration completes.
Data feeds on an entity
An entity's detail page can show a "Data feeds" tile summarising the Market DataMarket Data gives valuation, compliance, and reporting one governed price for an asset or currency pair, so they stop reconciling separate copies of the market.Read the concept feeds related to it: a "Related feeds" count and a "Last update" time, rather than a list of the feeds themselves. A feed counts as related for one of two distinct reasons, and the tile's count does not distinguish which applies. Either the feed is scoped directly to this entity's own contract or identity address, meaning the feed describes that entity. This does not establish who published it. Alternatively, this entity is registered as a trusted issuer for the feed's topic, meaning it is authorised to attest to that kind of data even though the feed itself belongs to a different contract. The first case is the subject of the data; the second is authority to publish for a topic. If the count is higher than you expected, select "View feeds" to open the individual feeds it covers, since a trusted-issuer relationship can inflate the count without this entity publishing anything itself. "Last update" is a single aggregate: the most recent publish time across every related feed, or "Never" when none of them has published yet. The tile shows a "No data feeds configured" state when neither relationship applies to anything.
Troubleshooting
Access restricted
Ask an administrator for entity-list permission. The Console denies the registry when the system permission read fails.
The entity is pending
"Pending registration" covers two different waits, and telling them apart decides what you do next. Before anyone has registered an identity for this entry, it stays "Pending registration" indefinitely; review "Pending registrations" or register the identity directly from the authorised account, since nothing advances it on its own. After that step is submitted, the entry stays "Pending registration" a second time while the Console's own request waits on the underlying chain transaction and its indexed confirmation before it returns. You do not need to refresh the page during this second wait, and there is no fixed duration for it. If the status stays "Pending registration" long after you know the registration step was submitted, the underlying transaction is the thing to check, not this page; ask whoever administers your organisation's chain operations before resubmitting. Do not issue a verification against an unconfirmed target either way.
No participant found at that identity address
Nothing exists at the address you entered, on this chain. The identity address is the separate contract described earlier on this page, not the entity's own contract or wallet address, and entering the wrong one of the pair produces exactly this result. Correct it and submit again.
The identity is already registered
The identity address already has a registration in the target organisation, and the request fails with a conflict instead of the not-found result above. This turns up when two identity managers act on the same pending request at the same time, or when you register an address for a participant that has already completed registration. The Console does not translate this failure into friendly copy the way it does the not-found case. You see the raw conflict message with a reference id instead, which identifies the conflict. Check the target organisation and its registration record before retrying.
Accept is unavailable on a pending registration
The request is missing the wallet or identity address the registration sheet needs, so there is nothing yet to register. This happens on the requesting participant's side, not yours; nothing here can supply the missing address for them. Reject stays available, and the participant can send a complete request again once it carries both addresses.
Finalize is disabled on a multisig draft
Four conditions gate it, and any one blocks the button. The threshold is not achievable with the signer weights added so far, an invited signer has not yet accepted or been revoked, or the draft itself is no longer open. A threshold edit you just made can also block it briefly while the save is in flight. An unresolved invite is the most common cause, since an invited signer's weight does not count toward the threshold until they accept. Wait a beat for an in-flight save; the button re-enables on its own. Check the draft's threshold and signer list first either way.
Registered, but a token still rejects the entity
Registration alone does not establish eligibility. Open Verify a participant for this entity and confirm it holds the verifications the token requires; a fully registered entity can still lack one of those claims. If the verification view is complete and the operation still fails, the token is applying a rule it evaluates only at the moment of the operation, which this page cannot see in advance. Inspect the operation's eligibility check or failure reason before retrying.
Participant creation failed
The Console preserves the name and wallet-type entries you already made so you can retry without starting over. Read the error and check the selected custody configuration, proof-of-control state, and active network. A repeated failure can also come from rate limits or incomplete identity infrastructure. Ask the platform operator to investigate with the error reference if the form cannot resolve it.
Frequently asked questions
What is the difference between "Register existing identity" and "Add participant"?
"Register existing identity" attaches an identity address that already exists somewhere on-chain to a participant in your organisation; nothing new is provisioned. "Add participant" does the opposite: the Console creates a new wallet and a new identity together, then registers that new identity. Reach for the first when the identity already exists and you have its address; reach for the second when the participant needs a wallet before it can exist at all.
I closed the multisig draft sheet before finalizing it. Did I lose it?
No. An open multisig draft is not tied to the browser tab that created it. Reopen the sheet by selecting "Create participant" from your account's own Participants page, choose the multisig wallet type again, and the draft appears in an open-drafts list with a resume button, carrying every signer and weight you had already added.
Does accepting a pending registration verify anything about the requester?
No. The confirmation summary, the identity address and the country you choose, is the only check this page performs. Selecting Accept and confirming activates the participant and all its wallets immediately, the same as registering an identity address you typed in yourself. Confirming a participant's legitimacy, or whatever your organisation's own process requires, happens before you accept, not as part of it.
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.
Insights
Read identity and verification counts for the selected organisation and network, and know when to stop trusting the aggregate and open the participant record.