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.

No Router Support Planned There is no plan to add a router variant that supports fee-on-transfer tokens. Token creators who want their token to be tradeable on Rapiddex v3 should either remove the transfer fee or deploy a fee-free wrapper token and a corresponding pool for the wrapper.

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.

Unrecoverable Loss Losses from negative rebase events that occur while a position is active are permanent. There is no protocol-level protection or compensation mechanism. Liquidity providers using rebasing tokens assume this risk in full.

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