Extension API (developer platform)
The Extension API is deployed and available. Developers or third-party integrations using it cannot be claimed.
System Status
System Status
Real-time operational status of Trusteed services. This page reflects the current health of our infrastructure.
Last updated: September 8, 2026
State per capability · read from the registry
Concrete capabilities, with their public ceiling.
Live confirms that a surface responds in production. It does not mean full coverage, universal commercial availability or validation of every flow.
Signed and verified on this load · JWS EdDSA
Check the same hash and the same key: registry_hash=8a0ac3121aed7c170daf895493cc204274a5f322fb00d3ea4f232680acca34a4 kid=4ed57a24-a48c-4df6-9c8c-f101f1d4bf8d /.well-known/trusteed-capabilities.json · /.well-known/jwks.json
MCP three-bucket tool registry
MCP is available in production for every store. The three-bucket split is in canary: that it is active for every merchant cannot be claimed.
governed by flag: MCP_THREE_BUCKET_ENABLEDUCP — Universal Commerce Protocol
We publish per-store UCP capabilities, with content derived from each store's real configuration. UCP transactions cannot be claimed.
llms.txt — agent discovery
We publish llms.txt for agent discovery. Agent traffic against it cannot be claimed.
A2A — agent-to-agent (agent card)
We publish an A2A agent card. That any agent has consumed it cannot be claimed.
FIDO2 / WebAuthn
We support FIDO2/WebAuthn — the endpoint is deployed. Adoption or passkey users cannot be claimed.
AG-UI — real-time checkout (SSE)
AG-UI is deployed for real-time checkout. Real agent sessions cannot be claimed.
SCP — Shopper Context Protocol
SCP is deployed and enabled by default. That any merchant is using it cannot be claimed.
governed by flag: SCP_ENABLEDLayer 1 — receipt JWS EdDSA (Ed25519) signature
We issue signed Trust Receipts (JWS EdDSA) in production. That every checkout generates one, or receipt issuance volume, cannot be claimed.
x402 HTTP-native payments
The x402 rail is deployed and no merchant has a settleable configuration today: the 402 builder and the settle route both return `x402_not_configured`. That we accept x402 payments — and any volume, settlement or merchant using it — cannot be claimed.
Agentic Commerce Protocol
ACP bridge deployed and configurable per merchant. None is configured in production: `/api/v1/health` reports demo.protocolBridges.acp = unconfigured. Settlement over this rail cannot be claimed.
Agent Payments Protocol (AP2)
bridge runs against Google's own demo AP2 environment; `GET /api/v1/health` reports demo.protocolBridges.ap2 = sandbox (derived from the signed capability registry since 2026-08-31), not a production cart-mandate flow — we publish below the registry ceiling (sandbox)
KYApay
Switched on for IDENTITY verification, not as a payment rail: that is the scope decided for this phase, and the code backs it — keys auto-provisioned by the KYA path are created with the `search`/`compare`/`cart`/`merchants:read` scopes and no `checkout`, so `/api/v1/agent/checkout` answers 403 `MISSING_SCOPE` to an agent authenticated with a Skyfire JWT alone. `/api/v1/health` reports protocols.kyapay.enabled = true, with chargeCount24h = 0 and lastChargeSuccess = null. Payment over this rail is a second phase; no settlement can be claimed today.
governed by flag: KYAPAY_ENABLEDTrustReceipt ↔ MPP binding
Binding implemented and dormant behind `SPEC056_MPP_BINDING_PROD_READY`: without the flag its five routes answer 503. No MPP-bound receipt has been issued in production.
governed by flag: SPEC056_MPP_BINDING_PROD_READYTrustReceipt v1.1 (eIDAS-hardened receipts)
Agentic transactions can generate a signed receipt … designed for eIDAS/ESIGN alignment. v1.1 issuance sits behind `TRUST_RECEIPT_EIDAS_HARDENING_ENABLED` (off by default): the corpus that exists today is v1.0.
governed by flag: TRUST_RECEIPT_EIDAS_HARDENING_ENABLEDeIDAS QTSP timestamping
Designed to issue QES via an accredited QTSP (InfoCert) — the integration is code-complete, pending production credentials
Agent HTTP signature identity verification
RFC 9421 verifier implemented and deployed in mode `block_spoofed` (the code default is `off`): a request carrying an HTTP signature that fails verification is rejected with 403 on the Customer and Checkout buckets; an unsigned request passes, and Discovery is never filtered. With neither `require_verified_checkout` nor `require_verified_authenticated` active, not signing costs nothing and agent identity remains a signal that cannot be relied on. That the agents reaching us are identified cannot be claimed, nor can any rejection count: it is not measured.
governed by flag: AGENT_IDENTITY_VERIFICATION_MODENLWeb natural-language discovery
NLWeb is deployed (route and pgvector present). It cannot be claimed that it indexes, answers queries, or that the `nlweb_ask` tool is available to agents: measured 2026-09-01, the route returns VECTOR_DB_UNAVAILABLE and the tool answers on no MCP surface.
WebMCP — browser bridge (W3C CG)
All four bridge bundles are served and their sha256 matches the build. NATIVE mode is unverified: the E2E suite injects a mocked `navigator.modelContext` and there is no run against a browser with real support. Working in a natively-supporting browser cannot be claimed.
MCP Apps — trust widgets (SEP-1865)
We serve MCP Apps widgets carrying the merchant's trust evidence. That any client has rendered them cannot be claimed.
Layer 2 — hash-chained receipts + signed checkpoints
Chaining and checkpoints implemented and ARMED in production: `TRUST_RECEIPT_CHAIN_ENABLED` is set and a genesis is declared (2026-08-06). Receipts issued before that genesis are not chained, and how many later ones are has not been counted: sequence immutability over the corpus cannot be offered, nor can an unbroken chain be claimed.
governed by flag: TRUST_RECEIPT_CHAIN_ENABLEDW3C Payment Request API — browser payment sheet
The human-confirmed payment path is implemented and its route deployed. That anything is charged through it cannot be claimed: no merchant has a configured processor, and no real payment has gone through this route.
governed by flag: BROWSER_PAYMENT_REQUIRE_SETTLEMENTMerchant verification via Digital Credentials API
We accept merchant identity verification via the Digital Credentials API — the endpoint is deployed. That any merchant has verified this way, or that the trust bonus has ever been granted, cannot be claimed.
governed by flag: EUDI_WALLET_ACCEPTANCE_ENABLEDKYA — agent operator verification
Agent operator identity verification is implemented and its route deployed. That there are verified operators cannot be claimed: the only identities in production are seeded demo data.
governed by flag: AGENT_IDENTITY_VERIFICATION_MODEMastercard Agent Pay
No settlement: `MCAP_ENABLED` is set in production, so the inbound payment adapter is registered and `/health` publishes the `protocols.mcap` block — yet `protocols.mcap.available` stays negative, because that field reflects the Stripe connection, not the flag. The credential surface is registered without a flag (`/api/v1/mcap/keys`, `/consent`, `/verifiable-intent`). No settlement over this rail can be claimed.
governed by flag: MCAP_ENABLEDIXOPAY payment trust
Opt-in per merchant via `MerchantPspConfig` and unconfigured in production (`/api/v1/health` → payment_trust.ixopay = unconfigured). Routing and vault are advisory-only: no real settlement executes through this layer.
VIC — Visa Intelligent Commerce
Adapter complete with no route registered: there is no surface to call it through. Blocked on external access to Visa's pilot, not on work of ours.
governed by flag: VIC_RECONCILIATION_ENABLEDPayPal
Implemented and unconfigured: production `/api/v1/health` does not publish the `paypal` block, which proves the credentials are missing. Settlement over PayPal cannot be claimed.
governed by flag: PAYPAL_ENABLEDLayer 3 — RFC 3161 timestamping against a QTSA
RFC 3161 timestamping implemented, with EU Trusted List validation, and no provisioned provider: `/api/v1/health` reports qtsp.enabled = false. No receipt carries a qualified timestamp today.
Sanctions screening
No OFAC/EU/UK provider integrated in production: no sanctions screening runs today. A merchant should not rely on this control for their compliance.
governed by flag: SANCTIONS_SCREENING_MODEA2-UI
No implementation in the source tree. Nothing is deployed, not even behind a flag: this is a plan, not a capability.
Layer 4 — qualified seal (QES verified against trust chain)
Not available. No code path produces a VERIFIED seal today: the signature is always persisted as SIGNED_UNVERIFIED, even with the flag on. Blocked on QTSP sandbox credentials.
governed by flag: QES_CADES_VERIFY_ENABLEDSystem Status
All systems operational
Agents and monitoring systems can query the live health endpoint for a machine-readable status report.
On payments, two things that sound contradictory and are not: Trusteed's role is to initiate and evidence payment flows over several rails, not to process them. We are not a payment processor and not the merchant of record — funds move through the merchant's own processor. The footer's "we do not process payments" and any "we accept <rail>" above describe those two different roles. Today no rail settles: no merchant has a payment processor configured and x402 returns x402_not_configured, so what is deployed is the initiation and evidence path, not completed payments.
GET /api/v1/healthHealth endpoint
- MCP Gateway
- Operational
- API v1
- Operational
- Dashboard
- Operational
- Shopify Integration
- Degraded
- WooCommerce Integration
- Operational
These rows report service availability — whether the process answering that surface is up right now — and not how widely the integration is rolled out. Only Shopify Integration has its own probe (token health); MCP Gateway, API v1 and WooCommerce Integration share the aggregate health of the same Fastify process, and Dashboard is proven by this page rendering. For rollout stage, read connectedPlatforms in /.well-known/agent-commerce.json, where the platform connectors are guided beta or sandbox.
Upstream dependencies
Service level targets
Trusteed's availability depends on a small set of upstream providers. When in doubt, check their status pages.
Auth0 (auth.trusteed.xyz)
https://status.auth0.com/Stripe
https://status.stripe.com/Railway (compute & Postgres)
https://railway.com/statusx402 facilitator
https://x402.org/Service level targets
Informational targets per tier. Contractual SLAs apply to Enterprise plans only.
Service level targets
- Uptime — STARTER: 99.5%
- Uptime — GROWTH / PRO: 99.9%
- Uptime — ENTERPRISE: 99.95%
- p95 latency — read tools: < 500 ms
- p95 latency — write/checkout: < 2 s
- RTO / RPO: 4 h / 24 h
Degraded right now
- No readiness check is reported as failing right now.
- No incidents reported in the last 90 days.
- An incident is a surface that stops answering. A readiness check reported as degraded is not an incident on its own — it is published below, live, as soon as the health endpoint reports it.
Urgent issues