Title: FAQ · EthSystems URL Source: https://original.es-internal.pages.dev/faq/ Markdown Content: --- description: Curated from direct conversations with institutions evaluating privacy on Ethereum. Each answer links deeper into the guide. title: FAQ · EthSystems image: https://original.es-internal.pages.dev/og/faq.png --- [Skip to content](#main-content) About EthSystems What is EthSystems? An engineering and research company building confidential systems for institutional Ethereum: the privacy and compliance infrastructure institutions need to put real financial activity on the network. [ About us ](/about/) Who is behind it? The team behind the Ethereum Foundation's Institutional Privacy Task Force (IPTF). [ Meet the team ](/about/) What have you actually built? A year of public, open-source work: private bonds (ZK, privacy L2s, FHE), compliance-first private stablecoin transfers, private cross-chain atomic swaps, a validium proof-of-concept, privacy-preserving identity, the Public Rails vs Private Ledgers decision framework, and the Ethereum Privacy Map. [ Writeups ](/blog/)[ Explore the map ](/explore/) Why does this matter? Every institutional use of Ethereum (tokenization, stablecoins, settlement) eventually hits the same blocker: a public ledger exposes positions, counterparties, and flows that regulated institutions cannot reveal. Confidentiality with built-in compliance is what makes those deployments viable. What do you offer institutions? Hands-on engineering engagements: privacy architecture and advisory, workshops that turn interest into concrete requirements, proof-of-concepts that de-risk decisions, and the design and build of confidential systems integrated with existing vendors and infrastructure, through to live implementation. Engagements can start small and scoped. [ Approaches ](/approaches/) What's your relationship with the Ethereum Foundation? We created and ran the Institutional Privacy Task Force at the EF, and we continue that body of work in active collaboration with EF and EF-aligned teams: coordinating the transition together, keeping the artifacts public, and collaborating on public goods, specs, and privacy work. EthSystems is its own company because commercial delivery needs a commercial structure; the collaboration continues. How do you relate to Ethlabs and Ethereum Institutional? As complementary nodes in the same network, often with overlapping supporters, and as collaborators. Ethlabs builds and grows the core protocol and platform capabilities of Ethereum. Ethereum Institutional is a neutral, non-commercial front door helping institutions understand and navigate the ecosystem. EthSystems is the specialist builder: when an institution moves from evaluating Ethereum to building on it, we're the accountable commercial counterparty that designs and delivers the confidential systems involved. Is your work open source? Yes. Our proof-of-concepts, libraries, frameworks, and the Ethereum Privacy Map are public, and we'll keep publishing. Open, verifiable work is how we earn trust. [ GitHub · map ](https://github.com/ethsystems/map) Where do you operate? Globally. Privacy basics Is Ethereum private enough for institutional use? Not by default. Ethereum is a public, transparent ledger — every transaction, balance, and counterparty relationship is visible to anyone. For institutional use, this is a non-starter: treasury operations leak competitive intelligence, counterparty exposure becomes public, and regulatory obligations around data minimization are impossible to meet. However, a growing ecosystem of privacy-preserving layers can be composed on top of Ethereum: shielded pools, privacy L2s, zero-knowledge proofs, and trusted execution environments. The question is not whether Ethereum is private, but which privacy architecture fits your requirements and what trade-offs you are accepting. [ Private Payments ](/approaches/approach-private-payments/)[ Shielded ERC-20 Transfers ](/patterns/pattern-shielding/)[ Private L2s ](/patterns/pattern-privacy-l2s/) What does "private" actually mean on a public blockchain? Privacy on Ethereum means controlling what information is visible and to whom. The spectrum ranges from anonymity (unlinkable addresses, but amounts may be visible) to full confidentiality (amounts, counterparties, and transaction patterns all hidden). Most institutional solutions sit somewhere in between, using selective disclosure to reveal specific data to authorized parties like regulators. EthSystems uses the I2I/I2U distinction to clarify threat models: in institution-to-institution contexts, both parties have symmetric trust and shared compliance burden. In institution-to-user contexts, the power dynamic is asymmetric and privacy protections must favor the weaker party. [ Regulatory disclosure ](/patterns/pattern-regulatory-disclosure-keys-proofs/)[ Viewing keys ](/patterns/pattern-user-controlled-viewing-keys/) Compliance & regulation What does MiCA say about on-chain privacy? MiCA does not prohibit on-chain privacy, but it imposes obligations that any privacy architecture must accommodate: KYC/AML for crypto-asset service providers, Travel Rule compliance for transfers, and record-keeping requirements. The key question is whether your privacy solution supports selective disclosure — the ability to reveal specific transaction data to regulators without making it publicly visible. Viewing keys and zero-knowledge proofs of compliance (proving you hold a valid KYC attestation without revealing your identity) are the primary mechanisms. The regulatory posture is: privacy is acceptable as long as compliance access exists. [ EU / MiCA ](/jurisdictions/eu-MiCA/)[ Regulatory disclosure ](/patterns/pattern-regulatory-disclosure-keys-proofs/) Can institutions use DeFi and stay compliant? It depends on the DeFi protocol and the jurisdiction. The core tension is that DeFi composability often requires public state, while institutional compliance requires controlled access. Permissioned DeFi pools (where participants are KYC'd before entry) and privacy layers with attestation-gated access are the two main patterns that reconcile these requirements. Shielded pools with attestation-gated entry can provide DeFi-like composability while maintaining a compliance perimeter. Our approaches on private payments and private trade settlement demonstrate this end-to-end. [ Private Payments ](/approaches/approach-private-payments/)[ Verifiable attestation ](/patterns/pattern-verifiable-attestation/) How do we handle Travel Rule obligations with private transfers? The Travel Rule requires originator and beneficiary information to accompany transfers above a threshold. In a shielded transfer, this information is hidden by default. The emerging pattern is to embed encrypted Travel Rule payloads within the transaction memo field, readable only by the recipient institution and, upon lawful request, by regulators holding a viewing key. Zero-knowledge proofs can attest that the payload is well-formed and that both parties satisfy KYC requirements, without revealing the payload contents on-chain. Several vendors are building Travel Rule compliance layers that integrate with shielded pool architectures. [ Regulatory disclosure ](/patterns/pattern-regulatory-disclosure-keys-proofs/)[ User-controlled viewing keys ](/patterns/pattern-user-controlled-viewing-keys/) Technology readiness Which privacy solutions are production-ready today? Privacy-preserving KYC (zero-knowledge credential verification) is the most mature — several vendors offer production-grade solutions. L1 shielded pools are production for individual use but institutional adoption is still early. Privacy L2s are approaching mainnet but not yet production for institutional workloads. FHE-based solutions are at the proof-of-concept stage. The honest answer: no single privacy architecture is fully production-ready for all institutional use cases today. The practical path is to pick the approach whose maturity matches your deployment timeline and risk tolerance. [ Private Identity ](/approaches/approach-private-identity/)[ Railgun ](/vendors/railgun/)[ Aztec ](/vendors/aztec/) How do viewing keys work for regulatory access? Viewing keys are cryptographic keys that grant read-only access to shielded transaction data without granting transfer authority. A user or institution holds a spending key (for moving funds) and a separate viewing key (for disclosure). The viewing key can be shared with a regulator or auditor, who can then decrypt and verify specific transactions without seeing anything else in the pool. The key properties: viewing keys are scoped (can be time-bounded or limited to specific accounts), they are read-only (no transfer authority), and they can be revoked. Dual-key architecture works in both L1 shielded pools and L2 privacy systems. [ User-controlled viewing keys ](/patterns/pattern-user-controlled-viewing-keys/)[ Regulatory disclosure ](/patterns/pattern-regulatory-disclosure-keys-proofs/) UTXO vs account model: which is better for privacy? UTXO-based privacy (Railgun, Zcash-style) provides stronger unlinkability by default — each transaction consumes and creates new notes, breaking the connection between sender and receiver. Account-based privacy (Aztec, FHE-based) is more familiar to Ethereum developers and supports richer programmability, but requires more careful design to prevent linkability. For institutional payments, UTXO models are simpler and better understood. For complex smart contract interactions (DeFi, derivatives), account-based privacy L2s offer more flexibility. The right choice depends on your use case rather than any absolute technical superiority. [ Private Payments ](/approaches/approach-private-payments/) × ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://ethsystems.org/#organization","name":"EthSystems","url":"https://ethsystems.org/","logo":"https://ethsystems.org/icon-maskable.png","sameAs":["https://x.com/eth_systems","https://www.linkedin.com/company/ethsystems/","https://github.com/ethsystems"]},{"@type":"WebSite","@id":"https://ethsystems.org/#website","url":"https://ethsystems.org/","name":"EthSystems","publisher":{"@id":"https://ethsystems.org/#organization"}}]} {"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"What is EthSystems?","acceptedAnswer":{"@type":"Answer","text":"An engineering and research company building confidential systems for institutional Ethereum: the privacy and compliance infrastructure institutions need to put real financial activity on the network."}},{"@type":"Question","name":"Who is behind it?","acceptedAnswer":{"@type":"Answer","text":"The team behind the Ethereum Foundation's Institutional Privacy Task Force (IPTF)."}},{"@type":"Question","name":"What have you actually built?","acceptedAnswer":{"@type":"Answer","text":"A year of public, open-source work: private bonds (ZK, privacy L2s, FHE), compliance-first private stablecoin transfers, private cross-chain atomic swaps, a validium proof-of-concept, privacy-preserving identity, the Public Rails vs Private Ledgers decision framework, and the Ethereum Privacy Map."}},{"@type":"Question","name":"Why does this matter?","acceptedAnswer":{"@type":"Answer","text":"Every institutional use of Ethereum (tokenization, stablecoins, settlement) eventually hits the same blocker: a public ledger exposes positions, counterparties, and flows that regulated institutions cannot reveal. Confidentiality with built-in compliance is what makes those deployments viable."}},{"@type":"Question","name":"What do you offer institutions?","acceptedAnswer":{"@type":"Answer","text":"Hands-on engineering engagements: privacy architecture and advisory, workshops that turn interest into concrete requirements, proof-of-concepts that de-risk decisions, and the design and build of confidential systems integrated with existing vendors and infrastructure, through to live implementation. Engagements can start small and scoped."}},{"@type":"Question","name":"What's your relationship with the Ethereum Foundation?","acceptedAnswer":{"@type":"Answer","text":"We created and ran the Institutional Privacy Task Force at the EF, and we continue that body of work in active collaboration with EF and EF-aligned teams: coordinating the transition together, keeping the artifacts public, and collaborating on public goods, specs, and privacy work. EthSystems is its own company because commercial delivery needs a commercial structure; the collaboration continues."}},{"@type":"Question","name":"How do you relate to Ethlabs and Ethereum Institutional?","acceptedAnswer":{"@type":"Answer","text":"As complementary nodes in the same network, often with overlapping supporters, and as collaborators. Ethlabs builds and grows the core protocol and platform capabilities of Ethereum. Ethereum Institutional is a neutral, non-commercial front door helping institutions understand and navigate the ecosystem. EthSystems is the specialist builder: when an institution moves from evaluating Ethereum to building on it, we're the accountable commercial counterparty that designs and delivers the confidential systems involved."}},{"@type":"Question","name":"Is your work open source?","acceptedAnswer":{"@type":"Answer","text":"Yes. Our proof-of-concepts, libraries, frameworks, and the Ethereum Privacy Map are public, and we'll keep publishing. Open, verifiable work is how we earn trust."}},{"@type":"Question","name":"Where do you operate?","acceptedAnswer":{"@type":"Answer","text":"Globally."}},{"@type":"Question","name":"Is Ethereum private enough for institutional use?","acceptedAnswer":{"@type":"Answer","text":"Not by default. Ethereum is a public, transparent ledger — every transaction, balance, and counterparty relationship is visible to anyone. For institutional use, this is a non-starter: treasury operations leak competitive intelligence, counterparty exposure becomes public, and regulatory obligations around data minimization are impossible to meet. However, a growing ecosystem of privacy-preserving layers can be composed on top of Ethereum: shielded pools, privacy L2s, zero-knowledge proofs, and trusted execution environments. The question is not whether Ethereum is private, but which privacy architecture fits your requirements and what trade-offs you are accepting."}},{"@type":"Question","name":"What does \"private\" actually mean on a public blockchain?","acceptedAnswer":{"@type":"Answer","text":"Privacy on Ethereum means controlling what information is visible and to whom. The spectrum ranges from anonymity (unlinkable addresses, but amounts may be visible) to full confidentiality (amounts, counterparties, and transaction patterns all hidden). Most institutional solutions sit somewhere in between, using selective disclosure to reveal specific data to authorized parties like regulators. EthSystems uses the I2I/I2U distinction to clarify threat models: in institution-to-institution contexts, both parties have symmetric trust and shared compliance burden. In institution-to-user contexts, the power dynamic is asymmetric and privacy protections must favor the weaker party."}},{"@type":"Question","name":"What does MiCA say about on-chain privacy?","acceptedAnswer":{"@type":"Answer","text":"MiCA does not prohibit on-chain privacy, but it imposes obligations that any privacy architecture must accommodate: KYC/AML for crypto-asset service providers, Travel Rule compliance for transfers, and record-keeping requirements. The key question is whether your privacy solution supports selective disclosure — the ability to reveal specific transaction data to regulators without making it publicly visible. Viewing keys and zero-knowledge proofs of compliance (proving you hold a valid KYC attestation without revealing your identity) are the primary mechanisms. The regulatory posture is: privacy is acceptable as long as compliance access exists."}},{"@type":"Question","name":"Can institutions use DeFi and stay compliant?","acceptedAnswer":{"@type":"Answer","text":"It depends on the DeFi protocol and the jurisdiction. The core tension is that DeFi composability often requires public state, while institutional compliance requires controlled access. Permissioned DeFi pools (where participants are KYC'd before entry) and privacy layers with attestation-gated access are the two main patterns that reconcile these requirements. Shielded pools with attestation-gated entry can provide DeFi-like composability while maintaining a compliance perimeter. Our approaches on private payments and private trade settlement demonstrate this end-to-end."}},{"@type":"Question","name":"How do we handle Travel Rule obligations with private transfers?","acceptedAnswer":{"@type":"Answer","text":"The Travel Rule requires originator and beneficiary information to accompany transfers above a threshold. In a shielded transfer, this information is hidden by default. The emerging pattern is to embed encrypted Travel Rule payloads within the transaction memo field, readable only by the recipient institution and, upon lawful request, by regulators holding a viewing key. Zero-knowledge proofs can attest that the payload is well-formed and that both parties satisfy KYC requirements, without revealing the payload contents on-chain. Several vendors are building Travel Rule compliance layers that integrate with shielded pool architectures."}},{"@type":"Question","name":"Which privacy solutions are production-ready today?","acceptedAnswer":{"@type":"Answer","text":"Privacy-preserving KYC (zero-knowledge credential verification) is the most mature — several vendors offer production-grade solutions. L1 shielded pools are production for individual use but institutional adoption is still early. Privacy L2s are approaching mainnet but not yet production for institutional workloads. FHE-based solutions are at the proof-of-concept stage. The honest answer: no single privacy architecture is fully production-ready for all institutional use cases today. The practical path is to pick the approach whose maturity matches your deployment timeline and risk tolerance."}},{"@type":"Question","name":"How do viewing keys work for regulatory access?","acceptedAnswer":{"@type":"Answer","text":"Viewing keys are cryptographic keys that grant read-only access to shielded transaction data without granting transfer authority. A user or institution holds a spending key (for moving funds) and a separate viewing key (for disclosure). The viewing key can be shared with a regulator or auditor, who can then decrypt and verify specific transactions without seeing anything else in the pool. The key properties: viewing keys are scoped (can be time-bounded or limited to specific accounts), they are read-only (no transfer authority), and they can be revoked. Dual-key architecture works in both L1 shielded pools and L2 privacy systems."}},{"@type":"Question","name":"UTXO vs account model: which is better for privacy?","acceptedAnswer":{"@type":"Answer","text":"UTXO-based privacy (Railgun, Zcash-style) provides stronger unlinkability by default — each transaction consumes and creates new notes, breaking the connection between sender and receiver. Account-based privacy (Aztec, FHE-based) is more familiar to Ethereum developers and supports richer programmability, but requires more careful design to prevent linkability. For institutional payments, UTXO models are simpler and better understood. For complex smart contract interactions (DeFi, derivatives), account-based privacy L2s offer more flexibility. The right choice depends on your use case rather than any absolute technical superiority."}}]} ```