A QTC bridge transaction on nearblocks shows only its envelope. For example, the mint piPTXyoqDZwSJsKk3DWGVvDSy8T7hWm6KW4LFxpTsLk reads as bridge-mng.near → omft.near: no Quantus sender, no Intents account, no amount in QTC terms. Everything needed to explain it is on-chain, but in function-call arguments and receipt logs that explorers don't surface. We now run nodes for every shard that matters, so the observer can surface them:
Quantus tx 0xc4444afc1d43ddccad1421cb1989a9159516411db085710317ead1adeda3bf8d sent 0.05 QTC to the bridge deposit address qzmobBdfcrzCFdMiEDK8DFy4XtgV2TYJQSy7iB1B3TwfDgqPf at block 180,029. The bridge fee payer qznFJTsh…UvB funded it, and it was swept to custody qzmzw3Bf…PTDk. The NEAR mint, piPTXyoq…:
The Quantus transaction hash is in the NEAR memo, so the link is exact, not inferred.
The deposit address → Intents account mapping is derivable from the chain alone. The Quantus tx gives the deposit address; the mint's msg.receiver_id gives the account. No call to the bridge operator's API is needed.
Deposit addresses are permanent per account. This one took deposits at 177,134 (mint 8m3diDYT…) and 180,029 (mint piPTXyoq…). So the mapping is many deposits to one account, and stable.
A withdrawal, NEAR Intents → Quantus
intents.near logs dip4ft_withdraw with token: "qtc.omft.near", receiver_id: "qtc.omft.near", memo: "WITHDRAW_TO:qz…" and the withdrawing Intents account_id. The QTC is then burned on NEAR, and custody pays the destination on Quantus, net of the 0.002 QTC bridge fee. (One example: custody → 1.096 QTC at block 172,709. The 2026-10-06 launch window had 122 such withdrawals to Quantus addresses.)
No NEAR hash appears on the Quantus side that we've seen. Linking a withdrawal to its payout means matching destination, amount (less the fee) and time. Report the match as inferred, with its rule.
A failed swap with its automatic refund
E4ysnVhtKSxp1uEKrwYTXSCrP2Nenkgod1wVTQCyC4Pb shows the whole round trip:
intents.nearft_withdraw + mt_burn
qtc.omft.nearft_transfer to dclv2.ref-labs.near
dclv2Failure: E407: account not in pool whitelist
qtc.omft.nearft_transfer back, memo: "refund"
intents.nearmt_mint, memo: "refund"
A good test fixture: a tx page must show failed receipts and their refunds, not only the happy path.
What
1. NEAR transaction page: GET /v1/near/tx/{hash} and /near/tx/:hash
The receipt tree: executor, predecessor, status (success / failure with its message), gas burnt, and the block and shard of each receipt.
Decoded function-call arguments (base64 JSON → JSON), with known memo formats parsed (BRIDGED_FROM:{…}, WITHDRAW_TO:<address>).
Amounts shown in token units using ft_metadata decimals, with the raw value alongside.
Cross-links: a Quantus tx hash in BRIDGED_FROM links to our Quantus tx/account pages, and Intents accounts link to (2).
Source: receipts live on several shards, so assemble the outcome from our three nodes. A single EXPERIMENTAL_tx_status call against one of them only returns its own shard's receipts: frankie at INCLUDED_FINAL returned only the intents.near receipt. Fall back to the archival RPCs (already configured) for receipts older than our nodes' history.
2. Intents account page: GET /v1/near/intents/{account_id} and /near/intents/:account
Current balances via mt_tokens_for_owner + mt_batch_balance_of on intents.near (frankie).
History of this account's dip4 / nep245 events: deposits (with their Quantus source), transfers, token_diff trades, withdrawals (with destination) and refunds, each linking to (1).
Account type: implicit ed25519 (64-hex), implicit eth (0x…), or named, plus public_keys_of.
No guessing who owns an account. Show what the chain links, nothing more.
3. QTC bridge: GET /v1/chains/quantus/bridge/{deposits,withdrawals} and /quantus/bridge
Deposits: Quantus tx, deposit address, amount, sweep tx (deposit address → custody), the fee payer's funding tx, NEAR mint tx, Intents account, and time from send to mint. Filter by ?account=, ?address= or ?quantus_tx=.
Withdrawals: NEAR tx, Intents account, WITHDRAW_TO address, amount, bridge fee, and the matched custody payout on Quantus (inferred, with the rule shown).
Summary: locked in custody vs minted on NEAR, the reconciliation from #39 (custody − the 5 QTC pre-bridge seed = ft_total_supply, within fees).
Indexing:
Quantus side: transfers into and out of custody and from the fee payer, which we already index.
NEAR side: omft.nearft_deposit calls signed by bridge-mng.near (shard 4, gargravarr), and intents.nearft_withdraw events for qtc.omft.near (shard 7, frankie).
Not in scope
The bridge operator's API (bridge.chaindefuser.comdeposit_address / recent_deposits). Useful for checking, but everything above is derivable on-chain and should be.
Non-QTC bridge traffic, beyond what the tx page decodes generically.
De-anonymising accounts. Linking a Quantus address to an Intents account is what the bridge publishes on-chain. The page should state that plainly rather than add attribution of its own.
## Why
A QTC bridge transaction on nearblocks shows only its envelope. For example, the mint `piPTXyoqDZwSJsKk3DWGVvDSy8T7hWm6KW4LFxpTsLk` reads as `bridge-mng.near` → `omft.near`: no Quantus sender, no Intents account, no amount in QTC terms. Everything needed to explain it is on-chain, but in function-call arguments and receipt logs that explorers don't surface. We now run nodes for every shard that matters, so the observer can surface them:
| Node | Shards | Accounts |
|---|---|---|
| frankie | 7 | `intents.near` |
| gargravarr | 8, 4 | `dclv2.ref-labs.near`; `qtc.omft.near`, `omft.near`, `liq.selfevident.near` |
| quadbrat | 12, 10 | `v2.ref-finance.near`; native USDC `17208628…` |
## What the chain already says (verified 2026-10-07)
### A deposit, Quantus → NEAR Intents
Quantus tx `0xc4444afc1d43ddccad1421cb1989a9159516411db085710317ead1adeda3bf8d` sent 0.05 QTC to the bridge deposit address `qzmobBdfcrzCFdMiEDK8DFy4XtgV2TYJQSy7iB1B3TwfDgqPf` at block 180,029. The bridge fee payer `qznFJTsh…UvB` funded it, and it was swept to custody `qzmzw3Bf…PTDk`. The NEAR mint, `piPTXyoq…`:
```
call omft.near.ft_deposit (signer bridge-mng.near)
owner_id: intents.near
token: qtc
amount: 50000000000
msg: {"receiver_id":"42d72e44014a6500cdefdac410866c848715e36c6d6a3f36457875b01e169978"}
memo: BRIDGED_FROM:{"networkType":"qtc","chainId":"mainnet","txHash":"0xc4444afc…bf8d"}
[qtc.omft.near] ft_mint owner omft.near, 50000000000
[qtc.omft.near] ft_transfer omft.near → intents.near, same BRIDGED_FROM memo
[intents.near] mt_mint owner 42d72e44…9978, nep141:qtc.omft.near, 50000000000, memo "deposit"
```
- **The Quantus transaction hash is in the NEAR memo,** so the link is exact, not inferred.
- **The deposit address → Intents account mapping is derivable from the chain alone.** The Quantus tx gives the deposit address; the mint's `msg.receiver_id` gives the account. No call to the bridge operator's API is needed.
- **Deposit addresses are permanent per account.** This one took deposits at 177,134 (mint `8m3diDYT…`) and 180,029 (mint `piPTXyoq…`). So the mapping is many deposits to one account, and stable.
### A withdrawal, NEAR Intents → Quantus
`intents.near` logs `dip4` `ft_withdraw` with `token: "qtc.omft.near"`, `receiver_id: "qtc.omft.near"`, `memo: "WITHDRAW_TO:qz…"` and the withdrawing Intents `account_id`. The QTC is then burned on NEAR, and custody pays the destination on Quantus, net of the 0.002 QTC bridge fee. (One example: custody → 1.096 QTC at block 172,709. The 2026-10-06 launch window had 122 such withdrawals to Quantus addresses.)
- **No NEAR hash appears on the Quantus side** that we've seen. Linking a withdrawal to its payout means matching destination, amount (less the fee) and time. Report the match as inferred, with its rule.
### A failed swap with its automatic refund
`E4ysnVhtKSxp1uEKrwYTXSCrP2Nenkgod1wVTQCyC4Pb` shows the whole round trip:
1. `intents.near` `ft_withdraw` + `mt_burn`
2. `qtc.omft.near` `ft_transfer` to `dclv2.ref-labs.near`
3. `dclv2` **Failure: `E407: account not in pool whitelist`**
4. `qtc.omft.near` `ft_transfer` back, `memo: "refund"`
5. `intents.near` `mt_mint`, `memo: "refund"`
A good test fixture: a tx page must show failed receipts and their refunds, not only the happy path.
## What
### 1. NEAR transaction page: `GET /v1/near/tx/{hash}` and `/near/tx/:hash`
- **The receipt tree:** executor, predecessor, status (success / failure with its message), gas burnt, and the block and shard of each receipt.
- **Decoded function-call arguments** (base64 JSON → JSON), with known memo formats parsed (`BRIDGED_FROM:{…}`, `WITHDRAW_TO:<address>`).
- **Decoded events:**
- `nep141` (`ft_mint`, `ft_transfer`, `ft_burn`)
- `nep245` (`mt_mint`, `mt_burn`, `mt_transfer`)
- `dip4` (`token_diff`, `transfer`, `ft_withdraw`, `intents_executed`)
- `dcl.ref` (`swap`)
- **Amounts shown in token units** using `ft_metadata` decimals, with the raw value alongside.
- **Cross-links:** a Quantus tx hash in `BRIDGED_FROM` links to our Quantus tx/account pages, and Intents accounts link to (2).
- **Source:** receipts live on several shards, so assemble the outcome from our three nodes. A single `EXPERIMENTAL_tx_status` call against one of them only returns its own shard's receipts: frankie at `INCLUDED_FINAL` returned only the `intents.near` receipt. Fall back to the archival RPCs (already configured) for receipts older than our nodes' history.
### 2. Intents account page: `GET /v1/near/intents/{account_id}` and `/near/intents/:account`
- **Current balances** via `mt_tokens_for_owner` + `mt_batch_balance_of` on `intents.near` (frankie).
- **History** of this account's `dip4` / `nep245` events: deposits (with their Quantus source), transfers, `token_diff` trades, withdrawals (with destination) and refunds, each linking to (1).
- **Account type:** implicit ed25519 (64-hex), implicit eth (`0x…`), or named, plus `public_keys_of`.
- **No guessing who owns an account.** Show what the chain links, nothing more.
### 3. QTC bridge: `GET /v1/chains/quantus/bridge/{deposits,withdrawals}` and `/quantus/bridge`
- **Deposits:** Quantus tx, deposit address, amount, sweep tx (deposit address → custody), the fee payer's funding tx, NEAR mint tx, Intents account, and time from send to mint. Filter by `?account=`, `?address=` or `?quantus_tx=`.
- **Withdrawals:** NEAR tx, Intents account, `WITHDRAW_TO` address, amount, bridge fee, and the matched custody payout on Quantus (inferred, with the rule shown).
- **Summary:** locked in custody vs minted on NEAR, the reconciliation from #39 (custody − the 5 QTC pre-bridge seed = `ft_total_supply`, within fees).
- **Indexing:**
- Quantus side: transfers into and out of custody and from the fee payer, which we already index.
- NEAR side: `omft.near` `ft_deposit` calls signed by `bridge-mng.near` (shard 4, gargravarr), and `intents.near` `ft_withdraw` events for `qtc.omft.near` (shard 7, frankie).
## Not in scope
- **The bridge operator's API** (`bridge.chaindefuser.com` `deposit_address` / `recent_deposits`). Useful for checking, but everything above is derivable on-chain and should be.
- **Non-QTC bridge traffic,** beyond what the tx page decodes generically.
- **De-anonymising accounts.** Linking a Quantus address to an Intents account is what the bridge publishes on-chain. The page should state that plainly rather than add attribution of its own.
Related: #27 (intents swaps), #37 (Ref DCL pool), #39 (blind spots and bridge reconciliation), #41 (bid side).
The mints are on a shard we already read.bridge-mng.near is on shard 8, which gargravarr tracks, and the direct-call scan already reads those chunks. gargravarr serves piPTXyoq… whole, and its ft_deposit arguments carry the Intents account (msg.receiver_id), the amount and BRIDGED_FROM.txHash. So recording a deposit needs no receipt fetch and no public endpoint.
A Quantus tx hash is Blake2-256 of the encoded extrinsic. Extrinsic 1 of block 180,029 hashes to exactly 0xc4444afc…bf8d. chain_extrinsic stores no hash, so it's computed for the bridge's deposit extrinsics, and stored for every extrinsic from now on.
Minting on NEAR began at #218,636,504 (a first mint of 1 QTC). That's about 142k blocks before gargravarr's history, by which point 155,994.698 QTC had been minted. Those mints are found by bisecting qtc.omft.near's ft_total_supply on the archive, then reading only the shard-8 chunks around each change. A block-by-block scan of the gap would cost about a day of public calls; this costs a few per mint.
Order:
Bridge deposits and withdrawals, linked (part 3).
Deposits: exact, joined on the computed hash.
Withdrawals: ft_withdraw / WITHDRAW_TO from the intents scan, matched to the custody payout on Quantus by destination, amount less the 0.002 QTC fee, and time. Marked as inferred, with the rule shown; anything that doesn't match is listed as unmatched, never forced.
NEAR tx page (part 1). Whole transactions from the archive, stored permanently once final, since a final tx never changes. Assembly from our own nodes once completeness can be checked. E4ysnVht… (failure plus refund) is the test fixture.
Intents account page (part 2). Balances from frankie; history assembled from what 1 and 2 index.
## 2026-10-07: plan, and three facts checked first
**Facts:**
- **The mints are on a shard we already read.** `bridge-mng.near` is on shard 8, which gargravarr tracks, and the direct-call scan already reads those chunks. gargravarr serves `piPTXyoq…` whole, and its `ft_deposit` arguments carry the Intents account (`msg.receiver_id`), the amount and `BRIDGED_FROM.txHash`. So recording a deposit needs no receipt fetch and no public endpoint.
- **A Quantus tx hash is Blake2-256 of the encoded extrinsic.** Extrinsic 1 of block 180,029 hashes to exactly `0xc4444afc…bf8d`. `chain_extrinsic` stores no hash, so it's computed for the bridge's deposit extrinsics, and stored for every extrinsic from now on.
- **Minting on NEAR began at #218,636,504** (a first mint of 1 QTC). That's about 142k blocks before gargravarr's history, by which point 155,994.698 QTC had been minted. Those mints are found by bisecting `qtc.omft.near`'s `ft_total_supply` on the archive, then reading only the shard-8 chunks around each change. A block-by-block scan of the gap would cost about a day of public calls; this costs a few per mint.
**Order:**
1. **Bridge deposits and withdrawals, linked (part 3).**
- Deposits: exact, joined on the computed hash.
- Withdrawals: `ft_withdraw` / `WITHDRAW_TO` from the intents scan, matched to the custody payout on Quantus by destination, amount less the 0.002 QTC fee, and time. Marked as inferred, with the rule shown; anything that doesn't match is listed as unmatched, never forced.
2. **NEAR tx page (part 1).** Whole transactions from the archive, stored permanently once final, since a final tx never changes. Assembly from our own nodes once completeness can be checked. `E4ysnVht…` (failure plus refund) is the test fixture.
3. **Intents account page (part 2).** Balances from frankie; history assembled from what 1 and 2 index.
2026-10-07: parts 1 and 2, what was measured before building
Part 3 is live and verified: 313 of 314 deposits are linked, and all 328 withdrawals are matched at a 0.002 QTC fee. #46 recovered three history mints that had been dropped. The one unlinked deposit (1.348 QTC, Quantus #180,567) has no mint on NEAR at all.
A whole transaction can be assembled from our own nodes, which contradicts the plan above ("from the archive … assembly from our own nodes once completeness can be checked"). Completeness turns out to be checkable, and the missing receipts are fetchable:
EXPERIMENTAL_tx_status answers only on a node tracking the signer's shard, and only when sender_account_id is an account on that shard. gargravarr returned 10 of 11 receipts for piPTXyoq…. frankie and quadbrat returned final_execution_status: NONE with nothing. A wrong-shard sender gets UNKNOWN_TRANSACTION or NONE even from the right node. The sender only routes; any account on the signer's shard works.
Completeness: every id in a receipt_ids list (the transaction's own, and each outcome's) must have an outcome. For piPTXyoq… the missing one was 5ecjV2FP…, the intents.nearft_on_transfer that logs mt_mint to 42d72e44…, which runs on shard 7.
A missing receipt is fetchable from the node tracking its receiver:EXPERIMENTAL_receipt returns the receipt (predecessor, actions), and EXPERIMENTAL_light_client_proof with type: receipt returns its outcome (logs, status, spawned receipts). frankie answered both for 5ecjV2FP…, so the tree is completed by following spawned receipts across our three nodes.
A public node (FastNEAR) answers tx_status for any sender with all outcomes (12 for piPTXyoq…). It is the fallback for a transaction older than our nodes' history, or one touching a shard we don't track (zec, btc and so on).
So the plan is: our nodes first, public only for what they can't serve, and the page says which source it was. A transaction is stored permanently once complete and every block it touched is final. It is stored raw and decoded on read, so a decoder fix applies to everything already stored.
Where the signer comes from. The page is addressed by hash alone. The API looks up an account on the signer's shard from what it indexed: the configured minter for a bridge mint, and intents.near for anything read from shard 7, which is the intents scan's trades, transfers and withdrawals. A hash it has never seen goes straight to the public node.
URLs are chain-scoped,/quantus/near/tx/<hash> and /quantus/near/intents/<account>, not the /near/… in the issue body. The site's grammar is /:chain/:kind/…, so /near would parse as a chain named "near". Both pages sit in the Markets section, which already covers the token on NEAR.
The account page's history is what this observer indexes, which is QTC only: trades, transfers, bridge deposits and bridge withdrawals. It is not every dip4/nep245 event the account was ever in. The page says so beside the list. Balances are complete for all tokens, read live from intents.near on frankie (mt_tokens_for_owner, mt_batch_balance_of, public_keys_of).
## 2026-10-07: parts 1 and 2, what was measured before building
Part 3 is live and verified: 313 of 314 deposits are linked, and all 328 withdrawals are matched at a 0.002 QTC fee. #46 recovered three history mints that had been dropped. The one unlinked deposit (1.348 QTC, Quantus #180,567) has no mint on NEAR at all.
**A whole transaction can be assembled from our own nodes, which contradicts the plan above** ("from the archive … assembly from our own nodes once completeness can be checked"). Completeness turns out to be checkable, and the missing receipts are fetchable:
- `EXPERIMENTAL_tx_status` answers only on a node tracking **the signer's shard**, and only when `sender_account_id` is an account on that shard. gargravarr returned 10 of 11 receipts for `piPTXyoq…`. frankie and quadbrat returned `final_execution_status: NONE` with nothing. A wrong-shard sender gets `UNKNOWN_TRANSACTION` or `NONE` even from the right node. The sender only routes; any account on the signer's shard works.
- **Completeness:** every id in a `receipt_ids` list (the transaction's own, and each outcome's) must have an outcome. For `piPTXyoq…` the missing one was `5ecjV2FP…`, the `intents.near` `ft_on_transfer` that logs `mt_mint` to `42d72e44…`, which runs on shard 7.
- **A missing receipt is fetchable from the node tracking its receiver:** `EXPERIMENTAL_receipt` returns the receipt (predecessor, actions), and `EXPERIMENTAL_light_client_proof` with `type: receipt` returns its outcome (logs, status, spawned receipts). frankie answered both for `5ecjV2FP…`, so the tree is completed by following spawned receipts across our three nodes.
- A public node (FastNEAR) answers `tx_status` for any sender with all outcomes (12 for `piPTXyoq…`). It is the fallback for a transaction older than our nodes' history, or one touching a shard we don't track (zec, btc and so on).
So the plan is: our nodes first, public only for what they can't serve, and the page says which source it was. A transaction is stored permanently once complete and every block it touched is final. It is stored raw and decoded on read, so a decoder fix applies to everything already stored.
**Where the signer comes from.** The page is addressed by hash alone. The API looks up an account on the signer's shard from what it indexed: the configured minter for a bridge mint, and `intents.near` for anything read from shard 7, which is the intents scan's trades, transfers and withdrawals. A hash it has never seen goes straight to the public node.
**URLs are chain-scoped,** `/quantus/near/tx/<hash>` and `/quantus/near/intents/<account>`, not the `/near/…` in the issue body. The site's grammar is `/:chain/:kind/…`, so `/near` would parse as a chain named "near". Both pages sit in the Markets section, which already covers the token on NEAR.
**The account page's history is what this observer indexes,** which is QTC only: trades, transfers, bridge deposits and bridge withdrawals. It is not every `dip4`/`nep245` event the account was ever in. The page says so beside the list. Balances are complete for all tokens, read live from `intents.near` on frankie (`mt_tokens_for_owner`, `mt_batch_balance_of`, `public_keys_of`).
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
A QTC bridge transaction on nearblocks shows only its envelope. For example, the mint
piPTXyoqDZwSJsKk3DWGVvDSy8T7hWm6KW4LFxpTsLkreads asbridge-mng.near→omft.near: no Quantus sender, no Intents account, no amount in QTC terms. Everything needed to explain it is on-chain, but in function-call arguments and receipt logs that explorers don't surface. We now run nodes for every shard that matters, so the observer can surface them:intents.neardclv2.ref-labs.near;qtc.omft.near,omft.near,liq.selfevident.nearv2.ref-finance.near; native USDC17208628…What the chain already says (verified 2026-10-07)
A deposit, Quantus → NEAR Intents
Quantus tx
0xc4444afc1d43ddccad1421cb1989a9159516411db085710317ead1adeda3bf8dsent 0.05 QTC to the bridge deposit addressqzmobBdfcrzCFdMiEDK8DFy4XtgV2TYJQSy7iB1B3TwfDgqPfat block 180,029. The bridge fee payerqznFJTsh…UvBfunded it, and it was swept to custodyqzmzw3Bf…PTDk. The NEAR mint,piPTXyoq…:msg.receiver_idgives the account. No call to the bridge operator's API is needed.8m3diDYT…) and 180,029 (mintpiPTXyoq…). So the mapping is many deposits to one account, and stable.A withdrawal, NEAR Intents → Quantus
intents.nearlogsdip4ft_withdrawwithtoken: "qtc.omft.near",receiver_id: "qtc.omft.near",memo: "WITHDRAW_TO:qz…"and the withdrawing Intentsaccount_id. The QTC is then burned on NEAR, and custody pays the destination on Quantus, net of the 0.002 QTC bridge fee. (One example: custody → 1.096 QTC at block 172,709. The 2026-10-06 launch window had 122 such withdrawals to Quantus addresses.)A failed swap with its automatic refund
E4ysnVhtKSxp1uEKrwYTXSCrP2Nenkgod1wVTQCyC4Pbshows the whole round trip:intents.nearft_withdraw+mt_burnqtc.omft.nearft_transfertodclv2.ref-labs.neardclv2Failure:E407: account not in pool whitelistqtc.omft.nearft_transferback,memo: "refund"intents.nearmt_mint,memo: "refund"A good test fixture: a tx page must show failed receipts and their refunds, not only the happy path.
What
1. NEAR transaction page:
GET /v1/near/tx/{hash}and/near/tx/:hashBRIDGED_FROM:{…},WITHDRAW_TO:<address>).nep141(ft_mint,ft_transfer,ft_burn)nep245(mt_mint,mt_burn,mt_transfer)dip4(token_diff,transfer,ft_withdraw,intents_executed)dcl.ref(swap)ft_metadatadecimals, with the raw value alongside.BRIDGED_FROMlinks to our Quantus tx/account pages, and Intents accounts link to (2).EXPERIMENTAL_tx_statuscall against one of them only returns its own shard's receipts: frankie atINCLUDED_FINALreturned only theintents.nearreceipt. Fall back to the archival RPCs (already configured) for receipts older than our nodes' history.2. Intents account page:
GET /v1/near/intents/{account_id}and/near/intents/:accountmt_tokens_for_owner+mt_batch_balance_ofonintents.near(frankie).dip4/nep245events: deposits (with their Quantus source), transfers,token_difftrades, withdrawals (with destination) and refunds, each linking to (1).0x…), or named, pluspublic_keys_of.3. QTC bridge:
GET /v1/chains/quantus/bridge/{deposits,withdrawals}and/quantus/bridge?account=,?address=or?quantus_tx=.WITHDRAW_TOaddress, amount, bridge fee, and the matched custody payout on Quantus (inferred, with the rule shown).ft_total_supply, within fees).omft.nearft_depositcalls signed bybridge-mng.near(shard 4, gargravarr), andintents.nearft_withdrawevents forqtc.omft.near(shard 7, frankie).Not in scope
bridge.chaindefuser.comdeposit_address/recent_deposits). Useful for checking, but everything above is derivable on-chain and should be.Related: #27 (intents swaps), #37 (Ref DCL pool), #39 (blind spots and bridge reconciliation), #41 (bid side).
2026-10-07: plan, and three facts checked first
Facts:
bridge-mng.nearis on shard 8, which gargravarr tracks, and the direct-call scan already reads those chunks. gargravarr servespiPTXyoq…whole, and itsft_depositarguments carry the Intents account (msg.receiver_id), the amount andBRIDGED_FROM.txHash. So recording a deposit needs no receipt fetch and no public endpoint.0xc4444afc…bf8d.chain_extrinsicstores no hash, so it's computed for the bridge's deposit extrinsics, and stored for every extrinsic from now on.qtc.omft.near'sft_total_supplyon the archive, then reading only the shard-8 chunks around each change. A block-by-block scan of the gap would cost about a day of public calls; this costs a few per mint.Order:
ft_withdraw/WITHDRAW_TOfrom the intents scan, matched to the custody payout on Quantus by destination, amount less the 0.002 QTC fee, and time. Marked as inferred, with the rule shown; anything that doesn't match is listed as unmatched, never forced.E4ysnVht…(failure plus refund) is the test fixture.2026-10-07: parts 1 and 2, what was measured before building
Part 3 is live and verified: 313 of 314 deposits are linked, and all 328 withdrawals are matched at a 0.002 QTC fee. #46 recovered three history mints that had been dropped. The one unlinked deposit (1.348 QTC, Quantus #180,567) has no mint on NEAR at all.
A whole transaction can be assembled from our own nodes, which contradicts the plan above ("from the archive … assembly from our own nodes once completeness can be checked"). Completeness turns out to be checkable, and the missing receipts are fetchable:
EXPERIMENTAL_tx_statusanswers only on a node tracking the signer's shard, and only whensender_account_idis an account on that shard. gargravarr returned 10 of 11 receipts forpiPTXyoq…. frankie and quadbrat returnedfinal_execution_status: NONEwith nothing. A wrong-shard sender getsUNKNOWN_TRANSACTIONorNONEeven from the right node. The sender only routes; any account on the signer's shard works.receipt_idslist (the transaction's own, and each outcome's) must have an outcome. ForpiPTXyoq…the missing one was5ecjV2FP…, theintents.nearft_on_transferthat logsmt_mintto42d72e44…, which runs on shard 7.EXPERIMENTAL_receiptreturns the receipt (predecessor, actions), andEXPERIMENTAL_light_client_proofwithtype: receiptreturns its outcome (logs, status, spawned receipts). frankie answered both for5ecjV2FP…, so the tree is completed by following spawned receipts across our three nodes.tx_statusfor any sender with all outcomes (12 forpiPTXyoq…). It is the fallback for a transaction older than our nodes' history, or one touching a shard we don't track (zec, btc and so on).So the plan is: our nodes first, public only for what they can't serve, and the page says which source it was. A transaction is stored permanently once complete and every block it touched is final. It is stored raw and decoded on read, so a decoder fix applies to everything already stored.
Where the signer comes from. The page is addressed by hash alone. The API looks up an account on the signer's shard from what it indexed: the configured minter for a bridge mint, and
intents.nearfor anything read from shard 7, which is the intents scan's trades, transfers and withdrawals. A hash it has never seen goes straight to the public node.URLs are chain-scoped,
/quantus/near/tx/<hash>and/quantus/near/intents/<account>, not the/near/…in the issue body. The site's grammar is/:chain/:kind/…, so/nearwould parse as a chain named "near". Both pages sit in the Markets section, which already covers the token on NEAR.The account page's history is what this observer indexes, which is QTC only: trades, transfers, bridge deposits and bridge withdrawals. It is not every
dip4/nep245event the account was ever in. The page says so beside the list. Balances are complete for all tokens, read live fromintents.nearon frankie (mt_tokens_for_owner,mt_batch_balance_of,public_keys_of).