EON Horizen EVM Sidechain and Gobi Testnet: A 2026 Guide

EON was an EVM-compatible sidechain associated with the Horizen ecosystem. Horizen is a blockchain project that has used several technical environments over time, and EON was one of the attempts to give it an Ethereum Virtual Machine layer. A sidechain is a separate blockchain that runs alongside a main chain and has its own validators, consensus and block production. Assets can move between the two through a bridge, and the sidechain can offer different speed or cost trade-offs.

The core idea of an EVM sidechain is simple. Developers who already know Solidity and tools such as Hardhat or Foundry can deploy familiar smart contracts without learning a new language. Users can connect wallets that already support Ethereum-style networks, provided they add the right network settings.

The topic you asked about described EON as live on the Gobi testnet. That fits how new chains usually launch: a testnet comes first so developers and node operators can find bugs before real value moves on the network. Public reporting used for this guide do not give a full technical specification for EON, so treat any detailed numbers, such as block times or fees, as things to confirm in Horizen's documentation.

• EON was described as an EVM-compatible sidechain.
• It was tied to Horizen, not to Ethereum mainnet directly.
• Its testnet was called Gobi.
• Its later status is covered in the migration section below.

EVM compatibility means a chain can run the same bytecode that Ethereum runs. A contract compiled for Ethereum can often be deployed on an EVM-compatible chain with few or no changes. Wallets that use the same address format and signing methods can also interact with it, which is why many chains advertise EVM support.

Compatibility is not the same as equivalence. A chain may differ in gas pricing, block timing, precompiled contracts, available opcodes or the set of supported tools. Those differences can break a contract that works on Ethereum, so developers should test the exact chain they plan to use.

For users, compatibility mainly affects wallet setup. You need the correct network name, chain ID, RPC URL and native token symbol. Mistakes here are a common source of lost funds, because a wallet may send tokens to the wrong network or show a token balance from a copy-cat network.

A useful check before using any EVM network is to compare the chain ID with the official documentation and a block explorer. If the explorer, documentation and wallet settings do not match, stop and find out why before you send anything.

• Compatible contracts still need testing on the target chain.
• Chain ID and RPC URL must come from an official source.
• Gas and token behaviour can differ from Ethereum.

A testnet is a copy of a blockchain network that runs with test tokens. Developers use it to deploy contracts, run scripts, test wallet integrations and check how the network behaves under load. Test tokens are usually obtained from a faucet, and they have no market value. A testnet is useful because mistakes there cost nothing, but it is not a guarantee that the mainnet will behave the same way.

Gobi was the testnet name associated with EON. The name tells you that a testnet exists and was used by builders, but it does not tell you whether the network is still running today. Testnets are often reset, retired or replaced when a project changes direction.

If you want to use a testnet, start with the official documentation. It should list the chain ID, RPC endpoints, block explorer and faucet. Use a separate wallet or account for testing so your main holdings never touch test networks, and never enter a seed phrase into a site that offers test tokens.

A testnet block explorer is also a useful check. If you can see recent blocks and transactions, the network is active. If the explorer shows old data or errors, the network may be paused, reset or retired.

• Test tokens have no real value.
• A testnet's name does not prove it is still live.
• Use a separate wallet for testing.
• Confirm everything from official pages.

One of the most important developments in public reporting is a February 2025 governance proposal from Horizen, called ZenIP 42406. According to the coverage in the results, the proposal described a plan to migrate ZEN tokens and EON to Base, positioning Base as an application chain optimised for the Horizen ecosystem.

Base is a layer-2 network built on Ethereum. In plain terms, a layer-2 processes transactions off the main Ethereum chain and posts data back to it, which can lower costs and speed up activity while inheriting some security from Ethereum. A migration of this kind moves a project's token and network activity onto that existing infrastructure rather than maintaining a standalone chain.

A governance proposal is a formal request that token holders vote on. Passing a proposal does not automatically finish a migration. Implementation steps, timelines, token bridging and any changes for developers depend on follow-up announcements and technical work.

For readers, the practical lesson is that EON should be understood as part of a larger shift. If you encountered EON in older material, check whether that information predates the migration proposal before following its instructions.

• ZenIP 42406 was a proposal to migrate ZEN and EON to Base.
• A proposal is not the same as a completed migration.
• Older guides may describe EON as a standalone sidechain.

Public reporting includes a Horizen release page that describes the ecosystem as EVM-native and built on Base, with a release for mainnet and testnet. That suggests the project's current direction is aligned with Base rather than a separate EON chain. The results do not, however, give a full, dated account of every step of the migration, or confirm whether the Gobi testnet still runs.

Because the situation can change, the best approach is to build your own status check. Start with Horizen's official website, documentation and announcements. Next, look at the relevant block explorer. Recent blocks and transactions point to an active network, while stale data suggests a paused or retired one.

A second check is the governance record. Proposals and their outcomes are usually posted publicly, so you can see whether ZenIP 42406 passed and what it said about timelines. If a source says a migration is complete, look for technical confirmation, such as updated chain IDs, bridge documentation or a developer migration guide.

Do not rely on a single social media post. Impersonation of crypto projects is common, and fake announcements often link to lookalike sites.

• Check official documentation and announcements first.
• Use the block explorer to confirm whether activity is current.
• Read the governance record directly where possible.
• Treat unverified posts with caution.

The topic you provided mentioned 75k in bug bounties for the EON sidechain. Public reporting do not confirm this. The only dollar figure close to that amount in the results comes from a Blockworks article about bug bounty payouts, which says MetaMask came a close second with payouts totalling $75,750. That number refers to a different program and does not describe Horizen or EON.

This matters because bounty amounts can be misquoted. A reward cap, a total pool, a payout to a single researcher and a program's annual budget are different things. Before you repeat any figure, identify exactly what it measures, which program it belongs to and when it was published.

To verify a bounty, look for the program page on the project's official site or on a recognised bounty platform. A real program will list the scope, which assets and contracts are covered, the severity levels, reward ranges, and the rules for reporting and disclosure. It should also name the channel where reports are accepted.

If a program is not clearly published, treat claims about it as unconfirmed. Do not send sensitive details to unofficial channels or to anyone who asks for private keys.

• The 75k figure was not confirmed by the results.
• The $75,750 figure relates to a different program.
• Check the scope, rules and reward structure on the official program page.

Bug bounty programs pay researchers to report security issues in a project's code, usually smart contracts, bridges or infrastructure. A well-run program defines a scope, sets severity tiers and promises a response process. Rewards are often scaled by impact, so a critical issue that could put user funds at risk typically pays far more than a minor problem.

The Blockworks article in the results also shows that bounty payouts can be spread across many programs and many years, so a single total does not describe any one project. The blockeden.xyz result discusses how AI tools may change the bounty landscape by making some pattern-based bugs easier to find. Those are general trends, not facts about EON.

For anyone who finds a suspected issue, the defensive path is clear. Stop testing as soon as you confirm a problem, avoid touching other users' funds, and report privately through the official channel named in the program's rules. Do not publish exploit details on social media before the team has had time to respond.

For project teams, a published scope, a clear contact address and a commitment to timely replies are the basics. These matter more than headline numbers.

• Rewards usually track the severity and impact of a finding.
• Report privately through the listed channel.
• Avoid public disclosure before a fix.
• Read the scope before testing anything.

If you are a developer exploring EVM chains, the right first step is a clean test environment. Create a dedicated development wallet, fund it only with test tokens from an official faucet, and keep its keys separate from any wallet that holds real assets. Store your test keys in an environment file or a local keystore that is excluded from version control.

Next, confirm the network details from official documentation: chain ID, RPC endpoint, native token name and block explorer. Enter them manually in your development tools and check the chain ID in your wallet before every deployment. A mismatch is a sign to stop.

Write tests that cover normal use, edge cases and hostile inputs. Run them against a local fork or a testnet, and compare gas costs and behaviour with the network you plan to target. If a dependency or bridge is involved, check its current documentation, because interfaces can change during migrations.

Finally, keep a record of contract addresses, deployment transactions and the commit you deployed. That record helps you verify later whether a deployed contract matches your code, and it is useful if you need to explain an issue to a security team.

• Use a separate development wallet with test tokens only.
• Confirm chain ID and RPC endpoints before each deployment.
• Test on a local fork or testnet first.
• Keep deployment records for later verification.

Users should treat any testnet as a practice space. Do not send real funds to a testnet address, and do not swap test tokens for anything of value, since test tokens are not redeemable. If you added a testnet to your wallet, consider removing it once you have finished, so you do not send assets to it by mistake.

Phishing is common around new chains. Attackers copy project names, create lookalike token contracts and post fake faucets or airdrops. Before you connect a wallet, check the URL carefully, bookmark the official site, and never enter a seed phrase into any website or chat, regardless of who asks.

Approvals deserve attention too. Many dApps request token spending permissions. Review what you have approved in a wallet's permissions tool and revoke anything you no longer need. Use a hardware wallet for significant holdings where possible.

If you are unsure whether a network, token or bridge is legitimate, pause and verify it through official channels before proceeding. Losing time is almost always better than losing funds.

• Use testnets only for testing.
• Bookmark official sites and check URLs carefully.
• Never share a seed phrase or private key.
• Review and revoke token approvals you no longer need.