SAYLOR Verify whether an airdrop, reward, NFT claim, migration, or wallet message is authentic before opening links, connecting a wallet, signing, approving, or paying.
The result you're building
A claim-verification record that establishes provenance through independent official channels, inspects the exact domain and contract/program, simulates requested actions, identifies approvals and asset movement, and uses a segregated low-value path or refuses the claim.
Use this guide when
- A wallet receives an unsolicited token, NFT, memo, URL, or claim notice.
- A social account announces eligibility or migration.
- A claim asks for signature, approval, fee, seed phrase, or software install.
Do not use it as a substitute for
- Clicking links or scanning QR codes from the unsolicited asset/message.
- Sharing a seed phrase/private key, signing opaque messages, or granting unlimited token/NFT approvals to receive a reward.
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.
- Unsolicited asset/message signature, mint/contract, sender, metadata, URL, and observation time.
- Independent official website/docs/social links reached without using the message link.
- Domain spelling/registration/TLS path, redirects, downloads, and wallet-connection behavior.
- Contract/program address, verified source/owner, requested calls/instructions, approvals, transfers, delegate/authority changes, and fees.
- Simulation, wallet diff, allowance/delegate review, revocation, and small isolated-wallet evidence.
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.
The asset itself can be the lure
A spam token/NFT name, image, memo, or metadata URL is untrusted input. Receiving it does not make its links or issuer authentic.
A signature can authorize more than login
Typed-data, transaction, delegate, permit, approval, and program instructions can move assets or grant future authority. Decode the exact payload and state change.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| Claim asks to import seed | Credential theft | Stop; verify official support guidance independently | No legitimate claim needs the wallet recovery secret. |
| Site domain nearly matches project | Phishing | Navigate from independently verified official channels and compare domain | Lookalike or compromised link may capture signatures. |
| Transaction includes token approval | Authorization | Decode spender, asset, amount, expiry, and calls | Claim may grant asset-moving authority unrelated to reward. |
| NFT metadata contains support URL | Spam content | Treat metadata as untrusted and verify mint/collection independently | Issuer controls display content but not legitimacy. |
| Simulation shows asset outflow | Drain behavior | Compare pre/post wallet balances, delegates, authorities, and accounts | Claim creates a cost or authority beyond the disclosed reward. |
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 — Do not interact with the lure
Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Record public signature/mint/contract/sender and screenshot safely; do not open embedded links, call numbers, download files, connect, sign, or burn until verified.
Read the result: Investigation begins without granting the sender more interaction.
Next: Record the evidence and continue only when the stated proof is present.
Step 02 — Find official provenance independently
Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Use a previously known bookmark, official documentation, verified repository, or independently located official account; confirm whether the claim, dates, eligibility, networks, and addresses are announced.
Read the result: At least two independent authoritative paths agree on the exact claim details.
Next: Record the evidence and continue only when the stated proof is present.
Step 03 — Verify domain and application
Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Check exact hostname, scheme, redirects, registration context as useful, official link relationship, expected wallet method, content security, and whether access pressure is manipulative.
Read the result: The claim site is reached from official sources and has no unexplained redirect/download.
Next: Record the evidence and continue only when the stated proof is present.
Step 04 — Verify contract/program and asset
Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Match chain, contract/mint, owner/program, verified source or official address, token/NFT collection, and claim distributor. Reject symbol/name-only matches.
Read the result: On-chain addresses exactly match official documentation.
Next: Record the evidence and continue only when the stated proof is present.
Step 05 — Decode and simulate every request
Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Inspect message/typed data/transaction, spender/delegate, assets, amounts, recipients, fees, account creation/closure, authorities, and pre/post state. Use read-only simulation where supported.
Read the result: No hidden asset outflow or persistent authority exists beyond explicit need.
Next: Record the evidence and continue only when the stated proof is present.
Step 06 — Use the lowest-risk execution path
Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Prefer a segregated low-value wallet, hardware confirmation, exact limited approval, official revoke path, sufficient native fee, and no unrelated valuable assets. Refuse if risk remains.
Read the result: Maximum exposure is intentionally bounded before signing.
Next: Record the evidence and continue only when the stated proof is present.
Step 07 — Verify result and clean permissions
Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Confirm reward and fees on-chain, review token approvals/delegates/session connections, revoke unnecessary authority through trusted tools, and document/report scam indicators.
Read the result: No unintended allowance, delegate, authority, session, or asset loss remains.
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.
- Unsolicited asset/message signature, mint/contract, sender, metadata, URL, and observation time.
- Independent official website/docs/social links reached without using the message link.
- Domain spelling/registration/TLS path, redirects, downloads, and wallet-connection behavior.
- Contract/program address, verified source/owner, requested calls/instructions, approvals, transfers, delegate/authority changes, and fees.
- Simulation, wallet diff, allowance/delegate review, revocation, and small isolated-wallet evidence.
Acceptance scoreboard
- Unsolicited message/asset is handled as untrusted without opening its links.
- Independent official sources confirm claim, dates, network, and exact addresses.
- Domain and redirects match official publication; no forced download or secret request exists.
- Contract/program and asset identities match on-chain and official evidence.
- Decoded/simulated request shows explicit recipients, amounts, fees, approvals, and state changes.
- Bounded execution, on-chain result, allowance/delegate/session cleanup, and reporting are complete.
Minimum handoff record
- Versioned airdrop and claim scam verification 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
- NFTs were unsolicited.
- Collection/mints are not listed by the claimed project.
- Metadata points to a lookalike domain.
- The site requests an unlimited token approval.
Decision: Treat them as spam and do not use the links or approve anything. Hide/report them through the wallet's safe UI; burn only if the wallet constructs a transparent harmless transaction and the user understands it is unnecessary.
Actions taken
- Verified the official project has no such claim.
- Recorded mint and scam domain without visiting through the wallet.
- Checked existing allowances/delegates.
- Reported/hid the spam and took no claim action.
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.
- Unsolicited message/asset is handled as untrusted without opening its links.
- Independent official sources confirm claim, dates, network, and exact addresses.
- Domain and redirects match official publication; no forced download or secret request exists.
- Contract/program and asset identities match on-chain and official evidence.
- Decoded/simulated request shows explicit recipients, amounts, fees, approvals, and state changes.
- Bounded execution, on-chain result, allowance/delegate/session cleanup, and reporting are complete.
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 |
|---|---|---|
| Claim asks to import seed | No legitimate claim needs the wallet recovery secret. | Stop; verify official support guidance independently |
| Site domain nearly matches project | Lookalike or compromised link may capture signatures. | Navigate from independently verified official channels and compare domain |
| Transaction includes token approval | Claim may grant asset-moving authority unrelated to reward. | Decode spender, asset, amount, expiry, and calls |
| NFT metadata contains support URL | Issuer controls display content but not legitimacy. | Treat metadata as untrusted and verify mint/collection independently |
Reusable handoff record
- Versioned airdrop and claim scam verification 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