Approvals in the execution flow

The short answer

On EVM chains such as Robinhood Chain, an ERC-20 swap usually needs the token owner to authorize a spender before that spender can call transferFrom. The approval can be an earlier onchain transaction, a signed permit, or part of a smart-account batch. If an earlier standalone approval succeeds and the later swap fails, the allowance still exists.

Solana's Token Program uses a different model. The token-account owner can approve one delegate for a capped amount on that specific token account. A normal owner-signed swap does not inherently require a standing delegate. When a delegate is used, its authority and remaining amount must be tracked separately from the swap result.

The ordinary ERC-20 execution sequence

Native ETH sent directly with an EVM transaction does not use an ERC-20 allowance. Wrapped ETH is an ERC-20 and generally does. The asset actually leaving the wallet determines whether an approval dependency exists.

The failure outcome depends on the transaction boundary

Atomic batching can shrink the exposure window, but only when the contract treats every required call as one reverting unit. The bundles and atomic execution guide explains that boundary.

Exact, buffered, and unlimited allowances

An exact allowance caps the spender near the planned input but can require another approval when the amount or route changes. A buffered allowance reduces repeated approvals but leaves deliberate excess authority. An unlimited allowance avoids recurring approval transactions and creates the largest persistent exposure if the spender is malicious, upgraded, or compromised.

ERC-20's original specification also warns about changing a nonzero allowance directly to another nonzero amount because transaction ordering can let a spender use both the old and new values. Interfaces may reduce to zero before setting a replacement, or use newer permission patterns. Treat every extra approval transaction as its own state change and gas cost.

Permits move authorization into a signature flow

ERC-2612 adds a signed permit message that can update an ERC-20 allowance without the owner first submitting an approval transaction. The permit includes an owner, spender, value, nonce, deadline, and signature. A third party can submit it, so the safety boundary is the signed message—not whether the wallet paid gas at signing time.

Uniswap's Permit2 supports two related models. AllowanceTransfer can give spenders amount- and time-bounded permissions through Permit2. SignatureTransfer supports a signed, one-time transfer whose spender permission lasts for the transaction in which the signature is consumed.

Permit2 still needs the token contract to authorize the Permit2 contract before it can move that token. That root ERC-20 allowance and the app-specific Permit2 permission are two layers. Revoking or expiring the second does not automatically erase the first.

Solana delegates belong to token accounts

A Solana Token Program approval records one delegate and one delegated amount on a particular token account. Approving a new delegate replaces the prior delegate and amount for that account. The delegate can transfer or burn up to the authorized amount under the Token Program's rules.

Because Solana transactions can contain several instructions atomically, an app can place approval, delegated action, and revoke instructions inside one transaction when its design requires that sequence. If a required instruction fails, the transaction's state changes do not persist. If approval is a separate successful transaction, it remains until replaced, consumed, or revoked.

A Token-2022 permanent delegate is different. It is configured at the mint level, applies across that mint's token accounts, and cannot be revoked by an individual holder. It is an issuer control to inspect before trading—not a wallet approval the holder accidentally left behind.

Read authority as part of the route

For the wallet-maintenance workflow, continue with revoking Solana token delegate approvals.

What the journal should preserve

1. The approval transaction, permit signature context, or Solana approve instruction that created authority.
2. Owner, token or mint, source token account, spender or delegate, raw amount, expiry, nonce, and relevant contract layer.
3. The swap result and actual amount consumed through transferFrom or delegated token instructions.
4. The post-trade allowance or delegate state and the confirmed revoke, replacement, or expiry event that ended it.

Primary sources