Stellar integration architecture

​

System overview — the governed loop on Stellar

Every Stellar payment through Sly runs the same five-layer loop: identity is resolved, policy is decided, settlement happens on chain via the Stellar Asset Contract, and a signed receipt makes the whole decision auditable offline. 🟢 The loop itself is live: POST /v1/x402/stellar/pay runs KYA gate → kill-switch → per-call cap → signs the Soroban auth entry with the agent’s Ed25519 key → mints the witness receipt. Denied calls never touch the network and return a signed deny artifact in the same envelope shape. The receipt binds agent identity (agent_id, agent_kya_tier), key-control proof (agent_chain_proof: "sep10"), custody disclosure (agent_custody_provider), rail choice (rail_selection.reasons), and the policy decision under one HMAC — verifiable offline with verify-offline.mjs. 🟡 The AttestProtocol anchor route is wired end-to-end (signed XDR returned) and reports status: "pending_init" — pending upstream contract init, tracked with the AttestProtocol team. 🟢 In the interim, receipt-hash anchoring to EAS on Base Sepolia is the live baseline (network is environment-selected: sandbox anchors to Base Sepolia, production to Base mainnet — this page and the evidence repo describe the sandbox/testnet path). 🔵 KYA attestation writes to a Soroban attestation contract are a Tranche 1 deliverable.

​

Building block 1 — Stellar Wallets Kit → verified agent onboarding

🟢 The middle of this flow is live today: agents bind their Stellar address via SEP-10 Web Authentication (POST /v1/agents/:id/stellar/challenge → sign off-screen → POST /v1/agents/:id/stellar/bind, verified with WebAuth.verifyChallengeTxSigners() from @stellar/stellar-sdk). A successful bind flips every subsequent receipt to agent_chain_proof: "sep10"; unbound agents are honestly stamped asserted. KYA tiering gates every settlement. 🔵 Tranche 1 puts Stellar Wallets Kit in front of that live path: an operator connects any supported wallet from the browser, signs the same SEP-10 challenge, and lands in the same chain-bindings table — no API scripting required. Verified agents then become discoverable (directory listing) and their tier is attested on chain (Soroban attestation contract; the live EAS-on-Base path is the interim anchoring backend).

​

Building block 2 — Stellar Disbursement Platform → governed multi-agent disbursement

🔵 The entire SDP path is a Tranche 2 deliverable — none of it is in the codebase today. What de-risks it: every node composes primitives that are already live in the single-payment path. Per-recipient KYA is the same L1 gate, the batch PolicyDecision is the same policy engine, and the per-payout witness receipt is the same envelope + HMAC — the new work is the batch orchestration and the SDP submission itself. External dependency, stated plainly: the SEP-24/31 anchor off-ramp requires an agreement with a list-approved anchor. This is a partnership blocker, not an engineering one, and Tranche 2 acceptance is scoped accordingly.

​

Building block 3 — Allbridge → cross-chain settlement under one receipt

🟢 selectRail() is live: a pure decision function that intersects tenant and agent rail allow-lists, scores candidates, and returns the chosen rail plus human-readable reasons — which land in the receipt’s rail_selection field (picked:fee_sponsored, picked:cheaper_fee, picked:faster_finality). 🔵 Tranche 3 extends it into a cross-chain router. Allbridge Core (Soroban-native liquidity pools) becomes a selectRail() route for cross-stablecoin transfers and chains CCTP doesn’t reach; the CCTP leg covers native USDC Base ↔ Stellar (Sly’s CCTP bridge service is live on other rails today; the Stellar leg is part of this tranche). Either route emits a single spanning receipt carrying both chain hashes and the reason codes for the route taken. 🟡 Custody enforcement at the rail rides on OZ Soroban smart accounts — the receipt-side abstraction is shipped (receipts honestly stamp env_key custody today); the on-chain custody contract is still being deployed. Soroban Trust Spine is the name of the Tranche 3 anchoring deliverable: witness-receipt and attestation writes to Soroban attestation contracts (existing contract or self-host fallback), verified via Soroban’s ed25519/secp256k1 host functions, with all Soroban contract components open-sourced (MIT).

​

Component inventory

​

Verify these claims

• Evidence repo: github.com/Sly-devs/stellar-evidence — 13 verified testnet settlements, 3 signed receipts, standalone verifier, sandbox HMAC key published inline.
• Headline transaction: stellar.expert/explorer/testnet/tx/378e8aa9… — Soroban invoke_host_function, USDC SAC transfer, both G-addresses match the signed receipt.
• Offline verification: node verify-offline.mjs headline-receipt.json → ✓ SIGNATURE VALID — 57 lines, Node built-ins only, no Sly infrastructure in the loop.

One click from this architecture page to on-chain proof. That’s the trust model: verify the chain, not the presentation.