Proof of Intelligence

Proof of Intelligence (PoI) is the mechanism that secures the AETRON network. Instead of spending compute on arbitrary puzzles like traditional Proof of Work, AETRON pays only for AI work it can prove was done correctly. Network security and token emission are anchored to verified, useful intelligence rather than wasted hashing.

The Core Guarantee

Every miner must provide a cryptographic proof that a computation ran exactly as declared: the same model, the same parameters, and the same execution settings. The network does not take a node's word for it, and it does not score work by opinion. Correctness is established mathematically.

This is the key difference from other decentralized AI networks, which rely on reputation or random spot checks. Those give only partial protection and break down against coordinated attackers. PoI composes several independent verification signals so that an attacker cannot find a single evasion strategy.

Why Proof of Work Does Not Fit

Proof of Work is easy to verify because the work itself is meaningless. A hash either falls below the target or it does not, and anyone can check it in microseconds. AI work has none of those properties:

• The result is useful, so an attacker gains by faking it rather than by discarding it.
• Re-running the full job to check it would double the cost of the whole network.
• Results are not bit-identical across different GPUs, so a naive equality check would reject honest miners.
• A cheaper model can produce a plausible-looking answer, so plausibility is not evidence.

PoI is built around those constraints. The check is partial (only a fraction of work is replayed), the comparison is tolerant within calibrated limits, and the object being compared is the internal state of the computation rather than the human-readable output.

What Gets Compared

Text output is not deterministic, because sampling introduces randomness. The probability distribution the model produces before sampling is deterministic for a given input and configuration. Two honest miners running the same model on the same prompt will emit different words but the same distribution. A miner that quietly swapped in a smaller model produces a distribution that is measurably different.

The same idea applies beyond language models. Diffusion models are pinned by hashes of intermediate latents at fixed steps, and encoder models by the hash of their output. In every case, the miner records a compact validation artifact and commits only its hash on chain. See Execution Spec for how the declared execution parameters are fixed so that a replay is reproducible at all.

Multi-Signal Composition

A single check, however good, gives an attacker one thing to optimize against. PoI stacks defenses that measure different things, so evading one does not help against the next.

1. Pre-checks. Before any compute is spent, the protocol validates the declared data type, model hash, hardware class, signature, and nonce uniqueness against the task's canonical spec. A mismatch here is rejected without ever running the model.
2. Compute checks. The replayed result is compared either bit-exactly inside one hardware class or against a calibrated tolerance across architectures, combined with quorum and composite signals that catch quantization tricks.
3. Continuity checks. When a model is split across several machines, hashes chain the activations passed between ranks, so a skipped, replayed, or modified segment breaks the chain.
4. Protocol checks. Output uniqueness rules stop a miner from replaying an answer it produced earlier, or one produced by a colluding peer on the same architecture.
5. Adversarial checks. For training work, weight and activation signals plus shadow replay against reference prompts catch backdoors and targeted misbehavior that leave normal metrics untouched.

Each layer was added in response to an attack that defeated the previous set. The layers measure orthogonal properties, so bypassing the whole composition requires evading all of them at once. Attack Resistance walks through the attack classes and which layer closes each one.

The Verification Protocol

Verification is distributed across the network. There is no separate validator role for AI work: miners re-check each other.

1. Execution

A miner serves the request and produces the answer off chain, in normal request time. Alongside the answer it records a validation artifact: the key states of the computation, the seed, and the model identity. Artifacts are small, on the order of a couple of hundred bytes per request. Nothing is written to the chain at this stage.

2. Batching

Artifacts are aggregated in two layers. Each miner builds a Merkle tree over its own artifacts and sends the root to the Neuronet owner. The owner builds a second tree over all miner roots and submits one aggregated root on chain for the whole Neuronet. A single transaction of roughly 200 bytes can commit a million requests, which keeps on-chain cost effectively independent of traffic volume.

3. Selection

The protocol picks which requests get replayed and who replays them, using verifiable randomness derived from chain state. Neither the executing miner nor the assigned checker can predict or influence the choice. The design target is a small sampling rate, around 7 percent of requests, low enough to be cheap and high enough that systematic cheating is caught quickly.

4. Replay

The assigned miner fetches the artifact from the executor, checks its Merkle proof against the committed root, and reproduces the computation. Replay is deliberately partial:

• For language models, one forward pass over the input reproduces the first generated token's distribution. For a 500 token answer that is about 0.2 percent of the original cost.
• For diffusion models, running 5 of 50 denoising steps and hashing the latent is about 10 percent of the original cost.
• For encoder models, the full run is cheap enough to repeat outright.

The comparison then runs against the tier configured for the task, either bit-exact or within calibrated tolerance.

5. Verdict

The checker submits its result on chain, roughly a hundred bytes, and only for the sampled requests. Matching work counts toward emission. A mismatch flags the job and puts the two miners into dispute.

What K-Quorum Gives

One comparison is a noisy signal. Hardware variance, an unlucky threshold, or a single dishonest checker can all produce a wrong verdict, and a verdict is what decides whether a miner earns or gets penalized. PoI therefore does not settle on one check.

A miner's verdict is decided over a quorum of independently assigned checkers. In the runtime the quorum size is 20 and the threshold is 10, so a fraud verdict requires at least half of the assigned checkers to report a mismatch. Two properties follow from this:

• False positives collapse. An honest miner near the tolerance boundary would have to fail against half the quorum, not against one unlucky pair, which makes accidental slashing very unlikely.
• Collusion gets expensive. Waving a cheater through requires controlling a majority of a randomly drawn set of 20 checkers, and the draw is fresh for every batch. A small colluding group cannot arrange to check itself.

The quorum also makes weak signals usable. Detection methods that are only partially reliable on a single job (quantization fraud is the usual example) become reliable once aggregated across the quorum, because the honest and fraudulent cases separate as the sample grows.

Enforcement and Disputes

Checking is not voluntary. At the end of an epoch the runtime looks at how many verifications a miner was assigned and how many it actually submitted. Reward is reduced in proportion to the ones it skipped, so ignoring assigned checks costs the miner directly.

When an executor and a checker disagree, the protocol assigns a third miner to replay the same request. The majority result stands, and the side that is out of line is penalized. A false accusation costs the accuser, which removes the incentive to attack a competitor by reporting fraud that did not happen.

Where to Go Next

• Inference Verification: how a miner's results are re-checked and compared in detail.
• Execution Spec: the canonical execution parameters that make a replay reproducible.
• Shadow Replay: why verification requests are indistinguishable from real user traffic.
• Heterogeneous Mining: how the same verification works across NVIDIA, AMD, Apple Silicon, and CPU, using two verification tiers.
• Attack Resistance: the attack classes PoI was tested against and the layer that closes each one.
• Privacy: how prompt and model confidentiality interact with a verification scheme that needs to re-run the work.
• Proof of Training: how model training, not only inference, is proven through Witnessed Checkpoints, including distributed Swarm Mode.