Moments

When you look up a token through Bluprynt's public API (GET /kyi/v1/tokens), the response tells you whether the token passed KYI (kyi_verified). It also includes the evidence behind that claim:

• Authorities: the addresses that control the token, such as its owner() or a Safe multisig and its signers.
• Verifications: the wallet proofs showing that the issuer controls one of those authorities. A proof is a signature, a contract signature or an on-chain transfer (see Wallet verification). Each verification names the authority it backs, and that authority must be one of the token's listed authorities.

The SDK re-checks that evidence against public data and your own RPC, so you don't have to rely on the kyi_verified flag alone.

Experimental

The KYI response types follow the public API's current shape. They will change until they are generated from the OpenAPI spec.

Which moment to ask for

The SDK reports facts, not verdicts: what held, and when.

Chain state changes. A wallet that controlled a token six months ago may not control it today. Whether that matters depends on your question:

Your question	Moment to check
Did a claim made six months ago hold when it was made?	"verified"
Is a recent claim backed?	"verified" on the newer record, or the instant it was made
Does the wallet still control the token?	"now"

By default the SDK works offline. It checks only timeless facts: who signed what, whether the wallet backs the authority it names, and whether that authority is listed for the token. It makes no RPC calls and needs no rpcUrls.

To read chain state, ask for moments with at:

const report = await verifyKyiResponse(response, {
  rpcUrls: { "eip155:1": "https://mainnet-eth.rpc.example.com" },
  at: ["verified", "now", new Date("2026-04-01T00:00:00Z")],
});

Each moment is reported separately, under its own label:

• "verified": each record's own moment. For a verification, that's its verified_at, and its own authority is also read at that time. For a listed authority, it's observed_at. An EVM contract signature is read at its recorded block.
• "now": the latest state the RPC serves.
• A Date: the instant you choose. Its label is the ISO string, such as "2026-04-01T00:00:00.000Z".

The SDK doesn't pick a moment for you, and it has no maximum age. If a 6-month-old verification's wallet is no longer an authority, the report says it held then and doesn't hold now: valid at "verified", invalid at "now". Showing a badge walks through two examples. Each result carries the timestamps and chain positions it was read at, so you can apply your own freshness rule.

Some chains can't answer for every moment. A Solana RPC can't read past account state, so a past moment there is unverifiable. That is a limit of the chain, not a failed check.

What gets checked, and when

For each verification, the SDK first checks that wallet_address is the authority itself or one of its signers. It then re-checks the proof according to its method. When you use verifyKyiToken or verifyKyiResponse, it last checks that the verification's authority is listed in the token's authorities, with the same type and the same address. Without that, a proof for some unrelated authority could vouch for the token, so the verification is invalid. Addresses are compared with the chain's rules: exactly on Solana and XRPL, ignoring case on EVM.

These checks are timeless and go in the verification's proof. Everything that depends on chain state runs only at the moments you ask for. At each moment, a verification is re-checked by its method and its own authority is read on-chain. Each listed authority is read on-chain at each moment too. Authority types the SDK can't check are unverifiable at every moment and need no RPC. A multisig can be an exception, depending on the chain: see the Reference for EVM, Solana and XRPL. A moment before the record, or "verified" for a record with no moment, gets its own reason instead (see Reading the report).

How each chain reads a moment, and which methods and authorities it checks, is in the Reference: EVM, Solana and XRPL.

Which function to call

Each chain has its own checker: evmKyi, solanaKyi and xrplKyi. Each chain package also exports functions bound to its checker.

Function	Checks
verifyKyiResponse(response, options)	A whole GET /kyi/v1/tokens response
verifyKyiToken(item, options)	One item from the response's data
checkKyiVerification(verification, token, options)	One verification on its own
checkKyiAuthority(authority, token, options)	One authority on its own

All of them accept at and rpcUrls. The @bluprynt/sdk versions of verifyKyiResponse and verifyKyiToken also take chains, and route each token to the checker for its chain.

verifyKyiToken and verifyKyiResponse check that each verification's authority is listed for the token. checkKyiVerification skips that check. Use the token or response functions when it matters.