The displayed output amount in a shiba swap quote is the raw integer estimate divided by 10 raised to the output token’s decimals, valid only for the pool state observed. Because that state can change, your application must preserve quote context, enforce execution limits, and record the amount actually settled.
- A quote estimates output for a particular chain, input amount, route, and observed block. It does not reserve liquidity.
- Execution must use the intended contract and enforce the accepted recipient, minimum output, and any supported expiry.
- Confirmed transfers establish the result; quoted, minimum, and settled output are separate amounts.
A Quote Describes One Route at One Observed Block
A quote describes what a specified input would produce through specified pools at the state used for quotation. Store the chain ID, input and output token contracts, raw input amount, ordered route, pool fee tier where applicable, observed block number or hash, and raw quoted output together. Retain the quote source and the contract deployment or version it used. Two routes with the same token symbols are different requests, even when their displayed estimates happen to match.
ShibaSwap operates across Ethereum and Shibarium, with versions that use different pool designs. Your application might obtain an estimate from a quoter, pool reads, or an SDK; the record should say which method produced it. The block context lets you explain the estimate later, but it cannot preserve that pool state for a future transaction. Trades and liquidity changes after quotation can alter the output.
Give each accepted quote an identity that survives the move from the screen to the transaction request. If a refresh chooses another route, create a new quote record and present its output and constraints for acceptance. Silently replacing the route would leave the application unable to say which estimate the user acted on.
Verified Token Units Make Quote Amounts Meaningful
Token decimals determine how raw integers become displayed amounts. Read and verify decimals for the token contract on the selected network, then keep calculations in integer units until display. For an output token with d decimals, displayed output is raw output divided by 10 raised to d. Converting through floating point can round a minimum output upward or make two distinct raw amounts look equal on screen.
Identify each asset by network and contract, not its symbol. A shiba swap request involving a token called BONE on one network must not inherit metadata or allowances from an asset with the same symbol on another. Native BONE used for Shibarium gas also has a different accounting role from an ERC-20 token in the swap route. Model native currency explicitly when a deployed interface supports wrapping or unwrapping it.
Keep quoted output, minimum output, and settled output as separate raw integers in the output token’s units. The quoted amount is the estimate; the minimum is the lower bound the user accepts for execution; the settled amount comes from the confirmed transaction. A display layer may shorten decimals, but it must not turn a rounded display value back into an execution constraint.
Pool Pricing and Native Gas Are Different Costs
A route quote reflects the pools’ pricing, including the trading fees applicable to its hops. Price impact describes how the trade changes the execution price relative to a reference price for those pools. Neither figure is the transaction’s native gas cost, and price impact is not the slippage limit enforced by a minimum output.
Estimate gas separately for the proposed call on its selected network. Ethereum gas is paid in ETH; Shibarium gas is paid in BONE. Gas usage and the native currency price can change before inclusion, so label that cost as an estimate too. ShibaSwap’s quoted output should remain in the output token’s units, while the gas estimate stays in native currency units. Combining them into a single “received” number would require an exchange rate and would obscure what the swap contract can enforce.
Execution Must Enforce the Accepted Bounds
Execution must turn the accepted quote into a call whose constraints the deployed contract can enforce. Confirm the active chain, router or other execution target, token path, input amount, recipient, and allowance spender against the accepted record. The spender is the address approved to take the input token; it must match the allowance target required by the chosen method. A valid quote does not make an approval to a different spender useful.
Derive the minimum output from the accepted quote and slippage policy in raw output units, then pass it to a method that enforces that floor. Use a deadline or expiry only when that specific deployed method supports one, and make its meaning clear in the application. Do not present a screen timer as an on-chain expiry if the call has no such constraint. The recipient deserves the same care: a successful swap sent to another address does not satisfy the application’s intended delivery.
Verify the deployed interface before constructing that call. ShibaSwap v2 has Uniswap v3 ancestry, but ancestry alone does not establish identical ABIs, contract addresses, or supported quoting and execution methods. The selected network and version determine which parameters and safeguards are available. Treat unsupported features as integration decisions to resolve, not fields to fill with guessed defaults.
Refreshing the quote narrows the time between observation and submission. Simulating the exact proposed call can expose a likely revert, an allowance problem, or a failed minimum at the simulated state. Neither step guarantees later execution: another transaction can change pool state before this one is included. The enforceable minimum, rather than the freshness label on the quote, defines the output bound.
Confirmed Transfers Close the Swap Record
A confirmed transaction closes the record only after you establish what the recipient received. Store the transaction hash, chain, receipt status and block, executed route when observable, gas paid, and output transfer or balance change. A receipt marked successful establishes that the call completed; it does not by itself supply the recipient’s final output amount.
For a straightforward ERC-20 output, relevant transfer logs can identify the delivered amount. Compare them with the recipient’s balance change when token behavior or a complex call makes logs alone ambiguous. Tokens that charge transfer fees are a useful boundary case: the router’s reported output can differ from the recipient’s gain. Support them only if the selected execution method can enforce the amount your application promises to the recipient, or exclude them from that promise.
Reconcile the confirmed amount with the accepted record before marking the swap filled. At shibaswap.app, review each shiba swap record using its quoted output, enforced minimum, and settled output as three distinct values. That comparison shows whether the application reported an estimate accurately and whether execution met the bound the user accepted.