Security model
What Omyra trusts, what it does not, and where the boundaries are. Privacy is a property of silicon; correctness a property of cryptography.
Omyra's premise is that privacy should be enforced by hardware and proven by cryptography, not promised in a terms page. This page is the honest version: what is trusted, and what is not.
Trust boundaries
| Component | Trusted? | Why |
|---|---|---|
| GPU operator | No | Sees only ciphertext; the enclave hides the prompt |
| TEE vendor (Intel / AMD) | Partially | Dual support limits the blast radius of a single-vendor flaw |
| Off-chain validator cohort | No | The Solana program re-verifies before settling |
| Solana program | Yes | This is the anchor of truth |
| Your wallet keys | You | They encrypt your Vault; only you hold them |
Defenses
- Confidential execution — prompts are sealed in a TEE; operators cannot read them.
- Verifiable receipts — every inference is provable after the fact without re-running it.
- Replay protection — validity windows make captured instructions useless after their slot passes.
- Reputation + slashing — providers bond
$OMYRA; misbehavior burns stake. - Provable deletion — nullifiers make erasure a one-way door you can verify.
Trusted setup
The target proof system requires a multi-party setup ceremony with a publicly auditable transcript; one honest participant suffices for soundness. Circuits do not activate on mainnet until the ceremony is complete and verified.
These mechanisms are engineering targets pending external audit and the completion of the trusted- setup ceremony. A protocol that exaggerates its present forfeits the trust it asks others to verify — everything here is meant to be checked, not believed.