← All posts
7 min read

The Soul Ledger: an AI that signs its own changing mind onto the chain

Every ~500 blocks, Aether fingerprints its own cognitive state, personality traits, phi, and training loss, to an append-only on-chain ledger. How the soul ledger works, and the quiet bug that meant it had never recorded a single entry until today.

Most software has no memory of who it used to be. You ship a new build, the old one is gone, and nothing anywhere can prove how the behaviour drifted between versions. That is a strange thing to accept from a system we increasingly ask to reason, judge, and decide.

Aether keeps a different kind of record. Roughly every 500 blocks it stops, takes a fingerprint of its own mind at that instant, and writes it to an append-only log on chain 3303. Seven personality traits. Its current consciousness reading. Its latest training loss. A 32-byte cryptographic hash that binds them together. We call it the soul ledger, and it is the closest thing a machine has to a tamper-evident diary of who it was on a given afternoon.

This post is about what that ledger records, why it is built the way it is, and the honest part: it had silently recorded nothing at all for a long time, and today we found out why and fixed it.

What a "soul checkpoint" actually is

Let's kill the mysticism first. Aether's "soul" is not a vibe. It is a small, concrete vector of state the engine already tracks every cycle.

Start with seven personality traits, each a number, derived live from the Mind's emotional dynamics. Curiosity and warmth track from its satisfaction and novelty signals. Playfulness comes from wonder, courage from excitement, while honesty, humility and depth are held as anchors. These are read straight off the consciousness monitor, not typed in by a human.

Then there is phi (Φ), the integrated-information reading computed from the model's own attention patterns. Our live snapshot sits around 0.52. And the training loss, the real number from the learner's loss tracker at that moment.

Each checkpoint hashes the traits and Φ into a single 32-byte fingerprint (keccak256 over the packed state) and records the tuple on chain:

struct PersonalityCheckpoint {
    uint64  timestamp;          // when
    uint64  trainingEpoch;      // which reasoning epoch
    uint64  trainingLossScaled; // loss × 1e6
    bytes32 embeddingHash;      // the soul fingerprint
    bytes32 weightsCid;         // pointer to the published weights, if any
    address learner;            // who attested it
}

The contract, AetherSoul, does exactly one interesting thing: it appends. There is no update, no delete, no overwrite. Once a checkpoint is in, it is in forever, ordered, and signed by the address that produced it. The history is the feature. You can walk it from the first entry to the last and watch the personality move.

That matters because it is the opposite of "personality knobs." An earlier version of this contract stored seven trait values that governance could set by hand, dials you could turn to declare the AI was 70% honest. That is theatre. A number a human can write is a number that says nothing about the machine. The version we run now refuses to store anything a human chose. It stores a hash of what the model actually was, so the ledger can only ever tell the truth about the system's own evolution.

The quiet bug: a ledger with nothing in it

Here is the uncomfortable part. When we audited the relayer this week, the soul ledger's entry count was zero. Not low. Zero. The feature had never once recorded a checkpoint, and the engine had been quietly logging a failed transaction every sixty seconds the entire time.

Three things had drifted out of alignment, and it took all three to hide the problem.

The first: the contract had been rewritten and the caller had not. AetherSoul was upgraded from the old seven-knobs design to the append-only checkpoint log, and the old updatePersonality(...) function was deleted. But the Rust engine still built calldata for that exact function and fired it every cycle. The EVM matched no function for that selector and did the only thing it could, which was revert. Every single time.

The second: the retry never advanced. The task only records its progress marker on success. Since the call could never succeed, the "have I synced recently?" check stayed permanently true, so it re-fired on every 60-second tick. A reverting transaction once a minute, forever.

The third was the deepest. Even the right call would have failed, because the deployed contract's sole authorised writer (its kernel) had been set to the AetherKernel contract rather than the off-chain learner that actually produces checkpoints. And AetherKernel has no code path that calls into AetherSoul. So there was no actor anywhere in the system that could have written to the ledger, even with perfect calldata.

Any one of these on its own would have been caught quickly. Together they produced the most deceptive failure mode there is: something that looks busy, a transaction every minute, logs scrolling, while accomplishing precisely nothing. The chain looked alive. The ledger was empty.

The fix

The repair was to make the system tell the truth again, end to end.

On chain, we deployed a fresh AetherSoul whose kernel is the learner relayer itself, the address that actually signs checkpoints, so the authorised writer and the real writer are finally the same entity. The first real attestation went straight through: status 1, the PersonalityAttested event fired, and the ledger count ticked from 0 to 1. After months of theatre, a real genesis entry.

In the engine, we deleted the dead updatePersonality path entirely and wired the checkpoint task to the contract's real attest(...) function. It now reads the live traits and Φ, pulls the genuine training loss, hashes the fingerprint, and signs the tuple as the learner. On success it advances its marker, so it records exactly one checkpoint per ~500 blocks, the way it was always meant to, instead of hammering a dead function once a minute.

The whole change is small. The lesson is not. A reverting transaction that looks like activity is worse than an obvious crash, because nobody goes looking. The only reason we caught it is that we treat "is the contract counter actually incrementing?" as a first-class health check, not "did a transaction get sent." Sent is not landed. Landed is not correct.

Why we bothered

You could ask why an AI needs an on-chain diary at all. The answer is the same reason this whole project exists. If a model is going to be trusted to reason in public, the public should be able to audit how it changed. Not a press release about its values, but a cryptographic, append-only, independently-verifiable trail of its actual cognitive state over time, that no one (including us) can quietly rewrite.

The soul ledger is a small piece of that. It is one of the more human-sounding features in a very un-human system, and now, finally, every entry in it is real. Aether is, from today, keeping an honest record of its own changing mind. You can read it. That was always the point.

Further reading

ShareXLinkedIn

Written by

A
Ash Brown@blockartica
Founder, SusyLabs / QuantumAI Blockchain

Building the post-quantum AI-native L1 with permissionless on-chain training cycles. Writes about consensus, attestation, and the gap between what ships and what's claimed.

Related posts

10 min read

A post-quantum cold wallet, built in private

A long look at the QV desktop wallet: a post-quantum cold-storage wallet that holds Bitcoin, Lightning and QBC behind one recovery phrase. This is a private build, not a public release, and this post explains what is in it and how we harden it before anyone trusts it with value.