When AERE Network describes itself as "EVM-compatible," it means something specific and consequential: every tool, library, wallet, and development framework built for Ethereum works on AERE without modification. This isn't a minor convenience, it's the difference between a chain that developers can use on day one and one that requires months of ecosystem-building before it becomes usable.
This article explains what EVM compatibility actually means, which tools it covers, what "porting" a dApp to AERE actually involves, and why AERE chose to build on the EVM rather than a custom execution environment.
The Ethereum Virtual Machine is the standardized execution environment that runs smart contract bytecode on Ethereum. It defines a precise instruction set (opcodes), a memory and storage model, a gas accounting system, and a set of precompiles for common cryptographic operations. Every Solidity or Vyper contract compiles to EVM bytecode. Every Ethereum node runs that bytecode identically.
Because the EVM is a published open standard, other chains can implement it independently. Any chain that executes the same instruction set and exposes the same JSON-RPC API is, from a tool perspective, indistinguishable from Ethereum. That's what AERE does. AERE runs Hyperledger Besu, one of the most battle-tested EVM implementations available, with chain ID 2800.
The Ethereum development ecosystem has been built over nearly a decade. Every piece of it works on AERE:
For most Ethereum dApps, deploying to AERE requires changing exactly one or two things:
// hardhat.config.js, add this network block networks: { aere: { url: "https://rpc.aere.network", chainId: 2800, accounts: [process.env.DEPLOYER_PRIVATE_KEY], } } // Then deploy the same way you would to any network: npx hardhat run scripts/deploy.js --network aere
The smart contract source code does not change. The ABI does not change. The frontend JavaScript does not change, except for updating the chain ID in the network configuration. The only exception is if your Ethereum contract depended on Ethereum-specific infrastructure that doesn't exist on AERE, like a specific oracle address or a bridge contract address, in which case you'd replace those with their AERE equivalents.
Some blockchains have chosen to build their own virtual machines and programming languages. There are legitimate reasons to do this, a custom VM can be optimized for specific performance characteristics or programming paradigms that the EVM wasn't designed for. But there's a cost: every developer who wants to build on your chain has to learn a new language, new tools, and new debugging techniques. The ecosystem you can offer is, for years, a fraction of what Ethereum offers.
AERE's decision to build on the EVM is a deliberate prioritization of developer accessibility over VM customization. The Ethereum toolchain is what professional smart contract developers know. Being able to deploy an existing Ethereum project to AERE on the same afternoon a developer hears about it is a more valuable property than any custom VM feature would be at this stage.
There is a meaningful distinction between a chain that is "EVM-compatible" and one that claims "EVM equivalence." Equivalence implies behavior identical to the Ethereum mainnet EVM at the opcode level, including edge-case gas accounting behavior. Compatibility means the standard instruction set and API are supported and all common patterns work correctly.
AERE runs Hyperledger Besu, which implements the EVM faithfully. Contracts that follow standard Solidity patterns and use standard libraries will behave identically on AERE as on Ethereum. Contracts that depend on very specific gas cost assumptions tied to Ethereum's fee market may need review, but such cases are rare in practice.
If you have an Ethereum dApp and want to run it on a chain with 1-second finality, negligible gas costs, and a hard-capped native token, AERE is a same-afternoon deployment. If you're starting a new project, you can write standard Solidity against the OpenZeppelin library, test with Hardhat or Foundry, and deploy to AERE without learning anything new.
The developer documentation has the full RPC reference, SDK, and contract registry. The grants program funds projects that deploy to AERE. And this tutorial walks through deploying your first contract in ten minutes.
← Back to Blog