SAYLOR Detect and normalize new Solana token and market events with source, slot, signature, authority, liquidity, confidence, deduplication, and delivery evidence.
The result you're building
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.
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
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Alert has mint but no market | Event definition | Inspect program instructions and executable pool/curve state | Mint exists but no tradeable launch has been proven. |
| Same launch alerts repeatedly | Dedup/identity | Compare signature, instruction index, and logical launch key | Provider reconnect/replay lacks deterministic event identity. |
| WebSocket misses launches | Gap recovery | Compare processed slots and backfill signatures/blocks | Disconnect or provider filtering created an unobserved range. |
| Provider labels wrong creator | Attribution | Trace signer, funding, account creation, and program semantics | Convenient account field is not necessarily the economic creator. |
| Alert arrives after price move | Latency/enrichment | Break slot-to-receive-to-parse-to-deliver spans | Provider lag or blocking enrichment dominates delivery. |
Step-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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
Step 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.
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
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.
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 been proven. | Inspect program instructions and executable pool/curve state |
| Same launch alerts repeatedly | Provider reconnect/replay lacks deterministic event identity. | Compare signature, instruction index, and logical launch key |
| WebSocket misses launches | Disconnect or provider filtering created an unobserved range. | Compare processed slots and backfill signatures/blocks |
| Provider labels wrong creator | Convenient account field is not necessarily the economic creator. | Trace signer, funding, account creation, and program semantics |
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. |
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