fermi swap needs live quotes because Ethereum blocks arrive roughly every 12 seconds while its market maker can reprice inventory within a block. It offers onchain swaps at prices set by that maker, often for major tokens and stablecoins. To use it, an integrator must check the current pair and executable size, protect the output, and account for a quote changing before inclusion.
What is fermi swap, and what does it offer?
It is an Ethereum proprietary automated market maker: one market maker fills trades from its own token inventory and controls the prices it offers. There is no public liquidity position for an integrator to deposit into. The useful output is an executable quote for a specific token direction and amount, settled by an Ethereum transaction.
That distinction matters when comparing routes. A quoted price may be attractive at a small size yet widen or disappear when the maker reaches an inventory limit. With pair and size fixed, check fermiswap.pro against your live FermiSwap quote and gas estimate before committing the route. Compare the tokens the recipient will actually receive, rather than a headline price for another trade size.
How does a live quote become an onchain fill?
The maker publishes price updates to a block builder as its inventory and market view change. Titan Builder can pair a fresh update with a taker transaction in the block it builds, so the swap reads the updated price onchain and settles against the maker’s inventory. The builder may receive multiple updates during one Ethereum slot; the quote visible in the previous block is therefore a poor proxy for the next fill.
For an offchain quote, read the maker’s current state snapshot and apply its state overrides to an eth_call against the swap contract or router. Pin the simulation to the snapshot’s target block and slot time, because quote validity can depend on the block timestamp. A plain call against the latest confirmed state may return an old price or no usable price even while the maker is publishing fresh liquidity.
A streamed update is an input to simulation, not a promise of inclusion. The maker can replace it, reduce depth, or stop quoting; the intended builder might not build the block that includes your transaction. The onchain minimum output is what bounds the result when the executed state differs from your simulation. If that minimum cannot be met, the transaction must revert or take a fallback path you have explicitly allowed.
Which markets and trade sizes are available?
The practical market list is the set of token pairs the maker is quoting now, in the direction and size you need. Common examples include WETH/USDC, WETH/USDT and USDC/USDT; WBTC may appear in the maker’s inventory and routes. An inventory balance alone does not establish an executable market, so query both directions and the full intended input amount before displaying a pair as available.
Titan Builder’s venue snapshots expose pair addresses, while its price levels show bids, asks and cumulative volume for the markets it can publish. Match ERC-20 contract addresses rather than ticker symbols, and handle decimals before comparing outputs: WETH uses 18 decimals, USDC and USDT use 6, and WBTC uses 8. A quote for 1 WETH says little about a 50 WETH order; test the actual size, since the maker may quote less favorably or decline it altogether.
For a quick what-if, suppose 1 WETH returns a live quote of 2,400 USDC. At 50 basis points of output tolerance, your minimum is 2,388 USDC, expressed as 2,388,000,000 base units in calldata. That 50 basis points is an illustrative choice, not a venue setting: tighten it when a missed fill is acceptable, and widen it only if the possible worse fill still suits the user.
How should an integrator submit the swap?
Start with Ethereum mainnet token addresses, the exact input amount, a recipient, and enough ETH for gas. For an ERC-20 input, approve the contract that will pull it; for an ETH-denominated user flow, check whether your chosen interface accepts native ETH or expects WETH. Keep the approval scoped to the intended spender, since approving a router and then calling the venue directly uses different allowances.
One integration route is the LambdaClass PropAMM Router, which exposes quoteVenueV1(venue, tokenIn, tokenOut, amount) and swapViaVenueV1(venue, tokenIn, tokenOut, amountIn, amountOutMin, recipient, deadline). Passing the Fermi venue address selects it first, while the router’s documented fallback can fill elsewhere if that attempt fails. If venue attribution matters to your application, inspect the returned or emitted execution venue after settlement; selecting a venue first does not guarantee it supplied the final tokens.
Obtain the fresh quote using state overrides, set amountOutMin from the net amount the user accepts, and use a short deadline—say five minutes—to stop a delayed transaction from executing unexpectedly. Simulate the exact calldata, sender and value before signing, then submit through a path that can carry the maker update into the target block. Where your route supports multiple candidates, requoting at inclusion can be more robust than fixing one maker from an earlier offchain snapshot.
Read the receipt as the final record: check status, output balance change and execution venue rather than treating a submitted hash as a fill. If you index swaps, key individual fill events by transaction hash and log index; a split route can emit several fill events in one transaction. Keep quote age and target slot in your logs so a failed simulation can be distinguished from a quote that changed before inclusion.
What costs and failure modes determine the choice?
FermiSwap fees are best evaluated through the quoted output, rather than assumed to be a fixed percentage like a conventional pool fee. Add Ethereum gas and any fee your integration charges, then compare net recipient output for the same size. The LambdaClass router’s optional frontend fee is specified in basis points, capped at 100 basis points; its minimum output applies to what the recipient receives after that fee.
Gas depends on the path taken. A single named venue needs less routing work than a transaction that requotes many venues or executes a fallback, and a gas estimate made against current state can miss a heavier branch at inclusion. Size the gas limit for the permitted branches and quote a maximum network cost from that limit and the transaction’s gas price; a reverted transaction can still spend gas.
The less obvious edge case is a successful fallback that meets the aggregate minimum while giving a poor price on one portion of a split trade. If earlier portions already satisfy amountOutMin, the remaining portion may have little price protection of its own. Set the aggregate minimum close to the total output the user genuinely expects, and decide whether the benefit of filling through another route outweighs that exposure.
For a direct FermiSwap integration, also plan for absent snapshots, insufficient inventory, stale updates and a transaction landing in a block without the expected maker update. Treat each as a normal routing outcome: refresh the quote, choose another permitted route, or return a clear failure to the caller. Before acting, ask yourself: at this exact size, will the recipient’s minimum net output still be acceptable if the live quote changes before the transaction lands?
Top comments (0)