Rebalancing and incentives

What rebalancing means

Timu uses rebalancing for actions that reduce a price pool's directional risk. The v24 protocol keeps two separate surfaces:

1. A built-in Marginal Xi fee adjustment applied in the trading transaction.
2. Optional, externally funded reward campaigns paid through a Merkle distributor.

A balancing trade does not create a later reward claim, and a reward leaf does not change pool fees, psi, or settlement.

Built-in Marginal Xi fee incentive

When a pool enables the Marginal Xi model, it classifies each action's notional against one canonical checkpoint:

• Balancing notional strictly reduces the risk measure.
• Worsening notional strictly increases it.
• Neutral notional leaves it unchanged.

The balancing part of a close or leverage reduction can receive a discount on the already-discounted base fee. Only the worsening part of an open can add a surcharge. Liquidation receives neither adjustment. If the exact risk transition cannot be proven, the full action is treated as worsening, which can remove a balancing discount but never adds a surcharge to a close.

This incentive changes the protocol fee paid in that transaction. It is not a reward token, rebate, or later claim. Use a fresh quote and carry maxProtocolFee. See Fees and staking.

The historical ArbitrageIncentiveVault scoring surface accepted only Pool v18 to v19 and is retired from current builds. It never created an entitlement on a v24 pool.

Reward campaigns

External rewards use two contracts:

• RewardCampaignRegistryV24 proposes, approves, and configures campaigns. Each campaign fixes its reward token, parameters, and status.
• MerkleRewardDistributorV2 holds campaign funds and pays reviewed Merkle epochs.

Each campaign is isolated. Funding, epochs, and claims are tracked per campaign ID, and one campaign's budget cannot pay another campaign's leaves.

An epoch lifecycle is:

1. A sponsor funds the campaign in the distributor.
2. The publisher proposes the next sequential epoch with a Merkle root, allocation, and claim deadline.
3. After an activation delay of at least 24 hours, anyone can activate the epoch if the claim window and funding still satisfy the bounds.
4. During the window, anyone can submit a proof, and payment always goes to the account committed in the leaf.
5. After the deadline, the epoch finalizes and releases unclaimed amounts back to the campaign's unclaimed funding.

The leaf is double-hashed and domain-bound: the payload includes the distributor address, chain ID, campaign ID, epoch ID, leaf index, account, reward token, and amount. A proof from another distributor, chain, campaign, or epoch cannot be replayed.

No default claimable program

Reward campaigns are deployment-dependent. At this baseline, the v24 testnet deployment has no proposed campaign, Merkle root, or funded epoch. Do not infer reward eligibility from a balancing fee discount, and do not treat UI estimates as claimable balances. Confirm a trusted registry and distributor address, the campaign status, and the epoch state from the active deployment source before relying on a claim.