SAYLOR The result you are building
Finished Result:
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.
Stop Before Proceeding:
Stop immediately if the claim requests seed/private key, recovery phrase, remote access, secret key file, unknown software, unlimited approval, transfer of valuable assets, or a rushed payment. A missed airdrop is cheaper than a drained wallet.
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
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
Claim asks to import Credential Stop; verify official support No legitimate claim needs the wallet recovery secret.
seed theft guidance independently
Site domain nearly Phishing Navigate from independently Lookalike or compromised link may capture signatures.
matches project verified official channels and
compare domain
Transaction includes Authorization Decode spender, asset, Claim may grant asset-moving authority unrelated to reward.
token approval amount, expiry, and calls
NFT metadata Spam content Treat metadata as untrusted Issuer controls display content but not legitimacy.
contains support URL and verify mint/collection
independently
Simulation shows Drain behavior Compare pre/post wallet Claim creates a cost or authority beyond the disclosed reward.
asset outflow balances, delegates,
authorities, and accountsStep-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 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.
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.
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.
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.
Procedure continued 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.
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.
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.
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 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
Starting Problem:
Three NFTs appear in a wallet, each promising a reward at a URL in the image.
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.
Proof Of Completion:
Wallet assets and authorities remain unchanged; the scam domain/collection is documented; no credential, signature, approval, or payment was provided.
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 Stop; verify official support guidance independently recovery secret.
Site domain nearly matches Lookalike or compromised link may Navigate from independently verified official channels and project capture signatures. compare domain
Transaction includes token Claim may grant asset-moving Decode spender, asset, amount, expiry, and calls approval authority unrelated to reward.
NFT metadata contains Issuer controls display content but not Treat metadata as untrusted and verify mint/collection support URL legitimacy. 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.
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://consumer.ftc.gov/articles/what-know-about-cryptocurrency-and-scams
- https://www.cisa.gov/secure-our-world/recognize-and-report-phishing
- https://ethereum.org/security/