On 2026-10-06 the team bridged 150,000 QTC to NEAR, and almost all of it went into a Ref Finance DCL pool, not into solver balances inside intents.near:
On Quantus: the team's holder qzozZqZW…jFEAc sent 150,000 QTC to a one-time deposit address at block 173,207. It was swept into bridge custody qzmzw3Bf…PTDk at 173,223.
On NEAR:qtc.omft.near supply went 3 → 150,003.2 QTC. liq.selfevident.near then ft_transfer_called it into dclv2.ref-labs.near, which now holds 149,999.90 QTC. intents.near holds 2.93.
The market page can't see any of this:
/intents/swaps reads token_diff pairs, and pool trades don't emit those.
/intents/inventory asks only solvers already seen filling trades. The Ref solver that has started buying from the pool hasn't filled any yet, so its holding isn't counted.
The chart's placeholder is honest ("none has settled"), but QTC has traded: at $20.13, in the pool.
The pool
get_pool on dclv2.ref-labs.near, pool 17208628f84f5d6ad33f0da3bbbeb27ffcb398eac501a31bd6ad2011e36133a1|qtc.omft.near|2000:
Price:1.0001^point is token_y per token_x in base units, so USD/QTC = 1 / (1.0001^point × 10^(6−12)).
The liquidity is a single-sided sell ladder.get_liquidity_range returns three ranges below the current point (which means they hold token_y) and nothing above:
Points
USD/QTC
L
QTC
USDC to take it all
99,040 – 108,159
$20.09 – $50.00
6,119,719,865
9,999
~$316,900
92,120 – 99,040
$50.00 – $99.88
48,351,642,599
40,000
~$2.83M
84,240 – 92,120
$99.88 – $219.63
153,451,387,116
100,000
~$14.8M
DCL is discretised (iZiSwap), so amounts are sums over points, not the continuous Uniswap v3 formula:
token_y in [l, r) = L · (s^r − s^l)/(s − 1)
token_x to take it all = L · (s^−l − s^−r)/(1 − 1/s)
where s = √1.0001
The continuous formula is off by about 2×10⁴. The discrete sums add up to 149,999 QTC, matching total_y.
How the pool is traded: through intents.near, invisibly
The first two swaps were execute_intents transactions signed by intents.near (the relay), each carrying one intent from solver-ref-2.near:
Tx
USDC in
QTC out
Price
BJEtXVsSB9zx5id3yzBx6Mti4aUH39B3h32xn5emXcS4
2.988295
0.148458
$20.13
BugJG5Cdq1eVCEnDeveatHzAqVxSpVEJfSFavxe54E8E
0.996199
0.049491
$20.13
Each logs, from dclv2.ref-labs.near (receipt status SuccessValue):
intents.near then logs intents_executed for the solver's intent and nep245mt_mint of the QTC to solver-ref-2.near (memo: "deposit"). There is no token_diff: the solver bought for its own account.
Two consequences:
The pool's swapper is always intents.near. The whitelist checks the caller, and the caller is the Verifier. The real trader is the signer in intents_executed for the same transaction, so attribution has to join the two.
A user's buy will probably be two events: a token_diff pair (user ↔ Ref solver, which we already index) and a dcl.ref swap (Ref solver ↔ pool). Count both and volume is double-counted. The pool swap is the solver restocking, not a second trade.
What
Index dcl.refswap events for pools containing the tracked asset, from receipts executed by dclv2.ref-labs.near:
pool id, token in/out, amounts, total_fee and protocol_fee
the receipt status: success only, the same rule as #27
the NEAR height and transaction hash
the intents_executed signer of the same transaction, as the attributed trader
Blind-spot warning: pool swaps made outsideintents.near, by the other whitelisted accounts calling directly, land in whichever shard their transaction is in. Following only intents.near's shard (chunk 7, transactions signed by the relay) misses them. Either also follow dclv2.ref-labs.near's receipts, or state this gap in reads the way #27 does.
Expose them separately from intents trades, e.g. /v1/chains/{chain}/ref/swaps and a source on each price figure (intents | ref-dcl). Don't merge them into one VWAP until the double-count rule above is settled.
A pool route, e.g. /v1/chains/{chain}/ref/pools, read with view calls (which go to view_urls, because our node doesn't track this shard):
pool id, fee, state and whitelist
current point and USD price, when token_x is an allowlisted stablecoin by contract ID
total_x / total_y
the ladder: each liquidity range's price bounds, QTC held and USDC to clear it, using the discrete sums above
how much USDC buyers have put in, which is what any seller can be paid from
Inventory: add every account in a tracked pool's whitelist to the solvers asked by /intents/inventory. solver-ref-2.near holds 0.198 QTC inside intents.near today and isn't counted.
Market page: the chart's first point should be the first pool swap, labelled by source. The placeholder's reason should account for pool swaps, so it doesn't claim nothing traded once one has.
Not in scope
Quoting through the pool.quote is a view and handy for a client, but it's an offer, not a trade, which is the same rule as #27.
Ref's v1 constant-product pools and its other DCL pools, unless the tracked asset appears in them.
Guessing the market maker's identity beyond the named account liq.selfevident.near.
## Why
On 2026-10-06 the team bridged 150,000 QTC to NEAR, and almost all of it went into a Ref Finance DCL pool, not into solver balances inside `intents.near`:
- **On Quantus:** the team's holder `qzozZqZW…jFEAc` sent 150,000 QTC to a one-time deposit address at block 173,207. It was swept into bridge custody `qzmzw3Bf…PTDk` at 173,223.
- **On NEAR:** `qtc.omft.near` supply went 3 → 150,003.2 QTC. `liq.selfevident.near` then `ft_transfer_call`ed it into `dclv2.ref-labs.near`, which now holds **149,999.90 QTC**. `intents.near` holds 2.93.
The market page can't see any of this:
- `/intents/swaps` reads `token_diff` pairs, and pool trades don't emit those.
- `/intents/inventory` asks only solvers already seen filling trades. The Ref solver that has started buying from the pool hasn't filled any yet, so its holding isn't counted.
- The chart's placeholder is honest ("none has settled"), but QTC *has* traded: at $20.13, in the pool.
## The pool
`get_pool` on `dclv2.ref-labs.near`, pool `17208628f84f5d6ad33f0da3bbbeb27ffcb398eac501a31bd6ad2011e36133a1|qtc.omft.near|2000`:
| | |
|---|---|
| token_x | `17208628…6133a1`, native USDC on NEAR, 6 decimals |
| token_y | `qtc.omft.near`, 12 decimals |
| fee | 2000 (0.2%); `point_delta` 40 |
| current_point | 108,159, which is **$20.09/QTC** |
| total_x / total_y | 3.994494 USDC / 149,999.901549 QTC |
| whitelist | `solver-ref-2.near`, `staging-ref-solver.near`, `liq.selfevident.near`, `intents.near`, `solver-ref.near`, `staging-intents.near` |
**Price:** `1.0001^point` is token_y per token_x in base units, so USD/QTC = `1 / (1.0001^point × 10^(6−12))`.
**The liquidity is a single-sided sell ladder.** `get_liquidity_range` returns three ranges below the current point (which means they hold token_y) and nothing above:
| Points | USD/QTC | L | QTC | USDC to take it all |
|---|---|---|---|---|
| 99,040 – 108,159 | $20.09 – $50.00 | 6,119,719,865 | 9,999 | ~$316,900 |
| 92,120 – 99,040 | $50.00 – $99.88 | 48,351,642,599 | 40,000 | ~$2.83M |
| 84,240 – 92,120 | $99.88 – $219.63 | 153,451,387,116 | 100,000 | ~$14.8M |
**DCL is discretised (iZiSwap), so amounts are sums over points, not the continuous Uniswap v3 formula:**
- token_y in `[l, r)` = `L · (s^r − s^l)/(s − 1)`
- token_x to take it all = `L · (s^−l − s^−r)/(1 − 1/s)`
- where `s = √1.0001`
The continuous formula is off by about 2×10⁴. The discrete sums add up to 149,999 QTC, matching `total_y`.
## How the pool is traded: through `intents.near`, invisibly
The first two swaps were `execute_intents` transactions signed by `intents.near` (the relay), each carrying one intent from `solver-ref-2.near`:
| Tx | USDC in | QTC out | Price |
|---|---|---|---|
| `BJEtXVsSB9zx5id3yzBx6Mti4aUH39B3h32xn5emXcS4` | 2.988295 | 0.148458 | $20.13 |
| `BugJG5Cdq1eVCEnDeveatHzAqVxSpVEJfSFavxe54E8E` | 0.996199 | 0.049491 | $20.13 |
Each logs, from `dclv2.ref-labs.near` (receipt status `SuccessValue`):
```
{"standard":"dcl.ref","version":"1.0.0","event":"swap","data":[{"swapper":"intents.near",
"pool_id":"…|qtc.omft.near|2000","token_in":"17208628…","token_out":"qtc.omft.near",
"amount_in":"2988295","amount_out":"148458365713","total_fee":"5977","protocol_fee":"1195",
"referral_fee":"0","referral_id":null}]}
```
`intents.near` then logs `intents_executed` for the solver's intent and `nep245` `mt_mint` of the QTC to `solver-ref-2.near` (`memo: "deposit"`). **There is no `token_diff`:** the solver bought for its own account.
Two consequences:
1. **The pool's `swapper` is always `intents.near`.** The whitelist checks the caller, and the caller is the Verifier. The real trader is the signer in `intents_executed` for the same transaction, so attribution has to join the two.
2. **A user's buy will probably be two events:** a `token_diff` pair (user ↔ Ref solver, which we already index) *and* a `dcl.ref` swap (Ref solver ↔ pool). Count both and volume is double-counted. The pool swap is the solver restocking, not a second trade.
## What
- **Index `dcl.ref` `swap` events** for pools containing the tracked asset, from receipts executed by `dclv2.ref-labs.near`:
- pool id, token in/out, amounts, `total_fee` and `protocol_fee`
- the receipt status: success only, the same rule as #27
- the NEAR height and transaction hash
- the `intents_executed` signer of the same transaction, as the attributed trader
**Blind-spot warning:** pool swaps made *outside* `intents.near`, by the other whitelisted accounts calling directly, land in whichever shard *their* transaction is in. Following only `intents.near`'s shard (chunk 7, transactions signed by the relay) misses them. Either also follow `dclv2.ref-labs.near`'s receipts, or state this gap in `reads` the way #27 does.
- **Expose them separately from intents trades**, e.g. `/v1/chains/{chain}/ref/swaps` and a `source` on each price figure (`intents` | `ref-dcl`). Don't merge them into one VWAP until the double-count rule above is settled.
- **A pool route**, e.g. `/v1/chains/{chain}/ref/pools`, read with view calls (which go to `view_urls`, because our node doesn't track this shard):
- pool id, fee, state and whitelist
- current point and USD price, when token_x is an allowlisted stablecoin by contract ID
- `total_x` / `total_y`
- the ladder: each liquidity range's price bounds, QTC held and USDC to clear it, using the discrete sums above
- how much USDC buyers have put in, which is what any seller can be paid from
- **Inventory:** add every account in a tracked pool's whitelist to the solvers asked by `/intents/inventory`. `solver-ref-2.near` holds 0.198 QTC inside `intents.near` today and isn't counted.
- **Market page:** the chart's first point should be the first pool swap, labelled by source. The placeholder's reason should account for pool swaps, so it doesn't claim nothing traded once one has.
## Not in scope
- **Quoting through the pool.** `quote` is a view and handy for a client, but it's an offer, not a trade, which is the same rule as #27.
- **Ref's v1 constant-product pools and its other DCL pools**, unless the tracked asset appears in them.
- **Guessing the market maker's identity** beyond the named account `liq.selfevident.near`.
2026-10-06: verified, two corrections, and the approach
Verified against the chain:
qtc.omft.near supply is 150,003.2.
The pool is at point 108,159 ($20.09), holding 149,999.90 QTC and 3.994494 USDC.
The discrete sums are right: the ranges recompute to 9,998.734, 40,000.000 and 100,000.000 QTC, needing about $316,900, $2.83M and $14.8M of USDC to clear.
Corrections:
get_liquidity_range returns amount_l, not amount. It also returns two ranges the issue didn't list:
108159..108160, the current point's own slot, which the swaps have partly consumed and which holds both tokens
108160..108200 with L 60,863: about 0.01 USDC above the current point, the only bids
There has been a third swap. The pool's cumulative counters read volume_x_in 3.994494 USDC and volume_y_out 0.198447 QTC, more than the two listed swaps sum to (3.984494 / 0.197949).
Where things run (shard layout V3):intents.near is on shard 7, dclv2.ref-labs.near on shard 8, qtc.omft.near on shard 4. Our node tracks shard 7 only, so the dcl.refswap event is logged where our node cannot see it. In tx BJEtX…, the relay's first intents.near receipt logs ft_withdraw (receiver dclv2.ref-labs.near, amount, the solver as account_id), intents_executed and mt_burn. Those are on shard 7 and visible.
Approach: option A, chosen over tracking shard 8 (which would mean about 5 h to add in place, roughly double the load on frankie, and a migration next week anyway):
Detect on our shard: a relay transaction whose intents.near outcome logs ft_withdraw to a tracked pool contract. The solver in that event is the trader.
Fetch that transaction's full outcome from the public RPC a few blocks later, once the pool's receipt has executed, and parse dcl.refswap events for pools containing the asset. Pending transactions are persisted, because the process restarts several times a day.
Measure the blind spot rather than assert it. The pool keeps cumulative counters, and the sum of indexed swaps against them is "our record accounts for N% of this pool's volume". Swaps made by whitelisted accounts calling the pool directly, outside Intents, are what A misses, and the coverage figure makes them visible in aggregate.
Pool state and ladder come from view calls on the public RPC, once a minute. The ladder arithmetic goes in blackbeard-core, with the numbers above as tests. The current point's slot is reported from total_x/total_y less the other ranges, rather than split from L.
Inventory: the pool's whitelist is added to the accounts asked.
Kept separate from Intents trades, as a second market /:chain/market/ref-dcl, so a user's buy (a token_diff fill) and a solver's restock (a pool swap) can never be summed into one volume.
Tracking shard 8 (option B) is for the new hardware.
## 2026-10-06: verified, two corrections, and the approach
**Verified against the chain:**
- `qtc.omft.near` supply is 150,003.2.
- The pool is at point 108,159 ($20.09), holding 149,999.90 QTC and 3.994494 USDC.
- The discrete sums are right: the ranges recompute to 9,998.734, 40,000.000 and 100,000.000 QTC, needing about $316,900, $2.83M and $14.8M of USDC to clear.
**Corrections:**
- **`get_liquidity_range` returns `amount_l`, not `amount`.** It also returns two ranges the issue didn't list:
- `108159..108160`, the current point's own slot, which the swaps have partly consumed and which holds both tokens
- `108160..108200` with L 60,863: about 0.01 USDC above the current point, the only bids
- **There has been a third swap.** The pool's cumulative counters read `volume_x_in` 3.994494 USDC and `volume_y_out` 0.198447 QTC, more than the two listed swaps sum to (3.984494 / 0.197949).
**Where things run (shard layout V3):** `intents.near` is on shard 7, `dclv2.ref-labs.near` on shard 8, `qtc.omft.near` on shard 4. Our node tracks shard 7 only, so **the `dcl.ref` `swap` event is logged where our node cannot see it.** In tx `BJEtX…`, the relay's first `intents.near` receipt logs `ft_withdraw` (receiver `dclv2.ref-labs.near`, amount, the solver as `account_id`), `intents_executed` and `mt_burn`. Those are on shard 7 and visible.
**Approach: option A**, chosen over tracking shard 8 (which would mean about 5 h to add in place, roughly double the load on frankie, and a migration next week anyway):
- **Detect** on our shard: a relay transaction whose `intents.near` outcome logs `ft_withdraw` to a tracked pool contract. The solver in that event is the trader.
- **Fetch** that transaction's full outcome from the public RPC a few blocks later, once the pool's receipt has executed, and parse `dcl.ref` `swap` events for pools containing the asset. Pending transactions are persisted, because the process restarts several times a day.
- **Measure the blind spot** rather than assert it. The pool keeps cumulative counters, and the sum of indexed swaps against them is "our record accounts for N% of this pool's volume". Swaps made by whitelisted accounts calling the pool directly, outside Intents, are what A misses, and the coverage figure makes them visible in aggregate.
- **Pool state and ladder** come from view calls on the public RPC, once a minute. The ladder arithmetic goes in `blackbeard-core`, with the numbers above as tests. The current point's slot is reported from `total_x`/`total_y` less the other ranges, rather than split from L.
- **Inventory:** the pool's whitelist is added to the accounts asked.
- **Kept separate from Intents trades,** as a second market `/:chain/market/ref-dcl`, so a user's buy (a `token_diff` fill) and a solver's restock (a pool swap) can never be summed into one volume.
- **Tracking shard 8 (option B)** is for the new hardware.
2026-10-06: deployed (b85e74f) and verified on production
Rescan: migration 0013 pulled the QTC scan back to NEAR 218,700,000. Production re-read that stretch from our own node, about 4 min, and found the three swaps it had passed before it knew to look.
Live: a fourth swap, a sell at NEAR 218,757,893, was detected on intents.near's shard, fetched whole from the public endpoint and recorded without intervention.
NEAR height
Side
Solver
Price
218,751,935
buy
solver-ref-2.near
$20.1288
218,752,703
buy
solver-ref-2.near
$20.1288
218,754,997
sell
solver-ref-2.near
$20.0483
218,757,893
sell
solver-ref-2.near
$20.0483
Coverage against the pool's own counters:
QTC sold in: indexed 0.019923980 of 0.019923980, 100%
QTC bought out: indexed 0.197949478 of 0.198447351, 99.75%. The gap is a single 0.000498 QTC buy for 0.01 USDC that no relay transaction we read accounts for: most likely a direct pool call by a whitelisted account, which option A cannot see. The page states it.
Pool: at $20.0886, holding 149,999.921 QTC and 3.595052 USDC. The ladder is as recomputed above.
Inventory: with the whitelist added, it finds solver-ref-2.near holding QTC inside intents.near.
Page:/quantus/market/ref-dcl. /quantus/market/near-intents carries a note pointing to it.
Remaining, so left open: a price chart for the pool's swaps on ref-dcl (the near-intents chart stays intents-only, never mixed), and tracking shard 8 (option B) on the new hardware, which would close the direct-call gap.
## 2026-10-06: deployed (`b85e74f`) and verified on production
- **Rescan:** migration 0013 pulled the QTC scan back to NEAR 218,700,000. Production re-read that stretch from our own node, about 4 min, and found the three swaps it had passed before it knew to look.
- **Live:** a fourth swap, a sell at NEAR 218,757,893, was detected on intents.near's shard, fetched whole from the public endpoint and recorded without intervention.
| NEAR height | Side | Solver | Price |
|---|---|---|---|
| 218,751,935 | buy | solver-ref-2.near | $20.1288 |
| 218,752,703 | buy | solver-ref-2.near | $20.1288 |
| 218,754,997 | sell | solver-ref-2.near | $20.0483 |
| 218,757,893 | sell | solver-ref-2.near | $20.0483 |
- **Coverage against the pool's own counters:**
- QTC sold in: indexed 0.019923980 of 0.019923980, **100%**
- QTC bought out: indexed 0.197949478 of 0.198447351, **99.75%**. The gap is a single 0.000498 QTC buy for 0.01 USDC that no relay transaction we read accounts for: most likely a direct pool call by a whitelisted account, which option A cannot see. The page states it.
- **Pool:** at $20.0886, holding 149,999.921 QTC and 3.595052 USDC. The ladder is as recomputed above.
- **Inventory:** with the whitelist added, it finds `solver-ref-2.near` holding QTC inside intents.near.
- **Page:** `/quantus/market/ref-dcl`. `/quantus/market/near-intents` carries a note pointing to it.
**Remaining, so left open:** a price chart for the pool's swaps on `ref-dcl` (the near-intents chart stays intents-only, never mixed), and tracking shard 8 (option B) on the new hardware, which would close the direct-call gap.
Chart:/quantus/market/ref-dcl has a Pool swap price panel, from /v1/chains/{chain}/ref/series?counter=nep141:….
It's bucketed the same way as the intents series, through one shared function, and drawn with the same plot and figures table.
It's a separate chart, not a second line on the intents one, because summing the two would count one demand twice.
On production: 6 pool swaps in 162 s buckets, between $20.048 and $20.129. The buys and sells sit about a fee's width either side of the pool price.
Correction:RefPool::counter_token was documented as the counter token's contract, but it carries the nep141: prefix. The first cut of the chart added the prefix again and drew an empty frame. Caught by rendering the chart, and the doc comment is fixed.
Option B (tracking shard 8, which closes the direct-call gap) is item 5 of #39 and waits for the new NEAR host.
## 2026-10-06: price chart deployed (`7cd2197`), closing
- **Chart:** `/quantus/market/ref-dcl` has a **Pool swap price** panel, from `/v1/chains/{chain}/ref/series?counter=nep141:…`.
- It's bucketed the same way as the intents series, through one shared function, and drawn with the same plot and figures table.
- It's a separate chart, not a second line on the intents one, because summing the two would count one demand twice.
- **On production:** 6 pool swaps in 162 s buckets, between **$20.048** and **$20.129**. The buys and sells sit about a fee's width either side of the pool price.
- **Correction:** `RefPool::counter_token` was documented as the counter token's contract, but it carries the `nep141:` prefix. The first cut of the chart added the prefix again and drew an empty frame. Caught by rendering the chart, and the doc comment is fixed.
- **Option B** (tracking shard 8, which closes the direct-call gap) is item 5 of #39 and waits for the new NEAR host.
2026-10-06: /intents/inventory published a false zero for two minutes
Between about 12:59 and 13:01 EEST, /intents/inventory reported QTC held: "0" with solvers: 30. Before and after, it was 5,991.605 QTC (solver-ref-2.near) with solvers: 34. On-chain the balance never moved: mt_balance_of(solver-ref-2.near, nep141:qtc.omft.near) on intents.near reads 5,991.605328583476 at every height sampled from 218,774,276 to 218,776,876.
Cause, from crates/blackbeard-api/src/intents.rs:inventory() builds whitelisted from chain.ref_pools, and falls back to an empty list when that is None (unwrap_or_default()). Until the pool loop has read its pools (e.g. right after a restart), the whitelist accounts aren't asked. solver-ref-2.near has filled no token_diff trade, so intents_solvers() doesn't name it either. read_inventory then returns Ok with a total of 0, which replaces the good reading.
That breaks the rule IntentsListing follows: "no verdict rather than a false all-clear." A partial read is presented as a complete one, and a client watching inventory saw the market maker's entire QTC vanish and reappear.
Suggested fix (any one of these works):
Skip the inventory read until ref_pools has been read at least once. Keep the previous Some(inv) meanwhile.
Or keep the last whitelist that was read, in the store, so a restart starts from it.
Or publish the solver list that was asked next to the count, and mark a read as partial when it asked fewer accounts than the last complete one.
qtc_watch now ignores a reading that asked fewer solvers than the previous one, for up to about 20 minutes.
## 2026-10-06: `/intents/inventory` published a false zero for two minutes
Between about 12:59 and 13:01 EEST, `/intents/inventory` reported QTC `held: "0"` with `solvers: 30`. Before and after, it was 5,991.605 QTC (`solver-ref-2.near`) with `solvers: 34`. On-chain the balance never moved: `mt_balance_of(solver-ref-2.near, nep141:qtc.omft.near)` on `intents.near` reads 5,991.605328583476 at every height sampled from 218,774,276 to 218,776,876.
**Cause, from `crates/blackbeard-api/src/intents.rs`:** `inventory()` builds `whitelisted` from `chain.ref_pools`, and falls back to an empty list when that is `None` (`unwrap_or_default()`). Until the pool loop has read its pools (e.g. right after a restart), the whitelist accounts aren't asked. `solver-ref-2.near` has filled no `token_diff` trade, so `intents_solvers()` doesn't name it either. `read_inventory` then returns `Ok` with a total of 0, which replaces the good reading.
That breaks the rule `IntentsListing` follows: *"no verdict rather than a false all-clear."* A partial read is presented as a complete one, and a client watching inventory saw the market maker's entire QTC vanish and reappear.
**Suggested fix (any one of these works):**
- Skip the inventory read until `ref_pools` has been read at least once. Keep the previous `Some(inv)` meanwhile.
- Or keep the last whitelist that was read, in the store, so a restart starts from it.
- Or publish the solver list that was asked next to the count, and mark a read as `partial` when it asked fewer accounts than the last complete one.
`qtc_watch` now ignores a reading that asked fewer solvers than the previous one, for up to about 20 minutes.
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
On 2026-10-06 the team bridged 150,000 QTC to NEAR, and almost all of it went into a Ref Finance DCL pool, not into solver balances inside
intents.near:qzozZqZW…jFEAcsent 150,000 QTC to a one-time deposit address at block 173,207. It was swept into bridge custodyqzmzw3Bf…PTDkat 173,223.qtc.omft.nearsupply went 3 → 150,003.2 QTC.liq.selfevident.nearthenft_transfer_called it intodclv2.ref-labs.near, which now holds 149,999.90 QTC.intents.nearholds 2.93.The market page can't see any of this:
/intents/swapsreadstoken_diffpairs, and pool trades don't emit those./intents/inventoryasks only solvers already seen filling trades. The Ref solver that has started buying from the pool hasn't filled any yet, so its holding isn't counted.The pool
get_poolondclv2.ref-labs.near, pool17208628f84f5d6ad33f0da3bbbeb27ffcb398eac501a31bd6ad2011e36133a1|qtc.omft.near|2000:17208628…6133a1, native USDC on NEAR, 6 decimalsqtc.omft.near, 12 decimalspoint_delta40solver-ref-2.near,staging-ref-solver.near,liq.selfevident.near,intents.near,solver-ref.near,staging-intents.nearPrice:
1.0001^pointis token_y per token_x in base units, so USD/QTC =1 / (1.0001^point × 10^(6−12)).The liquidity is a single-sided sell ladder.
get_liquidity_rangereturns three ranges below the current point (which means they hold token_y) and nothing above:DCL is discretised (iZiSwap), so amounts are sums over points, not the continuous Uniswap v3 formula:
[l, r)=L · (s^r − s^l)/(s − 1)L · (s^−l − s^−r)/(1 − 1/s)s = √1.0001The continuous formula is off by about 2×10⁴. The discrete sums add up to 149,999 QTC, matching
total_y.How the pool is traded: through
intents.near, invisiblyThe first two swaps were
execute_intentstransactions signed byintents.near(the relay), each carrying one intent fromsolver-ref-2.near:BJEtXVsSB9zx5id3yzBx6Mti4aUH39B3h32xn5emXcS4BugJG5Cdq1eVCEnDeveatHzAqVxSpVEJfSFavxe54E8EEach logs, from
dclv2.ref-labs.near(receipt statusSuccessValue):intents.nearthen logsintents_executedfor the solver's intent andnep245mt_mintof the QTC tosolver-ref-2.near(memo: "deposit"). There is notoken_diff: the solver bought for its own account.Two consequences:
swapperis alwaysintents.near. The whitelist checks the caller, and the caller is the Verifier. The real trader is the signer inintents_executedfor the same transaction, so attribution has to join the two.token_diffpair (user ↔ Ref solver, which we already index) and adcl.refswap (Ref solver ↔ pool). Count both and volume is double-counted. The pool swap is the solver restocking, not a second trade.What
Index
dcl.refswapevents for pools containing the tracked asset, from receipts executed bydclv2.ref-labs.near:total_feeandprotocol_feeintents_executedsigner of the same transaction, as the attributed traderBlind-spot warning: pool swaps made outside
intents.near, by the other whitelisted accounts calling directly, land in whichever shard their transaction is in. Following onlyintents.near's shard (chunk 7, transactions signed by the relay) misses them. Either also followdclv2.ref-labs.near's receipts, or state this gap inreadsthe way #27 does.Expose them separately from intents trades, e.g.
/v1/chains/{chain}/ref/swapsand asourceon each price figure (intents|ref-dcl). Don't merge them into one VWAP until the double-count rule above is settled.A pool route, e.g.
/v1/chains/{chain}/ref/pools, read with view calls (which go toview_urls, because our node doesn't track this shard):total_x/total_yInventory: add every account in a tracked pool's whitelist to the solvers asked by
/intents/inventory.solver-ref-2.nearholds 0.198 QTC insideintents.neartoday and isn't counted.Market page: the chart's first point should be the first pool swap, labelled by source. The placeholder's reason should account for pool swaps, so it doesn't claim nothing traded once one has.
Not in scope
quoteis a view and handy for a client, but it's an offer, not a trade, which is the same rule as #27.liq.selfevident.near.2026-10-06: verified, two corrections, and the approach
Verified against the chain:
qtc.omft.nearsupply is 150,003.2.Corrections:
get_liquidity_rangereturnsamount_l, notamount. It also returns two ranges the issue didn't list:108159..108160, the current point's own slot, which the swaps have partly consumed and which holds both tokens108160..108200with L 60,863: about 0.01 USDC above the current point, the only bidsvolume_x_in3.994494 USDC andvolume_y_out0.198447 QTC, more than the two listed swaps sum to (3.984494 / 0.197949).Where things run (shard layout V3):
intents.nearis on shard 7,dclv2.ref-labs.nearon shard 8,qtc.omft.nearon shard 4. Our node tracks shard 7 only, so thedcl.refswapevent is logged where our node cannot see it. In txBJEtX…, the relay's firstintents.nearreceipt logsft_withdraw(receiverdclv2.ref-labs.near, amount, the solver asaccount_id),intents_executedandmt_burn. Those are on shard 7 and visible.Approach: option A, chosen over tracking shard 8 (which would mean about 5 h to add in place, roughly double the load on frankie, and a migration next week anyway):
intents.nearoutcome logsft_withdrawto a tracked pool contract. The solver in that event is the trader.dcl.refswapevents for pools containing the asset. Pending transactions are persisted, because the process restarts several times a day.blackbeard-core, with the numbers above as tests. The current point's slot is reported fromtotal_x/total_yless the other ranges, rather than split from L./:chain/market/ref-dcl, so a user's buy (atoken_difffill) and a solver's restock (a pool swap) can never be summed into one volume.2026-10-06: deployed (
b85e74f) and verified on productionsolver-ref-2.nearholding QTC inside intents.near./quantus/market/ref-dcl./quantus/market/near-intentscarries a note pointing to it.Remaining, so left open: a price chart for the pool's swaps on
ref-dcl(the near-intents chart stays intents-only, never mixed), and tracking shard 8 (option B) on the new hardware, which would close the direct-call gap.2026-10-06: price chart deployed (
7cd2197), closing/quantus/market/ref-dclhas a Pool swap price panel, from/v1/chains/{chain}/ref/series?counter=nep141:….RefPool::counter_tokenwas documented as the counter token's contract, but it carries thenep141:prefix. The first cut of the chart added the prefix again and drew an empty frame. Caught by rendering the chart, and the doc comment is fixed.2026-10-06:
/intents/inventorypublished a false zero for two minutesBetween about 12:59 and 13:01 EEST,
/intents/inventoryreported QTCheld: "0"withsolvers: 30. Before and after, it was 5,991.605 QTC (solver-ref-2.near) withsolvers: 34. On-chain the balance never moved:mt_balance_of(solver-ref-2.near, nep141:qtc.omft.near)onintents.nearreads 5,991.605328583476 at every height sampled from 218,774,276 to 218,776,876.Cause, from
crates/blackbeard-api/src/intents.rs:inventory()buildswhitelistedfromchain.ref_pools, and falls back to an empty list when that isNone(unwrap_or_default()). Until the pool loop has read its pools (e.g. right after a restart), the whitelist accounts aren't asked.solver-ref-2.nearhas filled notoken_difftrade, sointents_solvers()doesn't name it either.read_inventorythen returnsOkwith a total of 0, which replaces the good reading.That breaks the rule
IntentsListingfollows: "no verdict rather than a false all-clear." A partial read is presented as a complete one, and a client watching inventory saw the market maker's entire QTC vanish and reappear.Suggested fix (any one of these works):
ref_poolshas been read at least once. Keep the previousSome(inv)meanwhile.partialwhen it asked fewer accounts than the last complete one.qtc_watchnow ignores a reading that asked fewer solvers than the previous one, for up to about 20 minutes.