From 78511981960071f7ccd5896a029bd7ae188fbfa8 Mon Sep 17 00:00:00 2001 From: Eras256 <219895655+Eras256@users.noreply.github.com> Date: Tue, 13 Oct 2026 13:29:45 -0600 Subject: [PATCH 1/2] docs(blog): builder's guide to KYC, KYB, and KYA integration New post, author Monserrat Mendoza, EN+ES. Walks through the three attestation categories (person tiers 1-3, business tier 4, agent tier 5), how to call each from the SDK, a flow diagram, and four product shapes that gate on one category or another. Every snippet is checked against @kumply/sdk@1.3.0 as actually published on npm (downloaded the tarball, type-checked a draft against its real .d.ts files with tsc), not the repo's own packages/sdk/README.md, which already documents meetsTierRequirement (PR #26) ahead of any release. That helper doesn't exist in 1.3.0's exports, so it's not mentioned here. Everything described runs on Fuji; the post is explicit that KUMPLY's own team issues the demo attestations with no identity check behind them, and that Mainnet C-Chain stays at zero attestations until Sumsub production is active. No hackathon or track is named. Also adds minimal 
/ block styling to the post template (no
earlier post used one), verified by rendering both locales with run-web.

Co-Authored-By: Claude Sonnet 5 
---
 .../web/src/app/[locale]/blog/[slug]/page.tsx |   9 +
 apps/web/src/content/blog.ts                  | 224 ++++++++++++++++++
 2 files changed, 233 insertions(+)

diff --git a/apps/web/src/app/[locale]/blog/[slug]/page.tsx b/apps/web/src/app/[locale]/blog/[slug]/page.tsx
index 32eed66..72b955a 100644
--- a/apps/web/src/app/[locale]/blog/[slug]/page.tsx
+++ b/apps/web/src/app/[locale]/blog/[slug]/page.tsx
@@ -164,6 +164,15 @@ export default async function BlogPostPage({
           background: var(--bg-card); border: 1px solid var(--border);
           padding: 0.1em 0.4em; border-radius: 6px; color: var(--text-primary);
         }
+        .blog-post__body pre {
+          margin: 1.5rem 0; padding: 1rem 1.25rem; overflow-x: auto;
+          background: var(--bg-card); border: 1px solid var(--border);
+          border-radius: var(--radius-md);
+        }
+        .blog-post__body pre code {
+          background: none; border: none; padding: 0; font-size: 0.85em;
+          color: var(--text-primary); white-space: pre;
+        }
         .blog-post__body .blog-scenario {
           margin: 1.75rem 0; padding: 1.5rem 1.5rem 1.25rem;
           border-left: 3px solid var(--accent);
diff --git a/apps/web/src/content/blog.ts b/apps/web/src/content/blog.ts
index aa41663..77e52cf 100644
--- a/apps/web/src/content/blog.ts
+++ b/apps/web/src/content/blog.ts
@@ -21,6 +21,230 @@ export interface BlogPost {
 }
 
 export const BLOG_POSTS: BlogPost[] = [
+  {
+    slug: "building-with-kumply-kyc-kyb-kya",
+    date: "2026-10-13",
+    author: {
+      name: "Monserrat Mendoza",
+      role: { en: "Co-founder, Dev Lead", es: "Co-founder, Líder de Desarrollo" },
+    },
+    readMinutes: 7,
+    category: "GUIDE",
+    title: {
+      en: "A Builder's Guide to KUMPLY: KYC, KYB, and KYA in One SDK",
+      es: "Guía para Builders de KUMPLY: KYC, KYB y KYA en un Solo SDK",
+    },
+    excerpt: {
+      en: "Most compliance checks only answer one question: is this address a verified person. KUMPLY's AttestationStore answers three separate questions, person, business, or AI agent, because those aren't rungs on the same ladder. A practical guide: what each category is for, how to call it from the SDK published on npm today, a simple flow diagram, and four product shapes that use it.",
+      es: "La mayoría de las revisiones de compliance solo responden una pregunta: si esta dirección es una persona verificada. El AttestationStore de KUMPLY responde tres preguntas distintas, persona, empresa o agente de IA, porque no son escalones de la misma escalera. Una guía práctica: para qué sirve cada categoría, cómo llamarla desde el SDK publicado hoy en npm, un diagrama simple del flujo, y cuatro formas de producto que la usan.",
+    },
+    bodyHtml: {
+      en: `
+
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 is where most integrations 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

+
+

+
+
+REQUEST
+Your app
+checks an address before
+an on-chain action
+
+ON-CHAIN, FUJI
+AttestationStore
+verify() or a category
+helper, free read
+
+
+call
+ack
+
+
+
+
+based on tier
+
+KYC
+Person, tier 1-3
+isPersonAtLeast()
+-> allow
+
+KYB
+Business, tier 4
+isBusiness()
+-> allow
+
+KYA
+Agent, tier 5
+isAgent()
+-> allow
+No match: request blocked,
+no on-chain action, no gas spent
+
+
+
+
+
+
+
+
+

+
+
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

+
+

+
1. A DeFi pool gated to verified people. KYC. Check isPersonAtLeast(address, TIER.BASIC) (or a higher level, your call) before a deposit, so the pool only holds funds from addresses with some identity behind them.

+
2. A marketplace where only verified agents transact. KYA. Check isAgent(address) before an autonomous agent is allowed to list, bid, or settle, so a buyer knows a verified operator stands behind whatever it's dealing with.

+
3. Payments or payroll between verified businesses. KYB. Check isBusiness(address) on both sides of a B2B transfer, so the counterparty is a company, not an anonymous wallet.

+
4. One person, one vote, no bots. KYC. Check isPersonAtLeast(address, TIER.BASIC) before a wallet is allowed to vote, so a single verified person can't split one voice into a hundred addresses.

+

+
+
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.

+`,
+      es: `
+
La mayoría de las integraciones que "revisan KYC" responden una sola pregunta de sí o no: si esta dirección es una persona verificada. El AttestationStore de KUMPLY responde tres preguntas distintas, porque una dirección puede ser una persona verificada, una empresa verificada o un agente de IA verificado, y son tipos de cosa diferentes, no tres escalones de la misma escalera. Esta es una guía práctica para builders: qué controla en realidad cada categoría, cómo llamarla desde el SDK que hoy está publicado en npm, un diagrama simple del flujo, y cuatro formas de producto que usan una u otra categoría.

+
+
Tres categorías, no una escalera

+
+
KYC, tiers 1 a 3 (persona): una escalera para individuos, Basic, Standard y Enhanced. Responde "¿es esta una persona verificada, y qué tan profunda fue la revisión?". Controla una función con un nivel mínimo usando isPersonAtLeast().

+
+
KYB, tier 4 (empresa): una categoría separada, no un nivel arriba de Enhanced. Responde "¿esta dirección la controla una empresa verificada?", para casos como facturación, nómina o liquidación B2B donde la contraparte necesita ser una empresa, no un individuo.

+
+
KYA, tier 5 (agente): también separada, pensada para direcciones que controla directamente un agente de IA autónomo. Responde "¿hay un operador verificado detrás de este agente?", para marketplaces o rieles de pago donde la contraparte podría no ser humana en absoluto.

+
+
Integración con el SDK

+
+
El SDK es @kumply/sdk en npm (versión 1.3.0 al momento de este post). Instálalo con tu gestor de paquetes favorito:

+
+
pnpm add @kumply/sdk    # o npm / yarn

+
+
Apunta un cliente a Fuji y lee la attestation de una dirección con verify(), una lectura gratuita que funciona incluso con el contrato pausado:

+
+
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 es un número crudo, del 1 al 5. Compararlo directamente es donde la mayoría de las integraciones confunden la categoría: revisar tier >= 4 para "es una empresa" también deja pasar a un agente Tier 5, porque 5 es mayor que 4 en una recta numérica simple. Los helpers de categoría del SDK hacen la comparación correcta por ti: un rango para personas, un tier exacto para una empresa o un agente.

+
+
const puedeUsarPool = await client.isPersonAtLeast(address, TIER.STANDARD);
+const puedeFacturar = await client.isBusiness(address);
+const puedeOperar = await client.isAgent(address);

+
+
También existe un método hasTier(address, tier), que se mantiene por compatibilidad hacia atrás y está marcado @deprecated en los tipos publicados. Hace la comparación simple de "mayor o igual", así que hasTier(address, TIER.KYB) también regresa true para un agente Tier 5, y hasTier(address, TIER.STANDARD) regresa true para una empresa Tier 4. Casi nunca es lo que quieres, y es justo por eso que existen los helpers de categoría. Usa isPersonAtLeast, isBusiness o isAgent para cualquier cosa nueva.

+
+
Cómo fluye la revisión

+
+

+
+
+SOLICITUD
+Tu app
+revisa una dirección antes
+de una acción on-chain
+
+ON-CHAIN, FUJI
+AttestationStore
+verify() o un helper
+de categoría, lectura gratis
+
+
+llama
+ack
+
+
+
+
+según el tier
+
+KYC
+Persona, tier 1-3
+isPersonAtLeast()
+-> permite
+
+KYB
+Empresa, tier 4
+isBusiness()
+-> permite
+
+KYA
+Agente, tier 5
+isAgent()
+-> permite
+Sin match: solicitud bloqueada,
+sin acción on-chain, sin gastar gas
+
+
+
+
+
+
+
+
+

+
+
La app lee la dirección una sola vez, con verify() o con el helper de categoría que de verdad necesita, y la respuesta de KUMPLY (si esa dirección tiene una attestation válida y sin vencer en el tier correcto) es lo que decide cuál de los tres caminos toma la app, o si bloquea la acción y no gasta nada de gas.

+
+
Cuatro cosas que podrías construir

+
+

+
1. Un pool de DeFi solo para usuarios verificados. KYC. Revisa isPersonAtLeast(address, TIER.BASIC) (o un nivel más alto, tú decides) antes de un depósito, para que el pool solo reciba fondos de direcciones con alguna identidad detrás.

+
2. Un marketplace donde solo transaccionan agentes verificados. KYA. Revisa isAgent(address) antes de que un agente autónomo pueda publicar, ofertar o liquidar, para que quien compra sepa que hay un operador verificado detrás de lo que sea que esté tratando.

+
3. Pagos o nómina entre empresas verificadas. KYB. Revisa isBusiness(address) en ambos lados de una transferencia B2B, para que la contraparte sea una empresa, no una wallet anónima.

+
4. Una persona, un voto, sin bots. KYC. Revisa isPersonAtLeast(address, TIER.BASIC) antes de dejar votar a una wallet, para que una sola persona verificada no pueda dividir su voz en cien direcciones.

+

+
+
Dónde está esto hoy: todo lo anterior corre en la testnet Fuji de Avalanche. Las attestations que vas a ver ahí, incluyendo cualquiera que emitamos nosotros mismos para pruebas, son attestations de demo: el propio equipo de KUMPLY las emite directamente, sin revisión de documentos ni verificación de identidad detrás. Por favor no leas un Tier 5 de piloto como prueba de quién opera de verdad una dirección. Mainnet C-Chain aloja los mismos contratos en modo de solo lectura, con cero attestations emitidas hasta que activemos Sumsub en producción.

+
+
La documentación completa y más patrones de integración (paymasters, smart accounts) están en kumply.xyz/developers, y la documentación técnica general está en kumply.xyz/docs.

+`,
+    },
+  },
   {
     slug: "0xgasless-paymaster-pilot-kya",
     date: "2026-10-08",

From 5c2b307ecee24bb44652b65fabf74fb38dab5d48 Mon Sep 17 00:00:00 2001
From: Eras256 <219895655+Eras256@users.noreply.github.com>
Date: Tue, 13 Oct 2026 13:37:28 -0600
Subject: [PATCH 2/2] docs(blog): soften two sentences ahead of Monse's review

Avoids implying other compliance checks/vendors by name, and reads
more naturally: "often starts with one question" instead of "only
answer one question", and "makes it easy to get the category wrong"
instead of "is where most integrations get the category wrong".
EN + ES, no other change.

Co-Authored-By: Claude Sonnet 5 
---
 apps/web/src/content/blog.ts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/apps/web/src/content/blog.ts b/apps/web/src/content/blog.ts
index 77e52cf..ef86210 100644
--- a/apps/web/src/content/blog.ts
+++ b/apps/web/src/content/blog.ts
@@ -35,8 +35,8 @@ export const BLOG_POSTS: BlogPost[] = [
       es: "Guía para Builders de KUMPLY: KYC, KYB y KYA en un Solo SDK",
     },
     excerpt: {
-      en: "Most compliance checks only answer one question: is this address a verified person. KUMPLY's AttestationStore answers three separate questions, person, business, or AI agent, because those aren't rungs on the same ladder. A practical guide: what each category is for, how to call it from the SDK published on npm today, a simple flow diagram, and four product shapes that use it.",
-      es: "La mayoría de las revisiones de compliance solo responden una pregunta: si esta dirección es una persona verificada. El AttestationStore de KUMPLY responde tres preguntas distintas, persona, empresa o agente de IA, porque no son escalones de la misma escalera. Una guía práctica: para qué sirve cada categoría, cómo llamarla desde el SDK publicado hoy en npm, un diagrama simple del flujo, y cuatro formas de producto que la usan.",
+      en: "A compliance check often starts with one question: is this address a verified person. KUMPLY's AttestationStore answers three separate questions, person, business, or AI agent, because those aren't rungs on the same ladder. A practical guide: what each category is for, how to call it from the SDK published on npm today, a simple flow diagram, and four product shapes that use it.",
+      es: "Una revisión de compliance suele empezar con una pregunta: si esta dirección es una persona verificada. El AttestationStore de KUMPLY responde tres preguntas distintas, persona, empresa o agente de IA, porque no son escalones de la misma escalera. Una guía práctica: para qué sirve cada categoría, cómo llamarla desde el SDK publicado hoy en npm, un diagrama simple del flujo, y cuatro formas de producto que la usan.",
     },
     bodyHtml: {
       en: `
@@ -68,7 +68,7 @@ const client = new KumplyClient({
 const result = await client.verify(address);
 // { verified, tier, timestamp, expiry }
-

result.tier is a raw number, 1 through 5. Comparing it directly is where most integrations 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.

+

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);
@@ -170,7 +170,7 @@ const client = new KumplyClient({
 const result = await client.verify(address);
 // { verified, tier, timestamp, expiry }
-

result.tier es un número crudo, del 1 al 5. Compararlo directamente es donde la mayoría de las integraciones confunden la categoría: revisar tier >= 4 para "es una empresa" también deja pasar a un agente Tier 5, porque 5 es mayor que 4 en una recta numérica simple. Los helpers de categoría del SDK hacen la comparación correcta por ti: un rango para personas, un tier exacto para una empresa o un agente.

+

result.tier es un número crudo, del 1 al 5. Compararlo directamente hace fácil confundir la categoría: revisar tier >= 4 para "es una empresa" también deja pasar a un agente Tier 5, porque 5 es mayor que 4 en una recta numérica simple. Los helpers de categoría del SDK hacen la comparación correcta por ti: un rango para personas, un tier exacto para una empresa o un agente.

const puedeUsarPool = await client.isPersonAtLeast(address, TIER.STANDARD);
 const puedeFacturar = await client.isBusiness(address);