brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
quicknode-webhooks-eventsBuild an authenticated, idempotent QuickNode Webhooks or Streams receiver with bounded acknowledgement, replay safety, and reorganization handling. Use when delivering onchain events to HTTP or durable destinations. Trigger with: "receive QuickNode webhooks", "secure a QuickNode Stream", "handle duplicate blockchain events".
Independent GitHub snapshot · Automated classification · Original documentation governs
name: quicknode-webhooks-events description: 'Build an authenticated, idempotent QuickNode Webhooks or Streams receiver with bounded acknowledgement, replay safety, and reorganization handling. Use when delivering onchain events to HTTP or durable destinations. Trigger with: "receive QuickNode webhooks", "secure a QuickNode Stream", "handle duplicate blockchain events".' allowed-tools: Read, Grep, Write, Edit version: 2.0.0 argument-hint: '[product-dataset-and-destination]' model: inherit effort: high license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:
Choose Webhooks for template-driven notifications or Streams for programmable, historical, and multi-destination pipelines. Both require authenticity, fast acknowledgement, idempotency, and explicit chain-reorganization behavior.
Authenticate event delivery with the generated HMAC security token and verify the signature over the unmodified request bytes before parsing. For Streams, add mTLS when its trust model is required. Keep endpoint tokens and Admin API keys out of receiver configuration because they authenticate different QuickNode surfaces.
Use Read and Grep to identify filtering, backfill, batching, destination, and reorg needs. Streams supports filter functions and destinations such as webhook, object storage, PostgreSQL, and Kafka; do not paste a Webhooks payload assumption into Streams.
Use the product's generated security token for HMAC verification. Compare signatures in constant time over the exact received bytes. For Streams, consider mTLS and a private-CA configuration where appropriate.
Use Write or Edit to cap body size, decode gzip only when configured, validate content type, verify authenticity before parsing, enqueue durably, and return 2xx within the configured timeout.
Derive a stable key from product metadata plus chain, block hash, transaction or log position, and destination. Persist receipt before acknowledging; do not deduplicate only by transaction hash when multiple logs are possible.
Treat delivery as at-least-once at the receiver. Streams processes batches sequentially, retries according to configuration, and can pause after maximum failures. Multiple destinations can replay to ones that already succeeded.
Configure and test the product's reorg behavior. Make downstream state reversible or versioned and keep a cursor that can be replayed from a documented block.
Use Read and Grep for receiver discovery and Write/Edit for verification, queueing, idempotency, and tests. Do not create or mutate a production Stream/Webhook without an explicit checkpoint.
A Stream receiver verifies HMAC over raw bytes, writes the batch and identity to a queue transactionally, returns 204, and processes business effects asynchronously. A redelivered batch is acknowledged without duplicating effects.
| Failure | Response |
|---|---|
| Signature fails | Reject before parsing and retain only sanitized metadata |
| Receiver exceeds timeout | Move work behind the durable acknowledgement boundary |
| Stream pauses | Repair the failing destination, then replay from the recorded cursor |
| Reorg invalidates an event | Apply the compensating state transition by block identity |