An outsider's check of NEAR Intents, from public chain data

Is every NEAR Intents balance backed?

NEAR Intents keeps every user's balance in one contract, intents.near. For each token, the sum of those balances should never exceed what the contract actually holds on the token's own contract. Two read-only calls test it. Anyone can run them, at any block.

Today

Reading the latest snapshot.

29 September 2026

Not backed

Reading the replay.

Exhibit 1

The hole, replayed block by block

USDT on BNB Chain, as held inside intents.near through the HOT Omni bridge. 25 September to 6 October 2026.

Owed to users mt_supply Held by the contract mt_balance_of Owed with nothing behind it USDT, millions

Reading.

The exact calls behind this chart

// liabilities: the sum of every user's balance of the token
intents.near  mt_batch_supply({"token_ids":["nep245:v2_1.omni.hot.tg:56_2CMMyVTGZkeyNZTSvS5sarzfir6g"]})
// holdings: what the contract owns on the token's own contract
v2_1.omni.hot.tg  mt_balance_of({"account_id":"intents.near","token_id":"56_2CMMyVTGZkeyNZTSvS5sarzfir6g"})
// both as JSON-RPC "query" / "call_function" with "block_id": <height>
// on archival-rpc.mainnet.fastnear.com (the deprecated archival-rpc.mainnet.near.org now refuses every request)

Points: every 6 hours across the window and every hour from 29 Sep 12:00 to 3 Oct 00:00 UTC, each at the block closest to that time. Data: replay-series.csv.

The ghost tally

The blocks where the unbacked amount changed, each found by bisection over block heights.

Reading.

How the steps were found

Between two heights with the same shortfall the code assumes no net change; otherwise it splits the interval and recurses until each change is pinned to the first block that shows it. Changes that reverse within 10 blocks are in-flight receipts of ordinary deposits and withdrawals and are dropped. Source: src/replay.js findSteps, levels. Data: ghost-steps.csv.

Every step in the unbacked amount
Block	Time (UTC)	Change	Unbacked after	Transaction (re-read from chain)

Was September the only hole?

The same check, once a day over the whole history archival RPC serves.

Reading.

How the days were sampled

Command: npm run history (resumable; every answer is cached). Data: data/raw/history/daily-top.json, summary data/derived/history.json.

Would the check cry wolf?

The same rule run over every priced token at eight moments. The rule fires when a token's unbacked amount is worth $1,000 or more at that day's price.

Reading.

The exact calls and prices

For each moment: intents.near mt_batch_supply for every token the 1Click API lists, then each token's own balance view for intents.near, all pinned to one block. Historical USD prices: coins.llama.fi/prices/historical/<unix>/coingecko:<id>, using the CoinGecko id the 1Click list gives each token.

Did the money come back?

The thesis's tested claim: what intents.near owes users, once a day, before and after the hole.

Owed to users mt_batch_supply The hole, first unbacked unit to closed USD at fixed prices, millions

Reading.

The test, and what would have proved it wrong

The same test on four measures, and with each token left out
Measure	Back at the reference level	With any one token left out	Last sample	Result

Command: npm run flows re-reads every daily sample from an archival node and requires every value to match. Data: data/raw/flows/daily-supply.json, result data/derived/flows.json, rules src/flows.js. THESIS.md, F6.

Exhibit 2

Today's ledger

Reading.

The 20 largest liabilities, owed against held

Bars are what users are owed in USD. A notch marks what the contract holds; a red segment would show a shortfall.

Reading.

The exact calls behind this table

intents.near  mt_tokens({"from_index":"0","limit":2000})            // every token id the ledger lists
intents.near  mt_batch_supply({"token_ids":[...100 ids...]})       // what users are owed
<ft>          ft_balance_of({"account_id":"intents.near"})          // NEP-141 holdings
<mt>          mt_batch_balance_of({"account_id":"intents.near","token_ids":[...]}) // NEP-245
// all at one "block_id"; prices from GET https://1click.chaindefuser.com/v0/tokens

Full table, every token with a balance: backing-now.csv.

Only tokens not fully backed

Every token with a balance in intents.near
Token	Chain	Owed (USD)	Held / owed	Status

Exhibit 3

Check it yourself, now

Your browser asks a public NEAR RPC node directly. Read-only views, no wallet, nothing signed. By default it checks the 25 largest liabilities (about 25 requests, seconds); tick the box to check every priced token (about 170 requests, two to four minutes on the free public node, which rate-limits).

Every priced token (slower)

Uses free.rpc.fastnear.com for chain reads and the 1Click token list for prices. The code it runs is the same module the command line uses: lib/check.js.

Exhibit 4

A result other contracts can read

The checker posts each result to a small contract on NEAR testnet, pinned to the mainnet block it checked. A lending market or vault could refuse NEAR Intents tokens as collateral unless is_backed_at_or_after(block) returns true. The contract derives "backed" from the numbers; it never takes the checker's word for it.

Reading the contract on testnet...

The exact calls

// read (this page, live, testnet RPC):
ghostcount.testnet  latest({})
ghostcount.testnet  is_backed_at_or_after({"block":"<mainnet height>"})
// write (CLI: npm run attest), signed by a function-call key that can only call attest:
ghostcount.testnet  attest({"a":{"mainnet_block":"...","owed_usd_cents":"...","shortfall_usd_cents":"...",
                                     "short_priced_tokens":[...],"report_sha256":"...", ...}})

Exhibit 5

What backs the backing, and who can move it

Layer 1 proves intents.near holds the tokens it owes. Most of those tokens are themselves claims on coins somewhere else, and the contracts have administrators. Some of that second layer can be checked from public data, to the coin. Most of it cannot.

How much of what users are owed can be checked

Priced liabilities in intents.near, by how far their reserves can be verified from public data.

nBTC: Bitcoin under NEAR's own signer

btc-connector.bridge.near, read from chain; UTXOs looked up on Bitcoin.

The exact calls

btc-connector.bridge.near  get_config({})            // signer: v1.signer, root key, change address
btc-connector.bridge.near  get_utxos_paged({"from_index":0,"limit":40})   // every UTXO + key path
btc-connector.bridge.near  get_btc_pending_infos_paged(...)               // withdrawals in flight
nbtc.bridge.near           ft_total_supply({})
v1.signer                  public_key({"domain_id":0})
v1.signer                  derived_public_key({"path":"<path>","predecessor":"btc-connector.bridge.near","domain_id":0})
// key = root + sha3-256("near-mpc-recovery v0.1.0 epsilon derivation:btc-connector.bridge.near,<path>") * G
// address = bech32 P2WPKH of hash160(compressed key), as in contracts/satoshi-bridge/src/kdf.rs
GET https://mempool.space/api/address/<address>/utxo
GET https://blockstream.info/api/address/<address>/utxo

wNEAR: NEAR held by wrap.near

wrap.near, read from chain.

The exact calls

wrap.near  ft_total_supply({})
query view_account wrap.near              // amount + locked; storage_usage * 10^19 yoctoNEAR is reserved for storage
query view_access_key_list wrap.near      // no keys: nobody can redeploy or sign for it
// near_deposit mints 1:1 for attached NEAR, near_withdraw burns and sends NEAR back
// (github.com/near/core-contracts, w-near/src/w_near.rs)

Who can do what to intents.near

Roles read from the contract's own access-control views.

The exact calls

intents.near  acl_get_super_admins({"skip":0,"limit":100})
intents.near  acl_get_grantees({"role":"<Role>","skip":0,"limit":100})  // 12 roles
intents.sputnik-dao.near  get_policy({})
query view_access_key_list intents.near

The tokens behind the largest balances

NEAR-side supply of each token, how much of it sits inside intents.near, and whether what backs it can be checked.

Token supply and reserves
Token	Route	In intents.near	Reserves

The exact calls

<ft>  ft_total_supply({})                         // whole NEAR-side supply
<ft>  ft_balance_of({"account_id":"intents.near"})
omft.near  acl_get_grantees({"role":"TokenDepositer",...}) // who may mint PoA tokens

Which bridge stands behind what users are owed

Priced liabilities in intents.near, grouped by the contract that issues each token.

Who can mint the bridged tokens

Read from each bridge contract's access-control views.

The exact calls

omft.near  acl_get_grantees({"role":"TokenDepositer","skip":0,"limit":100})
omft.near  acl_get_super_admins({"skip":0,"limit":100})
v2_1.omni.hot.tg / omdep.near / omni.bridge.near  acl_get_super_admins(...)
query view_account / view_access_key_list  <each holder>
// PoA factory source: contracts/poa/factory/src/contract.rs, ft_deposit()
//   #[access_control_any(roles(Role::DAO, Role::TokenDepositer))]

Chain Signatures, for comparison

v1.signer state, read from chain.

Method

Rebuild every number on this page

git clone https://github.com/spragginsdesigns/ghostcount && cd ghostcount
npm run rebuild:quick   # live check + re-reads recorded history, minutes
npm run rebuild         # full: dense replay, step search, controls
npm run check           # print today's check only
npm run demo            # serve this page on localhost:4110

What this does not prove

Layer 1 checks intents.near against the NEAR-side token contracts. Layer 2 is checked here only for wNEAR and nBTC; for the PoA Bridge and HOT Omni the reserves are not published in a form anyone outside could verify.
Bitcoin lookups use two public indexers, not a Bitcoin node of our own, and NEAR reads trust the RPC node; neither verifies proofs.
NFTs (NEP-171) are counted but not checked by default; there are tens of thousands and they carry no price.
Tokens without a 1Click price are checked, but their shortfalls carry no USD value and are listed separately.
A backed ledger is not a safe one: the roles above can still move or freeze balances by design.