Private credit note, partial sale
- Date
- 14 Oct 2026, 10:42 ET
- Instrument
- Seller
- Buyer
- Nominal
- Price
Privacy on Ethereum rests on some of the most advanced mathematics in use today. Using it well starts with something simpler: saying clearly who should see what.
I spent four years at a cryptography research startup, where I oversaw projects that were among the first to generate zero-knowledge proofs directly in a web browser, using WebAssembly. I’ve worked in technology my whole career. Even so, the first time someone explained zero-knowledge proofs to me, I didn’t get it. It took hundreds of hours reading about KZG commitments, talking it through with AI assistants and checking my understanding with cryptographer friends before a different mental model made it click. The good news is that you don’t have to do the same.
When science is this hard to explain, it starts to feel like magic. It doesn’t have to stay that way. Twenty years ago, encrypting an email or proving that a website was really yours sounded like specialist work. Today people ask for a secure connection and look for the padlock. Nobody needs to understand the cryptography underneath.
Privacy on Ethereum should get there too. An asset manager shouldn’t have to master ZK, FHE, MPC or TEE. What matters is being able to state your requirements in your own language, and to know what the technology can deliver. This primer offers one shared way to do that, so we all work from the same picture.
Redwan Meslem, Executive Director, Enterprise Ethereum Alliance
See the ideas in actionZooko Wilcox, founder of Zcash: What are zero-knowledge proofs? And why do they matter beyond crypto?
“Private” can mean three different things. Each one is a separate choice.
Amounts, prices, terms, and the logic behind them. The parties are known; the details aren’t.
The identities behind a transaction, and whether two transactions link to the same party.
The date and the fact of a trade can tip off a market on their own.
Institutions usually need confidentiality, with known counterparties. Anonymity is what worries compliance teams.
One transfer of a private credit note, and the copy each party receives. Pick a party.
Each party receives its own copy of this record.
Approves the transfer by checking the stamps. It never learns who traded or for how much.
Compliance doesn’t need everything in the clear. The bank and the regulator work from stamps, and the regulator holds a sealed envelope.
The question is the same in every use case: what goes behind a black bar, and for whom.
Cases from the EthSystems use-case library, where each one lists what’s hidden, what’s public, and what regulators can access.
The copies can look the same under every technology. What changes is behind the page: who else ends up reading the full record, beyond the parties entitled to it.
The original sits in a records room. A clerk reads it and makes each person’s copy by hand, with a black marker.
A small group of members each keep the full original in their own binder. Everyone outside gets a receipt with a fingerprint of the page.
The original never leaves its owner’s desk. A machine reads it and prints a stamp: “this meets the rules.” Anyone can check the stamp. No bars were drawn, because nothing was shown.
Imagine numbers in invisible ink that clerks can still update, for example subtracting a payment, without ever seeing them. Only a special lamp makes the ink visible, and a panel of trustees controls the lamp.
The original is split across clear sheets, one per trustee. Each sheet alone looks like static. Stack enough of them and the text appears. Trustees can also act together, for example to sign, without stacking.
The original goes into a windowless room inside someone else’s building. A machine inside reads it and passes copies and stamps out through a slot. A manufacturer’s seal certifies which machine is inside.
Real products often combine these. An FHE network may split its decryption key using MPC; a private chain may add zero-knowledge proofs to access controls.
Ask every provider who else reads the full record. Then check the answer against the copies you decided on.
The EEA Privacy Working Group report on these technologies.
Related EEA article: EY, Consensys and Fellow EEA Members Map Enterprise Privacy on Ethereum
For every party: text, black bar, stamp, or sealed envelope.
An operator, other group members, or nobody. That is who you trust.
Who authorizes it, how it’s scoped, and whether every opening is logged.
Then ask for an integration story where all three answers match yours. A product claim alone doesn’t show fit.
Ethereum’s developers are building privacy closer to the base layer.
A shielded pool built into Ethereum. In review; not included in the Hegotá upgrade.
Private writes, reads, and proving, end to end.
How institutions apply privacy, case by case.
Which Ethereum proposals matter for institutions.
Status as of October 2026: EIP-8182 is listed as declined for inclusion in the Hegotá upgrade meta EIP. Proposals change as they move through review; check the source before relying on a date.
Briefings, workshops, and forums that help institutions track what’s changing on Ethereum, privacy included, and what it means for them.
It does not have to. Confidentiality hides transaction details from the market, not from the parties that must check them. In the example above, the buyer’s compliance team reads its own customer’s activity, and the bank and regulator confirm sanctions and eligibility through stamps. Anonymity, where the parties themselves are hidden, is what raises AML concerns. Whether a specific system meets a given regime depends on its design and the rules that apply.
That depends on the system. In the example above, the regulator sees today that the rules were met and can open the full record later, with authority, through a viewing key or an equivalent mechanism. Ask each provider who can open that record, how access is authorized and scoped, and whether every opening is logged.
They differ in who else can read the full record and what you trust. With zero-knowledge proofs, data stays with its owner and only a proof is shared; you trust that the rules being proved are written correctly. With FHE, a system computes on encrypted data; you trust that key holders won’t decrypt together without permission. With MPC, data or keys are split across parties; you trust that not enough of them collude. With a TEE, data is processed inside protected hardware; you trust the hardware and its manufacturer. Products often combine them.
EIP-8182 proposes private ETH and ERC-20 transfers on Ethereum through a shielded-pool system contract. According to the proposal, it adds no new precompile, opcode or transaction type beyond installing that contract at a network upgrade. As of October 2026 it is in review, and the Hegotá upgrade meta EIP lists it as declined for inclusion in that upgrade. It is a proposal, not a deployed feature.
A primer from the Enterprise Ethereum Alliance. Parties, copies, and names in the example are illustrative. The metaphors simplify: each technology’s real guarantees depend on its design and configuration. This page is not legal advice.