Matcha Buy/Sell Tax Checks Before You Swap

Sell-token deductions and buy-token receipts

The sell token funds the exchange, while the buy token is delivered to the recipient, and their transfer rules can affect different parts of the same swap. A sell-side tax can reduce the amount that reaches a liquidity pool. A buy-side tax can reduce the tokens delivered afterward. The settlement transaction needs to accommodate those movements, including deductions that ordinary transfer assumptions would miss. A quote that ignores them can demand an amount that the contracts cannot actually deliver.

Read a displayed tax against its token and trade direction. Both sides of a swap can carry a charge, with each deduction applied under its own contract rules. Adding the displayed percentages does not necessarily give a single percentage loss: the charges concern different assets and transfer amounts. The quoted buy amount provides the combined estimate for the proposed exchange, with detected taxes already included. Subtracting those taxes again would count the same deductions twice.

Does a buy tax predict the cost of selling?

A buy tax does not establish the sell tax, because a token can impose different charges when it enters and leaves a trading position. The purchase quote concerns acquisition under the conditions simulated for that trade. A later sale has its own direction, amount, wallet, and execution time. Those conditions may activate different rules. A successful purchase therefore provides no assurance that selling later will have the same deduction or remain unrestricted.

Tax designs and trader control

Fee-on-transfer contracts can use several tax designs together, so the same token may behave differently across transactions. The applicable deduction follows the token's code and any permitted parameter changes. Choosing a swap amount or direction does not give the trader authority to rewrite those rules.

Real-time simulation and compatible routing

Matcha's tax support combines detection with routing, so the quote and execution path account for custom transfers together. 0x API v2 simulates token transfers to detect buy and sell taxes for the proposed swap. This gives the pricing engine information about the amount that a transfer actually delivers. The router then seeks compatible liquidity sources, including automated market maker (AMM) pools that can accommodate fee-on-transfer behavior. A token appearing in a pool does not by itself establish that every swap method handles its deductions correctly.

The chosen route needs settlement logic that works with the token's transfers. Tax-aware routing addresses that compatibility problem; it does not switch off the token's fee. Simulation also describes the conditions evaluated for a proposed trade. It cannot reserve liquidity or prevent a permitted contract change before the transaction executes.

Token taxes, swap fees, and network gas

A token tax, the trading service's swap fee, and network gas pay for different things, even when their effects appear in the same quote. Matcha does not receive the token-level buy or sell tax. The token's own rules determine its destination or use. Depending on the implementation, deductions may fund a project treasury, burn tokens, support a charity, or distribute rewards. A tax label alone does not identify the recipient or prove that the allocation benefits token holders.

With Matcha Standard, you pay network gas separately from any swap fee. Matcha Auto includes the network cost in its quote for eligible gasless execution. Both modes can involve a swap fee, with the fee structure depending on the trade. Gasless execution concerns how network costs are paid; a token's transfer deduction remains a separate cost. Compare quotes on a consistent basis, including whether gas is inside the displayed amount or payable separately.

Can raising slippage tolerance remove a token tax?

Raising slippage tolerance cannot remove a token tax; it increases the deterioration in execution terms that the swap permits. A wider tolerance may let an otherwise failing transaction complete when its output falls short, including on systems that mishandle taxed transfers. It does not repair the token's rules or explain the deduction. Excessive tolerance can also create room for sandwich attacks. A tax-aware quote should account for detected taxes without treating a larger slippage setting as the tax itself.

Price impact alongside transfer deductions

Price impact measures how the trade itself affects market pricing, whereas a token tax deducts an amount under the token's transfer rules. A trade against shallow liquidity can produce poor exchange terms even when the token charges no tax. A taxed token can also have sufficient liquidity and still impose a deduction. Deeper liquidity can reduce price impact, while any applicable transfer tax follows the token's rules. The proposed amount matters to both, though for different reasons.

A larger order can consume liquidity at progressively worse prices. A custom token may also apply amount-dependent taxes. Changing the order size therefore requires a new quote; proportional arithmetic alone may miss either effect. Slippage adds another distinction: market conditions can change between quoting and execution.

Contract powers behind a low displayed tax

Token security indicators describe contract powers that a swap's tax estimate cannot resolve, including whether transfers can stop or tax rates can change. Matcha displays security information powered by GoPlus Security on token pages. The indicators concern known code properties and detected risks. They supplement the transaction-specific tax estimate with information about how the token might behave under other conditions.

A token with modifiable tax settings can allow its administrator to change buy or sell rates. Address-specific controls can also impose different charges on different wallets. A modest rate in the proposed purchase says nothing about how an administrator will use those powers later.

Transfer restrictions can prevent disposal independently of the quoted percentage. A contract may pause transfers, block an address, impose a trading cooldown, or restrict selling the entire balance. A tax-aware swap route cannot override restrictions that the token enforces.

View image file

Proxy contracts and external calls can make the relevant behavior harder to assess. A proxy may point to an implementation that can change, while an external call introduces behavior from another contract. The presence of these features does not establish malicious intent. Their meaning comes from the actual permissions and implementation, including which changes remain possible and who can authorize them.

An unknown security result leaves that property unresolved. A scan with no detected issue does not establish unrestricted future selling, and a successful simulation cannot substitute for understanding retained contract powers.

Quote conditions and stale tax information

Tax information belongs to the proposed trade's conditions, including its wallet, amount, direction, and liquidity route. A previously recorded rate may describe a different transaction. Static token databases can miss conditional rules or retain values after the contract's behavior changes. The relevant estimate is the one that corresponds to the swap being considered, rather than a rate copied from an earlier trade or another wallet.

An address-specific tax can remain invisible in a calculation prepared for a different wallet.

Execution timing matters even when those inputs stay the same. Available liquidity can change after quoting, and permitted tax updates can alter transfer behavior. A fresh quote reduces reliance on stale conditions; it does not freeze blockchain state.

Allowances and failed settlement

Tax detection cannot supply a missing token balance or spending permission. Those requirements must be satisfied independently.

A failed swap may involve insufficient balance, inadequate allowance, unavailable liquidity, or a token restriction. The presence of a tax does not identify which requirement failed. An allowance sets how much the designated spender may take from a wallet. When an EVM swap through 0x API v2 needs token allowance, its quote identifies the spender as AllowanceHolder or Permit2. The Settler contract is not an approval target. Raising an allowance cannot make a taxed token deliver its gross transfer amount.

Approval permissions also differ from the token administrator's powers. The spender receives authorization to use the token; the token contract continues to govern deductions and restrictions. A mined transaction that reverts during EVM execution can still consume gas. Diagnosing the actual failure before resubmitting avoids repeatedly paying execution costs for an unchanged allowance, liquidity, or contract problem.

Quoted output and the settled receipt

The quoted buy amount estimates the tokens delivered by the proposed swap, while settlement establishes what the recipient actually received. The permitted minimum output also matters: it defines the execution boundary under the selected slippage terms. An estimate and a minimum serve different purposes. Detected taxes belong in the quote calculation, while the transaction must satisfy its settlement conditions to complete. Transaction records can contain several transfers through pools and settlement contracts.

A transfer into an intermediate contract does not establish the final recipient's receipt. The amount credited to the intended recipient answers the tax-adjusted delivery question. Network gas paid separately should remain separate from that token amount when interpreting the cost.

A later wallet transfer is a separate event. If the token taxes that movement, the balance afterward may differ from the amount originally credited by the swap. The settled swap amount remains the relevant figure for assessing the quoted delivery.