# Claims and identity Source: https://docs.settlemint.com/docs/architecture/concepts/claims-and-identity Understand how participants, wallet registration, OnchainID claims, trusted issuers, claim topics, and token compliance expressions work together in DALP. What does DALP store on-chain? Which part comes from a verifier? When does a token decide whether an address is eligible? DALP separates identity registration from claim verification. A participant represents the person or entity that must satisfy compliance rules. One or more participant wallets can be registered to that participant's OnchainID, and the OnchainID holds claims such as KYC, AML, accreditation, or asset-specific eligibility. A token operation passes only when DALP can resolve the active wallet for the participant, confirm that the wallet is not marked as lost, and verify the required claim expression against trusted issuers. ## The model in one pass [#the-model-in-one-pass] 1. A person or entity becomes a participant during onboarding. 2. The participant receives an OnchainID contract for the chain and tenant context. 3. DALP registers the participant's wallet, OnchainID address, and country in the identity registry. 4. A trusted issuer adds claims to the OnchainID after the off-chain verification work finishes. 5. A token-local identity registry evaluates the token's compliance expression against those claims. 6. Compliance modules use the result when they check mints, transfers, and other regulated token actions. KYC documents and review evidence stay with the verifier and operator workflow. DALP records the on-chain result: the identity link, claim topics, issuer, signature, claim data, and references needed for verification. ## Terms [#terms] | Term | Meaning | | --------------------- | ----------------------------------------------------------------------------------------------------------- | | Participant | The person or entity that DALP treats as the compliance subject. A participant is mirrored by an OnchainID. | | Wallet | An EVM address owned by a participant. The active wallet sends or receives the regulated token operation. | | EOA | A signing wallet controlled by the participant. | | Smart wallet | A participant wallet used as the executor when account-abstraction routing is active for the organization. | | OnchainID | The identity contract associated with the participant. It stores keys and claims. | | Identity registry | The on-chain registry that maps a wallet to an OnchainID contract and country. | | Claim topic | A numeric topic that names what a claim certifies, such as KYC or AML. | | Claim | A signed statement on an OnchainID for one topic. | | Trusted issuer | An issuer identity that DALP trusts for one or more claim topics. | | Compliance expression | The token's logical requirement over claim topics, such as KYC and AML. | ## Wallets inherit the participant's identity [#wallets-inherit-the-participants-identity] A wallet is not a separate compliance subject. DALP resolves the participant first, then uses the active participant wallet for the token operation. The identity registry links that wallet address to the participant's OnchainID and country. A claim does not live on the wallet row. The claim lives on the participant's OnchainID. A participant can have an EOA and a smart wallet, and both registered addresses can route back to the same participant identity. Organization account-abstraction settings decide which wallet executes a request. When account-abstraction routing is disabled, DALP uses the participant EOA as the executor. When account-abstraction routing is enabled and a smart wallet exists for the participant, DALP uses that smart wallet. For personal participants, DALP can provision the missing smart-wallet row on demand and still keeps one canonical smart wallet for the participant. Wallet key verification protects account access and key use. It does not replace KYC, KYB, trusted issuer claims, or token compliance expressions. ## What verification checks [#what-verification-checks] When DALP verifies a wallet for a token, it checks the registration and then evaluates the token's claim expression. | Check | Why it matters | | -------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Wallet is not marked as lost | Recovered or disabled wallet paths do not pass eligibility checks. | | Wallet is registered | DALP must resolve the active wallet to a participant OnchainID before it can inspect claims. | | Claim topic is valid | A topic must exist in the topic scheme registry before it can satisfy a rule. | | Claim exists on the OnchainID | The participant identity must hold at least one claim for the required topic. | | Issuer is trusted for that topic | A claim only counts when its issuer is trusted for the matching topic and identity context. | | Claim signature validates | DALP asks the trusted issuer contract whether the claim is valid for the identity, topic, signature, and data. | An empty claim expression does not make every wallet eligible. Registration and lost-wallet checks still run first. The empty expression only means there are no additional claim-topic requirements after the wallet resolves to an active identity. ## How expressions work [#how-expressions-work] DALP stores claim requirements as expression nodes. Topic nodes represent claim topics. Operator nodes combine them with AND, OR, or NOT. The expression is evaluated in postfix order. For example, `(KYC AND AML) OR ACCREDITED` becomes: ```text KYC AML AND ACCREDITED OR ``` A topic passes when the participant's OnchainID has a valid claim for that topic from a trusted issuer. The full expression passes only when the logical result is true. ## Why trusted issuers are separate [#why-trusted-issuers-are-separate] Claims are not accepted just because they exist on an OnchainID. DALP checks the trusted issuers registry for the required topic. One issuer can be trusted for KYC. Another issuer can be trusted for accreditation, collateral, or a custom eligibility topic. The trusted issuer is the issuer identity contract. Rotating the signing key for that issuer should keep the issuer identity address stable, so existing trust relationships and topic assignments do not have to change. ## Where this model appears [#where-this-model-appears] * Registering users creates the wallet-to-identity link. * KYC and KYB verification workflows add claims after off-chain review. * Trusted issuer configuration defines which issuers can satisfy each topic. * Identity verification modules evaluate claim expressions as part of token compliance. * Transfer and mint checks combine identity verification with other compliance modules, such as country, supply, investor count, transfer approval, and time locks. * Account-abstraction routing decides whether the participant EOA or smart wallet is the active executor for an organization. ## Related pages [#related-pages] * [Identity and compliance](/docs/architecture/security/identity-compliance) * [Identity verification module](/docs/architecture/security/compliance/identity-verification) * [Compliance transfer flow](/docs/architecture/flows/compliance-transfer) * [Register user](/docs/user-guides/user-management/register-user) * [Configure trusted issuers](/docs/user-guides/compliance/configure-trusted-issuers) * [Rotate provider claim signer key](/docs/runbooks/rotate-provider-claim-signer-key)