Technical Whitepaper

This document is not an offer. Nothing in it is an offer to sell, or a solicitation of an offer to buy, any security, token or other instrument, in any jurisdiction. There is no public sale of ATON, there has been no private round, and none is planned. ATON is acquired by mining it or, once listed, by buying it on the open market from somebody who did.

Nothing here is investment or financial advice. This document describes a protocol and a piece of software. It does not recommend any course of action and it makes no claim about the future value of anything. Automated trading, mining and holding a digital asset all carry the risk of losing money.

Forward-looking statements may not happen. Sections describing what will be built, when it will arrive and how it will behave are statements of present intention against a plan. They are not promises. Several depend on results that do not yet exist, and the document says so where that is the case. Dates in this paper are expressed as months from the start of the build rather than as calendar dates, for exactly that reason.

The regulatory position of ATON is unsettled and untested. Atheron Network Inc. is a British Columbia corporation. How ATON is classified in Canada, the United States or anywhere else has not been determined by any regulator or court, and nothing in this document is a legal opinion on that question. The project has taken the design decisions it believes reduce that exposure, which are described in this paper, and those decisions are not a substitute for a determination nobody has made.

Some parameters are not final, and are marked. Consensus parameters that depend on measurement rather than preference are given as targets with their resolution path stated. Section 30 lists every one of them in a single table so that no reader has to hunt for what is settled and what is not.

No warranty. The software described here is under development. It is provided, when it exists, without warranty of any kind. Access may be restricted in some jurisdictions and it is the reader's responsibility to know the rules that apply to them.

This document will be revised. Every revision is recorded in the project's public changelog with a date against it. The current version is stated on the cover.

Atheron is a Layer 1 blockchain whose graphics-card mining lane performs the same arithmetic as transformer inference, so the hardware that secures the chain is the hardware that runs the network's AI workloads. This paper specifies the protocol, the execution environment, the compute network layered on it, the decision-recording ledger that makes an AI trading engine's claims checkable, and the token that pays for all of it.

Proof of work is usually criticised for spending energy to produce a number that has no use beyond proving it was expensive to find. Atheron's second mining lane, Atheron-TMH, is built from FP16 matrix multiplication over a working set sized past typical GPU cache. Winning that lane requires the same hardware profile that runs transformer inference well: tensor cores and high memory bandwidth. That is the mechanical basis for the network's central claim, which is that a leased GPU can mine and serve inference from the same silicon, and that the operator can choose between them on price.

On top of that sits a dual virtual machine execution layer, giving both an EVM for compatibility with existing tooling and a native WebAssembly engine with precompiles reaching directly into chain-specific state. A Compute Mesh schedules inference and oracle jobs across staked nodes with redundant execution and majority agreement. A Signal Ledger commits the decisions of the network's trading engine on-chain at the moment they are made, which converts an unverifiable claim about a track record into a record anybody can check.

The token, ATON, has a fixed hard cap of 15,000,000,000 and no public sale at any point. Eighty per cent is issued by mining on a smooth emission curve equivalent to a halving every four years. Section 23 gives every figure in units rather than percentages.

Three unrelated inefficiencies, which turn out to share a solution.

Proof of work produces heat and nothing else

The security of a proof-of-work chain comes from the cost of the work. That cost is real and the security is real, but the work itself is discarded the moment it has served its purpose. Attempts to fix this by making the work useful have generally failed on one of two counts: either the useful work is not verifiable cheaply enough to serve as consensus, or making it useful makes it centralising, because the useful version favours one operator's specialised hardware.

Atheron does not claim to have solved that problem in general. It makes a narrower move: the work stays conventional hash-finding, and is verified exactly as a hash is verified, but the shape of the computation is chosen so that the hardware which wins at it is the hardware the network separately needs for something else. The work is still thrown away. The machines are not.

Decentralised AI inference has no economic anchor

Several projects have built networks for distributing machine-learning inference across independently operated hardware. The recurring difficulty is demand: a network of GPUs with nothing to run is a network of idle GPUs, and operators leave. Bootstrapping requires a workload large enough to keep nodes paid before third-party demand exists.

Atheron's mesh has such a workload from the first day it runs, because the network's own trading engine is a continuous consumer of inference, and because the same redundant-execution machinery serves oracle requests for any contract on the chain. Mining rewards provide a floor under node economics while that demand grows.

An AI trading product cannot prove anything it claims

Every automated trading product in the market reports its own results. A reader has no way to distinguish a good record from a selectively presented one, because the party with the strongest incentive to shade the number is also the only party holding it. Screenshots, dashboards and self-published statistics are all the same claim wearing different clothes.

If a decision is committed to a public chain at the moment it is made, before its outcome is known, and if that commitment is produced by a redundant process the operator does not unilaterally control, the resulting record is checkable by anybody. That does not make a strategy good. It makes the claim about its past falsifiable, which is a different and much rarer property.

Five commitments that constrain everything after this point. Where a later section makes a choice that looks inconvenient, one of these is usually why.

1. 01Decentralised from the first block, not eventually. The devnet's founding Compute Mesh nodes are consumer graphics cards. Initial model fine-tuning runs on the mesh rather than on rented cloud capacity. This costs real capability at the start, and Section 11 states plainly what it costs.
2. 02Custody is never taken. The trading engine holds no funds and no keys. A user's exchange credentials are encrypted on their own machine with a key derived from a passphrase the project never sees. The project cannot recover them, which is the only durable evidence that it does not hold them.
3. 03Claims must be checkable rather than trusted. Where the project asserts something about its own behaviour, the mechanism that makes the assertion verifiable is built alongside it. The Signal Ledger is the largest instance of this principle.
4. 04Novel components are named as novel. Atheron-TMH and the cross-VM router are the two genuinely new pieces here. Both carry disclosed emergency-patch capability under timelock, and both are described in this paper as unproven.
5. 05Nothing ships to mainnet unaudited. Section 26 lists every component whose audit is a hard gate on the mainnet date rather than a task that can follow it.

Four layers, each usable without the ones above it.

 ┌──────────────────────────────────────────────────────────────────────┐
 │  APPLICATIONS                                                        │
 │  Trading engine · DEX · third-party dApps · analytics API            │
 ├──────────────────────────────────────────────────────────────────────┤
 │  SERVICES                                                            │
 │  Compute Mesh   ·  Oracle   ·  Signal Ledger  ·  Governance          │
 │  redundant execution, majority agreement, staked nodes               │
 ├──────────────────────────────────────────────────────────────────────┤
 │  EXECUTION                                                           │
 │  Atheron-EVM (revm)   ⇄ cross-VM router ⇄   Atheron-WASM (wasmtime)  │
 │  account-based state, shared by both engines                         │
 ├──────────────────────────────────────────────────────────────────────┤
 │  CONSENSUS                                                           │
 │  GhostDAG ordering  ·  dual-lane proof of work  ·  ATON settlement   │
 └──────────────────────────────────────────────────────────────────────┘

The consensus layer is a true Layer 1 in the ordinary sense: its own validator and miner set, its own native settlement asset, its own security, derived from no other chain. Supporting EVM bytecode is a property of the execution layer and does not change that, in the same way that it does not for any other EVM-compatible Layer 1.

Each layer is a genuine dependency of the one above and not of the one below. The chain functions with no mesh. The mesh functions with no trading engine. The trading engine is the mesh's first large customer rather than its justification.

GhostDAG ordering over an account-based ledger, tuned for high throughput from genesis rather than ramped into it later.

Why a DAG rather than a chain

A single-chain protocol must discard every block that arrives in parallel with the winner. That is what limits its block rate: raise the rate and the orphan rate rises with it until security degrades. GhostDAG, from the PHANTOM family, keeps parallel blocks instead of discarding them. It identifies a well-connected subset of the DAG, the blue set, using an anticone constraint, and derives a total order over every block from it. Blocks that would have been orphaned still contribute their transactions and still earn.

The practical consequence is that block rate stops being bounded by propagation delay in the way it is on a single chain. The cost is a more complex ordering rule and a parameter, the anticone constraint, that must be tuned against real propagation behaviour rather than chosen from preference.

State model

GhostDAG governs ordering, not state representation. The closest reference implementation uses a UTXO ledger, but that is a choice layered on top rather than a requirement of the algorithm. Because the EVM cannot function without account-based state, Atheron's base ledger is account-based from genesis. Mining rewards, mesh payouts and staking all credit and debit account balances directly.

Parameters

The project has decided its tuning philosophy: target high throughput from genesis rather than launching conservatively and raising the rate later by network upgrade. That decision is made. The numbers it implies are not, because they are not the kind of thing that can be decided by preference.

What a block commits to, how a node validates one, and what changes because blocks arrive in parallel rather than in a line.

Header

The header is what a miner searches over and what a verifier checks. It commits to the parent set rather than to a single parent, which is the structural difference between a DAG protocol and a chain.

 BlockHeader
   version           u16     protocol version
   parents           [Hash]  the DAG parent set, not a single parent
   merkle_root       Hash    transactions in this block
   state_root        Hash    account state after applying this block's order
   utxo_commitment   —       absent; the ledger is account-based
   timestamp         u64     milliseconds
   lane              u8      0 = Atheron-B3, 1 = Atheron-TMH
   bits              u32     compact difficulty target for that lane
   nonce             u64     the searched value
   blue_score        u64     cumulative blue-set weight, from ordering
   pruning_point     Hash    the checkpoint this block builds past

Two fields deserve comment. parents is a set because a block may reference every tip it saw, and referencing more of them is what lets parallel work be kept rather than orphaned. lane selects which proof-of-work function the header is validated under, and is committed inside the header so a block cannot be replayed against the other lane's difficulty.

Validation order

1. 01Structural checks. Header well-formed, parents known, timestamp within the permitted drift, lane value valid.
2. 02Proof of work. Recompute the lane's function over the header and check the result against bits. For Lane A this is a BLAKE3 evaluation. For Lane B it is the full tensor-memory-hard derivation, which is expensive to search and cheap to verify only once.
3. 03Difficulty. Check bits against the retarget schedule for that lane independently of the other lane.
4. 04Ordering. Compute the block's position in the virtual chain by GhostDAG's rule and derive blue_score.
5. 05Execution. Apply the block's transactions in the derived order and check the resulting state_root.
6. 06Pruning consistency. Check the block builds past a pruning point the node accepts.

Ordering and finality

GhostDAG produces a total order over the DAG by identifying the blue set and walking it. A node's view of that order can change as blocks arrive, in the same way a chain can reorganise, but the depth at which it stops changing is a function of the anticone constraint and the block rate rather than of a fixed confirmation count.

Finality in practice is therefore probabilistic and deepening, with pruning-point checkpoints providing a floor past which reorganisation is not accepted. The confirmation depth that corresponds to a given confidence is a measured property, not a design choice, and it depends on the same parameters Section 30 lists as open. Publishing a confirmation count before measuring one would be stating a preference as a fact.

Data availability and pruning

Full history growth at a high block rate is a real operational constraint, not a footnote. Nodes prune past the pruning point, retaining headers and the state needed to validate forward. Archive nodes retaining everything are expected to exist but are not required for consensus. The pruning window is a tuning item measured against real storage growth on testnet.

Two independent proof-of-work functions, each producing half the block reward, each retargeting separately, with a dampener that stops either lane taking the network.

Lane A — Atheron-B3

A BLAKE3-based proof of work. Nonce search over a block header committing to the DAG parent set and the state root. It is deliberately ASIC-favourable. That is the lane's purpose: specialised hardware is efficient, it is durable, and a network with an ASIC lane has a class of participant whose capital is committed to that network specifically.

Lane B — Atheron-TMH, tensor-memory-hard

The novel component. The function is constructed so that the hardware which computes it efficiently is the hardware that runs transformer inference efficiently.

1. 01BLAKE3 expands the block header and nonce into a seed.
2. 02The seed deterministically generates a large pseudo-random weight matrix, with a working set of 512MB to 1GB, sized past typical GPU L2 cache so that memory bandwidth rather than cache residency is the binding constraint.
3. 03N rounds of FP16 or BF16 matrix multiplication run over that matrix. This is the same arithmetic and the same memory access pattern as transformer inference.
4. 04A final BLAKE3 pass compresses the resulting tensor state into the candidate block hash.

Verification is cheap in the way proof of work requires: a verifier reruns the derivation from the header and nonce and checks the result. The expensive part is finding a nonce, not confirming one.

Anti-monopoly balancing

Each lane retargets difficulty independently, approximately every 2,880 blocks. On top of that sits a lane-balance dampener: if either lane produces more than 65% of blocks over a trailing 2,016-block window, its next retarget receives an additional corrective multiplier. Both thresholds are stated here as the current design and both need testnet simulation before they are fixed.

The purpose is not to force an even split, which would be arbitrary, but to stop one lane's economics collapsing the other's. A network where one lane has become irrelevant has the security properties of a single-lane network while carrying the complexity of two.

Each lane retargets on its own schedule, with a corrective term that engages only when one lane is taking the network.

Independent retargeting

Each lane retargets approximately every 2,880 blocks of that lane, against that lane's own observed rate and its own share of the target block interval. The lanes do not share a difficulty. An ASIC farm arriving on Lane A raises Lane A's difficulty and leaves Lane B untouched, which is the intended behaviour: the lanes are separate markets for separate hardware.

The dampener

Independent retargeting alone permits a stable state where one lane produces nearly every block, because each lane retargets to its own rate regardless of the other's share. The dampener is what prevents that.

 at each retarget for lane L:
     share = blocks_from_L over the trailing 2016-block window
                     ÷ all blocks in that window

     base  = standard retarget factor for lane L

     if share > 0.65:
         factor = base × corrective(share)      # raises L's difficulty further
     else:
         factor = base

 corrective() is monotonic in share and equals 1.0 at the threshold,
 so the dampener engages smoothly rather than as a step.

The 65% threshold and the 2,016-block window are the current design and both need testnet simulation against realistic two-lane economics before they are fixed. They are on the open-parameter list.

Two virtual machines over one account-based state: an EVM for the tooling that already exists, and a WebAssembly engine for the things only this chain can offer.

Atheron-EVM

Built on revm, a mature Rust implementation of the EVM also used by Reth and Foundry. Embedding a known-good implementation is a substantially lower risk than writing one, and the EVM is not a component where novelty is rewarded.

• Standard Ethereum JSON-RPC over the eth_* namespace, so MetaMask, Hardhat, Foundry, ethers.js and web3.js work against Atheron with no new tooling for a Solidity developer.
• Native ATON is the gas token inside the EVM environment, represented as an 18-decimal wei-equivalent. This is the same pattern every non-Ethereum EVM Layer 1 uses.
• The chain ID is reserved early through the public registry at chainid.network, so wallets, explorers and tooling can be built against a stable, collision-free identifier well before mainnet rather than in the days before it.

Atheron-WASM

Built on wasmtime, with an Atheron-specific contract ABI and a Rust SDK. Developers write contracts in Rust, compile to wasm32-unknown-unknown and deploy through a native CLI. The design is in the spirit of CosmWasm and ink! rather than a new paradigm.

What the WASM engine has that the EVM side does not is native precompiles reaching directly into chain-specific state: Compute Mesh job submission, staking operations, mining-lane statistics and the Signal Ledger. A contract that needs to schedule an inference job and act on the result is a WASM contract. A contract that needs an existing Solidity library and an audience of Solidity developers is an EVM contract. Both are first class.

The Compute Mesh's own staking, job-assignment and slashing logic is itself implemented as native WASM contracts rather than hardcoded consensus rules. That is a deliberate trade: a newer and less battle-tested execution path now, in exchange for the ability to change mesh mechanics by contract upgrade rather than by hard fork later. It also makes the WASM engine's audit a hard gate on mainnet rather than a desirable extra.

Cross-VM router

By default the two engines are separate state machines. Letting an EVM contract call a WASM contract, or the reverse, requires a router that translates calls and return data between two ABIs with different type systems, different gas accounting and different failure semantics.

The router ships at mainnet. That is a decision, and it is a decision that moves the mainnet date rather than one that can be deferred past it. Every comparable dual-VM chain has found its hardest bugs in exactly this translation layer.

• Multiple independent audit passes on the router specifically, not only on the two engines individually.
• A public testnet period long enough for adversarial cross-VM call fuzzing, rather than each engine tested in isolation.
• A conservative allowlist of permitted cross-VM call patterns at mainnet, widened after a stability period, rather than an unrestricted router on day one.

Gas abstraction

A native account-abstraction layer following the well-established ERC-4337 pattern lets a dApp sponsor its users' gas, or lets a user pay gas in a token other than ATON with conversion handled underneath. A new application can therefore onboard somebody who has never held ATON. The pattern is proven elsewhere, so this is engineering effort rather than novel risk.

The account model both engines share, how work is metered, and what a transaction can be.

Account model

One account space, shared by both virtual machines. An account holds a balance in native ATON, a nonce, and, where it is a contract, code and storage. Mining rewards, mesh payouts, staking movements and slashing all credit and debit these balances directly. There are no UTXOs anywhere in the system.

Because the space is shared, an address means the same thing to both engines. A balance is not duplicated per VM and does not need bridging between them. What needs translating at the router is calls, not value, which is a materially smaller problem than a chain running two ledgers would have.

Gas

• One gas token. Native ATON, represented inside the EVM as an 18-decimal wei-equivalent, the same pattern every non-Ethereum EVM Layer 1 uses.
• Two schedules. The EVM meters by the Ethereum gas schedule so that existing contracts behave predictably. The WASM engine meters its own instruction and host-call costs. A cross-VM call is metered on both sides of the boundary, and the router's own translation cost is charged to the caller.
• Fees go to miners, with a portion to stakers under the fee-sharing parameter, which is governable rather than fixed in this paper.
• Gas abstraction lets a dApp sponsor its users' gas, or lets a user pay in another token with conversion underneath. The pattern is ERC-4337-shaped and well proven elsewhere, so it is engineering rather than novel risk.

Transaction types

State growth

A high block rate produces state and history faster than a slow one, and this is a genuine operational cost rather than a rounding error. Nodes prune past the pruning point, keeping headers and the state needed to validate forward. The pruning window is measured on testnet against real growth rather than assumed, and it appears on the open-parameter list for that reason.

A network of staked nodes that executes inference and oracle work redundantly, agrees on results by majority, and pays for them in ATON.

How a job resolves

1. 01A job is submitted, either by the trading engine, by a third-party dApp through the Developer Platform, or by any contract needing an oracle reading.
2. 02The job is replicated to N nodes, N=5 by default.
3. 03Each node computes independently and returns a result hash.
4. 04Three matching hashes out of five finalises the job and releases payment.
5. 05A node returning a non-matching result is slashed 2% of its stake.
6. 06For trade-triggering work, N rises to 9 with a threshold of 6.

The redundancy factor is what turns a set of independently operated machines into something whose output can be relied on without relying on any one of them. It is also what makes the same machinery usable as an oracle with no new trust assumption: a price feed answered by five independent nodes that must agree is exactly the structure already built for inference.

Node economics

The local scheduler

Each node runs a scheduler that arbitrates its GPUs between Lane B mining and compute jobs, on operator-set profitability thresholds. This is the point where the whole design becomes concrete: the operator does not choose between mining and serving inference when they buy the card. They choose continuously, on price, and the card does whichever is worth more at that moment.

Reputation

Beyond raw stake, nodes accumulate a record of historical accuracy, uptime and latency, which feeds job-matching priority. Higher-reputation nodes are matched preferentially to higher-value and latency-sensitive work, including oracle requests where staleness matters most. Reputation is a reliability mechanism layered on the stake model rather than a replacement for it, and it is its own audit item.

Third-party access from mainnet

Third-party developers can submit arbitrary inference jobs from mainnet day one, not as a later phase, and can eventually deploy their own fine-tuned models for the network to serve. The mesh is intended as a general decentralised compute utility rather than the trading engine's private backend. Service level tiers, offering guaranteed redundancy and latency for paying workloads, attach to that.

How a unit of work moves from submission to payment, and what happens at each way it can fail.

 submit ──► assign ──► execute ──► collect ──► agree ──► settle
    │          │          │           │          │          │
    │          │          │           │          │          └─ pay agreeing nodes,
    │          │          │           │          │             slash disagreeing ones
    │          │          │           │          └─ threshold met?
    │          │          │           │             N=5 → need 3
    │          │          │           │             N=9 → need 6   (trade-triggering)
    │          │          │           └─ result hashes returned within the deadline
    │          │          └─ each node computes independently, no gossip between them
    │          └─ N nodes chosen by stake tier, reputation and current load
    └─ job, its class, its redundancy requirement and its fee

Assignment

Nodes are selected on three criteria: stake tier, which bounds the value of work a node may be given; reputation, being the accumulated record of accuracy, uptime and latency; and current load, so that a single fast node does not accumulate the whole queue. Selection is deliberately not purely highest-stake, because that converges on centralisation among the largest operators.

Isolation during execution

Assigned nodes do not communicate. Each computes independently from the job specification and returns only a result hash. If nodes could see each other's results before committing, the majority requirement would collapse into whichever node answered first, and the redundancy would be theatre.

Failure modes and what happens

Determinism is a requirement, not a preference

Redundant execution with hash comparison only works if honest nodes computing the same job produce byte-identical output. For inference this is a real engineering constraint: floating-point reduction order, library versions and hardware differences can all produce results that differ in the last bits and therefore differ entirely once hashed.

The same redundant-execution machinery, pointed at data instead of inference, with no new trust model.

A contract needing an external reading, a price, a rate, anything off-chain, submits an oracle request as a mesh job. The request is replicated across N nodes, each fetches and returns, and a majority must agree before the reading is written. The economics, the staking, the slashing and the reputation weighting are the ones already described in Section 11.

Two things follow. The chain gets an oracle without importing a separate trust assumption or a separate set of paid operators, and GPU lessors get a second revenue line from infrastructure the project is already paying to audit. Oracle requests are latency-sensitive and stale readings are the failure mode that matters, which is why reputation weighting is applied most heavily here.

An on-chain record of every decision the trading engine makes, committed at the moment it is made, containing nothing that identifies the person it was made for.

Mechanism

When the trading engine's fusion layer produces an actionable decision, that inference job has already passed through the mesh's redundant-execution pipeline: nine nodes computed it, at least six agreed on a result hash. That finalised, already-decentralised result is the natural anchor. Rather than using it only to settle mesh payment, the engine commits a structured decision receipt into the Signal Ledger, a native WASM contract.

The property that matters is not that a record exists. It is that the record was produced by a process the operator does not unilaterally control and cannot quietly revise afterwards. A company writing its own results to its own database has produced a claim. A receipt committed through majority agreement, timestamped before the market moved, is a fact about what was decided and when.

What is recorded, and what is not

A public record of decisions is useful to everybody. A public record of positions would be a permanent liability attached to a named person, and no amount of usefulness would justify creating it. The input snapshot is committed as a hash rather than as data, which is enough to prove afterwards which inputs a decision was made from without publishing a market data feed.

What this does and does not establish

• Establishes: that a specific decision was made at a specific time, before the outcome was known, by a process that required independent agreement.
• Establishes: that the published history of decisions is complete, because an omitted decision would be a gap in an on-chain sequence.
• Does not establish: that the decisions were good. A verifiable record of being wrong is still a record of being wrong.
• Does not establish: what any individual made or lost. Two people acting on the same signal at the same moment can end up in very different places depending on size, venue, fees and timing, and the ledger deliberately holds none of those.

What a decision receipt contains, and the exact procedure a third party follows to check one.

Schema

 DecisionReceipt
   asset             AssetId    the pair the decision concerns
   direction         u8         0 buy · 1 sell · 2 hold
   confidence        u16        fixed point, 0 to 10000
   breakdown
     quant_score     i16        signed, fixed point
     sentiment_score i16        signed, fixed point
     fusion_weight   u16        the weighting applied at decision time
   model_version     [u8;32]    identifier of the exact model and runtime
   input_commitment  Hash       hash of the input snapshot, not the snapshot
   mesh_job          Hash       the mesh job whose agreement produced this
   timestamp         u64        milliseconds, from the ordering layer
   publisher         Option     present only for marketplace-published strategies

There is no field for the user, the account, the size, the price or the outcome. Not omitted at write time: absent from the structure, so a future change of policy cannot begin populating one.

Verifying a published record

1. 01Read the receipts for the strategy or publisher in question directly from the chain. Do not read a number from an interface.
2. 02Check each receipt's timestamp against the ordering of the block that contains it. A receipt cannot claim a time earlier than the block that carries it.
3. 03Check each receipt's mesh_job resolves to a settled job whose agreement threshold was met. A receipt whose job did not reach agreement is not a valid receipt.
4. 04Check the sequence for gaps. The record is a sequence, and a missing decision is visible as a discontinuity rather than as an absence.
5. 05If the input snapshot is later published, hash it and compare against input_commitment to confirm the decision was made from the data claimed.

Steps one to four require nothing but a node and are available to anybody. Step five requires the snapshot to be published, which is at the discretion of whoever holds it, and is the only step that is not unilaterally verifiable.

Two scoring engines feeding a fusion layer, executing non-custodially against the user's own exchange accounts, with every decision committed to the Signal Ledger.

Quant engine

Reads market structure across multiple timeframes and reduces it to a direction and a confidence. Its inputs are price and volume derived; it holds no view about news or sentiment. It is available on every subscription tier because a decision layer with only one engine is still a usable product.

Sentiment engine

A fine-tuned open-weight language model producing a structured sentiment and narrative score rather than free text. The base is from the Qwen family under Apache 2.0. Two properties drove that selection: strong multilingual reasoning, because sentiment that only reads English is sentiment that misses most of the market, and dense single-GPU deployability, which matches the mesh's actual hardware rather than requiring data-centre multi-GPU hosting.

Output is a structured score with a breakdown, not prose. A trading decision layer cannot consume an essay, and a system that produces one invites somebody to read it as advice.

Fusion and policy

The fusion layer combines the two scores under weights the user sets, then applies a policy layer holding the user's risk configuration: position sizing, per-asset and total exposure caps, and a drawdown threshold. The policy layer is the last thing between a score and an order, and it can only reduce. It never increases a position beyond what the user's settings allow, and where the configured limits leave no room, the decision recorded is to do nothing.

Custody

Exchange API credentials are encrypted with a key derived from a passphrase the user holds, and written to local storage on the user's own device. They are not synchronised, not backed up to any infrastructure the project operates, and not present in any database it runs. Orders are signed on the user's machine and sent to the user's exchange account. No funds pass through anything the project operates at any point.

The client checks the permissions attached to a submitted key and refuses to use a key carrying withdrawal permission, rather than accepting it and relying on a promise never to exercise it. The test of whether a non-custodial claim is real is whether the company can recover a lost key. Here it cannot, and that is the evidence rather than a caveat attached to it.

 user's machine                        │  atheron network
 ───────────────────────────────────── │ ────────────────────────────────
 passphrase ──► key derivation         │
                     │                 │
 api key ──────► encrypted at rest     │
                     │                 │
                     ▼                 │
              order signing ───────────┼──► user's exchange  (direct)
                                       │
 decision request ─────────────────────┼──► compute mesh
                                       │      9 nodes, ≥6 agree
                                       │            │
                                       │            ▼
                                       │    signal ledger  (on-chain)
                                       │    asset, direction, confidence,
                                       │    breakdown, model version,
                                       │    timestamp, input hash

Testing a rule set against a record that was committed before anybody knew the answer, which is a different exercise from testing against a vendor's own simulation.

A conventional backtest evaluates rules against data the vendor supplies, using a simulation the vendor wrote. Both halves are under the control of the party whose product is being evaluated. This is not usually fraud; it is that the degrees of freedom available to somebody producing a favourable curve are enormous and mostly invisible.

Backtesting against the Signal Ledger changes what is fixed. The decisions are already on-chain with timestamps that precede their outcomes, and they cannot be revised. A user varies their own policy layer, being sizing, caps and the drawdown threshold, and sees how the same immutable sequence of decisions would have been treated under those settings.

• Fixed: the decisions, their timing, their confidence and their breakdown.
• Variable: the user's own risk configuration.
• Not modelled and not claimed: fill prices, slippage, fees and venue behaviour, which are properties of the user's exchange and not of this system.

A hybrid venue, spot only, launching same-VM and connecting across the two engines once the router's allowlist widens.

Trading model

A hybrid design: a central-limit order book implemented natively in WASM, and automated market maker pools on both VM sides. The order book gives price-time priority for participants who want it; the pools give continuous liquidity for assets and sizes where a book would be thin.

Rollout shape

At mainnet the DEX trades same-VM only. EVM-side pools trade EVM-native assets; the WASM-side order book and pools trade WASM-native assets including ATON. Both are fully live. They are not yet cross-connected.

Cross-VM pairs, which unify liquidity across both engines, go live when the cross-VM router's conservative allowlist is widened after its stability period. This is not a reduction of ambition. It is that ambition sequenced behind a dependency the project already decided to de-risk, and pretending the two were independent would be the dishonest version.

Scope

Spot only. No leverage, no perpetuals, no synthetics, and no route to any of them. The regulatory position for decentralised derivatives venues is unsettled in a way that spot is not, and 2023 enforcement precedent against DeFi platforms for unregistered derivatives activity still stands. Building the capability first and asking afterwards is how projects arrive somewhere they did not intend to be. Derivatives are revisited only after dedicated legal review shows the picture for decentralised venues has actually settled, which is not a calendar commitment.

Design notes

• Oracle-secured pricing from the mesh for slippage protection on both the book and the pool side, reusing infrastructure already being audited rather than adding a trust assumption.
• Fair ordering is a stretch goal rather than a mainnet requirement. Because Atheron controls its own base consensus, batch-auction or encrypted-mempool ordering is genuinely achievable here in a way it is not for a venue bolted onto somebody else's chain. It is also cutting-edge work industry-wide, with real research risk, and this paper declines to promise it.
• Permissionless contracts, gated official front end. The contracts stay open to anybody. The project's own interface applies geo-blocking and address screening, the same split several established venues use.
• Fee sharing with ATON stakers, not only with market makers and liquidity providers. Fee parameters are governable rather than fixed in this paper.

What a third party can build on this chain, and which of the two engines they should reach for.

Surfaces

Choosing an engine

Use the EVM when the value is in existing code, existing libraries or an existing audience of Solidity developers. Use WASM when the contract's purpose involves something only this chain has: scheduling inference, reading which lane produced what, staking into the mesh, or writing to and reading from the Signal Ledger. The cross-VM router means the choice is not permanent, but it is cheaper to start on the right side.

Contribution policy

The project's own repositories are closed to outside pull requests during development. Interfaces are moving week to week and several components are heading into independent audit; merging outside changes into that puts both the reviewer and the contributor in a poor position. This changes when the specification settles and the first audits return. It is stated here because a developer platform that quietly closes its own repositories is worse than one that says so.

What each role requires in practice, so a reader can work out whether any of it applies to them before reading further.

Hardware, honestly

Lane B is designed so that a consumer card with tensor cores is a viable participant. The founding mesh is two such cards. That said, mining is a market: a viable participant is not the same as a profitable one, profitability depends on electricity price and on what everybody else brings, and this paper makes no claim about returns to any hardware.

The working set is deliberately sized past typical GPU L2 cache so that memory bandwidth binds rather than cache residency. A card with high compute and narrow memory will underperform its raw specification here, which is intended: the hardware profile being selected for is the inference profile, and inference is bandwidth-bound too.

What connects to other networks, and the significant thing that deliberately does not.

What exists

• Ethereum tooling compatibility at the JSON-RPC layer, so wallets, explorers, indexers and development frameworks work unchanged.
• Registered chain IDs for all three networks, so signed transactions cannot be replayed across them.
• Exchange connectivity in the trading engine, which is not a chain interoperability feature at all: the engine talks to centralised exchanges through the user's own API credentials, off-chain, and nothing about that touches the protocol.

What does not exist, on purpose

Stake-weighted on-chain voting for treasury and mesh parameters, plus a disclosed, scope-limited emergency capability over the two novel components.

The governance module

A native WASM contract following the governor pattern: proposal, stake-weighted vote, timelock, execution. Its scope at version one is treasury disbursement and Compute Mesh parameter changes, meaning stake amounts, slashing percentages and redundancy factors. That scope is not incidental: the treasury is already committed to milestone or governance-gated release, so a governance mechanism is a dependency of the tokenomics rather than an addition to them.

The safety valve, described rather than hidden

Atheron-TMH and the cross-VM router are the two components this paper has repeatedly named as novel and unproven at scale. Deploying either with no ability to patch means that a critical bug found after launch can never be fixed. A founder-controlled multisig therefore retains a scoped emergency-patch capability over those two components.

This is standard progressive decentralisation rather than something unique to this project, and it is described in every public document rather than mentioned in one. A reader who regards any admin capability as disqualifying now has the information to conclude that, which is the point of stating it.

Consensus-level changes beyond those two components stay with the core team until the network has enough independent validators that governance capture is not a realistic concern. Moving that boundary is itself a later governance decision.

A fixed cap of fifteen billion ATON, no sale of any kind at any point, and eighty per cent of it issued by mining on a schedule fixed at genesis.

Allocation, in units

Emission

The subsidy decays by 1.43% per month, smoothly, rather than halving in discrete steps. Over 48 months that compounds to a factor of 0.500897, which is a halving to within 0.18%. Over roughly 132 years it produces about 33 halving-equivalents. The cadence and the total lifetime therefore match Bitcoin's closely, and can be explained to anybody in those terms, while avoiding a discrete cliff.

The smoothness is not cosmetic. A literal 50% cliff applied across two independent mining lanes risks destabilising whichever lane is more economically marginal at that moment. A monthly decay reaches the same place without ever presenting that edge.

Vesting and unlocks

The treasury is deliberately absent from the supply curve in Figure 2. It has no schedule: it releases against milestones or by governance vote, and drawing a curve for it would imply a timetable that does not exist. The consequence is visible in that figure as the gap between where circulating supply settles, about 14,100,000,000, and the 15,000,000,000 cap.

Where fees go

How the pieces pay for each other, and where the assumptions are.

The three income streams a node can hold

1. 01Lane B block rewards. Half of each month's subsidy, divided among GPU miners by share of that lane's work.
2. 02Compute Mesh job fees. Paid per job by the trading engine, by third-party dApps and by oracle consumers, to the nodes that executed and agreed.
3. 03Reputation-weighted priority, which is not itself income but determines access to the higher-value job tiers.

A Lane A miner holds only the first. That asymmetry is intentional: the GPU lane is the one whose hardware has a second use, and the design's central claim is about that second use existing.

The scheduler's decision

A node's local scheduler compares, continuously, the expected value of mining the next interval against the expected value of taking available compute work, and allocates the GPU accordingly against operator-set thresholds. Three consequences follow, and they are worth stating because they are the mechanism rather than the marketing:

• Mining sets a floor under compute pricing. A node will not accept inference work priced below what mining would return, so compute fees cannot fall below mining economics without capacity leaving for the lane.
• Compute demand raises the cost of attacking Lane B. Capacity absorbed by paid inference is capacity not available to rent for an attack, and the attacker is bidding against a real buyer rather than against a subsidy alone.
• The two markets are coupled, in both directions. A collapse in compute demand pushes capacity back to mining and raises lane difficulty. A collapse in token price pushes capacity toward whichever is still paying. This coupling is the design's strength and is also a transmission path for shocks, which Section 31 lists as an economic risk rather than omitting.

Where the fees actually go

Section 23 gives the fee table. The point worth repeating here is what is absent: no fee stream is routed to token holders as a share of company revenue. Subscription income is ordinary corporate revenue. Staker fee-sharing applies to on-chain fees, being gas and DEX fees, which are network fees rather than company earnings. The distinction is deliberate and Section 23 explains why.

An honest gap

What this borrows, what it does differently, and where somebody else got there first.

Which components must be independently audited before mainnet, which are continuing commitments rather than one-time checks, and what is being relied on that has never been attacked.

Hard gates on the mainnet date

Each of the following must have completed independent audit before mainnet. These are not tasks that can follow the launch, and the mainnet date moves if one of them is not finished.

Continuing commitments, not one-time checks

• Cross-VM call fuzzing through a public testnet period long enough to be adversarial, rather than each engine tested alone.
• A standing bug bounty, separate from the pre-launch per-component bounties, so that the incentive to report rather than exploit persists after launch.
• Red-teaming of the fraud and sybil scoring as an ongoing commitment. Reward-farming technique evolves, and a system audited once is audited against last year's attacks.
• Re-audit on change. Any change to an audited component returns it to the queue. Audit is a property of a specific commit, not of a component name.

Operational security posture

• No component of the trading engine's model or inference path is published, and no key material of any kind is held by the project on a user's behalf.
• Security reports are handled through a published disclosure process and never through public channels. A vulnerability posted in a chat room is a vulnerability disclosed to whoever intends to use it.
• The decentralisation statement in Section 03 is a security property, not marketing: the chain, the mesh, the DEX and the Signal Ledger depend on no infrastructure the company operates, so the company failing does not take them down.

Who might attack this, what they would attack, what stops them, and where the honest answer is that nothing yet does.

Assumptions

• An adversary may control a substantial fraction of one lane's hashrate, may operate many mesh nodes, may submit arbitrary transactions and jobs, and may observe all network traffic.
• An adversary cannot break BLAKE3, cannot forge signatures, and cannot compel an honest node to run modified software.
• A user's own machine is outside the protocol's control. A compromised user device is a compromised user, and no protocol property recovers from it.

Attacks on consensus

Attacks on the Compute Mesh

Attacks on the Signal Ledger

Attacks on users

These are outside the protocol and are the ones most likely to actually cost somebody money, which is why they appear in a technical paper rather than only in support documentation.

• Impersonation and phishing. The most common and most effective attack on any crypto community. The project's standing rule is that no member of its team sends a first direct message to anybody, stated everywhere so that a message claiming otherwise is self-refuting.
• A compromised user device. Keys live on the user's machine, so malware there is inside the boundary the custody model describes. This is the cost of non-custodial design and it is not recoverable by anything on the protocol side.
• A key with withdrawal permission. The client refuses such a key rather than accepting it and promising restraint. That refusal is a product decision doing security work.
• Exchange failure. The user's venue holds their funds. Non-custodial design removes the project as a counterparty and does not remove the exchange.

Eight phases. Dates are expressed as months from the start of the build, because a calendar date implies a confidence nobody has.

What each network stage is for, and specifically which open parameters it is expected to close.

What a failed measurement means

If testnet shows the target block rate is not safely achievable at any anticone value, the response is to lower the genesis target or to delay mainnet. It is not to launch on the target and hope, and it is not to redefine safety. That is stated here so that a reader can hold the project to it later, which is the only reason to write such a sentence down.

Everything in this paper that is not yet fixed, in one table, with what settles it. Nothing on this list is resolvable by preference.

The failure modes a reader should weigh. This section is not a formality and it is not exhaustive.

Technical

• Atheron-TMH is unproven. If a shortcut attack exists, the GPU lane's security assumption fails and the algorithm has to be replaced under the emergency capability, which is disruptive even when it works.
• Reduced-precision non-determinism. FP16 and BF16 behaviour differs across vendors and driver versions. If the function is not bit-exact across the hardware that mines it, the network forks along hardware lines. This is a specific and named audit item.
• The cross-VM router ships at mainnet. It is the component most likely to carry a serious bug, and it is being launched rather than deferred.
• The target block rate may not be achievable safely. The stated response is to delay or lower the target. That response has a cost and it is the honest one.
• Account-based state on a GhostDAG client is a genuine deviation from the reference implementation, and the core state machine has to be built rather than adapted.

Economic

• Emission is front-loaded. Half the mining allocation is issued in four years. If network value has not grown by the time the subsidy has fallen substantially, security spend falls with it. This is the same shape Bitcoin has and the same risk it carries.
• Two lanes can become one. If one lane's economics collapse, the network has the security of a single-lane chain and the complexity of two. The dampener is intended to prevent it and has not been tested against real markets.
• Mesh demand may not arrive. The trading engine and mining rewards underwrite node economics at the start. If third-party demand does not follow, the mesh is an expensive way to run one product's inference.
• The treasury has no schedule. That is deliberate, and it means the market cannot price a known unlock in advance. Governance discretion is a governance risk.

Regulatory

• ATON's classification is untested in every jurisdiction that matters. The design decisions in this paper are intended to reduce that exposure and are not a determination by anybody with the authority to make one.
• The strategy marketplace may constitute regulated activity. Listing strategies for others to follow, and ordering them, resembles activity that several regimes treat as investment advice or as managing money. It needs dedicated counsel review in both Canada and the United States before it opens, and that review has not concluded.
• Operating exchange infrastructure raises its own questions, distinct from token classification: money-transmitter characterisation in the United States and dealer or marketplace registration in Canada.
• Jurisdictional access may have to be restricted, and the official front ends apply geo-blocking and address screening accordingly.

Execution

• The founding hardware is two consumer graphics cards. The scale-up path is real and is dependent on community capacity arriving.
• The schedule is estimates against a plan and plans in this field slip. The tracker exists so that slippage is visible rather than announced.
• Several components are being built simultaneously by a small team, and the mainnet gate requires all of the hard-gate audits to close.

Anticone

The set of blocks in a DAG that are neither ancestors nor descendants of a given block. Its permitted size, k, is the parameter that bounds how much parallelism the ordering rule tolerates.

Blue set

The well-connected subset of the DAG that GhostDAG identifies and orders. Blocks outside it still contribute transactions.

Cross-VM router

The translation layer letting a contract on one virtual machine call a contract on the other.

Compute Mesh

The network of staked nodes executing inference and oracle jobs redundantly, with majority agreement.

Decision receipt

The structured record the trading engine commits to the Signal Ledger when the fusion layer produces an actionable decision.

GhostDAG

The consensus protocol, from the PHANTOM family, that orders a directed acyclic graph of blocks rather than a single chain.

Lane A, Atheron-B3

The BLAKE3-based, ASIC-favourable mining lane.

Lane B, Atheron-TMH

The tensor-memory-hard, GPU-favourable mining lane whose arithmetic matches transformer inference.

Non-custodial

The property that the operator holds neither funds nor keys, evidenced here by the operator being unable to recover a lost key.

Precompile

A native function exposed to contracts, used on the WASM side to reach chain-specific state directly.

Pruning point

A checkpoint past which historical DAG data may be discarded by a node.

Redundant execution

Running the same job on N nodes and requiring a threshold of matching results before accepting it.

Signal Ledger

The on-chain contract holding decision receipts.

Slashing

Confiscation of a portion of a node's stake for returning a result that disagrees with the majority.

Virtual chain

The totally ordered sequence GhostDAG derives from the DAG, against which state transitions are applied.

This paper is revised as the project moves. Every revision is recorded in the project's public changelog with a date. The version in force is stated on the cover. Where this document and the public build tracker disagree about status, the tracker is correct.

A plain-language companion covering the same project without the specification detail is published alongside this paper. Where the two disagree on a fact, this one is the reference, and the disagreement is a defect to be reported.

Year by year, computed from the 1.43% monthly decay. Subsidy is the amount issued in the final month of that year. Circulating includes mined issuance, vested team tokens and the liquidity reserve, and excludes the treasury, which has no schedule.

Every numeric parameter in this document in one place, with its status.