Why does the UniSat integration show a BTC prefund error?

The documented UniSat integration checks whether its Particle account abstraction wallet has enough BTC for gas. An insufficient balance triggers a prefund error before execution. This concerns the smart contract wallet handling the Merlin Chain transaction. A balance shown elsewhere in the connected wallet does not establish that this account can cover the gas requirement.

Which token standard does the underlying iZiSwap pool design use?

The underlying iZiSwap pool model requires its token contracts to implement ERC-20. ERC-20 defines a standard interface for fungible tokens, including balances and transfers. A token’s association with the Bitcoin ecosystem does not by itself establish compatibility with a particular pool. The actual token contracts and the pool’s selected pair determine which assets participate.

Does connecting a wallet approve tokens for a liquidity deposit?

Connecting a wallet and approving a token for a liquidity deposit are separate authorizations. The documented liquidity interface includes token approval before adding the position. Approval grants the relevant contract spending permission; it does not by itself establish a completed liquidity deposit. The position also depends on the selected pair, fee tier, range and token amounts.

What does the pool overview’s 24-hour volume measure?

The pool overview’s 24-hour volume measures trading activity over that period. It differs from pool liquidity, which concerns available capital, and APR, which expresses an annualized percentage. None of these figures alone gives the amount a particular liquidity position has earned.

Can I reuse Merlin Chain mainnet contract addresses on testnet?

Mainnet and testnet require their own deployment addresses. The separate testnet record, updated January 19, 2024, identifies Merlin Chain Testnet as chain ID 686868 and lists its own contracts. Matching contract names describe corresponding functions across environments. They do not make the deployments interchangeable.

Is JavaScript necessary to display the exchange application?

The exchange application requires JavaScript to render its interface. With JavaScript disabled, it displays a message asking for it to be enabled.

Merlinswap uses an AMM for token trading on Merlin Chain

Updated on 16th October 2026

Merlinswap is a decentralized exchange on Merlin Chain, a Bitcoin layer-2 network, using iZiSwap’s concentrated liquidity automated market maker. An AMM exchanges tokens against liquidity supplied to pools. The platform combines swaps, limit orders and liquidity provision, alongside a token incentive model involving MP and esMP. Wallet integrations provide access to accounts on Merlin Chain. The main choices concern the exchange price, available liquidity and whether the task involves trading tokens or supplying capital to a pool.

Swaps draw from liquidity pools on Merlin Chain

A swap exchanges tokens through available pool liquidity. The iZiSwap engine draws from ordinary liquidity positions and limit orders, with the direction of the exchange determining which token it consumes and the available depth determining how far execution moves through the pool. A pool’s total balance alone does not describe the depth available around that price.

A quote estimates an exchange under a particular pool state. Prices and available liquidity can change before execution. The amount shown while preparing a trade therefore describes expected output, not an already completed exchange.

iZiSwap organizes concentrated liquidity at discrete prices

Concentrated liquidity places capital within a selected price range. iZiSwap represents that range as discrete price points, also called ticks, each with a defined exchange price. A swap uses liquidity at the current point and moves onward when that liquidity runs out. Range positions and fixed-price orders can therefore contribute to a common trading engine. A trade spanning several points can have a different average execution price from the starting price.

View image file

How do limit orders fit into Merlinswap trading?

Limit orders supply one-time liquidity at a selected price point within the iZiSwap design. This connects price-based orders to the same liquidity engine handling ordinary swaps.

A target price and incoming swap demand

An order trades when the price reaches its selected point and an incoming swap consumes its liquidity. A displayed price reaching the target does not alone establish a full fill, because execution depends on the swap demand reaching that point.

The executed portion after a price reversal

Ordinary liquidity can participate again when the price reverses. A limit order keeps the output tokens from its executed portion, so they do not automatically trade back when the price returns. The underlying iZiSwap design also requires order providers to claim traded tokens. Its grouped-order accounting handles these claims separately from swaps consuming the shared liquidity.

Wallet access depends on the integration

Trading requires access to the Merlin Chain account holding the relevant assets. The documented MetaMask and UniSat integrations connect to that account through different wallet arrangements.

MetaMask and Merlin Mainnet

The MetaMask integration uses a wallet connected to Merlin Mainnet. Although a wallet can support multiple networks, each network has its own balances and transaction context, so the selected account and the selected network both affect which assets are available for a Merlin Chain trade.

UniSat and the Particle smart contract wallet

The documented UniSat integration uses a Particle Network account abstraction wallet. This is a smart contract account with an EVM address. EVM means Ethereum Virtual Machine, the execution environment for these contract interactions. The relevant trading account is the Particle wallet shown within this integration.

Liquidity provision adds a price-range decision

Liquidity providers choose a token pair, fee tier and price range. Their capital supplies counterparties for swaps within that range. Outside it, a position consists of one token. Relative price changes can create impermanent loss compared with holding the original assets. Pool liquidity, trading volume and displayed APR describe different aspects of the pool. APR means annual percentage rate; its displayed value does not establish the final return from supplying liquidity.

MP and esMP have different roles in the token model

MP is the platform token, with a specified maximum supply of 21,000,000,000 MP. Maximum supply differs from circulating supply. esMP is its escrowed counterpart and has a governance role in token allocation and airdrop voting. Escrow introduces conditions on release, so an esMP allocation differs from an immediately available MP balance.

The documented exchange interface converts esMP into MP at a 1:1 ratio through linear vesting over 30 days. MP becomes claimable gradually. Starting another batch while esMP is already unlocking resets the ongoing vesting period. Distribution schedules for trading rewards and other allocations have their own timing. The conversion period therefore does not establish when a particular reward allocation first becomes available.

Static and dynamic liquidity mining also form part of the documented incentive design. Mining incentives are separate from the fees earned through trading activity in a pool. The documented dynamic-farm interface supports esMP staking to boost farm APR. A particular program’s terms determine participation and rewards.

Pool charges and network execution are separate costs

A pool’s fee tier determines its trading charge. Network gas pays for execution on Merlin Chain. These costs have different purposes and may use different assets.

The swap details show the liquidity provider fee alongside price impact. The fee is a charge for trading through the pool. Price impact describes the effect of consuming available liquidity. Its effect appears in the exchange rate, so a larger price impact can reduce output even when the fee tier stays unchanged.

Merlin Mainnet uses BTC for gas. A balance in another token cannot directly pay that BTC gas charge. The transaction needs a sufficient gas balance in the account handling execution.

Average price and minimum receive also describe different quantities. Average price concerns the exchange rate across the trade. Minimum receive sets the output floor for a swap with a specified input amount. The documented swap contract rejects the transaction if output falls below that minimum. Slippage concerns the difference between expected and actual execution prices. It differs from the price impact already reflected in a quote.

Read each amount in its own unit. Quoted output is what you expect to receive; gas is a separate BTC expense. Use a common valuation basis to compare input and output, then include gas when assessing the trade’s overall cost.

Core contracts connect the trading functions

The deployment separates underlying pool logic from contracts handling higher-level interactions. The Merlinswap 0.1 mainnet deployment record updated February 3, 2024 identifies Merlin Chain as chain ID 4200.

Core modules

The core listing includes a factory, directional swap modules, a liquidity module, a limit order module and a flash module. The iZiSwap architecture places the underlying swap, liquidity management and limit order logic in this layer.

Periphery and developer integration

The periphery listing includes quoters, a swap contract, a liquidity manager and a limit order manager. This layer provides higher-level interaction and management interfaces. Developer integration uses the associated iZiSwap design, SDK and API material. Contract-level support and the controls exposed by a particular application remain different aspects of access.

Choosing between a swap, an order and a liquidity position

A swap, a price-conditioned order and continuing liquidity provision give the same pool different uses. The intended use determines which function fits and which conditions matter:

For an exchange against available liquidity, use the swap quote to assess output and price impact.
For an order at a selected price point, account for the incoming swap demand needed to fill it.
For continuing participation as a liquidity provider, assess the selected range and exposure to changing token balances.
For incentive participation, distinguish pool trading fees from program rewards and their release conditions.

If the purpose changes from exchanging tokens to supplying capital, the relevant conditions change from execution terms to the position’s range and ongoing exposure.

Merlinswap: what people ask

Why does the UniSat integration show a BTC prefund error?: The documented UniSat integration checks whether its Particle account abstraction wallet has enough BTC for gas. An insufficient balance triggers a prefund error before execution. This concerns the smart contract wallet handling the Merlin Chain transaction. A balance shown elsewhere in the connected wallet does not establish that this account can cover the gas requirement.
Which token standard does the underlying iZiSwap pool design use?: The underlying iZiSwap pool model requires its token contracts to implement ERC-20. ERC-20 defines a standard interface for fungible tokens, including balances and transfers. A token’s association with the Bitcoin ecosystem does not by itself establish compatibility with a particular pool. The actual token contracts and the pool’s selected pair determine which assets participate.
Does connecting a wallet approve tokens for a liquidity deposit?: Connecting a wallet and approving a token for a liquidity deposit are separate authorizations. The documented liquidity interface includes token approval before adding the position. Approval grants the relevant contract spending permission; it does not by itself establish a completed liquidity deposit. The position also depends on the selected pair, fee tier, range and token amounts.
What does the pool overview’s 24-hour volume measure?: The pool overview’s 24-hour volume measures trading activity over that period. It differs from pool liquidity, which concerns available capital, and APR, which expresses an annualized percentage. None of these figures alone gives the amount a particular liquidity position has earned.
Can I reuse Merlin Chain mainnet contract addresses on testnet?: Mainnet and testnet require their own deployment addresses. The separate testnet record, updated January 19, 2024, identifies Merlin Chain Testnet as chain ID 686868 and lists its own contracts. Matching contract names describe corresponding functions across environments. They do not make the deployments interchangeable.
Is JavaScript necessary to display the exchange application?: The exchange application requires JavaScript to render its interface. With JavaScript disabled, it displays a message asking for it to be enabled.