Status and scope
TilcAI is an infrastructure for the agent of a person or organization to inquire, quote, book and buy from a business agent with limited authority, verifiable terms and payments on Stellar. It is being built in stages. The complete purchase flow is not enabled. Names may change.
- Available foundation An x402 payment rail with an OpenZeppelin Relayer on Stellar Testnet, a deterministic policy evaluator and versioned shared contracts.
- Being integrated MCP connector, quotes and orders, approval per purchase, payment reconciliation and delivery confirmation.
- Next steps Smart accounts with limited permissions, shared budget across agents and scheduled tasks.
The first flow targets one business, one service, one assistant, one user and one asset on stellar:testnet. This documentation distinguishes the available foundation, components being integrated and next steps.
A component being available is not the same as a purchase flow being enabled. Nothing here has been audited, and nothing runs with real funds.
Architecture
A request moves through the path below. The language model helps with the task; the infrastructure decides which actions can run and under which conditions.
Three planes stay separate, so a request can move forward in the first one without holding permissions in the third:
- Communication. Assistants, MCP tools and agent messages.
- Commerce and control. Business identity, quotes, orders, mandates and policy.
- Financial. Account, authorization, signing, payment and reconciliation.
| Module | Responsibility | Essential control |
|---|---|---|
| MCP server | Expose tools to assistants | Scopes and the principal's context |
| Gateway | Coordinate the purchase cycle | Idempotency and a state machine |
| Commercial adapter | Connect a business's capabilities | The business is the source of truth |
| Identity and offer verifier | Check who offers and that the terms are intact | Keys from an independent source of trust |
| Policy and budget | Evaluate provider, service, amount and limits | Deny by default |
| Authorization and signer | Bind the exact action to consent or a mandate | Secrets kept away from the model |
| Stellar adapter, facilitator and Relayer | Build, verify and submit the x402 payment | Exact asset, network and invocation |
| Reconciler and receipts | Establish the real result and keep evidence | Never repeat an uncertain payment |
Modules are logical responsibilities, not one service per box. Orders, mandates and states are kept in durable storage: a chat history is not a purchase record.
Business integration
The business keeps authority over its services, prices, availability and conditions. A commercial adapter connects the capabilities it can really back to the shared flow, and its agent consults the business's own systems. It does not invent stock, discounts or confirmations.
- Explicit capabilities. Each business exposes only the operations it supports, for example checking availability, holding a resource or confirming an order. Permissions distinguish them.
- Context from authentication. Business, user and role come from the authenticated session, never from a free argument proposed by the model.
- Identity with a limited scope. A business registers its operator, origin, keys and payment destination. Controlling a key or a domain does not prove legal identity or commercial quality.
- Signed quotes. A quote binds business, service, quantity, total price, network, asset, recipient, expiry and a hash of the terms.
A buyer accepts a quote only when:
- the signing key is recognized by an independent source (onboarding, an accepted registry or the principal's trusted configuration), never taken from the quote itself;
- service, network, asset, amount and recipient match the payment requirements exactly, and the quote has not expired;
- policy, budget and approval still allow the operation.
A signature protects the terms after signing. It does not protect against a compromised key, a phishing origin or a misconfigured policy, and it never grants spending authority.
Delivery comes from the business. The order is confirmed and fulfilled by the business's own system, and that evidence is kept apart from the payment receipt. Publishing a business profile requires its approval; adding a profile or exploring a use case does not enable sales. A business is presented as enabled only after its operational flow has been verified.
MCP and assistants
MCP (Model Context Protocol) is the tool interface for compatible assistants. TilcAI is designed to publish an MCP server with specific operations, authenticated following the MCP authorization specification. No MCP server is exposed yet. The names below are interface design, not a published package.
| Tool | Function | Permission |
|---|---|---|
list_businesses | Discover onboarded providers | Read |
get_service | Read services and conditions | Read |
get_availability | Check availability | Read |
request_quote | Get an identifiable quote | Preparation |
prepare_purchase | Verify and prepare an order | Authenticated user and policy |
request_purchase | Request execution of a prepared order | Exact confirmation or mandate |
get_order_status | Read the result of your own order | Ownership of the order |
request_cancellation | Ask to cancel under the terms | Matching commercial permission |
get_budget_status | Read limits and holds | Access to your own budget |
The model works with quote and order IDs. There is no unrestricted tool to send money to an arbitrary address. Price, recipient, quantity, network and asset travel as versioned data; the conversation explains that data but does not redefine it.
- Connecting is not spending. Connection, data access and purchase authority are separate. Selecting an assistant or allowing a tool never grants permission to spend.
- A skill is guidance, not permission. It explains how to inquire, clarify, prepare and report states. The server enforces the rules even if an agent ignores the skill.
- Support is per capability. The client catalog distinguishes reading, quoting, preparing and executing. Supporting MCP does not imply autonomous payments. Every client is tested with its own version and authentication.
- Status today. Every client in the catalog is in preparation. A guide is published for a client only after it has been tested, and no guide asks for a seed phrase, private key or token.
Permissions and payments
A payment becomes eligible only when all of these hold at once:
- a recognized identity and an authentic, current offer;
- an intent bound to an order and an applicable mandate;
- available and held budget;
- exact approval or a verifiable delegation.
A valid signature is not enough to authorize a payment. Reputation can inform a decision but never bypasses a limit.
Decisions and states are different things
| State | It means | It does not mean |
|---|---|---|
Allowed (ALLOW) | The policy passed for this intent | Permission to sign, a payment or a delivery |
| Approved | The user authorized the exact terms, or a valid mandate applies | That any funds moved |
| Sent | A payment attempt was submitted to the rail | That it settled; the result can still be uncertain |
| Settled | The rail confirmed the payment | That the service was delivered |
| Delivered | The business provided evidence of fulfillment | Evidence of the payment itself |
The policy engine returns ALLOW, DENY or REQUIRE_APPROVAL. The current prototype returns ALLOW or DENY; human approval is part of the authorization flow. An order keeps separate commerce, payment and budget states, so a paid order can still be waiting for delivery.
Two ways to authorize
- Approval per purchase (first route). The user connects a compatible account and reviews service, amount, asset, network, recipient and terms. The wallet signs an authorization compatible with the rail, which on Stellar x402 means a Soroban authorization entry. A login signature or a wallet connection is not enough. If the offer or the invocation changes, a new approval is required.
- Limited delegation (target route). A Soroban smart account owned by the user accepts a restricted signer within a mandate: exact network and asset, allowed contracts, recipients, per-operation and per-period amounts, providers, expiry and revocation. It is enabled only after the account, signer and rail are tested together. A working smart account does not by itself prove that a payment payload is compatible with it.
The payment rail today
The rail is an x402 facilitator running as a plugin inside an OpenZeppelin Relayer, on Stellar Testnet. It exposes verify, settle and supported. It checks the network, the allowed asset, the recipient, the amount and the payer's signed authorization, simulates the transaction, and the Relayer submits it and pays the network fee.
- Tested. A Testnet payment was confirmed on-chain and independently checked. Altered payloads were rejected before any funds moved. Repeating a settled payload did not pay twice. The settlement response carries payment evidence only, never delivery data.
- Not yet. Connection to quotes, approvals, budget and orders; a smart account as payer; mainnet; and USDC, since the Testnet test used the network's native asset.
The technical detail, payloads and error contract are in the payment rail documentation of the open tilcai-core repository.
When something goes wrong
- Uncertain payment. A timeout after sending is not a failure. The budget hold is kept and the same attempt is reconciled before anything is signed again. Retrying a query can be safe; retrying a financial execution requires knowing the state of the previous attempt.
- Payment without delivery. The order is not marked delivered. The issue is resolved under the commercial terms, and repeating the purchase is not an automatic fix.
- Revocation. Revoking a mandate blocks new signatures. It does not reverse a payment that already settled.
- Changed terms. A different price, provider or service stops the operation for a new approval. The agent cannot raise its own limit or approve its own exception.
Planned extensions
These are planned, not active. They are added behind the same operations and states.
- Planned extension A2A. A standard for agent-to-agent communication, with capabilities described by Agent Cards. It would connect a buyer's request to a business agent's capabilities. It does not replace inventory, a mandate or a financial signature. The first flow can run on MCP and a commercial API.
- Planned extension ERC-8004. A draft standard for identity, reputation and validation registries on Ethereum/EVM. It is not a native Stellar contract and does not guarantee trust. TilcAI plans a native operational identity on Stellar and, separately, an adapter to resolve an EVM registry. Reading an EVM identity never moves funds between networks or builds a bridge.
- Next steps Smart accounts, shared budget and scheduled tasks. See the build status on the overview.
Security model and known limits
- The model proposes; rules decide. Model output is never trusted for price, recipient or approval. An unverifiable condition blocks the operation or asks for human review.
- The signer is a separate boundary. Keys stay away from the model and from business data. This website stores no private keys, financial tokens or spending mandates.
- Facilitator dependency. Settlement relies on an x402 facilitator and a Relayer on Testnet. If they are unavailable, payments stop.
- Testnet only. The first flow runs on Stellar Testnet. Testnet and mainnet have separate configuration and are enabled separately.
- Not audited. Nothing described here has been audited.
Out of scope for now: an agent marketplace, trading or DeFi, cross-chain bridges, free-form price negotiation, purchases from any business without an adapter, regulated services and unlimited agent autonomy.
Glossary
- Principal
- The person or organization that owns the funds and grants authority.
- Mandate
- Authority delegated to an agent, with scope, limits, period and revocation.
- Quote
- Exact commercial terms from a business: service, price, asset, network, recipient and expiry.
- Order
- The commercial operation linking principal, business and quote, with its own states.
- MCP
- Model Context Protocol: the tool interface for compatible assistants.
- x402
- An HTTP payment protocol: a server answers
402 Payment Requiredwith payment terms and the client pays to obtain the resource. - Facilitator
- The component that verifies and submits an x402 payment. Here, a plugin running in an OpenZeppelin Relayer.
- Soroban
- Stellar's smart contract platform.
- Reconciliation
- Establishing the real result of a payment attempt, including when a call failed midway.
- Reason code
- A machine-readable explanation of a decision.