Participant eligibility

This endpoint evaluates whether a participant currently satisfies the system-level compliance modules that apply to them as a receiver. The platform returns one of three verdicts: allowed, needs-action, or blocked, together with reason codes that explain any follow-up requirement or block, and the source used to calculate the result.

A module that is installed but scoped so it does not apply to this participant is skipped, so an allowed verdict confirms the participant passes every module that applies, not necessarily every module installed. See Scope-aware evaluation below.

Endpoint

GET /api/v2/participants/{participantId}/compliance-eligibility

By default, the endpoint reads the indexed projection. Use that path for ordinary page renders, list refreshes, and integration polling. live=true bypasses the indexer and checks the installed compliance modules with live contract reads, so the request can take materially longer and should not run in bulk list views. Your API key or session must carry one of the eligibility-read roles: System manager, Identity manager, or Claim issuer.

Request

curl --globoff "$DALP_API_URL/api/v2/participants/participant_123/compliance-eligibility" \
  --header "X-Api-Key: $DALP_API_TOKEN"

Add live=true only when you need a fresh answer after a recent compliance change. Avoid this flag in bulk list views; each call runs live contract reads and is materially slower than an indexed read:

curl --globoff "$DALP_API_URL/api/v2/participants/participant_123/compliance-eligibility?live=true" \
  --header "X-Api-Key: $DALP_API_TOKEN"

Response

The result uses the single-resource API envelope. The data object contains the verdict, source, timestamp, and any reason codes.

{
  "data": {
    "verdict": "needs-action",
    "source": "indexer",
    "checkedAt": "2026-06-06T03:00:00.000Z",
    "wallet": "0x1000000000000000000000000000000000000001",
    "reasons": [
      {
        "code": "claim-missing",
        "moduleTypeId": "identity-verification",
        "instanceAddress": "0x2000000000000000000000000000000000000002",
        "details": {
          "topic": "kyc-approved"
        }
      }
    ]
  },
  "links": {
    "self": "/v2/participants/participant_123/compliance-eligibility"
  }
}

When a participant has more than one wallet, the body can include wallets with the eligibility result for each address. The top-level verdict is the most restrictive across the wallet set: blocked takes precedence over needs-action, and needs-action takes precedence over allowed.

Response fields

Verdicts

Reason codes

details.topic appears on claim-related reasons. details.countryCode is set for country-list reasons when the platform can resolve the country. details.expiresAt is included when a claim expiry produced the reason.

Scope-aware evaluation

A system-level compliance module can be installed with a scope that limits which transfers it evaluates. When a module is scoped so it does not apply to a participant as a receiver, the platform skips it rather than fail the participant against a rule that would never run on a transfer to them. This mirrors the on-chain compliance engine.

A module is skipped for the participant when its scope excludes them along the receiver path. That happens in three cases:

• the binding sets a token inclusion list, which an eligibility check has no token context to satisfy
• a receiver allow or exemption list the participant does not match
• a receiver country inclusion or exclusion that rules them out

A module whose scope leaves all dimensions open applies to every participant.

Because of this, the verdict reflects only the modules that apply. Two participants on the same system can return different verdicts not because one failed a check, but because a scoped rule reaches one and not the other. Read the compliance modules API to see how each module is scoped before you interpret an eligibility result.

Live recheck behaviour

Use the indexed verdict unless you or a workflow explicitly need a fresh answer after a recent compliance change. The live path queries the installed compliance modules directly and sets source: "live" on the result.

If a live read times out, the platform does not fail the whole request. It returns the indexed verdict, marks the result as live-sourced, and adds live-timeout reasons for the modules it could not reach in time. Treat that as a partial answer and retry later before using the verdict for a sensitive decision.

Related pages

• Compliance API route map
• Compliance modules API
• Identity recovery API
• Identity and compliance