ShieldAI Transaction Firewall

ShieldAI Transaction Firewall checks a transaction before your wallet asks you to sign it, and tells you plainly what it found. When a website asks your wallet to send a transaction, the extension shows an overlay first. It decodes common calls such as approvals, transfers and swaps, shows how much of your chain's own coin you are sending, what spending rights the call grants, and the full recipient address, and gives a verdict: Safe, Caution, High Risk or Block Recommended. You choose whether to continue or cancel. The extension warns you; it does not stop you. When a check cannot finish, for example because a data provider did not answer or a contract's age is not available, the verdict is Unknown and the overlay says why. An incomplete check is never shown as Safe. What it covers • Transactions on eight EVM chains. The extension's welcome page lists them. • Wallets that give web pages a standard provider (window.ethereum or EIP-6963). • Signature requests are checked by the server like transactions and shown in readable form: permits, Permit2, and Seaport and Blur marketplace orders (including Seaport bulk orders) that give your NFTs away for nothing or pay someone else. Blur listings sign only a summary of what is listed, not its prices, so they are shown as High Risk. A Sign-In with Ethereum message made for another site than the one asking is flagged Block Recommended, and so is every eth_sign request, which can sign a transaction. A message that is not readable text is flagged High Risk, and 32 bytes of it, which can be a hash signed in your name, Block Recommended. The text of a message you sign is never sent. • EIP-7702 delegations: a transaction that hands your account to a contract is flagged Block Recommended, with the contract's address and whether it is verified and how old it is. • Look-alike addresses: when you send to an address that starts and ends like one you sent to before but is a different address, the warning shows both in full with the difference marked. • Phishing: the address of each https site you open is checked against phishing intelligence, and a warning banner appears when the site is flagged. Settings • Balanced mode shows every verdict and leaves the choice to you. On a Block Recommended warning, the button to continue must be held down for 1.5 seconds. • When your wallet's network cannot be read or is not supported, the only option is Block. • Strict mode removes the option to continue when a check fails, the verdict is Unknown or Block Recommended, or the extension cannot read the request or its typed data. • Switching the extension off sends every request to your wallet as the page made it, with no warning, no analysis and no chain read. A frame or popup the page can script cannot be told the setting, so requests from one are still refused. • English, Tiếng Việt and 中文. Privacy • Sent for analysis: the transaction's recipient, sender, value, call data and chain ID; for a signature request, the signing method and any EIP-712 typed data, never the text or hash you sign (and for those, not your address either); for an EIP-7702 transaction, each delegate's address; and the origin (scheme, host and port) of the sites you visit, for the phishing check. • Kept only in your browser: the last 100 addresses you chose to send to, for the look-alike check, and phishing results for the current browser session. • Never collected: private keys, seed phrases, passwords or page content. • The default server is api.shieldbotsecurity.online. You can point the extension at your own server in its settings. Limits • This is a warning layer, not a guarantee. Always read your wallet's own confirmation screen. • It checks the wallet requests a page makes through the standard provider's request method (window.ethereum or an EIP-6963 provider), in the page itself and in frames from other origins (an origin is a scheme, host and port). The same kinds of request sent through the older send and sendAsync methods are refused, and a short notice says so. A page that reaches your wallet another way, such as through the wallet's own messaging, is not checked. • It rejects every wallet request it checks from a frame or popup that the page can script itself: a frame whose parent page has the same origin, a blank (about:blank) or srcdoc document, or a popup opened by a page of the same origin. It cannot keep its check private there, and a short notice says so. Open the dApp in its own tab instead. • While it is switched on, it never passes a request it checks to your wallet without showing it to you first, and a page cannot make it approve a request for you: only your own click or key press on the warning counts, and your wallet receives exactly the request you approved. This covers the ways listed above; a page that reaches your wallet through the wallet's own internal methods or messaging is not checked at all. If no warning appears within 60 seconds, or the page takes it away, or keeps it out of view for 10 seconds while you are on the tab, the request is rejected. • A page can still hide or cover the warning, or lay something over it to trick you into clicking (clickjacking). The extension makes this harder (continue and sign buttons wait half a second after the warning appears, and work only once the warning has been fully visible for half a second since it last became visible) but cannot fully prevent it. If the page covers or alters the warning, those buttons do nothing and the warning says why. A page that makes the warning invisible without moving it away leaves the request waiting; nothing is sent. A page-wide filter from another extension (for example a dark-mode filter) can keep the continue button unavailable on that site. • A batch of calls (wallet_sendCalls) is checked one call at a time, each with its own warning. How the calls work together is not analysed. • A delegation (EIP-7702) your wallet signs in its own screens, and a send you make from the wallet itself, a…