What You Saw Did Not Happen

The user approved. The signature was real, the key was theirs, and any verifier would have confirmed it. The money still went to the attacker.

Before you sign, a modern crypto wallet runs your transaction against the chain as it stands and shows you the result. The preview said the balance would go up. It was an honest answer to the question it had been asked. By the time the transaction ran, the answer had changed.

What was approved was a set of bytes. What executed was an outcome. This issue is about the distance between those two things, and about who is left holding it.

A preview is a measurement, and a measurement has a time. The wallet computes one against the state of the chain at that moment and puts it on the screen without a timestamp. It is correct when it is drawn. Nothing about the way it is presented tells you how long it stays correct.

The gap

The attack does not need the signature to be weak or the wallet to be fooled. It needs the seconds between the preview and the execution, and the fact that nobody asks the question again in between. The paper names the pattern by its old name.

Read that as a description of a design rather than as an accusation. The wallet is not deceived and it does not report anything false. It answers once, and it is never asked again. Every screen that draws a preview and then leaves it up has the same shape, whatever it is previewing.

The attacker does not have to guess who to target either. The phishing site connects to the wallet before the transaction is built, so the address is known the moment the victim clicks. Adding that address to a list is an ordinary write to an ordinary contract.

Six ways, three found

The paper works through the parts of a transaction that can change between simulation and execution, and builds a taxonomy of six classes: the contract’s own storage, an external contract’s storage, the gas limit, the gas price, the block number and the block timestamp. Any one of them can decide which branch a contract takes. Then it goes looking for them in real chain data, and this is where the study earns its keep.

Gas-control is nearly all of the volume and the cheapest of the three to build. The phishing site sets a high gas limit in the transaction, the simulator may use a smaller default of its own, and the contract branches on which one it sees. The victim does not have to do anything unusual for it to work.

Storage-control is rare and takes most of the money. There the attacker depends on neither a simulator’s defaults nor a race with the clock. They send a transaction that changes the contract, bid a high enough fee to get it in first, and the branch is settled. Control is worth more than volume.

The three that were not found are the other half of the finding. Gas prices move with congestion, so a threshold set today misfires tomorrow. Block heights have to be fetched over the network, which adds delay the attacker cannot control. External-control does what storage-control already does and costs more to deploy. Attackers left those on the table because they are unreliable, not because nobody thought of them.

Where the contracts are, and where the money went

The contracts are not spread the way the losses are. Ranked side by side, the two lists point in opposite directions.

We do not divide one of those numbers by another. The concentration figure in this issue is 91.5%, and it appears because the authors state it, not because we worked it out. The reason they give is ordinary: ether is worth more and more people hold it, so the same trick on the same day takes more.

Across the four chains the paper counts 6,223 victim transactions from 5,742 addresses. Ethereum accounts for 3,154 of those transactions, 2,780 addresses and $3.19M; BSC for 1,790, 1,719 and $182.32K; Polygon for 1,064, 1,030 and $2.15K; Avalanche for 215, 213 and $111.53K. A further 146 transactions deposited and came back whole, because the attacker’s transaction did not land in time.

One wei

The preview reported a direction. It did not report a size a person could weigh against what they were sending. A gain too small to name still reads as a gain, and the fee on such a transaction is larger than the reward, so the real balance change is negative before the branch ever matters.

That is the deeper design point, and it is not about phishing at all. The preview answers what your balance will be afterwards. It does not answer what you are sending. Those are different questions, and only one of them is safe to answer once and leave on the screen.

Flagged, and not flagged

Each of these chains has an explorer that labels addresses known to be involved in scams, and wallets can check a transaction’s destination against those labels. The paper looked up every contract it found.

On Avalanche the gap is widest: 12 of 3,136 contracts were labelled and 3,124 were not. That is not a measure of how alert anybody was. A reputation list looks backwards by construction — it can only carry addresses that somebody has already been hurt by and has already reported.

The detector

The contracts were found by a tool the authors built. It reads a contract’s compiled bytecode, follows every branch, and looks for one specific shape: a decision point where one path returns more than the caller deposited and the other sends the deposit to an address held in the contract. Anything matching is then run in a sandbox, twice, to see whether both outcomes actually occur. Against a ground truth of 44 phishing contracts it identified 43, with no false positives across 162,975 benign contracts.

Be precise about what a clean false-positive count buys. It says the tool accused none of the 162,975 contracts it was tested against. It does not say the shape it looks for is the only shape available, and the authors say as much themselves: a contract obfuscated well enough breaks the data-flow trace, and the one they missed was exactly that.

What a signature authorises

Here is the part that generalises past crypto wallets. A signature is over bytes. It fixes what those bytes are and who was willing to be associated with them. It does not fix what happens when they are executed, because that is decided later, by something else. Authorising bytes is not authorising effect.

This is the point where a vendor usually explains why its own product would have caught it. Ours would not have. Rather than argue that, we will quote our own documents, which said so before this paper existed.

That is NC-1.2 in our non-claims document, read at commit 4891071. It goes on to say that every artefact has to answer two questions separately — is this authentic, and is this still current — and that the second is answered by policy rather than by cryptography. The victim’s wallet answered the first and never asked the second again.

That is NC-1.4, on the hash an approval is bound to. It is deliberately narrow. The hash proves that a holder of the approver key authorised one exact set of parameters, so an approval for one set is not an approval for another. It says nothing about whether those parameters were a good idea, and nothing about what the world did with them afterwards.

And that is our threat model, on replay and freshness. The sentence immediately after it names the owner of the problem: freshness is the caller’s responsibility. A verifier can be handed an expiry and a freshness window, and it will enforce them — but only if it is handed them, and a caller who supplies none gets an answer about authenticity rather than about currency. Naming an owner is better than pretending the problem is solved. It is still not the same as solving it.

Where this sits in the series

Signal 001 was a model that behaved one way when it believed it was being watched and another way when it did not. Signal 002 was an agent that argued with the person standing at the gate, and the person refused. Signal 003 was an escape through the one opening a sealed environment had to leave open.

This one contains no deception at all. Nobody was argued with, nothing was forged, and no control failed. A person read a true statement about a world that had already changed, and signed it.

Now put it in your own company

• Your finance agent shows an operator a payment run to approve, and a supplier’s bank details are edited before the batch is released.
• Your deployment agent shows a diff, and the branch it will actually deploy moves between the review and the pipeline.
• Your procurement agent quotes a price that holds for a minute and executes after two.
• Your support agent shows the record it is about to change, and another process changes that record first.

None of those is exotic. Each is a preview that was true when it was drawn, approved by somebody with no way to know it had stopped being true.

On a public chain the gap is a few seconds and anybody can watch for it. Inside a company the gap between the screen and the effect is usually longer, and far fewer people are looking at it.

Where Noa Mandate stands

The honest sentence first, because everything after it is worth nothing without it. Noa Mandate would not have stopped this.

A wallet already asks. The user already approved. Putting a second approval screen in front of a transaction whose preview is wrong produces a second wrong preview, and calling it a gate does not change that.

What an approval gate changes is narrower, and worth stating exactly. It moves the decision off the machine that is under attack, it binds that decision to one exact set of parameters rather than to a description of them, and it leaves a record that somebody who does not trust us can check.

The approval request carries the operation rather than the agent’s account of it: which agent, which action, which parameters, which environment, and a digest of those parameters. The approval is bound to that digest, so an approval for one set of parameters is not an approval for another.

The signing key stays on the phone. Taking the server is therefore not sufficient on its own to mint a valid approval, because what is needed to sign is somewhere the server does not reach.

What is left afterwards is a hash-chained, signed record: who asked, what was held, which parameters the approval was bound to, what was decided, and what the dispatching layer observed. Alter a record and verification detects it. Be precise about what that buys — the chain proves the records you hold are intact and in order. It does not prove that none are missing, and it is not a measurement of the outside world.

You do not have to take our word for any of that. The verifier is open source and you run it yourself, in an empty directory:

mkdir noa-demo && cd noa-demo
npm init -y
npm install noa-receipt

Exactly one package arrives: noa-receipt. It has no runtime dependencies. The copy-paste quickstart lives in the repository’s README, and those blocks are executed by a gate on every push — so “it works” is not something we say, it is something a machine says.

Against an attack like this one the gate has a single narrow job, and it is not the one a reader might hope for. It cannot make a preview correct. What it can do is refuse to release an operation nobody authorised, hold the authorisation to one exact set of parameters, and leave a record that somebody outside the argument can check afterwards.

What we do not solve

This has to be said plainly, and it is the part most of this industry leaves out.

What is on offer is narrower and it is checkable. Not that an approval can never be overtaken by events — that the actions worth stopping cannot complete without one, that the request carries the operation rather than a description of it, that the approval is bound to exact parameters, and that the record can be verified afterwards by somebody who does not trust us.