Trust Status
Public status and launch readiness
See coarse live status plus the registry-derived snapshot of what still blocks live production. This page is public-safe and intentionally narrower than a production approval console.
What this status page shows
This page is powered by /api/health and /api/config/public. It is meant to stay clear and conservative, not to act like a full incident board.
API reachability
Reading the public health endpoint now.
This comes from the public health route only, so it should be read as coarse API reachability.
Sponsorship posture
The public config surface has not loaded yet.
This comes from the public config route and reflects the published sponsorship mode plus whether fee sponsorship is enabled.
Degraded-mode disclosure
Waiting for the public-safe inputs that drive this status disclosure.
Artax does not publish an operator-style incident timeline here. This is the bounded public-safe disclosure available today.
Last fetched
Not fetched yet
This browser last checked the public status at the time shown here.
What This Covers
Scope and hard limits
What it means
This page shows whether the coarse public health check is responding, whether sponsorship is currently active, limited, or paused, and which cluster plus transaction kinds the public config currently advertises.
What it does not mean
This page is not a live uptime certification, not an operator incident timeline, not a guarantee that every downstream dependency is healthy, and not a production support statement.
Published scope
Cluster, route scope, and published transaction kinds will appear here once public config loads.
Support and disclosure path
A public support and security reporting path is available at /trust/support and in SUPPORT.md plus SECURITY.md. It is a documented path, not a staffed production helpdesk or enterprise security program.
Launch-readiness snapshot
This section is derived from the canonical acceptance, compatibility-readiness, launch-gate, and release-evidence registries. It shows which paths have enough evidence for guarded validation and what is still missing before live production can be approved.
Acceptance sweep
7 required acceptance journeys are pinned in the canonical sweep for public entry, builder onboarding, review, dashboard operations, promotion, trust, and private admin checks.
8 total journeys are tracked, and 7 of them are required before live production approval.
Core launch paths
2 of 2 core launch paths are tracked as production-candidate paths.
2 non-core limited or example surfaces remain outside the main launch path.
Guarded rollout gate
The guarded pre-production rollout gate currently allows deploys. That means the core release checks are strong enough for continued private validation.
Guarded deploy allowed: yes. Production deploy allowed: no.
Production-only evidence
Production-only evidence is still the main gap. The current registries still show zero production approvals, zero production-supported compatibility profiles, and no live workflow-backed production smoke evidence.
Production approvals granted: 0. Signed or attested production artifacts: 0. Live workflow-backed production smoke records: 0. Production-supported compatibility profiles: 0.
Live Production Blockers
What still has to happen
These are the current production blockers pulled from the production launch gate and release-approval records. They must be resolved before live public production is approved.
Guarded production-candidate and production rollout workflows now exist, but no live production canary or smoke evidence exists yet.
Private dashboard environment-key proof is launch-window work: it must be run through the production web service against the one production API multi-cluster architecture, and it must prove one signed-in account and one project can hold separate devnet and mainnet-beta keys without cross-cluster key mutation.
A formal production approval record, canary rule, attestation policy, release-attestation-artifact policy, release-tracking policy, release-evidence-linkage policy, release-record-adoption policy, release-approval-authority policy, release-promotion policy, release-smoke-verification policy, and release-rollback policy now exist, and first checked-in local or synthetic proof records now exist across the production attestation, tracking, linkage, adoption, authority, promotion, smoke-verification, and rollback families, but no signed provenance, live workflow-backed production release evidence, or nonzero production approval record exists yet.
No production compatibility certification evidence exists yet.
Before live public production, a full repo security review must cover every checked-in line of code and unresolved trust-critical findings must block launch.
Guarded production-candidate and production rollout workflows now exist, but no live production canary or smoke record exists yet.
The private dashboard environment-key proof is now a production launch-window requirement: production web must route devnet and mainnet-beta requests through the one production API, one signed-in account and one project must create separate cluster-bound keys, and no devnet key may be mutated into a mainnet-beta key before live approval.
Formal production attestation, release-attestation-artifact, release-tracking, release-evidence-linkage, release-record-adoption, release-approval-authority, release-smoke-verification, release-rollback, and release-promotion policies now exist, and first checked-in local or synthetic proof records now exist across the production attestation, tracking, linkage, adoption, authority, promotion, smoke-verification, and rollback families, but no signed provenance, live workflow-backed production release evidence, or nonzero production approval record exists yet.
Registry review date: 2026-04-22
Core Launch Path Posture
These surfaces are the production-candidate paths. They are closest to live release, but they still need production certification and live release evidence.
Hosted review in browser wallets
CandidateCurrent hosted-review browser-wallet launch behavior is hardened enough to stay in the production-ready staging milestone and eventual launch window, while still remaining narrower than broad browser-family or wallet-brand production certification.
Broaden browser-level runtime certification beyond the current hosted-review path.
Server-to-server review and submit
CandidateCurrent server-to-server review and submit with external wallet signing is hardened enough for the production-ready staging milestone and launch-window planning, but it still remains narrower than broad signing-path production certification.
Convert current local, devnet, and staging evidence into live production release evidence.
Limited and example surfaces
These surfaces are real, but they are deliberately kept out of the core launch path until they have stronger runtime evidence and a broader certification story.
Partner embedded review example
Example onlyCurrent partner demo embedded review remains a repo-scoped design and integration example. It does not need to be staging-ready for the core launch window as long as public language stays example-only.
Keep the surface documented as example-only unless the broader partner-support program is funded and certified.
Browser add-on review flow
Limited scopeCurrent extension behavior remains a preview popup-review surface with a trusted-launch bridge and active-tab wallet link, but the runtime lab can now export a trusted acceptance snapshot from local or staging after the popup flow is exercised. The surface stays non-launch-blocking and narrower than universal signing claims.
Keep the surface documented as preview-only unless browser-device runtime evidence broadens the claim.
Interpretation rules
Health stays coarse
A healthy result only says the public API answered. It does not prove operator queues, webhook delivery, RPC redundancy, or every sponsorship-dependent subsystem is healthy.
Paused still means something useful
If sponsorship is paused or off, review is still possible, but sponsored submission should be treated as unavailable or narrower than the relay path.
Mock stays narrower than relay
Mock mode can be intentional, but it should never be presented like full live relay-backed sponsorship.
Next reads
This page is the narrow status view. Use the broader trust and developer pages for support boundaries, compatibility notes, and setup guidance.
Support
See the public support and security reporting path, scope rules, and response targets.
Open
Release assurance
See the formal release-evidence, approval, attestation, smoke, rollback, and launch-gate posture.
Open
Trust overview
Open the broader public-safe trust surface for support coverage, limitation honesty, and methodology links.
Open
Developers
See integration, hosted-review, funding, and machine-authority guidance.
Open
Quickstart
Follow the setup flow without assuming broader compatibility or production guarantees.
Open