Vision & scope
NotifyCool plans to build a decentralized transfer notification network with on-demand monitoring and public results. Task sponsors define watches and fund budgets. Independent nodes observe and verify source-chain events, then record confirmed results in NotifyCool blocks.
The network confirms matching token transfers. Order fulfillment, payment completion, payer identity and business accounting remain application responsibilities. Payment funds stay on the source chain; NotifyCool does not custody them.
- Simple integration: V1 plans HTTPS webhooks without requiring a NotifyCool node.
- Independent verification: public results, regular-node subscriptions and receipt proofs.
- Recoverable consumption: recorded positions, consumer cursors and replay within retention.
On-demand watches
A Watch specifies the source chain, token contract, address set, direction, minimum amount, start block, finality policy, expiry and budget. The network is responsible only for active, funded tasks. Changes require an explicit configuration version and effective position.
V1 proposes at most two explicitly named EVM chains with tested standard token contracts, selected through pilot requirements. Support is identified by chain ID and contract address, never just a token name or symbol.
- Create, fund, update, pause, resume, expire and close tasks.
- Report verified ranges, backlog and gaps; distinguish no match from unscanned or paused work.
- Automatic coverage of all chains, all tokens, arbitrary events, NFTs and other chain families is outside V1.
Verification, receipts & finality
Observers discover candidate events. Verifiers independently check source-chain facts, task versions and confirmation conditions. Consensus checks authorization, deduplication, fee caps and available budget, then atomically records the receipt and charge.
Receipts distinguish source-chain confirmation from NotifyCool finality. The normal path is observed → source_confirmed → finalized. Pre-confirmation reorgs discard orphaned candidates. If an accepted fact later becomes invalid, an appended correction references the original receipt.
Security depends on the chosen verification mechanism, committee honesty assumptions and data sources. Multiple signatures alone are not a security proof. Receipt proofs alone cannot show that no events were omitted.
- Receipts identify chains, blocks, transactions, event positions, contracts, addresses and integer amounts in smallest units.
- Task and policy versions, network positions, fee records and correction relationships stay explicit.
- No untested fixed confirmation latency or source-chain reorg loss compensation is promised.
Webhooks & node integration
Gateways consume finalized blocks, durably queue matching receipts, then deliver them asynchronously through HTTPS POST. Endpoint failures must not block consensus or alter confirmation results. Regular nodes can sync and subscribe to the same public results.
Versioned JSON includes schema_version, event_id, watch_id, event type and network position. Each endpoint uses an independent signing key. HMAC SHA-256 over the timestamp, delivery ID and raw body is proposed; the final signature specification remains to be settled.
Webhook signatures authenticate delivery. Verifying network acceptance additionally requires receipt inclusion proofs, finality materials and trusted checkpoints, with their associated trust assumptions.
- Expect duplicates and out-of-order events. Deduplicate with stable event_id values and process corrections separately.
- Return 2xx after signature verification and durable local queuing, then perform business processing. A 2xx is not proof of completed accounting.
- Bounded exponential retries, failure records, authenticated redelivery and cursor recovery are planned. Retries do not repeat event-confirmation charges.
- Callback URLs, signing keys and authentication settings stay with the selected gateway, outside public blocks.
Fees, authorization & budgets
Task sponsors pay for sustained network work. Existing public receipts can be read, and local queries on a regular node do not automatically incur protocol gas. Charges require verifiable payer authorization; arbitrary source-chain senders or recipients cannot be charged.
The proposed structure includes task-operation, monitoring-period and event-processing fees. Gateway quotas and service pricing are disclosed separately. The six-month data obligation requires ongoing funding. Mainnet fee assets, rates and reward distribution remain undecided.
- Control spending with per-event caps, periodic budgets, event quotas and pause mechanisms.
- Periodic billing should track verifiable coverage. Budget exhaustion and recovery positions must be explicit.
- Test units have no economic value. V1 does not require a tradable token and makes no investment-return promises.
Six-month history & privacy
Historical block bodies, event details and indexes have a default six-month rolling window starting at NotifyCool consensus confirmation. Pruning must satisfy protocol safety conditions. Current accounts, active tasks, scan progress, replay protection and necessary security metadata follow separate lifecycles.
New nodes verify snapshots using trusted recent checkpoints and then continue syncing. This adds explicit bootstrap trust assumptions; it is not equivalent to replaying all history from genesis. Queries outside retention must clearly report pruned history.
V1 proposes public watched addresses, matching rules and transfer results. Merchant identity and order data stay within the application. Pruning does not provide anonymity or force participants to erase saved public copies.
- Export receipts, proofs, relevant headers, authentication material and accepted trust evidence within retention for long-term audits.
- Webhook queues, delivery logs and retry windows have separate lifetimes. Six months of history does not mean six months of retries.
- Permanent archival, hidden source-chain transactions and private watch relationships are not promised.
Delivery roadmap & open decisions
The roadmap moves through a protocol prototype, multi-operator testnet, payment pilots and V1 mainnet readiness. Each stage advances on demonstrated integration, recovery and cost evidence. The project remains in design.
Before mainnet, the project must finalize supported chains and assets, consensus and admission, fee assets and rates, task lifecycles, pruning rules, disputes and corrections, governance and upgrades, measured performance targets and delivery-verification specifications.
- Verify that duplicate reports cannot repeat settlement, and wrong-chain or nonmatching events cannot create valid receipts.
- Test reorgs, shared data-source failures, exhausted budgets, omissions, partitions and unavailable data.
- Validate signatures, key rotation, reordered corrections, gateway switching and recovery within retention.
- The six-month storage obligation and recovery capability require real operation; simulation alone is insufficient.