Unsupported Tokens
Not all ERC-20 tokens are compatible with Rapiddex v3. Fee-on-transfer and rebasing tokens have non-standard transfer semantics that break protocol assumptions.
Fee-on-Transfer Tokens
Some tokens deduct a percentage of every transfer as a fee, so the recipient receives less than the amount
specified in the transfer() call. Rapiddex v3 router contracts are incompatible
with this behaviour.
The router assumes that when it sends amountIn tokens to the pool, the pool receives exactly
amountIn. If a transfer fee is deducted in transit, the pool's actual balance is less than
expected. This breaks the internal accounting and will cause the transaction to revert, or worse, execute with
an incorrect token balance.
Workarounds
- Token wrapper: deploy a standard ERC-20 wrapper contract that holds the fee-on-transfer token and issues 1:1 wrapper tokens without any transfer fee. Create a Rapiddex v3 pool for the wrapper token.
- Custom router: build a specialised router contract that accounts for the transfer fee by querying balances before and after each transfer. This is significantly more complex and is the responsibility of the token creator, not the protocol.
Rebasing Tokens
Rebasing tokens periodically adjust all token holder balances, either upward (positive rebase) or downward (negative rebase), without any transfer occurring. Examples include elastic-supply stablecoins and certain synthetic assets.
Unlike fee-on-transfer tokens, rebasing tokens can be used to create Rapiddex v3 pools and execute swaps. However, they carry a significant risk for liquidity providers.
Risk for Liquidity Providers
When a negative rebase occurs, all token balances decrease, including the tokens held inside a pool. The pool's internal accounting tracks liquidity in terms of the amounts deposited at mint time. After a negative rebase, the actual token balance in the pool is lower than what the position accounting expects.
When a liquidity provider's position is in range during a negative rebase event, they bear the full loss of the rebased amount with no mechanism to recover it. The pool has no way to distinguish a rebase from a legitimately low balance.
Positive Rebases
Positive rebases increase the pool's token balance beyond what the position accounting tracks. The additional tokens effectively become unclaimable by liquidity providers, since the accounting has no record of the extra balance. Positive rebases therefore silently dilute LP returns.
Summary
| Token Type | Pool Creation | Swapping | Liquidity Provision |
|---|---|---|---|
| Standard ERC-20 | Supported | Supported | Supported |
| Fee-on-Transfer | Possible | Broken via router | Not recommended |
| Rebasing | Supported | Supported | Risk of unrecoverable loss |
