Protocol Documentation · v0.1

Own the Graph.

HORUS is a private data marketplace on Solana. You sell access to your data — never the data itself. Encryption stays client-side, queries run inside a sealed enclave, settlement is on-chain, and every proof is zero-knowledge.

1. Overview

Today your behavioral data is harvested, packaged, and resold by brokers you never see. HORUS inverts that graph: data lives in encrypted vaults you control, buyers pay for narrowly-scoped, time-boxed query access, and you keep the spread. The raw rows never leave the vault — buyers receive only the computed answer to a pre-approved query.

Four primitives make that possible: client-side encryption so the network only ever sees ciphertext, a confidential compute enclave that runs queries without exposing rows, a zero-knowledge access circuit that lets a buyer prove entitlement without revealing what they hold, and an on-chain settlement program that escrows payment and enforces expiry.

2. System model

Four parties interact, and no single one is trusted with cleartext:

3. Encrypted vaults

A vault is an append-only set of records sealed with envelope encryption. Each record is encrypted under its own per-record data key (DEK); every DEK is wrapped by the vault's master key, which is derived on the owner's device and never transmitted.

Only the Merkle commitment C is registered on-chain — it fixes the dataset's contents without revealing size, schema, or values. Because every DEK is wrapped by a key the marketplace never sees, a full compromise of HORUS's infrastructure or storage layer yields nothing but opaque ciphertext.

4. ZK access proofs

When a buyer wants to query, they must prove three things at once — that they hold a live grant, that it covers this dataset, and that their query falls inside the licensed scope — without revealing the grant secret or the query itself. That is a Groth16 circuit over BN254.

The proof reveals nothing beyond its own validity. Two queries from the same buyer are unlinkable on-chain; an expired grant simply produces no satisfying witness, so verification fails by construction rather than by policy check.

5. Compute-to-data

A valid proof authorizes execution, not export. The approved query is dispatched to a confidential enclave that:

1. Attests. The enclave publishes a remote-attestation quote; the owner's wrapping policy only releases DEKs to an enclave whose measurement matches the audited build.
2. Unwraps in isolation. DEKs are unwrapped and rows decrypted inside sealed memory — never paged to disk, never visible to the host.
3. Runs the licensed query. Only operations whitelisted by the policy (aggregations, filtered counts, model inference) are permitted.
4. Returns the result only. The enclave emits the answer plus a signed receipt; intermediate rows are zeroized on exit.

Optional differential-privacy noise can be required by the policy, bounding what any single result reveals about an individual record.

6. Protocol flow

1. Seal. The owner encrypts a dataset locally and registers its Merkle commitment on-chain. Ciphertext is pinned to decentralized storage; the master key stays on the device.
2. List. The owner publishes an access policy — price, allowed query class, and time-to-live — as a marketplace listing bound to the commitment.
3. Grant. A buyer pays in $HORUS. The program escrows the payment and mints a non-transferable grant scoped to the listed policy.
4. Prove & query. The buyer submits a Groth16 proof of their grant; on verification the attested enclave runs the approved query and returns only the result.
5. Settle. Escrow releases to the owner on the first valid query. Grants auto-expire at their TTL — no lingering access, no silent resale.

7. Threat model

8. $HORUS token utility

• Settlement currency — every access grant is escrowed and paid in $HORUS.
• Operator staking — enclave operators stake to underwrite query availability; faulty attestation or downtime is slashed.
• Governance — listing standards, the fee schedule, and circuit/enclave upgrades are voted on-chain.

Contract address: TBA at launch. Verify only against this domain and @usehorus.

9. Privacy guarantees

• Raw records never leave the vault — buyers receive computed results, not exports.
• Keys are never uploaded; loss of the marketplace cannot expose data.
• Access is time-boxed and revocable; expired grants produce no valid proof.
• Buyer queries are unlinkable on-chain — the proof leaks nothing but its validity.
• Every grant, revocation, and settlement is publicly auditable on Solana.

10. Roadmap

• Phase 1 — Vault SDK (envelope encryption + Merkle commitments) and on-chain grant registry on devnet.
• Phase 2 — Groth16 access circuit, on-chain verifier, and attested confidential-query enclave.
• Phase 3 — Public marketplace, operator staking/slashing, and governance.

This documentation is a living draft and not investment advice. HORUS is experimental software; the cryptographic design is subject to audit before mainnet.