grenadeandClaude Opus 5.5
69050a45c1
Since launch the NEAR Intents page showed no price and no settlements while
QTC traded heavily: the scan counts `token_diff` trades, and 1Click settles
no QTC swap that way. A buy is a solver transferring QTC to a one-off
1Click account, passed on to a shared one; a sell is the mirror; the user's
payment is on their own chain and never on NEAR.
The scan now keeps every executed transfer of the asset (migration 0017,
cursor wound back to before the first QTC swap; pool swaps already recorded
are not re-queued), unclassified. `/v1/chains/{chain}/intents/fills`
classifies at read time against the solvers known then — the solver table
plus every Ref pool whitelist, since solver-ref-2.near never appears in a
token_diff — so a solver found later classifies its past fills without a
re-read. Solver to account is a buy, account to solver a sell; hops between
non-solvers (the pass-on, a flat 0.002 QTC per-swap fee to 5880ad…) are not
fills. Fills are pushed live; the NEAR Intents page lists them without a
price, and shows the Ref pool's restock price in its place.
Checked against the chain: the traced buy at #218,780,964 (2,991.6053 QTC,
solver-ref-2.near to d4524d…) and the sell at #218,758,672 classify as such,
and their pass-on hops do not.
Closes #43
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015pkwBsR54NRmZyU4QVhvfj
34 lines
1.7 KiB
SQL
34 lines
1.7 KiB
SQL
-- Executed transfers of the tracked asset inside intents.near.
|
|
-- blackbeard/observer#43.
|
|
--
|
|
-- 1Click settles QTC swaps as transfers, not `token_diff`: a solver transfers
|
|
-- the asset to a one-off 1Click account for a buy, or receives it for a sell,
|
|
-- and the user's payment happens on their own chain, never on NEAR. Every
|
|
-- executed transfer of the asset is kept, unclassified: which side is a
|
|
-- solver is decided when they are read, against the solvers known then, so a
|
|
-- solver discovered later classifies its past fills without a re-read.
|
|
create table intents_transfer (
|
|
chain text not null references chain (id) on delete cascade,
|
|
asset text not null,
|
|
near_height bigint not null,
|
|
tx_hash text not null,
|
|
receipt_id text not null,
|
|
transfer_index integer not null,
|
|
at timestamptz not null,
|
|
intent_hash text not null,
|
|
from_account text not null,
|
|
to_account text not null,
|
|
amount numeric not null,
|
|
primary key (chain, asset, tx_hash, receipt_id, transfer_index)
|
|
);
|
|
create index intents_transfer_recent on intents_transfer (chain, asset, near_height desc);
|
|
|
|
-- The scan read today's blocks before it knew to look for transfers, and
|
|
-- never revisits a range it has claimed (CLAUDE.md, "Changing what events are
|
|
-- kept"). Pull its high end back to just before the first QTC swap on NEAR
|
|
-- (#218,751,935, 2026-10-06 06:04 UTC) so those blocks are read again. Trades
|
|
-- and solvers upsert; pool swaps already recorded are not queued again.
|
|
update intents_scan
|
|
set high = least(high, 218740000)
|
|
where asset = 'nep141:qtc.omft.near';
|