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, testnet or mainnet with minimal amounts; nothing operates in commercial production or is audited) 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 to Stellar with CCTP
An end-to-end payment on testnet (Fuji to Stellar Testnet) and, since 10 October, on mainnet (Avalanche C-Chain to Stellar) with two real payments of 0.01 USDC: burn, Circle attestation and mint, with an API, reconciliation and a mode where the buyer pays no gas. Not audited, and larger amounts were not tested. It is a technical rail: it is not yet tied to quotes, orders or delivery.
Disbursement vault and simulated QR charge
A contract on Avalanche Fuji pays USDC to a wallet with a per-payment limit, a daily cap and a pause, and the relayer pays the gas. Six disbursements were confirmed in the end-to-end test with Optipagos: simulated QR, simulated deposit and disbursement. The QR is a simulator, with no bank or money, and the vault is not deployed on mainnet.
Third parties and accounts with a passkey (SCA phase)
Each third party has keys with permissions and a daily quota, and can request contract accounts with a passkey; the backends of Optipagos and of its agent already call this API. Verified on testnet on Avalanche Fuji and Stellar Testnet; off on mainnet. Still missing are delegation to agents, recovery and an audit.
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.
Backend monitoring
Each backend's signed events, testnet and mainnet, reach the site's dashboard, with one block per environment and a different secret for each. Still missing are a durable store on the site and the mainnet relayer's notices reaching TilcAI.
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; it is off on mainnet.
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 server and assistant guides
The tilcai-mcp 0.2.0 package is already on npm: six tools that let an agent with an EVM wallet pay USDC to a Stellar address through TilcAI's API, on testnet and on mainnet with separate keys. The commercial tools (catalog, quote, approval and order) still have no server. A guide is published for each client only after it has been tested.
WhatsApp channel
The Optipagos WhatsApp chat already shows the payment with biometric confirmation and its receipt. TilcAI's own adapter still has to be integrated and the demo repeated with credentials the team can reach.
After validating the foundation
Delegation and interoperability
No fixed dates: each item moves forward when its tests pass.
Smart accounts with limited permissions
The passkey account already exists on testnet; what is missing is delegated signing with scope, expiry and revocation so an agent can pay within a limit. It is 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 and Base Sepolia, Arc, Solana and Sui are still in the CCTP lab. Each route is enabled, one at a time, once it passes its end-to-end test and publishes its hashes.
Entering and leaving bolivianos
There is no verified provider or corridor yet. Today no QR deposit is accepted and no local currency is converted: the QR that exists is a simulator and CCTP only moves USDC.