LitGuard — FAQ

What each tool does, how to use it, what it's based on. All tools work against LiteForge testnet (chain 4441).

Transaction Debugger — /debug

What it does

Paste the hash of an already-mined transaction — get a call tree: who called whom, how much gas was spent at each level, and — if the transaction reverted — a human-readable revert reason instead of a raw hex error code.

How to use

1. Go to /debug.
2. Paste the transaction hash (0x... 64 hex chars) from LiteForge.
3. Click "Trace".

What you'll see

• Call tree: type (CALL/STATICCALL/DELEGATECALL), recipient address, function selector, gas.
• If something reverted — the reason: a string from require/revert("..."), Panic decoded (overflow, out-of-bounds, etc.), a decoded custom error (if the contract's ABI is known), or an honest "unknown error 0xselector" if nothing matched.
• Decoded events (Transfer/Approval/ApprovalForAll), if the transaction emitted any.

What it's based on

debug_traceTransaction with callTracer (plus tracerConfig.withLog for logs) directly against LiteForge's public RPC node. ABI is pulled from Blockscout for contracts with verified source — without it, custom errors stay undecoded, only the well-known ones resolve (Error(string), Panic(uint256)).

Limitations

• Only works with already-mined transactions (for hypothetical calls — /preview).
• Without contract verification, custom errors stay as a selector, not text.

Transaction Preview — /preview

What it does

Same call tree and error parsing as the debugger, but before sending the transaction to the network. Plus: what would change as a result of the call — balances, new approvals, token/NFT transfers.

How to use

1. Go to /preview.
2. Fill in: from (optional), to (required), calldata (0x..., optional), value (in wei, hex, optional).
3. Click "Simulate".

What you'll see

• An "Effects" block: native currency (zkLTC) balance changes for affected addresses, list of decoded events (who approved what to whom, who transferred what to whom).
• Call tree — same as in the debugger.

What it's based on

debug_traceCall (callTracer, for the call tree) and prestateTracer with diffMode: true (for storage/balance diff) — both pinned to the same block number (important: on LiteForge a new block lands every ~0.2s, so two independent requests with "latest" can land on different blocks and give contradictory results — this used to be a real bug, now fixed).

Limitations

• State-override scenarios (e.g. "what if I had a bigger balance") aren't implemented in the UI — the engine supports it via eth_call with state override, but there's no widget for it (see safe.md, deferred until actually needed).
• The forecast is accurate for the network's state at call time — if state changes before the real transaction is sent, the result may differ.

Airdrop / Sybil Check — /airdrop

What it does

Paste a wallet address — get a 0-100 score of "how bot-like this activity looks" plus a list of specific findings (flags). Does not say "you will/won't get the airdrop" — only a probabilistic signal based on activity patterns.

How to use

1. Go to /airdrop.
2. Paste the wallet address.
3. Click "Check".

What you'll see

• Score 0-100 (higher = looks more automated).
• Metrics: transaction count, wallet age (within the scanned window), number of unique contracts/functions, share of reverted transactions, median interval between transactions.
• Flags: what specifically triggered (e.g. "activity concentrated on a single contract", "transactions every 3 seconds — faster than a human can click").

What it's based on

Wallet transaction history via Blockscout (up to the last 250). The main signal is median interval between transactions: <30s is a strong bot indicator, <300s is a weak one. Scoring originally leaned on "contract/method diversity" (the idea being bots hit one target, humans hit many), but checking against real addresses showed many "diverse" wallets were actually multi-pool trading bots. Call frequency turned out far more reliable than target diversity.

Limitations

• Only looks at the last 250 transactions — wallet age and stats may not reflect the full history of very old/active addresses.
• A heuristic, not proof. Report wording is deliberately probabilistic.

Approvals Manager — /approvals

What it does

Paste a wallet address — get a list of currently active ERC20/NFT approvals (approve/setApprovalForAll) and revoke all of them in a single transaction.

How to use

1. Go to /approvals.
2. Paste the wallet address, click "Scan".
3. If active approvals are found — click "Revoke All". A browser wallet (MetaMask/Rabby etc.) opens to confirm one transaction that zeroes them all out at once.

What you'll see

• A list: token → spender, allowance amount (or "unlimited" for max-uint256); or token/collection → operator for NFT all-tokens approvals.
• A bulk revoke button.

What it's based on

Approval candidates come from the wallet's own outgoing transaction history (same data used for /airdrop) — looking for approve/setApprovalForAll calls by selector, decoding spender/operator. Candidates are then verified with a live read of allowance()/isApprovedForAll() via Multicall3 (one batched request) — an approve event doesn't mean the allowance is still active, it could have been revoked or replaced since. Revoke is a single transaction to Multicall3.aggregate3, calling approve(spender, 0)/setApprovalForAll(operator, false) for each found asset.

Limitations

• Doesn't index the whole chain — if someone approved a token to your wallet without going through your own wallet's history, that approval won't be found. For 99% of cases (approve is always sent by the owner) this isn't an issue.
• The "Revoke All" button needs a browser wallet (window.ethereum) installed — without it, only the list view works.

Contract Risk Scanner — /scanner

What it does

Paste a contract address — get a 0-100 risk score and a list of specific findings: whether selfdestruct is present, whether there's an unrestricted mint (not just by text match — verified with a live call from an unrelated address), whether it's an upgradeable proxy with an admin held by a plain wallet (EOA) instead of a multisig, whether blacklist patterns show up.

How to use

1. Go to /scanner.
2. Paste the contract address.
3. Click "Scan".

What you'll see

• Score 0-100, a "source verified" / "source NOT verified" tag.
• A list of flags with severity (high/medium/low/info) and explanation.
• A no-findings flag if nothing triggered — this doesn't mean "the contract is safe", it means "these specific patterns weren't found".

What it's based on

Two layers of checks:

• Text heuristics on source (verified contracts only, via Blockscout): selfdestruct(, mint without onlyOwner/onlyRole/AccessControl nearby (checked against being a real function body, not an interface declaration — this caught and fixed a real false positive on UniswapV2Router02), blacklist patterns.
• Live checks (any contract, verified or not): reading EIP-1967 storage slots (implementation/admin) — if it's a proxy and the admin turns out to be a plain wallet (EOA) rather than a multisig/timelock, that's high risk; and simulating a mint call from an unrelated address via the debugger/preview engine — a successful call is hard proof of an open mint, while a revert proves nothing (could be access control, could just be a maxed-out limit).

Limitations

• No live feed of new deployments (who just deployed) — the scanner only works on-demand for a specific address, it doesn't monitor the chain continuously.
• Text heuristics only work for verified contracts — for everything else, only the live checks apply (proxy slots, open-mint).
• no-findings means the absence of specific patterns, not a safety guarantee.

Signature Preview — /sign-preview

What it does

Paste an EIP-712 typed-data payload (the JSON a dApp asks a wallet to sign via eth_signTypedData_v4) — get a plain-English explanation of what authority it grants, to whom, and for how long, plus flags for anything suspicious. This targets the biggest gap the other five tools don't cover: modern drainers (Inferno, Pink Drainer and clones) mostly steal funds through signatures, not transactions — no gas, no on-chain footprint until the signature is actually used, and wallets often render the payload as an unreadable blob.

How to use

1. Go to /sign-preview.
2. Paste the full typed-data JSON (domain, primaryType, message — the same object a dApp passes to eth_signTypedData_v4) that a site is asking you to sign.
3. Click "Analyze".

What you'll see

• A one-line summary of what the signature actually does (e.g. "grants spender X the right to repeatedly pull up to Y of token Z, until revoked or expired").
• Flags: spender is a plain wallet instead of a contract, amount/expiration is effectively unlimited, wrong chain ID in the domain, or — most important — a Permit2-shaped payload whose verifyingContract is NOT the real canonical Permit2 address (a lookalike contract impersonating Permit2).

What it's based on

Recognizes the payload by primaryType and message shape: ERC-2612 Permit (and the DAI-style holder/allowed variant), Permit2's PermitTransferFrom/PermitBatchTransferFrom (one-time pulls) and PermitSingle/PermitBatch (ongoing allowances — the more dangerous Permit2 flavor, functionally equivalent to approve() but granted via signature instead of a transaction), and Seaport OrderComponents (NFT marketplace orders). Canonical Permit2 address (confirmed deployed on LiteForge) is hardcoded for the impersonation check; EOA-vs-contract check for the spender reuses a live eth_getCode call.

Limitations

• Doesn't intercept anything — there's no browser extension, you paste the payload yourself. A dApp/drainer that shows a fake "just sign this, it's free" prompt still requires you to know to paste it here first.
• Only recognizes the listed standards; anything else falls back to an honest "unrecognized structure, read the raw fields yourself" instead of a false sense of security.

DEX Honeypot Checker — /honeypot

What it does

Paste a token address — simulates buying it and immediately selling it back through a router, before you risk real funds. Catches the classic honeypot pattern: a token that lets anyone buy but blocks selling (via a hidden whitelist, a blacklist, or a "tax" quietly set to 100%). Also reports buy/sell tax percentage and reuses the Stage-5 contract scanner's findings (mint, blacklist, selfdestruct, proxy risk) for the same token.

How to use

1. Go to /honeypot.
2. Paste the token address. Router is optional — defaults to the UniswapV2Router02 confirmed active on LiteForge.
3. Click "Check".

What you'll see

• A one-line verdict: buy+sell both work, buy fails outright, or — the red flag — buy works but sell doesn't.
• Can buy / can sell / buy tax % / sell tax %.
• Any flags from the Stage-5 risk scanner for the token itself.

What it's based on

The tricky part: two separate simulated calls (buy, then sell) don't share state — eth_call/debug_traceCall don't let a hypothetical buy's result carry over into a second hypothetical sell. Solved with eth_call state overrides on both legs: the buy leg overrides the tester address's native balance (so no funded wallet is needed at all); the sell leg fakes "the tester already holds the bought tokens and approved the router" by brute-forcing the token's balance/allowance storage-mapping slots (try slots 0-9, inject a distinctive value via stateDiff, see which one moves balanceOf/allowance — the same technique honeypot-detection tools like RugDoc use, since there's no other way to fake holdings on an arbitrary, possibly-unverified ERC20). Tax is the gap between the actual simulated output and the router's own getAmountsOut quote for the same trade.

Limitations

• Only as good as the router/pair it's pointed at — a token with liquidity on a different DEX than the one checked won't be found.
• If the token's storage layout isn't a standard Solidity mapping (slots 0-9), the sell simulation is skipped with an honest "unverifiable" flag rather than a false "safe".
• A default 0.01 LTC trade size is used for the simulation — extreme liquidity-depth-dependent taxes at very different trade sizes aren't captured.

Address Poisoning Detector — /address-poisoning

What it does

Paste a wallet address — scans its incoming transfer history for lookalike senders: addresses that share the first and last few hex characters with someone the wallet has genuinely sent money to before. That's the mechanism behind address poisoning — an attacker sends a near-zero amount from a wallet crafted (via a vanity-address generator) to look like a real contact, betting the victim will later copy the attacker's address from transaction history instead of their real contact's.

How to use

1. Go to /address-poisoning.
2. Paste the wallet address.
3. Click "Scan".

What you'll see

• Nothing, if no lookalikes are found — an empty result here is a genuine "clean", not a coverage gap the way no-findings is on the risk scanner.
• For each match: the suspicious sender, which real trusted address it resembles, and whether the amount sent was dust (near-zero — the classic tell) or a real-sized amount (still worth checking, but a coincidental fingerprint collision is more plausible at four hex characters).

What it's based on

Builds a "trusted recipients" list from the wallet's own outgoing native-currency transfers (addresses it has actually paid), fingerprints each by its first 4 + last 4 hex characters, then checks every incoming sender against that fingerprint set — flagging anything that matches a trusted fingerprint but isn't the exact same address.

Limitations

• v1 scope is native-currency (zkLTC) transfers only. The ERC20 variant of this same attack — token.transfer(victim, 0) from a lookalike address — isn't caught yet, because the transaction's own to field is the token contract, not the victim; catching it needs parsing token-transfer logs per transaction, not just top-level tx fields.
• Four hex characters of prefix/suffix match (~2^32 combinations) is a coarse similarity bar — tune if it turns out too noisy or too lax in practice.
• No positive real-world case was found on LiteForge testnet to validate against (address poisoning is a targeted attack, rare on a testnet); the full algorithm was instead validated against constructed synthetic scenarios covering dust poisoning, a large-amount lookalike, and both real-trusted and unrelated-real senders — all classified correctly.

Claim / Faucet Domain Check — /domain-check

What it does

Paste a URL or domain — someone claiming "you're eligible for the LitVM airdrop, claim here" or "get testnet tokens at this faucet" — and check it against LitVM's real domains. Fake claim/faucet pages are the phishing pattern that spikes hardest around incentivized testnets and TGEs, and LitVM already has enough real subdomains (litvm.com, testnet., builders., docs., hackathon., plus Caldera's liteforge.*.caldera.xyz) that a convincing fake is easy to miss.

How to use

1. Go to /domain-check.
2. Paste the URL or bare domain.
3. Click "Check".

What you'll see

• Official LitVM domain — exact match against the curated list.
• Looks like a typosquat — either a small edit-distance from a real domain (e.g. lit-vm.com, litvm.io), or it contains the LitVM/LiteForge brand name without being one of the real domains (e.g. litvm-testnet.io, claim-litvm-airdrop.xyz — the more common real-world pattern, since attackers usually keep the brand name for credibility and add words/wrong TLDs rather than typo a few letters).
• Not recognized — doesn't match and doesn't resemble anything official. Could be an unrelated site; on its own this isn't a verdict either way.

What it's based on

A small, hand-maintained allowlist of domains each individually confirmed live before being hardcoded (see safe.md §0/§10) — not a crowdsourced or auto-updating phishing database. Two independent checks: Levenshtein edit-distance against the allowlist (catches character-substitution typosquats), and a substring check for "litvm"/"liteforge" appearing in a non-official domain (catches brand-name-plus-modifier fakes that edit-distance alone misses). Also flags punycode/non-ASCII characters as a homograph-attack indicator.

Limitations

• The allowlist is manually maintained — a new official subdomain won't be recognized until someone adds it here.
• Doesn't check page content, SSL, or registration date — purely a domain-string comparison. A phishing site on a domain that doesn't resemble LitVM at all (e.g. a generic URL shortener) won't be flagged.
• Not a general-purpose phishing-domain database (see safe.md's scope-cut on the original "domain registry + browser extension" idea) — scoped specifically to LitVM impersonation.

Safe Transaction Verifier — /safe-tx-check

What it does

Independently decodes a pending Safe (Gnosis Safe) multisig transaction's raw fields — to, value, data, operation — and flags dangerous patterns, without relying on the Safe web UI's own rendering of the transaction. This is the exact gap that led to the Bybit hack (Feb 2025, ~$1.4B, the largest crypto hack ever): signers approved a transaction because the UI showed something innocuous while the actual calldata swapped in malicious logic.

How to use

1. Go to /safe-tx-check.
2. Fill in to, value (wei), data (the calldata you're about to sign off on), and operation (0 = Call, 1 = Delegatecall) — get these from the Safe Transaction Service API or your wallet's "advanced" transaction details, not just what the Safe UI summarizes.
3. Click "Analyze".

Alternatively, if you're handed the transaction as a raw EIP-712 SafeTx typed-data payload to sign (the format hardware wallets show for clear/blind signing), paste it into /sign-preview instead — it recognizes primaryType: "SafeTx" and runs the exact same decoder.

What you'll see

• The decoded function call if it matches a known Safe management function (e.g. swapOwner(...), changeThreshold(...)), or a plain "doesn't match a known Safe function" note if it's a regular contract call.
• Flags: owner additions/removals/swaps, threshold changes, module enable/disable (a module can execute transactions from the Safe without collecting any owner signatures at all), guard changes, fallback handler changes, and — flagged regardless of target — operation=1 (delegatecall), since the target's code then runs with full access to the Safe's own storage.

What it's based on

Decodes calldata against Safe's owner/module/guard management ABI (addOwnerWithThreshold, removeOwner, swapOwner, changeThreshold, enableModule, disableModule, setGuard, setFallbackHandler, plus nested execTransaction/execTransactionFromModule) using viem's decodeFunctionData — function selectors are computed by viem.toFunctionSelector at runtime rather than hand-typed, to avoid transcription errors. Safe's canonical contracts (GnosisSafeProxyFactory, GnosisSafeL2, Safe v1.4.1) were confirmed deployed and verified on LiteForge before building this, matching the network's own listed Safe integration.

Limitations

• Decodes calldata; it doesn't simulate the transaction's actual effects (for that, take the decoded to/value/data into /preview).
• Only recognizes Safe's own management functions by name — a malicious call disguised as an unrelated, unrecognized function will show up as an honest "doesn't match a known Safe function" rather than a specific warning. Delegatecall is flagged regardless, since that's the pattern that matters most regardless of what function it targets.

Incident Response — /incident

What it does

For a wallet that's already been compromised: a three-step checklist with working buttons instead of a guide to read while it's still draining. Not a new engine — glues together tools that already exist (/approvals, /scanner) around the one question a compromised user actually has in the moment.

How to use

1. Go to /incident.
2. Paste the affected wallet address, click "Start".
3. Work through the three steps in order.

What you'll see

• Step 1 — Stop the bleeding. A direct link to /approvals with the wallet pre-filled and the scan already run — if the attacker still holds an approval, revoke it before anything else.
• Step 2 — Where did the funds go. The most recent outgoing native-currency and token transfers (capped to 15 on screen, most recent first — that's where an active drain shows up; full history is in the report). Each destination address links straight to /scanner, pre-filled and already scanned.
• Step 3 — Report the incident. A copy-paste-ready text report (wallet, timestamp, every outgoing transfer found, a checklist) for a forensics firm, law enforcement, or an exchange's fraud desk if funds moved to a deposit address.

What it's based on

Combines two Blockscout data sources: the transaction-history fetcher already used by /airdrop//approvals//address-poisoning (for native-currency transfers), and a separate token-transfers endpoint that gives the real sender/recipient of an ERC20/NFT transfer (unlike a plain transaction list, where the tx's own to is the token contract, not the actual recipient). The /approvals and /scanner pages both learned to read an ?address= query parameter and auto-run, specifically so these links function as one-click actions rather than just navigation.

Limitations

• Reactive only — this is what you do after something has already gone wrong. Nothing here stops an attack in progress (see safe.md's Watchtower/circuit-breaker discussion for why those aren't built yet).
• The drain list is a transaction-history query, not proof of theft — a busy wallet's normal activity (DEX trades, gas payments) shows up right alongside anything actually malicious. Use judgment on which entries look wrong.
• Doesn't cross-reference destination addresses against known scam/exchange clusters automatically — clicking through to /scanner tells you about the contract, not whether the address is a known attacker or an exchange hot wallet.

Common to all tools

• All data comes from LiteForge's public RPC node (https://liteforge.rpc.caldera.xyz/http) and the Blockscout explorer API. No tool asks for or stores private keys — only /approvals, when revoking, requests a signature via your already-installed browser wallet.
• Wherever it's relevant (airdrop checker, risk score), report wording is deliberately probabilistic — the tools give a signal for your own decision, not a verdict.