We build around capabilities, not promises.
We distinguish what can already be checked, what we are integrating and what follows. Each item says where it has evidence today (simulation or testnet; nothing runs in production) and who keeps its status accurate. We publish no fixed dates.
Verifiable components
Technical foundation and exploration
An available component is not an enabled purchase flow. A verified technical payment is not a commercial purchase.
USDC from Avalanche Fuji to Stellar with CCTP
An end-to-end payment on testnet: burn on Fuji, Circle attestation and mint on Stellar, with an API, reconciliation and a mode where the buyer pays no gas. Independently reproduced. It is a technical rail: it is not yet tied to quotes, orders or delivery.
Deterministic policy evaluator
A prototype in tilcai-core checks limits, recipient, network and asset, and returns ALLOW or DENY. ALLOW means the policy passed; it does not authorize a transfer or confirm a payment.
Shared contracts
Versioned types for IDs, states, errors, intent, mandate and MCP tools. They keep decision, payment and delivery as separate states. Team review is still pending.
Website, office and visual simulation
A bilingual website with an office and an illustrative policy simulation. They move no funds and do not call tilcai-core or a payment network.
Validating the flow
Inquiry and purchase with approval
A pilot is declared validated once the complete journey works in its stated environment.
Direct payment on Stellar with x402
Verification and settlement go through an OpenZeppelin Relayer. A testnet payment was confirmed and repeating the same payload did not pay twice, but the test used the native asset, not USDC. It still has to be repeated with USDC and connected to the order.
Quotes, orders and commercial adapter
Verifiable quotes, orders and the adapter that consults each business's own system, which stays the source of truth for prices and availability.
Approval per purchase
The user reviews and authorizes the exact terms of each purchase. Connecting an assistant or an account never authorizes spending.
Order, payment and delivery tied together
The technical rail already reconciles its payments. What is missing is linking each payment to its order and to the business's delivery confirmation, and keeping the budget hold when a result is uncertain.
MCP connector and assistant guides
The tool surface for assistants is specified, but no MCP server is exposed yet. A guide is published for each client only after it has been tested.
WhatsApp channel
The team demonstrated instruction, payment and receipt over WhatsApp. Our own adapter still has to be integrated and the demo repeated with credentials the team can reach.
Third parties and accounts (SCA phase)
The data for third parties, with keys stored as hashes, daily quotas and an account registry, is under review. Per-third-party authentication, the API and account issuance are still pending.
After validating the foundation
Delegation and interoperability
No fixed dates: each item moves forward when its tests pass.
Smart accounts with limited permissions
Delegated signing with scope, expiry and revocation, enabled only after the account, signer and rail have been tested together.
Shared budget across agents
Limits and holds coordinated across several agents, so they cannot spend the same funds twice.
Scheduled tasks and more clients or providers
Repeated purchases re-evaluated on every run, plus additional assistants and businesses.
More CCTP routes
Ethereum, Arbitrum, Base, Arc, Solana and Sui are in the lab. Each route is enabled, one at a time, once it passes its end-to-end test.
Entering and leaving bolivianos
There is no verified provider or corridor yet. Today no QR deposit is accepted and no local currency is converted: CCTP only moves USDC.