
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.
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:
| Operation | Today | After Glamsterdam |
|---|---|---|
| Write a new storage slot | 22,100 gas | 110,020 gas |
| Create an account by sending ETH | 25,000 gas | 183,600 gas, plus execution |
| Deploy code | 200 gas per byte | 1,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."
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.
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.
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.
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
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?
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
- ethereum/glamsterdam-gas-invariants: the gas table, the eight invariants and the randomness oracle example
- Blockonomi: Glamsterdam Hoodi launch postponed after EIP-8037 gas concerns
- crypto.news: Ethereum developers flag contracts at risk from gas changes
- Anatoly Yakovenko on the few smart contracts that matter, and a technical map of the six
- Bringing Inference Programs To Solana