Research, with
an inspectable basis.

01 / RESEARCH NOTES

Overview

SYNAP is an early interface for deep onchain research, initially scoped around Robinhood Chain and Pons Launchpad. The interface is operational; onchain collection and analytical engines are not connected.

The research model considers transaction behavior, wallet distributions and capital flows together. Its purpose is to help inspect evidence and its limitations, rather than replace evidence with a risk label.

• Observe before interpreting. Preserve what the chain records separately from an explanation of intent.
• Define the population. State the chain, block, time window, denominator, exclusions and coverage behind every metric.
• Keep uncertainty visible. Missing data, conflicting sources and indexing delays are part of the result.
• Make findings reproducible. Retain references and method versions so another researcher can inspect them.

02 / RESEARCH NOTES

System architecture

The intended pipeline has six stages. Only the research-input interface exists as a working research operation in this release.

1. Research input

   Implemented. A public address is trimmed and checked for the 0x + 40 hexadecimal character format. This does not validate a mixed-case checksum, chain membership or contract existence.

2. Data collection

   Planned. Read chain state, paginated indexed records and verified launch events through configured providers.

3. Validation

   Planned on the server. Recheck inputs, verify chain identity, reconcile sources and record coverage. Client-side syntax validation cannot replace this boundary.

4. Statistical processing

   Planned. Calculate distributions and time-based statistics on defined, versioned datasets with explicit denominators.

5. Security evaluation

   Planned. Inspect available contract evidence, control surfaces and coverage without treating a checklist as a safety guarantee.

6. Evidence-based reporting

   Planned. Attach observations, hypotheses, references and limitations to a reproducible report.

The current application uses Next.js App Router, TypeScript and Tailwind. The hero is a lazily loaded React Three Fiber scene. Documentation is server-rendered; interactive UI uses client components. There is no research API, database, indexer or server-side provider secret in the implementation.

03 / RESEARCH NOTES

Data sources

These are intended source classes, not active connections. Listing an endpoint or explorer does not establish integration, uptime or complete coverage.

Robinhood Chain RPC — not connected

Robinhood publishes separate mainnet and testnet configurations. A connector must verify chain identity before using a response. Public RPC capacity is rate-limited; historical queries may need archive access. No RPC health check or chain read is performed by SYNAP today. See the official network and endpoint documentation ↗.

Blockscout — not connected

An indexed explorer can supply contract metadata and token-holder records. The Blockscout token API reference ↗ documents paginated holder retrieval. Supported endpoints, authentication and limits depend on the instance and service. A future connector must check its configuration rather than assume a universal rate limit.

Pons launch events — unverified

No Pons factory address, ABI, deployment block or event signature has been verified in this repository. Launch-event ingestion remains unavailable until these identities and source references are established. A project name alone is not an authoritative contract identifier.

Freshness, completeness and indexing

RPC state and an explorer index can reflect different block heights. Reorganizations, delayed indexing, pagination gaps, provider timeouts and unavailable history can change the observed dataset. Record retrieval time, observed block number and hash, source identity, finality assumptions and missing ranges. An incomplete response must not be interpreted as a zero balance or no activity.

04 / RESEARCH NOTES

Statistical methodology

The following are definitions for planned analytical modules. They are not computed from live wallet data in the current application.

Holder concentration

Sort nonnegative balances in descending order: b₍₁₎ ≥ b₍₂₎ ≥ … ≥ b_(n). Choose an integer k between 1 and n, and a strictly positive, explicitly stated denominator D. D might be total supply at the observed block, an adjusted circulating-supply estimate, or the sum of a selected holder population. These choices answer different questions.

Numerator and denominator must use the same token units and compatible observation times. A concentration above 1 indicates an inconsistent denominator, duplicate accounting or incompatible observations; it is not an ordinary ownership share. Results are comparable across time only when denominator and exclusion policies are consistent.

Normalized holder distribution

Every analyzed balance must be finite and nonnegative, and their sum must be positive. The resulting p_i values sum to 1 over the analyzed population. They are not necessarily shares of the token’s full supply. An empty dataset or an all-zero dataset yields an undefined distribution; report it as unavailable.

Shannon entropy

Using the natural logarithm gives entropy in nats. Define the contribution at p_i = 0 by its limit, 0 ln(0) = 0. For n analyzed categories, 0 ≤ H ≤ ln(n); equal shares achieve the upper bound. Normalizing by ln(n) requires n > 1. For a population containing a single category, H = 0 and H / ln(1) is undefined.

Entropy describes the selected distribution, not the independence of owners. Wallet splitting can increase entropy without distributing control. Truncated holder lists and changing sample sizes can change entropy even if underlying ownership has not changed.

Z-score

Define the observation x, baseline population or sample, mean μ and standard deviation σ. If a sample estimator is used, specify the estimator and its minimum sample size. A zero or undefined standard deviation makes the z-score undefined; do not emit infinity or manufacture a zero score.

A z-score is a standardized distance, not automatically a probability or evidence of manipulation. Normal-tail interpretations require additional distributional assumptions. Autocorrelation, heavy tails, selection effects and nonstationary activity can invalidate naive thresholds. Define time windows before analysis and distinguish an exploratory pattern from a hypothesis tested on independent observations.

Entity types and exclusions

Contract-held tokens may represent staking or escrow. A liquidity pool holds reserves for many participants; a bridge can custody backing assets; an exchange may aggregate users; a treasury can hold operational inventory. None should automatically be treated as a single independent investor. Report raw address-level results alongside any adjusted population, disclose labels and their evidence, and avoid double-counting wrapped or bridged claims.

Sampling and missing data

Top-holder truncation, dust thresholds, missing transfer history, inconsistent decimals and index lag all introduce bias. A partial snapshot does not support a claim about the complete holder population. Publish analyzed counts, balance coverage relative to D, excluded categories and the snapshot block. Never replace unavailable observations with zero to make a metric computable.

05 / RESEARCH NOTES

Wallet relationships

Represent a wallet network as G = (V, E). V contains addresses within a stated scope. An edge can represent a transfer, a funding event or another explicitly defined relationship. Directed transfer edges should retain chain, asset, amount, block, transaction reference and time; aggregated edges must disclose their aggregation rule.

Temporal analysis asks whether paths occur in a defined order or window. Funding analysis asks whether addresses share a funding source or traceable path. Neither observation, on its own, establishes that the same person controls the addresses.

Exchanges, bridges, routers, custodians and public funding services can connect unrelated users. Labels may be incomplete or incorrect, and the observation window can hide earlier relationships. A coordination hypothesis needs independent supporting evidence and alternative explanations.

06 / RESEARCH NOTES

Security architecture

Security is a set of explicit boundaries, not a numerical guarantee. The current application accepts a string for a local syntax check. It has no research API or outbound provider call.

Do not infer a contract is safe because its source is verified or because a checklist has no finding. Proxy upgrades, privileged roles, economic dependencies and incomplete visibility can change the relevant risk surface. Security review must state what was inspected and what remains unknown.

07 / RESEARCH NOTES

Research integrity

A reproducible observation should identify its chain, contract, block number and block hash. A transaction-based finding should include transaction hashes and any relevant log indexes. Preserve the retrieval timestamp separately from the onchain observation timestamp.

• Source verification: identify the provider or explorer, retrieval method and any disagreement with independent references.
• Data coverage: record time and block ranges, retrieved pages, excluded addresses, missing records and finality assumptions.
• Confidence: separate directly observed facts, inferred relationships and unsupported hypotheses. An unexplained pattern is not a calibrated confidence score.
• Reproducibility: version query parameters, denominator policy, transformations and calculation methods.
• Freshness: show the snapshot block and retrieval time so a reader can judge staleness; do not label an old snapshot live.

The workspace currently shows unavailable source and observation fields because none of these records have been collected. It does not generate evidence references or research reports.

08 / RESEARCH NOTES

Limitations

SYNAP cannot guarantee fraud detection, identify insiders, predict prices, certify contract safety or provide complete historical coverage.

Public addresses are not verified identities. Private order flow, missing archive history, offchain arrangements, contract abstractions and indexer gaps can limit visibility. Statistical anomalies can arise from ordinary operational activity, and a lack of anomalies does not establish safety.

The present release has a narrower limitation: its data providers and analytics are unavailable. Its diagrams and methodology explain a proposed research approach; they are not live findings. The interface is a research aid, not an automated investment decision or security certification.

09 / RESEARCH NOTES

Research access

Public, Research and Quant Lab are an access proposal. Holder verification, token gating, billing, monitoring and compute allocation are not implemented.

Public

Proposed basic token overview, contract metadata and available evidence. The current public interface is accessible, but its onchain data is unavailable.

Research

Proposed holder access to extended statistical and wallet-structure research. Planned; not operational.

Quant Lab

Proposed holder access to historical analysis, monitoring and compute allocation. Planned; not operational.

No token purchase, wallet signature or membership is required to view this documentation or use the current address-format checker. Future eligibility rules and resource limits would need separate implementation and verification.