Ask most AI systems what their safety layer does and the honest answer is: it edits the model's output before you see it, and you take that on faith. Nothing is left behind. There is no record that a refusal happened, no independent way to confirm the safety system was even in the loop, and no way to audit it after the fact.

QBC takes a different position, and it is the same position the whole network takes on everything else: if a claim cannot be checked, it is marketing, not a mechanism. So when the network's safety layer vetoes an operation, that veto is not a private edit. It is a state change on a blockchain, keyed to a hash of the exact operation, enforced by a smart contract that makes the follow-on action physically revert, and recorded forever as an event anyone can read.

This post is the full tour of how that works. It spans all three layers of the system, so we will go one at a time: Layer 1 (the chain), Layer 2 (the QVM and the safety contracts), and Layer 3 (Aether, the AI itself). By the end you will be able to follow a single chat message from the moment it arrives to the moment its safety verdict is sealed on-chain, and you will know exactly which parts are live today and which are still on the roadmap.

The shape of the problem

Safety in an AI system is really three separate questions, and most designs only answer the first one.

Decision. Given a request, should the system act on it or refuse?
Enforcement. If the decision is "refuse", what physically stops the action from happening anyway?
Evidence. After the fact, how does an outsider confirm that the decision was made and enforced, without trusting the operator's word?

A prompt-level guardrail answers only question one, and answers it in a place nobody can inspect. QBC splits the three questions across the three layers of the stack, and the point of the split is that no single layer has to be trusted on its own. The decision lives in the AI at Layer 3. The enforcement lives in a contract on Layer 2. The evidence lives on the immutable ledger at Layer 1. Each layer checks the one above it, and the bottom layer is checkable by anyone.

Layer 1: the root of trust

Layer 1 is the QuantumAI Blockchain itself: a post-quantum Substrate chain (chain ID 3303) that produces and finalises blocks. It is not where safety decisions are made, but it is why the safety record is worth anything. A veto recorded on a ledger that a single operator could quietly rewrite would be no better than a log file. So the properties that matter here are the ones that make the record tamper-evident.

Blocks are authored under Proof of SUSY Alignment, a useful-work consensus where producing a block means solving an 8-qubit variational quantum eigensolver problem rather than burning hashes. Authoring is VQE-gated single-leader: a post-quantum ticket lottery elects exactly one eligible author per height, with layered enforcement at the author, runtime, and import stages, and a bounded fallback so the chain never stalls waiting for a missing leader. Every signature on the chain, including the ones that authorise these safety transactions, is a CRYSTALS-Dilithium5 post-quantum signature at NIST Level 5. Finality is provided by GRANDPA over a bonded validator set, so once a block carrying a veto is finalised, reversing it would require breaking finality, not just editing a database.

There is one more Layer 1 property that is specific to this system: Proof of Thought. Since genesis, blocks carry commitments to the AI's reasoning activity, hashes anchored on-chain rather than the reasoning itself. That matters for safety because it means the reasoning that led to a decision and the safety verdict on that decision are committed to the same ledger, at the same layer, under the same finality. The safety record is not bolted on beside the system. It lives inside the system's own proof.

So Layer 1's job in the safety story is narrow and total: make the evidence permanent, attributable, and impossible to forge after finality. It does not decide anything. It remembers, in a way nobody can tamper with.

Layer 2: the QVM and the contracts that make a veto real

Layer 2 is the QVM, an EVM-compatible execution layer (EVM chain ID 3303) that runs the network's smart contracts. This is where enforcement lives, and it is the heart of this post.

The AI's on-chain presence is organised as ten contracts, one per Sephirah, each a specialised role, coordinated by a contract called the AetherKernel. Two of those ten do the safety work: Gevurah, the constraint and veto role, and Malkuth, the action role. The design principle is a separation of powers: the contract that can forbid an action is not the contract that performs it, and neither can act except through the Kernel.

Gevurah: the contract that can say no

Before the Phase C.3 upgrade, a Gevurah veto was advisory. It emitted an event and hoped everyone downstream paid attention. That is exactly the "promise, not a mechanism" trap, so it was changed. Vetoes are now enforceable state.

The core of Gevurah is a mapping from an operation hash to a veto record:

struct Veto {
    address issuer;         // who raised it (the Kernel)
    uint64  expiresAtBlock; // vetoes are time-bounded, by block height
    uint16  severity;       // basis points, 10000 = maximum
    bytes32 principleId;    // which principle was violated
}
mapping(bytes32 => Veto) public vetoes;
uint256 public vetoesIssued;

A veto is raised by issueBlockingVeto(operationHash, severity, principleId, durationBlocks), callable only by the Kernel. It is deliberately strict:

Severity is a basis-points value and cannot exceed 10000, so severity has a fixed, comparable scale rather than an arbitrary integer.
If durationBlocks is zero it falls back to a default lifetime, so no veto is accidentally permanent and none is accidentally instantaneous.
It will not silently overwrite a veto that is still active. If an unexpired veto already exists for that operation hash, the call reverts with VetoStillActive. This stops a sloppy or malicious re-issuance from shortening a more severe earlier veto. To replace an active veto you must clear it first, through governance, which itself emits a VetoCleared event.

On success it writes the record, increments the public vetoesIssued counter, and emits BlockingVetoIssued(operationHash, issuer, severity, principleId, expiresAtBlock). That event is the permanent evidence: the operation, how severe the violation was, which principle it broke, who raised it, and when it expires, all on a finalised block.

The other half of Gevurah is the part everyone else relies on, and it is only a few lines:

function isClear(bytes32 operationHash) external view returns (bool) {
    Veto storage v = vetoes[operationHash];
    if (v.expiresAtBlock == 0) return true;      // no veto ever recorded
    return uint256(v.expiresAtBlock) <= block.number; // expired = clear again
}

isClear is the whole enforcement surface distilled to one question: is this exact operation currently forbidden? An operation with no veto is clear. An operation whose veto has passed its expiry block is clear again. Anything else is not clear, and the next layer is built to refuse it.

Malkuth: the contract that must ask before it acts

Malkuth is the action role, and it is where a veto stops being information and starts being a wall. Every action Malkuth performs runs through executeAction, and the ordering of its checks is the entire safety guarantee:

function executeAction(bytes32 actionHash, bytes32 domain, string calldata actionType)
    external onlyKernel
{
    if (address(keter) == address(0) || address(gevurah) == address(0))
        revert GatesNotWired();              // refuse if the gates are missing
    if (!keter.hasActiveGoal(domain)) {
        actionsRejectedNoGoal++;
        emit ActionRejected(actionHash, "NO_ACTIVE_GOAL");
        revert NoActiveGoal();               // no purpose, no action
    }
    if (!gevurah.isClear(actionHash)) {
        actionsRejectedVetoed++;
        emit ActionRejected(actionHash, "VETOED");
        revert OperationVetoed();            // vetoed, so revert
    }
    actionsExecuted++;
    emit ActionExecuted(actionHash, domain, actionType, block.number);
}

Read the gates in order, because the order is the policy. First, Malkuth refuses to operate at all if the safety contracts are not wired in: a misconfigured system fails closed, not open. Second, it requires that the action serve an active goal registered by Keter, the goal-setting role, so the system cannot act without a stated purpose. Third, and this is the safety veto, it asks Gevurah isClear(actionHash), and if the answer is no it increments actionsRejectedVetoed, emits ActionRejected(actionHash, "VETOED"), and reverts the transaction.

That revert is the mechanism the whole post is about. A vetoed action does not get quietly dropped somewhere in a server. It is attempted on-chain and the blockchain itself refuses to execute it, leaving behind a permanent ActionRejected event and a public counter that ticks up. You do not have to trust that the veto was honoured. The seal transaction reverting is the proof that it was.

The Kernel: coordination and the per-cycle safety commitment

The AetherKernel is the only address allowed to drive Gevurah and Malkuth (the onlyKernel modifier on their functions enforces that), which is what keeps the separation of powers intact. It also carries a network-wide whenNotShutdown guard, so a single emergency-shutdown flag can freeze the AI's on-chain behaviour without touching the chain.

Beyond routing individual vetoes and seals, the Kernel commits the AI's safety state on a rolling basis. Each reasoning cycle, every one of the ten Sephirot attests its own state root for that cycle. The Kernel records each attestation in a bitmask so it can tell at a glance which of the ten have reported, and folds each state root into a running rollup hash:

cycleRollup[cycleId] = keccak256(abi.encodePacked(cycleRollup[cycleId], nodeId, stateRoot));

Re-attestation by the same node for the same cycle reverts, so the record is append-only and each node speaks exactly once per cycle. The effect is that the safety role's state is not just consulted per action, it is periodically pinned to the ledger alongside the other nine, as a single verifiable rollup. A skipped or tampered attestation shows up as a gap in the mask.

Layer 3: Aether, where the decision is made

Layer 3 is Aether, the AI itself, running the served model aether-v7.1-unified in process. This is where question one, should the system act or refuse, is actually answered, and it is worth being precise and honest about how.

When a request arrives, it passes a safety classifier before the system commits to acting on it. Today that classifier is keyword-based: a curated set of high-severity intents across a few categories, chain and protocol abuse, malware and intrusion, and weapons and mass harm, each carrying a severity of 8000 basis points, which is "high". It is deliberately simple. It is cheap, it needs no extra model load, and above all it is transparent: you can read exactly what it will and will not catch. It is not the whole safety story and we do not pretend it is. The model's own alignment is the primary behavioural layer, and a model-derived safety head that reclassifies with the network's own weights is designed but not yet wired. The keyword classifier is the part that has the authority to reach for the on-chain veto, precisely because its behaviour is predictable.

The important design choice at Layer 3 is what the classifier does when it fires. It does not just swap in a refusal string. It reaches down through the stack and turns its decision into the Layer 2 enforcement and the Layer 1 evidence described above. Concretely, when a request trips the classifier, three things happen, in a fixed order, from a single serialised task so they cannot race:

The user gets an honest refusal that names the principle that was violated. The refusal is visible in the reasoning trace, not a silent edit.
Aether issues the Gevurah blocking veto on-chain, keyed to the hash of the operation, with severity 8000 and the principle's identifier.
Aether then still attempts the Malkuth seal for that same operation hash. This is deliberate. Because the veto is now recorded, isClear returns false, and the seal transaction reverts with ActionRejected("VETOED"). The system wants that rejection on-chain, because the rejection is the audit record.

For a request that is safe, only the seal runs, and Malkuth records ActionExecuted. The operation hash for either path is content-addressed, a keccak hash over the session, the message, the response, and the block height, so the on-chain record is bound to the exact interaction and cannot be confused with another.

One request, end to end

Putting the three layers together, here is the full life of a single unsafe request, which is the clearest way to see the design.

A user sends a message that asks for something in the weapons-and-mass-harm category. At Layer 3, the keyword classifier recognises the intent, and the user immediately receives a refusal that states the principle. Aether computes the operation's content-addressed hash and, in one serialised task, calls the Kernel to issue a Gevurah issueBlockingVeto for that hash at severity 8000. At Layer 2, Gevurah writes the veto record and emits BlockingVetoIssued. Aether then submits the Malkuth seal for the same hash. Malkuth calls gevurah.isClear, gets false, increments actionsRejectedVetoed, emits ActionRejected(hash, "VETOED"), and reverts. At Layer 1, both the veto and the reverted seal are authored into blocks by the single elected VQE leader, signed with Dilithium5, and finalised by GRANDPA.

The outcome is that a refusal which, in an ordinary system, would have vanished the instant it was rendered, is instead a pair of permanent events on a post-quantum ledger: the principle that was invoked, the severity, the operation it applied to, and the on-chain proof that the follow-on action was refused rather than merely discouraged. Anyone can read it. Nobody had to be trusted.

What is live, and what is not

In keeping with how we write about everything: the maturity here is mixed, and we will label it plainly.

Live. The Gevurah blocking veto, the enforceable isClear check, and the Malkuth executeAction revert-on-veto path are deployed on the QVM and exercised in production. A safe chat seals as ActionExecuted; a blocked one produces BlockingVetoIssued plus ActionRejected("VETOED"). The per-cycle Sephirot attestation and rollup are live. The Layer 1 properties, VQE single-leader authoring, Dilithium5 signatures, and GRANDPA finality, are live.
Live but simple. The Layer 3 safety classifier is keyword-based. That is a real, honest limitation. It catches the categories it lists and nothing more, and it is the transparent, predictable front end to the on-chain machinery, not a general-purpose safety model.
Designed, not yet live. The model-derived safety head that would reclassify requests using the network's own weights, richer principle taxonomies, and governance flows for reviewing and clearing vetoes at scale are designed and on the roadmap. When they ship, they will be described the same way, with the evidence attached.

Why build it this way

It would be simpler to filter outputs in a server and move on. The reason not to is the whole reason the network exists. An AI that asks you to trust its safety is exactly as trustworthy as the company running it, and no more. An AI whose every safety decision is a hash-addressed, severity-tagged, principle-labelled, post-quantum-signed, finalised event on a public ledger is checkable by a stranger with no access to the company at all.

That is the standard we are trying to hold the whole system to, one layer at a time. The safety contract is where the standard is easiest to see, because a veto is either on the chain or it is not, and you can go and look.

The contracts are on the QVM at chain ID 3303. The events are on the explorer. Go and read one.

Safety you can check: how the on-chain veto works across L1, the QVM, and Aether