Settlement rails

Both rails are live in sandbox today. Base Sepolia (eip155:84532) and Stellar testnet (stellar:testnet) settle real USDC through the same Sly governance loop. Mainnet for both rails (Base + Stellar pubnet) ships with production access — contact us once you’ve worked through the production access checklist.

What “rail-neutral” actually means

The four Sly primitives — Identity, Governance, Policy, Receipts — work the same on every rail. A receipt minted on Base and a receipt minted on Stellar carry the same identity fields, the same canonical encoding, the same HMAC algorithm, and the same offline verifier. The rail is a setting, not an integration.

   Identity        Governance       Policy         Receipts
       │               │               │              │
       ▼               ▼               ▼              ▼
┌─────────────────────────────────────────────────────────┐
│         Sly rail-neutral protocol surface               │
└─────────────────────────────────────────────────────────┘
       │                                       │
       ▼                                       ▼
  ┌────────┐                              ┌─────────┐
  │  Base  │                              │ Stellar │
  │   L2   │                              │ Soroban │
  └────────┘                              └─────────┘
   EIP-191                                   SEP-10
   USDC                                      USDC
   basescan                                  stellar.expert

The same /v1/agents/:id/... endpoints, the same dashboard surfaces, the same receipt shape. Only chain and the address format differ.

The two production rails

Base (EVM L2)

Coinbase’s L2 on Optimism Stack. Mid-large settlements. EVM ecosystem. ~2s finality. EIP-191 key-control proofs.

Stellar (Soroban)

Stellar Development Foundation’s smart-contract chain. Agent micro-payments. Fee-sponsored settlement. ~5s finality. SEP-10 key-control proofs.

Side by side

Property	Base	Stellar
Sandbox network	`eip155:84532` (Base Sepolia)	`stellar:testnet`
Mainnet network	`eip155:8453` (Base)	`stellar:pubnet`
x402 SDK	`@x402/evm`	`@x402/stellar`
Settlement latency	~2 s	~5 s
Per-tx fee	~$0.001 gas (paid in ETH)	~$0.00001 — fees sponsored by facilitator
USDC contract	`0x036…CbB4` Sepolia · `0x833…9913` mainnet	SAC `CBIELTK…DAMA` testnet · SAC `CCW67TSZ…SJMI75` mainnet
Address format	`0x` + 20 bytes (EIP-55 checksum)	`G…` 56-char base32 (Ed25519 pubkey)
Key-control proof	EIP-191 signed challenge	SEP-10 web auth challenge
Block explorer	basescan.org / sepolia.basescan.org	stellar.expert
Receipt anchoring	EAS (Ethereum Attestation Service)	AttestProtocol on Soroban — wired, pending upstream contract init
Fiat off-ramp	Coinbase, US-centric	475K+ MoneyGram locations · Yellowcard · Flutterwave
Best for	Settlement size $0.10+, EVM ecosystem	Sub-cent agent calls, EMEA/Africa fiat edge

Picking a rail by hand? The short rule: Base for mid/large settles in EVM-heavy stacks; Stellar for sub-cent agent micropayments and emerging-markets edges. Better: let selectRail() pick for you.

`selectRail()` — the decision function

Rail-neutrality at the platform level becomes a single pure function at the code level. selectRail() takes an intent, the tenant’s allow-list, the agent’s allow-list, and current network conditions, intersects them, scores the survivors, and returns the chosen rail plus the human-readable reasons it won.

import { selectRail } from '@sly_ai/sdk';

const decision = selectRail({
  intent: { kind: 'x402.pay', target_currency: 'USDC', max_amount: 0.01 },
  tenant: { allowed_rails: ['stellar:testnet', 'base-sepolia', 'base'] },
  agent:  { allowed_rails: ['stellar:testnet', 'base-sepolia'] },
});

// decision = {
//   chosen: 'stellar:testnet',
//   reasons: ['picked:fee_sponsored', 'picked:cheaper_fee', 'picked:faster_finality'],
//   rejected: []
// }

The reasons land in the receipt’s rail_selection field. The receipt explains itself.

{
  "receipt_id": "rcpt_…",
  "chain": "stellar:testnet",
  "rail_selection": {
    "chosen": "stellar:testnet",
    "reasons": ["picked:fee_sponsored", "picked:cheaper_fee", "picked:faster_finality"],
    "rejected": []
  },
  …
}

The decision tree

intent
  │
  ▼
intersect tenant.allowed_rails ∩ agent.allowed_rails
  │
  ▼
filter candidates by intent.target_currency
  │       ┌─ USDC available on both? continue
  │       └─ only one supports it? short-circuit, reason: only_currency_support
  ▼
score each remaining candidate:
  • +1 if facilitator sponsors fees on this network
  • +1 if known-cheaper per-tx fee for this intent size
  • +1 if known-faster finality
  • -1 if mainnet but tenant lacks production access
  │
  ▼
pick highest score (deterministic tiebreak by network alphabetical)
  │
  ▼
return { chosen, reasons, rejected }

Full source: apps/api/src/services/x402/select-rail.ts. Pure function, fully unit-tested, 0 side effects — replayable forever.

Allow-lists — two levers

Every agent’s effective rail allow-list is tenant.allowed_rails ∩ agent.allowed_rails. Two operators can independently dial down (never up) the rails their agents can settle on.

# Tenant-wide allow-list (Sly Operator role required)
PATCH /v1/tenant/allowed-rails
{ "allowed_rails": ["stellar:testnet", "base-sepolia", "base"] }

# Per-agent allow-list (Operator + Owner roles)
PATCH /v1/agents/:id
{ "allowed_rails": ["stellar:testnet"] }

Empty array ([]) means “no restriction” — defaults to platform-wide allow. Both fields render as Allowed Rails chip panels in the dashboard for the relevant scope.

Receipt shape, across rails

Every Sly governed payment — Base or Stellar — produces the same receipt envelope. Only chain, address format, and a couple of optional rail-specific fields vary.

{
  "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":         "stellar-demo-buyer",
  "agent_kya_tier":     2,
  "agent_chain_proof":  "<sep10 | eip191 | asserted>",
  "agent_custody_provider": "<env_key | oz_soroban | safe_evm>",
  "rail_selection":     { "chosen": "…", "reasons": [...], "rejected": [...] },
  "policy_decision":    { "decision": "approve", … },
  "signature_mode":     "witness-hmac",
  "canonical_encoding": "json-sort-keys-v1",
  "signature":          "…HMAC-SHA256(json-sort-keys-v1)"
}

Every field above is in the canonical encoding. Every field is in the HMAC. Tampering with the rail, the address, the agent, the custody provider, or the decision invalidates the signature on either rail.

Offline verification works the same

The verify-offline.mjs script in examples/stellar-demo/ is rail-agnostic — it re-derives the canonical encoding and HMAC, then byte-compares. Works for both Base and Stellar receipts because the canonical encoding is json-sort-keys-v1 regardless of chain.

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

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

This is the layer that lets you audit a Sly settlement without trusting Sly’s API at the moment of audit. Cryptography over wire.

What’s NOT yet at parity

Three places where Base is ahead of Stellar today, by design:

Capability	Base	Stellar	Status
Mainnet settlement	Ships with production access	Ships with production access	Contact us
Smart-account custody	ERC-4337 (Safe / Pimlico paths) — partial	OZ Soroban smart accounts — receipt-side abstraction shipped, on-chain custody contract still being deployed	Work in progress
On-chain receipt anchor	EAS — production	AttestProtocol — wired but pending upstream contract init	Work in progress

All three are coded against an abstraction; flipping one over is a config change, not a rebuild.

Where to go from here

Settling on Base

Full guide — endpoints, EIP-191 binding, witness receipts, dashboard surface, EAS anchoring.

Settling on Stellar

Full guide — endpoints, SEP-10 binding, custody providers, AttestProtocol anchoring, the three identity layers.

x402 protocol

The HTTP 402 micropayment protocol that both rails serve under the same Sly governance loop.

Production access

How to graduate from sandbox (both rails) to live mainnet settlement.

Get Started

Onboarding

Migration

Authentication

Core Concepts

Guides

Recipes

Architecture

Settlement & Treasury

Stellar

Protocols

Agent Platform

SDKs & Tools

Webhooks

Resources

Settlement rails

What “rail-neutral” actually means

The two production rails

Base (EVM L2)

Stellar (Soroban)

Side by side

`selectRail()` — the decision function

The decision tree

Allow-lists — two levers

Receipt shape, across rails

Offline verification works the same

What’s NOT yet at parity

Where to go from here

Settling on Base

Settling on Stellar

x402 protocol

Production access

​What “rail-neutral” actually means

​The two production rails

Base (EVM L2)

Stellar (Soroban)

​Side by side

​selectRail() — the decision function

​The decision tree

​Allow-lists — two levers

​Receipt shape, across rails

​Offline verification works the same

​What’s NOT yet at parity

​Where to go from here

Settling on Base

Settling on Stellar

x402 protocol

Production access

What “rail-neutral” actually means

The two production rails

Side by side

`selectRail()` — the decision function

The decision tree

Allow-lists — two levers

Receipt shape, across rails

Offline verification works the same

What’s NOT yet at parity

Where to go from here