On chain KYC for issuers

Who this is for: issuers deciding how to gate their token by identity, from a decision-making rather than a code-level view. For the developer-side integration steps, see Integrate on-chain KYC (dev guide). For what KYC verifies as a concept, see KYC (Know Your Customer).

What an issuer decides

Before any integration work happens, an issuer using on-chain KYC needs to settle:

• Who needs to pass. Every holder, or only holders above a certain allocation size or tier: see Eligibility & investor tiers.

• What "verified" means. A binary pass/fail, or a level tied to jurisdiction, accreditation status, or another category your counsel has defined per Compliance overview for issuers.

• What happens on failure or lapse. Whether a transfer to an unverified address simply reverts, whether an already-verified holder can later fall out of compliance (a credential expiring, for example), and what that does to their existing balance.

• Who provides verification. Whether you integrate a third-party KYC provider yourself, or rely on a Lumia-documented verifier pattern.

• Data retention. What evidence of the check you keep off-chain, and for how long: a requirement your counsel sets, not this documentation.

Where the technical integration lives

The concrete verifier flow, contract-level pattern, and any code sample live at Integrate on-chain KYC (dev guide). That page is written for a developer audience and is the single source for the integration mechanics. This page does not duplicate it.