A Builder's Guide to KUMPLY: KYC, KYB, and KYA in One SDK

Most "check KYC" integrations answer a single yes-or-no question: is this address a verified person. KUMPLY's AttestationStore answers three separate questions, because an address can be a verified person, a verified business, or a verified AI agent, and those are different kinds of thing, not three steps up the same ladder. This is a practical walkthrough for builders: what each category actually gates, how to call it from the SDK that is live on npm today, a simple diagram of the flow, and four product shapes that use one category or another.

Three categories, not one ladder

KYC, tiers 1 to 3 (person): a ladder for individuals, Basic, Standard, and Enhanced. It answers "is this a verified person, and how deep was the check." Gate a feature on a minimum level with isPersonAtLeast().

KYB, tier 4 (business): a separate category, not a level above Enhanced. It answers "is this address controlled by a verified business," for cases like invoicing, payroll, or B2B settlement where the counterparty needs to be a company, not an individual.

KYA, tier 5 (agent): also separate, built for addresses an autonomous AI agent controls directly. It answers "does a verified operator stand behind this agent," for marketplaces or payment rails where the counterparty might not be a human at all.

Integrating with the SDK

The SDK is @kumply/sdk on npm (version 1.3.0 as of this post). Install it with your package manager of choice:

pnpm add @kumply/sdk    # or npm / yarn

Point a client at Fuji and read an address's attestation with verify(), a free view call that works even while the contract is paused:

import { KumplyClient, DEPLOYMENTS, TIER } from "@kumply/sdk";

const client = new KumplyClient({
  network: "fuji",
  contractAddress: DEPLOYMENTS.fuji.attestationStore,
});

const result = await client.verify(address);
// { verified, tier, timestamp, expiry }

result.tier is a raw number, 1 through 5. Comparing it directly makes it easy to get the category wrong: checking tier >= 4 for "is this a business" also passes a Tier 5 agent, because 5 is greater than 4 on a plain number line. The SDK's category helpers do the right comparison for you: a range for people, an exact tier for a business or an agent.

const canUsePool = await client.isPersonAtLeast(address, TIER.STANDARD);
const canInvoice = await client.isBusiness(address);
const canTrade = await client.isAgent(address);

There is also a hasTier(address, tier) method, kept for backward compatibility and marked @deprecated in the published types. It does the plain "greater than or equal" comparison, so hasTier(address, TIER.KYB) returns true for a Tier 5 agent too, and hasTier(address, TIER.STANDARD) returns true for a Tier 4 business. Neither of those is usually what you want, which is exactly why the category-specific helpers exist. Use isPersonAtLeast, isBusiness, or isAgent for anything new.

How the check flows

The app reads the address once, either with verify() or with the category helper it actually needs, and KUMPLY's response (whether that address holds a valid, non-expired attestation at the right tier) is what decides which of the three paths the app takes, or whether it blocks the action and spends no gas at all.

Four things you could build

Where this stands: everything above runs on Avalanche Fuji testnet. The attestations you'll see there, including any we issue ourselves for testing, are demo attestations: KUMPLY's own team issues them directly, with no document check or identity verification behind them. Please don't read a pilot Tier 5 as proof of who actually operates an address. Mainnet C-Chain hosts the same contracts read-only, with zero attestations issued until we activate Sumsub in production.

Full reference docs and more integration patterns (paymasters, smart accounts) are at kumply.xyz/developers, and the general technical documentation is at kumply.xyz/docs.