Overview

The account stores one public commitment, the stateRoot. Authorized signers approve a transaction off-chain, then a zero-knowledge proof demonstrates that enough valid signatures came from members of the committed signer set. On-chain contracts learn that the policy passed and nothing about the identities behind it.

Core architecture

Private policy
signers + threshold → stateRoot → state-validation proof

Transaction authorization
M signatures + transaction hash → transaction proof
→ ERC-8039 verifier → smart-account integration → execution

Transaction flow

1. Commit the policy. Build a Merkle tree from the private signer set and threshold, then derive the public state root.
2. Register the commitment. The chosen smart-account integration stores or references the state root and ERC-8039 verifier.
3. Collect approvals. The required signers sign the transaction hash off-chain.
4. Prove authorization. The Noir circuit verifies ECDSA signatures, membership, uniqueness, and the threshold.
5. Execute. Submit the transaction and proof through the relevant Safe, Nexus, or compatible account flow. Execution continues after ERC-8039 verification succeeds.

State commitment

stateRoot = MerkleRoot([
  signersMerkleRoot,
  Poseidon(threshold)
])

The transaction circuit exposes only the transaction hash and state root as public inputs. Signers, signatures, membership paths, and threshold remain private witnesses.

Install and test

git clone https://github.com/MicrochainLabs/microchain-zk-signers.git
cd microchain-zk-signers
forge install
pnpm install

cd noir && nargo compile && cd ..
npx hardhat compile
npx hardhat test

Prerequisites: Node.js 18 or later, pnpm, Foundry, Nargo, and the Barretenberg bb CLI.

Why it exists

Conventional smart-account authorization publishes signer addresses, approval thresholds, and policy rules. The kit moves that logic into zero-knowledge circuits. The account stores a cryptographic commitment and verifies that a private authorization rule passed.

Primitive library

Repository structure

zk-smart-account-kit/
├── Nargo.toml
├── lib/
│   ├── zk_signer/
│   ├── zk_labels/
│   ├── zk_multisig/
│   └── zk_scope/
└── noir/

Integration model

1. Choose a primitive and construct its private state tree.
2. Commit the resulting root to the smart account or module.
3. Build circuit inputs and generate the proof off-chain.
4. Encode public signals and proof bytes for the account call.
5. Verify through an ERC-8039-compatible verifier before execution.

Why a standard is needed

Every ZK verifier contract on Ethereum currently exposes its own ABI. Groth16 expects one arrangement of curve points and public inputs. PLONK wrappers may accept receipts. UltraHonk has another layout. Proof encoding, failure behavior, and domain separation vary across implementations. Wallets and protocols must write custom integration logic for each verifier.

ERC-8039 creates one contract boundary across those systems. The parallel is ERC-1271: before its standard signature interface, each smart contract verified signatures differently. isValidSignature(bytes32,bytes) gave wallets and protocols one method they could rely on. ERC-8039 applies the same idea to zero-knowledge proofs.

The interface

Each ERC-8039 verifier is specialized for one proof system and one circuit. The surrounding smart account, protocol, or tool calls the same three functions regardless of the verifier behind them.

interface IERC8039 {
  // Verify a ZK proof. Must not revert on failure.
  function verifyProof(
    bytes calldata publicInputs,
    bytes calldata proof
  ) external view returns (bytes4 magicValue);

  // Machine-readable proof system identifier.
  function getProofType() external view returns (bytes32);

  // Human-readable description of the statement.
  function metadata() external view returns (string memory);
}

Magic-value verification

The return-value pattern mirrors ERC-1271. Successful verification returns the selector of verifyProof(bytes,bytes). An invalid proof returns zero. Verification failure is expressed as a return value, allowing callers to check proofs inline without exception-handling overhead.

Integrations should compare the returned bytes directly with the ERC-8039 magic value. Any other value is a failed verification.

Proof type and statement metadata

getProofType() describes how a proof is verified. It returns a machine-readable hash that routers, wallets, registries, and developer tooling can use to identify the proving stack.

keccak256("honk-barretenberg")
keccak256("groth16-circom")
keccak256("groth16-gnark")
keccak256("plonk-circom")
keccak256("plonk-halo2_pse")
keccak256("ultraplonk-barretenberg")
keccak256("sp1")
keccak256("risc0")

The standard defines nine proof-system identifiers and can accommodate additional identifiers as implementations evolve.

metadata() describes what the circuit proves. It gives auditors, interfaces, and operators readable context about the statement and its version.

"Private signers v1.3.0 - Private multisig wallet"
"Age verification v2.1.0 - Prove age > 18"
"DAO voting v1.0.0 - Token holder eligibility"
"Private transfer v2.5.0 - Shielded USDC transactions"

Generic public inputs

publicInputs is deliberately typed as bytes. Proof systems and circuits use different encodings, including arrays of field elements, integers, fixed-width values, and structured data. Each verifier adapter decodes the bytes into the format required by its underlying verifier.

This keeps the ERC interface independent of any proof system. An account can replace a Honk verifier with a Groth16, SP1, or RISC Zero verifier while preserving the account-facing call pattern. The verifier contract remains responsible for decoding its public inputs and invoking the underlying proof implementation.

Replay protection

A valid ZK proof can be replayed whenever its statement is not bound to a specific context. ERC-8039 leaves replay prevention to the circuit and its public signals because the verifier interface cannot infer the application’s security domain.

Context values should be included in publicInputs and consumed by the circuit itself:

Replay protection belongs inside the proven statement. The circuit must cryptographically enforce the context, rather than relying on metadata or off-chain conventions.

Inside the Microchain stack

zk-smart-account-kit targets ERC-8039 across its circuits. Verifiers for zk_multi_sig_ecdsa, zk_label_binding, and zk_scope_validation implement the same interface. Safe contract-owner adapters and ERC-7579 validator modules delegate proof checks to those verifier contracts.

1. A circuit defines the private witnesses and public statement.
2. Its ERC-8039 verifier decodes the public inputs and verifies the proof.
3. The Safe or ERC-7579 adapter checks the returned magic value.
4. The account’s authorization logic continues without depending on the underlying proof system.

smart account logic
      ↓ same IERC8039 call
ERC-8039 verifier adapter
      ↓ system-specific decoding
Honk / Groth16 / PLONK / SP1 / RISC Zero

Changing the proof system means changing the verifier contract. The smart-account integration and its authorization flow can remain unchanged.

Status and authorship

ERC-8039 is under review in the Ethereum ERCs repository as PR #1238. It is authored by Walid Khemiri and Ismail Amara, and emerged from the verification requirements of Microchain Labs’ private smart-account work.

Integration path

1. Define private state. Build the signer, label, multisig, or scope tree locally and retain the witnesses off-chain.
2. Install the commitment. Configure the account module with the root and its ERC-8039 verifier address.
3. Prepare the operation. Bind the proof to the account, chain, nonce, and transaction or user-operation hash.
4. Generate the proof. Run Noir and Barretenberg in the client or a trusted proving environment.
5. Encode validation data. Package the public signals and proof bytes in the format expected by the module.
6. Verify and execute. The account calls verifyProof, checks the magic value, and continues after validation.

Trust boundary

private witnesses
      ↓
client / prover ── proof + signals ──▶ smart account
                                           ↓
                                    ERC-8039 verifier
                                           ↓
                                       execution

The verifier should bind every proof to its intended account context. Domain separation, chain ID, nonce, and operation hash prevent replay in another account or transaction.

Safe integration

Safe integrates the protocol as an ERC-1271 contract owner. Each private signer group receives a ZKMultiSigEcdsaProxy. The proxy holds that group’s stateRoot and ERC-8039 verifier address, while the shared ZKMultiSigEcdsaSingleton contains the signature-validation logic. This keeps deployments small and allows many private signer groups to reuse one implementation.

Safe wallet
  └─ owner: ZKMultiSigEcdsaProxy
       ├─ stateRoot
       ├─ ERC-8039 verifier address
       └─ delegatecall → ZKMultiSigEcdsaSingleton
                            └─ verifyProof(stateRoot, safeTxHash, proof)

Nested thresholds

A Safe can combine public and private authorization layers. For example, a 2-of-3 Safe may have one EOA owner, one proxy representing a private 3-of-5 group, and another proxy representing a private 2-of-3 group. Safe sees three owner addresses; the members and internal thresholds behind the two proxies stay hidden.

Deployment flow

1. Deploy the factory, shared singleton, transaction verifier, and private-state verifier.
2. Compute the private signer commitment and generate the state-validation proof.
3. Call the factory to create a proxy containing the state root and verifier address.
4. Add the proxy address as a Safe owner and set the Safe-level threshold.
5. For each transaction, generate the ZK authorization proof and attach it as an ERC-1271 contract signature.

The proxy is public. The people represented by it, their number, their internal threshold, and the individual approvals remain private.

Nexus integration

Nexus uses the same private M-of-N circuit through a native ERC-7579 validator module. The ZKMultiSigValidator is installed on the Nexus smart account with an account-specific state root and ERC-8039 verifier. It validates ERC-4337 UserOperations and ERC-1271 signatures while working alongside other Nexus validators, executors, and hooks.

Nexus smart account · ERC-7579 / ERC-4337
  ├─ default validator
  └─ ZKMultiSigValidator
       ├─ stateRoot per account
       ├─ ERC-8039 verifier address
       ├─ validateUserOp()
       └─ isValidSignatureWithSender()

Deployment options

Execution flow

1. Define private signers and threshold, then compute the state root off-chain.
2. Install the validator or deploy a Nexus account through the factory.
3. Encode the ERC-7579 execution and build the UserOperation.
4. Collect the private approvals and generate a proof over the UserOperation hash.
5. Select the ZK validator in the nonce, place the proof in the signature field, and submit through the ERC-4337 flow.

Signer rotation changes the committed state used by the validator. The Nexus account address and the reusable verification module remain in place.