Paraswap token approvals grant spending permission to the contract for the selected execution mode

Paraswap token approvals authorize a specific contract to spend an ERC-20 token on a particular chain. Market swaps, Delta orders and AugustusRFQ trades use different spenders. Paraswap now uses the Velora name. The live allowance shows spending permission; a submitted approval alone does not confirm a swap or order fill.

Key takeaway: A confirmed approval is usable only when the intended spender has enough allowance for the source token on the correct chain.

Confirmed Permission for the Intended Contract

A sufficient on-chain allowance establishes spending permission for the intended contract, independently of any later swap or order fill. An allowance is the amount that a token owner lets a named spender withdraw. The token contract stores this permission for that owner and spender on that chain. Reading allowance(owner, spender) returns the remaining authorized amount in the token’s raw units. A successful approval transaction can update it, while a pending transaction provides no confirmed allowance change.

The Spender for Each Execution Mode

The returned execution mode identifies the settlement contract that is the spender for direct ERC-20 approval on the trade’s source chain.

Market Swaps Through Augustus v6.2

For Market swaps using Augustus v6.2, that router is the direct spender. The approval transaction calls the source token’s contract and names Augustus v6.2 as the spender. The swap transaction subsequently calls the router to execute the route. An allowance for another router address does not authorize this deployment, even when both addresses belong to the same protocol.

Delta Orders

Delta swaps, limit orders and TWAP orders use the Delta contract for direct source-token approval. The quote exposes its address as delta.spender , which identifies the allowance that the selected flow needs. Delta handles settlement gas within its execution flow, while a separate on-chain token approval costs gas. An existing sufficient allowance avoids another approval for that source requirement.

AugustusRFQ Maker and Taker Permissions

AugustusRFQ settles OTC and firm RFQ orders through its own contract. OTC means over-the-counter trading; RFQ means request for quote. In a direct-approval OTC flow, the maker authorizes AugustusRFQ for the maker asset, while the taker authorizes the asset they pay. Both permissions concern the RFQ contract on the order’s chain. OTC posting also accepts optional permitMakerAsset data for supported maker authorization. The signed offer still needs an on-chain fill to exchange the assets.

When Can a Permit Replace an Approval Transaction?

A supported permit can replace a separate direct-approval transaction for an immediate swap when the token and selected integration support that authorization method.

Immediate Swap Authorization

EIP-2612 lets a compatible token accept a signed message that sets spending permission. Delta and Market accept supported permit payloads through their build calls. The message identifies the spender and allowed amount, with a deadline limiting when the contract can accept it. Changing execution mode requires authorization for the new spender; a signature naming another spender cannot carry over.

Permit2 requires an underlying ERC-20 approval to the Permit2 contract before it can move the selected token. Its signature then authorizes the integration’s spender within that system. A first use of Permit2 can therefore require a paid approval transaction, even when subsequent authorizations use signatures. Direct router allowance and Permit2’s underlying allowance represent different permission layers.

Resting Limit and TWAP Orders

For ERC-20 sources, Delta’s limit-order and TWAP integrations require standing on-chain allowance covering the source requirement. Passing a permit payload to the build does not replace that requirement. A limit order may rest until its price becomes executable. A TWAP, or time-weighted average price order, divides execution into scheduled slices. Its allowance must cover the scheduled source requirement, not merely one slice. Existing sufficient approval remains usable while its allowance lasts.

Bounded Amounts and Lasting Access

An amount-limited approval caps what the spender may draw, while an unlimited approval leaves broader permission available for that token. The MaxUint256 option represents the maximum unsigned 256-bit allowance, commonly described as unlimited. That permission still belongs to the specified spender. It does not extend to every contract using the protocol’s name, and a mode change can require a different authorization.

View full-size image

A larger allowance creates no additional token balance. Execution still needs enough source tokens for the trade.

Raw token units determine whether an allowance covers the source requirement. The source token’s decimal precision converts the displayed quantity into those units; destination-token quantities cannot substitute for the input requirement. For a SELL swap, slippage tolerance governs acceptable output, while allowance governs permission to draw input tokens. Increasing tolerance cannot repair an insufficient source allowance.

Native Tokens Without ERC-20 Approval

Native ETH has no ERC-20 allowance; Market sends it with the swap, while Delta uses a separate deposit-based authorization when existing dETH cannot fund the order.

Native Input for Market and OTC

A Market transaction carries native input in its value field. AugustusRFQ OTC settlement requires wrapping native ETH first, after which the wrapped token follows ERC-20 authorization.

Delta Deposits and Existing dETH

A native-source Delta order without sufficient dETH needs a deposit that also authorizes the order. The integration first submits the order with signature: "0x" , leaving it in AWAITING_SIGNATURE . The user’s depositNativeAndPreSign transaction then supplies funds and records authorization on-chain. The deposit represents native funds as dETH, Delta’s wrapped-native token, at a 1:1 rate and costs gas. Existing sufficient dETH supports ordinary off-chain signing without another deposit or ERC-20 approval. Receiving native ETH does not require the recipient to make a source deposit.

Revocation After a Failed or Cancelled Trade

An unused ERC-20 allowance can remain after a failed swap or cancelled order because trade status and spending permission are separate. A Market revert does not erase an earlier successful approval. Cancelling a Delta order invalidates that order without zeroing its direct token allowance. Revocation changes the allowance itself, so cancelling an order and withdrawing spending permission accomplish different tasks.

A successful approve(spender, 0) removes the direct allowance for that spender and token on that chain. This transaction costs gas and cannot reverse a completed transfer. Other spenders retain their own permissions. Permit2 also has its own authorization layer, so clearing a direct Delta or Augustus allowance does not clear an underlying Permit2 approval.

Native funding needs different handling. Cancelling a native Delta order leaves dETH available for reuse or withdrawal. Unfilled native-source swap and limit orders refund their deposits automatically on expiry; expired native TWAP orders leave the unspent remainder as withdrawable dETH. Removing that dETH while an order remains open can make its funding insufficient, causing suspension or failure.

Helpful answers about Paraswap token approvals