Fees and Rewards
This page explains how wrap/unwrap fees, redeem fees, and rewards work in zERC20.
Overview
zERC20 uses a dynamic fee system to maintain balanced liquidity across all supported chains. When liquidity on a chain deviates from the target level, the system applies incentives to encourage rebalancing:
Wrap
Earn rewards
No reward
Unwrap
Pay fee
No fee
Why Fees and Rewards Exist
Each chain holds a pool of underlying tokens (USDC, ETH, etc.) that back the zERC20 supply. When liquidity becomes unevenly distributed—for example, most USDC ends up on Ethereum while Arbitrum runs low—users on Arbitrum may face difficulty unwrapping.
The fee/reward system solves this by:
Rewarding deposits on chains with low liquidity (encouraging users to add liquidity where it's needed)
Charging fees on withdrawals from chains with low liquidity (discouraging draining of scarce liquidity)
How Fees Are Calculated
Fees and rewards are calculated using a linear incentive curve based on two parameters:
Target Liquidity (T): The ideal liquidity level for the chain
Incentive Strength (k): How strongly the system incentivizes rebalancing
Current Fee Settings
zUSDC
10%
Fees/rewards apply across all supported chains
zETH
10%
Fees/rewards apply across all supported chains
zBNB
—
No fees or rewards (wrap/unwrap on BNB Chain only)
Note: zBNB can be transferred across multiple chains (BNB Chain, Ethereum, Arbitrum, Base) as an OFT token. However, wrap/unwrap (converting between BNB and zBNB) is only available on BNB Chain. Since there is no cross-chain liquidity balancing for the underlying asset, no fees or rewards apply.
Target Liquidity (T) is automatically calculated by a background service:
The default ratio is 80%, meaning the target is set to 80% of the equal-share amount. This allows moderate liquidity fluctuations without triggering fees or rewards. As liquidity flows between chains, targets adjust automatically.
The Formula
The fee/reward rate increases as liquidity drops further below the target:
The actual fee or reward is the integral (area under the curve) between your transaction's start and end liquidity levels.
Example
Suppose a chain has:
Current liquidity: 50,000 USDC
Target liquidity: 100,000 USDC
Incentive strength: 10%
Wrap 1,000 USDC: You would earn a reward of 49.5 USDC (4.95%) for adding liquidity to an under-supplied chain.
Unwrap 1,000 USDC: You would pay a fee of 50.5 USDC (5.05%) because liquidity is below target.
Fee Accumulation
Fees collected from unwraps accumulate in a surplus pool. This surplus is used to pay rewards for future wraps. When the surplus is depleted, wrap rewards are reduced accordingly.
Private Transfer Redeem Fee
Private transfers are claimed through a redeem transaction. Redeem can charge a protocol fee that is separate from the wrap/unwrap liquidity fee described above.
Current default:
Redeem fee
0.35% (35 bps)
1% (100 bps)
Private transfer redeem
Configured per Verifier contract, so operations can adjust it per token / chain deployment
The contract enforces MAX_REDEEM_FEE_BPS = 100, so the owner cannot set a redeem fee above 1%.
During the migration from older Verifier deployments, a destination chain that has not yet been upgraded for redeem fees may appear as 0 bps in the frontend / SDK. In that state, fee-related fields such as the fee withdrawal wallet may also appear unset. After that Verifier proxy is upgraded, the frontend reads the on-chain fee and applies the normal quote / confirmation flow.
The redeem fee is calculated only on the newly redeemable amount:
This avoids charging again for value that has already been redeemed. The fee is quoted by the destination chain's Verifier contract and is deducted in the token's smallest unit, so token decimals are handled by the contract and SDK.
The fee is rounded up to the nearest smallest unit. For example, 0.35% of a 999-unit redeem rounds up to 4 units. This prevents fee avoidance through micro-redeems.
Redeem fees are first recorded inside each Verifier's redeemFeeBalance. They are not minted during the user's redeem transaction. The protocol-controlled feeRecipient wallet can later call withdrawRedeemFees() to mint the accrued zERC20 fees to itself in one withdrawal.
feeRecipient is the withdrawal authority, not a per-redeem mint recipient. Production deployments should use a protocol-controlled multisig or Safe, and operations should monitor the RedeemFeesWithdrawn event against the accrued fee balance.
For gasless redeem, the relay fee is deducted after the redeem fee:
The frontend shows the redeem fee and relay fee before asking you to approve a gasless redeem.
Cross-Chain Unwrap to Reduce Fees
If a chain has low liquidity and high unwrap fees, you can use cross-chain unwrap to access liquidity from a different chain with lower fees.
How It Works
You initiate an unwrap on Chain A (where you hold zERC20)
Your zERC20 is bridged to Chain B (where liquidity is higher)
The unwrap happens on Chain B with lower fees
The underlying tokens are bridged back to Chain A
This entire process happens in a single transaction using LayerZero and Stargate.
When to Use Cross-Chain Unwrap
The unwrap fee on your current chain is high
Another chain has more liquidity (lower fees)
The bridge costs are less than the fee savings
The frontend displays both options with fee estimates, so you can compare before confirming.
Viewing Current Fees
In the frontend:
Open the Wrap / Unwrap modal
Select the UNWRAP tab
Enter an amount
The interface shows:
Same Chain: Fee amount for unwrapping on the current chain
Different Chain: Fee amounts for cross-chain unwrap options
Compare these to find the most cost-effective option.
Related
Getting Started — Basic wrap/unwrap instructions
Contract Spec: Incentive Curve — Technical details of the fee curve
Last updated
Was this helpful?