> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getsly.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Agentic identity
> The five facets of agent identity on Sly — KYA tier, chain binding, custody disclosure, on-chain anchoring, and NFT registry — and how every Sly receipt cryptographically binds the call-level facets together.
**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](/agents/kya-tiers) covers tier verification,
[Settling on Stellar](/settlement/stellar) and [Settling on Base](/settlement/base)
cover the chain-side per-call layers per rail, and [A2A agent card](/agents/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:
| Facet | Scope | Question | Receipt field |
| ------------------------------------------------------------------ | --------- | ------------------------------------------------------------------------ | -------------------------- |
| [**Tier**](#facet-1-tier-kya) | per-call | How thoroughly has Sly verified this agent? | `agent_kya_tier` |
| [**Control**](#facet-2-control-chain-binding) | per-call | Does the agent provably hold the keys for the address it claims? | `agent_chain_proof` |
| [**Custody**](#facet-3-custody-who-actually-signs) | per-call | Where do those keys actually live right now? | `agent_custody_provider` |
| [**Discoverability**](#facet-4-discoverability-on-chain-anchoring) | per-call | Can a stranger verify *this call* from chain alone? | (anchored on-chain) |
| [**Registry**](#facet-5-registry-nft-identity) | 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.
***
## 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.
| 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](/agents/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.
| 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](/settlement/stellar#layer-1-control-sep-10-key-control-proof) · [Settling on Base](/settlement/base#layer-1-control-eip-191)
***
## 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:
| 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.
***
## 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:
| 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:
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](/settlement/stellar#layer-3-discoverability-attestprotocol-on-soroban) · [Settling on Base](/settlement/base#layer-3-discoverability-eas)
***
## 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](https://eips.ethereum.org/EIPS/eip-8004)** 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.
```bash theme={null}
# 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](/agents/a2a-agent-card) (`GET /a2a//.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](/settlement/stellar#layer-3-discoverability-attestprotocol-on-soroban) — 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](mailto:hello@getsly.ai) 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](/agents/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](/agents/a2a-agent-card), not in the per-call receipt.
```json theme={null}
{
"receipt_id": "rcpt_…",
"chain": "",
"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:
| 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:
1. **Sly UI** — `/dashboard/agents/` (presentation, not proof)
2. **Sly API** — `GET /v1/agents/:id`, `GET /v1/agents/:id/chain-bindings`, `GET /a2a//.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
Facet 1 in depth — DSD declarations, tier-gating, kill-switch operators, Continuous Agent Integrity.
Facet 5 in depth — minting the NFT identity, the public agent card, reputation accrual on the on-chain Reputation Registry.
The session-token identity layer — separate from chain identity, complementary to it.
Rail-specific implementation of Facets 2–4 on Stellar (SEP-10, custody disclosure, AttestProtocol anchoring).
Rail-specific implementation of Facets 2–5 on Base (EIP-191, ERC-4337 custody, EAS anchoring, ERC-8004 NFT identity).