Skip to content
ATON
DevelopersNothing is live yet. Watch it get there.

Most of it ports.
Some of it does not.

The EVM engine takes the Solidity you already have and the tools you already use, without a rewrite and without a dialect. What is different is underneath: what gas costs, how long a block takes, and the order things arrive in.

Of the 9 things a project brings with it, 5 carry over untouched, 3 keep working while returning different answers, and 1 is not on that engine at all. The middle group is the one that costs people a weekend.

EVM engine
Standard eth_*
wallets and tooling unchanged
Native engine
Rust and cargo
protocol calls, no bridge
Client library
TypeScript
browser and Node
Open to everyone
Testnet Beta
month six of the build plan

SDKs and tooling

Two engines, and no wrong answer between them

They share one account model and one state, so a contract on either side is looking at the same balances as a contract on the other. Picking one is a question about your team and your deadline, not a bet on which half of the chain survives.

The EVM engine

The path of least resistance, and there is no penalty for taking it.

  • You have Solidity and would rather not rewrite it
  • Your users expect MetaMask and your team expects Hardhat or Foundry
  • You want the option of deploying the same contract elsewhere later
  • You would like to be live this afternoon rather than next month

The native engine

Where the things this chain has that other chains do not actually live.

  • You need to call staking, mining or compute directly, not through a wrapper
  • You are writing something performance-sensitive enough for it to matter
  • You want the protocol as a library rather than as a counterparty
  • You would rather write Rust
# the EVM side, once Testnet Beta is up
forge create src/Thing.sol:Thing --rpc-url <beta rpc>
# or hardhat, or remix, or whatever you already run

# the native side
cargo new --lib thing && cd thing
cargo atheron build          # wasm module + manifest
cargo atheron test           # against a local node
cargo atheron deploy --net beta

# from a browser or from Node, either engine
import { Atheron } from "@atheron/sdk";
const chain = new Atheron({ network: "beta" });
await chain.contract(addr).call("balanceOf", [who]);

Written the way it is intended to work rather than copied from a terminal, because none of these commands exist yet. They land with Testnet Beta, together, and this page will say so when they do.

Network parameters

Separate IDs, chosen but not yet filed

Testnet and mainnet carry different chain IDs, and that is a safety requirement rather than administration. A signed transaction includes the ID of the chain it was meant for. If two networks shared one, something you signed on testnet could be replayed against mainnet by anyone who saw it, and your wallet would have no way to object.

Both IDs and both short names were checked against the public registry and were unclaimed. They will be checked again immediately before the registration is filed, because a collision discovered after launch takes a hard fork to resolve rather than an apology.

Publishing them now, long before there is anything to connect to, gives anyone building against Atheron a fixed target instead of a moving one. The RPC and explorer URLs are the parts that do not exist yet, and they are filled in at Testnet Beta.

Testnet
28661
aton-test
Live month 3 · none value
Mainnet
2866
aton
Live month 9 · real value

There is a third network. Devnet is where the chain produces its first blocks, and it is reset whenever it suits us, never opened to outside nodes and never carries value. Its ID is not published and is not meant to be connected to, so listing it here would only invite traffic we would then have to turn away.

{
  "name": "Atheron Mainnet",
  "shortName": "aton",
  "chain": "ATON",
  "chainId": 2866,
  "networkId": 2866,
  "nativeCurrency": { "name": "Atheron", "symbol": "ATON", "decimals": 18 },
  "rpc": ["published with Testnet Beta"],
  "explorers": ["published with Testnet Beta"]
}

Eighteen decimals, because every piece of tooling in the ecosystem assumes it and being interesting about that would cost more than it could possibly gain.

Testnet and faucet

What you can actually use, and when

Right now: nothing. That is the honest answer and it stays the honest answer until month three. Here is the order things open up in, and what is genuinely missing at each stage rather than what is nearly ready.

Testnet Alpha

Month 3Closed

Consensus and mining only. No contracts, no engines, no faucet. It exists to answer one question with real data rather than a simulation: whether the block rate we are targeting is actually safe. Open to the two capped Launchpad tiers and to researchers working the mining bounty.

ConsensusBoth mining lanesEVM engineNative engineRouterFaucetExplorerSDKs

Testnet Beta

Month 6Anyone

The one to point your tools at. Both engines, the router between them, a faucet, the explorer, the SDKs and the documentation all land together, because shipping an SDK against an endpoint that does not exist yet helps nobody. Beta keeps running through mainnet and past it.

ConsensusBoth mining lanesEVM engineNative engineRouterFaucetExplorerSDKsReal value

Mainnet

Month 9Anyone

Fair launch, and it does not happen until every audit is closed and testnet has real continuous runtime behind it rather than a demonstration week. If testnet slips, this slips with it, and we would rather say that here than explain it later.

Everything aboveReal valueCross-engine DEX pairs

The faucet arrives with Beta and hands out test tokens with no value, rate limited per address, which is the ordinary arrangement and works until somebody decides to be clever about it. If that happens the limit gets tighter rather than the faucet getting switched off.

Protocol spec

Written so somebody else could build this

The normative specification and its cross-implementation test vectors live in their own repository and go public alongside Testnet Beta. The bar we are holding it to is that a competent team should be able to write a second, independent node from the specification alone, without reading ours and without asking us anything.

That is a real bar and most projects quietly fail it. A protocol whose only complete description is its reference implementation is not a protocol, it is a program, and everyone else on the network is a user of our code rather than a participant in a shared set of rules. The test vectors are what makes the difference checkable: a second implementation either produces the same outputs or it does not.

Until that repository is public, this paragraph is a promise like any other. The date it can start being judged on is the date Beta opens.