grenadeandClaude Opus 5.5
b85e74f1ca
On 2026-10-06 the team bridged 150,000 QTC to NEAR and put almost all of it in a Ref Finance DCL pool, not into solver balances, so the market page saw none of it. The pool contract (dclv2.ref-labs.near) is on shard 8 and our node tracks only intents.near's shard 7, so its swap events are never in anything the scan reads. What the scan does see is the relay transaction: the Verifier's outcome logs an ft_withdraw from the solver to the pool. Those are queued (ref_pending, migration 0012, persisted because the process restarts) and fetched whole from the public endpoint 20 blocks later, once the pool's receipt has run; its dcl.ref swaps are recorded with the solver as trader, since the pool itself records intents.near. Swaps made by calling the pool directly are missed — and the pool's own cumulative counters say by how much, so the page reports coverage instead of a disclaimer: today 99.75% of QTC bought out and 100% of QTC sold in, the gap one 0.000498 QTC buy. Pool state comes from view calls once a minute: price at the current point, holdings, whitelist, counters, and the liquidity ladder from blackbeard_core::dcl — discrete sums over points, with the current point split exactly by liquidity_x; tested against the pool's own totals (QTC to 0.01, and USDC short by exactly the LP fees total_x also holds). Pools are found by paging list_pools. It is its own market, /:chain/market/ref-dcl, never summed with NEAR Intents trades: a user's buy is a solver fill there and, after it, the solver's restock here. The pools' whitelists join the inventory poll, which now finds solver-ref-2.near holding 0.288 QTC. Migration 0013 pulls QTC's scan back to NEAR 218,700,000, before the pool, so the swaps production already passed are found on the re-read. Refs #37 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015pkwBsR54NRmZyU4QVhvfj
21 lines
1.1 KiB
SQL
21 lines
1.1 KiB
SQL
-- Re-read QTC's NEAR history from before its Ref DCL pool existed, so the
|
|
-- pool swaps the scan passed before it knew to look for them are found.
|
|
-- blackbeard/observer#37.
|
|
--
|
|
-- The intents scan queues a relay transaction for pool-swap fetching only
|
|
-- from the release that taught it to (0012). Every block it had already read
|
|
-- stays read: the cursor records where it has been, not what it looked for —
|
|
-- the lesson 0008 recorded for chain events. The first swaps in the USDC/QTC
|
|
-- pool were at NEAR 218,751,935 onward, after the cursor's high mark had
|
|
-- passed them.
|
|
--
|
|
-- Pulling `high` back to 218,700,000 — before the bridge minted any QTC —
|
|
-- makes the scan walk forward over that stretch again from our own node,
|
|
-- about four minutes. Re-reading is safe: trades upsert on their key, the
|
|
-- pool queue and pool swaps ignore duplicates. Solver fill counts are
|
|
-- informational and count that stretch twice; nothing divides by them.
|
|
-- `low` is untouched, so nothing older is re-read.
|
|
update intents_scan
|
|
set high = least(high, 218700000), updated_at = now()
|
|
where asset = 'nep141:qtc.omft.near';
|