Main
/
List
/
Categories
/
Tags
Encoded judgment is toxic data: three lines of a smart contract holding frozen judgment, a gas limit, an oracle check and a permanent failure flag, beside the same contract as one sentence of intent and a single exit that pays

Encoded Judgment Is Toxic Data

Ethereum's Glamsterdam repricing broke contracts that had frozen judgment into code. Most of a smart contract is judgment, and judgment is secondhand data about circumstances that have changed. Our draft SIMDs move it out: store intent on chain, judge fresh off chain, keep code for arithmetic.

10 min read
November 7, 2026

Data is a toxic asset: it outlives the reason you collected it, and it keeps costing you after the reason is gone.

There's a worse kind of data on chain: encoded judgment. Judgment is secondhand data. It's a decision someone made for a set of circumstances, written down as if those circumstances would never change. When they do change, the decision keeps acting as if they hadn't.

Ethereum just showed what that costs.

What happened with Glamsterdam

Ethereum's next upgrade, Glamsterdam, includes two proposals that reprice state: EIP-8037 and EIP-8038. Storage is a real burden on everyone who runs a node, so the cost of creating it goes up sharply:

OperationTodayAfter Glamsterdam
Write a new storage slot22,100 gas110,020 gas
Create an account by sending ETH25,000 gas183,600 gas, plus execution
Deploy code200 gas per byte1,530 gas per byte

The new accounting also changes how failures behave: a failed call can hand gas back to the contract that made it.

In August, the Ethereum Foundation warned that "a small set" of contracts might break. In October, the audit firm ChainSecurity found something the official replay of past transactions had missed: the new accounting could weaken contracts' defenses against attackers who deliberately starve a call of gas. They found 13 real contracts that could be affected. Days later, on All Core Devs call #248, the developers pulled the upgrade from the Hoodi testnet. On November 6 they published eight broken "invariants", rules contracts relied on that will no longer hold, and asked auditors to check their clients' code. They say they may soften the proposals depending on what comes back.

The process is careful and public, and the repricing has a real reason. That isn't the problem. The problem is what broke.

What broke was judgment

Look at the invariants the core developers found most often: fixed gas amounts that are no longer enough, and gas reserves and stipends sized for today's prices. Their own example is a randomness oracle with this line:

uint256 public constant CALLBACK_GAS = 100_000;   // sized for pre-Glamsterdam prices

That line isn't moving money. It's a judgment: someone's guess, in 2024, about what a callback would cost, frozen forever. Writing it into an immutable contract turns a price change into a migration. The core developers say so themselves: "Hard-coded constants and immutables are what turn a repricing into a migration."

Diagram: a simplified prediction market contract of eight lines. Five are judgment, in orange: a hard-coded gas guess, which oracle to trust, did it happen, what counts as on time, and a failure marked permanent. Three are mechanics: hold funds, pay out, refund. The judgment moves into one sentence of intent read by a jury from several AI labs; the mechanics map to six shared exit programs.

Most of a typical smart contract looks like this. Some of it moves money: hold funds, pay out, refund. Most of it decides: did the event happen, which oracle to trust, what counts as on time, how much gas a step needs, what a failure means. And because the deciding is written in code, it is frozen on deploy day.

A smart contract is a cache of judgment that can never be invalidated. When the world moves, the cache keeps answering.

Diagram: when a fork reprices gas, on Ethereum every app must be audited; some contracts are unaffected, some can be fixed with a setting or an upgrade key, and some are stuck and must migrate. With Actually Smart Contracts, the repricing means re-checking a few shared exit programs, and the contracts' words, which never mention gas, need no change. The grid is illustrative.

Only about six things need to be code

Solana co-founder Anatoly Yakovenko has argued that only about six smart contracts really matter, and that what's needed is a small set of well-audited building blocks, not endless custom code.

We agree, and we take it one step further. The mechanical part of a contract comes in a few shapes: hold, pay, refund, split by rank, pay by grade, release in stages. That is arithmetic, and it should be code: small, audited, shared. Nearly everything else rounds to judgment, and judgment shouldn't be code at all.

Diagram: on Ethereum today, a prediction market, an insurance contract and a bounty each write their own immutable contract, mostly deciding logic with a small part moving money. With Actually Smart Contracts, each app writes only its intent in words, a jury from several AI labs interprets it, and money moves through a few shared exit programs.

This is why every Verafy Harness settles through just six exit programs: escrow, bond, ledger, graded payout, ranked split and milestone escrow. That's all the code there is. Each is named by its hash, uses checked integer math, and runs only transfer lists that sum to zero. They decide nothing: they run the exit the jury chose. The harness runs them in a small JavaScript runtime, and can check them against the same programs compiled for Solana; any disagreement between the two is a fault.

Store intent, not judgment

Our three draft SIMDs (Solana Improvement Documents) take judgment out of the smart contract entirely. Only arithmetic remains in code.

  • Inference Programs. The program's logic is intent, written in natural language and stored on chain, inline or by reference to a page or a git commit. A caller asks for a ruling and escrows a budget.
  • Evaluators and Attestations. A jury of models from several labs runs the judgment off chain. Each evaluator commits first, then reveals a signed answer bound to the pinned evidence, optionally with a zero-knowledge proof that its model produced it.
  • Rulings, Disputes and Challenges. When the evaluators reach quorum, a ruling is recorded: the outcome, a summary, the reasoning by hash, and every vote's signature. Programs act on it. It can be challenged and overturned by a new ruling, and it is never erased.
Diagram: on chain, the inference program holds the intent in words, attestations hold each evaluator's commitment and signed answer, the ruling holds the outcome and signatures, and one of six shared exits moves the money. Off chain, a jury of evaluators decides, and the full reasoning, context and proofs are kept available by hash through the challenge window. The validator encodes exits, not judgment: six programs, and nothing else.

Storing anything on Solana is expensive, and today's proofs are far too large to store or verify on chain. So the chain keeps what must be permanent and small: the intent, the signatures, the hashes, the outcome. The judgment, and the evidence and reasoning behind it, stay off chain, pinned by hash and kept available through the challenge window.

The nature of a smart contract changes. It stops being an app's custom judgment compiled into bytecode, and becomes intent in words, plus a pointer to which of a few shared exits to run.

The end of code rot and judgment rot

Table diagram comparing judgment stored as code with inference programs: code rot, judgment rot, a platform upgrade, and who decided and why, with the limits that remain.

Code rot is code going bad because the platform changed under assumptions it froze. Intent never mentions gas, compute units or call stipends, so there is no custom judgment code on chain for a repricing to break. When the platform changes, there are six exits and the SIMD programs to re-check, maintained in one place, not every app ever deployed.

Judgment rot is a decision going bad because it was made forever: a failure "recorded for good," a nonce burned, an oracle trusted permanently. With inference programs, judgment is made when it's needed, against the world as it is on that day, and stays on the record, where a challenge can correct it without editing history.

A platform upgrade stops being an audit of every app followed by migrations, upgrade keys and stuck contracts. It becomes a short list to re-check.

Who decides, and can you check?

Diagram: on Ethereum, core developers reach rough consensus on calls, new rules change gas and failure behavior, and immutable contracts can't respond; the process is public but votes aren't recorded and you can't re-run a person. With Actually Smart Contracts, the contract's words are judged by a jury from several AI labs, and the ruling goes on the record; votes are signed, reasons recorded, and rulings can be replayed on pinned models. It is still a prototype, and words can be ambiguous.

Ethereum's rules are set by people, through a public process with no recorded votes. You can see that a decision was made, but you can't measure the judgment behind it, and you can't re-run a person to see if they'd decide the same way twice.

You can re-run a model. A jury's votes are signed and its reasoning is recorded. Give the same pinned model the same pinned evidence, and you can replay a ruling and measure whether the answer moves. Judgment isn't the problem. Unmeasured, frozen judgment is.

What this doesn't solve

  • The exits are still code. A repricing on Solana could affect them too. There are just six, maintained in one place.
  • Words can be ambiguous. Someone still has to write the intent clearly. Pinned evidence, an agreement bar and challenges manage that; they don't make a sloppy contract precise.
  • The reader can change. Models are retrained and retired. High-value contracts can pin open-weight models by hash, and a new model should have to re-rule past cases and agree with them before it sits on a jury.
  • Two pieces are missing on Solana: fair juror draws, and keeping the off-chain data available through the challenge window.
  • This is early. The SIMDs are drafts at "Idea" stage, in discussion #724. The ruling program has run on a local Solana test validator, not yet on devnet. Nothing here is a running network, and there is no token.

Store intent. Judge fresh. Keep code for arithmetic.

Don't store judgment. Store intent, and judge fresh, against the world as it is, on the record. Code is for arithmetic.

Read the SIMDs and argue with them in discussion #724. Run a harness, or a whole testnet on one machine, from harness.verafy.ai.

Sources

RSJRex St John
Forward-Looking Statements Notice: Verafy blog articles may contain forward-looking statements regarding Verafy’s future plans, technologies, and market positioning and opinions on possible future achievements. These statements are based on current expectations, predicated on attaining future goals, forecasts, and assumptions that involve risks and uncertainties. Actual outcomes and results may differ materially from those expressed or implied in these statements due to factors such as evolving market conditions, technological challenges, regulatory developments, and other risks beyond Verafy's control. Readers are cautioned not to place undue reliance on forward-looking statements. Verafy undertakes no obligation to update or revise such opinions as a result of later or new information, future events, or otherwise.