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: transactions seen in the scored window vs. total transactions all-time, wallet age (full history, see below), 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.

Total transaction count (all-time) comes from Blockscout's /counters endpoint — a running total the explorer maintains independent of pagination, so it's one cheap call regardless of how large the address's history is.

Wallet age is computed separately from the 250-tx window, via binary search: eth_getTransactionCount(address, blockNumber) returns the address's nonce as of a past block, and only increments on outgoing transactions. Binary-searching for the block where the nonce goes from 0 to 1 finds the first-ever outgoing transaction in ~25 RPC calls, instead of paginating Blockscout page-by-page back to genesis — infeasible for busy addresses (one tested address had 4.8M total transactions; that's ~96,000 pages). For an address that has never sent a transaction (nonce always 0, e.g. receive-only), the search finds nothing and age falls back to the oldest timestamp in the 250-tx window.

High-frequency automation alone doesn't distinguish a sybil farmer from legitimate infrastructure — a relayer, a keeper, a faucet dispensing to many wallets, or a deploy script all look equally "automated" on raw frequency. The difference is what's being repeated: a sybil farmer varies its action per protocol to farm eligibility across many surfaces; a relayer/keeper repeats one or two operations across many different target contracts; a faucet/dripper repeats plain native transfers (no calldata) to many different addresses; a deploy script is mostly contract creations. When one of these shapes matches strongly, the score is reduced and the summary says so explicitly instead of reading as a sybil-farming signal.

Limitations

• Activity metrics (contracts, methods, frequency, revert rate) only look at the last 250 transactions — may not reflect the full history of very old/active addresses. Wallet age is the exception (see above).
• Wallet age falls back to the 250-tx window for addresses that have never sent an outgoing transaction.
• A heuristic, not proof. Report wording is deliberately probabilistic.
• The relayer/keeper/faucet/deploy-script detection is itself a heuristic — a sybil operation deliberately shaped to mimic one of these patterns (e.g. always calling the same claim() across many airdrop contracts) would also score lower.

Approvals Manager — /approvals

What it does

Paste a wallet address — get a list of currently active ERC20/NFT approvals (approve/setApprovalForAll), with a revoke button per approval and a "Revoke All" that goes through them in sequence.

How to use

1. Go to /approvals.
2. Paste the wallet address, click "Scan".
3. Click "Revoke" on a single approval, or "Revoke All" to go through every one — each is its own wallet confirmation.

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 per-row revoke button and a bulk "Revoke All".

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 read-only request) — an approve event doesn't mean the allowance is still active, it could have been revoked or replaced since. Revoking is a direct approve(spender, 0)/setApprovalForAll(operator, false) call sent straight to the token, one transaction per approval — approve() reads msg.sender, so a shared relayer contract can't zero it out on the owner's behalf, only the owner's own wallet can.

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, "No WETH pair — not tested" (neutral, not a honeypot signal), 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.

Before simulating anything, the checker calls the router's own factory (getPair(WETH, token)) to confirm a WETH pool actually exists. No pair found → reported as "No WETH pair — not tested", separate from a real "cannot buy" — the former is just missing liquidity against WETH specifically (harmless), the latter (pair confirmed present, buy still reverts) is the actual honeypot signal. Conflating the two under one "cannot buy" message previously made routine missing-liquidity tokens read as scams.

Limitations

• Only checks liquidity against WETH on the given router's factory — a token paired only against a different quote asset (a stablecoin, another token) reports "no WETH pair", not "safe" or "unsafe", since that pair isn't checked.
• 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.

Pulse — /pulse

What it does

Paid, always-on background monitoring — Watchtower. The same detection logic the free tools run on-demand (contract risk, address poisoning) running continuously against your watched wallets, pushing alerts to Telegram in real time. Pro tier adds a weekly emailed report with an AI-written summary.

How to use

1. Go to /pulse, connect a wallet, pay for Standard (0.1 zkLTC) or Pro (1 zkLTC) — a one-time payment that unlocks the tier for 30 days, not a recurring subscription.
2. Go to /pulse/settings, add wallets to watch (up to 10 on Standard, 100 on Pro), optionally set per-token thresholds or watch specific contracts directly, and link Telegram via the bot link shown there.
3. Alerts land in Telegram as they happen. Pro subscribers who also set an email get a weekly report.

What you'll see

• Telegram alerts for: a new non-zero approval, an outgoing native transfer above your threshold, a buy/sell above a %-of-balance or a token-specific raw threshold you configured, a dust-amount transfer from an address that looks like one you've paid before, an interaction with a contract whose /scanner risk score crosses 50, any movement at all on a wallet you marked "alert on any activity," a balance dropping below a floor you set, a burst of transactions too fast to be a human clicking, and — for contracts watched directly — an owner/admin/implementation change or an unusually large mint.
• Pro: a weekly email with per-wallet approval and activity stats, per-watched-contract supply/holder trend, and a short AI-written paragraph connecting patterns across that week's numbers — the model only ever sees the same pre-computed facts the email already shows (never raw logs, calldata, or tx hashes) and is instructed to never invent a number or predict what happens next.

What it's based on

A dedicated Node worker polls each watched wallet's transaction history via Blockscout every 5 seconds and subscribes to Transfer/Withdrawal/Deposit logs over the LiteForge RPC's WebSocket, feeding the same detectors the free tools use (lib/litvm/contract-risk.ts, lib/litvm/address-poisoning.ts). Watched contracts are polled every 5 minutes for owner/admin/implementation drift and checked for large mints as they happen. Payment is verified by checking a real on-chain transaction to the treasury address for the right amount from the wallet you're claiming — no off-chain payment processor. Settings and the account dashboard are gated behind a signed-message proof of wallet ownership, not just the address itself. The weekly AI paragraph tries Groq's free tier first, then a chain of free OpenRouter models, and is simply omitted (the report still sends) if every provider fails.

Limitations

• Detection scope is exactly the underlying detectors' scope — this is the always-on delivery mechanism, not a separate or smarter engine.
• Wallets are polled every 5 seconds, not watched live per-block — real-time here means "within a few seconds," not instant.
• No auto-renewal: nothing is ever charged again automatically, so alerts silently stop once your paid period ends unless you pay again. Paying again while a higher tier is still active extends that tier rather than downgrading it.
• The weekly AI summary depends on free third-party model APIs — if all of them are unavailable, the report still sends, just without that paragraph.

Bookmarklet — /bookmarklet

What it does

Intercepts eth_sendTransaction, eth_signTypedData_v4/_v3, personal_sign, and eth_sign before your wallet ever sees them, on whatever dApp page you're using — a LitGuard checkpoint in front of MetaMask, Rabby, or any injected wallet. No install: a javascript: bookmark you drag to your bookmarks bar and click once per page.

How to use

1. Go to /bookmarklet, drag the "LitGuard" button to your bookmarks bar.
2. Open the dApp, connect your wallet as usual.
3. Before clicking Approve/Swap/Confirm, click the LitGuard bookmark once — a checkpoint appears over the page the next time your wallet is asked to sign or send anything.
4. Review the verdict, click Continue or Reject. Reject genuinely blocks the wallet call; it never reaches your wallet.
5. Click the bookmark again after a full page reload or navigation — it doesn't persist across either.

What it's based on

The same engine that powered LitGuard's earlier browser extension: POST /api/wallet-check runs a real debug_traceCall simulation for transactions (decoded balance/token/NFT changes, unlimited-approval detection, contract name and verification status, revert reason if it would fail) and the same signature-decoding engine as /sign-preview for typed-data/personal/blind-sign requests. The bookmarklet itself is a thin <script src> stub (/api/bookmarklet) that loads current interception logic fresh on every click — logic updates ship server-side, nobody needs to re-drag a new bookmarklet.

Limitations

• Depends on the dApp page's own CSP: it must allow loading a script from litguard.pro, and separately allow the check request back to litguard.pro. A strict CSP blocking either means a silent no-op, or a dialog that fails open with "check unavailable" once it can't reach the backend.
• Runs after the page's own scripts have already executed, unlike a browser extension's before-anything-runs injection — this defends against generic, careless drainer behavior, not an adversary who specifically targets LitGuard's own on-page checkpoint.
• Doesn't check the wallet's current chain yet — simulates against LiteForge (4441) regardless of what chain the wallet is actually connected to.
• Only sees requests through an injected provider (window.ethereum / EIP-6963). WalletConnect and mobile in-app browsers aren't covered.

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.