mint and on every
transfer, the token calls is_verified(account) on whatever contract is set as its
identity_verifier. Two contracts implement that interface on Stellar:
Both are Stellar-only and have no EVM counterpart beyond
WhitelistVerifier.sol.
whitelist-verifier
Soroban port ofWhitelistVerifier.sol — admin-controlled allow-list implementing
IdentityVerifierInterface.
Deploy
verifierAddress, or later):
attestation-registry
A generic “someone trusted records a fact, anyone can verify it later” primitive. An allow-listed attestor records a typed claim about a subject:- Subject —
Account(address)orAsset(asset_id)(the same 32-byteasset_idevery template is initialized with; the SDK hashes your asset ID string the same wayTokenFactorydoes). - Claim type — a short
Symbolyou choose, e.g.KYC,TITLE,DELIVERY,CREDIT. - value (
i128) — numeric payload: KYC tier, credit score, quantity delivered,1/0. - data (
String) — anything else: document hash, registry reference, URI, small JSON. - expires_at — unix seconds, or
0for never.
revoked but keeps it readable.
As an identity verifier
The registry implementsis_verified too: an account is verified when its latest
valid claim of the verifier claim type (default KYC) has value > 0. So a KYC
provider can be made an attestor and every template pointed straight at the registry.