Uniswap wallets are self-Custody Connections with ERC-20 Approval Controls

Uniswap Wallet, MetaMask, and Ledger separate interface choice from key control

Five wallet options connect to Uniswap through different interfaces, yet Uniswap Wallet, MetaMask, and Ledger leave transaction approval with the account controller.

Uniswap Wallet combines account management and the Uniswap interface in one product. MetaMask and Coinbase Wallet expose an injected provider in a desktop browser, while Rainbow reaches the interface through WalletConnect on mobile. Ledger moves the signature onto a hardware device, although companion software still presents the request. Those paths change where a prompt appears, not what a valid transaction contains: chain ID, nonce, recipient, value, calldata, and fee fields. In every case, the interface proposes an action, the selected account signs it, and the network determines whether the transaction executes.

Choosing among them changes key location, backup workflow, and prompt display; it does not merge their accounts or allowances.

A three-stage connection creates no token allowance

Three stages separate a Uniswap wallet connection from token spending: account discovery, explicit permission, and a signed state-changing request on the chosen network.

The interface reads an address before it asks the wallet to sign anything.

Connection permission

The connection request exposes one or more public accounts and the active chain to the interface. It lets Uniswap prepare quotes and send proposed messages or transactions back to the wallet. No approve call, Permit2 signature, or swap enters the chain at this stage. Disconnecting ends this communication session, while every existing allowance remains in contract storage.

Signing permission

Signing begins only when the wallet receives a defined payload. The prompt identifies either structured data or a transaction, and the account controller accepts or rejects that exact request.

Offchain signatures authorize structured data

An EIP-712 signature commits to typed fields without broadcasting a standalone transaction. Permit2 later verifies the signature when an integrated contract submits it with an onchain call.

Onchain transactions consume gas

An approval or swap carries a nonce, gas parameters, destination, and calldata. Signing produces a serialized transaction; broadcasting it asks validators or sequencers to change network state.

Chain IDs keep approvals inside one network

Five identifiers distinguish common Uniswap networks during wallet selection and typed-data signing: Ethereum uses chain ID 1, Optimism 10, Polygon 137, Base 8453, and Arbitrum One 42161.

An approval written on Ethereum changes Ethereum state only; the identically named token on Base has a different contract and allowance record. EIP-712 typed data includes a domain designed to bind a signature to context, commonly the chain ID and verifying contract. When a wallet displays the expected token on a different network, the balance, nonce, gas token, and spender address all refer to that other chain. Switching the network before signing forces the interface to rebuild the request, so one deployment never inherits another deployment’s allowance. That rebuilt payload gives the signer the correct network context.

Chain selection therefore decides which balances and approvals the Uniswap interface can use.

ERC-20 approval writes one owner-token-spender allowance

One ERC-20 approval call creates a single owner-token-spender allowance, giving a named contract authority up to the value the wallet signs onchain.

Three ERC-20 operations explain the lifecycle. approve(spender, value) writes the limit, allowance(owner, spender) reads what remains, and transferFrom(from, to, value) consumes it when the spender moves tokens. A successful approve call emits one Approval event. The value uses uint256, a 256-bit unsigned integer spanning 0 through 2^256−1, although individual tokens apply their own supply and decimal rules.

The remaining allowance belongs to that exact owner, token, and spender tuple.

Approving USDC does not authorize UNI, and approving one router does not authorize another spender. A maximum value reduces repeated approvals, while an exact value confines the contract to the intended quantity. Replacing an allowance overwrites the previous value under ERC-20; it does not add a second balance.

Permit2 divides reusable allowances from one-time transfers

Two Permit2 contracts, AllowanceTransfer and SignatureTransfer, separate reusable token allowances from one-time signed transfers while preserving the wallet as authorizer for each request.

AllowanceTransfer scopes repeat access

Permit2 packs a 160-bit amount, a 48-bit expiration, and a 48-bit nonce into one 256-bit allowance record.

AllowanceTransfer starts with a standard ERC-20 approval from the token owner to Permit2. The Uniswap app then requests a limited signed allowance that expires after 30 days. Its typed message names the token, amount, expiration, nonce, spender, and signature deadline. Because the token-to-Permit2 approval and the Permit2-to-router permission occupy different layers, the 30-day expiry closes the second layer; it does not erase the first ERC-20 allowance to Permit2.

SignatureTransfer confines authority to one use

SignatureTransfer bypasses a stored application allowance inside Permit2. The owner signs a transfer permit with an amount, nonce, and deadline, and the authorized contract spends it in the transaction consuming that signature. Permit2 also supports batched permits, while the Universal Router passes approved assets into a composed swap path.

Exact, balanced, and maximum allowances change repeat costs

Three approval strategies - exact, balanced, and maximum - trade additional onchain transactions against the duration and quantity of authority left available to the spender onchain, as recorded in Uniswap checklist.

An exact allowance covers the planned input and reaches zero after the spender consumes the full amount. A balanced allowance leaves a defined remainder for later swaps. A maximum allowance writes the largest value the wallet accepts, reducing repeated approval calls but retaining broader authority. The network price of any approval remains variable because gas usage, the base fee, and the priority fee move with the route and network conditions.

A first interaction with an ERC-20 token can require two onchain transactions - one approval and one swap - plus one offchain Permit2 signature. After a sufficient token-to-Permit2 approval exists, a later route needs a valid bounded permission and the swap transaction; the interface requests a new signature only when the signed permission is missing or expired. Within this flow, Uniswap wallets remain the signing layer, while Permit2 and the Universal Router define the permission path.

Why does the wallet ask twice before a swap?

Two separate authorizations appear because a token allowance changes spending permission, while the later swap confirmation submits the requested exchange to the network.

When no sufficient ERC-20 allowance exists, the first transaction targets the token contract and calls approve. Its receipt changes only the allowance record. The interface then requests a Permit2 signature when that route uses Permit2, followed by a transaction aimed at the router. That final transaction carries the swap calldata, input amount, minimum output, recipient, deadline, and network fee settings. If the first approval confirms but the swap never follows, the token balance remains unchanged and the allowance stays available under its recorded terms.

Reading the destination, action, amount, and deadline in sequence separates each prompt’s purpose.

Address length exposes account and network mismatches

A 20-byte EVM address contains 40 hexadecimal characters, or 42 characters with its 0x prefix, and identifies the account Uniswap reads onchain.

An EIP-55 checksum uses letter case to help software detect mistyped hexadecimal addresses, without changing the underlying 20 bytes. The connected address controls which balances, nonces, and owner-side allowances the interface retrieves. A switch from one MetaMask account to another changes all three data sets, even if both accounts share the same browser extension. WalletConnect likewise carries a specific account and chain inside its session, so a mobile wallet switch must reach the interface before the next request is prepared.

Matching the displayed account before signing keeps the quote, allowance, and final recipient aligned.

Contract wallets and hardware signers expose different edge cases

Two signature families matter for advanced Uniswap accounts: externally owned accounts return elliptic-curve signatures, while contract accounts validate signatures through deployed code.

A conventional Ethereum signature occupies 65 bytes: a 32-byte r value, a 32-byte s value, and a 1-byte recovery value. ERC-2098 defines a 64-byte compact representation. Ledger accounts still produce externally owned account signatures, but the device asks the controller to review and approve the payload. Safe and other contract accounts use EIP-1271 validation instead; its success value is the 4-byte value 0x1626ba7e. Permit2 supports EIP-1271, although the chosen interface and wallet connector must also deliver compatible prompts.

Raw or incomplete typed-data displays make the verifying contract, token, amount, chain ID, and deadline the decisive fields for a Permit2 request.

Expired, exhausted, and replaced allowances define the recovery path

Three allowance states explain most stalled Uniswap approvals: the remaining amount is zero, the expiration passed, or the token requires a zero reset.

An exhausted allowance needs a new limit before another transfer. An expired Permit2 permission needs a fresh signature, while its underlying ERC-20 approval to Permit2 can remain live. Some token implementations, including USDT and CRV, require the existing allowance to reach 0 before accepting another nonzero value. That reset produces one onchain approval to 0, followed by a second approval for the desired amount and then the swap transaction.

A disconnected session does not reset an ERC-20 allowance.

Revocation changes the allowance onchain, normally by setting its value to 0, and therefore consumes network gas. Reconnecting changes only the communication session. Checking the transaction receipt, active chain, connected owner, token contract, spender, remaining amount, and expiration identifies the precise state to update before resubmitting the request.