What the phone shows you: transaction analysis on the signer

A claim and the truth

When a web page asks you to sign something, it also tells you what it is. "Swap 1 ETH for USDC." "Claim your reward." "Verify your wallet." That description is a claim made by the page, and a malicious page can make any claim it likes. The bytes it hands to the wallet are a separate thing, and they are the only thing the blockchain will ever see.

AirNox Vault ignores the claim. It decodes the request from the exact bytes it is about to sign, on the phone, with its own parser, and shows you the result. What the desktop says about a request is a claim. What the phone shows is the truth.

Standard methods, recognised

Most of what you sign is ordinary. A transfer. A token allowance. A swap through a known router. A deposit into a contract. The phone recognises the standard operations of each chain family it supports and shows them in plain words: what operation, which token, how much, to whom, on which network, and what the fee cap is. A transfer looks like a transfer. An allowance looks like an allowance, with the spender and the amount spelled out.

Look-alikes, flagged

The dangerous requests are the ones that look ordinary and are not. A method whose name resembles a standard one but whose parameters do not fit. A call that delegates control to another contract in a way that does not show up in the headline. A target that is not the contract the page said it was talking to. A token whose symbol impersonates a well-known one. A recipient address that shares its first and last characters with one of yours.

Each of these is detected and turned into a finding. The phone does not refuse to sign, because the decision is yours. It makes sure you cannot miss it.

The findings

An unlimited allowance is the classic drainer move: approve once, lose everything in that token afterwards. The phone says "unlimited" in red and treats it as a finding.

An unknown spender is an allowance to an address that nobody vouched for. When a swap was quoted through a particular router and the approval targets something else, the mismatch is a finding.

A look-alike method, an impersonating token symbol, a look-alike recipient and a hidden delegation are each called out by name. For recipients, both the desktop and the phone show a deterministic picture of the address, so a look-alike that fools the eye on hex does not fool it on the picture.

Acknowledge, then Accept

A finding is not a pop-up you can dismiss by reflex. Accept stays disabled until every finding has been ticked. You can decline at any time. You can accept only after you have acknowledged what the phone found. That one design choice turns "I clicked through" into "I read it and chose to proceed", which is the difference between a drained wallet and a decision.

The desktop screens first

The same analysis runs on the desktop before a request ever leaves it, so most bad requests are flagged in the wallet window before they reach the phone. The phone runs the analysis again because the desktop is the machine we assume is compromised. Two independent passes, on two devices, with the final word on the one that holds the keys.

Reading is still your job

A signer that shows you the truth cannot stop you from agreeing to it. What it can do is make the truth impossible to miss: decoded from the bytes, in plain words, with the risky parts in red and a gate you have to pass on purpose. The rest is up to you, and now you have what you need to decide.