Implementation status
An explicit capability matrix. A working interface is not the same as a completed paid inference service.
In this chapter
How to read this handbook#
This is a product and engineering reference snapshot, reviewed on 20 September 2026. ‘Implemented’ means a capability exists and has been exercised; it is not a service-level guarantee. ‘In progress’ means only part of the workflow is complete. ‘Planned’ means it must not be relied on today. Hosted availability can lag a local build, so operators must verify the deployed release.
Capability matrix#
| Capability | Maturity | Important boundary |
|---|---|---|
| Public waitlist and referrals | Implemented | Redis-backed registration and referral ranking; not proof of wallet ownership or social activity. |
| Wallet sign-in | Implemented | Signature-verified, domain-bound challenges; browser-injected EVM wallets are the initial client path. |
| Persistent accounts and sessions | Implemented | PostgreSQL-backed identity and sessions, not a financial ledger. |
| API key creation and revocation | Implemented | Keys are real credentials and execute billable requests. |
| Supplier applications | Implemented intake | Applications remain pending review; they are not active serving endpoints. |
| Chat-first workspace | Implemented | Live model answers through verified supply; charges settle on the ledger. |
| Provider adapter | Implemented | OpenRouter is the initial verified upstream, activated through operator-owned offers with a server-side credential. |
| Request pipeline | Implemented; live | Quote → reserve → upstream call → usage reconciliation → capture/release → receipt. Verified end to end against production supply. |
| Verified supplier routing | Partial | Routing picks the cheapest active offer per model; only operator-owned OpenRouter offers are live. Third-party supplier verification/activation remains operator-run. |
| Usage accounting and funded balances | Implemented; live | Double-entry ledger with atomic reserve/capture/release. Real deposits credit real balances; a funded account can spend immediately. |
| Robinhood funding and payouts | Deposits live; payouts operator-run | USDG transfer claims to the treasury are verified on-chain and credited idempotently. Supplier payout requests escrow in the ledger and are settled manually by the operator. |
| x402 payments | Planned | Robinhood-compatible facilitator and asset behavior must be verified. |
| Attested confidential inference | Planned | No blanket end-to-end encryption or hardware confidentiality claim. |
What has been tested#
- Correct and incorrect wallet signatures, challenge replay, and concurrent verification.
- Account isolation: request parameters cannot select somebody else's account.
- API key creation, one-time secret disclosure, masked listing, and revocation.
- Supplier application ownership and persistence.
- Sessions and records surviving application/database restarts.
- Waitlist duplicate registration, multiple referrals, and storage failure handling.
- Browser navigation, unavailable-state behavior, and basic desktop/mobile layout.
- Trusted HTTPS, certificate renewal dry runs, and a database backup restoration into an isolated database.
A real billed request through production supply has completed and settled correctly on the ledger. These checks still do not equal an independent security audit or an exhaustive test of every wallet extension, contract wallet, device, payment failure, or operational incident. The deposit-claim path is enabled but has not yet been exercised with a real on-chain transfer.
What ‘operational marketplace’ will mean#
- A buyer authenticates and receives a real, durably recorded account.
- Funding is confirmed under an approved custody and payment model.
- An eligible supplier performs a real request under the selected service conditions.
- Actual usage is reconciled to an authorized charge without duplicate financial effects.
- Supplier earnings are recorded and paid through the approved settlement path.
- Failures, retries, partial outputs, refunds, and incidents have tested handling.
The core buyer loop now works: funded account → billed request → reconciled receipt → supplier payable. What remains before calling this a fully operational marketplace: a real customer deposit claimed on-chain, supplier self-service payouts, independent supplier supply, and operational hardening (alerting, off-host backups).