Programmable

Index only when you need discovery

Point verification needs an Ethereum provider, the manifest and the Router ABI. Continuous event indexing is optional.

If your product already has a token address or pool ID, use the point-verification guide. Build an indexer when you need a complete feed of new Router-stamped launches.

Start at the published block

Verify the live Router binding before reading logs. Ignore events from every other emitter.

Network: Ethereum mainnet · chainId 1
Router: 0x8622DD5bAb44185f2A458ac90384Ac99248f8d56 — opens Etherscan in a new tab
Start block: 25717612
End block: open
Explicit-block finality: At least 64 confirmations

Resolve these values from the live manifest. Also verify the Router runtime, immutable bindings, hosted ABI and ABI digest before the backfill begins. Remote RPC URLs must use HTTPS; plain HTTP is accepted only for loopback development endpoints.

Treat events as candidates

Filter by the exact Router address and full event topics. Logs help you discover a launch; getter verification establishes provenance.

Launch Stamp Router discovery events
Event	Full signature	topic0
ProgrammableLaunchStampedV1	`ProgrammableLaunchStampedV1(bytes32,address,address,address,bytes32,bytes32)`	`0x6cf479a102f1eebc9244f48f8d68f6aa52b4c5a4516318df58ba46614a5b14f2`
ProgrammableLaunchRouteStampedV1	`ProgrammableLaunchRouteStampedV1(bytes32,uint8,bytes32,bytes32,bytes32)`	`0x45e7cc355b63ca67d6278a0d8d23470ce2a0741a9c60283d7dee712df7a877a5`
ProgrammableComponentStampedV1	`ProgrammableComponentStampedV1(bytes32,address,uint8,bytes32)`	`0x8147265e7396d6400cee8d049456a1f7438fdfbe2a7c81c976d51ba67e52ff4b`

Hash the exact downloaded ABI bytes and match the manifest digest. From that byte-verified ABI, derive each full event signature, topic0, and the indexed input names in their published order. If any event descriptor differs from the manifest, return INDETERMINATE and do not ingest the log.

Backfill, verify, then follow live

Read bounded eth_getLogs chunks from 25717612 through a finalized boundary.
Require the exact Router emitter and published topic signatures, after deriving the byte-verified ABI closure: full signature, topic0, and indexed input names in order. A mismatch is INDETERMINATE; do not ingest the log. Correlate the three event types by launchId.
Reproduce every candidate with launchStamp(bytes32) and the identity-specific token or pool lookup at the same canonical block.
Accept the launch only when the Router binding, record, launch kind, identity and required proof checks succeed.
Begin polling or subscription from an overlapping checkpoint so the backfill and live follow have no gap.

Advance checkpoints only through finality

Keep an overlap between the stored checkpoint and the next query. Replay that overlap on every run.

Deduplicate identical block, transaction and log coordinates.
Prefer EIP-1898 reads with requireCanonical: true.
After a reorg, rewind to the last common finalized checkpoint and replay.
Respect endBlock if a future manifest retires this Router.
Keep ORPHANED as an event-observation state. It is not a point-verification result.

Store enough data to replay

A minimal durable index keeps the source coordinates, the verification block and the facts your product displays.

Event coordinate: Block number and hash, transaction hash and index, and log index.
Correlation: Launch ID, event topic and the exact Router address.
Verification: Canonical block number and hash, result state, launch kind and the token or pool identity you verified.
Checkpoint: The last finalized block number and hash.