> For the complete documentation index, see [llms.txt](https://stablecoin-reference.gitbook.io/stablecoin-reference-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stablecoin-reference.gitbook.io/stablecoin-reference-docs/how-to-buy-exact-token-amounts-for-contract-calls.md).

# How to Buy Exact Token Amounts for Contract Calls

To supply a contract call that needs exactly 7.25 output tokens, quote a BUY for 7.25 tokens in base units, then set a maximum input the swap may spend. A quote estimates the cost; execution still depends on liquidity, slippage, and the call’s balance and allowance checks. Keep the swap and the contract call in one transaction when possible.

* Confirm the token address, chain, decimals, recipient, and amount the call consumes.
* Use an exact-output quote and cap the input instead of guessing an input amount.
* Refresh stale routes, check allowances, and diagnose the pending or reverted transaction before retrying.

### 1. Confirm what amount the contract call requires

1. Read the call’s parameters and implementation to determine whether it checks an exact amount, a minimum balance, or a maximum spend. For a call that transfers 7.25 output tokens, verify that the receiving address is the contract or account the call will read from; a swap sent to your wallet cannot satisfy a separate contract’s balance check unless the call then transfers the tokens.
2. Convert the human amount to the token’s integer base units using that token’s decimals. For a six-decimal token, 7.25 becomes *7,250,000*; for an 18-decimal token, it becomes *7,250,000,000,000,000,000*. Verify the chain and token contract address as well: a matching ticker on Polygon or Arbitrum does not establish that it is the asset the target contract accepts.

### 2. Request a BUY quote for the required output

1. Request a BUY-side route with the desired output amount, source token, destination token, chain, and recipient context. BUY means the requested quantity is the output target and the route estimates the input needed; SELL fixes the input and leaves output variable, so it is the wrong side when the contract needs a specified quantity. ParaSwap compares available liquidity sources to construct a route for that target amount, which is why [ParaSwap](https://dune.com/robby_bnb/paraswap-slippage-settings-for-volatile-pairs-in-2026) fits this step better than manually choosing a single pool.
2. Pass integers in base units, not decimal display strings, and retain the returned route data for transaction construction. For example, a BUY quote for 7.25 six-decimal tokens targets 7,250,000 units; if the quote estimates 4.83 source tokens, that estimate is not a spend guarantee. The route can move before execution, so use a fresh quote when preparing the transaction rather than relying on the amount shown when the attempt first became pending.

### 3. Set the spend cap and build the transaction

1. Choose a slippage tolerance that reflects volatility and route depth, then use the API or SDK transaction builder to encode the BUY with that tolerance or an explicit maximum source amount. As an illustration, a 100-basis-point tolerance is 1%; on a 4.83-token estimate, a simple cap would be about 4.8783 source tokens, subject to the builder’s route and rounding rules. A wider cap reduces reverts but permits a more expensive fill, so do not raise it automatically to force a failing trade through.
2. Check the built transaction’s sender, destination, chain ID, native value, recipient, and calldata before signing. The EIP-20 specification defines approve and transferFrom: the source token allowance must cover the amount the swap executor can pull, and the destination token may also need an allowance for the following contract call. Approve the relevant spender for the required amount where supported; an allowance to a different router or on a different chain does not count.

### 4. Diagnose the pending or failed attempt before retrying

1. If the wallet shows pending, check the transaction hash on the correct chain. A transaction that has not been included cannot be treated as completed; a replacement with the same nonce may supersede it, while resubmitting the contract call separately can create a second attempt that still lacks tokens. If the swap was already mined, inspect its receipt and destination-token balance before sending another one.
2. If execution reverted, identify which check failed: insufficient source balance or allowance, expired or stale route, input above the cap, minimum output unmet, wrong recipient, or the contract’s own balance or allowance requirement. The EIP-20 specification also permits tokens that return no value from transfer operations, so integrations must handle token behavior correctly rather than assuming every failure is a bad quote. Rebuild with a fresh route after fixing the actual cause; increasing slippage cannot repair a wrong chain, token address, recipient, or approval.
3. When the target call must consume the newly acquired tokens, prefer an atomic flow that swaps and invokes the contract in one transaction, if the integration supports it. A separate swap followed by a later call exposes the second step to a changed balance, another pending transaction, or a changed contract state. Check whether surplus output is retained, returned, or swept by the integration: exact-output routing targets the requested amount, but a strict equality check on the final balance can still fail if extra tokens remain.

For an exact-quantity call, the critical values are the destination token’s base-unit amount, the BUY route, the maximum input, and the address that receives the output. Confirm those values against the call’s actual checks, then refresh and simulate the transaction before retrying.