Skip to main content
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.

​
The five facets

                ┌────────────────────────────────────────────────────────────┐
                │                   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:
FacetScopeQuestionReceipt field
Tierper-callHow thoroughly has Sly verified this agent?agent_kya_tier
Controlper-callDoes the agent provably hold the keys for the address it claims?agent_chain_proof
Custodyper-callWhere do those keys actually live right now?agent_custody_provider
Discoverabilityper-callCan a stranger verify this call from chain alone?(anchored on-chain)
Registryper-agentDoes 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.

​
Facet 1 — Tier (KYA)

Sly’s formal identity verification tiers — the direct parallel to KYC/KYB for humans. Four tiers, graduated spending limits, each tier requires more verification.
TierLabelPer-txDailyRequirements
0Registered$20$100Agent created
1Declared$100$500DSD declaration filed
2Verified$1,000$5,00030-day history OR enterprise override
3TrustedCustomCustomKill-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

​
Facet 2 — Control (chain binding)

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.
RailProtocolEndpoint
StellarSEP-10 Web AuthenticationPOST /v1/agents/:id/stellar/challenge → sign → POST /stellar/bind
BaseEIP-191 personal_signPOST /v1/agents/:id/evm/challenge → sign → POST /evm/bind
After binding, the receipt’s agent_chain_proof field flips:
ValueMeaning
assertedAddress claimed but not cryptographically proven
sep10Stellar address proven via SEP-10 challenge signature
eip191EVM 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

​
Facet 3 — Custody (who actually signs)

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:
ValueMeansStatus
env_keyPrivate key in env (sandbox default — convenient, not custodial)✅ Live
oz_sorobanOpenZeppelin Soroban smart account (Stellar)🚧 Receipt-side abstraction shipped, on-chain contract deployment in progress
safe_evmSafe smart-account custody via ERC-4337 bundler (Base)🚧 In development
crossmintCrossmint-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.

​
Facet 4 — Discoverability (on-chain anchoring)

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:
BackendNetworkStatus
eas-baseEthereum Attestation Service on Base / Base Sepolia✅ Production
attest-stellarAttestProtocol on Soroban🟡 Wired, latent — pending upstream contract init
Once anchored, anyone with the schema UID can:
  1. Scan all Sly receipt anchors for a given agent
  2. Pull the on-chain attestation
  3. Re-derive the canonical receipt hash from the source receipt
  4. 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

​
Facet 5 — Registry (NFT identity)

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.
ComponentWhat it does
Identity Registry (ERC-721)Mints the agent as an NFT. Token ID = persistent agent identity.
Reputation RegistryPer-counterparty feedback aggregated on-chain via getSummary(agentId, …).
A2A agent cardPublic JSON discovery document with identity.erc8004_id + reputation links.
Sly reputation sourceComposes the on-chain NFT + reputation + Sly’s KYA tier + age + activity into a single trust score for marketplace ranking.

​
What lives where

NetworkIdentity RegistryReputation RegistryStatus
Base mainnet0x8004A169…9a4320x8004BAa1…9DE9b63✅ Live
Base Sepolia0x13b52042…7a89c0xB5048e3e…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.

​
Why five facets, not one

Each facet answers a different threat. Collapse them into one and you lose the distinction between failure modes:
ThreatWhich facet catches it
Anonymous agent with no compliance postureTier (KYA gate refuses sub-T2 calls)
Agent claims an address it doesn’t controlControl (chain binding proof required)
Keys leak, custodian rotates themCustody (agent_custody_provider changes, surfaces in receipts)
Sly is offline; can’t fetch a specific receiptDiscoverability (the receipt hash is anchored on chain)
Sly is offline; need to find/trust the agent itselfRegistry (the agent’s NFT identity + reputation are on chain)
Sly is malicious; rewrites receiptsFacets 1–4 — the HMAC signs every per-call facet, and the receipt hash is anchored to a public schema
Counterparty wants to verify reputation independentlyRegistry (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:
  1. Sly UI — /dashboard/agents/<id> (presentation, not proof)
  2. Sly API — GET /v1/agents/:id, GET /v1/agents/:id/chain-bindings, GET /a2a/<id>/.well-known/agent.json
  3. Offline receipt verify — node verify-offline.mjs receipt.json (re-derives the HMAC; Facets 1–4 verified in one shot)
  4. Rail block explorer — basescan / stellar.expert (the underlying settlement)
  5. On-chain receipt attestation — EAS or AttestProtocol explorer (the receipt hash, published, signed by Sly’s anchor key — Facet 4)
  6. 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).