Skip to main content

Why choose to leverage fee distribution on your Arbitrum chain

Choosing fee distribution refers to configuring the chain's fee management system to enable the distribution or return of a portion of collected transaction fees (gas fees) back to users, developers, dApps, or other stakeholders. This is achieved through customizable fee collectors and optional distributor contracts, allowing chain owners to implement distribution mechanisms as part of the chain's economic model.

Fee distribution can incentivize usage, reward high-volume participants, or align with project tokenomics, but they are not a default setting—instead, they require intentional configuration during or after deployment. This choice contrasts with directing all fees to a single owner or treasury address without redistribution.

Configuration requires chain owner privileges and can be done post-deployment using precompiles or the Arbitrum Arbitrum Chain SDK. It's compatible with all DA modes (Rollup, AnyTrust, Alt-DA) and gas tokens (native ETH or custom), though custom tokens add complexity in exchange rate management for reimbursements. For example, surplus fees could be distributed to high-activity users or contributed to a community fund.

Key concepts​

  • Gas and fees in Arbitrum chains: Fees are charged for transaction execution and data posting, denominated in the chain's gas token (ETH by default or a custom ERC-20). They cover operational costs like sequencing, data availability, and parent chain interactions. Surplus fees (beyond minimum costs) can accumulate during congestion, providing a pool for potential distribution.
  • Fee distribution: Distribution involves returning part of the paid fees, often as incentives. In Arbitrum chains, this isn't an explicit "toggle" but is facilitated by routing fees to smart contracts that automate distributions (e.g., proportional payouts). This can be similar to rebate programs seen in apps on Arbitrum (e.g., trading fee rebates funded by incentives), but applied at the chain level.

Types of fees available for distribution​

  • Orbit base fee: Minimum execution fee; routed to an infrastructure account.
  • Orbit surplus fee: Congestion-based extra; routed to a network account.
  • Parent chain base fee: Data posting cost; routed to batch poster collectors.
  • Parent chain surplus fee: Optional batch poster reward; routed to a reward recipient.

Compatibility and considerations​

  • With custom gas token: Distributions work but require a fee token pricer for parent chain reimbursements (e.g., converting custom tokens to ETH). Pricers (manual, oracle-based, or trade-tracking) ensure accurate reimbursements to batch posters, which can include refund-like mechanics if reserves are managed.
  • With native ETH: Simpler, as no conversions are needed; distribution can be direct ETH payouts.

Pros​

  • Boosts user engagement by reducing effective costs (e.g., 75-100% distribution in dApp examples).
  • Flexible tokenomics, such as funding distributions with surplus or incentives like ARB grants.
  • Enhances competitiveness for high-throughput apps like gaming or DeFi.

Cons​

  • Reduces chain revenue, potentially impacting sustainability.
  • Adds complexity in setup and management (e.g., monitoring distributions, handling custom token risks like volatility).
  • Requires careful design to avoid abuse (e.g., sybil attacks on distributions).

Examples​

  • App-level distribution: Protocols like GMX or Synthetix on Arbitrum distribute 75%+ of trading fees using ARB incentives, which Arbitrum chains can emulate at the chain level.
  • Chain-level: Set surplus fees to a distributor that distributes to top users or integrates with programs like ArbiFuel for sponsored gas in early stages.

How to configure​

  1. Set fee collectors: Use the ArbOwner and ArbAggregator precompile (0x70) to assign addresses for each fee type (e.g., setInfraFeeAccount for Orbit base fees). Collectors can be simple addresses or smart contracts.
  2. Deploy a distributor contract: For distribution, deploy a contract like RewardDistributor.sol on the chain. Set recipients and proportions (e.g., 80% to treasury, 20% to user distribution pools using basis points).
  3. Trigger distributions: Call distributeRewards on the contract to execute distributions, specifying recipients and shares.
  • Tools: Use command-line (cast) or SDK extensions like arbOwnerActions for programmatic setup.

This feature underscores Arbitrum's modularity, allowing tailored fee economics while inheriting Ethereum security. For implementation, refer to official docs, SDK examples, or your RaaS; a list of RaaSes is on the Third-party providers page.