> For the complete documentation index, see [llms.txt](https://zerc20.gitbook.io/zerc20/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zerc20.gitbook.io/zerc20/for-users/fees-and-rewards.md).

# 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:

| Action     | Low Liquidity Chain | High Liquidity Chain |
| ---------- | ------------------- | -------------------- |
| **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

| Token | Incentive Strength (k) | Notes                                              |
| ----- | ---------------------- | -------------------------------------------------- |
| 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:

```
Target = Total liquidity across all chains / Number of chains × ratio
```

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:

```
When liquidity L < target T:
  Rate at point x = k × (1 - x/T)

When liquidity L ≥ target T:
  Rate = 0 (no fees or rewards)
```

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:

| Fee        | Default        | Maximum      | Applies To              | Notes                                                                                      |
| ---------- | -------------- | ------------ | ----------------------- | ------------------------------------------------------------------------------------------ |
| 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:

```
redeemableDiff = totalEligibleValue - totalTeleported
redeemFee = quoteRedeemFee(redeemableDiff)
userReceives = redeemableDiff - redeemFee
```

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:

```
userReceives = redeemableDiff - redeemFee - relayFee
```

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

1. You initiate an unwrap on Chain A (where you hold zERC20)
2. Your zERC20 is bridged to Chain B (where liquidity is higher)
3. The unwrap happens on Chain B with lower fees
4. 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:

1. Open the **Wrap / Unwrap** modal
2. Select the **UNWRAP** tab
3. 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](/zerc20/for-users/getting-started.md) — Basic wrap/unwrap instructions
* [Contract Spec: Incentive Curve](/zerc20/for-developers/specs/contract-spec.md#incentive-curve) — Technical details of the fee curve