DEV Community: Andrew Maury

Where Dollar Stablecoins Sit Against $1

Andrew Maury — Thu, 29 Oct 2026 16:43:54 +0000

On 21 October 2026 the OCC finalized its rule under the GENIUS Act, and its community-bank fact sheet says the agency is "encouraging the development of payment stablecoin capabilities within the community banking sector." The rule takes effect on 18 January 2027. As of 29 October the OCC is not yet taking applications, and it says it will announce separately when it begins.

A bank deciding whether to issue a public coin can already look at the coins that exist. So I measured where today's fiat-backed dollar stablecoins sat against $1 over the last 30 days, one number per coin. The page describes where they sat and makes no claim about why.

What I measured

DefiLlama publishes the two things this needs: a list of stablecoins with each one's supply and how it is backed, and a daily price for each. I took both on 27 October 2026. From the list I kept every coin pegged to the US dollar, labelled fiat-backed, with more than $1 million outstanding, which is 73 coins. For each one I took the distance of every daily price from $1, in basis points, over the 30 days from 28 September to 27 October, and used the median.

Two rules decide which coins count. A coin needs a usable price on at least 20 of the 30 days. And a daily price of exactly 1.0 is treated as a fixed value and dropped. That second rule removes three products that report a near-constant 1.0: BlackRock's BUIDL fund (28 of its 30 readings are exactly 1.0), Ondo's U.S. Dollar Token (27) and GAIB AID (23). None of the 45 coins that end up counted had a reading of exactly 1.0, so the rule removed no data from them. The other 25 dropped coins simply lack enough prices. In all 28 fail, 27 of them under $1 billion, and BUIDL is the one above. The 45 that pass have between 28 and 30 days each.

The fiat-backed label is DefiLlama's, and it is broader than the payment stablecoins the rule covers. It includes some yield-bearing tokens and at least one SEC-registered security, Figure's YLDS. I left them in, and the table on the original page lists every counted coin, so anyone can drop the ones they would not count.

The interactive chart (each coin's median distance from $1 against its supply, with a per-coin readout) and the table of all 45 coins, including each one's daily correlation with USDT, are on the original page.

What the numbers show

The large coins sat close. Seven coins have more than $1 billion outstanding. Five sat within 2.2 bps of $1: USDG and RLUSD at 1.0, USDGO at 1.3, PYUSD at 2.0 and USDC at 2.2. USD1 sat at 7.0 and USDT at 7.6.
The smaller coins spread out. The other 38, between $1 million and $1 billion, sat a median 10.3 bps from $1. Three of them were under 5 bps, and four were more than 40 bps away.
Size went with distance across the whole set, much less below $1 billion. Across all 45, the rank correlation between supply and distance is −0.42: larger coins tended to sit closer. Among the 38 coins under $1 billion it is −0.16, too weak to call a relation.
One issuer's coins can sit far apart. Paxos Trust Company issues both PYUSD, with $2.9 billion outstanding, which sat at 2.0 bps, and USDP, with $22.5 million, which sat at 21.7. The four coins in the set that Anchorage Digital Bank issues (USDGO, USDPT, USDtb and USAT) sat at 1.3, 3.1, 7.2 and 10.4. Sources for each issuer are on Anchorage's reserves page and, for USDPT, in The Block.
The insured bank's coin sat in the middle. SoFiUSD, issued by SoFi Bank, an FDIC-insured national bank, sat at 6.8 bps, with a worst single day of 19.6.

Which coins moved with USDT

USDT moved partway through the window. Its signed median (the median of price minus $1, so negative means below par) was −2.0 bps over the ten days from 28 September to 7 October and −8.3 bps from 8 October on. That is a step of 6.3 bps, and roughly four times the discount. Most of the field moved the same way: 33 of the 45 coins had a lower signed median after 8 October than before, and 35 of the 45 sat farther from $1.

Coin by coin, the smaller coins split. Correlating each one's daily price with USDT's over the window, 10 of the 38 under $1 billion score above 0.8, among them USAT, USDtb and First Digital's FDUSD. Eighteen score 0.2 or less, among them SoFiUSD, USDPT and USDP. The median is 0.24. Over 30 days a correlation like this mostly asks whether a coin stepped down on 8 October too, so it identifies which coins moved with USDT and says nothing about why. One possibility is that some prices are derived partly from trading against USDT; DefiLlama does not document how each price is built, so I cannot check that.

Measured against USDT's price on the same day, the smaller coins' median distance is 8.0 bps, against 10.3 from $1. That gap is no evidence of a link on its own. 35 of the 38 sit below $1, and so does USDT, so measuring against USDT shrinks the distance of any coin below par whether or not it tracks USDT. The correlation is the better test, and the original page's table gives it for every coin under $1 billion.

Over 90 days

The same method over 90 days gives smaller numbers. Taking the coins with enough prices for that window, again seven above $1 billion and 38 below though not quite the same 38, the large coins' median is 1.6 bps and the smaller coins' 7.5, or 5.8 against USDT. Twelve of the smaller coins sit under 5 bps, against three over 30 days. The 30-day window includes the October move in USDT and reads farther from $1. The chart on the original page shows it because it is the current one.

What the rule says that bears on this

Three points from the final rule and the statute behind it.

An insured bank issues through a subsidiary. Under the GENIUS Act, an insured bank must issue a payment stablecoin through a subsidiary (12 U.S.C. 5901(23)). SoFiUSD is issued by SoFi Bank itself today. The requirement applies from 18 January 2027, and existing issuers that apply by then may request a temporary waiver.
A tokenized deposit is a different instrument. In the words of the OCC's preamble, the Act's definition of a payment stablecoin "explicitly excludes deposits, regardless of whether the deposit is recorded using distributed ledger technology." A deposit can pay interest. A payment stablecoin's issuer cannot pay holders interest or yield "solely in connection with the holding, use, or retention" of the coin (12 U.S.C. 5903(a)(11)).
Secondary trading and supervision. The OCC says the rule's redemption requirements "do not apply to secondary market trading," and also that it "intends to review" secondary-market information "for supervisory purposes."

What this does not show

Trades. These are price-feed values, one a day. They say nothing about how much could be bought or sold at that price.
Redemption. What a coin trades at and what its issuer pays on redemption are separate questions. Nothing here measures the second.
Causes. Size, issuer, chain, trading venue and how the price feed is built all vary at once across 45 coins, and I have not separated them.
More than one window. The 30-day picture includes a move in USDT that changes it, as the 90-day figures show.

What I would track from launch

For a bank that issues a public coin, the inexpensive version of this is a few figures recorded every day from the first one: the coin's worst daily distance from par, the same against USDT, and which trading pairs its price feed is built from, since that decides how much of a USDT move lands in the coin's own number.

Data

DefiLlama's public stablecoins and stablecoinprices endpoints, both taken on 27 October 2026. Every figure on this page is printed by one script run against that snapshot, which also draws the chart. The snapshot and the script are available on request.

Originally published at rantum.xyz, which is the canonical source.

Andrew Maury is the founder of Rantum, a senior data science and ML studio that turns messy, fragmented and adversarial data into models, APIs and products that ship.

The Metric That Moved 82 Percent and the One That Didn't

Andrew Maury — Wed, 28 Oct 2026 20:15:32 +0000

ClearTrace publishes a median execution slippage for each venue on its leaderboard. On 21 October the cell for ParaSwap on Ethereum read 6.40 basis points, over 17,913 transactions in the trailing seven days. On 29 July the same cell read 36.83. That is a fall of 82.6 percent, and measured in basis points it is the largest move over the quarter of any venue cell ClearTrace publishes.

Two things inflate that figure: the dates it is measured between, and a change in the transactions underneath it. A second ClearTrace instrument holds the comparison steady, pricing the same pairs at the same sizes against the same baseline at the same moment, and across the same quarter it shows ParaSwap's execution barely moving at all.

What the number is

The cell is a median. For every fill routed through the venue on Ethereum in a trailing seven-day window, ClearTrace values both legs at Dune's price for that minute, takes the size of the gap between them, and reports the median in basis points. The fills come from Dune's dex_aggregator.trades, where the venue is labelled velora, the name ParaSwap now trades under. The count published beside the median is distinct transactions, while the median itself runs over fills; on 21 October that was 17,913 transactions and 17,955 fills.

Three details of the query matter later.

A transaction is credited to one project only, through a fixed priority order, so a change in how Dune attributes shared transactions moves this count.
A fill is dropped unless Dune has a price for both tokens in that minute, so a change in price coverage moves it too.
The query itself changed during the quarter: its file was committed eight times between 10 July and 2 October, some of those to comments, with the measurement changes on 20 August, 9 September and 23 September.

The 52 snapshots between 1 July and 21 October are readings from an instrument that changed while it was being read.

The window opened on the series high

36.83 is the highest reading in the whole series, and it is the reading the 90-day window opens on. 6.40 was the lowest reading up to that date, and it is the reading the window closes on. A change measured between those two dates is the full range of the series to that point, by the accident of where the calendar landed.

The opening value is also older than its date. It was first recorded on 24 July and appears again, identical, on 27 July and on 29 July, and so does every one of the other 39 venue cells. When a Dune run fails, ClearTrace's sync serves the last cached result instead, which is consistent with three identical snapshots across all 40 cells. The window opens on a measurement taken five days before the window began. The same series carries two more repeated pairs, on 13 and 15 July and on 26 and 29 August; the second is the late-August peak.

Between the endpoints the series does not trend. It rose to 29.43 in late August, fell to 16.62 by mid-September, climbed to 30.92 by the end of September and dropped 17 points the following week. That is ordinary in this data. Across 35 per-chain cells in the snapshot history, leaving out the ones ClearTrace has withdrawn or does not publish, the median absolute change over the quarter is 2.67 bps and the median range is 10.44. For the typical cell, the range inside the quarter is about three times the net move across it.

A selection of the 54 readings, with the count behind each:

Snapshot	Median, bps	Transactions
2026-07-01	13.94	4,434
2026-07-24	36.83	4,171
2026-07-27	36.83	4,171
2026-07-29	36.83	4,171
2026-08-26	29.43	7,598
2026-09-14	16.62	4,877
2026-09-29	30.92	5,919
2026-10-05	13.81	5,921
2026-10-14	8.89	6,838
2026-10-19	6.43	16,940
2026-10-21	6.40	17,913
2026-10-23	6.04	15,621
2026-10-26	7.72	7,394

All 54 readings, and a two-panel chart of the series with its sample count, are on the case study page.

Then the population more than doubled

The last step down, from 8.89 on 14 October to 6.43 on 19 October, coincides with the count behind the reading going from 6,838 transactions to 16,940. Two days later it was 17,913. Both readings cover seven days, so the week ending 19 October held about two and a half times as many ParaSwap transactions on Ethereum as the week ending 14 October.

The jump belongs to that venue on that chain. The same venue on Base went from 4,961 transactions to 5,003 on the same sync. Of the 23 other venue cells on individual chains present on both snapshots, the largest rise was 1.37 times, and 16 of them fell. In Dune's public model repository, ParaSwap's own models were last changed in June, and I found no change to the shared aggregator models after 23 September.

The two ParaSwap entrypoints that the snapshot history tracks separately did not grow either: together they show 1,487 transactions on 14 October and 1,396 on 19 October, although those rows refresh less often than the venue cell. The additional ten thousand or so transactions came through other contracts. They could be new flow, or flow that the priority order or the price coverage had been assigning elsewhere or dropping. Telling those apart takes a query I have not run for this piece. Either way, a median over 6,838 transactions and a median over 16,940 are medians over different populations.

The closing reading has a second problem. On 21 October the signed median, which keeps the direction of each gap, was 0.67 bps, and 53.9 percent of scored fills were costs to the taker. The distribution was close to centred on zero. ClearTrace's own methodology note explains the consequence: when the gaps centre near zero, the absolute median reports how noisy the price feed is for those token pairs more than it reports execution. The window closes on a reading close to that regime.

The readings after the window show the surge passing. On 23 October the cell read 6.04 on 15,621 transactions, lower again. On 26 October it read 7.72 on 7,394, with a signed median of 3.14 and 66.4 percent of fills as costs, which is also what ClearTrace's public API showed on 27 October. The count is back near where it sat before 19 October, and the reading has moved up with it.

A steady count is not a steady population

My first reading of this was wrong. One of the two entrypoints, AugustusV6_2, fell from 62.31 bps to 4.31 over the same quarter while its count barely moved, from 871 transactions to 862. I took that as the part of the fall that was real: same population, lower cost.

It does not hold. That row was refreshed far less often, with 11 distinct readings across 38 snapshots, and its window also opens on its own high and closes on its own low. Its readings span 4.31 to 62.31 on counts that never left the range from 627 to 1,239. The other entrypoint, AugustusFeeVault, went from 67.72 to 63.69 over the same window.

The venue cell shows the same thing more plainly. Between 29 September and 5 October it fell from 30.92 to 13.81 while its count moved by two transactions, from 5,919 to 5,921. A count says how many transactions went into a median and nothing about which ones. The mix can change completely under an unchanged count, and a median follows the mix.

What survives depends on the baseline

Comparing periods instead of endpoints helps, but it does not settle the question. In the first half of October, before the count jumped, the five readings ran from 13.81 down to 8.89, with a median of 11.36. Against August and September, whose readings had medians of 19.44 and 20.78, that is a fall of about 45 percent. Against the first three weeks of July, median 14.5, it is a fall of about 22 percent.

Neither baseline is the obvious one, and the evidence behind each is thinner than the number of readings suggests. The readings are seven-day windows taken every two or three days, so the five October readings cover about two weeks of transactions. The counts are no help either: they held between 5,900 and 6,900 in early October but ran from 4,121 to 7,881 in August and September, and the previous section shows what a steady count is worth. On this cell alone, ParaSwap's October readings were lower than its late-summer ones, by an amount that depends on which period you call normal, for a reason the median cannot identify.

The measurement that holds the comparison still

ClearTrace runs a second instrument that avoids most of this. Its quote sampler asks each aggregator for a route on a set of token pairs at four sizes, from $1,000 to $1 million, and simulates the swap against chain state from a neutral address. It then compares the output with what Uniswap's default route delivers for the same pair and size in the same time window. Each observation carries its own baseline, and the pairs are chosen by ClearTrace rather than by whoever happened to trade that week.

On the seven pairs the sampler priced in every period of the quarter, ParaSwap's median output against the Uniswap default stayed between -0.76 and -1.64 bps at every size, in every period from early July to 26 October, over 8,425 matched windows. The first half of October sits inside the range of the months before it, and the days of the surge differ from the fortnight before them by no more than 0.15 bps at any size. Most of that steady gap is the flat 1 basis point fee ClearTrace's sampler has measured ParaSwap taking on major pairs.

The sampler measures something narrower than the on-chain cell. Its figure is ParaSwap's routing relative to one baseline route, on chosen pairs, with simulated swaps, and the pairs it tracks have shifted at the edges over the quarter, which is why only the seven present throughout are used here. What it shows is that whatever moved the on-chain cell did not show up in how ParaSwap routed these seven pairs at these four sizes.

How the 82 percent got chosen

I found this number by asking which metric had moved most over the last 90 days, ranking every per-chain cell by the change between its first and last reading in the window, and taking the largest among the venue cells ClearTrace publishes.

That ranking leans toward exactly this case. Of the 41 per-chain cells with at least ten snapshots in the window, three open on their own series high and close on their own series low, or the reverse. The ranking put those three first, fourth and seventh, and ParaSwap's cell is the fourth. Asking for the biggest mover between two dates is partly asking which series the calendar caught at its extremes. The unit matters as well: in percentage terms the largest published move went the other way, OKX on Base rising from 7.03 to 16.48 bps, on a count that fell from 5,032 transactions to 1,870.

Three of the six largest moves sit in cells ClearTrace has withdrawn or does not publish, and two of those were withdrawn after we found the number did not mean what the column said.

What would make the comparison mean something

Compare periods, with their spread, and say which baseline. A month of readings has a median and a range. A change smaller than the range inside each month is weak evidence of anything, and a change whose size depends on the baseline needs every plausible baseline shown.
Print the count beside every value. A reading whose count jumps far outside its usual range starts a new series, and it should be read as one rather than as the next point on the old line.
Mark carried-forward readings and query versions. A snapshot that repeats the last value because a run failed is not a new observation, and a series that spans a query revision is two series.
Pair each observation with its own baseline where the question allows it. The discipline for this is implementation shortfall: the gap between the price at the moment of decision and the price achieved. ClearTrace's sampler is built on that pairing: each row holds a solicited quote and the simulated fill for it, and the comparison above sets each fill beside the baseline route's fill in the same window. Comparing two routes removes the price feed from the comparison, and fixing the pairs removes the change in mix between periods. Neither is available on a median of whatever traded that week.

Why the direction of the move matters

A cost reading that rises 82 percent gives the venue a reason to ask why. One that falls 82 percent gives nobody outside the measurement a reason to look, so the check has to come from whoever publishes it.

ClearTrace has a precedent in the same direction. Its Scorecard Edition 3 records that, in the window then measured, the cell for the 1inch Limit Order Protocol published 13.27 bps where the population left after removing one resolver's maker-side edge measured 29.73. That venue read about twice as good as it was.

ParaSwap's cell was a published number, it held the largest move of the quarter, and on the instrument that holds the comparison still, the quarter barely registers.

Originally published at rantum.xyz, which is the canonical source.

Andrew Maury is the founder of Rantum, a senior data science and ML studio that turns messy, fragmented and adversarial data into models, APIs and products that ship. The measurements in this piece come from ClearTrace, Rantum's neutral on-chain execution-quality project.

Outside the Polygon, or No Polygon at All

Andrew Maury — Wed, 28 Oct 2026 20:15:17 +0000

AddressIntel, our predictive real-estate intelligence project, fuses San Mateo and Santa Clara County GIS layers onto parcels: zoning, fire hazard severity, flood, fault, liquefaction, landslide, farmland, Williamson Act contracts, Coastal Zone. The mechanism is a point-in-polygon lookup against each county's ArcGIS REST endpoint, and then a derived answer about what can legally be built. The scored table holds 489,915 parcels across 16 cities.

Writing the lookup took an afternoon. Every expensive mistake since has come from the same place: the pipeline had a definite answer to give and gave it, where something weaker was called for. Four failures are below, alongside the one case the pipeline handled correctly. Two are the pure form, a confident answer standing in for one the pipeline did not have: a layer emptied upstream that read as a clean negative, and a fallback rule chosen to be conservative that was not conservative where it mattered. The third is a confident answer that was simply wrong, a polygon hit reported as a legal conclusion it does not support. The fourth turned up while this was being written, a resume mark recording a question the pipeline had never asked. The case it handled correctly is a city declining to assess a parcel and the refusal surviving the trip, which earns its place because a careless query nearly flattened it. Two further mistakes in what follows are mine rather than the pipeline's, and both are marked where they fall.

The fixes converge even where the faults differ: make the weaker answer representable, and keep it distinct from no.

A sibling piece, Scraping Adversarial Municipal Portals, covers the same shape in a different layer: a source that answers cheerfully and wrong, a rejected login returning an empty list. That one is about scraping HTML portals and detecting silent truncation. This one is about the spatial join and what a polygon lookup is entitled to conclude.

What the lookup is

There are two shapes of lookup, and the difference matters later. The listing path sends one point per property, geometryType=esriGeometryPoint with spatialRel=esriSpatialRelIntersects, and reads back either the intersecting feature's attributes or a count. The scoring path cannot afford that across half a million parcels, so it pulls each layer once for the city's bounding box and runs the point-in-polygon against parcel centroids locally. Every per-parcel figure here comes from that second shape. San Mateo County's layers sit on a self-hosted gis.smcgov.org MapServer, and two of its towns publish their own zoning from their own ArcGIS organisations because the county layer answers NO DATA ASSIGNED for them. Santa Clara County's sit on ArcGIS Online. Counting only the scoring path there are fourteen distinct hosts and twenty publishers, because a hostname is not a publisher. Nine of the fourteen are single-tenant hosts the publisher runs itself: seven cities with their own GIS servers, San Mateo County's self-hosted MapServer, and FEMA. The other five are shared services*.arcgis.com tenancies carrying eleven publishers between them: Santa Clara County, two state agencies for the geologic and fire layers, seven more cities publishing from their own ArcGIS organisations, and a regional zoning aggregator. Sharing a host does not mean sharing it widely: two of those five carry a single publisher apiece. Three more cities' zoning arrives as a local file rather than a REST layer, two of them because they publish nothing on a host of their own. The scoring module that reaches them is 2,377 lines, and most of that is neither geometry nor SQL.

The reliability work is the visible part, and it sits on the per-point listing path, not on the bulk scoring one. The Santa Clara host answers bursts with read timeouts and connection resets, so calls to it pass through a two-permit semaphore, two attempts with a jittered backoff sleep between them, and a staggered release so threads queued on the semaphore do not all fire the instant a slot frees. Above that sits a circuit breaker that opens after three consecutive call failures and skips the rest of the run. The scoring path makes larger and rarer bulk calls and carries none of this: three attempts by default, an unjittered backoff, no breaker. The breaker's own counters had to be put under a lock: without one, concurrent threads each crossed the threshold independently and logged the same trip line several times a few milliseconds apart, which is how the race was found.

None of that is the interesting failure. A timed-out call is loud. The failures below were all quiet.

A layer can be emptied without erroring

Santa Clara County republished two of its planning layers with zero rows countywide on 25 September 2026. The pipeline asked one of them, the Agricultural Preserves layer, whether each point fell inside a preserve, using returnCountOnly. An empty hosted layer answers that query perfectly well. It returns a count of zero. So the lookup did not error, did not time out, and did not trip the breaker. It simply began answering no for every parcel in the county, in the same shape as a true negative, and it would have gone on doing so indefinitely.

This is the failure mode worth naming, because a spatial join over someone else's layer is exactly where it hides. A join has three possible answers and the API gives you two. There is inside the polygon, outside the polygon, and no polygon to be inside of, and the third arrives wearing the second's clothes.

The discriminator we ended up with is a quirk of the hosting. A zero-row layer answers a bare returnCountOnly request fine, but rejects with HTTP 400 and Cannot perform query. Invalid query parameters. any request that both filters by geometry and materialises features. So when a feature fetch fails, the collector asks the layer for its unfiltered total row count. Zero means the layer really is empty upstream, and zero coverage is the correct report. Anything else, including a count it cannot obtain, leaves the layer marked unknown so the run still reads as failed:

if _layer_row_count(url) == 0:
print(f" WARN {label}: layer is EMPTY upstream (0 rows countywide) "
f"- reporting zero coverage, not a fetch failure ({e})")
return []
print(f" WARN {label}: fetch failed ({e}) - layer treated as unknown")
return None

An empty list and None are different values, deliberately, and every caller has to handle both.

That discriminator sits on the bulk collection path, and it is worth being exact about which path it does not sit on. The per-point lookups the listing-level enrichment uses still ask returnCountOnly one parcel at a time and still end in return c > 0, with no row-count probe. The farmland, Williamson Act and county SB 9 layers all go through that path, and every one of them would still read an emptied layer as a clean negative. The ag-preserve signal was not fixed by teaching that path the difference. It was fixed by retiring the live lookup and reading a snapshot taken before the layer was emptied, which the file itself qualifies: it was recovered from pre-emptying caches, two cities' caches had already been overwritten, and it covers the scored footprint and is not a countywide extract. The general lesson survives the specific fix, and so does the exposure.

A polygon hit is not a legal conclusion

The second failure produced wrong numbers instead of silence. SB 9, California's urban lot split law, disqualifies a site that is prime farmland or farmland of statewide importance. Santa Clara County publishes several agriculture-related layers, and for a while the pipeline folded three of them into one primeFarmland flag: the state farmland mapping, Williamson Act contracts, and agricultural preserves. A hit on any of them disqualified the parcel as prime farmland.

They are three different things, and only one of them is the statutory category. Measured against the scored table today, after the three were separated on 28 September 2026:

17 parcels are prime farmland or farmland of statewide importance, the category the statute actually names. 15 in San Jose, 2 in Los Gatos.
216 parcels are under a Williamson Act contract. That is a tax-assessment contract restricting land to agricultural use. It is not prime farmland, and strictly it is not one of the statutory site criteria either.
4,107 parcels sit in an agricultural preserve, 2,626 of them in Los Gatos and 1,228 in San Jose. An ag preserve is neither prime farmland nor a voter-approved agricultural protection measure, so it is not an SB 9 bar at all.

The three overlap only partly. All 216 Williamson parcels are also inside an ag preserve, but 16 of the 17 prime-farmland parcels are in neither other set, and the union of the three labels is 4,123 parcels today. The repository's record of the fix puts the old flag's reach at 4,104 Santa Clara parcels blocked as prime farmland, 104 of them ordinary San Jose tract houses the state farmland map classifies as urban and built-up land. That historical set is not the same set as today's union, because the old flag read the farmland layer unfiltered and today's reads only the two statutory categories. Of the 4,123, exactly 233 now carry a farmland-family disqualifier and only 17 of those carry the one the column used to give. The rest of the union is not thereby buildable: 3,157 of the 4,123 are still SB 9-blocked, almost all on fire or fault rather than on anything agricultural: 2,880 for very high fire and 707 for a fault zone, against 132 for lot size and 37 for flood.

The Williamson parcels are still blocked, under their own name. The contract forbids the housing project for the length of its rolling term, so reporting such a parcel as eligible would be wrong in the more dangerous direction: it would tell someone they can split land they legally cannot. Blocked, with its reason named accurately, is the correct report, and the reason string is what carries the accuracy.

Two layers of answer, because one is not enough

What makes this expressible is that the derivation emits two lists where a single verdict would collapse them. sb9BlockReasons holds what bars the split: the statutory site criteria, plus the Williamson Act contract, which is not one of them and bars it anyway. developmentBlockers holds everything that raises cost, risk or process friction, disqualifying or not. Several signals appear in one list and not the other, and the choice is load-bearing each time:

Fire. Only a Very High Fire Hazard Severity Zone is statutorily SB 9-disqualifying. Plain High raises construction and insurance cost and bars nothing. 5,214 parcels are Very High and blocked; 10,780 are High and carry a cost blocker only.
Coastal Zone. SB 9 and state ADU law do not override the Coastal Act, so a Coastal Development Permit is still required. The parcel is encumbered without being ineligible, so the signal is a development blocker and never a block reason.
Liquefaction and landslide. 201,670 and 14,085 parcels respectively. Neither bars anything; both change what building there costs. Putting them in the disqualifier list would have made two fifths of the coverage area read as undevelopable.

Writing the overlay as a Coastal Zone hit flips eligibility would be the same defect class as the farmland flag, just in the other direction. The accurate statement is narrower and less quotable: the overlay changes what the parcel costs and how long it takes, and sometimes, for specific named layers, it changes what is permitted.

One figure here cuts against the way this layer gets described, including in our own earlier notes. Of the 7,579 listing-level enrichment rows, 45 carry a Coastal Zone hit, and 42 of those are in Half Moon Bay. The other three sit in El Granada and Woodside, and across the remaining thirty cities the layer is correct and silent, with a single Burlingame row still unanswered. It is a real signal in one coastal town, and a case study that led with it would be presenting that town's overlay as a pipeline-wide feature.

The fallback that was not conservative

The second half of the pipeline is rules as code. A screening signal we care about is how built out a lot is, living area over allowable floor area, which needs each jurisdiction's floor-area rule. Those are 19 jurisdictions in a table of formulas, every entry carrying source, asOf and confidence: 9 high, 7 medium, 3 estimated, researched between 30 June and 3 September 2026, with 12 unincorporated county districts added on 27 October 2026. None of the three marked estimated is the raw default, and the labels repay reading closely. One is estimated from its city's 40 percent coverage standard times a stories factor, which lands near 0.52 effective, above the curated cluster instead of below it. One still applies the default, now capped by a table in that city's own code, with the slope half of its rule still missing. The third is not a floor-area ratio at all. The estimated tier marks what has not been finished, and what each entry does under that label still has to be read.

The default of 0.40 was chosen to be conservative. It sits at the low end of the curated cluster, so for a city near that cluster it understates allowable area, which biases against false this lot has headroom signals. That reasoning is sound and it is not a safety property, and the difference is the whole of what follows.

Four entries were curated on 3 September 2026 after an audit, all of them inheriting the default until that day, and the audit cut three ways. In one city the default held: across all 9,217 of its scored parcels it overstates only 11 percent of them and never by more than 1.20 times, which is the result the reasoning predicted. In two towns it did not. One has a ratio of 0.25 tapering to 0.15 above an acre, against which the default overstates allowable floor area by 1.60 times on a half-acre lot and 2.33 times at 200,000 square feet. The other is worse by an order of magnitude, because its caps are absolute rather than proportional: the repo records the default overstating it by 2.7 times at the minimum R-1 lot, 5.8 times at an acre and 29 times on a ten-acre parcel. In both towns the error is largest exactly where lots are biggest and a teardown call carries the most money. The fourth entry is the capped-default one described above, which is why it is still labelled estimated. An estate town is the shape a flat default gets most wrong, and it is also the shape where the signal gets used hardest.

The lesson is not that the default was badly chosen. It is that a default is an answer. Uncurated should read as unknown, not as safe, and the confidence field exists so that a caller can tell the difference instead of inheriting our optimism.

When the city itself declines to answer

The best-behaved source in this pipeline is the one that publishes its own uncertainty. Palo Alto's assessor parcel layer carries a floor-area field, and for some parcels it does not state a figure. It says instead that it cannot assess one, naming a creek, a flag lot or a right-of-way. That is a city telling you a constraint binds that it will not quantify.

1,317 of the 20,849 scored Palo Alto parcels carry the resulting far_not_assessable blocker. The arithmetic for those parcels is still run and still correct for the lot, and the flag rides alongside it to say that something we do not model is known to apply. That is a different statement from a missing value, and it is more useful than either a number or a blank.

Extracting it took two tries, and the first try is instructive. Matching the field loosely on the phrase can't assess also catches a different sentence the same layer uses, which means the district is not residential rather than that a physical constraint binds. The loose predicate pulled 7,593 parcels where the specific one pulls about 1,359, so more than four fifths of the matches were a different statement entirely. Two sentences in the same column, both reading as absence of a number, meaning unrelated things.

We ingest that layer's judgement and not its numbers, on purpose. Its floor-area values agree with our own formula for Palo Alto on 99.23 percent of 14,044 parcels, checked 28 August 2026, with the residual explained by rounding in its acreage strings. That agreement is what makes the layer trustworthy on the question, and it is also why its figures are not worth importing: they are our own arithmetic coming back to us. The non-redundant content is the refusal.

Unknown is also the resume cursor

Keeping unknown distinct from no stops being an honesty argument once the backfill runs. The overlay backfill walks already-enriched rows with a four-worker pool, and rows whose lookups time out are left undone and picked up next run. What makes that work is that a failed lookup writes None rather than False, so the row stays unmarked and the resume predicate finds it again:

# Only mark the SCC pass done when BOTH resolved; a None in either
# means that lookup errored -> retry next run. …
if r["city"] in SCC_CITIES and prime is not None and wact is not None:
payload["sccPrimeChecked"] = True

If a transient ArcGIS timeout had been recorded as a negative, the pipeline would be self-consistent, would converge, and would be wrong, with nothing left in the data to indicate which rows had never actually been asked. That is the theory. The column I reached for to demonstrate it does not show it. 2,217 enrichment rows carry a null corner-lot value, and I took all of them for a retry queue. Measured by development class, 1,121 are condominiums, 692 townhomes and 398 multifamily, and six are single-family homes. The first three groups are marked not-applicable and skipped by a check that runs before the resume predicate is ever evaluated, so their nulls are not outstanding work and never will be.

A further meaning hides under that one. Six more rows carry no corner-lot key at all, because a first-ever failed lookup writes nothing where a later one writes a null, and the predicate reads the field with a lookup that cannot tell an absent key from a null value. All six are single-family. Twelve rows are the queue, and finding the second six meant reading the predicate instead of the column.

A third set makes the point without rescuing it. 1,190 rows carry a null farmland value against 20 positive and 6,369 negative, and they are San Mateo County listings. The backfill records farmland as unknown for that county by design, because no state farmland source is wired for it, so no run will ever resolve those either.

So one column, three meanings. Not yet asked, which is work. Does not apply, which never was. No source wired, which is a gap in the pipeline rather than in the run. All three are stored as null, and the schema says which is which only if you go and look at a different field. A null records that a value is not known. It says nothing about whether anyone is still going to look, and the lesson of this section is that I read my own column wrong before I measured it.

What this pipeline still does not know

Three limits belong on the page, not in a footnote.

Zoning is mostly absent at the listing level. 5,487 of the 7,579 enrichment rows have a null GIS zoning value, and a further 1,124 carry the county layer's own NO DATA ASSIGNED sentinel, which the backfill treats as absent. By the pipeline's own test, 6,611 of 7,579 have no usable zoning and 968 do. Without zoning the derivation cannot reach a hard eligible and returns likely instead. That is one of two routes into the middle state and the smaller one: of the 109,132 scored parcels sitting there, 9,089 have no zone at all and 100,043 carry a zone that is simply not a single-family district, mostly multi-family and planned-development codes. Absence of a block reason means no disqualifier was found rather than that eligibility was established.

A resume cursor can mark a new question answered. Writing this piece turned up one more instance of its own subject, in the mechanism the previous section praises. The Williamson Act check became its own signal on 28 September 2026 and the backfill was updated to require it, but rows marked complete under the previous rule were never re-asked, because the predicate that would re-ask them is the one reading the stale mark. Measured on 28 October 2026, before the fix: 4,552 rows marked as having completed the farmland pass, and 3,768 of them carrying no williamsonAct key at all, with another 21 carrying it null. The per-parcel counts elsewhere on this page are unaffected, because the parcel-scoring path does not use the mark.

The fix merged on 28 October 2026, and it took two merges, which is the part worth having. The obvious version tests whether the row carries the field at all, and that version is wrong in a quieter way: a failed lookup writes a null, so the presence test would be satisfied by the error and lock it in permanently. So the completeness test mirrors the write-back condition instead, both answers present and not null.

That was not enough, because the write-back condition was itself unsafe. Making those 3,789 rows re-query opened a path that had been unreachable while they were skipped: the write stored the lookup's result without checking it, so a failed re-query replaced a resolved farmland answer with a null. Not one row at a time either, since once the circuit breaker opens every remaining call in the run returns null at once. A second change the same morning guards the two farmland writes, so a null replaces an answer only when there is no answer to lose. A third guards the coastal write just above them, which had been left alone and is the field the resume predicate keys on, so an unanswered lookup there both erased a resolved hit and re-opened the row. Three unguarded writes sat on one screen and the first repair fixed two of them, which is about the hit rate you should expect from a fix aimed at a symptom. The first fix's own test checked that a failed lookup is not marked complete and never checked what it writes, which is exactly the distance between a mark and the data it stands for. A mark records that a pass ran rather than that it answered what the pass asks today, and a field added afterwards has to be able to invalidate it. Merging the predicate did not answer anything by itself; the next scheduled run had to ask the question. It has since started doing so. Against the canonical copy the rows carrying a resolved Williamson value have gone from 763 to 962, and those still owing one from 3,768 to 3,575, which is the first evidence from production that the repair does what the test said it would.

Two copies of this database exist, and the figures above come from different ones. AddressIntel keeps a canonical copy that the application serves and a working copy on a development machine, both called the same thing. On 15 September 2026 four separate published figures were wrong from exactly that confusion, and the provenance test written in response identifies the canonical copy by requiring a marker table it carries and none of the marker tables only a development machine builds.

The two halves of this piece sit on opposite sides of that line. The parcel scoring table is named in the test as a development marker, and the canonical copy genuinely does not carry it, so every per-parcel figure here, the 489,915 and everything derived from it, exists only on the working copy and has no canonical counterpart to check against. The listing enrichment table is named in neither set, and I first read that silence as the same answer. It is not. The canonical copy carries that table too, with 7,579 rows against the working copy's 4,004, and every listing in the smaller set is present in the larger, though the two copies' stored payloads have since diverged, mostly on derived fields. The listing-level figures above are therefore measured on the canonical copy, and where an earlier draft of this piece quoted the working copy's version of one, it was quoting a 53 percent sample and calling it the population.

What to take from it

A spatial join has three answers. Inside, outside, and no layer to be inside of. If your schema cannot hold the third, you will serve it as the second.
Check that a negative source can still produce a positive. An upstream layer republished empty answers a count query cheerfully. Something in the pipeline has to be able to notice that a signal which used to fire has stopped firing entirely.
Keep the overlay hit and the legal conclusion in different fields. A polygon locates a parcel. A statute decides what that implies, and usually it implies less than the layer's name suggests.
Carry source, as-of date and confidence on every rule. Rules as code without provenance is a number with no way to tell curated from guessed, and the guess is where the large errors live.
Treat a default as an answer. Conservative in the typical case is not conservative in the tail, and the tail is where the decision is expensive.
Preserve a source's refusal to answer. It is information, it is cheap to carry, and it is the one thing a downstream model cannot reconstruct.

The overlay does change the answer. What took longest to get right was the smaller claim underneath it: knowing when the overlay has not answered at all.

Originally published at rantum.xyz, which is the canonical source.

Andrew Maury is the founder of Rantum, a senior data science and ML studio that turns messy, fragmented and adversarial data into models, APIs and products that ship. The pipeline in this piece is part of AddressIntel.

Null Is Not Zero: What an MCP Tool Description Has to Carry

Andrew Maury — Wed, 14 Oct 2026 17:06:21 +0000

A REST API's documentation is read by a developer once. An MCP tool description is the one piece of text a model reads on every single call, which makes it where you stop an agent misreporting your numbers. It is also prose, so it goes stale like prose.

AddressIntel reads building permits and parcel records across the SF Peninsula and scores what could be built on a given lot. It already had a REST API. Putting a Model Context Protocol server in front of that API is, as engineering, close to trivial: the whole thing is 312 lines of TypeScript across two files, six tools, and a client that adds a header, builds a query string and unwraps the API's error envelope.

What is not trivial is that the consumer changed. A developer reading REST docs forms a mental model once, writes code against it, and that code then behaves the same way forever. A model reads the tool description on every call and decides, each time, what the returned numbers mean and how to report them to whoever asked. The description is not documentation. It is the contract, and it is enforced by nothing.

That matters here more than it would for most data, because this data is full of ways to be confidently wrong. A teardown ROI of null is not a zero. A score that ranks candidates is not a return. A negative number is usually correct. Get any of those wrong in a summary to a buyer and you have invented a deal that does not exist.

What got built

Six tools over stdio, published to npm as addressintel-mcp and listed in the official MCP registry under the DNS-authenticated namespace co.addressintel/permits. search_permits for issued permits by city, keyword and valuation; list_sb9_inventory for lot-split and duplex eligibility with the per-parcel block reasons; list_adu_leads and list_redevelopment_leads for feasibility-ranked parcels; list_market_signals for the opportunity feed; get_property_intelligence for one property in depth.

The declaration keeps each tool's validation schema and its advertised JSON Schema side by side in one object, because a tool that spells its shape out twice in two separate blocks will eventually spell it differently:

interface ToolDef<T extends z.ZodTypeAny> {
  name: string;
  description: string;
  inputSchema: { /* advertised to the client */ };
  args: T;                    // validates the incoming call
  run: (args: z.infer<T>) => Promise<unknown>;
}

Two decisions in the transport layer are worth more than the rest of the code put together, and both exist because the caller is an installed agent rather than a developer at a terminal.

The first is what happens with no API key. The first draft of this client sent no auth header at all, so every endpoint returned 401 and the server was useless until you went and got a key. Now an unset key falls back to the literal string demo, which the API recognises as a public tier at 10 requests per minute and 5 rows per call. The server does something real the moment it is installed. A human will go find a key when they hit a wall; an agent will simply report that the tool is broken.

The second is error shape. The API returns a readable error in its failure envelope, and that string gets surfaced to the model rather than a bare status line, because it is what tells the agent whether to narrow the query, back off, or ask the user for a key. A status code tells a model nothing it can act on. For the same reason, a lookup that misses returns { found: false, message: "No property found with ID: ..." } rather than null: outside our coverage area a miss is a normal answer, not a failure, and it should arrive in words the model can pass along.

API_BASE defaults to the published domain rather than the bare App Hosting URL. Both serve the API, but the latter moves with the backend, and an installed client is the worst place to hard-code something that moves.

The descriptions are where the guardrails live

Here is the part I did not expect to spend the most time on. The description field for list_market_signals ends with three sentences that are not describing anything:

Quote those assumptions alongside the number. null means not modellable, with unmodellableReason naming the missing input: treat it as unknown, never as zero. Negatives are normal here; most of this market does not pencil.

That is an instruction to a model, sitting in a schema field. It is there because the alternative is an agent that says "four of these properties show a 0% return" when what the data said was "I could not model four of these properties." get_property_intelligence carries the matching one in the other direction: its scores rank candidates, none of them is a return, and the tool explicitly tells the model that this endpoint carries no ROI figure at all and points it at the other tool for one.

I went looking for how often that guard actually fires. Asking the live API for the five rows a demo-key agent gets, on 2026-10-14:

San Mateo: proformaROI null, reason no_envelope_rule
San Jose: proformaROI null, reason no_envelope_rule
Saratoga: proformaROI -7
Los Altos Hills: proformaROI null, reason no_envelope_rule
San Jose: proformaROI null, reason no_envelope_rule

Four of five null, one modellable at -7%, no positives. Both instructions are load-bearing on the very first call a new agent makes. An agent that reads null as zero reports four flat deals; an agent that does not know negatives are normal either suppresses the one real number or flips its sign. Five rows is a demo-tier sample and I am not generalising it to the corpus, but it is exactly what an agent sees, which is the population that matters for this question.

The reason the nulls are nulls took me a second read of the predicate to state correctly, and it is not the jurisdiction story I assumed. no_envelope_rule is parcel-scoped, not city-scoped: it is true when no curated allowable floor area governs a single-family rebuild on that parcel, which five separate conditions can cause. Measured against a production snapshot on 2026-09-03, 501 of 1,039 modelled active listings landed there, and 423 of those were condos, townhomes and multi-family units that never had an envelope to give. Another 56 were unincorporated county parcels, 2 were single-family rows the floor-area pass had not reached, and 20 carried a curated envelope more than four times the existing house, which is a rule that exists being deliberately distrusted. So the dominant case is a property type the model does not apply to, not a city nobody has curated.

In all five cases the served proforma refuses rather than substituting a default, which is the only defensible choice: a substituted envelope produces a number indistinguishable from a real one. The predicate was added after a Saratoga listing cleared an internal shortlist at 39.8% on a nine-thousand-square-foot build that nothing but existing x 1.5 had sized. The on-page calculator still seeds a default for a human to drag; the served number never quotes it.

Two of my own instructions had already gone stale

While checking the above I found that the description I have been praising is wrong, in two places. One drifted three days after the server's last commit, the other about two weeks later.

The hard cost. The list_market_signals description tells the model the proforma assumes "$400/sqft build," and tells it to quote those assumptions alongside the number. The live API serves assumptions.costPerSqft: 550. The constant moved from 400 to 550 on 2026-08-21, three days after the server's last commit, because 550 is the midpoint of a verified $400-700 builder band and 400 was the band's floor, which flattered every deal. Measured over 407 gated active listings at the time of that change, moving the hard cost 400 to 550 to 700 took the median ROI from -3.9% to -14.3% to -22.9%, and the count of parcels clearing 20% net from 60 to 28 to 15.

So the payload carries 550 and the prose next to it says 400, and the prose is the thing instructing the model to quote it. The field is right there in the same response, but nothing obliges a model to prefer a field it was not told to read over a sentence it was told to repeat. A stale number in REST docs misleads a developer who will probably notice. A stale number in a tool description is actively read out to the end user as an assumption behind a figure it does not match.

The history window. On 2026-09-03 the free tier was windowed to 30 days of history, grandfathering every key created before 2026-09-04. The server's paging argument still says only "Clamped to your API key's tier ceiling," which was a complete description of the tiers when it was written and is not one now. Nothing in the server mentions a history window at all; the word does not appear in its source, README or manifest.

The API itself is better behaved than its tool description, and the difference is the whole point. The two routes that apply the window, permits and market signals, both report a historyWindow field in the response, explicitly so a windowed caller can tell a quiet 30 days from a broken query; the other four routes the tools hit are not windowed at all. What is missing is any instruction to read it. For a question like "has anything been permitted at this address," a free key minted since that date is answering from the last 30 days, and the difference between a no and an unknown is sitting in a field the model was never told about. Worth being precise about the scope, too, since "30 days" sounds larger than it is: on the permits tool it windows permit history, but on list_market_signals it touches sold rows only and the active feed stays whole.

There is a third, cheaper instance I may as well report: src/index.ts still announces itself to clients as version 1.1.0 while the package and the registry manifest are both at 1.1.2. That one misleads nobody, which is exactly why it survived. I am not counting it alongside the other two, because those are instructions a model acts on and this is a string.

None of these is exotic. They are the ordinary consequence of putting operational constants into prose in a separate repository with its own release cycle, and they are the strongest argument I have for generating the volatile parts of a tool description from the same constants the API serves, rather than writing them by hand.

Getting listed is the other half of the work

Publishing an MCP server and having anyone able to find it are different projects. Seven surfaces, re-checked live on 2026-10-14:

Official MCP registry - listed, v1.1.2. Took a DNS-authenticated namespace and a manifest that validates against the schema.
Glama - listed, tools indexed. Auto-indexed, then claimed; the maintenance score wanted CI, a tagged release and a glama.json.
awesome-mcp-servers - merged 2026-09-07. A PR, corrected to the repo's own category conventions.
npm - 1.1.2, published from CI with a scoped token. The bin shebang is what makes it npx-runnable.
mcp.so - submission still open at 68 days. Free listings are nofollow ugc; the paid dofollow tier was declined.
Smithery - blocked upstream. The bundle path rejects any bundle declaring tools, and their issue has been open since June.
PulseMCP - structurally closed. New submissions are paused while they rework ingestion.

Four of seven landed cleanly, one is open indefinitely, one is blocked by a bug in somebody else's tooling and one has the door shut. The useful pattern is that the surfaces which worked are the ones with a machine-checkable artifact behind them: a manifest that validates, a published package, a repo a crawler can read. The ones that stalled are the ones gated on a human reading a queue. If you are planning this work, budget for the manifest and the package, and treat the directory listings as a lottery you enter cheaply.

On adoption I have nothing to report and will not pretend otherwise. npm shows 191 downloads in the 30 days to 2026-10-13, which for a package in this position is mostly mirrors and crawlers rather than people; the repo has no stars; PulseMCP alone lists over 21,700 servers. AddressIntel has never been monetized and has no customers. What exists is a published, installable capability, measured honestly.

What this shows

The adapter was an afternoon. The work was deciding what a model is allowed to conclude from each field, writing that into the one place the model reads on every call, and then going back and checking the contract against the live API instead of trusting it. That check is what found the $400 and the missing history window, and neither was visible from the code, the README or the repo's own commit history.

Exposing data to agents is becoming the default ask, and the easy part of it is the protocol. The hard part is that an agent will restate your numbers to someone who cannot see the payload, which means every caveat that used to live in a footnote now has to be machine-readable and kept in sync with the system that produces it.

Andrew Maury is the founder of Rantum, a senior data science and ML studio that turns messy, fragmented and adversarial data into models, APIs and products that ship. Originally published at rantum.xyz, which is the canonical source.

Fingerprinting Hidden DEX Frontends by the Bytes Standard Decoders Ignore

Andrew Maury — Wed, 30 Sep 2026 15:30:28 +0000

A swap's calldata often carries a few bytes past the last ABI word boundary. Decoders throw them away. They are some of the only on-chain evidence that an interface tagged the trade, and most of the work went into not saying which one.

The problem

Shared execution infrastructure gives a DEX frontend no standard way to sign its own trades. A swap placed in a wallet's built-in swap tab, in a portfolio app, or on a white-label interface reaches the same routers and the same pools as a swap placed on the router's own website, and lands on-chain looking identical. That is the attribution problem ClearTrace exists to work on.

Some interfaces do leave a mark, in a place nothing reads. A well-formed ABI call is a four-byte selector followed by some number of thirty-two-byte words. Stick a tag on the end and the call still works, because the decoder reads the arguments it expects and ignores whatever trails them. Etherscan renders the call cleanly. A decoded-trades table carries the swap with no sign of the tag at all.

So the tag sits there unread, in the one part of the transaction everybody throws out. Finding it is arithmetic on a length:

def has_calldata_suffix(input_hex: str) -> bool:
    """
    A well-formed ABI call is a 4-byte selector (8 hex chars) followed by some
    number of 32-byte words (64 hex chars each). A trailing remainder that
    doesn't fill a word is an appended fingerprint: the signature of modular
    frontends and wallet-native swap extensions.
    """
    if not input_hex:
        return False
    h = drop_hex_prefix(input_hex)
    n = len(h)
    return n > 8 and (n - 8) % 64 != 0

That is the whole detector. (The prefix strip is inline in the original; I gave it a name here so the arithmetic is the only thing on the page.) Notice what it does not do. It reads none of the bytes. It tells you something is there and nothing at all about what, which turns out to shape everything downstream of it.

What the bytes actually look like

The test is one of the vectors in ClearTrace's attribution kernel, next to direct-versus-proxy routing, fee-recipient detection and aggregator-router matching. The kernel does no I/O: hand it a transaction, a receipt and a function that resolves addresses to labels, and it hands back a classification. That means every decision in it can be tested against a static fixture. A second module maps the classification onto the published taxonomy, one of named frontend, aggregator-API-direct, wallet-embedded, bots and MEV, or unattributed, and tags it with a confidence tier that describes the method rather than how well-known the name is.

Both run per transaction on the live public API, so I could just point it at real trades. Everything below came out of it on 2026-09-30. The raw calldata I pulled separately, from a public node.

I took fifty consecutive Ethereum DEX trades above $1,000: a 3-minute-48-second window on 2026-09-29, 16:10:23 to 16:14:11 UTC, against Uniswap, Curve and Fluid pools, ranging from $1,043 to $1,999,358 with a median of $3,452. (Those sizes are the feed's leg-summed notional, a larger basis than the conserved figure in the aggregate table further down. I am flagging it because the last section of this piece complains about exactly that kind of double-count.) Eight of the fifty carried an unaligned tail on the top-level call. Here is what was actually in them:

1inch AggregationRouterV6, selector 0x07ed2379, 4 unaligned bytes, tail 2a6f45f2
An unlabelled contract (0x278d...f8d2), twice, selector 0x70521ae9, 3 unaligned bytes, tail 000012
MetaRouterGateway, twice, selector 0xa11b1198, 29 unaligned bytes, beginning bc_nlhvsi52 in ASCII
An unlabelled contract (0x881d...300c), selector 0x5f575529, 1 unaligned byte, tail 1f
A 7702 delegated EOA (0x0000...089b), twice, leading bytes 0x80000000, 23 and 30 unaligned bytes, packed payload

The MetaRouterGateway pair is the one I would hang something on: a byte-identical twenty-nine-byte tail on two separate transactions, starting with the ASCII string bc_nlhvsi52. Somebody's client identifier, in plain text, in calldata, where no standard decoder looks. The four bytes on the 1inch swap call are almost certainly a referral or partner tag, sitting after every declared argument has been filled, though I cannot prove that from the bytes alone. The three-byte 000012 tail does repeat across two transactions to the same contract, which is the pattern this vector is named for, but three low-entropy bytes are about as likely to be a packed trailing field as a tag.

Then there is the last row, which is where the whole thing gets its limit. Its leading four bytes are 0x80000000 and the rest is not ABI-encoded at all, just a packed argument block. There is no last word boundary for a tag to sit past, so the unaligned remainder the test reports is the payload. When I looked up the contract, its code turned out to be twenty-three bytes starting 0xef0100, an EIP-7702 delegation designator rather than a program, so the account is a delegated EOA and there probably is a wallet-side execution surface behind it. That came out of the contract code rather than the detector, though. What the detector caught here was an encoding choice.

That ceiling is structural and there is no clever way around it. Length arithmetic cannot tell an appended tag from an encoding that was never word-aligned to begin with, and two of my eight hits are the second kind. Some unknown share of every hit is noise like that. You can still use a detector in that state, but only if nothing downstream is ever allowed to read a hit as an identity.

What the eight hits were allowed to conclude

So how many of the eight produced a named frontend? None. All eight came back unattributed, at low confidence, with a separate fingerprinted flag set true. Two rules did that work, and a third sits in front of both.

A suffix on an aggregator's own router names no frontend. One of the eight was a 1inch AggregationRouterV6 call. A tag on an aggregator router could belong to the aggregator or to somebody's interface layered on top of it, and there is no way to tell, so neither gets the credit. There is one hole in this, and the code does not hide it: if the router's label matches a wallet, it is taken as an in-wallet swap at high confidence no matter what the aggregator flag says.
A suffix whose label matches nothing on the marker lists names nothing either. The other seven were on contracts with no label, or with a label that appears on neither the frontend nor the wallet list: three unlabelled, the two delegated accounts, the two MetaRouterGateway calls. I should be honest about that last pair. MetaRouterGateway is a routing interface. It goes unnamed because the marker list has not caught up, which is a coverage gap dressed up as a principled refusal.
MEV and bots get checked before the suffix at all. Two of the fifty went to bots_mev on their originator label alone. Neither carried a suffix, so nothing actually collided here. It matters anyway: the biggest contract by suffix-overlay volume on Ethereum is an atomic-arbitrage searcher. Check the suffix first and you strip that searcher of its bot classification and file it as fingerprinted-unattributed instead. Worse, anything labelled as both a bot and a wallet would go out as an in-wallet swap at high confidence.

The flag is doing more work than it looks like. unattributed with fingerprinted: false means I found no evidence. unattributed with fingerprinted: true means an interface definitely tagged this trade and I could not work out which one. Those are two different admissions, and squashing them together is how a coverage number quietly starts flattering you.

The two layers also rank the suffix differently, which confused me until I read both. The kernel's primary_vector puts it fourth, behind proxy, aggregator and fee-recipient, because that field answers how the trade was routed. The taxonomy puts it second, behind only the MEV check, because that one answers what I know about the interface. Same transaction, two questions, two orderings.

One guard in the naming path failed, and it failed the way guards do. To attach a name, the resolved label has to look like an interface, which in practice is a substring match against a marker list. One protocol on that list has a two-character name that is also the prefix every hex address starts with. The labeller, meanwhile, puts addresses inside names all the time: Wintermute (0x51c7…8ac2), Ethereum First Funder: 0xa4aF…. Every label of that shape read as a frontend. So a suffix-tagged transaction carrying one of them went out as a named frontend at high confidence, unless an infrastructure exclusion happened to catch it first. The fix strips address-shaped tokens out of the label before matching and then requires the marker to stand alone as its own word. Of all the places to put a matching bug, the high-confidence tier is the worst one.

The feed I drew these from is a rolling one-day sample, so it has already rotated and you cannot reproduce my fifty. Here are the eight hashes instead, so you can put them through the endpoint yourself:

0xbd1df7e5bfa30e7b28acae7343def9e6f2137e047072d267d4f4833892ae0ed2 (1inch AggregationRouterV6)
0x562b40b68022f1ed6d9c97a1ceec06d3f37215331509a2f28d1ccaf5ce33f75d (unlabelled, 0x278d...f8d2)
0xb008c636327b9f43e7c928c94fcd6fe22ca5d5001a028a941d2b2d8c624d5345 (unlabelled, 0x278d...f8d2)
0x9bb462fced2c7b5d7aabe31332d32ff000a4cfcea41a44a65127c18c8da01935 (MetaRouterGateway)
0x198342c58a22d5264dcfb1e5ed49a4d76faf72353d351bbb1047092935a2fdb7 (MetaRouterGateway)
0x7f0deb69de0f2e9d54ad7a85615ec20997d240b8f9f6577fe4bfe6cdf6173e6a (unlabelled, 0x881d...300c)
0x39f7f878402227b87b2d1197e68692791d626ee728d1bc333522161612310aea (7702 delegated EOA)
0x685667cee982f6aecc8ad596a832076804cc59846b960d207cdf144ad48acdb9 (7702 delegated EOA)

More evidence, less attribution

The endpoint has a deep mode that fetches internal call traces, widens the aggregator match to the whole call path, and runs the suffix test on every sub-call. More information, so better answers, or that was my assumption. One caveat first, because the code is plain about it: the live path counts a suffix on any traced call frame, reverted and static ones included, while the Dune version of the same vector requires a successful call. So some of the jump below is just a looser test. I did not measure how much. Here are the twenty newest transactions of the sample, run both ways:

Carrying a calldata suffix: 3 top-level only, 7 with traces
Attributed to any class: 4 top-level only, 3 with traces
Fingerprinted and unidentified: 3 top-level only, 7 with traces

Before anyone lifts those numbers: they are per-transaction counts on fifty consecutive trades above $1,000, and they are not coverage. ClearTrace publishes coverage volume-weighted over a seven-day window, currently 89.5% on Ethereum. A fifty-trade slice of mostly retail-sized swaps does not compare to that figure in either direction.

Traces more than doubled the fingerprints and left the sample less attributed, which is not what I expected to find. Five records changed state. Four of them just picked up the fingerprinted flag. One picked up an identity: an originator labelled only Market Maker turned out to reach KyberSwap's MetaAggregationRouterV2 further down the call path, and moved from unattributed to aggregator_api_direct. Two went the other way, down from aggregator_api_direct at medium confidence to fingerprinted-unattributed at low, because a suffix showed up on a sub-call and the aggregator rule says a tagged router is not the interface. The fifth one is my favourite: an ERC-4337 EntryPoint call whose traces also reached MetaAggregationRouterV2, and the suffix rule threw that identity away too.

One name gained, two lost. I am fairly relaxed about that trade, and one of the two was never a published name anyway, since its venue is withheld from output under a separate policy. Tune this system for coverage and it keeps both.

Why the big number is an overlay and not volume

The same test also runs at scale, in the Dune query behind the aggregate attribution table, over every successful internal call instead of just the top-level one. At that grain it goes off on most of the market. From the live API on 2026-09-30, against a trailing seven-day window whose attribution table was written 2026-09-29 16:20 UTC:

Ethereum: 4,077 contracts, $6.16B conserved volume, $5.13B suffix overlay (83.3%), and 2,180 rows whose overlay exceeds that row's own volume
Base: 3,716 contracts, $5.71B, $4.10B (71.9%), 1,392 rows
Arbitrum: 852 contracts, $1.07B, $527M (49.2%), 352 rows
Optimism: 231 contracts, $143M, $117M (82.2%), 112 rows

On 2,180 of Ethereum's 4,077 contract rows, the suffix figure comes out larger than that row's entire conserved volume. The two are counted at different grains: conserved volume takes each transaction's notional once, the overlay sums the legs. The top row on Ethereum is that atomic-arb searcher again, at a $982.1M overlay against $945.0M of its own routed volume.

You cannot add a column to a total it can exceed. So it rides along as a reported overlay, out of the headline sum, with the reasoning written into the query instead of left for whoever reads the output next. The query keeps a note about what happens if you fold the sibling fee overlay back in: the Ethereum total jumps sharply and overshoots the independent third-party estimate of the same market. Double-counting announces itself as a number you like.

Which settles what this vector is actually for. At the trace grain it is nearly everywhere, so it cannot tell frontends apart. At the transaction grain it is rare and specific and, on a live sample, names nobody. Either way its job is to mark the edge of what I know.

What this proves

Finding a signal nobody else reads took an afternoon. The rest of the work was the layer that decides what the signal is allowed to conclude, and then checking what that layer really does against live trades rather than trusting what its docstring says about it. On this sample it turned eight fingerprints into zero names and one honest flag, and dropped two medium-confidence attributions as soon as better evidence said they were shaky.

Any vendor can report coverage. The hard part is drawing a line you can defend between what a dataset knows, what it suspects and what it only inferred, and then putting that line on every record so a buyer can act on it. That is the part that survives contact with an adversarial domain, and it is the part Rantum builds.

Originally published at rantum.xyz, which is the canonical source.

Andrew Maury is the founder of Rantum, a senior data science and ML studio that turns messy, fragmented, and adversarial data into models, APIs, and products that ship. He spent roughly four years on data infrastructure at 0x Labs, advised the Uniswap Grants Program, and has done client work for Art Blocks.

Scraping Adversarial Municipal Portals: A Permit Pipeline That Knows When It Failed

Andrew Maury — Wed, 16 Sep 2026 16:24:02 +0000

Most California cities publish their building permits, and almost none of them publish the same way. The San Francisco Peninsula alone runs six vendor portal products (eTRAKiT, on at least two incompatible forks; Tyler Technologies' EnerGov and Civic Self Service; Accela; Clariti; PermitStack), one municipal open-data feed, and one city whose only complete record is a monthly report it posts as a document. Searches are login-gated, JavaScript-rendered, and driven by ASP.NET postbacks that rewrite the form under you. Two of the portals answer only to a real browser.

A blocked request is loud: it throws, the run goes red, somebody fixes it. The failures that cost you are the ones that return a well-formed answer to a question you did not ask.

This is a write-up of the permit-collection layer behind AddressIntel, a real-estate intelligence product built on fragmented municipal records. As of 2026-09-16 it holds 187,838 permits across 20 permitting jurisdictions: nineteen cities and towns, plus unincorporated San Mateo County, whose rows carry the names of seven coastal communities. 177,522 of the permits carry an assessor's parcel number and 128,324 carry a declared valuation above zero.

Two things about that count belong next to it. Coverage is uneven, from 53,160 rows in Palo Alto to 28 in Foster City, and a city with few rows is either quiet or under-collected, which the rest of this piece is about telling apart. And 39,830 rows, 21% of the total, carry no issued date: 37,235 of those are Palo Alto's, from an open-data export that publishes an application date and a lifecycle status for each permit (33,641 of them Finaled) but no issue date. The remaining 2,595 are spread across five other sources with mixed statuses, including 372 marked Issued that carry no date for it. One Saratoga row is dated 2026-10-03, seventeen days after this was written, with an application date of 2025-10-01. It is stored as the portal printed it.

Two failures that look like data

Failure one: the empty list that looks like a quiet month.

One city's portal login was being rejected on every run. The scraper printed a warning, returned an empty permit list, and the pipeline reported success. A city we actively cover disappeared from the product for weeks and nothing alarmed.

Then the absence turned into a zero. The city's demolition-permit count rendered as 0, indistinguishable from a city that had filed none, and that zero reached public copy written for builders in that market.

Failure two: the result set that is not the answer.

Every eTRAKiT host caps a search result. It applies the cap before sorting, it emits no error, and once the grid's page size is raised past the cap the pager that would have read "page 1 of N" disappears. Nothing on the page distinguishes a truncated result set from a complete one except its size.

The rows it keeps follow the portal's own internal order, which skews heavily oldest-first, so the truncation drops the newest permits: the only ones a recent-activity scrape exists to find.

1. Measure the cap; never assume it

Because nothing on the page announces truncation, the size of the result set is the only tell available, and it has to be read before anything is trusted. Each host's cap was measured directly on 2026-08-25, one query per host, page size raised to 2000 so the whole set arrived at once:

Host	Cap	`ISSUED AT LEAST 01/01/2015` returned
Atherton	100	100 rows, newest issued 2018-07-16
Hillsborough	500	500 rows, newest issued 2020-01-08
Saratoga	500	500 rows, newest issued 2015-04-09
Redwood City	1000	1000 rows, 743 of them from 2015

The cap ranges from 100 to 1000 across four hosts of nominally the same product, so it cannot be hardcoded once and forgotten. It is also independent of page size: page one of the un-resized grid reports "page 1 of N" with N times the page size equal to the cap exactly, and raising the page size past the cap returns the cap with no pager at all.

Sorting does not help. Sorting AT LEAST 01/01/2026 on the Hillsborough host by issued date descending, which is what the scraper's own sort helper does, still returns that query's 500 rows stopping at 2026-04-22, while the city has been issuing permits continuously since. (That is a different query from the one in the table above, which is why its cut-off date differs; both saturate at 500.) Sorting reorders the survivors. It does not change which rows survived.

Two hosts in the fleet are login-gated, so their caps are unmeasured rather than absent, and the code keeps that distinction. For those, the fallback test is a total landing exactly on a round number: a result set is a count of permits a city happened to issue, and that count landing on exactly 500 by coincidence is far less likely than it landing there because something clipped it.

def etrakit_is_saturated(total_rows, url=None, cap=None):
    """True when a result set of `total_rows` is sitting on its host's cap.

    Saturated means TRUNCATED: the portal returned as many rows as it will
    ever return, so there are almost certainly more records matching the
    search than came back, and the ones missing are the newest.

    Deliberately >= rather than ==: a host that raises its cap, or one whose
    cap was measured low, must still trip this.
    """
    if total_rows is None:
        return False
    cap = cap or etrakit_result_cap(url)
    if cap:
        return total_rows >= cap
    return total_rows in ETRAKIT_ROUND_CAPS

2. Find the one bucket the platform cannot truncate

Detecting truncation is only useful if there is something better to do than report it. The standard answer, bisect the query until each half fits, is unavailable here: the search offers one criterion and five operators (BEGINS WITH, CONTAINS, EQUALS, AT LEAST, AT MOST), there is no BETWEEN and no second field, the string operators reject a partial date outright, and AT MOST truncates from the same end, so an AT MOST query on the Atherton host comes back with 100 rows whose newest is 2008-04-28.

That leaves EQUALS on a single calendar day as the only bounded bucket the platform offers. Measured across the four date-search hosts, a single day returns 5 to 22 rows against caps of 100 to 1000. A bucket that small never reaches the cap, and the scraper checks each day's total anyway, so a day that did saturate would be reported rather than half-read.

The walk runs newest-first on a 45-day budget, because each day costs a postback and its settle time, and the freshest permits are the ones worth spending the budget on. Whatever the budget does not reach is named in the run log and recorded as a source failure. A historical backfill asks for 1825 days, which this path will not walk; the alternative is a backfill that returns the portal's oldest 500 rows and calls itself complete.

What the instrument reads. Across the sixteen scheduled runs from 2026-09-10 to 2026-09-16, twelve reached the Atherton host's date search. All twelve saturated its 100-row cap and fell back to the day-walk; the other four were cut off by the time budget before reaching it. None of the sixteen recorded an uncovered window, so the fallback never had to report a gap it could not close.

The outcome is visible in the database, which holds 138 Atherton permits issued on or after 2026-08-16, for a search the portal will not return more than 100 rows of. The town's 1,298-page records ingest cannot account for the surplus: it landed on 2026-08-05, before that window opens. Saturation on this host is the steady state, and without the fallback every one of those twelve runs would have reported success while handing back the oldest hundred rows of the window.

The budget that binds is max_permits, at 50. Every one of those runs stopped after 12 to 16 of the 31 days on that cap, which the walk inherits from the plain search. The 45-day figure is the ceiling on how far back a walk may reach.

A saturation the day-walk fully recovered from costs time and is therefore not recorded as a failure. Only days the walk could not cover are. A busy city would otherwise red the pipeline twice a day forever, which is the alarm-nobody-reads failure mode the health gate exists to prevent.

3. Two gates, and the incident between them

The health registry records only failures the scrapers know about: a rejected login, an unreachable portal, a saturated search that could not be recovered. It does not infer breakage from a low permit count, because a quiet city and a broken scraper both produce zero permits, and guessing between them is how you build an alarm that cries wolf and then gets ignored. If a scraper cannot tell you it failed, that is a gap in the scraper.

That rule is right for the registry, and it was not enough for the pipeline. On 2026-09-01, two cities were found silently dead in production: Sunnyvale had added no permit row for 14 days, Woodside for 33. Every run in that window reported success, and three separate guards missed it. The registry saw nothing, because neither city failed in a way its scraper knew about: Woodside's date-walk searched a portal that has no date search and got a legitimate empty result, and Sunnyvale's aggregator answered HTTP 200 with frozen data. The freshness check read MAX(scraped_at) across every city at once, which San Jose alone holds at today forever, so it reported all sources fresh on the morning both cities were 14 and 33 days dead. The third guard reported which targets the time budget had cut off; Sunnyvale had been reached in 8 of the previous 11 runs and ingested nothing on every one.

A permit source can fail by succeeding at nothing, and nothing was watching whether rows actually landed, per city, over time. A second gate now does that. It infers from volume, the inference the registry refuses to make, and it makes it in one place, explicitly, with a threshold that can be read.

Sizing that threshold is where the interesting mistake lives. The obvious approach is to learn each city's normal silence from its own history, and that was tried first. Measured against the production snapshot, a dozen unrelated cities shared an identical 13-day gap in August 2026, a rotation failure that had reached only half the target list for twelve days. A threshold learned from that history would have set Sunnyvale's tolerance to 20 days and slept straight through its 14-day outage. A guard that learns "normal" from a record containing its own failure mode gets blinder every time it fails. The threshold is sized from how much each city normally files instead, with a ten-day floor.

Three details of the registry follow from the same reasoning.

Failures flush on every failure. The scrape executes under a timeout that terminates it when the budget expires, routinely. Anything saved only at the end of the run is lost exactly when a slow, failing source is the likeliest cause.
The gate runs last, after the sync and the data-store save. The run goes red, but every byte the scrape did manage to collect is already persisted. A red run that kept its data is the goal.
Known-unscrapable sources report without reddening the run. Where the fix is a new data source rather than a retry, a permanent red is a switched-off alarm. Entry into that list requires a tracked issue and a stated reason.

The retry policy is drawn on the same line. A timeout, a stale element reference, an intercepted click, a grid that did not re-render, an ASP.NET postback that never landed: these differ between two runs against unchanged markup, so they get one more attempt with a fresh driver. Two red runs in August 2026 were of this kind, one dying on an index error and one on a renderer timeout. For the first, the run ninety minutes earlier had walked the identical pages, blocks and pagers to a clean finish; that comparison was not made for the second. Neither was a markup change, and a single retry would very likely have absorbed both. In both, the sync and the data-store save had already succeeded, so they were red purely on an exit code.

NoSuchElement is excluded from that list. An element that is simply absent is the signature of a portal whose markup changed, which is real breakage and must red the run on the first attempt.

One inference across sources is safe. One quiet city is ordinary. Every city sharing a single scraper going quiet at once is a fact about the shared code, so a platform whose every source came back empty is reported as a known failure.

4. Knowing when scraping is the wrong answer

One town's portal has no issued-date search at all, only permit number and site address. A number-walk is technically possible; the town's permits carry year-prefixed series identifiers that the fleet's number-walk path already enumerates elsewhere. It is still the wrong fix, because that portal's public detail panel carries no declared valuation and no parcel number, and declared valuation is the field the town is carried for. A number-walk would restore row count while losing the column that matters, at roughly thirty-six seconds per permit. The route out is a recurring public-records request, and that channel now carries the town's entire permit record. Re-measured at publication against the September refresh, received 2026-09-11: 5,237 permits, of which 2,460 carry a declared valuation totalling $322,162,086. The town confirmed on 2026-09-01 that a standing arrangement is not available, so each refresh is its own request.

That entry in the registry also carries its own correction. It used to assert that the number-walk was impossible because the town's permit identifiers were pure numeric strings with no series prefix. They are not. The claim had been written while the town had zero scraped rows and nobody had yet seen a real permit number from it, and it survived until a records delivery revealed the actual format. Written into a code comment, an assumption made in the absence of data reads exactly like a measurement.

The results grid clips long descriptions to thirty characters server-side, with a literal ellipsis and no title attribute holding the full string, so the complete value is not on the page. The ellipsis is kept rather than stripped: it is the only record that the stored value is a prefix, and stripping it would make a clipped string indistinguishable from a complete one. Full strings arrive later from the sources that print them whole, and the writer never overwrites a value it already holds, so a clipped scrape cannot regress a complete record.

What this buys

A permit table assembled from these sources can carry a claim about its own coverage. The saturation check, the day-walk, the two gates and the retry line each turn one specific silent failure into a logged one, and the numbers above are what they read on a given week. When a vendor changes a form control, the run goes red and the data it collected stays saved.

A scraper that could not report its own failure produced a zero, and that zero became a published statistic. The pipeline now records "unknown" separately from "none", and the difference is what a buyer of this data is paying for.

Originally published at rantum.xyz, which is the canonical source.

Andrew Maury is the founder of Rantum, a senior data science and ML studio that turns messy, fragmented, and adversarial data into models, APIs, and products that ship. Previously ~4 years on data infrastructure at 0x Labs; past work advising the Uniswap Grants Program, and client work for Art Blocks.

Backed, or Just Named: Thirteen Forged Tokenized-Equity Tickers

Andrew Maury — Wed, 09 Sep 2026 20:49:17 +0000

Originally published at rantum.xyz, which is the canonical source.

Thirteen contracts on Base forged five of Coinbase's tokenized-equity tickers and recorded $393,805 of volume before they stopped. Coinbase says the genuine tokens beside them are backed one-for-one. Neither the name nor the bytecode tells the two apart. One on-chain check narrows it, and it is worth being exact about how far.

Four things a token can be

In Money Stuff on 9 September 2026, Matt Levine set out a taxonomy for tokenized stocks. A token carrying a company's name, he observes, can be one of exactly four things. It can be stock, issued on-chain by the company itself. It can be an SPV: "I buy 1,000 AMC shares, I put them in a pot, and I issue exactly 1,000 tokens against that pot." It can be a swap, an IOU for the asset's return. Or it can be nothing: "I issue 1,000 tokens each representing one AMC share, and you buy them, and I don't owe you anything. They're just, like, crypto tokens with the name 'AMC' on them." He notes the fourth is out of fashion in equity tokenization, "though it is a very traditional approach in crypto generally."

Levine is writing about Robinhood, whose tokens Robinhood describes, in a statement he quotes, as "backed 1:1 by the corresponding underlying equity." By his taxonomy a token like that is the second kind. That classification is mine, applied to his categories; he is not describing the contracts below, and this piece borrows his ladder and nothing else.

What the taxonomy leaves open is the question a holder actually has. Four categories are named, but nothing in that column says how someone holding a token would work out which of the four they hold. That question has a partial on-chain answer.

What measurement can and cannot settle

A rung is a claim about the world off the chain. Whether shares are sitting in a custodian's account is not visible from a contract, so on-chain data cannot confirm the first three rungs. No amount of reading state proves a pot exists.

It can do the opposite. On-chain data can show that nothing is behind a token, which rules out the first three and leaves only the fourth. The check is cheap and it runs in one direction. What follows is a namespace where running it separates the second rung from the fourth inside a single set of search results.

What I found

Everything below comes from two sources. Contract state (name, symbol, decimals, totalSupply, eth_getCode) was read directly from Base over RPC on 3 September 2026 and again on 9 September. Volume comes from one execution of a query over Dune's decoded dex.trades table for Base, window 1 July to 3 September 2026, run on 3 September; those figures are leg sums, which count each leg of a route and are an upper bound on the collapsed per-trade figure.

Coinbase publishes a list of thirteen B20 tokenized-equity contracts on Base. On 3 September, four of them had traded: NVDAc, AAPLc, METAc and GOOGLc, tracking NVIDIA, Apple, Meta and Alphabet. By 9 September ten of the thirteen carried supply, so the asset class is being issued faster than this piece is being written. In the window the four traded $241,972,775, which is 0.167% of all Base DEX volume in the same window. Aerodrome Slipstream carried 86.46% of it.

Alongside them, in the same window, thirteen impostor contracts forged five of those tickers: NVDAc, AAPLc, METAc, GOOGLc and COINc. Together they recorded $393,804.68. Ten of the thirteen ran a uniform pattern: roughly half an hour of life, between 58 and 71 distinct taker addresses, then nothing. The three COINc contracts ran differently, each with a single taker, two of them recording $138,882 between them in consecutive half-hours.

COINc is worth a sentence on its own. Coinbase's COINc contract is on the published list, but as of 9 September its supply is zero; the genuine token has not been issued. The three COINc forgeries recorded $138,882 against a real token that did not yet exist. Nothing in this dataset is a cleaner example of Levine's fourth rung.

The address shape is not an identifier

Coinbase's B20 contracts share an 88-bit address prefix, 0xb200000000000000000000, which Base documents as the standard's address convention. It reads like a namespace badge. Eighty-eight bits is not something a forger mines, and nobody had to: the prefix comes with the deployment path, and 7,532 distinct tokens on Base carry it. The first pass at measuring this asset class matched on the prefix, and the highest-volume NVDAc, AAPLc and METAc rows it returned were forgeries. A prefix check does not need to be defeated. It clears the impostors for free.

The name does not separate them either

The obvious fallback is to read name() and compare it with the company. That clears the forgeries that match and flags only the ones that do not bother.

Two of the thirteen return a name() of NVIDIA Corporation, byte-identical to Coinbase's own contract. Four use Meta Platform Inc., one character away from the real Meta Platforms Inc. Four more return the bare ticker. A name check passes the two exact matches and catches the four that were never going to pass anything.

And neither does the bytecode

Bytecode fingerprinting is the technique that cracked the mainnet impersonator fleet, where 1,005 contracts shared one byte-identical 5,150-byte runtime. It returns nothing here. eth_getCode at every address in this namespace, genuine and forged alike, is the single reserved byte 0xef. Whatever machinery on Base answers eth_call for these addresses, it is not per-contract runtime, so there is no code to hash and no fingerprint to compare. I did not investigate the mechanism; the negative result is what matters for detection.

How to detect it

One check remains, and it is the one that reads the backing rather than the branding. Coinbase's contracts carry 8 decimals and a supply denominated in shares. Every impostor carries 18 decimals and exactly 1,000,000,000 units.

-- Base mainnet, read 2026-09-09 (morning, UTC-7)
-- canonical NVDAc
decimals()    = 8
totalSupply() = 15,473.08          -- a share count

-- forged NVDAc, same prefix, same name() string
decimals()    = 18
totalSupply() = 1,000,000,000.00   -- a round number, chosen not derived

The intuition runs backwards. A supply of one billion at 18 decimals is not a forgery signature; it is the ordinary default in this namespace. Five unrelated tokens on the same prefix, picked by hand on 3 September, are all 18 decimals and four of the five carry exactly one billion. The impostors look normal. Coinbase's tokens look unusual, because 8 decimals and a share count are what one-for-one backing forces on you. The test only works if you already know what the genuine article looks like, which means the issuer's published contract list is the thing actually separating them, and the supply shape is a way to notice when a row does not match it.

The stronger signal: the supply moves

A static reading is a snapshot, and a forger can copy a share-shaped number for the cost of one deployment. A claim backed one-for-one has to be minted when someone deposits and burned when someone redeems, so its supply moves. Reading the same contracts six days apart:

token	supply 2026-09-03	supply 2026-09-09	change
NVDAc (canonical)	12,640.08	15,473.08	up
AAPLc (canonical)	5,773.03	7,276.36	up
METAc (canonical)	2,978.89	2,130.54	down
GOOGLc (canonical)	not recorded	7,976.14	(no 09-03 reading)
all 13 impostors	1,000,000,000.00	1,000,000,000.00	none

By the evening of 9 September the canonical figures had moved again: NVDAc to 15,537.08, GOOGLc to 8,046.14, and AAPLc down to 6,702.59. A number that goes down is the useful one, because a decrease is what redemption looks like from outside, and a fixed-supply forgery cannot show one without actually burning tokens.

It is important not to overstate this. A forger with a mint-and-burn function can simulate movement, so drift is evidence of an active issuer process rather than of custody. What it does is raise the cost of forgery from a one-time deployment to an ongoing one. In this dataset none of the thirteen paid it: every impostor sat at exactly one billion across both readings. That is the same shape of result as the name check, forgers who did not bother, at a higher price. It rules out the empty case and is consistent with the second rung, which is the most that reading a chain delivers.

What this does not show

It does not verify Coinbase's custody. Everything above is consistent with one-for-one backing and rules out the empty case. Confirming that shares sit in an account is an audit question, not an on-chain one, and nothing here touches it.

It does not establish who was on the other side of the $393,805. "Taker" here means a distinct address that took the other side of a swap in the decoded trade data. Whether those addresses were independent of the deployers was not measured, and the uniform ~30-minute, ~60-taker lifecycle is consistent with automated new-token sniping. So the $393,805 is volume the pools recorded, not demonstrated third-party demand, and nothing here claims anyone was harmed. The finding is that the forgeries were indistinguishable by the checks most people would run; whether anyone ran one is unknown.

The window is 1 July to 3 September 2026, and volumes are leg sums. The thirteen impostors are the ones that appeared in that window; nothing rules out others before or since.

Supply figures drift, and that is the point of the section that uses them. The 3 September canonical readings had all moved by the morning of 9 September and again by the evening. Every figure here is a timestamped reading, not a standing fact.

The separate Ethereum mainnet fleet shares a playbook with these contracts. Whether it shares an operator was not looked for.

Why it matters

Three intuitive checks on this namespace all fail. The address prefix is shared by 7,532 tokens and costs nothing to obtain. The name is copyable and was copied byte-for-byte. The bytecode is a single reserved byte for everyone. Three plausible verification strategies, each returning a confident wrong answer.

The check that works reads what is behind the token and watches whether that number behaves like a claim on something. It cannot confirm the claim. It can rule out its absence, and in this case it did, for ten of Coinbase's contracts and none of the thirteen forgeries.

One Pool Deep: Available Capacity Is Not a Realized Fill

Andrew Maury — Tue, 08 Sep 2026 16:23:05 +0000

Originally published at rantum.xyz, which is the canonical source.

Two measurements of Uniswap execution landed on the same surface this month, and at a glance they look like the same measurement. One reconstructs how much liquidity a pair actually holds. The other measures what a trader's order actually received. A desk evaluating execution needs both, and using one where the other belongs is a mistake worth naming. This is the short version. The full note, with every figure and its source, is on the rantum.xyz research page linked above.

The supply-side measurement: how much a pair could absorb

A public study on ethresear.ch, "When Multiple Pools Behave Like One: Impact-Constrained Capacity Concentration in Uniswap v3," reconstructs daily Uniswap-v3 pool state from Mint, Burn, and Swap events and asks a counterfactual question: for a given pair on a given day, what is the maximum notional you could push at a fixed price-impact tolerance, on the single best pool versus split across the pair's sibling fee-tier pools?

Its headline result, across 293,273 family-day-direction-impact cells over 78 pairs on Ethereum (January 2024 to June 2026), is that the depth that matters at a fixed impact tolerance sits in one fee tier. The median effective number of pools is 1.076, and a single tier holds a median 96.3% of impact-constrained capacity. Despite several fee-tier pools per pair, at the liquidity layer a pair behaves like one deep pool. The author scopes this tightly and says so: it measures capacity at the liquidity layer, and gas, routing frictions, MEV, and cross-layer effects are out of scope. It is how much could be executed, not what was.

The demand-side measurement: what an order actually received

ClearTrace starts from the opposite end. It takes an aggregator's quote and the fill that actually settles, measures the gap in basis points, and decomposes it into the pieces that caused it:

output_gap_bps = (quoted_out - realized_out) / quoted_out * 10,000
slippage_bps   = output_gap_bps - fee_bps - mev_bps

A reverted trade is never forced into that formula, because a failed trade decomposed nothing. It is counted as a rate across a batch instead. This runs over actual and fork-simulated fills at fixed sizes ($1k, $10k, $100k, $1M), and it deliberately includes the three things the capacity study sets aside: MEV, reverts, and routing topology.

The numbers it produces are realized outcomes. On the 2026-08-26 sampler export across Ethereum aggregators, the median fill lands at or within a fraction of a basis point of its quote at every size cohort, while fork-verifiable quotes fail to realize at a low single-digit rate that varies by size (3.6% at $1k, 2.2% at $100k, 4.5% at $1M). These are demand-side measurements: what a specific order got, after the router did its work.

Why they are different objects

Available capacity is a ceiling. A realized fill is a result. The distance between them is exactly the routing, MEV, and reverts the capacity study places out of scope, so neither number validates the other. A pair with an effective pool count near one can still deliver a clean fill, because a router works around a shallow book by splitting across venues. A pair with ample impact-constrained capacity can still realize badly, because MEV or a revert lands on the actual trade and never touches the counterfactual optimizer. They answer different questions about the same pair.

ClearTrace runs nothing resembling the study's method. There is no pool-state reconstruction and no capacity optimizer anywhere in its codebase. It never needed one, because it measures the trade rather than the terrain.

The one place they connect

There is a real link, and stating it precisely is more useful than overstating it. The study describes the terrain a router faces: at the AMM layer a pair is effectively one deep pool. ClearTrace's realized data shows median fills holding near their quote across sizes anyway. Those two facts are consistent only if size-aware routers are spreading orders across mechanisms rather than leaning on that one pool, and that is what the per-trade routing data shows: in the same export, 83.7% of sampled $1M routes split across more than one venue, a median of three distinct venues per route, against 69.0% at $1k.

At size, the extra venues are increasingly not AMM pools at all. On the same export, the share of KyberSwap's sampled Ethereum routes touching at least one off-chain RFQ leg rises from 2.2% at $1k to 10.0% at $10k, 21.5% at $100k, and 81.1% at $1M over the full sample span. That last figure moves month to month, so read it as a range rather than a constant. RFQ depth is exactly the liquidity a pool-state reconstruction cannot see, so at $1M the realized fills in this data route dominantly through depth that is invisible to the study's optimizer by construction. The study explains why aggressive size-aware routing exists. ClearTrace measures whether that routing actually delivers.

What it means for a desk

If you evaluate execution, you want both views and you should not substitute one for the other. The supply view tells you how much a venue can absorb before impact bites, which is a property of the pool. The demand view tells you what your order actually received, which is a property of your trade and the route it took. A venue can look deep and fill you badly. A venue can look shallow and fill you well through a router. One number without the other is half the picture.

The full research note, including the sourcing for every figure, is at rantum.xyz. ClearTrace is at cleartracedata.com.

Andrew Maury is the founder of Rantum, a senior data science and ML studio that turns messy, fragmented, and adversarial data into models, APIs, and products that ship. He has 6+ years in crypto: he previously scaled data at 0x Labs, contributed to Dune's Spellbook, and advised the Uniswap Grants Program.

The Liquidity Mirage: $3.28B of Reported Liquidity, Backed by 0.0007 ETH

Andrew Maury — Wed, 02 Sep 2026 15:27:40 +0000

Originally published at rantum.xyz, which is the canonical source.

A Uniswap V3 pool on Ethereum mainnet reports $3,286,019,931 of liquidity. The real assets backing it are 0.000739 WETH, which at $2,410.77 per ETH is about $1.78. Both figures are accurate, and the gap between them is the whole story.

This is what turned up while building a much less interesting thing: a browser extension that flags impersonator tokens in DEX listings.

The challenge

Token discovery surfaces have a verification problem that price feeds do not. A ticker is not an identifier. Anyone can deploy a contract whose name() returns "Dai Stablecoin" and whose symbol() returns "DAI", and nothing in the resulting search result distinguishes it from the real one. The contract address does, and the contract address is exactly the field that gets truncated in every list view.

The usual answer is a blocklist of known scams, which is a race you lose: new contracts deploy faster than any list is maintained. The inverse works better. Instead of enumerating what is fake, enumerate what is canonical, keyed on (ticker, chainId), and flag a row that shares a ticker on the same chain with a different address.

Building that check surfaced something more interesting than the check.

One bytecode, two deployers

Searching a handful of blue-chip tickers on DexScreener returned rows that looked like ordinary duplicates. They were not. Fourteen contracts on Ethereum mainnet impersonated nine well-known tokens and ran an identical playbook rather than being fourteen coincidences.

Those fourteen turned out to be a rounding error. Enumerating every contract the two deployer wallets ever created returns 1,031 deployments, 1,005 of which carry that same 5,150 byte bytecode, split almost exactly evenly at 503 and 502. Running the detector described below across all 1,005 finds 184 impersonating a canonical ticker outright, across 143 distinct real tokens, plus 59 more cloning tickers that have several legitimate claimants. The remaining 762 use names no curated list carries, which is ordinary memecoin noise. That is still a floor: only two deployer wallets were enumerated.

Every one of the fourteen returns the same 5,150 byte runtime bytecode, SHA-256 prefix 7ff6feb2ee87face. The tokens they impersonate do not resemble each other at all: real DAI is 7,904 bytes, CRV 4,369, COMP 6,795, PEPE 4,517, every one distinct. Identical bytecode across fourteen supposedly unrelated tokens is a deployment fingerprint, not a coincidence.

Blockscout's contract metadata names the source MintBurnTeamToken, an off-the-shelf mintable template, and attributes all fourteen to just two externally owned accounts, split eight and six. No creation transaction is indexed for any of them, which is consistent with factory deployment instead of direct creation.

The tickers spoofed: DAI, CRV, APE, SHIB and LDO twice each, plus COMP, ENS, GRT and SNX. Nine tickers, fourteen contracts.

The mirage: $3.28 billion from an initialization tick

The impersonation is cheap and common. The reported liquidity is the interesting part. Take the fake DAI pool, 0x90e6...5a87, a Uniswap V3 pool at the 0.3% fee tier, and read its state directly:

balanceOf(fakeDAI, pool)  = 2,506,024,274.84   // worthless token
balanceOf(WETH,    pool)  =         0.000739   // the entire real backing
slot0().tick              =          -75,180   // chosen at initialization
price(token1/token0)      =    0.0005434 WETH  // derived from that tick

A Uniswap V3 pool is initialized at whatever price its creator chooses, because that price is a tick rather than a consequence of deposited capital. A V3 position is then defined by a price range, and that is the part that does the work here.

The Mint event for this pool provides liquidity across the range [-75180, 887220]. The lower bound is exactly the initialization tick, the price the pool still sits at today. The upper bound, 887220, is the highest tick the 0.3% fee tier permits, so the range runs from the chosen price to effectively infinite price. When the price sits at the very bottom of a range, the position is denominated entirely in token0 and requires none of token1 at all.

So the deposit was 2,506,024,276 minted tokens and 0.000000000 WETH. Not a rounding error of WETH. None. The same structure appears on the CRV, SHIB and COMP pools, each opened with a single-sided position and zero WETH. The 0.000739 WETH sitting in this pool today did not come from the deployer; it is the accumulated dust of the daily cron buying its own token, a few thousandths of a cent at a time.

DexScreener values those reserves at the pool's spot price and reports the product as liquidity:

2,506,024,274 tokens x $1.31 = $3,286,019,931 of "liquidity."

The displayed price rounds to $1.31, and reproducing the total to the dollar takes the unrounded $1.3112. That rounding is worth $3.1 million on its own, which is a fair illustration of the scale being discussed.

The pool holds 0.000739 WETH, and that is a hard ceiling: it is the most anyone could ever extract by selling the token back into it, whatever the quoted price says. At $2,410.77 per ETH that ceiling is $1.78. The reported figure exceeds it by a factor of roughly 1.8 billion to one. Nothing is wrong with the arithmetic. The arithmetic is correct on inputs that were manufactured.

The fingerprint repeats, exactly

What makes this tractable to detect is that the operation never varied its parameters. Every one of the six pools sampled shows the same signature: a large reported liquidity, one cent of reported 24 hour volume, and precisely one buy and zero sells. Re-read 24 hours later, on 2026-09-02, all six returned identical figures.

That is not neglect. It is a schedule. The fake DAI pool's full swap history is 103 trades between 24 February and 2 September 2026, and in the last sixty days it traded on forty out of sixty days, thirty-seven of them between 04:00 and 04:59 UTC. The other three sampled pools cluster in the same window. Each trade is dust: roughly 0.012 of the fake token out for about 0.0000066 WETH in, about one and a half cents.

So the "one buy, $0.01 of volume" reading is not a stale cache and not a dead pool. It is a daily cron job buying a fraction of a cent of its own token, which is exactly enough to keep the pair looking traded to an indexer that sorts on recent activity. The listing is maintained.

Ticker spoofed	Pool created	Reported liquidity	24h volume	Buys / sells
DAI	2026-02-24	$3,286,019,931	$0.01	1 / 0
CRV	2026-02-28	$431,462,383	$0.01	1 / 0
ENS	2026-03-07	$389,657,165	$0.01	1 / 0
LDO	2026-02-28	$212,719,545	$0.01	1 / 0
COMP	2026-03-08	$130,141,448	$0.01	1 / 0
SHIB	2026-03-08	$42,017,195	$0.01	1 / 0

Those six pools alone account for $4,492,017,667 of reported liquidity. All six were created between 24 February and 8 March 2026, and all six were still live, still listed, and still returned by ticker search on 1 September 2026, more than six months later.

Where the exposure is, and where it is not

This is not evenly distributed across venues, and it would be sloppy to imply it is. A live ticker search for CRV in the Uniswap interface returns six genuine Curve deployments across six chains, plus yCRV and cvxCRV, and none of the fleet. Searching by contract address is a different matter: the picker resolves any address pasted into it, fleet contracts included. What the curated list governs is what surfaces when a user types a ticker, and none of the fourteen appear on the Uniswap Labs default list.

The exposure sits on aggregators like DexScreener that index every pool by design, where comprehensiveness is the product and filtering is left to the reader. That is a stated design choice and not an oversight, which is precisely why the filtering has to come from somewhere else.

Detecting it without accusing the innocent

The detector is a canonical allowlist keyed on (ticker, chainId), built from independently maintained token lists rather than hand entered: 2,289 tickers and 3,675 ticker and chain pairs. Two decisions carry most of the weight.

The chain key is not optional. Keying on ticker alone flags every legitimately bridged token as an impersonator. The same real PEPE appears on seven chains, the same real CRV on six. A ticker only check would have called all of them fraudulent on day one.

Sources are ranked, not pooled. Curated lists (Uniswap Labs Default, 1inch) decide the canonical address. A permissive source (CoinGecko), which lists essentially every token with a market page, gets no vote on the address. It only reports how many other projects claim the same ticker on that chain. Treating all sources as equal peers deletes the tickers that matter most: PEPE, SHIB, UNI and APE all vanish, because a permissive list carries "Pepe King Prawn" and "El Sapo Pepe" alongside the real thing. Their presence is not evidence that real PEPE is ambiguous.

That second signal then gates the accusation. A red "not the canonical contract" verdict is only issued when every source agrees the ticker has exactly one claimant on that chain. Where a ticker has several legitimate claimants, the verdict degrades to "more than one project uses this ticker, check the address yourself."

That gate exists because the first version did not have it, and was wrong twice on a single page. It flagged Milady Cult Coin, its own project with several million in liquidity and trading since December 2024, for not being Cult DAO. It flagged the wojak token doing $202k a day for not being the Wojak Coin doing $5.5k a day, calling the more actively traded asset the fake. Neither was impersonating anything. Both tickers simply have two real claimants, and the canonical holder of a ticker is a curator's assignment rather than a fact. A measurement layer that cannot tell those two situations apart should not be issuing verdicts on either.

What this does not show

Nobody appears to have fallen for it, and that is worth stating precisely because it is stronger than the usual "no victim flow was traced". Reading every swap on four of the pools, the counterparty is always the wallet that deployed the token: 100 of 100 on the fake DAI pool, 99 of 99 on CRV, 93 of 93 on SHIB, 77 of 77 on COMP. In six months these pools have had no external participants at all. The contracts are live, findable and misrepresented, and so far the only person trading them is the person who made them.

Nor is "one operator" established. The two deployer wallets each service only their own tokens, and they are not linked. Both were touched early by the same address, which looked like a possible controller until it was read: it sends one identical 514 byte message to each of 2,996 distinct recipients, and the message decodes to a freelance designer advertising branding work to token deployers. It is unsolicited marketing, not a funding link.

The two deployer accounts were not deanonymised. The MintBurnTeamToken label comes from public contract metadata and was not independently source verified. Pool economics were measured on six pools and the daily schedule on four; the other 999 contracts are confirmed by bytecode and ticker, not by reading each one's pool.

Every number above was read directly from Ethereum mainnet via eth_getCode, eth_call, pool state and swap logs, or from the public DexScreener and Blockscout APIs, on 2026-09-01 and 2026-09-02. Prices move and pools can be removed, which is why the measurements are timestamped.

Why it matters

Verification and indexing are different jobs, and conflating them scales badly. An indexer that reports what a pool says about itself is not lying. It is faithfully reporting manufactured inputs. The gap between reported and real is where the work is, and closing it takes ordinary discipline: read the underlying state directly, key your joins on identifiers instead of labels, and be willing to return "I do not know" instead of a confident wrong answer.

Fabrication is getting cheaper. Seven ten-thousandths of an ETH bought a $3.28 billion listing that survived six months on a major discovery surface. Independent verification gets more valuable in exact proportion.

The Revert Rate That Lies: Why You Cannot Rank a DEX Metric Across Execution Models

Andrew Maury — Wed, 02 Sep 2026 14:53:54 +0000

Originally published at rantum.xyz, which is the canonical source.

A revert rate answers one question: how often did a swap fail on-chain? It reads like a clean reliability number, and a leaderboard that ranks venues by it looks like a fair reliability ranking. It is not one, because the number only means the same thing across venues that fail the same way.

This is a short account of a measurement trap that is easy to fall into, hard to see once you have, and directly hostile to a benchmark that claims to be neutral. It is also a record of ClearTrace falling into it, shipping the mistake to production, and then building the fix into the pipeline so the invalid comparison cannot be made again.

The same number, two different measurements

Start with how a swap actually fails, because that is what decides whether its failure is countable.

On a router, the user signs and submits the swap. 1inch, Uniswap, KyberSwap, ParaSwap, and Odos all work this way. If the swap fails, it fails on-chain, ClearTrace sees it, and the revert rate is exactly what it looks like: the odds your transaction does not land.

On a batch-auction venue like CoW Protocol, the user signs an order, not a transaction. A solver wins the batch and submits one settlement transaction for everyone in it. An order that cannot be filled, from a bad price, no solver, or expiry, simply never becomes a transaction. The user's failure is invisible on-chain by construction.

On an intent venue like 1inch Fusion, the shape is the same. The user signs an intent, a third-party resolver fills and submits it, and an unfilled or expired intent leaves no trace on-chain.

So the on-chain revert rate of a batch-auction or intent venue is structurally near zero, and it is near zero regardless of how reliably the venue actually fills. It is not measuring reliability. It is measuring settlement.

The direction of the error is the dangerous part

Measured live on Ethereum over the trailing seven days (September 2026), CoW's revert rate reads 0.53% and 1inch's Limit Order Protocol reads 0.56%, while the routers 1inch and KyberSwap read 1.11% and 1.75%. Sort that single column and the two off-chain venues sit at the top as the most reliable.

That ordering is a category error, and the specific way it is wrong is what makes it corrosive. It flatters exactly the venues a third party can measure least, because their failures never reach the chain to be counted. A benchmark that systematically favors the venues it cannot see is not neutral, whatever its intentions. That is the fastest way to lose the one thing a third-party benchmark is for.

The discriminator is who submits, not where it settles

The tempting shortcut is "off-chain settlement means no reverts." It is wrong in a way that matters. In classic request-for-quote, the market maker signs a quote, but the taker still submits the transaction carrying that signature. An expired quote or a short maker balance therefore does revert on-chain, in the user's own transaction. A venue like that is router-shaped for measurement even though its price came from off-chain.

So the rule is not about where the price originated. It is a single question: does a user's failed swap become a transaction anyone can count? If yes, the venue is a router and its revert rate is comparable. If no, its revert rate is structurally near zero and is not a signal. If the answer is not established, or the venue runs more than one model, it is unclassified and never ranked.

The taxonomy, and the guard that enforces it

ClearTrace encodes those four models as one taxonomy that every consumer imports from a single module, so the rule cannot drift between the dashboard, the API, and the pre-send checks. A short excerpt:

# Execution models
ROUTER, BATCH_AUCTION, INTENT, UNCLASSIFIED = "router", "batch_auction", "intent", "unclassified"

# The ONLY model whose tx-level revert rate measures user reliability, because it
# is the only one where the transaction that fails belongs to the user.
REVERT_COMPARABLE_MODELS = frozenset({ROUTER})

class CrossModelComparison(ValueError):
    """Raised when code tries to rank/compare revert rates across execution models."""

def rank_by_revert(rows, rate_key="revert_rate_pct", project_key="project", strict=True):
    """Rank venues by revert rate, best first, WITHIN ONE EXECUTION MODEL.
    Refuses to return a list that mixes models, because such a list ranks nothing."""
    rankable, refused = [], []
    for r in rows:
        (rankable if is_revert_comparable(r.get(project_key)) else refused).append(r)
    if strict and refused:
        raise CrossModelComparison(
            "refusing to rank revert rates across execution models: these venues do "
            "not submit the user's transaction, so their on-chain revert rate is not "
            "comparable to a router's.")
    rankable.sort(key=lambda r: r.get(rate_key))
    return rankable

Every published row is stamped with its execution_model and a revert_comparable flag. Those two fields are live on the public API today, so a downstream consumer, whether the ClearTrace dashboard or an outside script, can never read a batch-auction revert rate as reliability without being told otherwise. And a compare page does not print a suppressed head-to-head as a blank. It replaces the number with the reason: a sentence explaining that the two venues settle differently, that the off-chain venue's on-chain revert rate is therefore structurally near zero regardless of how reliably it fills, and that putting it beside a router's would overstate its reliability rather than measure it. The refusal is legible, not silent.

Under-claiming is the default

A venue ClearTrace has not established is unclassified, and unclassified never ranks on revert. Absence of evidence is not evidence. A venue that runs both models is also unclassified: Bebop settles taker-submitted quotes, where a failed fill reverts in the user's own transaction, and solver-submitted intents, where failures never land. A rate over that mixed population answers no question, so ClearTrace does not rank it until the two are split. The same discipline applies to a venue like Tokenlon, whose very low on-chain rate would top any reliability ranking, which is exactly why it needs evidence about who submits rather than an assumption.

Why the guardrail exists

None of this is hypothetical. ClearTrace once shipped the sentence "CoWSwap's revert rate is 0.04% versus ParaSwap's 1.41%" to production, in body copy and in indexed FAQ schema. That is a 35x reliability claim, and it was purely an artifact of settlement: CoW's number was structurally low because unfillable orders never became transactions, not because it executed 35 times more reliably than a router. A flattering wrong number costs a neutral benchmark its credibility exactly as a damaging one does. The taxonomy, the CrossModelComparison guard, and a pre-send claim gate that blocks any cross-model revert claim before it leaves the building are the response to that specific mistake.

What it proves

The rare skill here is not a model or a scraper. It is knowing which comparison is invalid and building the refusal into the pipeline, so a metric that looks universal is only ever computed over the population where it means something. Finding signal in adversarial data includes declining to manufacture signal that is not there, even when the invalid version would make the product look more complete.

For a foundation, a grant program, or a protocol team spending real money against a metric, that is the difference between a dashboard and a source of record: a benchmark whose numbers survive contact with the teams they describe, because the one comparison that would embarrass it is blocked in code rather than caught in review.

The full case study is at rantum.xyz. ClearTrace is at cleartracedata.com.

Where Did This Trade Come From? Attributing DEX Volume in Dune SQL

Andrew Maury — Thu, 27 Aug 2026 15:14:59 +0000

This is an adapted excerpt from Chapter 6 of my book, The DeFi Data Quick-Start: Reading On-Chain Truth with Dune Analytics. The book goes from your first Dune query to a dashboard you can defend. This chapter is the hardest problem in it.

The one field that isn't there

A row in dex.trades tells you the chain, the venue, the tokens, the amounts, and the transaction hash. It tells you everything except the one field half the money in DeFi wishes existed: where the trade came from. No origin: uniswap-web-app, no frontend: metamask-swaps, nothing.

That missing field is worth a great deal. Incentive programs, business development deals, and market-share claims all hinge on an answer nobody can read directly off the chain. Reconstructing it is the discipline called attribution, and it is mostly a matter of knowing where to look.

Two identical rows, two different worlds

Consider two rows from dex.trades: same day, same pool, each a swap of 2 WETH for USDC minutes apart. In the curated table they are nearly indistinguishable.

Behind the first is a person. She opened her wallet app, tapped the built-in swap button, and accepted a quote. Her wallet's backend called an aggregator, the aggregator picked the route, and the trade settled through a router into the pool. Four parties touched that flow, and if anyone deserves credit for bringing the user, it is the wallet whose button she tapped.

Behind the second is a bot: a market-making program calling the pool contract directly. No frontend, no human, no quote, just an automated rebalancing loop.

A volume dashboard counts these two rows identically. An incentive program that rewards "adoption" pays them identically. Attribution is the work of telling them apart, at scale, from public data alone.

Why the obvious answers are wrong

The chain gives you two address fields per transaction, and it pays to see exactly why neither answers the question.

tx_from is the wallet that signed the transaction. It tells you who traded, not which interface brought them. Ten thousand different tx_from addresses might all be customers of a single wallet app.

tx_to is the first contract the transaction called. This is the field naive dashboards actually use, and it systematically credits the wrong layer. It names the router, the plumbing, not the frontend. Every trade through a given aggregator's contract shows the same tx_to, whether the user came from the aggregator's own site, a wallet's swap tab, or an integration none of us has heard of. Attributing by tx_to is like attributing retail sales to the delivery truck.

The true origin, the app or interface where the user actually was, usually never appears on-chain as an address at all. It has to be inferred from the shape of the transaction. Different origins leave different fingerprints. There are four kinds in practice, and the first is nearly free when it is present.

When the trade signs its own work

Sometimes a transaction carries more than the trade itself. A few APIs append a few identifying bytes to the end of the call data: a tag the contract never reads, riding along to say "this order was built by integration X." The 0x API's affiliate suffix worked this way. Others pass the integrator as an explicit argument that the contract decodes, the way 1inch's referral parameter routes referral fees. Both land on-chain, permanently, in every block explorer.

Where these tags exist, attribution is one join away: extract the marker, join to dex.trades on the transaction hash, and map tags to names. Here is the appended-tag form as a runnable probe. It ranks the most common 16-byte call-data tails across a few hours of Ethereum DEX flow:

with tails as (
    select
        bytearray_substring(
            tx.data,
            bytearray_length(tx.data) - 15,
            16
        ) as calldata_tail,
        t.tx_hash,
        t.amount_usd
    from dex.trades t
    join ethereum.transactions tx
        on t.tx_hash = tx.hash
        and tx.block_time >= now() - interval '6' hour
    where t.blockchain = 'ethereum'
        and t.block_time >= now() - interval '6' hour
        and bytearray_length(tx.data) >= 16
)
select
    calldata_tail,
    -- tags ride on transactions, not fills
    count(distinct tx_hash) as txs,
    sum(amount_usd) as volume_usd
from tails
where calldata_tail
      <> 0x00000000000000000000000000000000
group by 1
order by txs desc
limit 25

Run it and the tagging convention stares back at you. The query drops the all-zero tail up front, because that bucket is mostly untagged flow and call data that ends in zero-padded arguments. What remains is candidates. When I ran this in July 2026 while drafting the book, one high-frequency tail held the hex spelling of a short ASCII name with a counter beside it: an integrator marking its own orders in plain sight. Run the probe yourself and you will find it, or whoever is tagging this month.

One caution before you attribute anything to a tail. It can also be the end of an ordinary function argument, since token addresses produce repeating fragments too. Treat a candidate tag as a hypothesis. Pull a handful of its transactions, check the entry contract, and confirm the pattern holds across several days before it earns a name.

The real limit is the word voluntary. Tagging is a convention some APIs offer and some integrators use. It is not a standard, and it is not enforced. Absence of a tag is not evidence of absence of a frontend. A system that counts only tagged flow will undercount exactly the integrators who never opted in, and overstate the "direct" share by the same amount.

The other three techniques, in brief

When a trade carries no tag, three more techniques pick up the flow:

Known-contract registries. Routers, aggregator entry points, wallet swap contracts, and custom proxies all have stable addresses. Label one once, and every past and future trade through it becomes attributable retroactively. A single proxy label can reclassify millions in volume. This is why ClearTrace tracks over 172,000 attributed contracts across Ethereum, Base, Arbitrum, and Optimism: the unlabeled long tail is where misattribution hides.
Trace fingerprints. The internal call tree has a shape. A protocol's own frontend produces a compact tree, a wallet-native swap adds a fee hop and an extra transfer, an aggregator split fans across several pools, and a bot calling the pool directly shows almost no tree at all. No single shape is definitive, but across thousands of transactions from one entry point they classify with high confidence.
Fee-recipient clustering. Most frontends skim a small fee to a collection address as part of the swap. That address is a signature: every trade paying the same recipient came through the same integration, named or not. I wrote a full walk-through of this one on its own, Who Got Paid: Identifying Anonymous DEX Frontends by Their Fee Recipient.

The part most dashboards skip

The four techniques combine into a cascade, strongest evidence first. One sensible ordering: explicit call-data tag, then registry match, then trace fingerprint, then fee-recipient cluster. A real system tunes that order to its own confidence in each signal, and screens out known bot and MEV contracts before classifying anything. And then the step that matters most:

If none of them fires, leave the trade unattributed.

That is the design, not a failure mode. A neutral attribution system reports its unattributed share instead of forcing every trade into a bucket, and it treats that residual as a headline number about its own coverage. When you see an attribution chart that sums to a clean 100% with no "unknown" slice, you are looking at a method that either got very lucky or made something up. No serious system attributes everything; a real one measures its own coverage and reports the gap.

So here is ClearTrace's gap, for the record. As of August 2026, roughly 10% of DEX volume across Ethereum, Base, Arbitrum, and Optimism sits in the unattributed bucket, ranging from 8% on Ethereum to 17% on Optimism. The shape underneath is the interesting part: nearly 99% of tracked contract rows are unnamed, while nearly 90% of volume is named. The head is easy. The long tail is the job.

State the method, show the denominator, publish the residual.

The DeFi Data Quick-Start is on Amazon now, in Kindle and paperback. The book's runnable queries and a live dashboard are on the free companion page at rantum.xyz/quickstart.

Who Got Paid: Identifying Anonymous DEX Frontends by Their Fee Recipient

Andrew Maury — Thu, 20 Aug 2026 17:40:08 +0000

Originally published at rantum.xyz, which is the canonical source.

Most swaps do not announce their origin. A meta-frontend, a wallet's in-app swap tab, and a Telegram trading bot can all route through the same public router, emit the same Swap event, and leave calldata that looks generic. Three of ClearTrace's four attribution vectors work on routing evidence: was the entrypoint a known aggregator, did the user call a pool directly or through a proxy, is there a fingerprint appended to the calldata. When all three come up empty, the transaction is anonymous by every structural measure.

But an anonymous frontend is usually still a business, and a business takes a cut. When that cut is taken inside the swap transaction itself, the way affiliate and referral skims are, it has to move on-chain where the receipt records it. That is the evidence this vector reads. A frontend that sweeps its revenue later, or monetizes off-chain entirely, leaves nothing here. And one dependency shapes everything downstream: finding who got paid is mechanical, but naming them requires a label somebody has already attached to that address.

The problem is that the cut does not identify itself. There is no fee standard on Ethereum. Individual projects emit their own fee events, LiFi's collector contract logs a FeesCollected event a decoder can subscribe to, but nothing generic marks one token movement as revenue and another as settlement across the long tail of routers this vector exists for. A frontend's revenue is an ordinary ERC-20 Transfer log sitting in a receipt beside the swap's own transfers, structurally identical to them. You cannot decode it, because there is nothing to decode. You can only work out which transfers are not part of the swap and see who is left.

Trap 1: identification by exclusion puts every error in the exclusion set

Turning "which transfer is the fee" into "which transfers are not the swap" is the move available here, and it relocates all of the risk into the exclusion list. Every category you forget to exclude becomes a false frontend. The user receiving their own output tokens is not a fee. The contract that was called is not a fee. A pool receiving the input side of the trade is not a fee. A token contract receiving its own token, which some fee-on-transfer designs do, is not a fee. A burn address is not a fee. Miss any one of those and the vector confidently reports a counterparty as the frontend that originated the trade.

Trap 2: a fee sink is a signal in one direction only

This one is not obvious until it breaks something. Once a candidate recipient is found, its identity comes from a resolved label, and the labels contain infrastructure names as well as product names. A contract labelled as a fee vault is strong evidence when it is receiving the skim: something paid it, and that something is the monetization path you are trying to name. The same label on the contract the user called means the opposite, or rather it means nothing, because a fee vault is not a user interface and treating it as one invents a frontend out of plumbing.

So the same marker has to be a positive signal in one position and no signal in the other. In the taxonomy this is a single boolean, as_fee_recipient, threaded through the name classifier to select which exclusion set applies. It is one flag standing in for a real asymmetry: evidence about who got paid does not transfer to evidence about who was called.

Trap 3: getting paid is not the same as being the frontend

Even a clean recipient with a clean label is indirect evidence. Referral programs pay addresses that belong to partners rather than to the interface. A single fee address can serve several products from the same team. An affiliate skim names whoever holds the affiliate relationship, which is often but not always the surface the user actually touched. The vector answers "who monetized this trade," and that is a strong hint about the frontend rather than a proof of it.

The implementation

# app/attribution_kernel.py: the fee-recipient vector.
# ERC20 transfers to an address that is not the user, not the called
# contract, not a pool, not a token contract, and not a burn sink —
# i.e. a party skimming a fee out of the swap.
excluded = {tx_from, tx_to} | BURN_ADDRESSES | pools
token_contracts = {t[0] for t in transfers}
fee_recipients = []
seen = set()
for token, recipient, raw_amount in transfers:
    if not recipient or recipient in excluded or recipient in token_contracts:
        continue
    if recipient in seen:
        continue
    seen.add(recipient)
    fee_recipients.append({
        "address": recipient,
        "name": resolve_name(recipient),
        "token_contract": token,
        "raw_amount": str(raw_amount),  # exact; no USD/decimals applied
    })

Two decisions in that block are worth pulling out.

The amount is stored exactly and never converted. raw_amount is the integer from the transfer's data field, kept as a string, with no token decimals applied and no USD price attached. That looks like an omission and is a refusal. Converting it requires the token's decimals and a price at that block, and both are lookups that can fail quietly and produce a number that is wrong by orders of magnitude while still looking plausible in a table. Attribution does not need the fee's value.

Recipients are deduplicated within a transaction. A single address can receive several transfers in one swap, on a multi-hop route or when both sides of a trade pay the same collector. Reporting it repeatedly would imply several fee events where there was one relationship.

The confidence tier, and the bug that set it

A matched recipient is handed to the frontend taxonomy, which resolves the label into a kind (wallet, frontend, MEV bot, or nothing) and returns a bucket with an explicit confidence. A calldata-suffix match returns high. A fee-recipient match returns medium, always, by construction: indirect but specific, which is exactly what an affiliate payment is.

The tiering earns its keep, and the repository records what happened when the name matching underneath it was too loose. An earlier version treated 0x as a plain substring marker for the 0x protocol. But 0x is also the prefix of every hex address, and the labeler routinely embeds addresses in names, rendering them as Wintermute (0x51c7…8ac2) or emitting heuristic labels like Ethereum First Funder: 0xa4aF…. Every such label matched. The comment in the source states the damage plainly: any suffix-tagged transaction carrying any non-MEV, non-wallet label was booked as a named frontend at high confidence. One loose substring rule silently promoted a large class of unknowns into confident, named, wrong attributions.

The fix was a stricter entity pattern, but the durable lesson is about tiering. A system that only emits identities cannot be audited after a matching bug. A system that emits identities with the evidence class attached lets you find every attribution that rested on the broken rung and re-evaluate exactly those.

Under-claiming, in code

The taxonomy sorts every transaction into one of five buckets: named frontend, aggregator API direct, wallet embedded, bots and MEV, or unattributed. The interesting case is a transaction that carries a calldata fingerprint proving some frontend tagged it, where the identity cannot be resolved. The obvious move is to guess from the router. The implemented move is to return unattributed with a fingerprinted flag set, so the leaderboard can show "fingerprinted, unidentified" as its own quantity rather than folding it into either a named frontend or the raw unknown pile.

What one real run returns

Method pieces are cheap without a run, so here is one: the 50 most recent Ethereum swaps in ClearTrace's synced dex.trades sample, a seven-minute window from 2026-07-01, receipts refetched from an archive node on 2026-08-20 and pushed through the kernel in receipt-only mode with ClearTrace's own label store answering resolve_name. All 50 classified. On 39, at least one transfer survived the five exclusions. The calldata-suffix vector settled 23, the aggregator and bot rungs took four each, fourteen resolved nothing, and the fee vector decided the final attribution on five.

Then we inspected the five, and this is the part that earns the confidence tier. Every one rested on a label attached to routing infrastructure rather than to a monetizing interface. Two resolved through an adapter contract whose name contains a venue string, so the frontend marker matched plumbing. The three we dissected transfer by transfer were not fees at all. In a $4,165 stablecoin swap routed through TransitSwapRouterV5, the surviving recipients were a market-making counterparty that received 2.655 WETH and paid back 4,165 USDC, a routing contract that both received and forwarded funds, and an address carrying an aggregator label that received the full trade notional. The taxonomy walked the list, hit the aggregator label, and booked a named frontend at medium confidence. In a $172k swap, three surviving recipients received the identical amount, which is not three fees, it is the notional in flight.

So the run's honest summary: in receipt-only mode, the exclusion set cannot tell a fee from a hop. Everything in a multi-hop route that is not the user, the entry contract, a pool, a token contract, or a burn survives, wearing whatever label it has. The vector found the route, not the revenue. The structural fix is known and not yet built: exclude every address that also sends within the same receipt, or use trace data to remove the whole call path. Neither exists in the kernel today. This run is the argument for building both.

What the tier system did do is exactly its job. All five wrong names went out the door marked medium and fee_recipient, which means one query finds every attribution resting on this rung, and re-evaluating them after the exclusion fix touches nothing booked on suffix or aggregator evidence. An untiered system would have published the same five names as flat facts and left no seam to find them by.

And that is also the honest answer to where this rung lives in production until the fix lands. The receipt-only kernel serves single transactions on demand, with the method and confidence in every response, and feeds no leaderboard. The vector's SQL twin, which does feed the aggregate dashboards, already treats fee-recipient volume as an overlay rather than as truth: the query credits the full trade amount to every qualifying intermediate, reports the result as its own column, and never folds it into the conserved volume total, with a comment in the repo measuring the over-crediting it would otherwise cause at roughly 80% of an Ethereum total. The rung stays because a quarantined hint is still a hint; nothing it produces reaches a published total.

What this does not claim

It does not cluster frontends by fee rate. The obvious next step from "who got paid" is "how much, as a rate," on the theory that a consistent basis-point cut would group several anonymous routers under one operator. That is not implemented, and the reason is in the design above: the vector deliberately holds the amount as a raw integer, so a rate would require the decimals-and-price conversion it exists to avoid, applied to both the fee and the trade notional, before any two swaps could be compared. A fee rate is also weak identity evidence in a way an address is not: interface fees cluster around a handful of conventional sizes, so a rate is a habit shared across unrelated products, where an address belongs to exactly one operator. The address is the identifier.

It also inherits every limit of the labeling layer beneath it. The vector can isolate a recipient cleanly and still return nothing, because there is no label for that address, and the run above adds the sharper failure: when the store's labels are attached to infrastructure, or simply wrong, the vector inherits those errors at medium confidence. Whatever it names, it names because someone already labelled the collector, so on genuinely anonymous frontends it can only surface what the label store already holds, and on this sample it correctly named none. And the exclusion set is a fixed list of five categories, not a learned classifier: a fee routed through an intermediate contract that resembles a pool, or paid in a later transaction rather than inside the swap, is invisible to this pass by construction.

Nothing in a swap receipt is labelled as revenue. The fee is legible only as the transfer left over once everything structural has been ruled out, so the exclusions are the entire product, and every category they miss walks into the output wearing a name. The run above is that account for this vector, published rather than filed.

The full case study, including the taxonomy cascade and what this proves to a client, is at rantum.xyz. ClearTrace is at cleartracedata.com.