Orogen

Legal

Disclaimers, scope, and posture.

This page reflects the protocol's regulatory posture as of the current snapshot. It is not legal advice. Customers operating in regulated industries should consult counsel on the applicability of Orogen to their use case. General contact: hello@orogen.network.

1. Token status

OROG is the utility token of the Orogen network. The four uses are (a) gateway burn on customer top-up, (b) operator stake, (c) validator stake, (d) governance.

Any token launch, distribution, listing, or jurisdiction-specific access path is subject to the final terms published for that event. This page summarizes the current product and protocol posture; it is not a token sale document.

2. US retail geo-fence at TGE

At TGE, the gateway and the AMM will enforce a geo-fence excluding US natural-person retail participants from primary token acquisition until a regulatory pathway is established. US-based enterprise customers will be able to consume inference services via the gateway (paying USDC/USD) without directly holding OROG, because the burn happens at the gateway layer. US-based operators will be able to participate by registering as legal entities and entering into a per-tier compute services agreement.

The geo-fence will be reviewed quarterly. Lifting it requires (a) a no-action letter or equivalent regulatory clarity in the US, or (b) a registration path appropriate to the network's posture.

3. EU AI Act

The EU AI Act applies to providers of general-purpose AI models and to deployers of high-risk AI systems. Orogen, in its role as a compute substrate, does not train or fine-tune base models; it serves inference of customer-selected models. The protocol surfaces a model-card transparency notice per base model registered via pallet-model-registry and supports customer-side disclosure of which (base_model, adapter) served a given request via the response receipt. Customers deploying high-risk AI systems remain responsible for their own AI Act compliance.

4. HIPAA, PCI, SOC 2 scope

Orogen does not claim HIPAA compliance, PCI compliance, or SOC 2 certification at launch. The TEE-anchored verification stack provides strong technical guarantees against host-OS or cloud-provider access to plaintext prompts and responses, but technical posture is not the same as regulatory certification. Customers requiring formal compliance certifications should contact hello@orogen.network to discuss compliance-tier scoping; these tiers may be subject to operator restrictions, additional contractual terms, and certified third-party audits.

5. Forward-looking statements

Numbers, dates, and roadmap milestones on this site are targets, not forecasts and not commitments. Decision gates are real; if a gate condition is not met, the next phase moves. Phase-gate reviews are published quarterly on the public status page.

6. Cookies and analytics

orogen.network does not set tracking cookies, does not load third-party analytics scripts (Google Analytics, Segment, Mixpanel, Plausible, or equivalents), and does not fingerprint visitors. No browser-side telemetry beacons are emitted from this marketing site. Authenticated product surfaces (such as the future gateway dashboard) will rely on first-party session cookies for API-key management and will document their own cookie posture when they ship.

7. Sanctions screening

At launch, the gateway will screen customer accounts and operator registration applications against major sanctions lists (including the U.S. OFAC SDN list, the EU consolidated list, the UK HMT consolidated list, and the UN consolidated list) and will use independent wallet-address screening providers to avoid single-vendor false positives. Specific provider selection is TBA. Matches are blocked at the gateway; the operator's stake is not seized by the protocol absent a separate slashing-class fault, but blocked operators cannot receive job routing. Customers and operators will be able to contest a match through the published compliance contact at launch.

8. Data retention

Customer prompts and responses are not stored by the protocol after the receipt commitment is finalised on-chain. The receipt itself contains only content hashes (model_hash, adapter_hash, prompt_hash, output_hash), not plaintext. Operators are contractually required to purge plaintext from their TEEs at the end of each request lifecycle; the TEE attestation chain provides a technical guarantee that plaintext does not exit the enclave. Server-side gateway logs containing request metadata (timestamps, model identifiers, byte counts, response codes) are retained for the minimum operational window required for reconciliation and abuse mitigation; the specific window is TBA and will be published before launch. Receipts and on-chain commitments are permanent by design, because they are the audit trail.

9. Informational content

Information about OROG, token mechanics, emission schedule, BME loop dynamics, allocation, and roadmap is provided for informational purposes describing the protocol's design. Tax, accounting, and legal treatment varies by jurisdiction; consult qualified professionals in your jurisdiction before acting. Residents of jurisdictions that restrict access to non-bank-issued tokens, including certain U.S. retail contexts addressed in §2 above, should not attempt to acquire OROG until access is available for their category.

10. Trademarks and attribution

Orogen and the Orogen mark are unregistered trademarks. NVIDIA, NVTrust, NVL72, H100, H200, and B200 are trademarks of NVIDIA Corporation. AMD, Instinct, and ROCm are trademarks of Advanced Micro Devices, Inc. Intel TDX is a trademark of Intel Corporation. Mentions are nominative and do not imply endorsement.

11. Contact

General: hello@orogen.network · Security disclosures: security@orogen.network.