Hermez Network: Pros and Cons of Deploying Smart Contracts

Hermez is easy to misread because the name refers to two materially different systems. Hermez 1.0 was a payment-focused zk-rollup for token transfers and swaps, not a general-purpose smart contract environment. Polygon zkEVM, which grew out of the Hermez roadmap after Polygon’s August 13, 2021 merger, is the version that actually matters for Solidity deployment. That distinction is not cosmetic. It changes the answer to whether “deploying smart contracts on Hermez” is even possible.

Hermez Network means two different products

The practical conclusion is simple. If someone says “deploy on Hermez Network” in 2026, they usually mean Polygon zkEVM, not the original Hermez payment rollup. For an informed Web3 team, that naming cleanup should happen before any technical or token economy discussion starts.

The technical history is short, but it changes the deployment thesis

Hermez 1.0 went live in March 2021 as a decentralized zk-rollup focused on payments and ERC-20 transfers. Polygon’s later technical history states that Hermez 1.0 had already been live since March 2021 and scaled to 2,000 transactions per second, while the live site still describes it as a payment network optimized for transfers rather than arbitrary application logic.

Polygon merged with Hermez on August 13, 2021 and explicitly framed the next phase as an EVM-compatible roadmap. That date matters because it marks the point where “Hermez” stopped being only a payments rollup and became a path toward a zkEVM product under the Polygon umbrella.

Polygon then published the Hermez 2.0 architecture on May 13, 2022 and made the new objective explicit: smart contract support. The same post also explains why the original Proof-of-Donation design was replaced. Polygon’s argument was operational as much as theoretical. PoD was complex, vulnerable during bootstrapping, costly for competitors, and exposed the network to service-level delays if the winning operator malfunctioned or behaved maliciously.

Polygon zkEVM Mainnet Beta launched on March 27, 2023 as a permissionless public network, and Polygon also open-sourced the codebase under AGPL v3 that same day. That was the real deployment milestone for smart contracts.

The decisive late-stage fact is negative. On June 11, 2025, Polygon published the 2026 sunset plan for Polygon zkEVM Mainnet Beta, said support levels would drop, and said no new EIPs would be supported. Polygon also said the sequencer would continue running for the next 12 months and that forced transactions would remain enabled so users could exit. For any new deployment decision made on March 10, 2026, this is the first fact that should sit on the table.

What matters technically before you deploy

Polygon zkEVM is attractive because it preserves much of the Ethereum developer workflow. Polygon says the network supports a majority of Ethereum EIPs, precompiles, and opcodes, exposes an Ethereum-compatible JSON-RPC interface, and allows seamless deployment of smart contracts, wallets, and tools that already work on Ethereum. The official tooling guides go further and state that Hardhat is the preferred framework and that any smart contract deployable to Ethereum can be deployed easily with Foundry.

Polygon zkEVM is still a separate chain state, not Ethereum with cheaper gas. Polygon’s EVM basics documentation states that L1 smart contracts cannot be directly accessed through L2 transactions because the zkEVM has its own state. In practice that means every application that assumes synchronous access to Ethereum mainnet contracts needs explicit bridge or message-passing design.

The settlement architecture is strong on paper and operationally heavier in practice. Polygon’s architecture docs describe a consensus contract on Ethereum, a zkNode stack, a zkProver, a verifier contract, and a bridge. Batches are executed off-chain, then verified on Ethereum through validity proofs. From a security-budget-maximalist lens, that is the right direction. Security is paid for at the settlement layer rather than hand-waved at the app layer. But it also means application teams inherit bridge dependencies, proof infrastructure assumptions, and L1-linked failure modes.

Developers should not read “EVM-equivalent” as “byte-for-byte identical under every edge case.” Polygon’s own Etrog documentation still lists differences that matter for contracts near the metal. SELFDESTRUCT is not supported and is replaced by SENDALL. BASEFEE is not supported because the zkEVM implements Berlin rather than London behavior in that context. Polygon also marks EIP-2718 and EIP-2930 as unsupported. That does not break ordinary ERC-20 or NFT deployments, but it does mean sophisticated protocol code should be tested against actual zkEVM semantics, not just assumed portable because it compiled on Ethereum.

The governance and upgrade model is another non-trivial deployment input. Polygon’s overview says upgrades use an admin multisig, a timelock, and a transparent upgradeable proxy. The same docs specify a 10-day timelock, a 2-of-3 admin multisig, and an emergency 6-of-8 Security Council that can bypass the timelock if funds are at risk. That is more structured than many L2s, but it is still governance trust, not pure cryptoeconomic neutrality.

The case for deploying smart contracts on Hermez’s zkEVM lineage

The strongest pro is inherited Ethereum settlement with validity proofs. Polygon’s docs are clear that transaction finality and batch consolidation are achieved through smart contracts on Ethereum, and that full transaction data plus validity proofs are posted to Ethereum. For teams that care about long-run defensibility, that is better than building on a cheaper environment whose security budget depends on weak externalities.

The second pro is migration cost. Polygon’s core pitch has always been that most Ethereum tooling and contracts can move with limited code changes. That reduces audit delta, reduces integration friction, and shortens time to production. For teams with mature Solidity codebases, that matters more than headline TPS claims. Rewriting contracts for a new VM is not just a developer tax. It is a fresh attack surface.

The third pro is source visibility. Polygon zkEVM is fully open-source under AGPL v3. That gives infrastructure teams, auditors, and protocol engineers a much better base for threat modeling than opaque rollup stacks. If your application has meaningful treasury, bridge, or token economy exposure, open infrastructure is not a luxury feature. It is part of your security process.

The fourth pro is that Polygon did not ignore operational security. The public record includes audits, a bug bounty with rewards up to $1,000,000 for critical findings, an emergency state, and force-batch or force-verification mechanisms intended to reduce censorship and liveness risk. Those are meaningful safeguards, even if they do not eliminate trust assumptions.

The case against deploying there now

The biggest con in 2026 is not technical elegance. It is product continuity. Polygon has already announced that Polygon zkEVM Mainnet Beta is being sunset during 2026, that support will be lower, and that no new EIPs will be supported. New smart contract deployments on a network in managed wind-down mode face an obvious problem: even if the chain is secure enough today, the ecosystem support surface is shrinking by design.

The second con is centralization during the network’s beta life. Polygon’s risk disclosures state that the mainnet beta has centralized features, including Sequencer and Aggregator roles maintained by Polygon Labs, and that these actors can delay inclusion or reorder transactions. The architecture docs likewise say only one sequencer and one aggregator are currently operational despite the broader permissionless design target. For a team that treats credible neutrality as part of its security model, that is a material caveat.

The third con is bridge exposure. Polygon explicitly warns that cross-chain bridging can be subject to attacks or exploits affecting smart contracts, hardware, software, or related systems. Because most application value on an L2 arrives through bridging, the bridge is part of the application’s real security perimeter whether the team acknowledges it or not.

The fourth con is compatibility drift at the edges. Polygon markets zkEVM as EVM-equivalent, but its own protocol pages still document unsupported opcodes and transaction-type differences. If your contracts rely on unusual EVM behavior, timestamp-sensitive logic, or lower-level gas semantics, you need test vectors on zkEVM itself. Cheap deployment is not cheap if it creates a hidden re-audit obligation.

The fifth con is operations. Polygon’s risk disclosures note that the zkProver currently does not support ARM-powered Macs, does not recommend WSL or WSL2 for Windows users, and may fail on some AMD setups because of required Intel instructions. That does not block ordinary dApp deployment through hosted infrastructure, but it does matter for teams that want full-stack sovereignty. Owning your own infrastructure is part of long-run security budgeting. If the proving or node stack is awkward to run, decentralization remains more aspirational than achieved.

Notable projects and the practical verdict

At mainnet beta launch on March 27, 2023, Polygon highlighted Lens and Balancer as flagship dApps launching on Polygon zkEVM, alongside gaming projects such as Midnight Society and Oath of Peak. Polygon also named infrastructure providers including ANKR, Alchemy, Sequence, and The Graph. That launch roster shows the network was credible enough to attract recognizable Ethereum-native brands and infrastructure vendors.

The practical verdict is therefore split by timeframe. Historically, the Hermez-to-zkEVM lineage offered a credible reason to deploy: Ethereum-aligned security, lower costs than L1, familiar Solidity tooling, and a serious attempt to fund security and public-goods infrastructure rather than pretending coordination costs disappear.

For a fresh deployment decision on March 10, 2026, the answer is mostly no. The reason is not that the architecture was unserious. It is that deployment is a forward-looking commitment, and Polygon zkEVM is already on a published sunset path. Security assumptions without long-term operator support, upgrade support, and ecosystem continuity are weaker than they look in architecture diagrams. Lower short-term fees do not compensate for migration risk on a winding-down chain.

For teams evaluating L2 placement, the hard question is not only “Can the contract deploy?” It is “Who funds security, operations, upgrades, exits, and migration when market attention moves on?” That is where token economy design intersects with chain choice. At FinDaS Tokenomics, tokenomics consulting on L2 deployments usually starts with settlement guarantees, operator concentration, bridge dependency, and migration cost before it touches incentives or emissions. On Hermez’s original payment network, smart contract deployment was the wrong question. On Polygon zkEVM in 2026, the right question is whether you want to deploy into a sunset.

This article is part of our Choosing The Right Blockchain series.