Deploy the Solidity you already have and it runs, with the wallet and the tools you already use. Beside it sits a native engine where Rust contracts reach straight into the parts of this chain that nothing else has.
Both write to the same accounts. Nothing is duplicated between them and nothing has to be moved across, because there is only one ledger underneath the pair.
How it works
Plenty of chains run two virtual machines. What decides whether that is useful or annoying is whether they share a ledger.
Solidity deploys unchanged. The wallet, the test framework and the deployment scripts you already use work against this chain on day one. Nobody has to learn a new language to find out whether their contract runs here, because it already does.
Compatibility has a ceiling. Native contracts, written in Rust, call straight into things the EVM has no concept of: staking, mining statistics, submitting a compute job. The Compute Mesh, governance and the Signal Ledger are all written on this side, because they had to be.
There is one account state and both engines use it. A balance is not duplicated per engine and does not need moving between them. That is what makes this an execution layer rather than two chains sharing a name, and it is what the animation above is showing.
A contract on one side can call a contract on the other, through a router that translates between two very different ways of describing a function call. Values do not need bridging, because there is only one ledger. What needs translating is the call itself.
Which side to build on
If the value in what you are building is existing code, an existing library or an existing audience of Solidity developers, use the EVM side. Nothing about it is a compatibility shim you will regret later. It is a first-class engine and most of what gets deployed here will probably live on it.
If what you are building only makes sense on this chain, use the native side. That means anything that schedules inference on the Compute Mesh, reads which mining lane produced what, stakes into the network, or writes to the Signal Ledger. Those are not things the EVM has words for, and reaching them from that side means going through the router every time.
The choice is not permanent, because the two can call each other. It is just cheaper to start on the right side than to move later.
ATHERON-EVM ATHERON-WASM
solidity, vyper rust
existing ethereum tooling native cli and sdk
what you would put here what is already here
ported contracts the compute mesh
token standards governance and timelock
anything with a library the signal ledger
anything with an audience staking and lane data
reaching the protocol reaching the protocol
through the router directly, via precompilesThe right-hand column is not a list of what we would like to build there. It is what the network itself is written in. The Compute Mesh runs as native contracts rather than as hardcoded protocol rules, which is why its behaviour can be changed by a vote instead of a hard fork, and why that engine's audit carries the mesh's weight as well as its own.
It would have been easier to ship the two engines first and add the router in an upgrade six months later. That was a real option and we turned it down.
Shipping it at mainnet costs us: more to build, more to integrate, more to audit, and a longer run-up before launch. What it avoids is an ecosystem that spends its first year in two halves that cannot reach each other, and a migration afterwards that nobody enjoys and some people never do.
It launches behind a conservative list of permitted call patterns rather than wide open, and that list widens after a stability period. That is the compromise: shipped and integrated on day one, but not with more surface exposed than it needs.