SAYLOR The result you are building
Finished Result:
A launch-monitor pipeline that defines what counts as a launch, observes multiple on-chain event paths, backfills gaps, resolves token and pool identity, enriches risk without delaying the base alert, and proves no duplicate or silently lost accepted events.
Use this guide when
- You monitor token creation, Pump-style launches, pools, migration, liquidity, or first trade.
- Wallets with domains or known identities trigger alerts.
- A client needs real-time plus replayable evidence.
Do not use it as a substitute for
- Calling every mint a tradeable launch.
- Presenting a fast alert as endorsement, safety proof, or guaranteed opportunity.
Before you change anything
Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- Cluster/genesis, RPC/WebSocket/indexer providers, commitment, program IDs, and versions.
- Launch definition: mint, metadata, curve/market/pool creation, liquidity, migration, or first trade.
- Slot, block time, signature, instruction/event index, account keys, mint, pool, quote asset, and creator.
- Authorities, token program/extensions, supply/decimals, liquidity, domains, labels, and enrichment times.
- Checkpoint, gap/backfill, fork, duplicate, provider disagreement, latency, and delivery tests.
Stop Before Proceeding:
Stop or mark unknown when chain, program, account ownership, mint, or event finality cannot be verified. Never request a user's seed phrase or sign a transaction to monitor public events.
Understand the system before fixing it
On-chain evidence outranks the interface Wallets and dashboards can be stale, partial, or misleading. Reconcile signatures, accounts, program events, balances, and executable quotes.
Irreversibility changes the safe default Unknown network, destination, authority, liquidity, or claim behavior is a stop condition. Use low-value tests and explicit maximum loss.
Launch is a defined state transition Mint creation, metadata, bonding-curve creation, pool creation, migration, and first executable market are different events. Publish the exact one detected.
Speed and completeness trade off Send a minimal evidence-backed base event quickly, then attach versioned enrichment rather than blocking on slow or unreliable providers.
Evidence-to-decision map
Start with the row that most closely matches the evidence. The first test isolates a layer; it is not permission to
make every available change.
Evidence Likely layer First decisive check What the result means
Alert has mint but no Event Inspect program instructions Mint exists but no tradeable launch has been proven.
market definition and executable pool/curve
state
Same launch alerts Dedup/identity Compare signature, instruction Provider reconnect/replay lacks deterministic event identity.
repeatedly index, and logical launch key
WebSocket misses Gap recovery Compare processed slots and Disconnect or provider filtering created an unobserved range.
launches backfill signatures/blocks
Provider labels Attribution Trace signer, funding, account Convenient account field is not necessarily the economic creator.
wrong creator creation, and program
semantics
Alert arrives after Latency/enrich Break slot-to-receive-to-parse-t Provider lag or blocking enrichment dominates delivery.
price move ment o-deliver spansStep-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
01 Define launch states and programs Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: List supported cluster, token programs/extensions, launchpad/AMM programs, and exact state transitions for mint, curve, pool, migration, liquidity, and first trade. Version the definitions.
Read the result: Every alert names one deterministic event type and supporting instruction/state.
Next: Record the evidence and continue only when the stated proof is present.
02 Subscribe with durable checkpoints Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Use logs/accounts/blocks/signatures as appropriate, record provider, commitment, slot, parent/root, signature, instruction index, receive time, and last contiguous checkpoint.
Read the result: Reconnect resumes from a known slot without assuming continuity.
Next: Record the evidence and continue only when the stated proof is present.
03 Parse and validate identity Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Verify program ownership/discriminators, mint/token program, decimals/supply, pool/curve accounts, quote asset, creator/funder evidence, and metadata addresses. Reject malformed associations.
Read the result: Mint and market identities can be independently reproduced from the transaction/state.
Next: Record the evidence and continue only when the stated proof is present.
04 Deduplicate and handle forks Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Use chain-aware event keys, store first observation and updates, merge provider duplicates, and update/retract unfinalized events under a documented commitment policy.
Read the result: Reconnect, replay, and provider fan-in produce one logical event history.
Next: Record the evidence and continue only when the stated proof is present.
Procedure continued 05 Backfill gaps and reconcile providers Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Detect slot/signature gaps, fetch blocks or program history, compare providers, and mark unrecoverable ranges. Do not label a feed complete without coverage evidence.
Read the result: Accepted monitoring windows have contiguous or explicitly missing coverage.
Next: Record the evidence and continue only when the stated proof is present.
06 Enrich asynchronously with timestamps Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Attach authorities, token extensions, metadata, liquidity, top holders, domains, socials, and risk signals with source/observed time/confidence. Keep base event immutable.
Read the result: Slow enrichment cannot delay or rewrite the original launch evidence silently.
Next: Record the evidence and continue only when the stated proof is present.
07 Deliver and test end to end Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Use stable alert IDs, idempotent recipient delivery, retries with reconciliation, latency metrics, and replay endpoints. Test disconnect, fork, duplicate, provider lag, malformed event, and backlog.
Read the result: Each accepted event is delivered once per recipient policy or visibly terminal with full provenance.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet Evidence record Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- Cluster/genesis, RPC/WebSocket/indexer providers, commitment, program IDs, and versions.
- Launch definition: mint, metadata, curve/market/pool creation, liquidity, migration, or first trade.
- Slot, block time, signature, instruction/event index, account keys, mint, pool, quote asset, and creator.
- Authorities, token program/extensions, supply/decimals, liquidity, domains, labels, and enrichment times.
- Checkpoint, gap/backfill, fork, duplicate, provider disagreement, latency, and delivery tests.
Acceptance scoreboard
- Launch, pool, migration, liquidity, and trade states are defined by supported program versions.
- Every event has cluster, provider, commitment, slot, signature, instruction, accounts, and receive times.
- Program/account/mint/pool identity validates independently.
- Dedup, fork, reconnect, overlap, and multi-provider behavior are deterministic.
- Contiguous coverage or explicit gap evidence is reported.
- Base alert, asynchronous enrichment, delivery, latency, replay, and failure state are auditable.
Decision rule SHIP / AUTOMATE GATE Proceed only when every required acceptance check is supported by direct evidence, rollback is available, and the remaining risk is explicitly owned. Unknown is not a pass.
Minimum handoff record
- Versioned solana token launch monitor scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Starting Problem:
A monitor pings the same Pump-style migration three times after an RPC reconnect.
Evidence collected
- All alerts share the same transaction signature.
- Instruction indexes are not stored.
- WebSocket replay overlaps the last processed slot.
- Dedup key uses receive time and mint only.
Decision Use signature plus instruction/event identity and a logical migration key; keep overlapping replay but make consumption idempotent.
Actions taken
- Stored contiguous slot checkpoint and overlap window.
- Derived deterministic chain event ID.
- Merged enrichment updates into one alert record.
- Added reconnect and multi-provider duplicate tests.
Proof Of Completion:
Repeated replay and provider fan-in produce one migration event, one recipient delivery, and a traceable update history with no coverage gap.
Why this example matters The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- Launch, pool, migration, liquidity, and trade states are defined by supported program versions.
- Every event has cluster, provider, commitment, slot, signature, instruction, accounts, and receive times.
- Program/account/mint/pool identity validates independently.
- Dedup, fork, reconnect, overlap, and multi-provider behavior are deterministic.
- Contiguous coverage or explicit gap evidence is reported.
- Base alert, asynchronous enrichment, delivery, latency, replay, and failure state are auditable.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear What happened What it usually means Next safe move
Alert has mint but no market Mint exists but no tradeable launch has Inspect program instructions and executable pool/curve state been proven.
Same launch alerts repeatedly Provider reconnect/replay lacks Compare signature, instruction index, and logical launch key deterministic event identity.
WebSocket misses launches Disconnect or provider filtering created Compare processed slots and backfill signatures/blocks an unobserved range.
Provider labels wrong creator Convenient account field is not Trace signer, funding, account creation, and program semantics necessarily the economic creator.
Reusable handoff record
- Versioned solana token launch monitor scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
Field Type Requirement
target object Versioned environment, resource, identity, or workflow being evaluated.
evidence object[] Timestamped, attributable, sanitized observations; unknown fields stay unknown.
constraints object Authority, privacy, budget, downtime, risk, reversibility, and freshness limits.
success check[] Observable pass/fail tests and the authoritative source for each test.
Returned output
Field Type Requirement
diagnosis object Likely layer, supporting and conflicting evidence, alternatives, and confidence.
plan step[] Ordered bounded actions with owner, risk, expected proof, and stop condition.
verification check[] Observed pass/fail/unknown results, not inferred success from command exit alone.
handoff object Sanitized evidence record, recovery state, remaining risk, and next review trigger.
Agent refusal and escalation rules
•
Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
•
Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
•
Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
•
Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule
Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low
confidence; a controlled test that isolates the layer and passes verification can support high confidence.Official reference starting points
- https://solana.com/docs/rpc/websocket
- https://solana.com/docs/core/transactions
- https://solana.com/docs/rpc#configuring-state-commitment