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

Transaction flow

1. Commit the policy. Build a Merkle tree from the private signer set and threshold, then derive the public state root.
2. Deploy the account. Generate a state-validity proof and let the factory deploy the proxy after verification.
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. ERC-1271 validation succeeds after the ERC-8039 verifier returns its magic value.

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.

The interface

ERC-8039 gives accounts and modules one stable contract boundary for different proving systems. Authentication, authorization, recovery, and policy logic can evolve without coupling the account to a specific verifier implementation.

interface IERC8039 {
  function verifyProof(
    bytes calldata publicSignals,
    bytes calldata proof
  ) external view returns (bytes4 magicValue);

  function getProofType() external view returns (bytes32);
  function metadata() external view returns (string memory);
}

What it enables

Verification contract

1. The account defines the expected proof type and public-signal format.
2. The caller submits public signals and opaque proof bytes.
3. The ERC-8039 verifier validates the proof using its chosen backend.
4. A valid call returns the standard magic value; every other result fails closed.

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.

Production checklist