Matcha swap: What each approval and signature authorizes

A matcha swap can ask you to approve a token, sign an order, or confirm an on-chain trade, and those prompts grant different powers. An approval lets a contract move a specified token amount from your wallet; a signature may authorize an order without sending a transaction; a transaction executes on-chain and usually costs gas. The wallet prompt is the useful dividing line: read what it names as spender, amount, and action before confirming.

The distinction matters because “approve” is not the same as “swap.” A token approval can remain usable after the screen closes, while a swap transaction is a single attempt to exchange assets at the quoted terms. For background on how the product is described, matchaswap.pro is one source; the permissions themselves are defined by the wallet request and the contracts involved. Matcha’s interface and supported routes can change, so treat the specific prompt in front of you as decisive.

What does a Matcha swap approval allow?

A Matcha swap approval allows a named contract to transfer a token from your wallet up to the approved amount. On Ethereum-style networks, an ERC-20 token contract records this permission as an allowance. It is separate from the transaction that performs the trade, which is why a first-time swap can require an approval transaction followed by a swap transaction.

There are two broad approaches to that permission. A direct approval names a router or aggregator contract as spender. If the allowance is larger than the trade—or unlimited—the spender may be able to move more of that token later, until the allowance is used, expires where applicable, or is revoked. A one-time approval design routes execution through an intermediary that uses the permission for a particular trade and consumes it in that transaction. That can reduce the time and amount exposed, but it still depends on the code and path used to execute the swap.

Matcha Meta’s One-Time Approval setting illustrates the difference. In January 2026, a vulnerability in an integrated third-party router, SwapNet, exposed users who had turned off the setting and approved that router directly. Matcha said its own and 0x’s AllowanceHolder and Settler contracts were not involved; it removed SwapNet and the option to turn off One-Time Approval. The episode showed that a permission granted to a route provider carries that provider’s risk, even when the trade began in an aggregator interface.

What do you sign for a Matcha limit order?

A limit order signature typically authorizes an order with defined terms, rather than immediately exchanging tokens. The order can specify the assets and amounts, the price condition and an expiry. A relayer or maker may later submit it for execution if the conditions are met; the signature itself is not an on-chain swap and does not, by itself, prove that the order has filled.

That does not mean an order signature is harmless or that no approval is ever needed. A contract must still have a valid way to receive the tokens when the order fills, which can involve a prior token allowance or a permit signature supported by the token and flow. Depending on the implementation, the wallet may show a token approval first, then a typed-data order signature. These are distinct permissions: the approval concerns token movement, while the signed order sets the trade instruction and its limits.

Compared with a market swap, a limit order trades certainty of timing for price control. A market swap attempts execution against a current quote; a limit order may wait, partially fill, expire, or never fill. Its signing step may avoid an on-chain transaction at placement, but execution still has to happen on-chain, and approvals may still be part of the setup.

How should you read each wallet prompt?

Matcha swap prompts are easiest to assess by separating the permission from the trade and checking the details against your intention. A concise check before signing is more useful than relying on a button label such as “confirm” or “place order.”

• Token approval: Check the token, spender address, and allowance amount. An unlimited amount creates broader standing permission than the amount needed for one trade.
• Typed-data signature: Check the wallet, network, token, amount, recipient or spender, expiry, and any displayed order terms. It is not a gas-paying transaction, but it can authorize an action under those terms.
• Swap transaction: Check the destination contract, input amount, minimum output or slippage terms, and network fee. This is the on-chain execution request.
• Cancellation or revocation: An unfilled signed order may need an order cancellation, while a token allowance may need a separate revoke transaction. Cancelling one does not necessarily remove the other.

For most users, the better default is the narrowest permission the supported flow offers, followed by a deliberate review of the trade itself. Smaller approvals can mean another approval step later; broad allowances are more convenient for repeat use but leave more permission outstanding. If you have used an older setting that approved individual aggregators directly, check existing allowances on the relevant networks and revoke any you no longer need. A new interface setting does not necessarily erase permissions already recorded by token contracts.

The next signals to watch are concrete: whether Matcha continues to route through one-time permissions, what spender and amount each wallet prompt displays, and whether a limit order’s expiry and fill status are visible before signing. Those details show what you authorize now—and what permission may remain after the trade.