Participant role assignments

A participant role assignment shows which access-control roles a participant holds, broken out by the participant's signing address and operations address. DALP returns this view at two scopes: system-wide roles for the whole deployment, and per-asset roles for one token.

Use these endpoints to audit who holds which authority and to confirm that a participant's granted roles are complete before they act. For the model behind the roles themselves, see Role-based access control and Authorization.

What the view answers

Each item describes one participant's role state across the addresses that can carry authority. The exact shape depends on whether account abstraction is enabled for the deployment.

When account abstraction is enabled

• eoaRoles lists the roles held on the participant's signing address (the externally owned account).
• smartWalletRoles lists the roles held on the participant's operations address (the smart account used when account abstraction routes the operation).
• missingRoles lists roles the participant holds on the signing address but not on the operations address.
• drift is true when missingRoles is non-empty, meaning at least one role the participant holds on the signing address is not present on the operations address.

Read drift and missingRoles together when you reconcile permissions. A participant can hold a role on the signing address that the operations address does not carry, so an operation routed through the operations address would not have it. The view surfaces that gap instead of hiding it behind a single combined list. The comparison is one-way: it reports signing-address roles that the operations address is missing, not roles that exist only on the operations address.

When account abstraction is disabled

In deployments without account abstraction, the view falls back to a consolidated read of indexed role rows. Every role found for a participant is reported in eoaRoles, while smartWalletRoles, missingRoles, and drift are always empty or false because there is no separate operations address to compare against. Integrators should treat eoaRoles as the complete role set for the participant in this mode.

Endpoints

Both endpoints are frozen v2 collection contracts. They return the standard DALP collection envelope with data for the page of items, meta for total count and facets, and links for pagination.

See Organization and system scope for how the active organisation and chain context bound every read.

Path parameters

Item fields

The two scopes share the same shape, with one difference: the per-token view also returns accountAddress and reports isContract per participant, while the system view always reports isContract as false.

Contract rows in the per-token view

The per-token endpoint also returns rows for role-holder accounts that are not mapped to a participant. These rows have participantId, signingAddress, and operationsAddress set to null, accountAddress and displayName set to the role-holder address, and isContract set to true. They are distinct from participant rows where participantId is null because the caller cannot resolve participant names. In those masked participant rows, signingAddress and operationsAddress are still present.

Role names

The role names returned in eoaRoles, smartWalletRoles, and missingRoles depend on the scope.

• System view uses system roles: admin, auditor, systemManager, tokenManager, complianceManager, claimPolicyManager, claimIssuer, identityManager, feedsManager, gasManager.
• Per-token view uses asset roles: admin, custodian, emergency, fundsManager, governance, saleAdmin, supplyManagement.

Query the list

Both endpoints accept the standard collection query parameters: pagination with page[limit] and page[offset], sorting with sort, global search with filter[q], and per-field filters. The default sort is by displayName.

You can filter and build facets on the role arrays and on drift. To list every participant in drift, meaning they hold a role on the signing address that the operations address does not carry:

curl --globoff "https://your-platform.example.com/api/v2/system/participants/roles?filter[drift]=true" \
  -H "X-Api-Key: YOUR_DALP_API_KEY"

To list participants whose signing address holds a specific system role:

curl --globoff "https://your-platform.example.com/api/v2/system/participants/roles?filter[eoaRoles]=complianceManager" \
  -H "X-Api-Key: YOUR_DALP_API_KEY"

filter[eoaRoles] matches the signing address only. When a participant holds a role on the operations address instead, that grant appears in smartWalletRoles and is not returned by an eoaRoles filter. To audit every account that can exercise a role, check both eoaRoles and smartWalletRoles rather than filtering on eoaRoles alone.

For the per-token view, supply the token address in the path:

curl --globoff "https://your-platform.example.com/api/v2/tokens/0xTOKEN/participants/roles?filter[drift]=true" \
  -H "X-Api-Key: YOUR_DALP_API_KEY"

The response includes facet counts in meta for the filterable role fields and drift, so a client can show how many participants hold each role or are in drift without making a second call.

Authorisation

Reading the system view requires a caller with the roles that govern system access listing. Reading the per-token view requires read access to that token. Participant name resolution is gated separately: when the caller cannot resolve participant names, participantId is returned as null and displayName falls back to the participant's signing address. The role rows and addresses are still returned.

Related

• Role-based access control
• Authorization
• Organization and system scope
• Request headers