Paladin - Modular System for Programmable Privacy on EVM chains

Fits with patterns (names only)

Not a substitute for

  • Privacy L2 or App-chain
  • Identity and Attestations

Architecture

  • Sidecar next to any standard EVM node; Paladin acts as a privacy-preserving transaction manager for Ethereum (no client fork).
  • Secure channels between Paladin nodes for selective disclosure; data at rest remains private, data in-flight is encrypted end-to-end.
  • Privacy-preserving smart contracts split across two parts:
    • Base EVM smart contract on the unmodified chain (ordering/finality, double-spend, proof validation, signature validation).
    • Off-chain Paladin runtime that manages private state, proofs/endorsements, and coordination.
  • Provides similar function to legacy privacy-group managers (e.g., Tessera) with additional interoperability and atomic composition across domains.
  • Base EVM ledger is the single source of truth; all domains interoperate atomically on one ledger; state stored in masked form to preserve confidentiality and anonymity.
  • Transaction manager coordinates assembly, submission, and confirmation to:
    • Public EVM contracts
    • UTXO-based privacy preserving tokens
    • FHE based confidential tokens (future plans)
    • Private EVM contracts in privacy groups
  • Key management integrates with enterprise HSM/SSM; supports native Ethereum signing, EIP-712 endorsements, ZKP proof generation, as well as FHE wallet-side cryptography in future plans.
  • Programming model includes plug points for:
    • Wallet functions (coin/state indexing and selection for submission)
    • Endorsement coordination and signature collection with flexible endorsement policies
    • Distributed sequencer for transaction coordination
    • Proof generation (ZK proofs, notary certificates, and others)
    • High-performance code modules in Java and WebAssembly

Privacy domains are implementations of a plug-point for the on-chain logic (pure on-chain EVM), and the app-layer logic (proof systems, merkle tree management, private EVM execution, endorsement/attestation coordination), that are the common components of every privacy-preserving smart contract in the EVM ecosystem.

Paladin aims to be open and flexible enough that any privacy system could plug in - as any transparent ERC-20 can plug into a wallet today.

Hardened reference implementations are provided out of the box as follows:

  • Zeto (ZK UTXO tokens)
    • Onchain commitments hide ownership/amounts/history of the UTXOs.
    • Enforces mass conservation and other spending policies (KYC, auditability, etc.) via ZK proofs.
    • Currently implemented with zkSNARKs in Circom based circuits, using groth16 by default.
    • Paladin runtime includes a token indexer, UTXO selector, and proof generator.
    • Optional ERC20 bridge via deposit/withdraw.
    • Lock/unlock flows prevent proof theft in multi-leg flows (e.g., DvP).
  • Noto (notarized UTXO tokens)
    • Onchain commitments hide ownership/amounts/history of the UTXOs.
    • Enforces mass conservation and other spending policies via notary certificates (EIP-712 signatures).
    • Notary/issuer governs confidential UTXO state; can be backed by EOAs or privacy groups.
    • Supports basic and hooks notary modes; private and public ABIs for mint/transfer/burn and lock/unlock flows; approveTransfer and delegateLock enable delegated execution.
  • Pente (private EVM execution in privacy groups)
    • Each privacy group is a unique contract that maintains its own private world state as UTXO commitments onchain.
    • Exact transitions are pre-verified off-chain and endorsed; on-chain verification uses threshold/EIP-712 signatures with no base EVM changes.
    • Paladin runs ephemeral Besu EVMs in-process for pre-execution; privacy groups can interoperate atomically with token domains.

Enterprise demand and use cases

  • Segments: asset issuers, asset holders and network builders needing custody/compliance.
  • Common implementations: cash-like tokens plus tradeable assets; PvP; DvP; private negotiation of programmable transaction rules.
  • Buyer profile: typically VP or Head of Digital Assets; privacy repeatedly cited as a key blocker for public-chain adoption.

Technical details

  • Data transports and registry
    • Two identity types:
      • Account signing identities (long-lived; may be secp256k1, BabyJubJub).
      • Runtime routing identities (for data-in-flight; transport certs/addresses/hosts/topics).
    • Registry plugin resolves routing identifiers to transport details; address book maps friendly names to accounts.
    • Transport principles: asynchronous message transfer, idempotent requests with retries, end-to-end encryption even via hubs/buses.
  • Approval-based atomic transactions (DvP/PvP)
    • Pre-approval/setup: parties reach a private state root; prepare token transfers.
    • Approval/prepare: swap contract deployed; each domain pre-approves (privacy group endorsement, notary approval, ZK proof).
    • Execution/commit: call execute() on the swap contract; all sub-transactions commit or revert atomically.
    • Post-execution: domains remain independent; provenance is hidden except to entitled parties.

Strengths

  • Atomic composition across privacy domains without modifying EVM clients.
  • Multiple privacy models under one surface (ZK UTXO, notary-backed UTXO, group-private EVM).
  • Enterprise operations alignment: HSM/SSM integration, registry/addressing, predictable governance boundaries.

Risks and open questions

  • Centralization and custodial key management trade-offs in some deployments.
  • Operator access to client data in certain operating modes (trust boundary).
  • Scope and roadmap for interop with public DeFi and external venues.

Links