#27 groups an outcome's token_diff legs by (asset, counter token), sums the positive deltas, and infers a side only when exactly one leg in the group carries a referral. #27's last comment flagged that inference as weak. This measures it.
Survey. I read 3,000 NEAR blocks (about 30 min ending 2026-10-03 ~16:20Z) of intents.near's shard from our own node, keeping every executed leg in a successful intents.near outcome: 350 outcomes, 1,026 legs.
Present on 407 legs. 404 are implicit (64-hex) accounts, the per-quote deposit accounts 1Click creates. 3 are *.craft.tg / intents.tg named accounts.
solvers
589 legs on named accounts (solver-priv-liq.near 258, blockzen-1-main.near 128, solver-multichain-asset.near 54, kipseli.near 41, …). None has a referral.
withdraws in the same outcome
364 of 407 referral legs. The 43 that don't are users keeping proceeds inside Intents (1click-unknown, 1click-1cs, 1click-protocol-fees, intents.tg). The only named account that withdraws is solver-ref.near, which has no referral.
referral legs per outcome
0: 3 · 1: 288 · 2: 58 · 3: 1
outcomes with ≥2 takers
59. Their takers trade the same pair in 5, different pairs in 54.
no-referral outcomes
3: two are solver-to-solver (crux-solver.near ↔ blockzen-1-main.near); one is an implicit account and a solver, with no referral.
The taker's own diff is the trade. In every single-taker outcome, the taker's diff on each token equals minus the sum of the other legs' diffs to within 0.2% (576 of 576 token amounts). The gap is the protocol fee. So the taker's leg alone gives an exact price, and it is the price the user actually got: gross out, net in.
What the current rule gets wrong. Since it groups per (asset, counter), other users' swaps of other pairs never interfere. It fails only when two takers trade the same pair in one outcome (5 of 350, about 1.4%). It merges two people's swaps into one trade, drops the side, and prices the merge. In a market as thin as QTC's will be, one merged pair of trades is a material share of the record.
1click-protocol-fees is a real taker. This leg looked like a fee leg mislabelled as the user. It is 1Click's fee account selling the fees it collected: a genuine trade, with the fee account as the taker. Leave it in, labelled.
What
One trade per taker leg of the tracked asset. A taker leg is a leg with a referral whose diff names exactly the asset and one counter.
asset_amount / counter_amount are the absolute values of that leg's own diff. side comes from its sign; taker and referral from the leg.
Makers are the legs of the same pair without a referral.
Fallback, when no leg of the pair has a referral: today's pooled trade (positive sums), with side/taker null and a kind saying it is between counterparties with no identified taker (solver to solver). The price is still a real trade; only the direction is unknown.
kind on the wire, so the page can separate user swaps from solver rebalancing. VWAP stays over all of them; the count by kind is shown.
The Quantus wallet's own swaps. The wallet sends referral: quantus. 1Click's referrals here are all 1click-<partner>, so expect 1click-quantus. Record it as found. Do not hard-code that guess as a rule until a real wallet swap shows it.
Tests: the captured fixture (single taker), plus a captured same-pair multi-taker outcome as a new fixture, plus a solver-to-solver one.
No data migration. Production holds no QTC trades yet. Re-indexing is a cursor collapse if it ever comes to that.
## Why
#27 groups an outcome's `token_diff` legs by (asset, counter token), sums the positive deltas, and infers a side only when exactly one leg in the group carries a `referral`. #27's last comment flagged that inference as weak. This measures it.
**Survey.** I read 3,000 NEAR blocks (about 30 min ending 2026-10-03 ~16:20Z) of `intents.near`'s shard from our own node, keeping every executed leg in a successful `intents.near` outcome: 350 outcomes, 1,026 legs.
| Signal | Finding |
|---|---|
| legs per outcome | 2: 193 · 3: 72 · 4: 26 · 5: 43 · 6+: 16. Not pairs. |
| `referral` | Present on 407 legs. 404 are implicit (64-hex) accounts, the per-quote deposit accounts 1Click creates. 3 are `*.craft.tg` / `intents.tg` named accounts. |
| solvers | 589 legs on named accounts (`solver-priv-liq.near` 258, `blockzen-1-main.near` 128, `solver-multichain-asset.near` 54, `kipseli.near` 41, …). **None** has a referral. |
| withdraws in the same outcome | 364 of 407 referral legs. The 43 that don't are users keeping proceeds inside Intents (`1click-unknown`, `1click-1cs`, `1click-protocol-fees`, `intents.tg`). The only named account that withdraws is `solver-ref.near`, which has no referral. |
| referral legs per outcome | 0: 3 · 1: 288 · **2: 58** · 3: 1 |
| outcomes with ≥2 takers | 59. Their takers trade **the same pair in 5**, different pairs in 54. |
| no-referral outcomes | 3: two are solver-to-solver (`crux-solver.near` ↔ `blockzen-1-main.near`); one is an implicit account and a solver, with no referral. |
**The taker's own diff is the trade.** In every single-taker outcome, the taker's diff on each token equals minus the sum of the other legs' diffs to within 0.2% (576 of 576 token amounts). The gap is the protocol fee. So the taker's leg alone gives an exact price, and it is the price the user actually got: gross out, net in.
**What the current rule gets wrong.** Since it groups per (asset, counter), other users' swaps of other pairs never interfere. It fails only when **two takers trade the same pair in one outcome** (5 of 350, about 1.4%). It merges two people's swaps into one trade, drops the side, and prices the merge. In a market as thin as QTC's will be, one merged pair of trades is a material share of the record.
**`1click-protocol-fees` is a real taker.** This leg looked like a fee leg mislabelled as the user. It is 1Click's fee account selling the fees it collected: a genuine trade, with the fee account as the taker. Leave it in, labelled.
## What
- **One trade per taker leg** of the tracked asset. A taker leg is a leg with a `referral` whose diff names exactly the asset and one counter.
- `asset_amount` / `counter_amount` are the absolute values of that leg's own diff. `side` comes from its sign; `taker` and `referral` from the leg.
- Makers are the legs of the same pair without a referral.
- **Fallback, when no leg of the pair has a referral:** today's pooled trade (positive sums), with `side`/`taker` null and a `kind` saying it is between counterparties with no identified taker (solver to solver). The price is still a real trade; only the direction is unknown.
- `kind` on the wire, so the page can separate user swaps from solver rebalancing. VWAP stays over all of them; the count by kind is shown.
- **The Quantus wallet's own swaps.** The wallet sends `referral: quantus`. 1Click's referrals here are all `1click-<partner>`, so expect `1click-quantus`. Record it as found. Do not hard-code that guess as a rule until a real wallet swap shows it.
- **Tests:** the captured fixture (single taker), plus a captured same-pair multi-taker outcome as a new fixture, plus a solver-to-solver one.
- **No data migration.** Production holds no QTC trades yet. Re-indexing is a cursor collapse if it ever comes to that.
2026-10-03: worse than described — solver hops are counted as trades
I looked for a "two takers, same pair" outcome to use as a test fixture. The first one, tx GTH3v6ff… at NEAR 218,371,635, is not two users. It is one account (1click-e2e_tests) making a round trip, wNEAR → Solana USDC → wNEAR, and the solvers routed both legs through USDT on Ethereum:
With wNEAR as the tracked asset, the current code does three wrong things:
It merges the two opposite taker legs into one wNEAR/sol-USDC trade. The positive sums take wNEAR from one trade and USDC from the other, so the price is meaningless and the side is dropped.
It records solver-priv-liq.near's wNEAR/eth-USDT legs as a second trade, against a token the user never touched. They have no referral, so they fall into the pooled path.
That second trade counts the same wNEAR again as volume.
How common. Of 347 outcomes with a taker, 156 (45%) contain solver legs on a pair no taker traded: 377 such hop legs. The tokens in them are eth-USDT 284, eth-USDC 120, wNEAR 65, ETH 46, SOL 43, ZEC 17, … A QTC swap routed QTC → USDT → USDC would show a phantom QTC/USDT trade, priced from the solvers' internal leg.
Change to the plan. The fallback is decided per outcome, not per pair. If an outcome has any taker leg, every other leg in it is a fill or a hop and is never a trade. The pooled trade with kind: unattributed applies only to outcomes with no referral leg at all (solver to solver, 3 of 350). Both cases go in as fixtures.
## 2026-10-03: worse than described — solver hops are counted as trades
I looked for a "two takers, same pair" outcome to use as a test fixture. The first one, tx `GTH3v6ff…` at NEAR 218,371,635, is not two users. It is **one account (`1click-e2e_tests`) making a round trip**, wNEAR → Solana USDC → wNEAR, and the solvers **routed both legs through USDT on Ethereum**:
```
a5e8dc1b… (1click-e2e_tests) sol-USDC +1,335,270 wNEAR −287,513.95…
a5e8dc1b… (1click-e2e_tests) sol-USDC −322,478 wNEAR +68,591.62…
solver-priv-liq.near eth-USDT −1,335,408 wNEAR +287,513.66…
solver-multichain-asset.near eth-USDT +1,335,406 sol-USDC −1,335,272
solver-priv-liq.near eth-USDT +322,444 wNEAR −68,591.69…
solver-multichain-asset-escrow eth-USDT −322,445 sol-USDC +322,477
```
With wNEAR as the tracked asset, the current code does three wrong things:
1. It merges the two opposite taker legs into one wNEAR/sol-USDC trade. The positive sums take wNEAR from one trade and USDC from the other, so the price is meaningless and the side is dropped.
2. It records `solver-priv-liq.near`'s wNEAR/eth-USDT legs as **a second trade**, against a token the user never touched. They have no referral, so they fall into the pooled path.
3. That second trade counts the same wNEAR again as volume.
**How common.** Of 347 outcomes with a taker, **156 (45%) contain solver legs on a pair no taker traded**: 377 such hop legs. The tokens in them are eth-USDT 284, eth-USDC 120, wNEAR 65, ETH 46, SOL 43, ZEC 17, … A QTC swap routed QTC → USDT → USDC would show a phantom QTC/USDT trade, priced from the solvers' internal leg.
**Change to the plan.** The fallback is decided **per outcome, not per pair**. If an outcome has any taker leg, every other leg in it is a fill or a hop and is never a trade. The pooled trade with `kind: unattributed` applies only to outcomes with no referral leg at all (solver to solver, 3 of 350). Both cases go in as fixtures.
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
#27 groups an outcome's
token_difflegs by (asset, counter token), sums the positive deltas, and infers a side only when exactly one leg in the group carries areferral. #27's last comment flagged that inference as weak. This measures it.Survey. I read 3,000 NEAR blocks (about 30 min ending 2026-10-03 ~16:20Z) of
intents.near's shard from our own node, keeping every executed leg in a successfulintents.nearoutcome: 350 outcomes, 1,026 legs.referral*.craft.tg/intents.tgnamed accounts.solver-priv-liq.near258,blockzen-1-main.near128,solver-multichain-asset.near54,kipseli.near41, …). None has a referral.1click-unknown,1click-1cs,1click-protocol-fees,intents.tg). The only named account that withdraws issolver-ref.near, which has no referral.crux-solver.near↔blockzen-1-main.near); one is an implicit account and a solver, with no referral.The taker's own diff is the trade. In every single-taker outcome, the taker's diff on each token equals minus the sum of the other legs' diffs to within 0.2% (576 of 576 token amounts). The gap is the protocol fee. So the taker's leg alone gives an exact price, and it is the price the user actually got: gross out, net in.
What the current rule gets wrong. Since it groups per (asset, counter), other users' swaps of other pairs never interfere. It fails only when two takers trade the same pair in one outcome (5 of 350, about 1.4%). It merges two people's swaps into one trade, drops the side, and prices the merge. In a market as thin as QTC's will be, one merged pair of trades is a material share of the record.
1click-protocol-feesis a real taker. This leg looked like a fee leg mislabelled as the user. It is 1Click's fee account selling the fees it collected: a genuine trade, with the fee account as the taker. Leave it in, labelled.What
referralwhose diff names exactly the asset and one counter.asset_amount/counter_amountare the absolute values of that leg's own diff.sidecomes from its sign;takerandreferralfrom the leg.side/takernull and akindsaying it is between counterparties with no identified taker (solver to solver). The price is still a real trade; only the direction is unknown.kindon the wire, so the page can separate user swaps from solver rebalancing. VWAP stays over all of them; the count by kind is shown.referral: quantus. 1Click's referrals here are all1click-<partner>, so expect1click-quantus. Record it as found. Do not hard-code that guess as a rule until a real wallet swap shows it.2026-10-03: worse than described — solver hops are counted as trades
I looked for a "two takers, same pair" outcome to use as a test fixture. The first one, tx
GTH3v6ff…at NEAR 218,371,635, is not two users. It is one account (1click-e2e_tests) making a round trip, wNEAR → Solana USDC → wNEAR, and the solvers routed both legs through USDT on Ethereum:With wNEAR as the tracked asset, the current code does three wrong things:
solver-priv-liq.near's wNEAR/eth-USDT legs as a second trade, against a token the user never touched. They have no referral, so they fall into the pooled path.How common. Of 347 outcomes with a taker, 156 (45%) contain solver legs on a pair no taker traded: 377 such hop legs. The tokens in them are eth-USDT 284, eth-USDC 120, wNEAR 65, ETH 46, SOL 43, ZEC 17, … A QTC swap routed QTC → USDT → USDC would show a phantom QTC/USDT trade, priced from the solvers' internal leg.
Change to the plan. The fallback is decided per outcome, not per pair. If an outcome has any taker leg, every other leg in it is a fill or a hop and is never a trade. The pooled trade with
kind: unattributedapplies only to outcomes with no referral leg at all (solver to solver, 3 of 350). Both cases go in as fixtures.