SAYLOR Track authorized public wallet activity across Solana and EVM networks without confusing chain identity, internal calls, token contracts, bridge steps, confirmations, or address labels.
The result you're building
A chain-aware wallet event feed that validates network and address, defines inbound/outbound/contract/approval/bridge activity, records authoritative transaction evidence, handles finality and reorganizations, and delivers normalized alerts with raw provenance.
Use this guide when
- You monitor public wallets, treasury addresses, clients' watchlists, or domain-linked addresses.
- Events must be normalized across Solana, Ethereum, Base, or other EVM networks.
- The same hexadecimal address can exist on several EVM chains with unrelated activity.
Do not use it as a substitute for
- Assuming a label proves ownership or identity.
- Collapsing a bridge deposit and destination receipt into one transfer without correlation evidence.
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.
- Watchlist source, owner/label claim, purpose, chain/network identifiers, address, and validation time.
- RPC/indexer providers, commitment/confirmations, start checkpoint, and coverage.
- Transaction/signature/hash, block/slot, index/log/instruction, from/to, asset contract/mint, amount/raw units, fee, and status.
- Token metadata/source, internal calls, approvals, program events, bridge correlation, and counterparty labels.
- Reorg/fork, duplicate, gap, provider disagreement, spam, dust, 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.
Address format does not identify network
EVM addresses can be valid on many chains. Every record needs a CAIP-style or equivalent chain identity; Solana addresses need cluster and account ownership context.
Transfers are not the whole transaction
Approvals, delegate changes, internal calls, token-program instructions, failed transactions, fees, burns, mints, and bridge events can change risk without a simple transfer.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Same EVM address shows unexpected assets | Network selection | Verify chain ID, RPC genesis, and explorer | Monitor queried the wrong network or merged networks. |
| Alert says received but tx failed | Execution/status | Inspect receipt/status and reverted logs policy | Indexer emitted intent/log-like data without final success semantics. |
| Amount is off by powers of ten | Token metadata | Read contract/mint decimals and raw amount | Metadata is missing, stale, or from wrong asset. |
| Bridge appears as two unrelated transfers | Correlation | Match protocol message/nonce /source/destination evidence | Cross-chain legs need protocol-specific linkage and finality. |
| Dust/spam floods feed | Classification | Evaluate asset authenticity, amount, sender pattern, and user policy | Feed treats every transfer as equally meaningful. |
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 — Build a chain-qualified watchlist
Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Store network/cluster ID, validated address, label source, ownership confidence, purpose, start point, and alert policy. Keep labels as claims with provenance.
Read the result: No event exists without an explicit chain and watchlist basis.
Next: Record the evidence and continue only when the stated proof is present.
Step 02 — Verify providers and checkpoints
Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Confirm chain ID/genesis, RPC/indexer capability, finality model, current head, checkpoint, and gap recovery. Use more than one source for critical reconciliation.
Read the result: Coverage starts at a known block/slot and provider cannot silently switch network.
Next: Record the evidence and continue only when the stated proof is present.
Step 03 — Parse native and token activity
Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Capture transaction status, fees, value, calls/instructions, internal transfers where available, logs/events, approvals/delegates, mints/burns, and account changes.
Read the result: Normalized event preserves raw references and does not invent success.
Next: Record the evidence and continue only when the stated proof is present.
Step 04 — Resolve asset and amount safely
Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Validate token contract/mint, program/standard, decimals, symbol/name source, raw amount, and executable value source/time. Flag unknown/spam.
Read the result: Displayed amount can be reproduced from raw units and verified metadata.
Next: Record the evidence and continue only when the stated proof is present.
Step 05 — Handle finality and reorganization
Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Publish observed versus confirmed/final state, update or retract on reorg/fork, and deduplicate by chain transaction and subevent identity.
Read the result: Replayed blocks and finality changes produce one consistent event history.
Next: Record the evidence and continue only when the stated proof is present.
Step 06 — Correlate bridges and counterparties cautiously
Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Use protocol-specific message IDs/nonces/contracts and both-chain evidence; label exchanges/contracts/domains only with source and confidence.
Read the result: Cross-chain relationship and identity claims are explainable and qualified.
Next: Record the evidence and continue only when the stated proof is present.
Step 07 — Deliver and reconcile
Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Apply materiality/spam filters, stable alert IDs, idempotent delivery, gap reports, and periodic balance/nonce/signature reconciliation.
Read the result: Alert stream reconciles to authoritative chain state for the declared coverage window.
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.
- Watchlist source, owner/label claim, purpose, chain/network identifiers, address, and validation time.
- RPC/indexer providers, commitment/confirmations, start checkpoint, and coverage.
- Transaction/signature/hash, block/slot, index/log/instruction, from/to, asset contract/mint, amount/raw units, fee, and status.
- Token metadata/source, internal calls, approvals, program events, bridge correlation, and counterparty labels.
- Reorg/fork, duplicate, gap, provider disagreement, spam, dust, and delivery tests.
Acceptance scoreboard
- Every watch entry and event binds chain/network, address, source, purpose, and label confidence.
- Provider chain identity, checkpoint, finality, and coverage are verified.
- Transaction success, fees, transfers, calls/instructions, approvals, and subevents preserve raw evidence.
- Asset contract/mint, decimals, raw/display amount, and value time are reproducible.
- Reorg/fork/replay/gap/duplicate/bridge/spam behavior is explicit.
- Alerts reconcile to authoritative balances and activity across the declared window.
Minimum handoff record
- Versioned cross-chain wallet activity 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
- The address format is valid on both chains.
- Provider request omitted an explicit chain ID in stored metadata.
- Token symbol 'USDC' was accepted without contract address.
- Explorer link defaults to Ethereum.
Decision: The record is unusable because network and asset contract are not bound. Qualify every event by chain ID and contract, then rebuild affected alerts.
Actions taken
- Stored chain ID/genesis with every provider response.
- Validated USDC contract per chain and raw decimals.
- Generated network-specific explorer links.
- Added wrong-network canary 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.
- Every watch entry and event binds chain/network, address, source, purpose, and label confidence.
- Provider chain identity, checkpoint, finality, and coverage are verified.
- Transaction success, fees, transfers, calls/instructions, approvals, and subevents preserve raw evidence.
- Asset contract/mint, decimals, raw/display amount, and value time are reproducible.
- Reorg/fork/replay/gap/duplicate/bridge/spam behavior is explicit.
- Alerts reconcile to authoritative balances and activity across the declared window.
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 |
|---|---|---|
| Same EVM address shows unexpected assets | Monitor queried the wrong network or merged networks. | Verify chain ID, RPC genesis, and explorer |
| Alert says received but tx failed | Indexer emitted intent/log-like data without final success semantics. | Inspect receipt/status and reverted logs policy |
| Amount is off by powers of ten | Metadata is missing, stale, or from wrong asset. | Read contract/mint decimals and raw amount |
| Bridge appears as two unrelated transfers | Cross-chain legs need protocol-specific linkage and finality. | Match protocol message/nonce/source/destination evidence |
Reusable handoff record
- Versioned cross-chain wallet activity 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