Data Privacy
What Is Programmable Privacy? From Programmable Cryptography to Verifiable Execution
March 2, 2026
16 mins read
Programmable Privacy in 2026 shows how private computation becomes verifiable execution, plus how Selective Disclosure reduces compliance exposure.
Programmable Privacy becomes a production problem when institutions need confidential workflows and verifiable outcomes at the same time. Private data cannot leak into logs, vendors, or counterparties, yet regulators and risk committees still demand replayable evidence. The only workable answer is privacy that stays composable, auditable, and integration ready.
Programmable Privacy forces a clean separation between confidentiality and integrity. Inputs can remain hidden, but outputs must be checkable. In production, the data plane must follow the same evidence-first rule, which Orochi outlines in Verifiable Data Pipeline, and zkDatabase applies by turning off-chain operations into receipts others can verify.
What is Programmable Privacy?
Programmable Privacy is privacy that supports composable application logic, not just hidden transfers. It lets applications compute on sensitive inputs, produce verifiable outputs, and still preserve confidentiality where needed.
What makes privacy “programmable” instead of just “private”?
Programmable Privacy is not a single technique. It is a contract between the application and the infrastructure: the application specifies privacy characteristics for user inputs, and the system enforces those characteristics while still producing correct results that others can verify. The SoK framing makes this explicit: programmable privacy is tied to application programmability, where developers specify privacy behavior for inputs used by application logic.
That immediately clarifies what “programmable” means in practice: policy, computation, and verifiability move together. Policy defines what must remain confidential and what can be disclosed. Computation defines the transformations and constraints applied to private inputs. Verifiability defines the public artifact that lets another party check correctness without receiving the raw inputs. If any one of those is missing, you get either secrecy without composability, or composability without confidentiality, or confidentiality without an integration story.
The boundary matters. Programmable Privacy draws a line between what stays hidden, what is proven, and what becomes public state. Hidden data can include bids, trading intents, identity attributes, underwriting variables, and proprietary signals. Proven claims can include eligibility, constraints, conservation rules, and policy compliance. Public state is the minimum commitment that anchors the result: a state commitment, a receipt, or a verification record that other systems can depend on.
What problem does Programmable Privacy solve that wallets and mixers do not?
Wallets and mixers primarily target transaction secrecy. They can hide who paid whom, or obscure linkability across transfers, but they do not solve application privacy. Protocols that run auctions, intent solvers, private credit, identity gating, and enterprise workflows need private shared state and verifiable execution, not just hidden transactions.
- Programmable Privacy supports private shared state, so multiple users can coordinate on an outcome without leaking sensitive inputs.
- Programmable Privacy enables computation on hidden inputs while still producing outputs others can verify independently.
- Programmable Privacy reduces MEV surfaces by protecting pre execution information like intents, routes, and bid details.
- Programmable Privacy supports privacy preserving compliance through selective disclosure, so verifiers see only what policy requires.
Why does Programmable Privacy matter for real protocols and institutions in 2026?
2026 adoption pressure comes from two directions: market design and regulated workflows. Programmable Privacy becomes infrastructure when it can be reasoned about, audited, and integrated reliably, instead of existing as an opaque black box.
Compliance Without Overexposure
Institutions require provable compliance, but they cannot operationalize compliance by pushing sensitive data into logs, analytics pipelines, vendors, or counterparties. That pattern creates permanent copies of sensitive records across systems that were never designed to store them, and it turns routine verification into an ever growing breach surface. Compliance teams want the opposite: minimal disclosure, deterministic review, and evidence they can replay.
Overexposure has a measurable shape. It increases linkability, raises breach liability, and makes revocation or remediation nearly impossible once data propagates through third party tooling. Programmable Privacy addresses this by shifting from disclosure to verification artifacts. Selective disclosure becomes the interface, and proofs, attestations, or receipts become the deliverable. Verifiers confirm eligibility and policy adherence without receiving raw fields, and auditors validate outcomes by rechecking evidence objects rather than requesting more data.
The integration standard is evidence. Outputs must be portable and replayable so that auditors and counterparties can validate consistently across environments. That is how privacy moves from a promise to an operational control.
Institutional-Grade RWA Tokenization
RWAs do not fail at token minting. They fail at dispute surfaces: ownership, valuation, custody, and reporting. Institutions need tokenization where critical claims are verifiable, yet sensitive records remain access controlled. Programmable Privacy supports this by proving what matters without exporting entire registries or compliance datasets.
- Prove ownership state and authorized updates without exporting registries or identity records into counterparties’ systems.
- Prove valuation inputs and transformation rules, which prevents collateral drift and pricing manipulation from becoming silent protocol risk.
- Prove custody events and settlement readiness using receipts that withstand audits and disputes across multiple parties.
- Prove investor eligibility and KYC AML constraints via selective disclosure instead of full data disclosure.
- Produce audit ready evidence that aligns issuers, custodians, and venues on one verifiable record.
Capital Markets Compatibility
Capital markets demand more than privacy. They require audit trails, standardized reporting, reconciliation, corporate actions support, and deterministic dispute resolution. That operating environment rewards systems that can produce consistent evidence under pressure: month end reporting, risk committee review, regulator inquiries, and post trade investigation.
Programmable Privacy creates policy bound verifiability, where confidentiality is preserved but outcomes remain independently checkable through verifiable execution. Real workflows are hybrid: most data and controls stay off chain, while settlement and composability anchor on chain. Compatibility means bridging that gap without breaking compliance. If privacy prevents verification, capital markets reject it. If verification requires full disclosure, institutions reject it. Programmable Privacy exists to stop that false choice.
Without privacy plus verifiable evidence objects, tokenized assets struggle to integrate into rails and operating standards that capital markets already rely on.
What is the Programmable Privacy stack?
A programmable privacy stack is a layered architecture that combines PETs, verification, availability, policy, and developer UX. The stack matters because most failures come from integration boundaries, not from a single primitive.
Which layers typically appear in a real programmable privacy stack?
Treat the stack as an integration map. Each layer answers a different question: where private compute runs, how outcomes become verifiable, how data remains available for audit, how keys and access are governed, and how developers wire policies into products. Archetype frames this shift as the emergence of private shared state powered by PETs, which only becomes practical when the system integrates cleanly across layers.
- A private compute layer executes PET based workloads where sensitive inputs must remain confidential.
- A verification layer produces proofs, attestations, or receipts that let independent parties validate outcomes.
- A data availability and storage layer ensures commitments, logs, and retrieval paths exist for audit and dispute handling.
- A key management and access control layer defines who can decrypt, who can attest, and how revocation works.
- An application integration layer exposes wallet UX, SDKs, and policy wiring so developers can ship reliable products.
Where do integration boundaries leak privacy even if the cryptography is sound?
Metadata leakage is the classic footgun. Timing, size, access patterns, retries, and correlation often leak more than the ciphertext. Many privacy designs fail because they treat the cryptography as the boundary, while the system leaks through its operational seams. That includes log and analytics leakage in off chain services, where developers add “temporary” debugging and never remove it.
Bridging and cross domain identity linkage also bites. A protocol can keep bids private but still leak user identity through address reuse, cross chain message patterns, or compliance integration shortcuts. Operational leakage is the last killer. When something fails, systems often degrade into a fallback path that reveals inputs to recover liveness. Those paths must be designed and audited up front, not bolted on after the incident.
Which PETs (Privacy-Enhancing Technologies) power Programmable Privacy?
ZKPs, MPC, FHE, and TEEs solve different parts of the privacy problem. The right choice depends on what must be hidden, what must be proven, and what trust assumptions are acceptable.
How do ZKPs enable programmable privacy without revealing inputs?
ZKPs let a prover demonstrate that a statement about hidden data is true without revealing the data itself. In Programmable Privacy systems, that usually means proving constraints: eligibility checks, invariants, correct execution of a computation, or correct state transitions. The SoK frames ZK proofs as especially useful in the independent computation phase because users can generate proofs that reference data without revealing that data to verifiers.
ZKPs fit best at verification and settlement boundaries. You can keep sensitive inputs off chain, run computation in a private domain, and then post a succinct proof that the output satisfies agreed rules. The tradeoff is cost and expressiveness. Circuits can be expensive, and developer ergonomics can be brutal without good tooling. That is why hybrid privacy stacks keep showing up in production: ZKPs handle verifiability, while other PETs handle compute or key management. (Archetype)
When does MPC outperform ZKPs for mediated computation?
MPC shines when multiple parties must jointly compute over private inputs, especially in settings where no single party can hold all secrets. The SoK highlights mediated computation as the phase where protocol operators execute non trivial logic on combined private inputs, often under extra trust assumptions or quorum assumptions.
- MPC provides strong confidentiality under multi party assumptions because no single node holds the full secret input.
- MPC introduces coordination and latency costs, which get worse under adversarial networks and multi round protocols.
- MPC increases operational complexity through key resharing, participant churn handling, and quorum management.
- MPC fits auctions, shared analytics, and joint risk scoring where multiple institutions contribute secrets and accept coordination overhead.
What is FHE good for today, and where does it still break?
FHE behaves like a privacy coprocessor model: compute on ciphertext, decrypt later, and verify carefully. It is powerful because it reduces interaction, but it is cost sensitive, and the system still needs a clean story for correctness and decryption governance. Archetype’s stack framing emphasizes that the engineering reality pushes teams into hybrids rather than single primitive designs.
- FHE enables confidential compute with minimal interaction because the server can operate directly on encrypted values.
- FHE often hits performance bottlenecks for general purpose workloads, which forces careful workload selection and batching.
- FHE requires a verification strategy for correctness claims, typically via proofs, audits, or hybrid designs.
- FHE fits constrained computations and repeated evaluation workloads where fixed function performance becomes acceptable.
What do TEEs guarantee, and what do they ask the system to trust?
TEEs can deliver practical performance and developer ergonomics because they run code in a protected enclave boundary. The cost is trust assumptions: hardware integrity and attestation validity become part of the security model. Hybrid privacy stacks often use TEEs to make other stacks more verifiable through secure remote attestation.
- TEEs enable fast private execution by isolating computation inside an enclave.
- TEEs require trust in hardware integrity and the attestation model that proves which code ran where.
- TEEs carry exposure surfaces like side channels, rollback, and supply chain risk that must be modeled explicitly.
- TEEs fit high throughput private services where auditability is achieved via attestations and external verification artifacts.
How should a protocol choose between ZK, MPC, FHE, and TEE for Programmable Privacy?
Protocols choose privacy primitives the same way they choose consensus assumptions: by writing down what must stay secret, what must be verifiable, and what cannot fail in production. ZK, MPC, FHE, and TEEs all “do privacy,” but they optimize different axes. This table compresses the real decision matrix into a quick, checkable view.
| ZK | MPC | FHE | TEE | |
|---|---|---|---|---|
| Public verifiability (anyone can verify independently) | ✅ | ❌ | ❌ | ❌ |
| Joint compute across multiple parties’ private inputs | ❌ | ✅ | ❌ | ❌ |
| Compute directly on ciphertext | ❌ | ❌ | ✅ | ❌ |
| High throughput, low latency in production | ❌ | ❌ | ❌ | ✅ |
| Requires interactive rounds between participants | ❌ | ✅ | ❌ | ❌ |
| Requires committee/participants to stay online | ❌ | ✅ | ❌ | ❌ |
| Relies on hardware trust and attestation | ❌ | ❌ | ❌ | ✅ |
| Best for sealing outcomes at settlement boundaries (on-chain verification) | ✅ | ❌ | ❌ | ❌ |
| Best fit for the mediated computation layer (off-chain compute service) | ❌ | ✅ | ✅ | ✅ |
| Liveness is the dominant production risk | ❌ | ✅ | ❌ | ✅ |
There is no universal best primitive for Programmable Privacy. ZK wins when the outcome must be publicly verifiable. MPC wins when multiple parties must compute jointly without sharing inputs. FHE wins when the server must compute on ciphertext with minimal interaction. TEEs win when latency and throughput matter most, with hardware trust accepted.
What does “verifiable execution” mean in a programmable privacy system?
Verifiable execution turns private computation into an outcome others can trust. It requires explicit artifacts: commitments, proofs or attestations, and replayable verification paths.
How do commitments and receipts make private computation auditable without revealing data?
Commitments are public anchors for private state. They let the system bind a hidden dataset, a hidden computation input, or an intermediate state to a cryptographic digest, usually a Merkle tree root or a related cryptographic accumulator. Once you have a state commitment, you can prove membership, prove correct updates, and prove correct query results without revealing the full dataset.
Receipts are minimal evidence objects that package what an integrator needs: who proved what, under what policy, and how a verifier can replay the check. They separate confidentiality from integrity. Confidentiality stays with the hidden data and the access control. Integrity rides with the receipt and the verification path. Receipt design becomes an API for auditors and integrators because it determines how easily another system can validate outcomes without bespoke trust.
How does zkDatabase make privacy claims verifiable in real systems?
Orochi’s zkDatabase is Verifiable Data Infrastructure that turns privacy and compliance claims into checkable evidence. It provides proof bound data operations and verifiable queries, so off chain data handling can be verified on chain without exporting sensitive datasets.
How does zkDatabase turn privacy claims into audit grade evidence?
zkDatabase stores data off chain while anchoring verification artifacts on chain. The architectural goal is simple: keep sensitive datasets in the environment where they are operationally manageable, but bind every critical operation to cryptographic evidence. That includes inserts, updates, and queries. Each operation updates a state commitment, often modeled as a Merkle tree style accumulator, and the system produces a proof that the operation was consistent with the committed state and the declared policy.
This is where ZKPs stop being a buzzword and start being a control. Insert proofs show that new records entered the committed dataset under valid rules. Update proofs show that changes were authorized and applied correctly, without rewriting history. Query proofs show that returned results were correct with respect to a specific state commitment, including completeness constraints when the query semantics require them. Those proofs become receipts, which verifiers and compliance teams can replay without trusting the operator’s narrative.
A verifier contract on one chain can check a proof generated off chain against a state commitment anchored on another chain, as long as the commitment and verification inputs are bridged with integrity. That pattern makes privacy claims auditable across multi chain deployments without moving the underlying datasets across domains.
How does zkDatabase support Selective Disclosure for compliance without data leakage?
zkDatabase helps by binding disclosure and verification to evidence artifacts that can be validated independently, so teams stop exporting full records just to satisfy checks.
- zkDatabase can prove eligibility or constraints without revealing raw fields or full records, which preserves confidentiality while meeting verification needs.
- zkDatabase can minimize exposure in logs and downstream systems by avoiding full dataset movement and by standardizing verification around receipts.
- zkDatabase can reduce integration burden with standardized verification paths that counterparties can replay consistently across environments.
Conclusion
Programmable Privacy survives institutional scrutiny when it produces verifiable execution outcomes without forcing data overexposure. The path is consistent: programmable cryptography gives the primitives, the Programmable Privacy stack defines the integration layers, the phase model clarifies trust boundaries, and the decision matrix selects ZKPs, MPC, FHE, or TEEs based on operational reality.
The 2026 insight is policy bound privacy receipts. Systems that standardize receipts will integrate faster than systems that only ship cryptography, because auditors and counterparties buy evidence, not slogans. zkDatabase fit this moment as Verifiable Data Infrastructure: proof bound operations, verifiable queries, and portable receipts that let privacy claims become checkable controls instead of hidden assumptions.
FAQs
Question 1: What is Programmable Privacy in blockchain systems?
Programmable Privacy is privacy that supports composable application logic, meaning a protocol can compute on sensitive inputs and still produce verifiable outputs that others can check. Unlike transaction privacy, which mainly hides sender, receiver, or amounts, programmable privacy targets application workflows like auctions, intents, identity, and credit. In practice it relies on a programmable privacy stack of PETs plus verifiable execution artifacts such as proofs, attestations, commitments, and receipts.
Question 2: Is Selective Disclosure the same as ZK privacy?
Selective disclosure and ZK privacy are related, but not the same. Selective disclosure is a data sharing pattern that limits what is revealed, while ZK proofs are a verification mechanism that can prove claims about hidden data without revealing it. Many production systems combine both: selective disclosure defines what is shared, and ZKPs prove that what is shared is sufficient and correct.
Question 3: Which is best for programmable privacy?
“Best” depends on what must be verifiable, your latency budget, and which trust assumptions are acceptable. Use ZK when you need public verification, MPC when multiple parties contribute private inputs, FHE when computation must run on ciphertext, and TEEs when production throughput is the priority and hardware trust is acceptable.
- ZK: strongest public verifiability for outcomes and constraints.
- MPC: strongest multi-input confidentiality, but requires coordination and liveness.
- FHE: compute on ciphertext with low interaction, but cost-sensitive and workload-limited.
- TEE: highest throughput and lowest latency, but depends on hardware trust and attestation.
Related toData Privacy
