Permit2 Signature Verification and Witness Types

Wallets must correctly decode and display EIP-712 typed data for PermitSingle, PermitBatch, and Witness types to prevent blind-signing attacks. The Witness type string is opaque to the Permit2 contract, meaning wallets cannot rely solely on the contract's domain to infer intent. Implementers must parse the witnessTypeString and witness fields to show users exactly which application-specific data they are authorizing. Failure to render this clearly enables phishing where a malicious dapp requests a permit for a legitimate token but with a hidden witness payload that authorizes a secondary action.

Integrating contracts that accept Permit2 signatures with Witness data must implement custom verification logic to validate the witness against expected parameters. The Permit2 contract only verifies the primary permit (token, amount, expiration) and the signature itself; it does not inspect the witness payload. The calling contract is responsible for hashing the expected witness data and comparing it to the witness field in the signed message. A missing or incorrect check allows an attacker to replay a valid signature with a different witness, potentially authorizing unintended state changes in the integrating protocol.

Permit2 uses a nonce-based replay protection scheme that differs from the traditional ERC-20 permit nonce model. The nonce is scoped to the token and the owner, and it is consumed on a per-signature basis. For Witness types, the nonce is consumed even if the witness verification fails on the integrating contract, which can lead to denial-of-service if the dapp's expected witness parameters change between signature and submission. Integrators must design their off-chain signature requests to be idempotent and handle nonce consumption failures gracefully, potentially using a separate nonce manager for witness-dependent flows.

PermitSingle and PermitBatch both include a deadline field that the Permit2 contract enforces at the time of on-chain execution. However, the Witness type adds a layer of complexity: the integrating contract may have its own time-sensitive logic that is not captured by the Permit2 deadline. If a user signs a permit with a valid deadline but the witness data becomes stale (e.g., a quote expires), the dapp must perform its own timestamp check on the witness. Relying solely on the Permit2 deadline for witness freshness creates a window where an outdated witness can be submitted with a still-valid permit.

The Universal Router's command-based architecture relies on Permit2 signatures to atomically approve and execute complex swap paths. Aggregators and fillers constructing these command sequences must correctly encode the Permit2 permit batch alongside the swap commands, ensuring the witness data matches the expected output of the swap. A mismatch between the signed witness and the on-chain state at execution time causes the entire transaction to revert, wasting gas. Integrators should simulate the full command sequence against a fork before submitting to mainnet to validate witness alignment.

Chainscore Labs can perform targeted audits of Permit2 integration code, focusing on the correctness of Witness type handling, nonce management, and signature verification flows. Our review covers the full lifecycle: off-chain typed data construction, wallet display and signing, on-chain permit consumption, and witness validation logic. We identify replay vectors, witness mismatch conditions, and edge cases in expiration handling that could lead to stuck transactions or unauthorized state changes. Teams building gasless approval flows or complex multi-step transactions on top of Permit2 can engage us for pre-deployment security review.

Start with Uniswap’s official Permit2 documentation to confirm the intended split between AllowanceTransfer and SignatureTransfer flows. For signature verification and witness types, this distinction matters: PermitSingle and PermitBatch relate to allowance-style approvals, while witness-bearing transfers are part of SignatureTransfer. Integration teams should use the docs to map which Permit2 surface their frontend, wallet, router, or aggregator actually calls before implementing typed-data generation or approval revocation UX.

The Uniswap Permit2 repository is the canonical source for contract interfaces, hashing libraries, tests, and deployment assumptions. Wallets and dapps that build EIP-712 payloads without relying fully on an SDK should validate their struct names, field ordering, nonce usage, and domain construction against the Solidity source and tests. This is especially important for witness transfers, where mismatched type strings or field ordering can produce signatures that appear valid in the UI but fail on-chain.

Use the SignatureTransfer reference when implementing one-time signature-based token transfers, including permitTransferFrom and witness-aware transfer flows. The operational focus should be on correctly binding the signature to token permissions, nonce, deadline, spender, and any witness data that the consuming contract requires. Aggregators and routers should treat witness values as security-critical context, not optional metadata, because the witness is how application-specific intent can be committed into the signed Permit2 message.

Review the AllowanceTransfer reference when implementing PermitSingle, PermitBatch, or allowance-based Permit2 approvals. These flows have different replay and expiration behavior than SignatureTransfer witness flows, so teams should avoid reusing nonce-management assumptions across both surfaces. Wallets should clearly distinguish a reusable Permit2 allowance from a one-time signature transfer, and backends should monitor outstanding allowances separately from consumed signature-transfer nonces.

For witness-type correctness, inspect the Permit2 hashing implementation directly rather than relying only on frontend examples. The hashing library defines how Permit2 constructs EIP-712 digests for permit structs and witness-bearing messages. Engineering teams should use it as the source of truth for type hashes, encoded fields, and witness type composition, then add regression tests that compare locally generated digests against contract-level expectations before enabling production signing.

Permit2 signatures depend on EIP-712 domain separation and typed structured data semantics. Teams should verify that their wallet connector, mobile wallet, backend signer, or embedded wallet uses compatible eth_signTypedData behavior and includes the correct chain ID, verifying contract, primary type, and nested type definitions. This is the reference to use when debugging signature mismatches caused by JSON serialization, field ordering, type-string construction, or wallet-specific rendering differences.