Deployed post-bond split
The deployed v2 model keeps the total post-bond trading fee at 1%. Each harvested fee asset is allocated as follows:
- 0.20% creator
- 20% of the total fee accrues to the launch creator in pull-payment escrow.
- 0.30% community
- 30% funds community/trader reward accounting and finalized claim epochs.
- 0.30% liquidity
- 30% stays in the permanent vault reserve and can be compounded into the locked position.
- 0.20% platform
- 20% is transferred to the configured protocol treasury.
The four allocations sum to 1.00%. The older 0.35%/0.40%/0.25% copy was incorrect and is not the v2 model.
Developer reward claims
The fee vault transfers the creator share to a creator escrow and calls accrue with the creator as recipient. The creator calls claim for the fee asset; the escrow zeroes claimable state before transferring, preventing duplicate claims. The rewards page re-reads claimable state immediately before presenting a signable claim.
Per-token lifetime totals come from actual fee-harvest events. Lotus does not multiply 24-hour volume by a fee percentage and present that estimate as money made. Before bond, creator earnings are exactly zero. The authoritative signable amount is always the escrow’s on-chain claimable mapping.
Trader reward epochs
The community-rewards contract splits each token and fee asset into 50% holder and 50% trader buckets. Its owner transfers a bucket into the V2 epoch manager, records that funding, creates a bounded epoch, proposes an allocation root after measurement, and finalizes it after the delay. A claim supplies epoch ID, launch token, fee asset, bucket, leaf index, account, amount, and Merkle proof. The contract recomputes the root and marks the index claimed before transfer.
- Epoch length: 24 hours.
- Trading measurement window: first 6 hours.
- Finalization delay: 6 hours after epoch end.
- Claim duration: 30 days after finalization becomes available.
The hosted reward index publishes each wallet’s allocation and Merkle proof; the contract independently verifies that proof. Without a configured index, the interface shows allocation totals as unavailable instead of guessing. If no funded epoch exists, the exact total and claimable amount are both zero.
Epoch operation is an explicit workflow
Current Arc deployment status
Arc Mainnet V4 is active; the initial registry is empty
The deployed V4 stack contains the 20/30/30/20 accounting, permanent liquidity reserve and compounding path, community reward custody, creator pull payments, and token/asset/bucket-scoped Merkle claims. No contract redeployment is required for these paths.
A replacement deployment must also be followed by the hosted Arc indexer, epoch allocation worker, and a funded finalized canary epoch before trader allocations appear. Passing local tests is not an external security audit; mainnet deployment should remain gated on independent review and a small-value staged canary.
The Rewards page runs a live readiness check and disables claim buttons whenever these conditions fail. The machine-readable status is available at /api/rewards/readiness.