Institutional Privacy

Privacy Infrastructure for Institutions.

Q: What is institutional privacy?

Institutional privacy is the expression of the H33 Privacy Layer for regulated entities in which competitive information such as positions, order flow, counterparties, and client identities is protected while a required claim is proven and post-quantum attested. The institution keeps competitive privacy; the counterparty or examiner gets a verifiable claim, not the data behind it. It supports a compliance program but does not by itself make an institution compliant.

Q: Does an attestation mean my institution is compliant?

No. An attestation proves a bounded claim, such as that AML screening was completed or that reserves were adequate at a point in time. Whether the institution is compliant overall is a separate determination made by the institution and its regulators. The privacy techniques provide verifiable evidence that supports that determination; they do not replace it.

Related · tier-1 reading. For the privacy story end-to-end — FHE + STARK proof + portable artifact, see Privacy Layer.

Banks, custodians, and regulated entities need privacy they can prove compliance for.

Institutional digital asset participation requires two things that existing infrastructure cannot provide simultaneously: competitive privacy and regulatory compliance. H33 delivers both.

One API call. 32 bytes on-chain. No PII custody. Post-quantum survivable.

Schedule Demo Privacy Layer

Definition

What institutional privacy is.

Institutional privacy is the thematic expression of the Privacy Layer for regulated entities — banks, custodians, asset managers, insurers, exchanges — in which competitive information (positions, order flow, counterparties, client identities) is protected while a required claim is proven and post-quantum attested. The institution keeps its competitive privacy; the counterparty or examiner gets a verifiable claim, not the data behind it.

Why this exists: institutions cannot expose strategy on public ledgers, yet cannot use sanctioned mixers or unregulated privacy chains. Institutional privacy exists to close that gap — competitive protection and provable claims at once. The concept is owned by the Privacy Layer; this page is a supporting expression, and each chain named is a reference environment the evidence anchors to, never a system H33 owns. The techniques here support compliance programs; they do not by themselves make an institution compliant, which is a separate determination.

Owner

The Privacy Layer owns the concept — institutional privacy reinforces it, never redefines it.

Attestation by H33-74

H33-74 attests each proof with three post-quantum families and anchors a 32-byte commitment.

Mechanism

STARK zero-knowledge proof (ZK), minimization, and selective disclosure. Encrypted compute (FHE) is a separate data-in-use mechanism, used only where genuinely required.

Independent verification

Any examiner or counterparty confirms an attestation with the public verifier — see Verification — without trusting H33 or the institution.

The Problem

The institutional privacy gap.

Institutions cannot participate in DeFi or hold digital assets publicly without revealing competitive information. Trading strategies, portfolio allocations, counterparty relationships, order flow -- all visible on public ledgers. But they also cannot use existing privacy tools. Tornado Cash is sanctioned. Mixers are non-compliant. Privacy chains lack regulatory frameworks. The gap between what institutions need and what exists today is the institutional privacy gap.

Public Ledgers

Competitive intelligence leakage

Competitors monitor your wallets. Counterparties front-run your trades. Portfolio positions become public intelligence. Institutional participation means institutional exposure.

Existing Privacy Tools

Regulatory non-compliance

Tornado Cash: sanctioned. Mixers: flagged by compliance tools. Privacy chains: no regulatory framework. No existing privacy tool satisfies institutional compliance requirements.

H33 Institutional Privacy

Privacy for competitive protection. Compliance for regulatory requirements.

STARK proofs verify that regulatory requirements are satisfied without revealing the underlying positions, trades, or counterparties. The institution maintains competitive privacy. The regulator maintains compliance visibility. Neither compromises for the other.

Use Cases

Privacy and compliance by institution type.

Each institution type has specific privacy requirements and specific compliance obligations. H33 addresses both simultaneously for each.

Banks

Wire Privacy + AML Proof

Process wire transfers and cross-border payments privately while producing per-transaction AML compliance attestations.

Transaction routing without counterparty exposure
Per-transaction AML screening attestation
Correspondent banking privacy
BSA/CTR threshold monitoring without amount disclosure
Examiner-verifiable compliance evidence

Asset Managers

Portfolio Privacy + Fiduciary Proof

Protect portfolio positions and strategy while proving fiduciary compliance and investment mandate adherence.

Position privacy across public chains
Investment mandate compliance proof
Concentration limit attestation without positions
Best execution proof without order details
LP reporting without position disclosure

Insurance

Claims Privacy + Actuarial Proof

Process claims and manage reserves privately while proving actuarial soundness and regulatory capital adequacy.

Claims processing without PII exposure
Reserve adequacy attestation
Actuarial model validation without model disclosure
Reinsurance verification without cedent exposure
Regulatory capital proof

Exchanges

Order Flow Privacy + Market Surveillance Proof

Protect order flow and trading activity while proving market surveillance and manipulation monitoring compliance.

Order flow privacy from external observers
Market manipulation monitoring attestation
Wash trading detection proof
Volume and liquidity attestation
Regulatory audit trail without trade details

Integration

One API call. 32 bytes on-chain. No PII custody.

Integration is a single REST endpoint. The institution submits a compliance claim. H33 generates the STARK proof, signs with three PQ families, and returns a 32-byte commitment ready for on-chain anchoring. No PII crosses the wire. No data custody required.

                
                institutional integration
            
// One API call from your compliance system
const attestation = await h33.attest({
  claim:    "aml_screening_passed",
  entity:   "institution_id_hash",
  chain:    "solana",     // or bitcoin, ethereum, base, arbitrum
  epoch:    "24h",        // OFAC cadence
});

// Returns:
// attestation.commitment  → 32 bytes (on-chain anchor)
// attestation.cachee_key  → retrieval key for full proof
// attestation.expires_at  → epoch expiry timestamp
// attestation.revocable   → true

// What was NOT sent to H33:
// - transaction details
// - counterparty identities
// - portfolio positions
// - client PII

Lifecycle

Create. Verify. Refresh. Revoke.

Attestations are living compliance objects. They are created when compliance is verified, queried when counterparties need proof, refreshed when epochs expire, and revoked when circumstances change. Every state transition is immutably recorded.

Step 1

Create

STARK proof generated from compliance claim. H33-74 attests with three PQ families. 32-byte commitment anchored on-chain. Full proof stored in Cachee.

Step 2

Verify

Any party verifies independently. On-chain commitment check, H33-74 signature verification, or full STARK proof verification via the public HATS verifier.

Step 3

Refresh

When attestation approaches epoch expiry, institution re-attests. New proof generated, new commitment anchored. Previous attestation remains in the audit trail.

Step 4

Revoke

Circumstances change. Attestation revoked immediately. On-chain status updated. All verifiers see revocation in real time. Compliance state changes take effect instantly.

Attestations are time-bound, revocable, and portable. Compliance is continuous, not static. Evidence is exportable for audits, litigation, and regulatory examinations.

Post-Quantum Survivability

Institutional evidence must hold for 30+ years.

Banks store records for decades. Insurance claims span generations. Regulatory evidence must be verifiable years after the fact. Classical cryptographic signatures will not survive the quantum transition. Every compliance attestation signed with ECDSA or RSA today will be unverifiable when quantum computers arrive. Institutional privacy infrastructure must be post-quantum from day one.

Three Hardness Assumptions

H33-74 attests with three independent mathematical hardness assumptions: MLWE lattices (ML-DSA), NTRU lattices (FALCON), and stateless hash functions (SLH-DSA). Breaks only if all three are simultaneously broken.

NIST FIPS Standards

All three PQ families are NIST-standardized (FIPS 203, 204, 205). Not experimental. Not academic. Production-grade post-quantum cryptography deployed at institutional scale.

Hash-Based STARK Proofs

STARK proofs are hash-based and post-quantum secure by construction. No elliptic curve assumptions. No pairing-based cryptography. Only collision-resistant hash functions under SHA3-256.

Harvest-Now-Decrypt-Later

Adversaries are capturing encrypted institutional data today, waiting for quantum computers to decrypt it later. Compliance evidence signed with classical cryptography is already being harvested. The migration deadline is not when quantum computers arrive -- it was years ago.

Boundary Questions

Where institutional privacy begins and ends.

Seven questions that fix the boundary of this expression against the owner that defines it, the mechanisms it uses, and the chains it references.

1 · Privacy property

Selective disclosure for regulated entities: a required claim is proven and verifiable while positions, order flow, counterparties, and client identities stay inside the institution.

2 · What is context-specific

The institution-type claims — AML, fiduciary, actuarial, surveillance — and their examiners are specific to regulated finance. The proof machinery is shared across the platform.

3 · Supplied by H33-74

The 74-byte post-quantum attestation: three-family PQ signatures, signer set, timestamp, authority scope, governance link. See H33-74.

4 · Mechanism

A combination: STARK ZK proof, minimization, and selective disclosure. FHE only where encrypted compute is genuinely in the workflow — a distinct data-in-use mechanism.

5 · What the chain does NOT provide

The chain gives permanence and public ordering for the 32-byte commitment only — an anchoring surface the evidence anchors to. It provides no privacy, no attestation, no compliance determination.

6 · Independent verification

Recompute the commitment and check all three PQ signatures with the public verifier — no vendor trust. See Verification.

7 · When to prefer another mechanism

Prefer FHE when the requirement is computation over data that stays encrypted end to end, rather than proving a claim about it.

Decision Guidance

When to use this, and when not to.

When to use this

Protect competitive information while proving a required claim.

Use institutional privacy when a regulated entity must show an examiner or counterparty that a requirement is satisfied — AML, fiduciary, actuarial soundness, market surveillance — while positions, order flow, and client data stay private. It supports the institution's compliance program; it does not replace the institution's own compliance determination.

When NOT to use this

Not encrypted compute, not a compliance verdict.

Do not use it when the need is computation over data that stays encrypted end to end — route to /fhe/, a different (data-in-use) mechanism. Do not read an attestation as a statement that an institution "is compliant" — it proves a bounded claim; the compliance conclusion belongs to the institution and its regulators. For property-level DeFi checks, see DeFi Privacy.

FAQ

Institutional privacy, in plain terms.

What is institutional privacy?

Institutional privacy is the expression of the Privacy Layer for regulated entities in which competitive information — positions, order flow, counterparties, client identities — is protected while a required claim is proven and post-quantum attested. The institution keeps competitive privacy; the counterparty or examiner gets a verifiable claim, not the data behind it. It supports a compliance program but does not by itself make an institution compliant.

Does an attestation mean my institution is compliant?

No. An attestation proves a bounded claim — for example that AML screening was completed or that reserves were adequate at a point in time. Whether the institution is compliant overall is a separate determination made by the institution and its regulators. The privacy techniques provide verifiable evidence that supports that determination; they do not replace it.

Is the mechanism ZK or FHE?

Primarily a STARK zero-knowledge proof plus minimization and selective disclosure, attested by H33-74. Where the workflow genuinely requires computing on data that stays encrypted end to end, fully homomorphic encryption may participate — but FHE is a distinct data-in-use mechanism documented at /fhe/. If encrypted compute is your actual need, start there.

What does the blockchain contribute, and how is the evidence verified?

The chain contributes permanence and public ordering for a 32-byte commitment only — an anchoring surface the evidence anchors to, never owns. It provides no privacy or compliance of its own. The evidence is verified independently by recomputing the commitment and checking the three post-quantum signatures with the public verifier, described at Verification — no trust in H33 or the institution required.