# Protect > Understand what you are authorizing before funds move. Assess EVM transactions, permits, typed-data signatures, ERC-4337 user operations, and EIP-7702 delegations for asset effects, permission changes, and policy decisions before signing. 1. [Platform](https://trilocore.com/platform/) 2. Protect See asset movements, permission changes, and policy decisions before signing. [Book a demo](https://trilocore.com/demo) [Wallet & custody workflows](https://trilocore.com/platform/#wallets-custodians) At a glance - Status: Available - Access: Partner API integration and guided walkthrough — [book a demo](https://trilocore.com/demo) - Payloads: EVM transactions, EIP-712 permits & orders, ERC-4337, EIP-7702 - Decisions: `allow`, `warn`, `require_review`, or `block` (enforced by caller) On this page - [Workflow](https://trilocore.com/platform/protect#problem) - [Capabilities](https://trilocore.com/platform/protect#capabilities) - [Pre-signing example](https://trilocore.com/platform/protect#example) - [Integration use cases](https://trilocore.com/platform/protect#audience) - [Coverage & limits](https://trilocore.com/platform/protect#limits) The problem ## Raw calldata and typed-data hashes hide what a signature actually grants Signers routinely approve transactions, Permit2 allowances, or EIP-7702 delegations that look routine on the surface while granting unlimited token control, delegating account code, or routing value to an untrusted spender. Wallets, custodians, and treasury teams need structured pre-signing evidence rather than opaque hex strings. 01 ### Submit before signing Send an unsigned EVM transaction, typed-data signature, ERC-4337 user operation, or EIP-7702 authorization along with chain and account context. 02 ### Inspect asset & permission effects See expected balance transfers alongside token allowances, Permit2 grants, NFT operator approvals, and account delegation targets. 03 ### Review risk explanations Read structured risk findings with severity levels, reason codes, and clear explanations of what the payload authorizes. 04 ### Enforce policy Receive a policy decision — `allow`, `warn`, `require_review`, or `block` — enforced by your wallet, signer, or custody workflow. Capabilities ## What Protect evaluates before a signature is produced Built for pre-signing integration into wallets, custody approval queues, and treasury signing workflows. ### Transaction and signature assessments Assess standard EVM transactions, EIP-712 typed data (including EIP-2612 permits, Permit2 single and batch approvals, and off-chain orders), personal-sign payloads, ERC-4337 user operations, and EIP-7702 delegation authorizations. ### Asset and permission effects Surface expected native and token transfers alongside ERC-20 allowances, NFT operator approvals, Permit2 spender grants, and account code delegation targets. ### Risk explanations Every finding includes a severity level, stable reason code, and clear explanation — such as an unlimited allowance to an unverified spender, a long-lived off-chain permit, or a cross-chain replay-capable authorization. ### Policy decisions Evaluate assessments against revisioned policies with trusted-target allowlists, known-bad denylists, and severity thresholds. Incomplete assessments never default to `allow`. ### Assessment history and feedback Retrieve past assessments by ID with their pinned state context and policy revision, and record operator feedback (such as confirmed benign or confirmed threat) for audit trails. ### Multi-step bundle handling For multi-transaction bundles, Protect evaluates the first step and marks remaining steps as incomplete with a `require_review` floor; full sequential bundle simulation is **not available** today. Example outcome ## Clear pre-signing evidence for operators and users When a treasury operator or wallet user is asked to sign a Permit2 typed-data payload, Protect decodes the exact spender, token, cap, and expiration, flags an unlimited allowance to an unknown spender address, and returns a policy decision before the signature is produced. 1. Payload received unsigned Permit2 PermitSingle 2. Permission decoded unlimited USDC allowance → 0x99f1…44d2 3. Risk finding recorded HIGH · untrusted spender 4. Policy decision returned block (enforced by caller) protect · asmt_01jb2… · evm_typed_data (Permit2)Illustrative Decision: block — unlimited USDC Permit2 allowance to unverified spender `0x99f1…44d2` View technical details // Subject: PermitSingle on Ethereum mainnet (chain_id: 1) Signer: 0x3a91…8820 (Treasury Operations Safe) Token: USDC (0xA0b8…eB48) Spender: 0x99f1…44d2 (unverified contract, not in trusted targets) // Permission & asset effects [PERMISSION] Grants UNLIMITED (2^160 - 1) USDC allowance via Permit2 [EXPIRY] Permit valid for 365 days (sigDeadline: 30m) // Risk findings & policy evaluation (policy rev 7) [HIGH] UNLIMITED_PERMIT_UNTRUSTED_SPENDER Decision: block · Completeness: complete (block 21,019,105) decision: block · policy rev 7Illustrative Pre-signing Permit2 assessment with decoded permission effect and **caller-enforced policy decision**. Integration use cases ## Who integrates Protect ### Wallets and signing interfaces Translate opaque calldata, Permit2 approvals, and EIP-7702 authorizations into clear asset and permission changes with warnings before the user signs. ### Custodians and institutional signers Route high-risk or incomplete assessments to compliance and security review (`require_review`) and automatically reject denylisted or policy-violating payloads (`block`). ### Protocol treasuries and exchanges Check multisig proposals, rebalance transactions, and settlement operations against trusted contract allowlists and expected balance effects before co-signing. Coverage and limits ## What Protect covers and important boundaries Protect evaluates unsigned EVM payloads and returns structured evidence and a policy decision; the integrating system enforces the decision. - Networks: EVM networks (Ethereum, BNB Chain, Polygon, Arbitrum, Optimism, and Base). Solana pre-signing assessment is not available - Supported payloads: `evm_transaction`, `evm_typed_data` (EIP-2612, Permit2, orders), `evm_personal_sign`, `evm_user_operation` (ERC-4337), `evm_authorization` (EIP-7702), and first-step `evm_bundle` - Safe fallback: When simulation or state context is incomplete, Protect marks completeness explicitly and returns at least `require_review` — never `allow` - Caller enforcement: Protect returns a policy decision; the integrating wallet, signer, or custody system enforces that decision before signing or broadcast - Not a guarantee of safety: Every assessment reflects chain state at a specific block snapshot; on-chain state or counterparty contracts can change before inclusion - Multi-step bundles: Bundle requests evaluate the first transaction and mark subsequent steps as not simulated ## Integrate pre-signing assessment into your signing flow. Book a demo to walk through Protect payload assessments, policy configuration, and API integration for your wallet, custody platform, or treasury. [Book a demo](https://trilocore.com/demo) [Explore the platform](https://trilocore.com/platform/) --- [Canonical HTML version](https://trilocore.com/platform/protect)