The problem SignGuard solves

The Problem It Solves

One of the biggest problems in Ethereum today is that users are regularly asked to sign transactions they do not fully understand. Wallets often show raw calldata, contract addresses, token approvals, hex signatures, or vague method names, but this does not clearly explain what will actually happen after signing.

Many existing transaction security tools focus mainly on whether something is “safe” or “unsafe.” While this is useful, it often leaves users without enough context. A green checkmark does not explain what permissions are being granted, which assets may move, who the user is interacting with, or whether the transaction matches the user’s real intent.

This problem affects not only beginners, but also developers. Complex Web3 transactions can involve proxy contracts, batched calls, internal contract calls, delegate execution, account abstraction flows, ERC-4337 UserOperations, paymasters, session keys, plugins, and multiple protocol layers. Even experienced developers often need to jump between explorers, contract addresses, calldata decoders, traces, ABIs, and documentation just to understand what a single transaction is doing.

SignGuard solves this by adding a transaction understanding layer before signing. Instead of only showing a generic risk label, SignGuard analyzes and explains what the transaction actually does using transaction simulation, calldata decoding, contract inspection, approval analysis, ENS verification, Sourcify source verification, phishing detection, protocol identification, and suspicious permission checks.

People can use SignGuard to:

• understand what they are signing before confirming a wallet transaction;
• detect dangerous approvals, suspicious spenders, fake contracts, and drainer-style interactions;
• verify whether the target contract is known, verified, or suspicious;
• understand ENS-related actions such as record updates, name transfers, resolver changes, or Name Wrapper approvals;
• inspect complex developer flows such as proxy interactions, batched calls, ERC-4337 UserOperations, paymasters, session keys, and internal execution paths;
• ask AI follow-up questions about the transaction using the full analyzed context;
• debug complex transaction flows through traces, execution graphs, decoded calldata, simulation results, and contract interaction data;
• integrate transaction safety checks into wallets, dApps, browser extensions, SDKs, or backend tools.

SignGuard adapts the explanation to the user’s knowledge level. Beginners receive simple, human-readable explanations focused on what will happen and what to watch out for. Regular users receive more context about risks, permissions, assets, and protocol behavior. Developers can inspect advanced evidence such as decoded calldata, simulation traces, ENS validation results, contract interaction graphs, source verification data, internal calls, and low-level execution details.

The AI assistant makes the workflow interactive. Instead of being limited to a static report, users and developers can ask questions such as “What exactly happens if I sign this?”, “Why is this approval risky?”, “Which internal call changed?”, “Why did this UserOperation call a different contract?”, or “Is this ENS identity legitimate?” The assistant answers using the structured analysis results, not just raw calldata.

Overall, SignGuard makes Ethereum signing easier, safer, and more understandable. For users, it turns confusing wallet confirmations into clear transaction explanations. For developers, it reduces the time needed to inspect, debug, and understand complex transaction flows before anything is signed or executed on-chain.

Challenges we ran into

Challenges We Ran Into

One of the biggest challenges was making the analysis reliable without treating AI as the source of truth. It was tempting to let the LLM directly explain the transaction, but that could create incorrect or unsafe answers. We solved this by building a deterministic analysis pipeline first: decode calldata, simulate execution, collect Sourcify metadata, detect effects, score risks, and only then use AI as an optional explanation layer based on those facts.

Another challenge was handling transactions when contract source or ABI data was missing. In those cases, raw calldata is hard for users to understand. We added fallback behavior so the analyzer still returns useful information from simulation, traces, selector lookup, risk rules, and conservative explanations instead of failing.

ENS support also required extra care. An ENS name can help users recognize an address, but it should not automatically make a transaction safe. We handled this by using reverse lookup with forward confirmation, showing warnings for mismatches, and treating ENS as identity context rather than proof of trust.

Finally, integrating the analyzer into wallet UX was difficult because browser extensions, MetaMask Snaps, backend services, and SDK packages all have different security boundaries. We separated the project into a core engine, browser SDK, backend SDK, Snap, and extension so that sensitive API keys stay on the backend while wallets and dApps can still use the analysis safely.