These pages define the public API contract, explain where each field comes from,
document the phase 1 registry model, and make the current policy gaps visible.
Where a launch-time decision is still open, the docs say TBD instead of improvising certainty.
These three documents define the read-only public surface and the conditions under which the website is allowed to present it as production-grade data.
Endpoint inventory, canonical response structures, error behavior, and how to read source, fresh, available, and issues.
Explains which fields are on-chain, which fields are local enrichments, how freshness is derived, and what the site must not infer when the data is partial.
Covers the registry file format, phase 1 EVM scope, placeholder-address hazards, and the checklist required before the transparency hub can be published as production.
The next layer is not just transport or schema. It is the narrative discipline required to explain proof-of-reserves data, cross-chain domains, and compliance powers without overselling maturity.
Defines total_reserves, liquid_reserves, report_hash, and the reconciliation rule against global supply.
Explains why USDX uses protocol-defined domain_id values rather than only native chain IDs, and how aliases map into those canonical domains.
Sets the public posture for freezes, sanctions, KYC flags, and disclosure promises, while marking the operational and legal pieces that are still not finalized.
The backend now exposes a dedicated read-only layer for transparency. These docs turn that capability into a publishable surface with a clear contract and honest limits.
For self-hosted deployments, the backend also ships a reference dashboard and /metrics endpoint. The website remains the branded public layer over the same JSON surface.
API pricing, paid packaging, mint and redeem SLAs, jurisdiction blocks, and onboarding mechanics still need product and legal closure. Public docs should keep those items marked TBD until approved.