Settling on Base

Available now on sandbox. Base Sepolia (eip155:84532) settlement is live for every Sly tenant. Base mainnet (eip155:8453) ships with production access — contact us once you’ve worked through the production access checklist.

Why Base

Base is Coinbase’s L2 on the Optimism Stack. Two reasons it’s Sly’s primary EVM rail:

EVM ecosystem alignment. Most agentic-payments SDKs (Pimlico, Safe, Privy, Crossmint) target EVM first. Smart-account custody — including ERC-4337 — works without a port.
The x402.org facilitator runs on Base by default. Coinbase operates the open facilitator at https://www.x402.org/facilitator which accepts both eip155:8453 (mainnet) and eip155:84532 (Sepolia). Settlement is one-hop.

For agent-to-agent micropayments where the typical settle is sub-cent, Stellar is the better fit — fees are sponsored. For typical

0.10–

10 commerce settlements, Base wins on EVM tooling. See Settlement rails for the side-by-side.

The flow

Agent ─── 1. GET /api ──────────────► Seller x402 API
      ◄── 2. 402 + PAYMENT-REQUIRED ──
              { accepts: [{
                scheme: "exact",
                network: "base-sepolia",
                amount: "100000",
                asset: "0x036…CbB4",   ← Base Sepolia USDC
                payTo: "0xrecv…"
              }]}

Agent ─── 3. POST /v1/x402/pay ─────────────────► Sly
              { agent_id, url, intent }                │
                                                       │
                              ┌────────────────────────┘
                              ▼ L1–L5 governance
                              │
                              │  L1  KYA tier check
                              │  L2  Kill-switch + status
                              │  L3  Per-call cap
                              │  L4  Sign EIP-3009 transferWithAuthorization
                              │      with the agent's secp256k1 key
                              │  L5  Mint witness receipt
                              │
                              ▼
              ┌── 4. PAYMENT-SIGNATURE ──┐
              │   (signed PaymentPayload) │
              ▼                          │
Seller verifies + settles via x402.org facilitator
                  │
                  ▼
        EIP-3009 USDC.transferWithAuthorization on Base
                  │
                  ▼
Agent  ◄── 5. 200 OK + protected JSON
            + witness receipt persisted to Sly's ledger

Steps 1, 2, and the on-chain settle are vanilla x402 — same spec as Stellar. The Sly-side governance (L1–L5) and the witness receipt are the differentiation.

Quickstart

Use the same Sly API key

Your existing tenant API key works on both rails. The endpoint is /v1/x402/pay (Base is the default rail), or /v1/x402/stellar/pay for Stellar — both produce the same receipt envelope.

Call /v1/x402/pay

curl -X POST https://sandbox.getsly.ai/v1/x402/pay \
  -H "Authorization: Bearer pk_test_…" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "<your T2+ agent UUID>",
    "url": "https://seller.example.com/my-service",
    "max_amount": 0.05,
    "intent": { "reason": "demo call", "model": "claude" }
  }'

The intent’s network is implicit — if your tenant’s allowed_rails includes Base, Sly defaults to Base. To force Base when both rails are allowed, pass intent.preferred_rail: 'base-sepolia'.

Receive a signed witness receipt

{
  "ok": true,
  "receipt": {
    "receipt_id": "rcpt_…",
    "chain": "eip155:84532",
    "from_address": "0xagent…",
    "to_address":   "0xrecv…",
    "amount": "0.0500000", "asset": "USDC",
    "agent_id":       "…",
    "agent_name":     "my-buyer-agent",
    "agent_kya_tier": 2,
    "agent_chain_proof": "eip191",
    "agent_custody_provider": "safe_evm",
    "rail_selection": {
      "chosen": "base-sepolia",
      "reasons": ["picked:evm_tooling", "picked:tenant_default"]
    },
    "policy_decision": { "decision": "approve", … },
    "signature_mode": "witness-hmac",
    "signature": "…"
  },
  "receipt_hash": "0x…",
  "http_status": 200,
  "response_body": { … the seller's protected JSON … }
}

(Optional) Verify the receipt offline

Receipts are HMAC-signed by Sly over a stable canonical encoding (json-sort-keys-v1). Anyone with your tenant’s witness key can re-derive the signature without any network call. The verifier is rail-agnostic — same script that verifies Stellar receipts verifies Base receipts.

node verify-offline.mjs receipt.json
# → ✓ SIGNATURE VALID — receipt is verifiable offline.

Agentic identity on Base — three layers

The same three-layer identity stack Sly built for Stellar applies to Base. The mechanics differ; the receipt fields are identical.

Sly’s full identity model is a four-facet framework that applies across rails. This page covers the three chain-side layers as they’re implemented on Base. For the unified view — including KYA tier (the Sly-side facet) and how all four facets bind together in the receipt envelope — see Agentic identity.

Layer 1 — Control (EIP-191)

The agent proves it controls the 0x… address by signing a Sly-issued challenge with the EVM keypair. The receipt’s agent_chain_proof field flips from asserted to eip191 once the binding is on file.

# 1. Sly issues an EIP-191 challenge
curl -X POST https://api.getsly.ai/v1/agents/:id/evm/challenge \
  -H "Authorization: Bearer pk_test_…" \
  -d '{"chain": "eip155:84532"}'
# → { "challenge": "Sly:agent:…:auth:<nonce>:<ts>", "expires_at": "…" }

# 2. Agent signs the challenge with its EVM keypair (off-screen)

# 3. Agent submits the signature to bind
curl -X POST https://api.getsly.ai/v1/agents/:id/evm/bind \
  -H "Authorization: Bearer pk_test_…" \
  -d '{"chain": "eip155:84532", "address": "0x…", "signature": "0x…"}'
# → { "verified": true, "method": "eip191", "binding_id": "…" }

Bindings render in the agent detail page’s Chain Bindings panel with a green ✓ EIP-191 PROVEN badge.

Layer 2 — Custody

The agent_custody_provider field disclosure mirrors Stellar. Three valid values for Base today:

Value	What it means	Status
`env_key`	Private key in env (sandbox default)	✅ Live
`safe_evm`	Safe smart-account custody (ERC-4337 bundler)	🚧 Work in progress
`pimlico_v3`	Pimlico-managed AA wallets	📋 Roadmap

The receipt stamps whichever provider actually signed. Honest about what’s under the hood today, structurally ready for the upgrade.

Layer 3 — Discoverability (EAS)

Receipt hashes can be anchored to Ethereum Attestation Service on Base / Base Sepolia for chain-discoverable identity. Unlike Stellar’s AttestProtocol path (still pending upstream contract init), EAS is in production today.

curl -X POST https://api.getsly.ai/v1/x402/receipts/:id/anchor \
  -H "Authorization: Bearer pk_test_…" \
  -d '{"backend": "eas-base"}'
# → {
#   "backend": "eas-base",
#   "network": "eip155:84532",
#   "schema_uid": "0x…",
#   "attestation_uid": "0x…",
#   "tx_hash": "0x…",
#   "explorer": "https://sepolia.basescan.org/tx/0x…"
# }

Anyone with the schema UID can scan all Sly receipt anchors on Base — independent of Sly’s API uptime.

API surface

Endpoint	Purpose
`POST /v1/x402/pay`	Governed payment — L1–L5 + Base settle + receipt mint
`GET /v1/x402/info`	Network, facilitator URL, demo agent address (sandbox sanity)
`GET /v1/x402/receipts/:receipt_id`	Fetch the full signed envelope by `rcpt_*` id
`GET /v1/x402/denies?limit=25`	Recent governance denials from the audit log
`POST /v1/x402/receipts/:id/anchor`	Anchor a witness receipt hash to EAS on Base / Base Sepolia
`POST /v1/agents/:id/evm/challenge`	Issue an EIP-191 chain-binding challenge
`POST /v1/agents/:id/evm/bind`	Bind an EVM address with a signed challenge
`GET /v1/agents/:id/chain-bindings`	List active chain bindings for the agent (cross-rail)

All endpoints are tenant-scoped via your existing API key.

Dashboard

Base settlements render in /dashboard/transfers with:

A 🔵 base sepolia (or 🔵 base for mainnet) rail badge
The Rail column on the transfers list
The “All Rails” filter (All / Base / Base Sepolia / Stellar / Internal)

Click into a Base transfer for:

Sly-Governed x402 Settlement block at the top
Agentic Identity callout — agent name (linked to detail page) with KYA tier badge at sign time
Counterparties — 0x… address chips with click-through to basescan / sepolia.basescan
Witness Receipt panel — full envelope with Download JSON and Copy verify command buttons

The agent detail page shows:

Allowed Rails chips at the top of the header card (e.g. 🌟 stellar testnet · 🔵 base sepolia)
Chain Bindings panel (under the KYA tab) — every chain this agent has proven key-control on, with the proof method badge (✓ EIP-191 PROVEN for Base, ✓ SEP-10 PROVEN for Stellar)

Five layers of evidence

Verifying a Base settlement, weakest to strongest:

Sly UI — /dashboard/transfers/<id> (UX surface, not proof)
Sly DB — your tenant’s transfers row + protocol_metadata.witness_receipt
Offline receipt verify — node verify-offline.mjs receipt.json (HMAC re-derives — identity + amount + decision are tamper-proof)
Basescan — curl https://sepolia.basescan.org/tx/<hash> (USDC actually moved between addresses)
EAS attestation — curl https://base-sepolia.easscan.org/attestation/view/<uid> (the receipt hash, anchored, signed by Sly’s anchor key)

Layers 3 + 4 + 5 together form an airtight chain of custody.

Roadmap

Shipped

Base Sepolia settlement · L1–L5 governance · witness receipts with agentic identity · EAS anchoring · dashboard surface · offline verification · EIP-191 chain binding.

Work in progress

Base mainnet · ERC-4337 / Safe smart-account custody · Pimlico bundler integration · multi-rail selectRail() defaults. Contact us to be added to the production-access roadmap.

Compare rails

Side-by-side: Base vs Stellar, selectRail() decision function, allow-list configuration.

Settle on Stellar

Stellar guide — sub-cent settle, fee-sponsored, three-layer agentic identity.

​Why Base

​The flow

​Quickstart

​Agentic identity on Base — three layers

​Layer 1 — Control (EIP-191)

​Layer 2 — Custody

​Layer 3 — Discoverability (EAS)

​API surface

​Dashboard

​Five layers of evidence

​Roadmap

Shipped

Work in progress

Compare rails

Settle on Stellar

Why Base

The flow

Quickstart

Agentic identity on Base — three layers

Layer 1 — Control (EIP-191)

Layer 2 — Custody

Layer 3 — Discoverability (EAS)

API surface

Dashboard

Five layers of evidence

Roadmap