On NEAR Intents a price exists only when a solver chooses to quote. Solvers are admitted by a central permission (partner portal, KYC/KYB), and only admitted solvers see the stream of quote requests: in effect a private view of order flow. A solver can stop quoting, in one direction or both, whenever it likes, and nothing on-chain records that it did. The chain records only the trades that happened.
The QTC launch makes the question concrete:
2026-10-06, 18:00 EEST onward: buying QTC was quoted; selling QTC was never quoted to the public (1Click and near.com both: No liquidity available). All 127 QTC sales into the Ref pool during the launch window were the Ref solver's own rebalance swaps (solver-ref-2.near). The pool's price only went up: $20.09 → ~$105.
2026-10-07 morning: quoting stopped in both directions, and the swap button disappeared from the Quantus Android wallet. Yet on-chain at ~07:40 UTC:
the Ref DCL pool is Running at $101.48, holding $3.51M USDC (of which $110k is limit bids) and 97,625 QTC
solver-ref-2.near holds 2,426 QTC and $191k USDC inside intents.near
51e8f94d…7cbe holds 84,797 QTC and $1.86M USDC
Between the evening and the morning, ~5,300 QTC went back into the pool (QTC left 92,290 → 97,625; net buyer USDC ~$3.83M → $3.40M), consistent with solver rebalancing, not public selling.
"No liquidity available" was therefore not a statement about liquidity. Capacity existed on both sides; the quotes didn't. Whether that's a launch policy, risk management, the in-progress MPC/bridge audit, or something less benign can't be told from one day, and nobody records it at all. The observer can: it already sees every shard involved (frankie 7, gargravarr 8 + 4, quadbrat 12 + 10) and can add the one thing the chain lacks, a record of the offers.
What
1. Quote probe (off-chain, labelled as offers per #27)
Once a minute, keyless dry quotes to 1Click (/v0/quote, dry: true, depositType: INTENTS, so nothing is ever committed):
Both directions: QTC → USDC and USDC → QTC.
A few sizes: e.g. 1 / 10 / 100 / 1,000 QTC, and $100 / $1k / $10k / $100k USDC.
A few counter assets: native USDC on NEAR, plus USDC on Ethereum (the most-quoted payout).
Stored per probe: time, direction, size, counter asset, outcome (quoted / no_liquidity / pair_unavailable / other error, verbatim), quoted amountOut and minAmountOut, the correlationId, and response latency.
Alongside each probe, at the same moment, the on-chain fill price for the same size from the pool's quote view on gargravarr. That yields the solver's markup over the pool, and makes "no quote while the pool could fill it" explicit.
Rate: low and identified (a distinct User-Agent). These are a handful of read-only requests a minute, not a load.
2. On-chain context, already within reach
Solver liveness: the time of each whitelisted solver's last pool swap (dcl.refswap; #37) and last token_diff fill (#27). "No quotes, but the solver is still rebalancing" is different from "the solver is offline".
Solver inventory over time (#34, with the whitelist fix from #37's comment).
Pool changes:state, whitelist diffs, liquidity added or removed by the LP, limit orders posted or pulled (#41).
Supply arriving to sell: QTC bridged into NEAR (#39, #44), especially deposits made while sell quotes were off.
3. Derived figures
Availability per direction: the share of probes quoted, per hour or day.
Asymmetry: buy availability minus sell availability. Yesterday's evening would read as close to +100%.
Quoted markup over the pool, per direction and size: how much worse the solver's price is than the on-chain fill.
Pauses: intervals where a direction is unquoted while the pool's on-chain fill for the same size exists. Each records its start, end, what the price did over the pause and the following hours, and on-chain events inside it (inventory moves, rebalances, LP or whitelist changes, bridge inflows).
Pause-to-move statistics, once there's enough history: price change after a pause starts, against the same window at random times. Report sample sizes and confidence intervals, never a verdict from a handful of events.
4. Display
A quote-availability strip per direction above the price chart on /:chain/market/*: green with the quoted price, red with the error; a hatched band where the pool could fill but no quote was given.
A pause log: each pause with its duration, the price before, during and after, and the linked on-chain events.
A daily summary: availability by direction, asymmetry, median markup, number and length of pauses.
Principles
Record, don't accuse. The page states what was offered, what the chain could have filled, and what happened next, with the probe method stated plainly. Readers draw conclusions. Benign explanations (a launch policy, risk limits, audits, maintenance) must remain visible as possibilities, and any public statement from RHEA, NEAR or Quantus explaining a pause should be linkable on the pause.
Offers are not prices. Probe results never feed the price series (#27); they're shown as quote availability.
What we can't see is stated. Other users' quote requests, which solvers were asked, solver admissions and the reasons for refusals are all off-chain and private to admitted solvers. The page says so.
Not in scope
Becoming a solver to see the order flow (that needs admission).
Attributing intent to any named solver or company.
Probes heavy enough to matter to anyone's systems.
## Why
On NEAR Intents a price exists only when a solver chooses to quote. Solvers are admitted by a central permission (partner portal, KYC/KYB), and only admitted solvers see the stream of quote requests: in effect a private view of order flow. A solver can stop quoting, in one direction or both, whenever it likes, and nothing on-chain records that it did. The chain records only the trades that happened.
The QTC launch makes the question concrete:
- **2026-10-06, 18:00 EEST onward:** buying QTC was quoted; **selling QTC was never quoted** to the public (1Click and near.com both: `No liquidity available`). All 127 QTC sales into the Ref pool during the launch window were the Ref solver's own `rebalance` swaps (`solver-ref-2.near`). The pool's price only went up: $20.09 → ~$105.
- **2026-10-07 morning:** quoting stopped **in both directions**, and the swap button disappeared from the Quantus Android wallet. Yet on-chain at ~07:40 UTC:
- the Ref DCL pool is `Running` at $101.48, holding **$3.51M USDC** (of which $110k is limit bids) and **97,625 QTC**
- `solver-ref-2.near` holds 2,426 QTC and $191k USDC inside `intents.near`
- `51e8f94d…7cbe` holds 84,797 QTC and $1.86M USDC
- Between the evening and the morning, ~5,300 QTC went back into the pool (QTC left 92,290 → 97,625; net buyer USDC ~$3.83M → $3.40M), consistent with solver rebalancing, not public selling.
**"No liquidity available" was therefore not a statement about liquidity.** Capacity existed on both sides; the quotes didn't. Whether that's a launch policy, risk management, the in-progress MPC/bridge audit, or something less benign can't be told from one day, and nobody records it at all. The observer can: it already sees every shard involved (frankie 7, gargravarr 8 + 4, quadbrat 12 + 10) and can add the one thing the chain lacks, a record of the offers.
## What
### 1. Quote probe (off-chain, labelled as offers per #27)
Once a minute, keyless dry quotes to 1Click (`/v0/quote`, `dry: true`, `depositType: INTENTS`, so nothing is ever committed):
- **Both directions:** QTC → USDC and USDC → QTC.
- **A few sizes:** e.g. 1 / 10 / 100 / 1,000 QTC, and $100 / $1k / $10k / $100k USDC.
- **A few counter assets:** native USDC on NEAR, plus USDC on Ethereum (the most-quoted payout).
- **Stored per probe:** time, direction, size, counter asset, outcome (`quoted` / `no_liquidity` / `pair_unavailable` / other error, verbatim), quoted `amountOut` and `minAmountOut`, the `correlationId`, and response latency.
- **Alongside each probe,** at the same moment, the **on-chain fill price** for the same size from the pool's `quote` view on gargravarr. That yields **the solver's markup over the pool**, and makes "no quote while the pool could fill it" explicit.
- **Rate:** low and identified (a distinct User-Agent). These are a handful of read-only requests a minute, not a load.
### 2. On-chain context, already within reach
- **Solver liveness:** the time of each whitelisted solver's last pool swap (`dcl.ref` `swap`; #37) and last `token_diff` fill (#27). "No quotes, but the solver is still rebalancing" is different from "the solver is offline".
- **Solver inventory** over time (#34, with the whitelist fix from #37's comment).
- **Pool changes:** `state`, `whitelist` diffs, liquidity added or removed by the LP, limit orders posted or pulled (#41).
- **Supply arriving to sell:** QTC bridged into NEAR (#39, #44), especially deposits made while sell quotes were off.
### 3. Derived figures
- **Availability per direction:** the share of probes quoted, per hour or day.
- **Asymmetry:** buy availability minus sell availability. Yesterday's evening would read as close to +100%.
- **Quoted markup over the pool,** per direction and size: how much worse the solver's price is than the on-chain fill.
- **Pauses:** intervals where a direction is unquoted while the pool's on-chain fill for the same size exists. Each records its start, end, what the price did over the pause and the following hours, and on-chain events inside it (inventory moves, rebalances, LP or whitelist changes, bridge inflows).
- **Pause-to-move statistics, once there's enough history:** price change after a pause starts, against the same window at random times. **Report sample sizes and confidence intervals, never a verdict from a handful of events.**
### 4. Display
- A **quote-availability strip** per direction above the price chart on `/:chain/market/*`: green with the quoted price, red with the error; a hatched band where the pool could fill but no quote was given.
- A **pause log:** each pause with its duration, the price before, during and after, and the linked on-chain events.
- A **daily summary:** availability by direction, asymmetry, median markup, number and length of pauses.
## Principles
- **Record, don't accuse.** The page states what was offered, what the chain could have filled, and what happened next, with the probe method stated plainly. Readers draw conclusions. Benign explanations (a launch policy, risk limits, audits, maintenance) must remain visible as possibilities, and any public statement from RHEA, NEAR or Quantus explaining a pause should be linkable on the pause.
- **Offers are not prices.** Probe results never feed the price series (#27); they're shown as quote availability.
- **What we can't see is stated.** Other users' quote requests, which solvers were asked, solver admissions and the reasons for refusals are all off-chain and private to admitted solvers. The page says so.
## Not in scope
- Becoming a solver to see the order flow (that needs admission).
- Attributing intent to any named solver or company.
- Probes heavy enough to matter to anyone's systems.
Related: #27, #34, #37, #39, #41, #44.
2026-10-07: 1Click access, rate limit and terms, checked before building
Keyless dry quotes work, and the limit is declared
Two dry quotes (dry: true, depositType/recipientTypeINTENTS, no key) sent to https://1click.chaindefuser.com/v0/quote at 10:24 UTC, User-Agent naming this issue:
Request
Result
1,000 QTC → USDC (native, 17208628…)
400 No liquidity available, correlationId 7937dbb1…
100 USDC → QTC
400 No liquidity available, correlationId dcc8be23…
The control shows the request is well formed, so the QTC answer is real: neither direction was quoted at that moment, matching what the wallet and near.com show.
Every response carries the unauthenticated limit: x-ratelimit-limit-unauth: 1200, x-ratelimit-reset-unauth: 60. That is 1,200 requests a minute without a key. The reduced schedule proposed earlier (the smallest size each way every minute, the full grid every 10 to 15 minutes) averages about 3 a minute, a quarter of one percent of the published allowance.
The 1Click terms
1Click is governed by the 1ClickSwap API Terms of Service (Intents Technology Limited, BVI, effective 2026-08-28), not by the near.com platform terms. Using the API without registering is contemplated: an Unregistered Developer is defined and given a fee tier, 20 bps on swap volume, which never applies to dry quotes.
Read against the probe:
Nothing prohibits monitoring, polling or automated access. Section 5.1 forbids abusive or excessive volume, MEV, interfering with solvers, circumventing rate limits, and overburdening the infrastructure. A few read-only quotes a minute, inside the published limit, is none of those.
§4.1(b): "not use the Services to build a competitive product, including for the purpose of benchmarking availability, performance, or functionality". The benchmarking language qualifies building a competitive product. An observatory publishing whether quotes were offered competes with nothing. The clause is still the one a hostile reader would cite, so it is recorded here.
§4.1(e): "not cache, store, or archive API data for more than twenty-four (24) hours, except for static transaction records strictly required for displaying transaction history to End-Users; nor use any API data to train … pricing algorithms; nor sell, rent, or commercialize API data on a standalone basis". This one is explicit, and it bears on the design. As written, storing every probe's quoted amountOut, minAmountOut and correlationId indefinitely, as the issue body proposes, would archive API data well past 24 hours.
§4.1(f)–(j) (KYC, sanctions screening, unmasked originator addresses, end-user disclosures) are obligations on integrators whose end users transact. No transaction is ever made here.
§2.8: limits may be changed or enforced at any time. If access is throttled or cut off, the record must say "probe failed", never "no quote given". The page has to tell those apart.
What §4.1(e) changes
The probe itself is fine. The archive needs a decision:
(a) Store only this observer's own observations, long term:
whether a quote was offered, and the error text when not;
latency;
the markup over the pool's on-chain fill, computed at probe time.
Raw responses (amounts, correlationIds) are kept for 24 hours for debugging and then deleted. The derived markup is our measurement, not their data, though a strict reader could argue it is "API data" in another form.
(b) Store everything, as the issue proposes, and accept the §4.1(e) exposure.
(a) keeps every figure the issue's derived section needs: availability, asymmetry, markup and pauses. It gives up being able to show a specific historical quote's exact numbers.
## 2026-10-07: 1Click access, rate limit and terms, checked before building
### Keyless dry quotes work, and the limit is declared
Two dry quotes (`dry: true`, `depositType`/`recipientType` `INTENTS`, no key) sent to `https://1click.chaindefuser.com/v0/quote` at 10:24 UTC, User-Agent naming this issue:
| Request | Result |
|---|---|
| 1,000 QTC → USDC (native, `17208628…`) | **400 `No liquidity available`**, correlationId `7937dbb1…` |
| 100 USDC → QTC | **400 `No liquidity available`**, correlationId `dcc8be23…` |
| **Control:** 100 USDC → wNEAR, identical request shape | **201**, 19.6836 wNEAR, minAmountOut 19.4867 |
The control shows the request is well formed, so the QTC answer is real: neither direction was quoted at that moment, matching what the wallet and near.com show.
Every response carries the unauthenticated limit: `x-ratelimit-limit-unauth: 1200`, `x-ratelimit-reset-unauth: 60`. That is **1,200 requests a minute** without a key. The reduced schedule proposed earlier (the smallest size each way every minute, the full grid every 10 to 15 minutes) averages about 3 a minute, a quarter of one percent of the published allowance.
### The 1Click terms
1Click is governed by the **1ClickSwap API Terms of Service** (Intents Technology Limited, BVI, effective 2026-08-28), not by the near.com platform terms. Using the API without registering is contemplated: an *Unregistered Developer* is defined and given a fee tier, 20 bps on swap volume, which never applies to dry quotes.
Read against the probe:
- **Nothing prohibits monitoring, polling or automated access.** Section 5.1 forbids abusive or excessive volume, MEV, interfering with solvers, circumventing rate limits, and overburdening the infrastructure. A few read-only quotes a minute, inside the published limit, is none of those.
- **§4.1(b)**: *"not use the Services to build a competitive product, including for the purpose of benchmarking availability, performance, or functionality"*. The benchmarking language qualifies building a **competitive product**. An observatory publishing whether quotes were offered competes with nothing. The clause is still the one a hostile reader would cite, so it is recorded here.
- **§4.1(e)**: *"not cache, store, or archive API data for more than twenty-four (24) hours, except for static transaction records strictly required for displaying transaction history to End-Users; nor use any API data to train … pricing algorithms; nor sell, rent, or commercialize API data on a standalone basis"*. **This one is explicit, and it bears on the design.** As written, storing every probe's quoted `amountOut`, `minAmountOut` and `correlationId` indefinitely, as the issue body proposes, would archive API data well past 24 hours.
- **§4.1(f)–(j)** (KYC, sanctions screening, unmasked originator addresses, end-user disclosures) are obligations on integrators whose end users transact. No transaction is ever made here.
- **§2.8**: limits may be changed or enforced at any time. If access is throttled or cut off, the record must say "probe failed", never "no quote given". The page has to tell those apart.
### What §4.1(e) changes
The probe itself is fine. The archive needs a decision:
- **(a) Store only this observer's own observations, long term:**
- whether a quote was offered, and the error text when not;
- latency;
- the markup over the pool's on-chain fill, computed at probe time.
Raw responses (amounts, correlationIds) are kept for 24 hours for debugging and then deleted. The derived markup is our measurement, not their data, though a strict reader could argue it is "API data" in another form.
- **(b) Store everything, as the issue proposes,** and accept the §4.1(e) exposure.
(a) keeps every figure the issue's derived section needs: availability, asymmetry, markup and pauses. It gives up being able to show a specific historical quote's exact numbers.
2026-10-07: part 1 is live (6b3bf76), recording since 11:01 UTC
Decision on the earlier comment: (a). Only our own observations are kept. A quote becomes markup_bps against the pool when it arrives, and raw responses are pruned after 24 hours (1ClickSwap API Terms §4.1(e)).
What it records
Probes. Keyless dry quotes on QTC pairs only, both directions, against native USDC and Ethereum USDC. The smallest size goes every minute (1 QTC, or 100 USDC); the full grid goes every 15 minutes (1/10/100/1,000 QTC and $100/$1k/$10k/$100k). That averages about 4 requests a minute against the published limit of 1,200.
Alongside each probe, read from our own nodes at the same moment:
the Ref DCL pool's quote for the same input;
every solver's balance of the token the trade would need, across the whole solver set (30 that have filled on Intents, plus the pool whitelists), one solver at a time.
A solver counts as able when it alone held at least what the pool would pay, because solvers do not pool inventory.
What it does not claim. A probe that gets no answer is failed, never no_liquidity, so throttling or blocking cannot read as a solver pause.
First production rounds, 11:01 and 11:02 UTC: every answer "No liquidity available"
Trade
Pool would pay
Largest single holding of what was needed
Solvers able
sell 1 QTC → USDC (NEAR)
101.37 USDC
solver-multichain-asset.near: 1,629,892 USDC
10
sell 1 QTC → USDC (Ethereum)
101.37 USDC (native pool as reference)
solver-priv-liq.near: 1,062,583 USDC.e
16
buy QTC with 100 USDC (NEAR)
0.9825 QTC
solver-ref-2.near: 2,070.28 QTC
1
buy QTC with 100 USDC (Ethereum)
0.9825 QTC
solver-ref-2.near: 2,070.28 QTC
1
Sell side: ten solvers each held enough native USDC, and sixteen enough Ethereum USDC, to pay a seller of 1 QTC on their own, and none quoted.
Buy side:solver-ref-2.near is the only solver holding any QTC, and its holding fell from 2,308 at 10:50 to 2,070 at 11:01 while no quote was being given.
These figures are what the page shows, with the benign explanations stated beside them. Which solvers 1Click asked, and what they answered, stays private to them.
Still to come in this issue
Pause log.
Price-after-pause statistics. Deliberately later: they need weeks of history and a careful review of the wording before anything like them is published.
The on-chain context in part 2: whitelist and LP changes, bridge inflows during pauses.
## 2026-10-07: part 1 is live (6b3bf76), recording since 11:01 UTC
Decision on the earlier comment: **(a)**. Only our own observations are kept. A quote becomes `markup_bps` against the pool when it arrives, and raw responses are pruned after 24 hours (1ClickSwap API Terms §4.1(e)).
### What it records
**Probes.** Keyless dry quotes on **QTC pairs only**, both directions, against native USDC and Ethereum USDC. The smallest size goes every minute (1 QTC, or 100 USDC); the full grid goes every 15 minutes (1/10/100/1,000 QTC and $100/$1k/$10k/$100k). That averages about 4 requests a minute against the published limit of 1,200.
**Alongside each probe**, read from our own nodes at the same moment:
- the Ref DCL pool's `quote` for the same input;
- every solver's balance of the token the trade would need, across the whole solver set (30 that have filled on Intents, plus the pool whitelists), one solver at a time.
A solver counts as **able** when it alone held at least what the pool would pay, because solvers do not pool inventory.
**What it does not claim.** A probe that gets no answer is `failed`, never `no_liquidity`, so throttling or blocking cannot read as a solver pause.
### First production rounds, 11:01 and 11:02 UTC: every answer "No liquidity available"
| Trade | Pool would pay | Largest single holding of what was needed | Solvers able |
|---|---|---|---|
| sell 1 QTC → USDC (NEAR) | 101.37 USDC | `solver-multichain-asset.near`: 1,629,892 USDC | **10** |
| sell 1 QTC → USDC (Ethereum) | 101.37 USDC (native pool as reference) | `solver-priv-liq.near`: 1,062,583 USDC.e | **16** |
| buy QTC with 100 USDC (NEAR) | 0.9825 QTC | `solver-ref-2.near`: 2,070.28 QTC | **1** |
| buy QTC with 100 USDC (Ethereum) | 0.9825 QTC | `solver-ref-2.near`: 2,070.28 QTC | **1** |
**Sell side:** ten solvers each held enough native USDC, and sixteen enough Ethereum USDC, to pay a seller of 1 QTC on their own, and none quoted.
**Buy side:** `solver-ref-2.near` is the only solver holding any QTC, and its holding fell from 2,308 at 10:50 to 2,070 at 11:01 while no quote was being given.
These figures are what the page shows, with the benign explanations stated beside them. Which solvers 1Click asked, and what they answered, stays private to them.
### Still to come in this issue
- **Pause log.**
- **Price-after-pause statistics.** Deliberately later: they need weeks of history and a careful review of the wording before anything like them is published.
- **The on-chain context in part 2:** whitelist and LP changes, bridge inflows during pauses.
2026-10-07: 1Click filled QTC buys while every probe was refused, so the probe's question is narrower than it looked
Shipped today: the pause log, asymmetry and daily summary (ab2b59d), and on-chain context per pause (8892f0a), which needed a new record, ref_pool_settings, for the pool's state and whitelist. The first context it computed contradicts an assumption in this issue.
What the context showed
During the pause that began when the record did (11:01 UTC) and was still running at 15:00:
Solver pool trading: 145 swaps by known solvers, 710 QTC sold into the pool and 1,333 QTC bought out of it. solver-ref-2.near's QTC holding rose from 2,070 to 2,460.
Fills:2 fills, decoded with the site's own transaction page:
8EiqtANy…, 14:18:03 UTC: solver-ref-2.near signed a transfer of 233.31 QTC to a one-off account, which signed it on to 51e8f94d… with an opaque 1Click memo.
CZNrw5kF…, 14:57:02 UTC: the same shape, 114.81 QTC.
That is how a 1Click buy settles on NEAR. At the pool price these were roughly $23.7k and $11.6k.
Every buy probe in that hour was "No liquidity available": $100 every minute, and $1k, $10k and $100k at 14:15, 14:30 and 14:45, against both native and Ethereum USDC.
What that means for the probe
The claim "1Click quoted nobody" is wrong. It quoted somebody: two buys were filled while our probes were refused. What the probe establishes is narrower: a keyless, dry, INTENTS-deposit quote for USDC→QTC was refused while someone else's request was filled.
The difference could be any of:
Origin asset: the buyer paid with something other than USDC.
Deposit type:ORIGIN_CHAIN, paying from the buyer's own chain, where the probe deposits from inside Intents.
Authentication: a partner JWT, where the probe has no key.
Size: something between the grid sizes. Unlikely, since $10k and $100k bracket both fills.
NEAR does not show which, because 1Click takes payment on the buyer's own chain. Nothing here says the refusal was selective on purpose. It says the probe as configured does not see what those buyers saw.
Changes this calls for
Wording. "No quote" must be stated as "no quote for this request", and the panel must name the request shape. The context line already lists 1Click fills, so a reader sees both facts side by side.
Probe variants, to locate the difference rather than speculate: depositType: ORIGIN_CHAIN with USDC on Ethereum as origin, and USDT and wNEAR as origin assets. The same cadence rules apply, a few more requests per quarter hour inside the published limit. If one variant is quoted while the INTENTS probe is refused, that is the finding, and it is a fact about routing, not about intent.
Fill classification. The context counts transfers with a solver on one side as fills. These two are genuine solver deliveries; the hub's other traffic (one-off accounts paying the 0.002 QTC withdrawal fee to 5880ad…) is not counted, which is correct.
## 2026-10-07: 1Click filled QTC buys while every probe was refused, so the probe's question is narrower than it looked
Shipped today: the pause log, asymmetry and daily summary (ab2b59d), and on-chain context per pause (8892f0a), which needed a new record, `ref_pool_settings`, for the pool's state and whitelist. The first context it computed contradicts an assumption in this issue.
### What the context showed
During the pause that began when the record did (11:01 UTC) and was still running at 15:00:
- **Solver pool trading:** 145 swaps by known solvers, 710 QTC sold into the pool and 1,333 QTC bought out of it. `solver-ref-2.near`'s QTC holding rose from 2,070 to 2,460.
- **Bridge inflow:** 23 bridge deposits brought 206 QTC onto NEAR.
- **Fills:** **2 fills**, decoded with the site's own transaction page:
- `8EiqtANy…`, 14:18:03 UTC: `solver-ref-2.near` signed a transfer of **233.31 QTC** to a one-off account, which signed it on to `51e8f94d…` with an opaque 1Click memo.
- `CZNrw5kF…`, 14:57:02 UTC: the same shape, **114.81 QTC**.
That is how a 1Click **buy** settles on NEAR. At the pool price these were roughly $23.7k and $11.6k.
**Every buy probe in that hour was "No liquidity available": $100 every minute, and $1k, $10k and $100k at 14:15, 14:30 and 14:45, against both native and Ethereum USDC.**
### What that means for the probe
**The claim "1Click quoted nobody" is wrong.** It quoted somebody: two buys were filled while our probes were refused. What the probe establishes is narrower: **a keyless, dry, `INTENTS`-deposit quote for USDC→QTC was refused** while someone else's request was filled.
The difference could be any of:
- **Origin asset:** the buyer paid with something other than USDC.
- **Deposit type:** `ORIGIN_CHAIN`, paying from the buyer's own chain, where the probe deposits from inside Intents.
- **Authentication:** a partner JWT, where the probe has no key.
- **Size:** something between the grid sizes. Unlikely, since $10k and $100k bracket both fills.
NEAR does not show which, because 1Click takes payment on the buyer's own chain. Nothing here says the refusal was selective on purpose. It says the probe as configured does not see what those buyers saw.
### Changes this calls for
1. **Wording.** "No quote" must be stated as **"no quote for this request"**, and the panel must name the request shape. The context line already lists 1Click fills, so a reader sees both facts side by side.
2. **Probe variants**, to locate the difference rather than speculate: `depositType: ORIGIN_CHAIN` with USDC on Ethereum as origin, and USDT and wNEAR as origin assets. The same cadence rules apply, a few more requests per quarter hour inside the published limit. If one variant is quoted while the `INTENTS` probe is refused, that is the finding, and it is a fact about routing, not about intent.
3. **Fill classification.** The context counts transfers with a solver on one side as fills. These two are genuine solver deliveries; the hub's other traffic (one-off accounts paying the 0.002 QTC withdrawal fee to `5880ad…`) is not counted, which is correct.
2026-10-07: looking for a buy that 1Click will quote, and what the fill record says about sells
Every form of buy request was refused (15:2x UTC)
Twenty-odd dry quotes, keyless, paced, with nothing committed. They varied one thing at a time from the probe's request:
Delivery: QTC kept inside Intents; QTC delivered on Quantus (nep141:qtc.omft.near, blockchain qtc, to the site's donation address); QTC delivered to a NEAR account (1cs_v1:near:nep141:qtc.omft.near).
Payment: USDC on NEAR, USDT, wNEAR, and deposits from Ethereum (USDC, USDT, ETH), Bitcoin, Solana and the NEAR chain.
Size and swap type: $100, $12k and $24k (the size of the real fills); EXACT_INPUT, EXACT_OUTPUT and FLEX_INPUT.
All refused: "No liquidity available". A USDC→wNEAR control in each request shape was quoted. Two things about the requests themselves:
An Ethereum-deposit refund to 0x0…0 or 0x…dEaD is rejected as refundTo is not valid: burn addresses are refused by name. A refund inside Intents (refundType: INTENTS) is accepted, and that is what the Ethereum-deposit variants used.
So there was no keyless buy request that worked at that moment. Buys were filled at 14:18 and 14:57, so quoting either comes and goes over time or depends on who asks, and a single round of requests cannot tell which.
The fill record contradicts this issue's opening
The body says selling QTC "was never quoted to the public" on launch evening. The fill record says someone's sells were quoted:
47 sell fills, 11,761 QTC in total, all taken by solver-ref-2.near. 45 of them fell between 18:45 and 19:41 UTC on 2026-10-06, at 100–460 QTC each, about one a minute at 6–8 seconds past it. That is regular enough to look automated, but it could be one seller or many.
Each went through its own one-off account, and every one was funded by 1Click's hub 51e8f94d… (11,760.6 QTC in total), the shape a 1Click sell settles in. None was funded by a bridge mint directly, so the chain does not say whose QTC it was.
Pool price: the burst landed at the evening's peak, about $104–105, and the pool fell about 10%, into the low $90s, within the hour.
For the rest of the fills: the 87 launch buys (15:00–17:59 UTC) coincide with the price climbing from about $86 to $102, the overnight buys with a recovery from $91 to $100, and today's two buys with a flat market around $101.
What this does and does not show
It shows both sides were quoted to somebody while the public was told "No liquidity available". The public reports, and our probe since 11:01 UTC, are the refusals; the fill record is the quotes.
It does not show who, or how they asked. Plausible routes: a partner key (JWT), a deposit flow NEAR does not see, or simply a different moment. The sell burst coinciding with the peak is a fact about timing. It is not evidence of intent, and it will not be presented as such.
On the "buys when buy pressure drives the price up" idea: buys coinciding with a rising price is partly mechanical. solver-ref-2.near restocks from the pool to fill a buy, and that restocking is what moves the pool's price. The record cannot separate cause from effect here without many more events.
Next, to locate the difference rather than speculate
Rotate variants through the minute probe. Each minute, the current request plus one variant in turn: delivery to Quantus, an Ethereum deposit, a 1cs_v1 asset id. The first minute any variant is quoted while the baseline is refused names the routing difference. If none is ever quoted while fills keep happening, that points to authenticated requests. The quote record ought to have been kept this way from the start.
Probe sells in the same shapes, which would also test the guess that a sell needs a whitelisted account.
## 2026-10-07: looking for a buy that 1Click will quote, and what the fill record says about sells
### Every form of buy request was refused (15:2x UTC)
Twenty-odd dry quotes, keyless, paced, with nothing committed. They varied one thing at a time from the probe's request:
- **Delivery:** QTC kept inside Intents; QTC delivered on Quantus (`nep141:qtc.omft.near`, blockchain `qtc`, to the site's donation address); QTC delivered to a NEAR account (`1cs_v1:near:nep141:qtc.omft.near`).
- **Payment:** USDC on NEAR, USDT, wNEAR, and deposits from Ethereum (USDC, USDT, ETH), Bitcoin, Solana and the NEAR chain.
- **Size and swap type:** $100, $12k and $24k (the size of the real fills); `EXACT_INPUT`, `EXACT_OUTPUT` and `FLEX_INPUT`.
**All refused: "No liquidity available".** A USDC→wNEAR control in each request shape was quoted. Two things about the requests themselves:
- An Ethereum-deposit refund to `0x0…0` or `0x…dEaD` is rejected as `refundTo is not valid`: burn addresses are refused by name. A refund inside Intents (`refundType: INTENTS`) is accepted, and that is what the Ethereum-deposit variants used.
- **1Click lists QTC twice**: `nep141:qtc.omft.near` (blockchain `qtc`) and `1cs_v1:near:nep141:qtc.omft.near` (blockchain `near`).
So there was no keyless buy request that worked at that moment. Buys were filled at 14:18 and 14:57, so quoting either comes and goes over time or depends on who asks, and a single round of requests cannot tell which.
### The fill record contradicts this issue's opening
The body says selling QTC "was never quoted to the public" on launch evening. The fill record says someone's sells were quoted:
- **47 sell fills, 11,761 QTC in total, all taken by `solver-ref-2.near`.** 45 of them fell between **18:45 and 19:41 UTC on 2026-10-06**, at 100–460 QTC each, about **one a minute at 6–8 seconds past it**. That is regular enough to look automated, but it could be one seller or many.
- Each went through its own one-off account, and **every one was funded by 1Click's hub `51e8f94d…`** (11,760.6 QTC in total), the shape a 1Click sell settles in. None was funded by a bridge mint directly, so the chain does not say whose QTC it was.
- **Pool price:** the burst landed at the evening's **peak, about $104–105**, and the pool fell about 10%, into the low $90s, within the hour.
For the rest of the fills: the 87 launch buys (15:00–17:59 UTC) coincide with the price climbing from about $86 to $102, the overnight buys with a recovery from $91 to $100, and today's two buys with a flat market around $101.
### What this does and does not show
- It shows both sides were quoted to **somebody** while the public was told "No liquidity available". The public reports, and our probe since 11:01 UTC, are the refusals; the fill record is the quotes.
- It does not show who, or how they asked. Plausible routes: a partner key (JWT), a deposit flow NEAR does not see, or simply a different moment. The sell burst coinciding with the peak is a fact about timing. It is **not** evidence of intent, and it will not be presented as such.
- **On the "buys when buy pressure drives the price up" idea:** buys coinciding with a rising price is partly mechanical. `solver-ref-2.near` restocks from the pool to fill a buy, and that restocking is what moves the pool's price. The record cannot separate cause from effect here without many more events.
### Next, to locate the difference rather than speculate
- **Rotate variants through the minute probe.** Each minute, the current request plus one variant in turn: delivery to Quantus, an Ethereum deposit, a `1cs_v1` asset id. The first minute any variant is quoted while the baseline is refused names the routing difference. If none is ever quoted while fills keep happening, that points to authenticated requests. The quote record ought to have been kept this way from the start.
- **Probe sells in the same shapes,** which would also test the guess that a sell needs a whitelisted account.
2026-10-07: where the QTC/USDC pool's whitelist came from
ref_pool_settings began recording at 14:59 UTC today, so it can say only what the whitelist has been since. Its history before that was read off the archive by bisecting the pool's own get_pool view:
Block
When (UTC)
What
#218,316,831
2026-10-03 ~07:00
Pool 17208628…|qtc.omft.near|2000 created on dclv2.ref-labs.near, whitelist empty
refchef.near proposes to ref-finance.sputnik-dao.near: "Set pool whitelist for …|qtc.omft.near|2000"
#218,321,052
2026-10-03 07:45:07
Proposal executes on the approving vote of nicktrust.near (tx 3ZPb9G5h…, with approvals from nicktrust.near, refchef.near and wannamakeit.near). set_pool_whitelist sets all six at once, logging dcl.ref pool_whitelist_updated with the DAO as operator.
#218,636,504
2026-10-06
First QTC minted on NEAR. The whitelist is already in force.
now
Unchanged at every height checked since #218,321,052
The six accounts: intents.near, staging-intents.near, staging-ref-solver.near, solver-ref.near, solver-ref-2.near, liq.selfevident.near.
What this establishes:
Who can swap. The QTC/USDC pool is swappable only by those six. Every public trade reaches it through intents.near, and only Ref's own solvers and one liquidity account may call it directly.
Who decided it. The list was decided by Ref Finance's DAO through a proposal, three days before QTC existed on NEAR. It is not a reaction to anything that happened after launch.
The other pools. Every other QTC pool on dclv2.ref-labs.near (seven of them) has an empty whitelist, so anyone may swap in those, but they hold little liquidity.
Method, for next time: a pool setting's history can always be bisected from the archive by reading get_pool at past heights. About 30 calls found both the creation and the change here, against a block-by-block scan of shard 8.
## 2026-10-07: where the QTC/USDC pool's whitelist came from
`ref_pool_settings` began recording at 14:59 UTC today, so it can say only what the whitelist has been since. Its history before that was read off the archive by bisecting the pool's own `get_pool` view:
| Block | When (UTC) | What |
|---|---|---|
| #218,316,831 | 2026-10-03 ~07:00 | Pool `17208628…\|qtc.omft.near\|2000` created on `dclv2.ref-labs.near`, **whitelist empty** |
| proposal #926 | 2026-10-03 07:18:47 | `refchef.near` proposes to `ref-finance.sputnik-dao.near`: "Set pool whitelist for …\|qtc.omft.near\|2000" |
| #218,321,052 | 2026-10-03 07:45:07 | Proposal executes on the approving vote of `nicktrust.near` (tx `3ZPb9G5h…`, with approvals from `nicktrust.near`, `refchef.near` and `wannamakeit.near`). `set_pool_whitelist` sets **all six at once**, logging `dcl.ref pool_whitelist_updated` with the DAO as operator. |
| #218,636,504 | 2026-10-06 | First QTC minted on NEAR. The whitelist is already in force. |
| now | | **Unchanged** at every height checked since #218,321,052 |
The six accounts: `intents.near`, `staging-intents.near`, `staging-ref-solver.near`, `solver-ref.near`, `solver-ref-2.near`, `liq.selfevident.near`.
What this establishes:
- **Who can swap.** The QTC/USDC pool is swappable only by those six. Every public trade reaches it through `intents.near`, and only Ref's own solvers and one liquidity account may call it directly.
- **Who decided it.** The list was decided by Ref Finance's DAO through a proposal, three days before QTC existed on NEAR. It is not a reaction to anything that happened after launch.
- **The other pools.** Every other QTC pool on `dclv2.ref-labs.near` (seven of them) has an empty whitelist, so anyone may swap in those, but they hold little liquidity.
Method, for next time: a pool setting's history can always be bisected from the archive by reading `get_pool` at past heights. About 30 calls found both the creation and the change here, against a block-by-block scan of shard 8.
2026-10-08: first case — the pool rose from $101.59 to $157.83 overnight while public quotes were refused both ways
Window: NEAR blocks 218,963,708 → 219,043,107 (2026-10-07 17:00 UTC → 2026-10-08 ~05:50 UTC). Read from frankie (shard 7) and gargravarr (shard 8).
Public quotes (keyless 1Click, dry: true, inside Intents)
Sell 10 QTC → USDC:No liquidity available on every probe, every ~5 min, all night (qtc_watch journal).
Buy QTC with $100 USDC (native USDC and USDC on Ethereum): No liquidity available at 05:48 UTC. A continuous buy-side probe started at ~06:30 UTC and has logged No liquidity available since.
Elsewhere: the Quantus Android wallet's swap button was removed on 2026-10-07, and the logged-out near.com demo also said No liquidity available.
What the chain shows in the same window
3,498 QTC-related execute_intents transactions.
Pool swaps through Intents: all by solver-ref-2.near, all memo: "rebalance":
2,096 USDC → QTC (pool buys), ~$8.41M of USDC sent to the pool. The pool's USDC rose $7.64M; the rest is presumably refunds or fees, unverified.
287 QTC → USDC (pool sells), 7,223 QTC.
No token_diff trades, as at launch. Delivery to buyers is by transfer:
solver-ref-2.near → per-order accounts 58,036.20 QTC
per-order accounts → 51e8f94d…7cbe (near.com's pooled account) 60,017.10 QTC
51e8f94d…7cbe → other accounts 8,014.76 QTC
→ of which withdrawn to Quantus (WITHDRAW_TO) 6,793.82 QTC
This is the same flow as the launch window: orders filled by the Ref solver and credited to the account that near.com purchases land in.
The pool:
2026-10-07 17:05 UTC
2026-10-08 05:50 UTC
Price
$101.59
$157.83
USDC
$3.53M
$11.17M
QTC left
97,457
37,263 (all in the $157.83–$219.63 band)
Cumulative
USDC in 14.45M / out 3.39M; QTC in 31,872 / out 144,608
Supply: the team's holder qzozZqZW…jFEAc moved another 30,000 QTC (43,840 → 13,840). Bridge custody is at 180,689 QTC against NEAR supply 180,672.6, still fully backed.
What this records
Buy orders reaching the Ref solver through near.com were filled all night, about 58k QTC worth, while:
the keyless public API was refused in both directions;
selling was refused everywhere (the only QTC sold into the pool was the solver's own rebalance).
With only buyers served and the solver restocking from a sell-only ladder, the pool price could only rise, and did, by 55%.
Not yet established
Whether logged-in near.com accounts receive buy quotes. The flows say someone's buys were filled. A logged-in quote request would confirm the selection is by channel (a partner key) rather than by account.
Whether near.com users could have sold. No QTC → USDC fills to anyone but the solver itself appear in the window.
The reason. Policy, risk limits, the bridge audit, or something else. It should be recorded as unknown until stated.
This is the pattern the issue's probe and pause log are for: per-direction availability, per channel where we can test one, against on-chain fills.
## 2026-10-08: first case — the pool rose from $101.59 to $157.83 overnight while public quotes were refused both ways
**Window:** NEAR blocks 218,963,708 → 219,043,107 (2026-10-07 17:00 UTC → 2026-10-08 ~05:50 UTC). Read from frankie (shard 7) and gargravarr (shard 8).
### Public quotes (keyless 1Click, `dry: true`, inside Intents)
- **Sell 10 QTC → USDC:** `No liquidity available` on every probe, every ~5 min, all night (`qtc_watch` journal).
- **Buy QTC with $100 USDC** (native USDC and USDC on Ethereum): `No liquidity available` at 05:48 UTC. A continuous buy-side probe started at ~06:30 UTC and has logged `No liquidity available` since.
- **Elsewhere:** the Quantus Android wallet's swap button was removed on 2026-10-07, and the logged-out near.com demo also said `No liquidity available`.
### What the chain shows in the same window
- **3,498** QTC-related `execute_intents` transactions.
- **Pool swaps through Intents:** all by `solver-ref-2.near`, all `memo: "rebalance"`:
- **2,096** USDC → QTC (pool buys), ~$8.41M of USDC sent to the pool. The pool's USDC rose $7.64M; the rest is presumably refunds or fees, unverified.
- **287** QTC → USDC (pool sells), 7,223 QTC.
- **No `token_diff` trades,** as at launch. Delivery to buyers is by `transfer`:
```
solver-ref-2.near → per-order accounts 58,036.20 QTC
per-order accounts → 51e8f94d…7cbe (near.com's pooled account) 60,017.10 QTC
51e8f94d…7cbe → other accounts 8,014.76 QTC
→ of which withdrawn to Quantus (WITHDRAW_TO) 6,793.82 QTC
```
This is the same flow as the launch window: orders filled by the Ref solver and credited to the account that near.com purchases land in.
- **The pool:**
| | 2026-10-07 17:05 UTC | 2026-10-08 05:50 UTC |
|---|---|---|
| Price | $101.59 | **$157.83** |
| USDC | $3.53M | **$11.17M** |
| QTC left | 97,457 | **37,263** (all in the $157.83–$219.63 band) |
| Cumulative | | USDC in 14.45M / out 3.39M; QTC in 31,872 / out 144,608 |
- **Supply:** the team's holder `qzozZqZW…jFEAc` moved another 30,000 QTC (43,840 → 13,840). Bridge custody is at 180,689 QTC against NEAR supply 180,672.6, still fully backed.
### What this records
Buy orders reaching the Ref solver through near.com were filled all night, about 58k QTC worth, while:
1. the keyless public API was refused in **both** directions;
2. **selling was refused everywhere** (the only QTC sold into the pool was the solver's own `rebalance`).
With only buyers served and the solver restocking from a sell-only ladder, the pool price could only rise, and did, by 55%.
### Not yet established
- **Whether logged-in near.com accounts receive buy quotes.** The flows say someone's buys were filled. A logged-in quote request would confirm the selection is by channel (a partner key) rather than by account.
- **Whether near.com users could have sold.** No QTC → USDC fills to anyone but the solver itself appear in the window.
- **The reason.** Policy, risk limits, the bridge audit, or something else. It should be recorded as unknown until stated.
This is the pattern the issue's probe and pause log are for: per-direction availability, per channel where we can test one, against on-chain fills.
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 NEAR Intents a price exists only when a solver chooses to quote. Solvers are admitted by a central permission (partner portal, KYC/KYB), and only admitted solvers see the stream of quote requests: in effect a private view of order flow. A solver can stop quoting, in one direction or both, whenever it likes, and nothing on-chain records that it did. The chain records only the trades that happened.
The QTC launch makes the question concrete:
No liquidity available). All 127 QTC sales into the Ref pool during the launch window were the Ref solver's ownrebalanceswaps (solver-ref-2.near). The pool's price only went up: $20.09 → ~$105.Runningat $101.48, holding $3.51M USDC (of which $110k is limit bids) and 97,625 QTCsolver-ref-2.nearholds 2,426 QTC and $191k USDC insideintents.near51e8f94d…7cbeholds 84,797 QTC and $1.86M USDC"No liquidity available" was therefore not a statement about liquidity. Capacity existed on both sides; the quotes didn't. Whether that's a launch policy, risk management, the in-progress MPC/bridge audit, or something less benign can't be told from one day, and nobody records it at all. The observer can: it already sees every shard involved (frankie 7, gargravarr 8 + 4, quadbrat 12 + 10) and can add the one thing the chain lacks, a record of the offers.
What
1. Quote probe (off-chain, labelled as offers per #27)
Once a minute, keyless dry quotes to 1Click (
/v0/quote,dry: true,depositType: INTENTS, so nothing is ever committed):quoted/no_liquidity/pair_unavailable/ other error, verbatim), quotedamountOutandminAmountOut, thecorrelationId, and response latency.quoteview on gargravarr. That yields the solver's markup over the pool, and makes "no quote while the pool could fill it" explicit.2. On-chain context, already within reach
dcl.refswap; #37) and lasttoken_difffill (#27). "No quotes, but the solver is still rebalancing" is different from "the solver is offline".state,whitelistdiffs, liquidity added or removed by the LP, limit orders posted or pulled (#41).3. Derived figures
4. Display
/:chain/market/*: green with the quoted price, red with the error; a hatched band where the pool could fill but no quote was given.Principles
Not in scope
Related: #27, #34, #37, #39, #41, #44.
2026-10-07: 1Click access, rate limit and terms, checked before building
Keyless dry quotes work, and the limit is declared
Two dry quotes (
dry: true,depositType/recipientTypeINTENTS, no key) sent tohttps://1click.chaindefuser.com/v0/quoteat 10:24 UTC, User-Agent naming this issue:17208628…)No liquidity available, correlationId7937dbb1…No liquidity available, correlationIddcc8be23…The control shows the request is well formed, so the QTC answer is real: neither direction was quoted at that moment, matching what the wallet and near.com show.
Every response carries the unauthenticated limit:
x-ratelimit-limit-unauth: 1200,x-ratelimit-reset-unauth: 60. That is 1,200 requests a minute without a key. The reduced schedule proposed earlier (the smallest size each way every minute, the full grid every 10 to 15 minutes) averages about 3 a minute, a quarter of one percent of the published allowance.The 1Click terms
1Click is governed by the 1ClickSwap API Terms of Service (Intents Technology Limited, BVI, effective 2026-08-28), not by the near.com platform terms. Using the API without registering is contemplated: an Unregistered Developer is defined and given a fee tier, 20 bps on swap volume, which never applies to dry quotes.
Read against the probe:
amountOut,minAmountOutandcorrelationIdindefinitely, as the issue body proposes, would archive API data well past 24 hours.What §4.1(e) changes
The probe itself is fine. The archive needs a decision:
(a) Store only this observer's own observations, long term:
Raw responses (amounts, correlationIds) are kept for 24 hours for debugging and then deleted. The derived markup is our measurement, not their data, though a strict reader could argue it is "API data" in another form.
(b) Store everything, as the issue proposes, and accept the §4.1(e) exposure.
(a) keeps every figure the issue's derived section needs: availability, asymmetry, markup and pauses. It gives up being able to show a specific historical quote's exact numbers.
2026-10-07: part 1 is live (
6b3bf76), recording since 11:01 UTCDecision on the earlier comment: (a). Only our own observations are kept. A quote becomes
markup_bpsagainst the pool when it arrives, and raw responses are pruned after 24 hours (1ClickSwap API Terms §4.1(e)).What it records
Probes. Keyless dry quotes on QTC pairs only, both directions, against native USDC and Ethereum USDC. The smallest size goes every minute (1 QTC, or 100 USDC); the full grid goes every 15 minutes (1/10/100/1,000 QTC and $100/$1k/$10k/$100k). That averages about 4 requests a minute against the published limit of 1,200.
Alongside each probe, read from our own nodes at the same moment:
quotefor the same input;A solver counts as able when it alone held at least what the pool would pay, because solvers do not pool inventory.
What it does not claim. A probe that gets no answer is
failed, neverno_liquidity, so throttling or blocking cannot read as a solver pause.First production rounds, 11:01 and 11:02 UTC: every answer "No liquidity available"
solver-multichain-asset.near: 1,629,892 USDCsolver-priv-liq.near: 1,062,583 USDC.esolver-ref-2.near: 2,070.28 QTCsolver-ref-2.near: 2,070.28 QTCSell side: ten solvers each held enough native USDC, and sixteen enough Ethereum USDC, to pay a seller of 1 QTC on their own, and none quoted.
Buy side:
solver-ref-2.nearis the only solver holding any QTC, and its holding fell from 2,308 at 10:50 to 2,070 at 11:01 while no quote was being given.These figures are what the page shows, with the benign explanations stated beside them. Which solvers 1Click asked, and what they answered, stays private to them.
Still to come in this issue
2026-10-07: 1Click filled QTC buys while every probe was refused, so the probe's question is narrower than it looked
Shipped today: the pause log, asymmetry and daily summary (
ab2b59d), and on-chain context per pause (8892f0a), which needed a new record,ref_pool_settings, for the pool's state and whitelist. The first context it computed contradicts an assumption in this issue.What the context showed
During the pause that began when the record did (11:01 UTC) and was still running at 15:00:
solver-ref-2.near's QTC holding rose from 2,070 to 2,460.8EiqtANy…, 14:18:03 UTC:solver-ref-2.nearsigned a transfer of 233.31 QTC to a one-off account, which signed it on to51e8f94d…with an opaque 1Click memo.CZNrw5kF…, 14:57:02 UTC: the same shape, 114.81 QTC.That is how a 1Click buy settles on NEAR. At the pool price these were roughly $23.7k and $11.6k.
Every buy probe in that hour was "No liquidity available": $100 every minute, and $1k, $10k and $100k at 14:15, 14:30 and 14:45, against both native and Ethereum USDC.
What that means for the probe
The claim "1Click quoted nobody" is wrong. It quoted somebody: two buys were filled while our probes were refused. What the probe establishes is narrower: a keyless, dry,
INTENTS-deposit quote for USDC→QTC was refused while someone else's request was filled.The difference could be any of:
ORIGIN_CHAIN, paying from the buyer's own chain, where the probe deposits from inside Intents.NEAR does not show which, because 1Click takes payment on the buyer's own chain. Nothing here says the refusal was selective on purpose. It says the probe as configured does not see what those buyers saw.
Changes this calls for
depositType: ORIGIN_CHAINwith USDC on Ethereum as origin, and USDT and wNEAR as origin assets. The same cadence rules apply, a few more requests per quarter hour inside the published limit. If one variant is quoted while theINTENTSprobe is refused, that is the finding, and it is a fact about routing, not about intent.5880ad…) is not counted, which is correct.2026-10-07: looking for a buy that 1Click will quote, and what the fill record says about sells
Every form of buy request was refused (15:2x UTC)
Twenty-odd dry quotes, keyless, paced, with nothing committed. They varied one thing at a time from the probe's request:
nep141:qtc.omft.near, blockchainqtc, to the site's donation address); QTC delivered to a NEAR account (1cs_v1:near:nep141:qtc.omft.near).EXACT_INPUT,EXACT_OUTPUTandFLEX_INPUT.All refused: "No liquidity available". A USDC→wNEAR control in each request shape was quoted. Two things about the requests themselves:
0x0…0or0x…dEaDis rejected asrefundTo is not valid: burn addresses are refused by name. A refund inside Intents (refundType: INTENTS) is accepted, and that is what the Ethereum-deposit variants used.nep141:qtc.omft.near(blockchainqtc) and1cs_v1:near:nep141:qtc.omft.near(blockchainnear).So there was no keyless buy request that worked at that moment. Buys were filled at 14:18 and 14:57, so quoting either comes and goes over time or depends on who asks, and a single round of requests cannot tell which.
The fill record contradicts this issue's opening
The body says selling QTC "was never quoted to the public" on launch evening. The fill record says someone's sells were quoted:
solver-ref-2.near. 45 of them fell between 18:45 and 19:41 UTC on 2026-10-06, at 100–460 QTC each, about one a minute at 6–8 seconds past it. That is regular enough to look automated, but it could be one seller or many.51e8f94d…(11,760.6 QTC in total), the shape a 1Click sell settles in. None was funded by a bridge mint directly, so the chain does not say whose QTC it was.For the rest of the fills: the 87 launch buys (15:00–17:59 UTC) coincide with the price climbing from about $86 to $102, the overnight buys with a recovery from $91 to $100, and today's two buys with a flat market around $101.
What this does and does not show
solver-ref-2.nearrestocks from the pool to fill a buy, and that restocking is what moves the pool's price. The record cannot separate cause from effect here without many more events.Next, to locate the difference rather than speculate
1cs_v1asset id. The first minute any variant is quoted while the baseline is refused names the routing difference. If none is ever quoted while fills keep happening, that points to authenticated requests. The quote record ought to have been kept this way from the start.2026-10-07: where the QTC/USDC pool's whitelist came from
ref_pool_settingsbegan recording at 14:59 UTC today, so it can say only what the whitelist has been since. Its history before that was read off the archive by bisecting the pool's ownget_poolview:17208628…|qtc.omft.near|2000created ondclv2.ref-labs.near, whitelist emptyrefchef.nearproposes toref-finance.sputnik-dao.near: "Set pool whitelist for …|qtc.omft.near|2000"nicktrust.near(tx3ZPb9G5h…, with approvals fromnicktrust.near,refchef.nearandwannamakeit.near).set_pool_whitelistsets all six at once, loggingdcl.ref pool_whitelist_updatedwith the DAO as operator.The six accounts:
intents.near,staging-intents.near,staging-ref-solver.near,solver-ref.near,solver-ref-2.near,liq.selfevident.near.What this establishes:
intents.near, and only Ref's own solvers and one liquidity account may call it directly.dclv2.ref-labs.near(seven of them) has an empty whitelist, so anyone may swap in those, but they hold little liquidity.Method, for next time: a pool setting's history can always be bisected from the archive by reading
get_poolat past heights. About 30 calls found both the creation and the change here, against a block-by-block scan of shard 8.2026-10-08: first case — the pool rose from $101.59 to $157.83 overnight while public quotes were refused both ways
Window: NEAR blocks 218,963,708 → 219,043,107 (2026-10-07 17:00 UTC → 2026-10-08 ~05:50 UTC). Read from frankie (shard 7) and gargravarr (shard 8).
Public quotes (keyless 1Click,
dry: true, inside Intents)No liquidity availableon every probe, every ~5 min, all night (qtc_watchjournal).No liquidity availableat 05:48 UTC. A continuous buy-side probe started at ~06:30 UTC and has loggedNo liquidity availablesince.No liquidity available.What the chain shows in the same window
3,498 QTC-related
execute_intentstransactions.Pool swaps through Intents: all by
solver-ref-2.near, allmemo: "rebalance":No
token_difftrades, as at launch. Delivery to buyers is bytransfer:This is the same flow as the launch window: orders filled by the Ref solver and credited to the account that near.com purchases land in.
The pool:
Supply: the team's holder
qzozZqZW…jFEAcmoved another 30,000 QTC (43,840 → 13,840). Bridge custody is at 180,689 QTC against NEAR supply 180,672.6, still fully backed.What this records
Buy orders reaching the Ref solver through near.com were filled all night, about 58k QTC worth, while:
rebalance).With only buyers served and the solver restocking from a sell-only ladder, the pool price could only rise, and did, by 55%.
Not yet established
This is the pattern the issue's probe and pause log are for: per-direction availability, per channel where we can test one, against on-chain fills.