Research · private account logic
Our ZK Statements for Smart Accounts
Self-custody should give people control over their assets without requiring them to become experts in addresses, calldata, and contract permissions.
Why We Are Building ZK Statements
At Microchain Labs, our work on ZK statements begins with that tension. We want accounts that are easier to operate, reveal less sensitive information, and enforce meaningful limits on what can happen to the assets they control.
The previous section introduced ZK statements and the infrastructure needed to use them. Here, we explain why we are building our own statements, the problems each addresses, and how they fit together.
Self-Custody Beyond Key Ownership
Self-custody means retaining authority over your account rather than depending on a custodian to authorize actions for you. That authority may belong to one person, several participants, or an account governed by explicit rules.
But holding the keys is only part of the experience. Using on-chain protocols means deciding which contracts to trust, what permissions to grant, and whether a proposed transaction does what you intend.
The EVM executes addresses, function selectors, and encoded parameters. People think in terms of colleagues, recipients, applications, and actions: pay a supplier, approve an expense, deposit into a lending protocol.
That translation creates both a usability problem and a security problem. A transaction can be correctly signed and still be the wrong transaction.
Where the Experience Breaks Down
Common workflows ask users to make high-stakes decisions with limited context:
- Recognize a recipient or protocol from a long hexadecimal address.
- Interpret unfamiliar approval requests or transaction data.
- Distinguish the action displayed by an interface from the action actually submitted.
- Coordinate several signers while maintaining backups and operational continuity.
- Grant broad permissions because configuring narrower ones is difficult.
Blind signing, misleading interfaces, address substitution, excessive approvals, and compromised keys exploit different parts of this experience. Public signer configurations can also expose relationships and make account operators easier to identify.
These are not problems that better wording or additional confirmation screens can solve alone. A compromised interface can display reassuring text. Multiple people can approve the same misleading request. A valid signature establishes authorization under the account's rules, not that the signer understood every consequence.
Our direction is to combine understandable interactions with constraints the account itself enforces. ZK lets us prove those constraints over private configuration without publishing every signer, label, or policy parameter.
ZK is not necessary for every form of account restriction. Its contribution here is making authorization and policy checks compatible with private state.
1. ZK MultiSig: Shared Control, Private Signers
Our multisignature work started with a practical question: can an account require collective approval without publishing its ownership structure?
Microchain's ZK MultiSig approach uses zero-knowledge proofs to validate threshold signatures for an Ethereum smart account. Instead of storing an explicit signer list on-chain, the account stores a cryptographic commitment to its private configuration.
The Statement
At least the required number of distinct authorized signers signed this transaction hash, and the signer set and threshold match the account's committed configuration.
The signer set is represented by a Merkle root. In the documented construction, the account's public state root commits to both that signer root and the threshold. The proof checks signatures, membership, and distinctness without publishing the full set or identifying the participating signers.
Why It Matters
A treasury can require several approvals without advertising its entire signing committee through the account's verification data. Shared control reduces dependence on one key; privacy reduces what the authorization mechanism reveals about the people behind it.
For the user experience, the objective is a familiar approval workflow. Participants approve an operation, while the proof carries the evidence that the collective requirement was met.
This does not remove coordination or key-management responsibilities. Whoever assembles the proof may receive sensitive signing data, and enough compromised or deceived signers can still approve a harmful operation. Threshold authorization answers who must approve, not which behavior should be allowed.
2. ZK Signer: Membership Without Public Identity
Not every account needs several signatures for each action. Sometimes several people or devices should be eligible to operate an account, with any one authorized signer able to act.
That leads to a different question: can the account verify an authorized signature without learning which member signed?
The Statement
A valid signature over this transaction hash belongs to an address in the account's committed signer set.
ZK Signer verifies the signature and the derived address's membership in a private signer tree. The proof exposes the transaction hash and signer-set commitment, not the signer's public key, signature, or address as verification inputs.
Why It Matters
An account can have multiple eligible signers without making their identities part of its public authorization configuration. This supports a shared account or multiple authorized devices without forcing every action through a threshold workflow.
ZK Signer is one-of-many authorization; ZK MultiSig is threshold authorization. Multiple eligible signers do not automatically mean multiple approvals are required.
The distinction also determines the risk. Compromising one eligible key can be enough to satisfy ZK Signer. Privacy does not reduce that key's authority. To limit what it can do, signer authorization must be combined with behavior constraints.
3. ZK Labels: Human Meaning, Verifiable Bindings
People should be able to choose a colleague, role, recipient, or protocol by name. Comparing addresses should not be the primary way they establish confidence in an interaction.
But replacing an address with a friendly label is not sufficient. If the interface can silently change the mapping, the name provides convenience without an enforceable connection to the address.
Our question was: can we make the relationship between a human-readable label and a machine-readable identifier provable?
The Statement
This label and identifier form a binding in the registry represented by the accepted commitment.
ZK Labels binds names such as cfo or auditor to identifiers such as Ethereum addresses. A Merkle commitment represents the registry, and a proof establishes membership of a binding without requiring publication of the entire registry.
From Names to Execution
The application resolves a selected name to an address using its off-chain registry data. ZK does not perform a secret address lookup for the EVM; it proves that the binding is consistent with the committed registry.
For destination authorization, that proof must be connected to the actual transaction target. Otherwise, proving a valid binding for one address would say nothing about a transaction sent to another.
This is the foundation for our human-to-machine trust layer: a name-based interaction backed by a verifiable binding, rather than display text alone. The EVM still receives the address it needs to execute the call. The label and the rest of the registry need not be disclosed.
What the Binding Guarantees
A membership proof establishes consistency with the accepted registry, not the truth of a real-world identity. Naming an address after a protocol does not prove that it is the official deployment, audited, or safe.
Registry setup, trusted sourcing, and authorized updates therefore matter. So does the interface: a compromised UI could misrepresent which valid entry was selected. ZK Labels is a building block for trustworthy interactions, not proof of what the user saw or intended.
4. ZK Scope: Authority With Boundaries
Our next question goes beyond signer identity: why should permission to operate an account imply permission to perform any action?
A broadly authorized key can become a broadly useful attack tool. Incidents such as the Bybit theft sharpen the need to examine the entire authorization workflow, not just whether signatures are valid. They do not establish that any one ZK primitive would have prevented the incident.
Our response is to make permitted behavior an explicit part of account configuration.
The Statement
This transaction satisfies a permitted rule in the account's committed scope.
ZK Scope represents permitted transaction patterns as a private rule set. Rules can constrain the destination contract, function selector, native-token value, and supported calldata parameters. A proof establishes that a transaction matches an allowed rule without publishing the complete policy.
The documented primitive supports exact-match and upper-bound constraints on a limited set of decoded parameters. It is not a general interpreter for arbitrary contract behavior.
Limiting a Compromised Key
Consider an operating key intended only to make bounded payments to configured recipients. Possessing that key should not automatically permit arbitrary transfers, changes to account ownership, or removal of the policy.
With correct integration, an attacker who compromises the key still cannot authorize an operation outside its enforced scope. The same restrictions apply regardless of who possesses the key.
That is narrower, and more useful, than claiming a compromised key cannot execute any malicious transaction. An attacker may exploit actions that remain permitted. A per-transaction limit does not impose a daily budget; repeated permitted transactions can still cause loss. An allowed protocol can also contain vulnerabilities.
The protection depends on binding proof inputs to the actual execution, checking the current policy commitment, and preventing alternate execution or configuration paths from bypassing the restriction. A key that can remove its own scope is not meaningfully confined by it.
Composing an Account Experience
These statements answer complementary questions:
| Primitive | Question It Answers |
|---|---|
| ZK MultiSig | Did enough distinct authorized signers approve? |
| ZK Signer | Did an authorized member sign? |
| ZK Labels | Does this name-to-identifier binding belong to the accepted registry? |
| ZK Scope | Does this transaction satisfy a permitted behavior? |
Imagine a team account where an operator chooses a supplier by name and prepares a payment. Signer authorization proves that the operator may act. A label binding connects the configured supplier name to the destination. Scope checks the supported transaction fields against a permitted payment rule.
For an account requiring collective control, threshold authorization can replace single-member authorization. These checks must refer to the same operation and accepted configuration; independently valid proofs are not automatically a secure composition.
Our documented ZK Labeled Signer and ZK Labeled Signer + Scope constructions explore this composition directly. They bring signer authorization, named destinations, and behavior constraints together, rather than leaving their relationships to UI conventions alone.
The aim is a simpler interaction backed by more precise enforcement: users work with names and intended actions, while the account checks cryptographic evidence about the corresponding machine-level operation.
Protocol Building Blocks
We are developing these approaches as reusable protocol building blocks, not just features of one wallet interface. Each combines a statement, private configuration, public commitments, proof generation, and an account integration that enforces the intended checks.
ERC-8039 provides a common verification interface. The playground makes supported statements tangible through configuration, simulation, and proof experiments. Neither replaces circuit review, correct account integration, or operational security.
Privacy also has a precise boundary. Hiding authorization witnesses does not hide ordinary EVM execution, transaction destinations, timing, or every relationship that observers might infer. Private registry data must remain available to authorized operators and be protected wherever proofs are prepared.
Our perspective is that usability, privacy, and security should be designed together. Names make interactions understandable. Private commitments reduce disclosure. Signer and scope proofs make specific authorization conditions enforceable.
Self-custody should mean more than holding a key. It should mean understandable control over who can act, what they can do, and what the world needs to learn about it.