With #37 the market pages cover NEAR Intents trades and Ref DCL pools. That is two venues, and less than two of NEAR's ten shards. This issue lists the remaining blind spots, measured where possible, and the cheapest way to close each one, starting with a check that catches the ones we haven't thought of.
No hidden venue today, but nothing would tell us when there is one.
Ref v1.v2.ref-finance.near has 8,914 pools. One of them, #8900, is a SIMPLE_POOL pairing qtc.omft.near with 9035115a44bf437ab7497b69d1cec3701098a081b35a38033f7a98da12ee796e. That token's ft_metadata reads {"name":"quantum test token","symbol":"QTEST","decimals":6}. The pool is empty (amounts: ["0","0"], fee 25), so it's a test, but it shows QTC pools are being created outside DCL. Pool discovery covers only dcl_contracts.
The bridge, on the Quantus side. This is #27 phase 2, never built. The Quantus side is entirely on our own chain, which we already index, and the pattern is now clear:
A deposit is a transfer to a one-time address. The fee payerqznFJTshpdkU6bFpiT7xbi4cLyS7wkLKa1gCWs8m3xwi3bUvB sends that address exactly 0.0010166025 QTC, and the address sweeps the full deposit to custodyqzmzw3Bf2sPHaqSZJnUmNJAYiD5DZosZ4xw1kZduqGGKePTDk. NEAR supply rises by the same amount.
A withdrawal is a transfer out of custody, e.g. 1.096 QTC at block 172,709.
It reconciles to the base unit, from custody's full history:
withdrawals out: 1.096 (plus a 0.996 round trip at 171,220/171,235 that nets to zero)
150,004.8 − 1.096 = 150,003.704, against ft_total_supply150,003.700
custody holds 150,008.702: the same, plus the 5 QTC test the team's holder sent before any deposit (block 169,168), less fees
So there's a figure both chains can verify (QTC locked = QTC minted), plus a per-deposit record of who bridged how much and when. That includes miners bridging to sell, which is the supply the market pages can't see coming.
Intents arriving as cross-contract receipts (#27's gap). Unlike the pool gap in #37, it isn't measured. Everything needed is on shard 7: mt_mint, mt_burn, mt_transfer and token_diff for nep141:qtc.omft.near are all logged by intents.near. The QTC balance of intents.near (ft_balance_of) should change by exactly what the indexed events account for. Any difference is the gap, measured the same way #37 measures the pool.
Direct pool calls on shard 8 (#37). Measured at 99.75% coverage of buys. Closed by tracking shard 8.
Confidential Intents. Trades on NEAR's private shard are invisible by design. They should be named in reads so the page never implies completeness.
What
In order of cost:
Supply reconciliation in /intents/price's listing (or a sibling route), once a minute by view calls:
ft_total_supply
the balance of every account we name: intents.near, each tracked pool contract, each pool's whitelist and LPs, and solvers seen in trades
unaccounted = supply − Σ named, with the named breakdown
A rising unaccounted is the alarm for blind spot 1: a new venue, holder or route, wherever it is.
Ref v1 discovery: scan v2.ref-finance.near (get_number_of_pools / get_pools) for pools holding the asset, report them on the market page (empty or not), and include their balances in the reconciliation. Indexing v1 swaps can wait until one has liquidity.
name the fee payer and custody in config, as evidence-backed roles
classify transfers: deposit sweeps into custody, withdrawals out of it, and the fee payer's funding transfers, which identify each deposit address as it's used
expose /v1/chains/{chain}/bridge with locked (custody minus any pre-bridge seed, i.e. the 5 QTC), minted (ft_total_supply), the difference, and per-deposit/withdrawal rows
Measure the intents gap: the reconciliation in blind spot 4, reported as coverage like #37's.
Option B on the new hardware: track shards 4 and 8. Shard 8 closes direct pool calls. Shard 4 gives bridge mints and burns, transfers, registrations and liquidity changes as events instead of once-a-minute inferences.
reads names Confidential Intents as unreadable.
Not in scope
SafeTrade and any other exchange: off-chain. The CoinGecko ticker is someone else's number (#27).
Over-the-counter deals settled as plain transfers: indistinguishable from any other transfer, on either chain.
## Why
With #37 the market pages cover NEAR Intents trades and Ref DCL pools. That is two venues, and less than two of NEAR's ten shards. This issue lists the remaining blind spots, measured where possible, and the cheapest way to close each one, starting with a check that catches the ones we haven't thought of.
## Shards (layout V3: ids 10, 11, 1, 8, 9, 6, 7, 4, 12, 13)
| Shard | QTC-relevant accounts | Coverage today |
|---|---|---|
| 7 | `intents.near` | complete, from our node |
| 8 | `dclv2.ref-labs.near` | partial: only transactions first detected on shard 7 are fetched whole from the public RPC (#37 option A) |
| **4** | `qtc.omft.near`, `omft.near`, `omni.bridge.near`, `liq.selfevident.near`, `solver-ref-2.near` | view calls only, no events |
| 12 | `v2.ref-finance.near` (Ref v1) | none |
| 10 | `17208628…6133a1` (USDC) | none; only matters for USDC flows |
**Shard 4 is where everything that happens to QTC on NEAR, other than a trade, takes place:**
- bridge mints and burns
- plain `ft_transfer`s between accounts
- `storage_deposit` registrations of new holders
- the market maker's own calls that add or remove pool liquidity
## Blind spots
1. **Unknown holders and venues.** Nothing notices QTC moving to an account or contract we don't already name. Reconciled by hand at 2026-10-06 ~09:45 EEST:
```
ft_total_supply 150,003.700000
dclv2.ref-labs.near 150,000.016145
intents.near 3.314354
liq.selfevident.near 0.100501
unaccounted 0.269000
```
No hidden venue today, but nothing would tell us when there is one.
2. **Ref v1.** `v2.ref-finance.near` has 8,914 pools. One of them, **#8900**, is a `SIMPLE_POOL` pairing `qtc.omft.near` with `9035115a44bf437ab7497b69d1cec3701098a081b35a38033f7a98da12ee796e`. That token's `ft_metadata` reads `{"name":"quantum test token","symbol":"QTEST","decimals":6}`. The pool is empty (`amounts: ["0","0"]`, fee 25), so it's a test, but it shows QTC pools are being created outside DCL. Pool discovery covers only `dcl_contracts`.
3. **The bridge, on the Quantus side.** This is #27 phase 2, never built. **The Quantus side is entirely on our own chain**, which we already index, and the pattern is now clear:
- **A deposit** is a transfer to a one-time address. The **fee payer** `qznFJTshpdkU6bFpiT7xbi4cLyS7wkLKa1gCWs8m3xwi3bUvB` sends that address exactly 0.0010166025 QTC, and the address sweeps the full deposit to **custody** `qzmzw3Bf2sPHaqSZJnUmNJAYiD5DZosZ4xw1kZduqGGKePTDk`. NEAR supply rises by the same amount.
- **A withdrawal** is a transfer *out* of custody, e.g. 1.096 QTC at block 172,709.
- **It reconciles to the base unit**, from custody's full history:
- deposits swept in: 1+1+1+1+0.1+0.1+0.1+150,000+0.5 = **150,004.8**
- withdrawals out: **1.096** (plus a 0.996 round trip at 171,220/171,235 that nets to zero)
- 150,004.8 − 1.096 = **150,003.704**, against `ft_total_supply` **150,003.700**
- custody holds **150,008.702**: the same, plus the 5 QTC test the team's holder sent before any deposit (block 169,168), less fees
- So there's a figure both chains can verify (QTC locked = QTC minted), plus a per-deposit record of who bridged how much and when. That includes miners bridging to sell, which is the supply the market pages can't see coming.
4. **Intents arriving as cross-contract receipts** (#27's gap). Unlike the pool gap in #37, **it isn't measured.** Everything needed is on shard 7: `mt_mint`, `mt_burn`, `mt_transfer` and `token_diff` for `nep141:qtc.omft.near` are all logged by `intents.near`. The QTC balance of `intents.near` (`ft_balance_of`) should change by exactly what the indexed events account for. Any difference is the gap, measured the same way #37 measures the pool.
5. **Direct pool calls** on shard 8 (#37). Measured at 99.75% coverage of buys. Closed by tracking shard 8.
6. **Confidential Intents.** Trades on NEAR's private shard are invisible by design. They should be named in `reads` so the page never implies completeness.
## What
In order of cost:
1. **Supply reconciliation** in `/intents/price`'s `listing` (or a sibling route), once a minute by view calls:
- `ft_total_supply`
- the balance of every account we name: `intents.near`, each tracked pool contract, each pool's whitelist and LPs, and solvers seen in trades
- **`unaccounted`** = supply − Σ named, with the named breakdown
A rising `unaccounted` is the alarm for blind spot 1: a new venue, holder or route, wherever it is.
2. **Ref v1 discovery:** scan `v2.ref-finance.near` (`get_number_of_pools` / `get_pools`) for pools holding the asset, report them on the market page (empty or not), and include their balances in the reconciliation. Indexing v1 swaps can wait until one has liquidity.
3. **Bridge custody on Quantus** (#27 phase 2):
- name the fee payer and custody in config, as evidence-backed roles
- classify transfers: deposit sweeps into custody, withdrawals out of it, and the fee payer's funding transfers, which identify each deposit address as it's used
- expose `/v1/chains/{chain}/bridge` with locked (custody minus any pre-bridge seed, i.e. the 5 QTC), minted (`ft_total_supply`), the difference, and per-deposit/withdrawal rows
- show it next to the backing ceiling (#36)
4. **Measure the intents gap:** the reconciliation in blind spot 4, reported as coverage like #37's.
5. **Option B on the new hardware: track shards 4 and 8.** Shard 8 closes direct pool calls. Shard 4 gives bridge mints and burns, transfers, registrations and liquidity changes as events instead of once-a-minute inferences.
6. **`reads` names Confidential Intents** as unreadable.
## Not in scope
- **SafeTrade and any other exchange:** off-chain. The CoinGecko ticker is someone else's number (#27).
- **Over-the-counter deals** settled as plain transfers: indistinguishable from any other transfer, on either chain.
- **1Click quotes:** offers, not trades (#27).
2026-10-06 ~17:30 EEST: bridge custody (item 3). Two corrections and one finding
Building item 3 against every transfer on custody and the fee payer, as production has them indexed up to block ~176,178.
Correction 1: deposit addresses are not one-time.qzkz3nBAawgVa7oYWMcsx5GorCn4CtcFKvjyViQQFMWW9AS7i deposited three times: 0.2 QTC at 174,731, 1 at 174,760 and 5,990 at 174,829. The fee payer funded it before each sweep, at 174,730, 174,759 and 174,828. A rule expecting one sweep per address would have dropped two of them. 13 deposits come from 11 addresses.
Correction 2: the funding amount is not fixed. It is usually 0.0010166025 QTC, but it was 0.0010169025 before the 150,000 QTC sweep (173,222) and 0.0010168025 before the 5,990 (174,828). Presumably it covers the sweep's own fee, which depends on the transaction. Matching on the amount would miss the two largest deposits on the chain. The classifier matches on who and when: a transfer into custody from an address the fee payer funded at most max_sweep_lag blocks earlier (default 100; every deposit so far was funded exactly one block before).
Figures re-derived now (the issue's were from before the 5,990 deposit):
QTC
custody balance (chain state, read from bob)
155,999.701002692
other inflows (the 5 QTC seed, from qzozZq…, which was never funded and itself funded the fee payer at 169,160)
5
locked = balance − other inflows
155,994.701
deposited / withdrawn
155,996.996 / 2.292
net deposited
155,994.704
minted (qtc.omft.near ft_total_supply)
155,994.698
locked − minted
+0.003
The 0.003 between net deposited and locked is custody's own fees on its three withdrawals.
Finding, outside this item: the account route double-counts ordinary transfers. Every ordinary transfer emits both Balances::Transfer and Wormhole::NativeTransferred, with the same sender, recipient and amount: custody's 17 transfers are 17 of each. Store::account_flows sums both, so /accounts/qzmzw3… reports received = 312,003.992 QTC and receipts = 28, which is exactly double the real 156,001.996 and 14. The distribution table's queries read the same pair of event types, so they very likely double-count visible transfers in the same way; I haven't verified that one. The bridge query takes Balances::Transfer once, plus NativeTransferred only where the sender is the hidden sentinel (an exit, which has no Balances::Transfer).
## 2026-10-06 ~17:30 EEST: bridge custody (item 3). Two corrections and one finding
Building item 3 against every transfer on custody and the fee payer, as production has them indexed up to block ~176,178.
**Correction 1: deposit addresses are not one-time.** `qzkz3nBAawgVa7oYWMcsx5GorCn4CtcFKvjyViQQFMWW9AS7i` deposited three times: 0.2 QTC at 174,731, 1 at 174,760 and 5,990 at 174,829. The fee payer funded it before each sweep, at 174,730, 174,759 and 174,828. A rule expecting one sweep per address would have dropped two of them. 13 deposits come from 11 addresses.
**Correction 2: the funding amount is not fixed.** It is usually 0.0010166025 QTC, but it was 0.0010169025 before the 150,000 QTC sweep (173,222) and 0.0010168025 before the 5,990 (174,828). Presumably it covers the sweep's own fee, which depends on the transaction. Matching on the amount would miss the two largest deposits on the chain. The classifier matches on *who* and *when*: a transfer into custody from an address the fee payer funded at most `max_sweep_lag` blocks earlier (default 100; every deposit so far was funded exactly one block before).
**Figures re-derived now** (the issue's were from before the 5,990 deposit):
| | QTC |
|---|---|
| custody balance (chain state, read from bob) | 155,999.701002692 |
| other inflows (the 5 QTC seed, from `qzozZq…`, which was never funded and itself funded the fee payer at 169,160) | 5 |
| **locked** = balance − other inflows | **155,994.701** |
| deposited / withdrawn | 155,996.996 / 2.292 |
| net deposited | 155,994.704 |
| **minted** (`qtc.omft.near` ft_total_supply) | **155,994.698** |
| locked − minted | **+0.003** |
The 0.003 between net deposited and locked is custody's own fees on its three withdrawals.
**Finding, outside this item: the account route double-counts ordinary transfers.** Every ordinary transfer emits both `Balances::Transfer` and `Wormhole::NativeTransferred`, with the same sender, recipient and amount: custody's 17 transfers are 17 of each. `Store::account_flows` sums both, so `/accounts/qzmzw3…` reports `received` = 312,003.992 QTC and `receipts` = 28, which is exactly double the real 156,001.996 and 14. The distribution table's queries read the same pair of event types, so they very likely double-count visible transfers in the same way; I haven't verified that one. The bridge query takes `Balances::Transfer` once, plus `NativeTransferred` only where the sender is the hidden sentinel (an exit, which has no `Balances::Transfer`).
As written, item 4 can't measure what it set out to. It proposed checking intents.near's QTC balance (ft_balance_of) against what the indexed events account for, to measure the trades arriving as cross-contract receipts that the scan doesn't read. But:
A trade doesn't change that balance. It moves QTC between accounts inside intents.near. So the check is blind to exactly the gap it was meant to measure.
What the balance does move with is deposits and withdrawals, and neither is indexed. A deposit arrives as a receipt from qtc.omft.near (ft_on_transfer), never inside the relay-signed transactions the scan reads.
Replacement: a block-by-block series of QTC moving into and out of NEAR Intents.
Read intents.near's ft_balance_of on qtc.omft.near at every NEAR block, from gargravarr, which tracks the token's shard (4) and so answers at any block it holds.
Record each change with its height and time: up is QTC deposited into NEAR Intents, down is QTC withdrawn.
Exact, and independent of which route a deposit took. Its limits:
it can't say who deposited or withdrew
a deposit and a withdrawal in the same block net to one figure
history starts at the oldest block gargravarr holds
Shown on the NEAR Intents market page as flows in and out, beside the supply reconciliation (item 1).
## 2026-10-06: item 4 replaced
**As written, item 4 can't measure what it set out to.** It proposed checking intents.near's QTC balance (`ft_balance_of`) against what the indexed events account for, to measure the trades arriving as cross-contract receipts that the scan doesn't read. But:
- **A trade doesn't change that balance.** It moves QTC between accounts *inside* intents.near. So the check is blind to exactly the gap it was meant to measure.
- **What the balance does move with is deposits and withdrawals,** and neither is indexed. A deposit arrives as a receipt from `qtc.omft.near` (`ft_on_transfer`), never inside the relay-signed transactions the scan reads.
**Replacement:** a block-by-block series of QTC moving into and out of NEAR Intents.
- Read intents.near's `ft_balance_of` on `qtc.omft.near` at every NEAR block, from gargravarr, which tracks the token's shard (4) and so answers at any block it holds.
- Record each change with its height and time: up is QTC deposited into NEAR Intents, down is QTC withdrawn.
- Exact, and independent of which route a deposit took. Its limits:
- it can't say *who* deposited or withdrew
- a deposit and a withdrawal in the same block net to one figure
- history starts at the oldest block gargravarr holds
Shown on the NEAR Intents market page as flows in and out, beside the supply reconciliation (item 1).
2026-10-06: all six items shipped and verified on production; closing
#
Item
Shipped
Verified
1
Supply reconciliation
unaccounted in the listing: supply less intents.near, the DCL pool contract, every pool whitelist account and Ref's classic exchange. Withheld until every balance is read.
0.269 QTC, matching the hand count in this issue. A first-pass bug read 0.3695 by missing the whitelist; it was fixed the same day.
2
Ref v1 discovery
All classic pools listed every 10 min on quadbrat (shard 12), shown on the Ref market page.
8,916 pools scanned; QTC is only in #8900, the empty QTC/QTEST test pool.
3
Bridge custody
/bridge: custody against minted, with deposits and withdrawals. The alarm fires only when the NEAR supply was read after the last custody movement.
Locked 155,994.701 against minted 155,994.698 at the time; deposit addresses are reused and funding amounts vary (comment above).
4
Replaced: QTC into and out of NEAR Intents
intents.near's balance read at every block on gargravarr (shard 4), with each change recorded.
Matches direct reads (36,044.097 QTC at #218,805,000; 72,671.542 at #218,811,064); in 1,044 rows each balance less its change equals the previous one.
5
Shards 4 and 8
gargravarr tracks both (quadbrat has 10 and 12). Direct pool calls about QTC are scanned on 4 and 8; pool and token views come from gargravarr while it is at the tip.
Queues real direct calls; the first cut matched every call to the DCL contract, and was fixed by migration 0016 plus a re-read.
6
reads names Confidential Intents
In the price response.
—
Found on the way, fixed separately:
#42: every visible transfer was counted twice across three queries.
FastNEAR's per-IP rate limit starved the pool reads after restarts. Fixed by one process-wide pacer, by seeding the pools from recorded swaps, and by moving views onto our own nodes.
The pending-swap fetch idled between batches and served the queue oldest first, leaving 1,574 relay swaps behind an arbitrage bot's failed attempts. It now serves relay swaps first and has no idle wait.
## 2026-10-06: all six items shipped and verified on production; closing
| # | Item | Shipped | Verified |
|---|---|---|---|
| 1 | Supply reconciliation | `unaccounted` in the listing: supply less intents.near, the DCL pool contract, every pool whitelist account and Ref's classic exchange. Withheld until every balance is read. | 0.269 QTC, matching the hand count in this issue. A first-pass bug read 0.3695 by missing the whitelist; it was fixed the same day. |
| 2 | Ref v1 discovery | All classic pools listed every 10 min on quadbrat (shard 12), shown on the Ref market page. | 8,916 pools scanned; QTC is only in #8900, the empty QTC/QTEST test pool. |
| 3 | Bridge custody | `/bridge`: custody against minted, with deposits and withdrawals. The alarm fires only when the NEAR supply was read after the last custody movement. | Locked 155,994.701 against minted 155,994.698 at the time; deposit addresses are reused and funding amounts vary (comment above). |
| 4 | *Replaced:* QTC into and out of NEAR Intents | intents.near's balance read at every block on gargravarr (shard 4), with each change recorded. | Matches direct reads (36,044.097 QTC at #218,805,000; 72,671.542 at #218,811,064); in 1,044 rows each balance less its change equals the previous one. |
| 5 | Shards 4 and 8 | gargravarr tracks both (quadbrat has 10 and 12). Direct pool calls about QTC are scanned on 4 and 8; pool and token views come from gargravarr while it is at the tip. | Queues real direct calls; the first cut matched every call to the DCL contract, and was fixed by migration 0016 plus a re-read. |
| 6 | `reads` names Confidential Intents | In the price response. | — |
**Found on the way, fixed separately:**
- #42: every visible transfer was counted twice across three queries.
- FastNEAR's per-IP rate limit starved the pool reads after restarts. Fixed by one process-wide pacer, by seeding the pools from recorded swaps, and by moving views onto our own nodes.
- The pending-swap fetch idled between batches and served the queue oldest first, leaving 1,574 relay swaps behind an arbitrage bot's failed attempts. It now serves relay swaps first and has no idle wait.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why
With #37 the market pages cover NEAR Intents trades and Ref DCL pools. That is two venues, and less than two of NEAR's ten shards. This issue lists the remaining blind spots, measured where possible, and the cheapest way to close each one, starting with a check that catches the ones we haven't thought of.
Shards (layout V3: ids 10, 11, 1, 8, 9, 6, 7, 4, 12, 13)
intents.neardclv2.ref-labs.nearqtc.omft.near,omft.near,omni.bridge.near,liq.selfevident.near,solver-ref-2.nearv2.ref-finance.near(Ref v1)17208628…6133a1(USDC)Shard 4 is where everything that happens to QTC on NEAR, other than a trade, takes place:
ft_transfers between accountsstorage_depositregistrations of new holdersBlind spots
Unknown holders and venues. Nothing notices QTC moving to an account or contract we don't already name. Reconciled by hand at 2026-10-06 ~09:45 EEST:
No hidden venue today, but nothing would tell us when there is one.
Ref v1.
v2.ref-finance.nearhas 8,914 pools. One of them, #8900, is aSIMPLE_POOLpairingqtc.omft.nearwith9035115a44bf437ab7497b69d1cec3701098a081b35a38033f7a98da12ee796e. That token'sft_metadatareads{"name":"quantum test token","symbol":"QTEST","decimals":6}. The pool is empty (amounts: ["0","0"], fee 25), so it's a test, but it shows QTC pools are being created outside DCL. Pool discovery covers onlydcl_contracts.The bridge, on the Quantus side. This is #27 phase 2, never built. The Quantus side is entirely on our own chain, which we already index, and the pattern is now clear:
qznFJTshpdkU6bFpiT7xbi4cLyS7wkLKa1gCWs8m3xwi3bUvBsends that address exactly 0.0010166025 QTC, and the address sweeps the full deposit to custodyqzmzw3Bf2sPHaqSZJnUmNJAYiD5DZosZ4xw1kZduqGGKePTDk. NEAR supply rises by the same amount.ft_total_supply150,003.700Intents arriving as cross-contract receipts (#27's gap). Unlike the pool gap in #37, it isn't measured. Everything needed is on shard 7:
mt_mint,mt_burn,mt_transferandtoken_difffornep141:qtc.omft.nearare all logged byintents.near. The QTC balance ofintents.near(ft_balance_of) should change by exactly what the indexed events account for. Any difference is the gap, measured the same way #37 measures the pool.Direct pool calls on shard 8 (#37). Measured at 99.75% coverage of buys. Closed by tracking shard 8.
Confidential Intents. Trades on NEAR's private shard are invisible by design. They should be named in
readsso the page never implies completeness.What
In order of cost:
Supply reconciliation in
/intents/price'slisting(or a sibling route), once a minute by view calls:ft_total_supplyintents.near, each tracked pool contract, each pool's whitelist and LPs, and solvers seen in tradesunaccounted= supply − Σ named, with the named breakdownA rising
unaccountedis the alarm for blind spot 1: a new venue, holder or route, wherever it is.Ref v1 discovery: scan
v2.ref-finance.near(get_number_of_pools/get_pools) for pools holding the asset, report them on the market page (empty or not), and include their balances in the reconciliation. Indexing v1 swaps can wait until one has liquidity.Bridge custody on Quantus (#27 phase 2):
/v1/chains/{chain}/bridgewith locked (custody minus any pre-bridge seed, i.e. the 5 QTC), minted (ft_total_supply), the difference, and per-deposit/withdrawal rowsMeasure the intents gap: the reconciliation in blind spot 4, reported as coverage like #37's.
Option B on the new hardware: track shards 4 and 8. Shard 8 closes direct pool calls. Shard 4 gives bridge mints and burns, transfers, registrations and liquidity changes as events instead of once-a-minute inferences.
readsnames Confidential Intents as unreadable.Not in scope
2026-10-06 ~17:30 EEST: bridge custody (item 3). Two corrections and one finding
Building item 3 against every transfer on custody and the fee payer, as production has them indexed up to block ~176,178.
Correction 1: deposit addresses are not one-time.
qzkz3nBAawgVa7oYWMcsx5GorCn4CtcFKvjyViQQFMWW9AS7ideposited three times: 0.2 QTC at 174,731, 1 at 174,760 and 5,990 at 174,829. The fee payer funded it before each sweep, at 174,730, 174,759 and 174,828. A rule expecting one sweep per address would have dropped two of them. 13 deposits come from 11 addresses.Correction 2: the funding amount is not fixed. It is usually 0.0010166025 QTC, but it was 0.0010169025 before the 150,000 QTC sweep (173,222) and 0.0010168025 before the 5,990 (174,828). Presumably it covers the sweep's own fee, which depends on the transaction. Matching on the amount would miss the two largest deposits on the chain. The classifier matches on who and when: a transfer into custody from an address the fee payer funded at most
max_sweep_lagblocks earlier (default 100; every deposit so far was funded exactly one block before).Figures re-derived now (the issue's were from before the 5,990 deposit):
qzozZq…, which was never funded and itself funded the fee payer at 169,160)qtc.omft.nearft_total_supply)The 0.003 between net deposited and locked is custody's own fees on its three withdrawals.
Finding, outside this item: the account route double-counts ordinary transfers. Every ordinary transfer emits both
Balances::TransferandWormhole::NativeTransferred, with the same sender, recipient and amount: custody's 17 transfers are 17 of each.Store::account_flowssums both, so/accounts/qzmzw3…reportsreceived= 312,003.992 QTC andreceipts= 28, which is exactly double the real 156,001.996 and 14. The distribution table's queries read the same pair of event types, so they very likely double-count visible transfers in the same way; I haven't verified that one. The bridge query takesBalances::Transferonce, plusNativeTransferredonly where the sender is the hidden sentinel (an exit, which has noBalances::Transfer).2026-10-06: item 4 replaced
As written, item 4 can't measure what it set out to. It proposed checking intents.near's QTC balance (
ft_balance_of) against what the indexed events account for, to measure the trades arriving as cross-contract receipts that the scan doesn't read. But:qtc.omft.near(ft_on_transfer), never inside the relay-signed transactions the scan reads.Replacement: a block-by-block series of QTC moving into and out of NEAR Intents.
ft_balance_ofonqtc.omft.nearat every NEAR block, from gargravarr, which tracks the token's shard (4) and so answers at any block it holds.Shown on the NEAR Intents market page as flows in and out, beside the supply reconciliation (item 1).
2026-10-06: all six items shipped and verified on production; closing
unaccountedin the listing: supply less intents.near, the DCL pool contract, every pool whitelist account and Ref's classic exchange. Withheld until every balance is read./bridge: custody against minted, with deposits and withdrawals. The alarm fires only when the NEAR supply was read after the last custody movement.readsnames Confidential IntentsFound on the way, fixed separately: