SettleMint
User management

Your onchain identity

Read the Onchain identity page on your DALP account. Understand your onchain identity address, your on-chain registration status, and the verifications that let you transact under a compliance policy.

Your onchain identity is the on-chain record that lets compliance policies recognize you. When a token enforces a rule like "holders must be KYC-verified in an allowed country," the policy reads the verifications attached to your identity to decide whether an action can proceed. The Onchain identity page is where you see that record: the identity address, whether it is registered on-chain, and the verifications it holds.

Open it from the user menu under Onchain identity.

Your onchain identity address

The first card shows your onchain identity address with a QR code. This is the on-chain identity contract that represents you. Verifications are issued against this address, and compliance checks resolve to it when they evaluate whether you can hold or move an asset.

If you do not have an identity yet, the card shows No identity registered instead of an address. An identity is created as part of onboarding and registration; until then, there is nothing for compliance policies to read.

Registration status and country

The Details card reports two facts about your identity:

FieldMeaning
Registration statusWhether your identity is registered on-chain. A registered identity is visible to the registry that compliance policies consult.
CountryThe country recorded for your identity registration, used by policies that restrict who can hold an asset by jurisdiction.

Registration is what makes your identity usable by compliance rules. An identity that exists but is not registered cannot satisfy a policy that requires a registered holder.

The verifications section

A verification is a signed statement about you, issued by an authorized party and recorded against your identity. KYC confirmation, an allowed-country attestation, and a qualified-investor status are all verifications. Compliance policies require specific verifications before they let an action through.

The section header shows an Active count: the number of verifications currently in force on your identity. Revoked verifications are not counted.

The table below lists each verification:

ColumnWhat it tells you
TrustedWhether the verification comes from an issuer registered in the trusted issuers registry. A trust badge marks verifications a policy will accept; an untrusted verification is recorded but is not honored by compliance checks.
VerificationThe verification topic, such as a KYC or country attestation.
StatusActive while the verification is in force, Revoked once it has been withdrawn.
IssuerThe address that issued the verification.
Verification dataThe values carried by the verification, where the topic defines them.

Select a row to open its history: a timeline of when the verification was added, changed, revoked, or removed, with the transaction behind each event. The history stays available after a verification is revoked, so the record is auditable.

Trusted versus untrusted issuers

A verification only carries weight when a compliance policy trusts its issuer. The trust badge tells you, at a glance, whether each verification is from an issuer the registry recognizes. An untrusted verification is preserved for the record but does not unlock anything a policy gates, because the policy will not accept an issuer it does not trust.

Issuing a verification

The Issue verification action opens a sheet to issue a new verification to your identity. You pick a verification topic and provide its values, then sign and submit.

This action is gated on the verification issuer role. If you do not hold that role, DALP tells you that you are not authorized to issue verifications. Issuing a verification with the same topic and the same issuer as an existing one replaces the existing one. A different issuer issuing the same topic creates a separate verification.

Revoking a verification

If your identity is the one shown, each active verification offers a Revoke action. Revoking marks the verification as invalid going forward while preserving it in the history for audit. A revoked verification drops out of the active count and stops satisfying any policy that depended on it.

On this page