Distributions

Protocol Balance and Funding

The ar.io network maintains a protocol balance that funds all gateway and observer rewards. This balance is primarily funded through ArNS name purchases, ensuring sustainable network incentives aligned with usage.

Epoch Allocation

Each epoch, a portion of the protocol balance is earmarked for distribution as rewards. The protocol uses this allocation to reward functional gateways and observers.

Funding Sources

• ArNS Name Purchases: Primary funding mechanism - fees from ArNS name registrations and renewals
• Network Genesis Allocation: Initial ARIO tokens allocated at network launch
• Undistributed Rewards: Rewards not claimed due to poor performance roll forward to future epochs

From this allocation, two distinct reward categories are derived:

Base Rewards

Base Gateway Reward (BGR)

This is the portion of the epoch reward allocation distributed to functional gateways.

Base Observer Reward (BOR)

Observers, due to their additional responsibilities, have a separate reward category for successfully performing observation duties.

Distribution Based on Performance

The reward distribution is contingent on the performance classifications derived from the Performance Evaluation:

• Functional Gateways: Gateways that meet the performance criteria receive the Base Gateway Reward.
• Deficient Gateways: Gateways falling short in performance do not receive any gateway rewards.
• Functional Observers: Observers that fulfilled their duty receive the Base Observer Reward.
• Deficient Observers: Observers failing to meet their responsibilities do not receive observer rewards. If they are also functional gateways, their gateway reward can be reduced for that epoch as a consequence for not performing their observation duty.

Epoch Pipeline

On Solana, reward distribution is driven by a permissionless 6-step epoch pipeline rather than a single atomic operation:

1. create_epoch — Initialize epoch, compute reward rate
2. tally_weights — Batched weight computation
3. prescribe_epoch — Select observers and prescribed names via weighted roulette
4. save_observations — Observers submit pass/fail reports
5. distribute_epoch — Batched reward distribution
6. close_epoch — Reclaim rent from completed epoch accounts

All steps are permissionless and idempotent — anyone can crank them, and running them multiple times is safe.

Operator Rewards

Operator rewards always auto-compound into the operator's stake. There is no toggle — operators must call decrease_operator_stake to realize rewards as liquid tokens.

Distribution to Delegates

Delegate rewards use a reward-per-share accumulator pattern. Rather than distributing rewards to each delegate individually each epoch, the protocol tracks a cumulative reward-per-token on each gateway. Pending rewards are settled when the delegator interacts with the protocol (e.g., delegate more, withdraw, or claim rewards).

Leaving gateways receive 0 rewards for any epoch in which they have initiated withdrawal.

Delegate reward distribution considers the gateway's total reward, the gateway's delegate reward share setting, and each delegate's proportional stake. Delegated rewards are added to the delegate's existing stake for that gateway and can later be withdrawn subject to normal withdrawal rules.

Undistributed Rewards

In cases where rewards are not distributed, either due to the inactivity or deficiency of gateways or observers, the allocated tokens shall remain in the protocol balance and carry forward to the next epoch.

This mechanism is in place to discourage observers from frivolously marking their peers as offline in hopes of attaining a higher portion of the reward pool.

Note that if a gateway (and its delegates) leaves the network or a delegate fully withdraws stake from a gateway, they become ineligible to receive rewards within the corresponding epoch and the earmarked rewards will not be distributed.

Handling Deficient Gateways

To maintain network efficiency and reduce state bloat, gateways that remain deficient for a sustained period can be removed from the network. When this happens, their minimum network-join stake is slashed to the protocol balance, while eligible excess and delegated stake follow the standard withdrawal process.

---

Next Steps

Congratulations! You now understand the complete OIP system. Ready to learn more?

• Explore Gateways → Gateway Documentation for technical details
• Learn about ArNS → ArNS Documentation for naming system details
• Back to Introduction → OIP Introduction to review the basics