What this proposes: A system contract for shielded transfers and withdrawals of ETH and ERC-20 tokens — single canonical note tree, hard-fork-only upgrades, no admin keys. Deposits are public; transfers and withdrawals are authorized by signing standard EIP-1559 type-2 transactions on reserved chain IDs, which are converted into ZK proofs and submitted on-chain (locally or via a Privacy RPC). A Privacy RPC presents the intent chain as a standard EVM network, so wallets see a normal send flow — no custom signing UI required. A companion proof verification precompile with fork-defined circuit IDs allows new auth methods and proof systems to be added per hard fork.
Why enshrine: App-level pools face a dilemma: upgradeable → governance risk; immutable → ossification risk. A system contract resolves both — code is upgraded through the same social consensus process as any protocol change, so when cryptographic assumptions weaken, the pool migrates. The anonymity set is canonical from day one rather than bootstrapped from zero across competing deployments. Ethereum defines valid public transactions; a canonical definition of valid private transactions is a natural complement. The failure surface is bounded: a ZK soundness bug in a system contract exposes pool-held funds, not the consensus layer.
Key design choices we’d like feedback on:
-
Intent format: Users sign standard type-2 transactions on reserved chain IDs derived deterministically from the execution chain ID. Works with every existing wallet without modification, but RLP + keccak inside the circuit is expensive. Worth the circuit cost, or is there a cleaner authorization primitive that doesn’t require wallet changes?
-
Label-based proof of innocence: Notes carry a lineage label traceable to the original deposit. Counterparties can require ancestry proofs; the base contract doesn’t enforce compliance. Is there a case where opt-in PoI at the counterparty level is insufficient that we haven’t considered?
-
Issuer viewing keys: Permissioned-asset issuers register a viewing key tied to their token address; the circuit automatically encrypts an additional ciphertext for their token only. Is scoped visibility — issuers can see transfers of their own token, nothing else — sufficient for the issuer use cases people actually have?
-
System contract vs. precompile-only: A ZK verification precompile alone makes on-chain operations gas-feasible but doesn’t resolve governance, ossification, or anonymity-set fragmentation for the pool contract itself. The pool state must live somewhere with an upgrade model. Do people see a precompile-only path that actually resolves these?
-
State growth: Each pool transaction writes ~4 permanent storage slots (nullifiers are not pruneable). This is standard for privacy pools, but enshrinement makes it protocol-level state. Acceptable for v0, or should an accumulator-based nullifier scheme be a prerequisite?
Working implementation: Server-side proving demo at private.facet.org — a bridge to full wallet integration while wallets adopt the intent standard natively. Source: github.com/0xFacet/facet-private-demo. An article further describing the motivation is available here.
Full spec: