QASH Valuation API and international adopter access

Issuer: OpenForex Society. Authority: QASH Valuation Authority. Standards: QASH Valuation Feed & Oracle Standard 1.0; QASH Valuation API Standard 1.0; QASH International Adopter Access Standard 1.0. Primary reference currency and constitutional denominator: NONE.

OpenForex Society determines and publishes the authoritative QASH valuation state. Adopting environments consume that valuation through authorized interfaces and shall not redefine the constitutional value of QASH independently.

QASHAPP is an adopting environment of QASH. It is not the source of QASH valuation.

Any compliant international organization may obtain authorized access to the OpenForex QASH Valuation API and integrate QASH valuation into its own systems without becoming the constitutional authority of QASH.

Implementation and activation

The repository contains the executable qash-authority/ service: a four-dimension decimal Value Engine, publication authority, persistent immutable epochs and revisions, authenticated REST API, adopter registration and credential management, developer portal, sandbox, signed publication capability, OpenAPI contract and a server-side QASHAPP reference client.

Society governance and the public source-data service are deployed. The available-data library exposes 83 retained source observations and derived source statistics through JSON/CSV and a public observations API. The publication-status endpoint reports current QASH valuation availability from the authority’s own current-epoch checks.

The designated valuation API targets are https://api.openforex.io/qash/v1 and https://sandbox-api.openforex.io/qash/v1. These target addresses do not establish that a current valuation is available. Integrators should verify publication status and obtain authorized endpoint and credential details through the Society’s onboarding process. Public source observations are available now at /governance/data/observations.json without an API credential.

Standard and publication status

The Third Value Neutrality Standard establishes QASH’s reference role. The TVX-2.6 construction and OAS-1.0 admission workflow define the four capacities, neutral normalization, source evidence and review responsibilities. A rate is available for operational use only through a current authorized publication; the standard’s publication and a particular dataset’s readiness are separate facts.

The QASH reference calculator implements the common-reference arithmetic with explicit input provenance, decimal precision and a downloadable calculation record. Preset figures are illustrative. Entering values does not issue an authority publication. Read the source dataset’s exact scope and the valuation epoch’s validity before integration.

Authority and value

Constitution → Third Value Methodology → Value Engine → Valuation State → Valuation Authority → API → Authorized Adopters → Applications → Transactions / Settlement.

The engine obtains N₁–N₄ from approved neutral dimension transformations and computes V(A,t) = [N₁ × N₂ × N₃ × N₄]^(1/4). The API publishes QASH per one asset unit, QPU(A,t). An application calculates only Quantity × QPU and labels the result Reference QASH Value, preserving its valuation epoch. TVX is Q(A,t) ÷ Q(B,t) from one authoritative epoch. Monetary supply, execution and settlement do not redefine value.

No market currency or commodity becomes a hidden denominator. The analytical structural model in the TVX learning toolkit is separate from the constitutional production engine.

REST access

Requests use HTTPS with X-API-Key and X-API-Secret. Credentials belong to individual approved applications and are stored as one-way hashes. Secrets are displayed once when issued. An optional timestamp and nonce pair enforces a five-minute window and replay detection. Use server-side credentials; never bundle them into an application UI.

/valuations supports asset, asset_type, status, epoch, page and limit. A historical epoch can be selected explicitly; it never returns today's value in place of the requested state. Reciprocal responses use direction=asset_per_qash, with explicit source and destination units. Valuation numbers are decimal strings. Published precision uses half-even rounding; ratios use 18 decimal places.

Errors include INVALID_CREDENTIAL, CREDENTIAL_REVOKED, INSUFFICIENT_SCOPE, RATE_LIMIT_EXCEEDED, ASSET_NOT_SUPPORTED, VALUATION_NOT_AVAILABLE, EPOCH_NOT_FOUND, REVISION_NOT_FOUND, SERVICE_UNAVAILABLE and INVALID_REQUEST. Every structured error carries a request ID. The OpenAPI contract documents request and response shapes.

Epochs and integrity

DRAFT and PROVISIONAL are retained but not selected as current authorized data. FINAL and REVISED are consumable within their validity period. RETIRED withdraws current availability. Expired publications do not silently fall back to an older value. Historical audit copies remain historical.

An epoch retains observation cutoff, calculation/publication times, validity, versions, four dimensions, V(A), QPU, complete observation provenance, authorizer and integrity metadata. Revisions create a new epoch with its predecessor, reason and source change. Previous records are immutable.

Production publications are signed with Ed25519. Verification uses the full epoch object with integrity removed, sorted-key compact ASCII JSON and the detached signature. Adopters must pin the authority public key independently. A key supplied alongside a payload alone does not establish publisher identity.

Default cache policy is no-store. Any approved application cache must retain publication identity, validity, revision and status. On feed failure, display VALUATION_UNAVAILABLE; do not substitute an FX rate or represent stale data as current.

International onboarding

Organization → registration → OpenForex review → adopter ID → application approval → application credentials → sandbox validation → compliance and technical evidence → separate production approval → production API access.

Registration records legal name, jurisdiction, organization type, technical/compliance contacts, application, intended use, requested assets, expected volume, environment, standards acceptance and the responsible technical officer. The first reference adopter is QASHAPP, OFS-ADP-000001, with ordinary permissions. Its real registration details must be supplied before production onboarding is enabled.

Organizations agree not to redefine QASH, alter authoritative valuation, mislabel bilateral rates as constitutional TVX, erase epoch information or manipulate feeds. They protect credentials, maintain audit records, preserve attribution, report corruption and respect API and settlement standards. Sandbox approval never confers production access.

The developer portal supports application requests, ordinary credential issuance, listing without secrets, rotation, revocation, usage and production review requests. Standard access is 1,000 requests/hour; operator-reviewed limits can be 10,000, 100,000 or negotiated. Quotas apply per organization and never change the valuation.

Webhook subscriptions are reserved for review; a publication outbox records epoch and revision identifiers. Delivery and the QASH Valuation Stream remain future interfaces. They must consume the same authorized publication.

Continue with the developer entry point, TVX toolkit boundaries and constitutional standard.