Ethereum$1,686.33 keeps talking about "privacy by default," but the plumbing is still missing, and Ameen Soleimani is calling it out. [1]
Ameen Soleimani, a well known Ethereum$1,686.33 developer and privacy advocate, argued this week that Ethereum$1,686.33's zkEVM privacy ambitions are bottlenecked by one unsexy but critical upgrade: a Poseidon hash precompile. Without it, he says, privacy features that rely on zero knowledge proofs stay stuck in "nice roadmap, no native support" territory, especially on Ethereum layer 1 where gas costs are unforgiving. [2]
Register for free and get unlimited access to all articles.
Why Poseidon matters for zk proofs, not vibes
Poseidon is a hash function designed to be efficient inside zero knowledge circuits. That matters because zk systems do not pay the same computational costs as regular execution. A hash that is cheap on a normal CPU can be expensive to prove in a zk circuit, and that cost explodes when you need to hash repeatedly (common in Merkle trees, nullifiers, commitments, and shielded transfer designs).
Soleimani's point is straightforward: if Ethereum wants practical, composable privacy using zk proofs, it needs the hash primitive that zk builders actually want to use, and it needs it in the cheapest form possible on chain.
A precompile is a built in contract at a special address that executes a specific cryptographic operation far more efficiently than you can implement in Solidity or EVM bytecode. Ethereum already relies on precompiles for widely used primitives such as elliptic curve operations and hashing.
Adding Poseidon as a precompile would not magically make every wallet private. What it would do is make common zk patterns cheaper and more practical to verify on Ethereum L1, and easier to standardize across applications. [3]
Without a precompile, teams can still use Poseidon, but they pay for it the hard way: more gas, more constraints, more engineering complexity, and often the conclusion that "we will just do it on a rollup" (which is fine, until you need L1 verification, L1 settlement logic, or broad composability).
Soleimani framed this as a gap between Ethereum's messaging and its willingness to ship the low level upgrade that makes privacy usable at scale. The meme version is basically: "wen privacy," but for developers.
"Others already have it" and that is the pressure point
Soleimani also highlighted that other networks have supported Poseidon style primitives earlier, naming Solana$79.10, Starknet, and Stellar$0.2465, with implementations appearing across the 2020 to 2022 window.
That comparison is not just chain tribalism. It is about developer ergonomics and time to ship. If you are building zk applications and one ecosystem offers cheaper, standardized primitives for proof verification, you get a more predictable cost model. Ethereum's pitch has long been security, liquidity, and composability, but those advantages are easier to sell when core primitives do not feel stuck in committee.
He also claimed that Starknet contributors tried to help move Ethereum toward Poseidon support and got waved off. That specific detail is hard to independently verify from the public thread alone, but the broader implication is clear: zk teams want alignment on primitives, and Ethereum's coordination process is slow enough that competitors can look "done" while Ethereum looks like it is still debating the screwdriver.
This is not a fresh idea. Soleimani pointed to EIP-5988, a proposal first floated in 2022 that would add Poseidon functionality to the EVM via precompile style support. Years later, the proposal has not translated into mainnet functionality. [4]
That timeline matters because Ethereum's roadmap is crowded with legitimate priorities, including scaling, account abstraction improvements, and ongoing work around verifier efficiency. Still, Soleimani's criticism is that privacy cannot remain a perpetual side quest. If Ethereum wants "native shielded transfers" or broadly usable privacy preserving apps, it has to decide that a zk friendly hash primitive is not optional.
Put differently: zkEVM privacy is not only about fancy proving systems. It is also about the boring parts, namely which hash function your circuits assume, how expensive it is to verify, and whether developers can rely on it across the ecosystem without hand rolled implementations.
Privacy by default, but default to what?
Ethereum has been circling privacy improvements at the application and wallet layers, including newer standards aimed at reducing address reuse and improving payment privacy patterns. Those are helpful, but Soleimani is arguing for infrastructure level support that makes zk privacy cheaper to execute and verify.
There is also a subtle political angle here. "Privacy by default" can mean many things, from better UX around stealth addresses, to private transfers, to selective disclosure identity systems. Each category carries tradeoffs, and Ethereum tends to move only when the security and social consensus is strong.
Poseidon is not a full privacy solution, but it is a common building block. Not adding it can look like Ethereum is comfortable marketing privacy while leaving zk developers to absorb the cost and complexity.
To be fair, adding a new precompile is not trivial. It creates a long term maintenance commitment, demands serious cryptographic review, and raises compatibility questions across clients and tooling. Ethereum's bias toward caution is part of why it is trusted to secure large amounts of value. Soleimani's counterargument is that Poseidon is already "battle tested" in production zk systems, and that the opportunity cost of waiting is rising as competitors harden their zk stacks.
For teams building privacy preserving apps, the near term reality stays the same: most practical privacy work will continue on zk rollups and app specific environments where verification costs are easier to manage, and where teams can standardize their own primitives without waiting for L1.
For Ethereum mainnet, the cost angle is the real constraint. Without precompiles, proving friendly hashing on L1 becomes a "rich app" feature, and many designs remain uneconomical. That can keep native shielded transfer concepts stuck in prototype land, and it can push more privacy innovation away from the base layer.
For the market, this is not a token catalyst on its own. It is an infrastructure narrative that affects developer mindshare and long term platform competitiveness. Liquidity tends to follow the apps that ship, not the threads that go viral.
What to watch next
Watch EIP-5988 and any renewed push to prioritize a Poseidon precompile in client discussions and Ethereum research forums.
If Ethereum core devs signal concrete movement, such as a formal timeline, testnet implementation, or a coordinated security review, expect zk privacy teams to treat it as a meaningful unlock for L1 verification patterns.
If it stays stalled, expect more privacy heavy zk development to keep routing around L1, and expect competitors that already optimized these primitives to keep pitching themselves as the place where zk apps ship faster, cheaper, and with fewer "gas pain" footnotes.
Your reviews help us improve the quality of both current and future articles. All reviews are public and visible to other readers. We use both ratings and comments to improve future articles and to revise any articles that do not meet our standards.
See more like this on Google
