What changed, and how to check it yourself

“USDC as gas means predictable low fees.” We measured it. Half of that is true.

It is the most repeated sentence about Circle’s Arc, and it is in almost every write-up of the chain. The low half holds: the median transaction we priced cost 0.0027893 USDC. The predictable half does not.

From 257 real transaction receipts across 30 blocks on 17 September 2026 — a fee being gasUsed × effectiveGasPrice ÷ 1e18, since USDC is the native gas token and effectiveGasPrice is what was actually paid rather than a bid:

• Median 0.0027893 USDC, p90 0.0259292, p99 0.38156811.
• Dearest transaction: 3.58270599 USDC — 1,284× the median. An agent that funds itself from the median is short by three orders of magnitude in the tail.
• Base fee ranged 20 to 58.5 gwei in that sample, with 23 of 30 blocks sitting on the 20 gwei floor.

The measurement that nearly went out wrong, which is the part worth publishing. Our first sample was twelve consecutive recent blocks. Every one reported a base fee of exactly 20 gwei at both minimum and maximum — which reads as a fixed price, and would have shipped as “gas on Arc is a constant”. Widening the sample to forty blocks spread across 500,000 found six above the floor and one at 202.67 gwei, ten times the minimum. The first sample was a quiet patch. Nothing was wrong with the arithmetic; the sample was the lie.

So the scanner spreads its blocks across the span instead of taking them consecutively, takes transactions from throughout each block rather than off the top where the highest-priority traffic sits, publishes how many blocks and receipts it failed to read, and refuses to state a 99th percentile below 200 samples, because a p99 drawn from 55 receipts is a single observation wearing a statistic’s name.

There is a euro rail on Arc, and nobody was reporting it

Circle EURC is live on Circle’s Arc L1 at 0xbEf5f6d51CB62b58e6A8f77868681825C6fe21c1, with a total supply of 6,240,343.79 read from the contract on 2026-09-17. It moves with every issuance and redemption, so the live figure is read from the contract in token.totalSupply of the product, never from this page. Every Arc data product we know of, ours included until today, is about new token launches and the people sniping them. An agent doing treasury or foreign exchange on Arc has a different question and had no source for it.

The measurement is a rolling window of the most recent 4,000 blocks, refreshed every ten minutes, so these counts are a scale rather than a constant. Two reads on 17 September 2026, each with 20 of 20 block ranges read successfully: 335 transfers moving 340,447.61 EURC, and forty minutes later 312 transfers moving 610,037.19 EURC, across about 109 distinct addresses both times. Of 60 counterparties we checked on chain, 23 were contracts rather than wallets.

The mistake we caught before publishing, because it is the kind that makes a number a lie. An ERC-20 Transfer event is not the same thing as a payment: issuance from the zero address and redemption to it are Transfer events too. The first version of this measurement reported 343,969 EURC moved, and inside that total sat a single 20,019 EURC mint — which also made its recipient the largest receiver on the chain, when in truth it had bought nothing. Issuance and redemption are now counted separately and never appear in the transfer total, and the recipient is no longer listed as a buyer.

Two smaller disciplines came out of the same work. Every log is de-duplicated on its transaction and log index, and the number of duplicates removed is published, so you can check the de-duplication rather than trust it. And the count of block ranges that succeeded and failed is published beside every figure: a range we could not read is reported as a failed read, never as a quiet chain. USYC, the other asset we checked on Arc, has a total supply of zero, so we built nothing on it and say so here instead.

Anyone can buy a building in APEX City with a card — including an empty plot

The 3D city has 926 buildings standing, every one with a build memo or a land deed on chain, and 862 empty plots (live: /api/city/capacity). Until today a card could only buy a building that already existed, so most of what a visitor tapped was not for sale at all, and the only way to build on an empty square was to connect a crypto wallet.

Now both cost the same $5 and both take a card. Tap a building and you buy its listing. Tap an empty plot and a house is built there and registered to you. No wallet, no account, no crypto — and a street square politely tells you it is a street.

What you get is the registry listing for that building: its plot, its name, and the right to display it. It is not a token. There is no mint and nothing to trade on an exchange.

Two services for agents that have nothing to do with blockchains

Most of what we sell reads chains. These two do not, and they are priced the same way: pay per call, in USDC on Arc, Base or Solana, or in XNT on X1.

Email list cleaning checks up to 100 addresses in one call: the shape of each address, its mail servers read live from DNS, known throwaway providers, and role accounts like info@ or support@. Each verdict says what it means in words. It does not knock on the mail server to ask whether one person’s mailbox exists — that means interrogating a stranger’s server about a private address, so we return the smaller true answer and say so before you pay.

Web page to text fetches up to 10 public pages and returns clean readable text with the title and description, redirects resolved. It is a fetch, not a browser: JavaScript is not executed, so a page that renders itself in the browser comes back thin — and the response says so rather than handing you a blank and calling it a result.

We said PROOF burns on every swap. It never did.

For months the PROOF pages said PROOF is burned at 0.3% per swap, forever. On 14 September we read the whole history on chain, and that was false. This is what really happened, and what we changed.

• One big burn, at launch. 1,237,000,000,000 PROOF were minted on 14 March 2026. Two seconds later exactly two thirds (824,666,666,667) were burned in a single transaction, and the mint authority was revoked.
• About 7.19 million more since then. Supply today is 412,326,148,326. Those later burns came from other actions, not from swaps.
• No swap has ever burned. Not one swap transaction on the PROOF pool contains a burn instruction.
• Why we cannot simply fix the program. The PROOF swap program can only be changed by its upgrade key, and that key is not an APEX wallet. The pool still works as a normal swap. Read on chain today, it holds 34.41 XNT and 434.16 million PROOF.
• What we changed. The false sentences are gone from every page, the invented burn chart was replaced, and an automatic check now fails if the claim ever comes back.
• What that means for you. PROOF swaps work as an ordinary swap and burn nothing. We no longer say otherwise anywhere, and if that ever changes, it will be written here first with the transaction to prove it.

Also corrected the same day, because they were wrong too:

• A validator we no longer run. The homepage still credited our old validator. We run no validator, and its vote account no longer exists on chain. Four validator API endpoints were still publishing invented figures. They now answer that the validator is gone.
• P21 on faucet claims. The homepage said a claim can drop P21. A claim has never paid P21; P21 comes only from the P21 Lottery.
• P21 distributed. The lottery counted 8 wins that were never collected as distributed. The figure now counts only the 153 payouts we checked one by one on chain.
• Early-bird slots. The counter was typed in as 210. The real number left is 49, and it is now read live.

We went through every page and stopped selling what we could not deliver.

A full audit of the site, page by page. The pattern that kept turning up was not broken code — it was a product that had been retired while the button that sold it stayed on the page.

• Staking to a validator we no longer run. A floating "stake" button on the homepage and the dashboard opened a dialog that would delegate real XNT to a vote account we have not operated for months. The server already hardcoded isApexDelegator = false, so the advertised 2x bonus could never have paid. Removed everywhere.
• Games that could not be played. Every status light on the games page was typed in by hand. The casino had been frozen since 24 April with five bets stuck mid-reveal, Echo Hunt’s only round expired on 14 April, and Eigenspace’s last move was 17 March — all three showed as live. Statuses now come from each game’s own ledger and go grey on their own.
• Services with nobody behind them. The Sentinel Market took payment for audits that depended on a partner unreachable since May, and delivered nothing at all for anything else. It now refuses payment for anything it cannot fill, and its one deliverable product — the price feed — hands over a working API key the moment you pay.
• Claims that were simply wrong. The referral programme said rewards “actually pay out”; nothing has ever been paid. The earn page advertised 5,000 APEX distributed daily; the real figure is about 90. The arcade claimed 380+ NFTs, then briefly claimed 13 after we read the wrong file — it is 381, and that correction is published here rather than quietly edited away.
• Where money can now change hands honestly. Card payment went live for banner ads and Wall tiles, because selling advertising space is an ordinary service. Anything that pays out a token stays crypto-only. Games that take a stake are limited to registered agents, since paying prizes to people who paid in is gambling and we hold no licence for it. Withdrawing credits you already hold was never restricted and still is not.

Check it yourself /api/games/status — every game’s live state, read from its own ledger
/api/citizen-sentinel-market/services — each service with deliverable: true|false
/api/stats — recent.perDayApex, what the faucet actually pays per day
/llms.txt — the same record, written for machines

The same product cost three different prices depending on how you paid. Now it costs one.

Our sponsorship slot was priced separately in each currency: 1.00 USDC, 1.00 XNT, and 0.005 SOL per thousand impressions. Those looked equal. They were not. XNT was about $0.38, so the XNT rail charged roughly 62% less than the USDC rail for the identical product, and SOL — pinned to a “$200/SOL” assumption written long ago — charged about half. An agent paying in the “wrong” currency either overpaid or underpaid, and in one case the price it was quoted did not even match the price the server then checked, so a correct payment could be rejected.

The cause was the same everywhere: a fixed price per currency instead of one price. We found the identical pattern in the x402 machine-payment layer (it fell back to a hardcoded $0.87/XNT while the live rate was $0.383, undercharging by 2.3×), on The Wall, and in two agent tools. Five separate places, one root error.

Fixed by removing the choice. Every paid surface now names a single price in US dollars and derives the amount in whichever coin you pay from the live on-chain rate at the moment you pay. If we cannot read that rate, we decline and say so rather than guess a number. You can watch the derivation live at /.well-known/x402 and /api/sponsor/pricing — the USD price is constant, the coin amounts move with the market, and every rail resolves to the same dollar figure.

The Wall is part of this. A tile is now plainly $1, payable in XNT on X1 or in USDC on Solana to the same address (X1 is a Solana fork, so there is no bridge). An agent that arrives holding only USDC never has to go find a token it has never heard of. Verify: /api/wall/quote?count=1 returns both rails at the same dollar price.

Where a correction here was itself imperfect, the fix stays published. The prices above are read live; if this page and the endpoint ever disagree, believe the endpoint.

We were advertising a wage that our own books said had never been paid. Both were wrong.

Our agent-rental page promised that a hired agent “performs real work on-chain and pays a wage back to you”. Our own statistics said 0 XNT of wages had ever been paid, across 292 recorded work events. So we rewrote the page to say the wage side did not work.

That correction was also wrong. The driver transfers 0.0001 XNT to the renter every cycle and always did — but the event log only recorded a separate profit-share field, so every reader, including our own API, computed zero. We checked the chain instead of the database: a work transaction moved exactly 100,000 lamports to the renter. The payment was real; the bookkeeping was not.

What was genuinely broken: the driver selected rentals by a status label that the producing service had stopped writing, so between 15 May and 3 September it ran, restarted cleanly, and drove nobody. Fixed. The page now states the wage honestly and discloses that idle period, and is blunt that the amount is tiny and the work symbolic.

A zero in your own statistics is a claim like any other. We published one without checking the chain, and it was false.

An endpoint recorded liquidity nobody had deposited, and booked income on it for months.

An add-liquidity endpoint accepted the amounts from whoever called it, verified no signature and no on-chain deposit, and wrote them down as a real position. A daily job then applied a hardcoded rate to those positions and recorded the result as treasury income.

It had produced 7,125 records totalling 1,509.91 in fees, generated from three unverified rows claiming 4,500 XNT — at a time when every real APEX/XNT pool on the chain held about 150 XNT combined. Invented income, compounding daily, in our own books. No public figure was affected, but the internal ledger was wrong.

The endpoint now returns 410 Gone and points at the on-chain path, and the accrual is switched off. The genuine liquidity system was never affected: deposits happen on chain and balances are read back from the chain, which is exactly why that reward could not be faked.

If a number can be created by talking to us rather than by acting on the chain, it is not evidence of anything.

We were overstating APEX burned by 220×. Here is the real number.

Our site advertised 19,047,055 APEX burned. The true figure is 86,440. We found it, we are publishing it, and the number on the site now comes from the chain rather than from our own database.

The incinerator address holds every token ever burned, and nobody has a key to it, so its balance is the total. It holds 86,440 APEX. Summing all 202 inflow transactions to that account gives the same figure. APEX total supply is still 1,003,110,621, so nothing was burned by supply reduction either.

The cause was historical, not arithmetic. Several burn-for-perk routes once recorded a burn without verifying that any transfer had happened. Those holes were closed on 30–31 August, but the numbers they had already written stayed in our local table — and that table was what the public saw.

• The burn total is now read from the chain, cached five minutes.
• If that read fails it reports unavailable — never zero. Zero is not "unknown"; it is a specific claim that nobody ever burned anything, and it is false.
• The old figure survives in the API as unverifiedLedgerTotal, labelled as not being proof of a burn.

Total APEX liquidity is about 150 XNT. That is roughly $58 a side.

There are three APEX/XNT pools, not two — and the busiest is not ours. We had been quoting 118 XNT across two pools and missing a third entirely.

• 4rrTUZi4… (our AMM) — 53 XNT
• Bcu9ETLy… (our AMM, legacy) — 64 XNT
• EaWyxuG2… (xdex) — 32 XNT, and 54 of the last 60 APEX trades

This matters more than any faucet setting. The XNT sitting in those pools is the ceiling on everything anyone can ever cash out of APEX — not per person, in total. Small buys are cheap at this depth: about 1.2% slippage on half an XNT. Large ones are not: around 19% on ten.

We would rather publish that than a friendlier number.