Verification log

Everything below was observed against the deployed system, not computed from the code. Each row says what was checked, what came back, and where a reader can check it independently. The explorer links are for people; the mirror-node and gateway links are the ones to use from a script, because HashScan and Arcscan are client-rendered apps that answer 404 to a plain curl.

Service: https://vaultradar-service-production.up.railway.app · Dashboard: https://vaultradar-dashboard-production.up.railway.app

Deployed subgraphs, the verification gate

bun run verify-deployments queries each registered deployment's _meta and pins what it finds. Run against the live gateway:

live 11, stale 1, down 3 / 15 total     14 of 15 deployment ids pinned

The three that are down are an upstream fact, not a defect: convex-finance and aura-finance on Ethereum last indexed years ago, and aave-v3 on Base resolves to no allocations, so there is no deployment id to pin. Vaults under a dead registration come back unavailable rather than silently stale. The live data path itself:

On-chain identity

The service's ML-DSA-65 public-key hash is written as ERC-8004 metadata under pq.sig.pubhash at registry 0x8004A818BFB912233c491871b3d84c89A494BD9e, which is deployed at the same address on both testnets.

Both anchors were read back and compared against the live agent card's pq.sig.pub_hash:

card pub_hash : dd4a56bffd570c901648dcac7261d5bc38c079a139f3bc0e26c619a138cbf2e1
chain 296     : matches
chain 5042002 : matches

The agent's own discover(), the code path that decides whether to pay, reports cardSignatureValid: true, keyBindingValid: true, and both identities matching.

Settled payments

Nine paid requests have settled: eight on Hedera, one on Arc. Every row below was read back rather than copied from the run records, the transactions from the Hedera mirror node, the receipt hashes from the deployed service, which still serves each one.

All eight Hedera transactions are SUCCESS, all eight move HTS USDC 0.0.429274 from payer 0.0.10463726 to pay-to 0.0.10463666, and all eight are submitted by the same facilitator account 0.0.7162784, which is why the ids share a prefix.

The amounts are the pricing constants as they land on chain, which is the check that the quote the client enforced and the charge the facilitator signed are the same number: 0.0015 is 0.001 + 0.0005 × 1 and 0.051 is that formula at a hundred vaults, both hederaScanPriceUsd in packages/core/src/pricing.ts, and the strict tier's whole-protocol table is the flat TABLE_PRICE_USD of 0.06 in the same file.

The five 100-vault scans are the ones worth clicking: each bought a sealed verdict for every vault under the two live Messari registrations in one request, and the price rose with the count, which a single-vault example cannot show.

One in full

The first row, as the mirror node returns it:

transaction  0.0.7162784@1789169558.289173297
payer        0.0.10463726   −1500 atomic units of HTS USDC 0.0.429274
payTo        0.0.10463666   +1500 atomic units
result       SUCCESS            consensus 1789169584.294669104

The client verified the returned receipt, opened the sealed reply, and printed the signed per-vault attestation inside it.

Arc rail

The ninth. 2 USDC deposited into Circle Gateway, then a 0.003 USDC sealed scan. Gateway batches settlement, so a payment's own reference is a batch id rather than a transaction hash:

approval tx  0xcb3e84eb2c788e46cb5ae5110a7b50fc4d8f85d84b2ebd398c50a6d50e54c949
deposit tx   0xe253e739cd2ca42c11c841db8d6891470ee0d22bff5ba30acb75c453ce35ac64
payment      batch reference cbc2021d-d57e-4e05-b43f-56707a532f33, receipt ok, reply opened

approval · deposit

HCS audit trail

Each settled request enqueues { v, receipt_hash, sig, issued_at } to topic 0.0.10483981. The ML-DSA-65 signature is larger than the topic's message limit, so the queue chunks it and the reader reassembles on lookup. One committed receipt, looked up through the service:

GET /v1/receipts/50bddf81474ad98fca492c1f640a695ea525342dc4cef85c2f5ff0704ff50cbc
→ { topicId: "0.0.10483981", sequence: "10", consensus_timestamp: "1789168622.245410844" }

Topic on the mirror node

Substreams sink

The ERC-4626 module is published as erc4626-vault-metrics@v0.1.0 and runs as a sink in the same project, writing into the Postgres the service reads. Observed while catching up:

cursor block  25,957,527   (chain head 25,957,608 — 81 blocks behind)
rows written  190,220      (~79 rows/s)

Test suite

bun test        464 pass, 1 skip, 0 fail
bun run typecheck  exit 0 across core, service, agent and dashboard