What It Actually Takes to Build a Relayer-Free Privacy Protocol on Ethereum

Zero-knowledge smart contract development services build privacy-preserving apps — private transfers, shielded pools, mixers — on public blockchains like Ethereum, using cryptographic proofs that verify a transaction is valid without revealing who sent what. The hard part is rarely the cryptography. It’s the on-chain gas math that decides whether your protocol can run without a central middleman.

That distinction is where most founders — and a fair number of development shops — get burned. You can ship a working private-transfer app in months. Whether it stays censorship-resistant, cheap, and free of a chokepoint that regulators or infrastructure providers can lean on is an engineering problem hiding inside the fee arithmetic. A recent benchmark study of Ethereum’s proposed frame-transaction standard (EIP-8141) put hard numbers on exactly how tight that arithmetic is, and those numbers now double as a buyer’s checklist.

What a privacy-preserving smart contract actually requires

Strip away the acronyms and a shielded-pool app needs three moving parts. First, a note commitment — an encrypted record that says “this much value exists in the pool” without naming the owner. Second, a nullifier — a one-time marker the contract records when a note is spent, so nobody can spend the same funds twice. Third, a zero-knowledge proof — a small piece of math (in practice, a Groth16 proof, the cheapest kind to check on Ethereum) that proves the spend is valid without exposing which note it drained or who owns it.

When a user withdraws, the contract verifies the proof, marks the nullifier as used, and creates any new commitments. Tornado Cash’s classic withdrawal is the simplest shape: spend one note, create none. RAILGUN’s private transfers spend and create several at once. Every design decision after this point is about making that verification cheap enough to happen in public — and that’s where the money is spent.

The discipline here matches any Solidity smart contract build and audit, just with an unforgiving cryptographic layer bolted on. The threat modelling and gas-optimisation work you’d expect on any DeFi protocol still applies — there’s simply less room for error.

Why most privacy apps still need a middleman

Here’s the problem privacy protocols have never fully solved: to withdraw anonymously, you can’t pay the gas fee from your own wallet, because that wallet would link you to the withdrawal. So today’s apps route the transaction through an off-chain relayer — a paid third party that submits it for you. That relayer is a single point of failure. It can be censored, shut down, or pressured to filter transactions, and it quietly undoes much of the censorship resistance the protocol promised.

The EIP-8141 research asks a pointed question: can a new class of Ethereum transaction let these apps drop the relayer entirely and still propagate through the public mempool — the open waiting room where pending transactions sit before they’re mined? The answer is a qualified yes, and the qualification is a gas cap. To ride the public mempool, a transaction’s verification work can’t exceed a limit the proposal calls MAX_VERIFY_GAS, currently set at 100,000 gas.

If you’re building a private-transfer app and want it to be unstoppable, this is the whole ballgame. Removing the relayer is the difference between “private, until someone leans on our infrastructure partner” and “private, full stop.” A capable development partner treats relayer removal as a design constraint from day one — not a feature to bolt on later.

The gas math buyers get wrong

This is where good intentions meet BN254 math and lose. According to the EIP-8141 benchmark, the single most expensive irreducible operation — the pairing check that validates a Groth16 proof on Ethereum — costs 181,000 gas on its own. The proposed 100,000-gas cap doesn’t just make privacy transactions tight; it makes them impossible. Nothing fits.

The benchmark works out the true floor after every available optimisation. The cheapest possible shielded transaction — a single-note spend like a Tornado withdrawal — needs 211,828 gas. The largest deployed shape, RAILGUN spending and nullifying eight notes at once, needs at least 351,828 gas. On top of the pairing check, the protocol pays a flat 20,000 gas per nullifier, which is why the cost climbs with the number of notes a transaction touches. The study’s recommendation is blunt: raise the cap to at least 250,000 gas, which admits every common transaction shape — and below 200,000, “the use case does not exist.”

Here’s the trap for buyers. A team that hasn’t done this arithmetic will quote you a build against the current cap, ship it, and discover their transactions can’t propagate. Worse, some of the cost is easy to hide in the wrong place. The benchmark notes that RAILGUN’s real dominant expense isn’t proof verification at all — inserting two commitments into its Merkle tree costs 503,472 gas, roughly 1.6x the proof verification itself, because each insertion calls a Poseidon hashing library 17 times at 29,616 gas apiece. That cost is unavoidable, but where you put it matters: shove it into the verification step and you blow the mempool cap; defer it to a follow-on step and your protocol still qualifies as relayer-free.

The implementation choices that decide whether you can go relayer-free

Several engineering decisions separate a protocol that fits the budget from one that doesn’t, and every one of them is a question worth asking a prospective partner. Bind the proof to the transaction using the transaction’s own signature hash, so a proof sitting in the mempool can’t be hijacked and re-pointed at a different recipient — this also lets you delete the relayer, fee, and refund fields Tornado’s original circuit carried, cutting its public inputs from six down to one. Fold every remaining public input into a single hashed commitment, which keeps verification cost flat no matter how many notes a transaction spends. Hardcode the proof’s verifying key directly in the contract code rather than reading it from storage.

That last one has a hidden payoff most buyers never hear about. On a shared privacy pool, users can only transact in parallel if the contract’s validation step reads no storage. A verifying key sitting in storage is exactly such a read — so a lazy implementation doesn’t just cost more gas, it silently serialises your users into a queue. The benchmark measured RAILGUN’s storage-based key read at up to 88,393 gas for its largest shape. These are not academic distinctions; they’re the difference between a protocol that scales and one that grinds.

Every optimisation has a cost somewhere. Folding inputs into one hash makes verification cheap on-chain but nearly triples the work a user’s device does to generate the proof — the benchmark measured Tornado’s circuit growing 2.7x. A serious partner will walk you through that tradeoff explicitly and let you choose, rather than optimising one number and quietly wrecking another.

Should you build a custom privacy protocol, or use an existing one?

Build only if privacy is your product. If you’re designing a new shielded pool, a compliance-aware private-payments rail, or a protocol whose privacy guarantees are the differentiator, custom development is the honest answer — no off-the-shelf tool will match your specific note structure, compliance hooks, and censorship-resistance requirements.

Don’t build if you need privacy as a feature inside a broader app. Integrating an existing, audited protocol like RAILGUN, or using a privacy-focused chain, is far cheaper and skips the multi-month circuit-and-audit cycle. Custom zero-knowledge work carries a real audit burden — you’re auditing both Solidity and the cryptographic circuit, two distinct specialities — and the gas math above shows how easily a subtle choice becomes an expensive one. If your privacy needs are modest, or if the trust model of a permissioned network is acceptable, the honest comparison in a public-versus-private blockchain decision guide may point you away from a custom zk build entirely. Scoping this properly up front, using something like a cost-of-custom-blockchain scoping framework, saves far more than it costs.

Within a couple of years, standards like EIP-8141 will make relayer-free privacy the default expectation for serious protocols, and the apps still routing withdrawals through a paid middleman will look as dated as unencrypted websites do now.

How to evaluate a blockchain development partner for privacy work

Ask three questions. First: what verification-gas budget are you designing against, and can you show me the per-nullifier and per-commitment breakdown? A partner who can’t produce that number on request hasn’t done the arithmetic. Second: where does the Merkle-tree insertion cost live in your design — in verification, or deferred? The wrong answer breaks mempool compatibility. Third: who audits the circuit, separately from the Solidity? Circuit bugs don’t throw errors; they silently let attackers forge proofs, and general smart-contract auditors are not trained to catch them.

FAQ

Q: How much does it cost to build a zero-knowledge privacy protocol on Ethereum? A: There’s no single figure, because cost scales with the complexity of your note structure and the number of transaction shapes you support. The real cost drivers are circuit design, two separate audits (Solidity and the zero-knowledge circuit), and the gas-optimisation work needed to fit the mempool budget. Scope it against defined tiers before committing — a fixed quote given without gas analysis is a warning sign.

Q: What is a nullifier, and why does it matter for cost? A: A nullifier is a one-time marker the contract records when a private note is spent, preventing anyone from spending the same funds twice. It matters commercially because each nullifier adds a flat 20,000 gas to verification, according to the EIP-8141 benchmark — so a transaction spending eight notes costs meaningfully more than one spending a single note, and your fee estimates have to reflect that.

Q: How long does a privacy protocol build take? A: Longer than a standard DeFi contract, because the circuit design and its dedicated audit run in addition to the usual Solidity development and testing cycle. The circuit work in particular can’t be rushed — the tradeoff between on-chain gas cost and client-side proof-generation time has to be tuned deliberately, and getting it wrong means either transactions that don’t fit the mempool or a user experience that feels broken.

Key Takeaways

• The 100,000-gas mempool cap in EIP-8141 makes relayer-free privacy impossible today — the pairing check alone costs 181,000 gas — so any partner quoting against the current cap hasn’t run the numbers.
• The cheapest possible shielded transaction needs 211,828 gas and the largest deployed shape needs 351,828, per the benchmark; a 250,000-gas cap is the threshold that makes most privacy apps viable.
• Merkle-tree insertion, not proof verification, is often the dominant cost — RAILGUN’s runs to 503,472 gas — and where you place it determines whether your protocol stays mempool-compatible.
• Custom zero-knowledge development is worth it only when privacy is your product; if you need privacy as a feature, integrating an audited existing protocol is far cheaper and faster.
• Budget for two audits, not one: the cryptographic circuit needs a specialist review that general smart-contract auditors can’t provide.

If you’re scoping a privacy-preserving DeFi protocol and want the gas math checked before you commit a budget, book a blockchain development consultation to pressure-test the design.