Scroll token spending and ERC-20 allowances

Scroll uses ERC-20 allowances to let a designated spender move approved tokens from your wallet through the token contract. The allowance belongs to an owner-spender pair within that token's deployment. Approval grants permission; an application action determines whether tokens actually move. Your balance and remaining allowance must both cover the requested transfer, subject to the token's rules. A successful approval alone does not complete a swap or deposit. The main choices concern the spender's identity, the amount of standing permission, and the authorization method that the selected token and application support. Existing permission can make another approval unnecessary.

Key takeaway: A standard finite allowance retains unused permission when the approved amount exceeds the tokens that an application actually spends.

From approval to an application action

Permission in the token contract

An application that pulls tokens needs usable permission for its actual spender before the transfer executes. In the basic ERC-20 flow, the owner calls approve on the token contract. The function's arguments identify the spender and amount. The transaction destination is therefore the token contract, even when wallet labels emphasize an application. A successful call records an Approval event and updates the allowance. Reading allowance(owner, spender) on that same token contract reveals the remaining permission. Signing or submitting a transaction alone does not establish that the contract accepted the approval.

Execution in the application

The application call performs its operation and can use transferFrom to pull the approved tokens. Its execution may still fail because of application conditions or token restrictions. A successful transaction receipt records execution; transfer logs and application state identify what actually completed. The authorization and application operations commonly occupy separate transactions in an ordinary wallet flow. An existing allowance or a supported permit integration can remove the need for a new standalone approval.

Owner, spender, and recipient

The spender calls the token contract; the recipient receives the tokens that this call transfers. The owner holds the balance and grants permission. A spender can be an account or an application contract, and its address can differ from the recipient's address. Standard approval specifies the spender and amount without fixing the eventual recipient. For a contract spender, its code determines which transfers it can initiate. The application name shown by an interface does not substitute for the actual approved address.

How much access does an allowance grant?

An allowance limits one spender's access to one owner's balance in one ERC-20 token contract.

Finite spending limits

A finite allowance works as a remaining spending budget. A standard ERC-20 allowance can cover multiple transfers up to the remaining approved amount. Ordinary finite-allowance accounting deducts the amount spent through transferFrom. The approved amount can exceed the wallet's balance, although a transfer still needs sufficient tokens. Tokens received later can consequently increase the balance exposed to an existing allowance. Balance and permission therefore need separate readings, expressed in the same token units.

A cap equal to the intended transfer amount leaves no unused permission after that amount is fully spent under standard finite accounting.

Effectively unlimited approvals

Some implementations treat the maximum unsigned integer as effectively unlimited and leave that allowance unchanged after spending. This supports repeated use without fresh approvals. It also leaves substantial standing permission over that token. A compromised spender may move approved tokens without another approval prompt if an attacker controls the spender account or can make the spender contract initiate the transfer. A finite cap reduces the exposed quantity. It does not establish that the spender's behavior is acceptable, or reserve the approved tokens for a particular application outcome.

Can a signature replace an approval transaction?

ERC-2612 permits can replace the owner's standalone approval transaction when the token and application support that method. The owner signs an EIP-712 structured message, and an on-chain permit call applies the authorization. A compatible application can combine permit execution and token spending within the same transaction. Signing the message alone leaves the recorded allowance unchanged. The integration must support the selected token's actual permit format; a function named permit does not establish universal compatibility.

The signed authorization identifies the owner, spender, amount, nonce, and deadline. Its signing domain distinguishes the relevant contract and chain. The nonce prevents reuse after successful permit execution. The person or service submitting the signature can differ from the token owner, so submission arrangements also affect when the permission takes effect.

View image file

An ERC-2612 permit rejects execution after its signed deadline. That deadline limits when the signed authorization can take effect on the chain. It does not automatically expire the allowance that a successful standard permit creates. A token that implements expiring allowances can impose a separate deadline on spending.

Approval costs on the public network

Standalone approvals and revocations consume transaction gas on the public Scroll network, paid in ETH. The spending cap does not quote that cost. Fees reflect execution and the applicable Ethereum data fee. A new standalone approval adds another paid transaction when the selected flow needs one. Existing usable permission avoids that extra approval transaction. A permit signature changes how authorization reaches the chain; the transaction that submits it still has an execution cost that someone pays.

Changing permission and stopping future spending

Replacing a nonzero allowance

A standard approve call replaces the current allowance with the specified value. Changing directly between nonzero values creates an ordering risk: the spender may use the old allowance before the update and then access the new allowance. Resetting permission to zero before setting a new amount mitigates this replacement risk. Some tokens also require that reset for compatibility. For separate wallet transactions, the reset must take effect before the replacement grant. The old permission remains available until the reset executes.

Revoking the remaining allowance

Setting the standard allowance to zero removes future spending permission through that allowance after the update executes. Disconnecting the wallet from an application does not alter this stored permission. Grants to other spender addresses remain separate records. An unused ERC-2612 permit can set permission again if its signature, nonce, and deadline remain valid. The remaining allowance read from the affected token contract describes this particular owner-spender pair.

When does a direct token transfer avoid approval?

A direct transfer from the token owner uses transfer and does not require a separate ERC-20 allowance.

This operation moves tokens to the specified recipient from the caller's own balance. It fits an intended address-to-address token payment. Sending tokens directly to an application contract can change that contract's balance without crediting a deposit position. The application determines how it recognizes deposits and permits withdrawals. Tokens sent to a contract with no suitable recovery function may remain inaccessible. Where a deposit function pulls tokens and records the position, that application call connects the transfer with its accounting.

Scroll questions worth asking

8 Oct 2026 · updated