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: October 23, 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=7b453527408ba11dc0b20e58585483347426fb8a1322cdd91f40c443ede66cc2 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 settles in test mode: real settlements are verified on Base Sepolia (testnet, no real value) in the demonstration store. That we accept x402 payments with real value — and mainnet, volume, or real merchants using it — cannot be claimed.
Agentic Commerce Protocol
ACP bridge deployed and configured for the demonstration store (Stripe in test mode, no real money). Settlement with real value over this rail, merchants settling through it, and volume cannot be claimed.
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, with a caveat about provenance: this entry's `MCAP_ENABLED="true"` reading was taken from the Railway console, which is a different deployment. Measured on 2026-09-10 against `trusteed.xyz` and `api.trusteed.xyz` — both reporting `deployment: 55f23abf`, the host that actually serves — `/api/v1/health` does NOT publish the `protocols.mcap` block, and that block only appears when the flag is `"true"`: on the serving host the inbound payment adapter therefore never registers. The credential surface is registered without a flag (`/api/v1/mcap/keys`, `/consent`, `/verifiable-intent`). Neither settlement over this rail nor its availability on the serving host 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.
Agent Payments Protocol (AP2)
AP2 v0.1 over REST is withdrawn (it never normalized a mandate in production). AP2 v0.2 over the UCP extension `dev.ucp.common.payment.ap2_mandate` is under construction behind a flag that is off. It cannot be claimed that any store accepts it, that it runs against any third-party environment, or that it settles payments.
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
Some systems degraded: see the live health endpoint below for what and why
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. Per the signed capability registry (/.well-known/trusteed-capabilities.json), the rails where an agent itself settles stand as follows. LIVE (settles real value): none. CODE_COMPLETE (implemented; can settle real value wherever an operator has enabled the rail; the registry's evidence says whether a charge has been observed): none. SANDBOX (test value only): x402, acp. Not settling (PLANNED or DORMANT): ap2, mcap, paypal. Whether a given merchant can be charged through the browser-payment path depends on that merchant's own payment-processor configuration, which changes over time and is not asserted here: ask get_payment_methods for the store.
GET /api/v1/healthHealth endpoint
- MCP Gateway
- Degraded
- API v1
- Degraded
- Dashboard
- Operational
- Shopify Integration
- Degraded
- WooCommerce Integration
- Degraded
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. That aggregate comes from the deployment serving this domain, which is the one a visitor or an agent reaches; the residual Railway deployment listed under dependencies is a different process and is not what these rows measure. For rollout stage, read connectedPlatforms in /.well-known/agent-commerce.json, where the platform connectors are guided beta or sandbox.
System Status
Purchase flow (demo store)
A synthetic purchase runs against the public demo store every 15 minutes. Each row is one stage of it, so a failure shows up in the stage that broke instead of hiding behind a process that still answers.
This is the demonstration store with a sandbox key. Payment initiation stops at the approval link and charges nothing, and the receipt is not collected in this mode, so a green run does not prove that any payment can be taken. A row marked Not measured has no reading: either the run stopped at an earlier failing step, or, as with the receipt in this mode, it is not collected on purpose.
Purchase flow (demo store)
- Discovery
- Operational
- Cart and shipping
- Operational
- Checkout preview
- Operational
- Approval
- Not measured
- Payment initiation (no charge)
- Failing
- Receipt
- Not measured
- NLWeb search
- Degraded
Optional feature. It is reported on its own row and does not count towards the purchase flow.
System Status
Upstream dependencies
Trusteed's availability depends on a small set of upstream providers. Each one below says what it actually carries; where the provider publishes a status page, it is linked.
Arsys (Spain, EU)
Serves trusteed.xyz and api.trusteed.xyz: the public site, the merchant panel and the API deployment that answers both of those domains, with its own production database. If this page loaded, this is the provider that served it.
This provider does not publish a public status page.
Railway (compute & Postgres)
Runs a second, residual API deployment with the other production database, reachable on its own railway.app hostname. It does not receive traffic for trusteed.xyz or api.trusteed.xyz, so a Railway outage does not take down the surfaces listed above it.
https://railway.com/statusAuth0 (auth.trusteed.xyz)
Identity provider for merchant and agent authentication.
https://status.auth0.com/Stripe
Subscription billing and the card rail available to merchants.
https://status.stripe.com/x402 facilitator
Stablecoin rail. Its state is in the payments note above and in the signed capability registry.
https://x402.org/Measured on September 8, 2026: trusteed.xyz and api.trusteed.xyz resolve to the same address and are served by the same deployment. Both publish deployment fingerprint 55f23abf in /api/v1/health, over nginx. The Railway deployment publishes a different one (154994f4) on its own hostname. That is the check to repeat before assuming a provider change affects this page: two hostnames publishing the same fingerprint are the same deployment, whatever a provider dashboard says.
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
- Platform check: Degraded — see logs for detail
- Purchase flow (demo store): failing at step complete_checkout
- NLWeb search: the search query path is not answering
- 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