Agentic identity

Agentic identity is the question every payment system has to answer for an AI agent: who is this agent, what does it control, who actually signs for it, and how can anyone verify any of it? Sly’s answer is five facets, each independently verifiable.

This page is the unified view. Each facet has a dedicated page or page-section: KYA tiers covers tier verification, Settling on Stellar and Settling on Base cover the chain-side per-call layers per rail, and A2A agent card covers the ERC-8004 NFT registry.

                ┌────────────────────────────────────────────────────────────┐
                │                   Agentic identity                         │
                │   Facets 1–4 bind per call · Facet 5 binds the agent       │
                └────────────────────────────────────────────────────────────┘
                          │       │       │       │              │
        ┌─────────────────┘       │       │       └──────────┐   │
        │           ┌─────────────┘       └────┐             │   │
        ▼           ▼                          ▼             ▼   ▼
   ╔══════════╗ ╔══════════╗            ╔══════════╗ ╔════════════╗ ╔══════════╗
   ║ Tier     ║ ║ Control  ║            ║ Custody  ║ ║Discover-   ║ ║ Registry ║
   ║ (Sly)    ║ ║ (chain)  ║            ║ (chain)  ║ ║ ability    ║ ║ (chain)  ║
   ╚══════════╝ ╚══════════╝            ╚══════════╝ ╚════════════╝ ╚══════════╝
   KYA T0–T3    SEP-10 /                env_key /    AttestProtocol  ERC-8004
   declared,    EIP-191                 oz_soroban / / EAS —         NFT — agent
   verified,    challenge-              safe_evm —   per-receipt     minted on
   trusted      response                who actually hash anchored   Identity
                proof of key            signed       to public       Registry
                control                              schema          contract

Each facet answers a different question:

Facet	Scope	Question	Receipt field
Tier	per-call	How thoroughly has Sly verified this agent?	`agent_kya_tier`
Control	per-call	Does the agent provably hold the keys for the address it claims?	`agent_chain_proof`
Custody	per-call	Where do those keys actually live right now?	`agent_custody_provider`
Discoverability	per-call	Can a stranger verify this call from chain alone?	(anchored on-chain)
Registry	per-agent	Does this agent have a persistent, portable, public on-chain identity?	(NFT on Identity Registry)

Facets 1–4 are bound to each call — they live in the receipt envelope and are part of the canonical encoding (json-sort-keys-v1) that the HMAC signs. Facet 5 is bound to the agent itself — it’s a persistent NFT that exists across calls, settles, and outlives Sly.

Sly’s formal identity verification tiers — the direct parallel to KYC/KYB for humans. Four tiers, graduated spending limits, each tier requires more verification.

Tier	Label	Per-tx	Daily	Requirements
0	Registered	$20	$100	Agent created
1	Declared	$100	$500	DSD declaration filed
2	Verified	$1,000	$5,000	30-day history OR enterprise override
3	Trusted	Custom	Custom	Kill-switch operator + Continuous Agent Integrity

The receipt stamps agent_kya_tier at sign time — frozen in the envelope. Even if the agent’s tier later changes (or gets revoked), that receipt’s tier value stays exactly what it was when Sly approved the payment. → Full details: KYA tiers

Tier verification tells you Sly trusts the agent. Chain binding tells you the agent provably controls the on-chain address the receipt names. Without it, the agent’s address is just an assertion — a wallet field Sly accepted on faith. The mechanism is rail-specific but conceptually identical: Sly issues a fresh challenge, the agent signs it with the keypair it claims to control, Sly verifies the signature.

Rail	Protocol	Endpoint
Stellar	SEP-10 Web Authentication	`POST /v1/agents/:id/stellar/challenge` → sign → `POST /stellar/bind`
Base	EIP-191 personal_sign	`POST /v1/agents/:id/evm/challenge` → sign → `POST /evm/bind`

After binding, the receipt’s agent_chain_proof field flips:

Value	Meaning
`asserted`	Address claimed but not cryptographically proven
`sep10`	Stellar address proven via SEP-10 challenge signature
`eip191`	EVM address proven via EIP-191 challenge signature

Bindings render in the agent detail page’s Chain Bindings panel with a green ✓ SEP-10 PROVEN / ✓ EIP-191 PROVEN badge; asserted addresses render with an amber asserted badge that explains, in the tooltip, what’s NOT cryptographically backed. → Rail specifics: Settling on Stellar · Settling on Base

The most common identity mistake in agentic-payment systems is conflating “the agent’s address is X” with “the agent’s process controls X’s keys, right now.” Facet 2 proves the agent signed once at bind time. Custody disclosure tells you where the keys actually live for each new signature. The receipt’s agent_custody_provider field stamps whichever provider actually signed the call:

Value	Means	Status
`env_key`	Private key in env (sandbox default — convenient, not custodial)	✅ Live
`oz_soroban`	OpenZeppelin Soroban smart account (Stellar)	🚧 Receipt-side abstraction shipped, on-chain contract deployment in progress
`safe_evm`	Safe smart-account custody via ERC-4337 bundler (Base)	🚧 In development
`crossmint`	Crossmint-managed wallets	📋 Future

This is the structural change that lets future custody providers drop in without breaking any receipt verifier — the canonical encoding handles new values by design. No fake green checks: if the keys are still in env, the receipt says env_key. The honesty is the feature.

Facets 1–3 are discoverable through Sly’s API and your tenant database. Facet 4 makes the receipt’s existence visible from chain alone — without trusting Sly. The /anchor route publishes the receipt hash to chain under Sly’s schema:

Backend	Network	Status
`eas-base`	Ethereum Attestation Service on Base / Base Sepolia	✅ Production
`attest-stellar`	AttestProtocol on Soroban	🟡 Wired, latent — pending upstream contract init

Once anchored, anyone with the schema UID can:

Scan all Sly receipt anchors for a given agent
Pull the on-chain attestation
Re-derive the canonical receipt hash from the source receipt
Byte-compare — without ever calling the Sly API

This is what survives Sly going offline. The on-chain anchor is the governance attestation; the underlying settlement tx is the money movement. Together they make a payment verifiable end-to-end without depending on any single party — including Sly. → Rail specifics: Settling on Stellar · Settling on Base

Facets 1–4 prove things about each call. Facet 5 makes the agent itself discoverable as a first-class on-chain entity — a persistent NFT identity that exists across calls, settles, and Sly’s uptime. Sly registers agents on the ERC-8004 Trustless Agents Identity Registry — an ERC-721 contract on Base / Base Sepolia. Each agent gets a unique token ID that any system can read, link to, and build reputation around independent of Sly’s database.

# Mint the NFT identity (one-time, costs gas — sponsored by Sly platform wallet)
curl -X POST https://api.getsly.ai/v1/agents/$AGENT_ID/erc8004 \
  -H "Authorization: Bearer pk_test_…" \
  -d '{ "chain": "base" }'
# → { "agent_id": "…", "erc8004_id": "1234", "tx_hash": "0x…",
#     "explorer": "https://sepolia.basescan.org/nft/0x13b5…/1234" }

After registration, the agent’s A2A agent card (GET /a2a/<agent_id>/.well-known/agent.json) carries the NFT link, and the on-chain Reputation Registry accrues per-counterparty feedback that anyone can query — including buyers comparing your agent against others.

Component	What it does
Identity Registry (ERC-721)	Mints the agent as an NFT. Token ID = persistent agent identity.
Reputation Registry	Per-counterparty feedback aggregated on-chain via `getSummary(agentId, …)`.
A2A agent card	Public JSON discovery document with `identity.erc8004_id` + reputation links.
Sly reputation source	Composes the on-chain NFT + reputation + Sly’s KYA tier + age + activity into a single trust score for marketplace ranking.

What lives where

Network	Identity Registry	Reputation Registry	Status
Base mainnet	`0x8004A169…9a432`	`0x8004BAa1…9DE9b63`	✅ Live
Base Sepolia	`0x13b52042…7a89c`	`0xB5048e3e…869e322`	✅ Live (sandbox)
Stellar mainnet / testnet (Soroban)	—	—	🚧 Work in progress

Stellar — work in progress. A Soroban-based agent identity registry comparable to ERC-8004 is in development. The closest existing in-tree primitive is AttestProtocol — which we already use for per-receipt hash anchoring (Facet 4) — but AttestProtocol attests to facts, not agents. The proper analog is a persistent Soroban smart contract registry under Sly’s anchor authority. Contact us if Stellar Facet 5 is on your critical path and we’ll prioritize.

Why this matters

Portability — the NFT identity survives Sly going offline. Your agent’s track record isn’t locked in Sly’s database.
Composability — any DeFi/marketplace contract on Base can gate on Identity Registry.balanceOf(agentAddress) > 0 to require a verified Sly agent.
Reputation neutrality — counterparty feedback accrues on the public Reputation Registry. No single platform (including Sly) controls it.
Identifier stability — the erc8004_id is the durable cross-system identifier. UUIDs change between databases; an ERC-721 token ID does not.

Today the Sly platform wallet custodies the NFT (managed identity, like Facet 3’s env_key default — convenient, not self-sovereign). Transferring NFT ownership to the agent operator’s wallet is a future story aligned with Facet 3’s smart-account custody roadmap. → Endpoint surface + reputation details: A2A agent card

The receipt envelope

Every Sly governed payment — Base or Stellar — produces a receipt that carries the four per-call facets (1–4) as first-class fields. Facet 5 lives on the A2A agent card, not in the per-call receipt.

{
  "receipt_id":         "rcpt_…",
  "chain":              "<eip155:84532 | stellar:testnet | …>",
  "asset":              "USDC",
  "amount":             "0.0100000",
  "from_address":       "<0x… | G…>",
  "to_address":         "<0x… | G…>",
  "agent_id":           "…",
  "agent_name":         "…",
  "agent_kya_tier":             2,         // ← Facet 1: Tier
  "agent_chain_proof":          "sep10",   // ← Facet 2: Control
  "agent_custody_provider":     "env_key", // ← Facet 3: Custody
  "rail_selection":             { … },     // selectRail audit trail
  "policy_decision":            { "decision": "approve", … },
  "signature_mode":     "witness-hmac",
  "canonical_encoding": "json-sort-keys-v1",
  "signature":          "…HMAC-SHA256 over every field above"
}

Facets 4 and 5 don’t appear as receipt fields. Facet 4 is the receipt hash being published on chain after the fact — the per-call attestation. Facet 5 is the agent itself being minted as an NFT on a public registry — orthogonal to any single call. Each facet answers a different threat. Collapse them into one and you lose the distinction between failure modes:

Threat	Which facet catches it
Anonymous agent with no compliance posture	Tier (KYA gate refuses sub-T2 calls)
Agent claims an address it doesn’t control	Control (chain binding proof required)
Keys leak, custodian rotates them	Custody (`agent_custody_provider` changes, surfaces in receipts)
Sly is offline; can’t fetch a specific receipt	Discoverability (the receipt hash is anchored on chain)
Sly is offline; need to find/trust the agent itself	Registry (the agent’s NFT identity + reputation are on chain)
Sly is malicious; rewrites receipts	Facets 1–4 — the HMAC signs every per-call facet, and the receipt hash is anchored to a public schema
Counterparty wants to verify reputation independently	Registry (Reputation Registry’s `getSummary()` reads on-chain, no Sly API call)

The five-facet design means a single compromise doesn’t break the chain of custody. A tier downgrade doesn’t invalidate previously-signed receipts. A custody migration is visible in the receipt stream. An on-chain anchor outlives Sly’s database. A persistent NFT identity outlives Sly entirely.

Verifying agent identity end-to-end

Six layers of evidence, weakest to strongest:

Sly UI — /dashboard/agents/<id> (presentation, not proof)
Sly API — GET /v1/agents/:id, GET /v1/agents/:id/chain-bindings, GET /a2a/<id>/.well-known/agent.json
Offline receipt verify — node verify-offline.mjs receipt.json (re-derives the HMAC; Facets 1–4 verified in one shot)
Rail block explorer — basescan / stellar.expert (the underlying settlement)
On-chain receipt attestation — EAS or AttestProtocol explorer (the receipt hash, published, signed by Sly’s anchor key — Facet 4)
On-chain agent NFT + reputation — BaseScan ERC-8004 Identity Registry + Reputation Registry (the persistent agent identity and counterparty feedback — Facet 5, Base only today)

Layers 3 + 4 + 5 + 6 together form an airtight chain of custody for the agent’s identity AND the money movement, independent of Sly’s API uptime or honesty at audit time.

Where to go from here

KYA verification tiers

Facet 1 in depth — DSD declarations, tier-gating, kill-switch operators, Continuous Agent Integrity.

A2A agent card + ERC-8004

Facet 5 in depth — minting the NFT identity, the public agent card, reputation accrual on the on-chain Reputation Registry.

Ed25519 keypair auth

The session-token identity layer — separate from chain identity, complementary to it.

Settling on Stellar

Rail-specific implementation of Facets 2–4 on Stellar (SEP-10, custody disclosure, AttestProtocol anchoring).

Settling on Base

Rail-specific implementation of Facets 2–5 on Base (EIP-191, ERC-4337 custody, EAS anchoring, ERC-8004 NFT identity).

Get Started

Onboarding

Migration

Authentication

Core Concepts

Guides

Recipes

Architecture

Settlement & Treasury

Stellar

Protocols

Agent Platform

SDKs & Tools

Webhooks

Resources

Agentic identity

The five facets

Facet 1 — Tier (KYA)

Facet 2 — Control (chain binding)

Facet 3 — Custody (who actually signs)

Facet 4 — Discoverability (on-chain anchoring)

Facet 5 — Registry (NFT identity)

What lives where

Why this matters

The receipt envelope

Why five facets, not one

Verifying agent identity end-to-end

Where to go from here

KYA verification tiers

A2A agent card + ERC-8004

Ed25519 keypair auth

Settling on Stellar

Settling on Base

​The five facets

​Facet 1 — Tier (KYA)

​Facet 2 — Control (chain binding)

​Facet 3 — Custody (who actually signs)

​Facet 4 — Discoverability (on-chain anchoring)

​Facet 5 — Registry (NFT identity)

​What lives where

​Why this matters

​The receipt envelope

​Why five facets, not one

​Verifying agent identity end-to-end

​Where to go from here

KYA verification tiers

A2A agent card + ERC-8004

Ed25519 keypair auth

Settling on Stellar

Settling on Base

The five facets

Facet 1 — Tier (KYA)

Facet 2 — Control (chain binding)

Facet 3 — Custody (who actually signs)

Facet 4 — Discoverability (on-chain anchoring)

Facet 5 — Registry (NFT identity)

What lives where

Why this matters

The receipt envelope

Why five facets, not one

Verifying agent identity end-to-end

Where to go from here