What we're building next.
The TempoKey roadmap: bot connections, paid APIs and planned Robinhood Chain integration, from monitoring to agent wallets and automated workflows.
From payment keys to useful work
TempoKey starts with a simple promise: let an agent pay for a task while you control what it can spend. The next step is to make connecting a bot, choosing a service and checking the result feel like one workflow.
Alongside the Tempo payment foundation, we plan full agent support on Robinhood Chain. The goal is a useful service for people and applications on the network, from monitoring to permissioned execution.
Live — The payment foundation
- Tempo Mainnet payments with delegated P256 keys, per-token budgets, recipient restrictions, expiry and revocation.
- A TypeScript SDK for payments, swaps and sequential batches, plus an authenticated payment REST API.
- Individual key export, bot connection guidance, on-chain payment history and compact transaction receipts.
- A Robinhood testnet membership pilot that increases shared hosted API capacity.
A real MPP purchase has been demonstrated with an external integration. An in-app service catalog and ready-made bot connectors are still planned.
Next — Connect your bot
Make the first integration easier, starting with Grok-compatible tools and a reusable connection flow for other agent runtimes.
- Product: guided setup, a connection check and a clear approval step for the first purchase.
- Bot integrations: an authenticated MCP payment service and a Grok function-calling example. Chat receives task instructions and results; credentials stay in the payment runtime.
- Key handling: encrypted local key storage, clearer backup and recovery options, and per-tool access controls.
- Developer tools: a runnable Node.js starter, environment validation and typed tool definitions.
Then — Buy API services
Bring service discovery, price checks and payment into the dashboard. Start with web search and page extraction, then evaluate image generation and browser sessions.
- Product: a small service catalog with clear provider information, supported tokens and request examples.
- Payment flow: preview the service price and network fee before payment, enforce a task budget and show whether the requested result was delivered.
- Receipts: include the service name, payment amount, fee, transaction link and request outcome. A confirmed payment and a successful service response remain separate statuses.
- Engineering: a reusable MPP adapter with chain, token, recipient and amount checks; quote-expiry handling; and protection against accidental duplicate purchases.
Later — Run repeatable workflows
Turn individual purchases into tasks that can be scheduled, monitored and stopped.
- Product: scheduled jobs, reusable task templates, pause controls and an activity view for each run.
- Spending controls: budgets per task and service, approval thresholds and alerts before the authorized budget is exhausted.
- Operations: signed webhooks, delivery retries, CSV exports and reconciliation between service results and on-chain payments.
- Engineering: durable job storage, queues, idempotent execution and a history index that reduces browser RPC polling.
Robinhood Chain — Full integration track
Build toward a single dashboard and developer interface for agents on Tempo and Robinhood Chain, with separate balances, permissions and transaction histories for each network. The stages below describe planned work, not current mainnet support.
| Stage | What users can do | Engineering milestone |
|---|---|---|
| 1. Observe | Monitor selected wallets, token balances, transfers and contract events. Receive alerts and request an activity report. | A read-only RPC and indexing adapter, typed bot tools, confirmation handling and recoverable event processing. |
| 2. Authorize | Create a Robinhood Chain agent wallet with explicit permissions, expiry and revocation. | Evaluate smart accounts and session keys; enforce token budgets, contract and function allowlists, and time limits. Prove the policy on testnet before mainnet. |
| 3. Execute | Send supported payments and use selected application actions with previews, spending controls and receipts. | A separate transaction adapter, simulation, gas estimates, ETH fee budgeting and recovery from uncertain transaction status. Enable each application only after integration testing. |
| 4. Automate | Run scheduled or event-driven workflows across supported services from one activity view. | SDK, API and bot-tool support; signed webhooks; explicit approvals for each network; duplicate prevention and per-step results. |
Full integration means support for the workflows and applications we explicitly document. It does not mean access to Robinhood brokerage accounts, every asset or every application. Automatic bridging and unrestricted trading are outside the initial scope. TempoKey is an independent project; this roadmap does not announce a Robinhood partnership.
The planned token lock on Robinhood Chain would qualify an owner for shared TempoKey service capacity. Payments for workflow tasks would initially remain on Tempo. Holding or locking tokens will never grant an agent wallet permissions. Token identifiers, launch settings and timing remain unannounced.
Membership track — Capacity for useful work
Extend the working testnet quota pilot into shared allowances for managed automation. This track follows the availability of the services it controls; publishing a token does not activate those services.
| Stage | Product milestone | Engineering milestone |
|---|---|---|
| Pilot — live | Lock test tTK to increase the owner's hosted API quota. | Confirmed position verification and persistent owner usage accounting. |
| Build — planned | Show active monitoring rules, workflow slots and their remaining capacity in the dashboard. | Owner-scoped allowances, atomic slot reservations, a durable scheduler and authenticated webhook delivery. |
| Validate — planned | Preview the effect of withdrawing tokens before confirming a request. | Test quota downgrades, pauses, service outages and recovery. Stop excess jobs before new paid work; preserve history and revocation access. |
| Mainnet — gated | Activate verified token locks only after the supported services and operating rules are published. | Review the lock contract, validate mainnet reads and ship tested capacity enforcement before enabling benefits. |
Developer track — Easier to build on
Developer work runs alongside the product stages, with working examples and predictable behavior taking priority over adding more endpoints.
- SDK: stable package releases, stronger types for payment results and quotes, and a first-class Python client.
- API: versioned interfaces, generated clients, webhook verification helpers and clearer machine-readable errors.
- Examples: a Grok payment-tool starter, an MCP integration, a paid-search workflow and a small service-provider example.
- Testing: expand contract tests for MPP providers, failure-recovery tests, wallet integration checks and release compatibility coverage.
- Documentation: copy-and-run tutorials, migration guides and a clear matrix of supported networks, tokens and runtime integrations.
Exploring — Teams and the integration ecosystem
- Shared workspaces with separate roles for owners, developers and operators.
- Team approval rules and shared service quotas, while wallet spending permissions remain explicit.
- Discounts on individual TempoKey services after pricing exists, separate from upstream API costs and network gas.
- A reviewed integration catalog with provider deposits, clear withdrawal terms and dispute handling. A deposit would not replace security review.
- Community proposals and feedback on integration priorities, without authority over user funds.
- Networks beyond Tempo and Robinhood Chain after demand and integration reliability are demonstrated.
These ideas are not scheduled commitments. The current tTK pilot does not define a future token allocation or mainnet launch date.
How we choose what ships
Priorities follow real tasks: can a user connect a bot, understand the price, receive the result and verify the payment? We will narrow scope when needed to make that workflow reliable.
- Ship a small, usable integration before expanding the catalog.
- Test spending boundaries, duplicate requests and failure recovery before enabling unattended purchases.
- Document supported behavior and remaining limitations in the release notes.
- Use feedback from actual integrations to reorder the next milestones.