ASSAY

00 Abstract

When you swap a token, the interface tells you what you received. That figure is a report — a claim produced by the same system that executed the trade.

Assay discards the report and reconstructs the fill independently from finalized chain state: what left the wallet, what entered it, what the venue kept, and what the network charged. The result is deterministic — anyone re-running it against the same transaction lands on the same number — so it is checkable rather than trusted.

The name is literal. An assay determines what a metal is actually made of, as opposed to what a seller claims. Assay offices have refused to take sellers at their word since the 1300s: you bring the silver, they test it themselves, and only then is it struck. A fill is an alloy of the same kind. You were promised a thousand parts; the chain says how many arrived.

01 The problem

Arbitrum One (chain ID 42161) is an Ethereum L2 carrying a dense, permissionless venue ecosystem — AMMs, aggregators, routers, launchpads. Standard Ethereum tooling runs on it without modification, which is what makes the method below portable: it reads ERC-20 Transfer records, and those are the same artefact on every EVM chain.

On any such venue, the number you are shown after a trade is computed and displayed by the venue's own interface. Between the price you were quoted and the tokens that actually settled, several things happen that the interface has no obligation to surface pre-trade:

• Venue fees, sometimes disclosed, sometimes folded into the rate.
• Pool slippage, rarely shown before you sign.
• Routing through intermediaries, each taking a cut.
• Gas, paid separately in ETH and absent from the token summary entirely.

The interface's event logs are no better as a source of truth: they are written by the same contract whose behaviour you are trying to verify. To know what actually happened, you cannot ask the venue. You have to rebuild it from the chain.

02 Method

Assay reconstructs a fill in four steps. None involve interpretation.

1. Confirm settlement. Fetch the transaction and its receipt. A transaction that has not finalized is a rumour, not a fill; a reverted transaction has no settlement to reconstruct.
2. Read the transfers. Collect every ERC-20 Transfer event emitted by the token contracts themselves — topic 0xddf252ad… — ignoring whatever the venue said about its own work.
3. Net against the wallet. Sum the transfers where the wallet is sender or recipient. Incoming minus outgoing, per token. That net delta is what moved, and no interface gets a vote in it.
4. Compute fineness. If the amount you were promised is supplied, divide what arrived by what was owed, in parts per thousand. Assay offices round down — you never receive credit for purity you do not have — so Assay does too.

Gas is accounted separately: gasUsed × effectiveGasPrice, read directly from the receipt, reported in ETH and labelled as a network cost rather than something the venue kept.

All arithmetic is exact (arbitrary-precision integers). Display values are truncated; the computed figures never are.

03 Fineness

Millesimal fineness is the real standard for precious metal: sterling silver is 925 fine — 925 parts silver per thousand. Assay applies the same scale to a fill:

A struck assay produces a hallmark — a row of punch marks in the manner of a real silver hallmark: assayer, fineness, office, and the block it settled in. The mark is not a badge of approval; it is a record of what the test found, refusal included.

04 Architecture

The bench is a single static client. There is no backend, no account system, and no server that sees the transactions you assay on it. The Assay Agent — the optional watcher described in section 04a — is the exception, and it is the only one.

• Reconstruction runs entirely in the browser against a JSON-RPC endpoint.
• Permalinks (/tx/0x…) do not store a result; they re-run the assay from the chain when opened, so a shared link verifies itself in front of its reader.
• The ledger — your history of struck assays — lives in your browser's local storage and nowhere else.
• Wallet assay (/wallet/0x…) reconstructs recent fills for an address by reading its transfer logs over a block window via eth_getLogs.

For production, the client points at a proxied provider endpoint on the project's own domain. This carries higher rate limits than the public RPC and, by being reached through the project's domain rather than the chain's public hostname, is unaffected by the DNS interception some networks apply to the latter.

04a The Assay Agent, and what it costs

Everything above describes the bench, and remains true of it. The Assay Agent is a separate, opt-in watcher that assays transactions as they settle and explains them on Telegram. It cannot work the way the bench does, and the difference is worth stating rather than burying.

• It needs a server. To send you a message about a wallet, something has to be running when the transaction settles. That is a persistent process, not a static file.
• It holds a join the bench refuses to make. A Telegram chat id against a set of on-chain addresses. That pair is the deanonymising link the bench never creates, and it is the real cost of the feature.
• It keeps a history. What each account struck, so a dashboard can differ between accounts. That is a record of your activity which did not previously exist anywhere.
• It publishes a little. A front-page feed carries a display name taken from Telegram, the ticker, what arrived against what was promised, and the grade — for accounts that have not opted out. It carries no address and no transaction hash: those columns are not selected, rather than selected and filtered.

Nobody is running a hosted agent. The code is in the repository and the intended deployment is your own. Where a claim in this paper says no server, read it as a claim about the bench; where it matters, this section is the correction.

The arithmetic is not duplicated. The agent reconstructs with a literal port of the browser's method — the same Transfer topic, the same netting, the same BigInt fineness with the same truncation, the same grade thresholds — pinned against the client's own outputs by test. A language model writes the sentences of each notice and is given the figures already computed; it is instructed, in the system prompt and again in the output schema, never to compute, re-derive, round or convert any of them. Every notice carries a permalink, which re-runs the assay from the chain in front of whoever opens it.

05 What Assay verifies — and what it does not

Honesty about the boundary is part of the method.

What it catches

A venue claiming one output while the token moved another. Because the venue contract and the token contract are different contracts, the venue cannot forge the token's own transfer record. This is the common and important case.

What it does not catch

Step ii trusts each token contract to report its own transfers, which is a weaker guarantee than diffing raw account balances at block N−1 and N. A malicious token that misreports its transfers would defeat it. True balance-diffing requires an archive node, which the public RPC does not serve; it is on the roadmap, not in the current build.

The floor is not the quote

Assay reads the floor you signed (amountOutMin) from Uniswap V2-style routers, from Camelot's variant of them, and from Uniswap V3's single-hop call (exactInputSingle, selector 0x04e45aaf). The floor is a real, cryptographically committed promise — but it is weaker than the quote the interface displayed, and the two must not be confused. The floor therefore never feeds fineness; fineness still requires the promised figure, supplied by you until a venue's own ABI makes the quote readable.

No selector here was recalled or taken from a signature database. Each was derived from its signature with keccak-256, then confirmed present in the deployed bytecode of the router that implements it, read with eth_getCode. That check is also what removed the predecessor chain's aggregator: its selector appears in no Arbitrum router at all. The word indices were then checked against every recognised fill in an 8,000-block window — 539 settled transactions from 183 distinct wallets. For the two V3 calls the floor was at or below what arrived in 363/363, and the word naming the output token was the token that arrived in 363/363. For the V2-shaped selectors the floor held in 163/176. Seven of the twenty selectors produced no fill in that window at all; those rest on the bytecode and the published ABI alone, and the tool lists them as unobserved on every run rather than folding them into the totals above.

All thirteen exceptions fell at one address, which read correctly seventy-eight times in the same window — so the word index is right and something else is wrong. That contract takes a cut of the input before swapping, so the floor it recorded was set against more than ever reached the pool, and a wallet that nets less than its own floor has not been short-changed by the decoder. This is the case for the runtime check rather than against it. Assay re-checks every decode against what the reconstruction independently found: if the token encoded in the calldata is not the token that actually arrived, or the floor exceeds it, the number is withheld and said to be withheld. A router Assay does not recognise is named, not guessed at — and so is one whose floor is real but not at a fixed word, such as the Universal Router's.

06 Roadmap

Stated as future work, not as done.

• Quote decoders. Read the figure the interface actually quoted, not merely the floor beneath it, so fineness becomes automatic. This needs each venue's own ABI; the floor is what can be read without one.
• State diffing. Reconstruct from balance deltas at block N−1 vs N, via an archive node, closing the malicious-token gap.
• Drift. Track whether a stock token's on-chain price tracks the reference asset it represents, and by how much, over time.
• Wallet history indexer. A stateful service so the wallet view reflects full history rather than a fixed recent window.

07 On a token

At the time of writing there is no token, and this section deliberately contains no supply figure, distribution table, or staking schedule. Those are not withheld for suspense; they do not exist, and inventing them is precisely how a project becomes uncheckable.

If a token is introduced, this whitepaper commits to two constraints:

1. Utility is tied only to features that have shipped. A token cannot grant access to reconstruction quality, decoders, or history that the roadmap has not yet delivered. Selling access to unbuilt functionality is the failure mode Assay exists to expose in others.
2. No fabricated traction. Any figure this project publishes — holders, volume, usage — must be one a reader can reconstruct from the chain, by the same method the product itself uses. A claim the product's own tooling would contradict does not get made.

The tokenomics, if and when they exist, will be published as real, consistent, and on-chain-verifiable numbers — or not at all.

08 Status

The working components ship in the client and can be run by anyone against the live chain. The rest are blank because they are blank.

09 Why the name

A trading interface asks for trust. An assay office refuses to give it and tests the metal instead. That refusal — show me, don't tell me — is the entire product, and the reason a fill and a bar of silver are, for Assay's purposes, the same object: something whose true content can be measured, and therefore should be, rather than taken on the word of whoever handed it to you.

Claimed ≠ actual.