Direct signing request receipts
Distinct account + input groups Additional receipts with repeated inputs
Bars start at zero and keep the same scale when the counting lens changes.
An investigation, not an adoption score
Is chain abstraction becoming a platform?
Real use is visible. Platform breadth remains unresolved. Here, even the direction of a short activity comparison depends on what we count.
NEAR mainnet
v1.signer10 & 11 Nov 2026 · 00:00–01:00 UTCSaved, selected cohorts · not a live trendThe analytical lens
Same records. Different questions.
Loading the sealed receipt evidence…
Inspect the measurement
Inspect repeated signing inputs
Each receipt is real. Grouping identical inputs answers a different question; it does not make the original workload count wrong.
| Initiating account / input | 10 Nov | 11 Nov | Inspect |
|---|
Facts, interpretation, alternatives
What does this establish?
The activity signal is definition-sensitive.
Loading the whole-hour measurement…
Grouping uses the initiating account and the complete decoded signing arguments. It does not group by account name or guess which users belong together.
Workload is not platform breadth.
The shared signing service is being used. These two post hoc one-hour cohorts do not identify independent operators, establish sustained adoption, or measure destination execution.
A successful platform could also be concentrated: one integration can serve many users. Concentration alone does not refute the platform thesis.
A repeated input has more than one explanation.
It may reflect a retry, an intentional repeat, or application logic. Some same-input pairs contain an “Already signed” callback error; other pairs have no recorded failure. We do not classify all repeats as retries.
Different time-of-hour mixes, automation and incomplete indexing can also affect the comparison. Change the matched window to inspect that sensitivity.
Coverage, attribution, and what is unknown
Exact population
Both cohorts are selected by parent-transaction block and UTC timestamp. Receipt creation and execution may occur later. They are not two full days or a representative monthly sample.
Source: FastNear’s indexed account history and complete returned traces, with archived NEAR boundary blocks. Returned parent sets and emitted receipt coverage are verified; completeness against an independent full node is not established.
Attribution stays bounded
omni.bridge.near has a documented Omni Bridge contract role. That does not prove independent ownership or a user count. Architectural bridge-family relationships are treated as heuristic grouping, not common control.
Operator identities for fast-auth.near, tx-bench.near, the kernel accounts and other initiators remain unverified in this study. Names and periodic activity do not prove test traffic or artificial demand.
Input equality is not intent equality. Signature request, returned signature data and destination settlement are different stages. No execution rate is inferred.
Make the result yours
Re-run it from the raw records.
The contribution is a reproducible measurement sensitivity—not a new explorer, an adoption score, or a prediction.
npm test
npm run rebuild
npm run independent-audit
npm run investigation-check
npm run serveOffline path: Node.js 20+ and Python 3. No install, API key, wallet, or chain transaction needed.
Original findings & sensitivity tableWhat changes with the definition and window ↗Methodology & source queriesSelection, deduplication and limitations ↗Immutable raw comparison archiveIndex pages, transaction traces, boundaries and protocol rules ↓Artifact checksumsVerify the exact dataset and generated documents ↗The long-term NEAR thesisEvidence for, evidence against, and what would change the case ↗Public sourceCollection scripts, analysis and tests ↗