Derpdex
Derpdex swap requirements and concentrated liquidity
Derpdex is a decentralized exchange built around token swaps and liquidity that providers allocate within chosen price ranges. A swap requires compatible assets on the selected network, sufficient spending permission, and usable pool liquidity. Providing liquidity adds another decision: the price range within which your assets participate in trading. Access also matters. Swapping through an interface requires access and a usable quote; managing deposited liquidity requires identifying the existing position.
Swap access and an unavailable interface
The normal swap path uses a wallet-connected interface to prepare an exchange through the protocol's contracts. When that interface is unavailable, an existing position requires a different approach: identifying its network, owner, and position manager before considering any contract interaction. A missing interface alone doesn't establish whether funds are withdrawable.
The swap workflow separates spending permission from exchange execution. A swap review screen appears before submission; the on-chain transaction record establishes whether the submitted operation succeeded. An approval confirmation therefore doesn't establish that the requested exchange occurred.
For an existing liquidity position, a generic token transfer isn't a substitute for the position manager's withdrawal operations. Without the correct contract and position details, there's no reliable basis for constructing that transaction.
Wallet, router, pool, and position manager
The exchange has separate components for authorizing transactions, executing swaps, holding liquidity, and recording individual positions. Their relationship explains why a wallet connection, an approval, and a liquidity deposit have different effects.
Wallet and network
A wallet supplies the account that signs transactions. The account's assets and permissions belong to a particular network. Derpdex's documented deployments include zkSync Era, Base, and opBNB, with EVM-compatible wallets used for access. Those deployment names don't establish that every pool or interface remains available.
Router and pool
The router directs a swap through liquidity pools. Each pool contains the assets and pricing state used for execution. A factory creates pool contracts; its existence doesn't guarantee sufficient liquidity for a particular exchange.
Position manager
The position manager records individual liquidity positions. It connects a provider's ownership record with the pool and selected range. This distinction matters when locating deposited assets: a position can exist even when an interface doesn't display it.
Does token approval complete a Derpdex swap?
Token approval authorizes spending; it doesn't complete the swap. For an ERC-20 input, the spending contract needs sufficient permission for the amount it will transfer. A previously granted allowance can satisfy that requirement, so approval isn't necessarily required before every exchange.
An ERC-20 allowance specifies how much a spender may transfer from an owner's token balance. The allowance belongs to a particular owner, token, and spender. Permission granted to a different contract doesn't authorize the intended router. The swap remains a separate operation that uses the permitted tokens.
A spending cap also deserves attention when the wallet requests a signature. An amount beyond the intended transaction grants broader permission. The relevant comparison is between the requested cap and the planned input, rather than whether the wallet labels the request an approval.
Asset compatibility and available balances
Usable funds must exist on the network where the selected pool operates. Switching the wallet's network changes its view and transaction destination; it doesn't move assets between chains. A separate transfer or bridge operation may be necessary before an exchange becomes possible.
A token's symbol doesn't uniquely identify its contract. The selected token address and network must match the asset you intend to exchange. A token list can help identify assets, but inclusion doesn't establish that a particular pool has executable liquidity.
Transaction fees require their own funding. Having enough of the input token doesn't necessarily mean the account can pay network charges.
The balance available for trading must account for any native asset that also pays those charges. The appropriate reserve depends on the transaction estimate and the network's fee rules, rather than a universal amount.
Quotes, price movement, and transaction costs
A swap quote reflects the selected input and available execution path. Its output depends on pool liquidity, the fee that each pool charges, and market conditions when the transaction executes. Approval changes permission; it doesn't preserve a quoted exchange rate.
Price impact and slippage
Price impact describes how the trade itself changes execution prices within the available liquidity. Slippage concerns movement between the quoted outcome and execution. These effects have different causes, even when both reduce the amount received. A route through additional pools can provide an exchange path when no direct pool exists, provided the necessary liquidity is available.
Slippage tolerance defines acceptable movement. Raising it doesn't supply missing liquidity or repair an incorrect token selection.
Pool fees and network charges
Derpdex's pool model supports distinct trading fee tiers. The relevant tier belongs to the selected pool, so one percentage cannot describe every possible swap. A lower tier alone doesn't establish better execution when liquidity differs.
Network charges pay for transaction processing. A separate approval can add another charge before the exchange. Computational work and network conditions affect those costs; a fixed quoted cost cannot cover every transaction. An executed transaction that reverts can still consume gas.
Liquidity deposits and range exposure
Providing liquidity commits assets to a trading position with a selected price range. The current pool price and that range determine the required asset composition. This is a different commitment from swapping: the position continues to change composition as trading moves through its range.
A concentrated liquidity position stops earning swap fees while the pool price remains outside its selected range. At that point, the position holds one of the pool's assets. A narrower range concentrates participation within fewer prices, while a wider range covers more movement. Neither choice guarantees earnings.
Derpdex represents these positions with ERC-721 non-fungible tokens. Providers can hold multiple positions with different ranges, and trading fees aren't automatically reinvested by the basic position mechanism. A single-sided range can also convert an asset as price traverses it; subsequent price movement can reverse that conversion while liquidity remains deposited.
What needs to match before you sign?
The network, asset contracts, spending permission, and transaction limits must match the intended operation. For a liquidity deposit, the pool and range add further conditions.
- The wallet account and selected network contain the assets needed for the operation.
- The token contracts match the intended assets, and the selected route has usable liquidity.
- The requested spender and spending cap correspond to the intended transaction.
- The account can cover estimated network charges as well as the input amount.
- The swap's output limit, or the deposit's price range and asset amounts, reflects the commitment you intend to make.
An unresolved mismatch is a reason to pause before signing. Repeated approval requests won't repair an unavailable route or fund network charges. With those checks satisfied and the interface available, select the input and output tokens and enter the input amount. Review the quote and minimum output before signing. Grant sufficient spending permission if needed, then submit the separate swap transaction. Check its on-chain status and received tokens to confirm the exchange.
Transaction results and existing positions
A transaction's status must be interpreted alongside the operation it performed. A successful approval records permission. A successful swap records an exchange. For liquidity, the position record establishes ownership and allocation; the wallet's freely spendable token balance describes something different.
The transaction hash identifies the operation independently of the interface's display. Its status and token transfers help distinguish an executed swap from a pending request or failed call. An output token may require a wallet display update even when its transfer has completed.
Withdrawal requires the operations supported by the deployed position manager. Position ownership, any separate staking arrangement, and the contract's authorization rules can affect the available path. Don't assume that moving a position token releases its underlying assets, or that a function from another protocol applies here.
Choosing an exchange or a continuing position
A swap suits the immediate task of exchanging an input asset for an output asset at acceptable execution terms. Liquidity provision creates continuing exposure to a pool's prices and trading activity. Holding the assets in a wallet avoids that position-management commitment, although their market values can still change.
Compare a liquidity position's value, including earned fees, with the value of simply holding the original assets. Changes in their relative prices can leave the position worth less than those holdings, and fees may not offset the difference. For a swap, the relevant outcome is the amount received and the total transaction cost. If access is unavailable, managing an existing position remains a separate problem from choosing where to make a new exchange.
Derpdex: the short answers
Can disconnecting my wallet revoke token permissions?
Disconnecting a wallet doesn't revoke an ERC-20 allowance already recorded on the blockchain. Disconnection ends the interface's connection to the account. Changing spending permission requires a separate authorization change for the relevant token and spender. Treat wallet connection status and recorded token permissions as separate states.
Why can a token balance differ from the raw number in a contract?
A wallet can display a token balance using the token's decimal precision, while a contract returns the balance in its smallest units. The displayed amount can therefore differ from the raw integer without implying missing funds. Comparing balances requires the same token contract, account, network, and decimal interpretation.
Is a pool's trading fee the amount every liquidity provider receives?
A pool's trading fee isn't the amount each provider receives. Providers share eligible fees according to their active liquidity contribution at the prices traded, and the protocol's distribution rules can allocate part of the fees elsewhere. A displayed pool fee therefore doesn't describe an individual position's income or establish a return on its deposited assets.
Do I need both pool assets for every liquidity deposit?
The assets required depend on the selected range relative to the current pool price. A range containing that price generally requires both assets, while a range entirely to one side can require a single asset. The required quantities can change as the pool price moves before the deposit executes.
Will a failed swap always incur a network charge?
A swap that executes and then reverts can incur a charge for the computation performed. Rejecting a wallet request before broadcast is different because no transaction executes on the network. A wallet error alone doesn't distinguish those cases; an on-chain transaction record shows whether the network processed the attempt.