> ## 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. # Stellar integration architecture > How Sly's governed settlement loop runs on Stellar today, and the integration plan for Stellar Wallets Kit, the Stellar Disbursement Platform, and Allbridge โ€” with the build status of every component labeled. **Every component on this page carries one of three status labels.** They match the status language used across these docs and are independently checkable against Sly's public evidence repo, [Sly-devs/stellar-evidence](https://github.com/Sly-devs/stellar-evidence) โ€” on-chain transactions, signed receipts, and an offline verifier, no Sly login required. | Label | Meaning | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | ๐ŸŸข **Live** | Running on Stellar testnet today (`stellar:testnet`). Mainnet (`stellar:pubnet`) ships with production access. Verifiable via the evidence repo. | | ๐ŸŸก **Pending external** | Code path complete and honestly surfaced in API responses; blocked on a dependency outside Sly's codebase. | | ๐Ÿ”ต **Planned โ€” funded** | Not in the codebase. Deliverable of the funded tranche noted. Never presented as built. | ## 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. ```mermaid theme={null} flowchart LR A["Agent
(agent_id + intent)"] --> KYA["KYA resolution
tier at sign time"] KYA --> PD{"PolicyDecision
L1 tier ยท L2 kill-switch ยท L3 cap"} PD -- deny --> DENY["Signed deny artifact
same envelope, same HMAC"] PD -- approve --> SETTLE["x402 settlement
USDC SAC + Soroban auth entries
via the public x402.org facilitator
(fees sponsored on Stellar)"] SETTLE --> WR["Witness receipt
HMAC-SHA256 over json-sort-keys-v1"] WR --> EAS["Receipt anchor โ€” EAS on Base
(interim baseline)"] WR --> AP["Receipt anchor โ€” AttestProtocol
on Soroban"] WR --> KAT["KYA attestation write
Soroban attestation contract"] classDef live fill:#e6f6ec,stroke:#1a7f37,color:#14532d classDef pending fill:#fff8e1,stroke:#9a6700,color:#713f12 classDef planned fill:#eef2ff,stroke:#4f46e5,color:#312e81 class KYA,PD,DENY,SETTLE,WR,EAS live class AP pending class KAT planned ``` ๐ŸŸข 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 ```mermaid theme={null} flowchart LR W["Multi-wallet connect
Freighter ยท xBull ยท Albedo ยท Lobstr"] --> C["SEP-10 bind
challenge โ†’ sign โ†’ bind"] C --> T["KYA tier assignment"] T --> D["Directory listing"] D --> AT["KYA attestation write
Soroban attestation contract"] classDef live fill:#e6f6ec,stroke:#1a7f37,color:#14532d classDef planned fill:#eef2ff,stroke:#4f46e5,color:#312e81 class C,T live class W,D,AT planned ``` ๐ŸŸข 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 ```mermaid theme={null} flowchart LR O["Orchestrator agent"] --> RK["Per-recipient KYA"] RK --> BP["Batch PolicyDecision"] BP --> SDP["SDP submission"] SDP --> WRP["Witness receipt
per payout"] WRP --> AN["SEP-24/31
anchor off-ramp"] classDef planned fill:#eef2ff,stroke:#4f46e5,color:#312e81 class O,RK,BP,SDP,WRP,AN planned ``` ๐Ÿ”ต 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 ```mermaid theme={null} flowchart LR I["Intent
currency ยท amount ยท chains"] --> SR["selectRail()"] SR -- "native USDC
Base โ†” Stellar" --> CCTP["CCTP route
burn / mint"] SR -- "cross-stablecoin ยท
non-CCTP chains" --> AB["Allbridge Core route
Soroban liquidity pools"] CCTP --> SPAN["Spanning receipt
both chain hashes + reason codes"] AB --> SPAN SPAN --> CUST["Smart-account custody
limits enforced at the rail"] classDef live fill:#e6f6ec,stroke:#1a7f37,color:#14532d classDef pending fill:#fff8e1,stroke:#9a6700,color:#713f12 classDef planned fill:#eef2ff,stroke:#4f46e5,color:#312e81 class SR live class CUST pending class CCTP,AB,SPAN planned ``` ๐ŸŸข `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 | Component | Status | Runs against | Where to verify | | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | x402 governed settlement (`POST /v1/x402/stellar/pay`, L1โ€“L5) | ๐ŸŸข Live | Sly API โ†’ USDC SAC via x402.org facilitator | Evidence repo ยง1 โ€” headline tx on stellar.expert | | SEP-10 chain binding (challenge / sign / bind) | ๐ŸŸข Live | Sly API + Horizon | Receipt field `agent_chain_proof: "sep10"`; evidence repo ยง5โ€“ยง6 | | KYA tiering + signed deny artifacts | ๐ŸŸข Live | Sly API | Deny artifact JSON โ€” `/settlement/stellar` | | `selectRail()` decision function | ๐ŸŸข Live | Sly API (pure function) | `rail_selection.reasons` in every receipt | | `StellarRailAdapter` (settle, balance, history, health) | ๐ŸŸข Live | Horizon + Soroban RPC | `/settlement/stellar` | | Witness receipts (HMAC over `json-sort-keys-v1`) | ๐ŸŸข Live | Sly API โ€” offline-verifiable | `verify-offline.mjs` in the evidence repo | | Dashboard surface (rail badges, receipt panel, chain bindings) | ๐ŸŸข Live | app.getsly.ai | Narrated tour in the evidence repo | | Receipt anchoring โ€” EAS on Base (interim baseline) | ๐ŸŸข Live | Base Sepolia in sandbox โ€” environment-selected, Base mainnet in production (non-Stellar interim leg) | Anchor route, backend `eas-base` | | Receipt anchoring โ€” AttestProtocol on Soroban | ๐ŸŸก Pending external โ€” wired, pending upstream contract init | Soroban RPC | Anchor route returns signed XDR + `status: "pending_init"` | | OZ Soroban smart-account custody | ๐ŸŸก Pending external โ€” receipt-side abstraction shipped; on-chain contract still being deployed | Soroban | Receipts stamp `agent_custody_provider` honestly (`env_key` today) | | Stellar Wallets Kit onboarding | ๐Ÿ”ต Planned โ€” funded (Tranche 1) | Browser + Sly API | โ€” | | Directory listing of verified agents | ๐Ÿ”ต Planned โ€” funded (Tranche 1) | Sly API | โ€” | | KYA attestation write path | ๐Ÿ”ต Planned โ€” funded (Tranche 1) | Soroban attestation contract | โ€” | | SDP governed disbursement + SEP-24/31 anchor flow | ๐Ÿ”ต Planned โ€” funded (Tranche 2) | SDP + list-approved anchor | โ€” | | Allbridge Core route + spanning receipt | ๐Ÿ”ต Planned โ€” funded (Tranche 3) | Allbridge Core (Soroban pools) | โ€” | | Soroban Trust Spine (native anchoring, MIT) | ๐Ÿ”ต Planned โ€” funded (Tranche 3) | Soroban ed25519/secp256k1 host functions | โ€” | ## Verify these claims * **Evidence repo:** [github.com/Sly-devs/stellar-evidence](https://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โ€ฆ](https://stellar.expert/explorer/testnet/tx/378e8aa99eb136c50e9ee5d7ebaca3d4f931c2b701d241fc6419f7470a4ccc12) โ€” 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.