A credible signal starts with a verifiable data path.
From a public chain event to a useful alert, every transformation should be inspectable.
This page describes a proposed architecture for Sinkers, not infrastructure that is currently running. A production blockchain intelligence platform needs dependable RPC access, event indexing, classification rules, observability, and careful handling of incomplete data. None of those feeds are connected to this preview.
BNB Smart Chain as the initial focus
BNB Smart Chain exposes blocks, transactions, receipts, and contract logs through JSON-RPC endpoints. A monitoring service can subscribe to new blocks or backfill historical ranges, then decode selected events from verified contract interfaces. Provider rate limits, reorganizations, and inconsistent availability need explicit handling.
The chain choice defines the scope of early coverage. It does not imply that every token, pool, or contract is supported. A product should publish which contracts and event families it indexes and how it catches up after outages.
Move from raw events to traceable records
A data pipeline typically reads block headers and receipts, identifies relevant logs, validates their chain and contract addresses, and normalizes them into records. Each record should preserve transaction hash, log index, block number, and source so a displayed observation can be independently checked.
Backfills and live ingestion must converge without duplicate events. Reorganization handling should mark provisional observations and later reconcile them when chain finality advances. The preview has no such pipeline, and no current-chain values are shown.
Derived labels need rules and provenance
A raw transfer log is a low-level fact; labels such as swap, liquidity change, or wallet cluster are derived. A classification layer can combine known pool registries, event signatures, token metadata, and transaction traces, but each added assumption creates uncertainty.
Rules should be versioned and explainable. If a method changes, analysts need to know which results were produced by which version. The interface should keep the raw event available so a user can challenge the interpretation instead of treating it as ground truth.
Anomaly detection should be conservative
Anomaly detection compares current behavior with an explicit baseline. For token markets, useful baselines may vary by activity, pool size, time of day, and volatility. A threshold that is appropriate for one asset may be noisy or insensitive for another.
Any future detector must be evaluated against historical examples, false positives, missed events, and data gaps. It should state that an alert identifies a pattern rather than predicts a price outcome. See Dump Detector for the intended user-facing explanation.
Keep interfaces and delivery paths secure
A future API could expose documented, rate-limited read endpoints for supported assets and events. Inputs such as chain IDs and contract addresses should be validated, errors should be structured, and upstream credentials should remain server-side. Public endpoints should not reveal provider keys or internal infrastructure details.
Notification delivery—such as email or a community bot—should let users choose what they receive and provide a clear unsubscribe path. A Telegram integration is a future possibility, not a configured service. Avoid asking for unnecessary wallet permissions just to read public data.
The current build is a website prototype
The current deliverable includes educational content, navigation, a demo dashboard, and a client-side pool simulator. It does not include PostgreSQL-backed accounts, RPC ingestion, an event indexer, a production API, WalletConnect, Telegram notifications, or a live analytics engine.
That separation is deliberate: the interface does not fabricate live monitoring or security claims. The Roadmap labels future work as planned, and Documentation explains the boundaries of this preview.
Good questions deserve clear answers.
These notes reflect the current prototype status. For product details, follow the linked guides and their stated limits.
Is the data pipeline operational?
No. RPC, indexing, and production analytics services have not been configured.
Does the app use PostgreSQL today?
No database-backed feature is connected in this preview. Persistent accounts and alert history are not implemented.
Which chain is supported?
The product concept focuses on BNB Smart Chain; this preview does not query it live.
THE INTELLIGENCE BEHIND EVERY MARKET SIGNAL.
Stay ahead by staying curious. Verify the event, question the interpretation, and keep the limits in view.