Observation and Incentives (OIP)

Overview

The Observation and Incentive Protocol is designed to maintain and enhance the operational integrity of gateways on the AR.IO Network. It achieves this through a combination of incentivizing gateways for good performance and tasking those gateways to fulfill the role of "observers". The protocol is intentionally simple and adaptable, employing a smart contract-based method for onchain “voting” to assess peer performance while being flexible on how that performance is measured. This setup permits gateway and observer nodes to experiment and evolve best practices for performance evaluation, all while operating within the bounds of the network's immutable smart contract, thus eliminating the need for frequent contract updates (forks).

In this protocol, observers evaluate their gateway peers' performance to resolve ArNS names. Their aim is to ensure each gateway in the network accurately resolves a subset of names and assigning a pass / fail score based on their findings.

A key component of the protocol is its reward mechanism. This system is predicated on gateway performance and compliance with observation duties. Gateways that excel are tagged as "Functional Gateways" and earn rewards, while those that do not meet the criteria, “Deficient Gateways” risk facing penalties – namely, the lack of rewards.

Funds for incentive rewards are derived from the protocol balance, which consists of ARIO tokens initially allocated at network genesis as well as those collected from ArNS asset purchases. Every epoch, this balance is utilized to distribute rewards to qualifying gateways and observers based on certain performance metrics.

Observation Protocol

The Observation protocol is organized around daily epochs, periods of time that are broken into an observation reporting and tallying phase. The protocol is followed across each epoch, promoting consistent healthy network activity that can form pro-social behaviors and react to malicious circumstances.

Onchain Reports

The to-be-evaluated ArNS names include a set of two (2) names randomly determined by the protocol, known as “prescribed names”, which are common across all observers within the epoch, as well as a set of eight (8) “chosen names” picked at the discretion of each individual observer. “Prescribed names” are assigned to act as a common denominator / baseline while “chosen names” allow each observer to evaluate names that may be important to their operation.

Observers shall upload their completed reports (in JSON format) to the Arweave network as an onchain audit trail. In addition, observers shall submit an interaction to the AR.IO smart contract detailing each gateway that they observed to have “failed” their assessments. These “votes” are tallied and used to determine the reward distribution.

Selection of Observers

The observer selection process commences at the beginning of each epoch and employs a random-weighted selection method. By combining random selection with weighted criteria like stake, tenure, and past rewards, the process aims to ensure both fairness and acknowledgment of consistent performance. This method allows for a systematic yet randomized approach to selecting gateways for observation tasks.

Criteria for Selection

Up to fifty (50) gateways can be chosen as observers per epoch. If the GAR is below that amount, then every gateway is designated as an observer for that epoch. If there are greater than 50, then randomized selection shall be utilized.

The weighted selection criteria will consider the following for each gateway:

• Stake Weight (SW): This factor considers how financially committed a gateway is to the network. It is the ratio of the total amount of ARIO tokens staked by the gateway (plus any delegated stake) relative to the network minimum and is expressed as:

• Tenure Weight (TW): This factor considers how long a gateway has been part of the network, with a maximum value capped at four (4). This means that the maximum value is achieved after 2-years of participation in the network. It is calculated as:

• Gateway Performance Ratio Weight (GPRW): This factor is a proxy for a gateway’s performance at resolving ArNS names. The weight represents the ratio of epochs in which a gateway received rewards for correctly resolving names relative to their total time on the network. To prevent division by zero conditions, it is calculated as:

• Observer Performance Ratio Weight (OPRW): This factor is a proxy for a gateway’s performance at fulfilling observation duties. The weight reflects the ratio of epochs in which a gateway, as an observer, successfully submitted observation reports relative to their total periods of service as an observer. To prevent division by zero conditions thus unfairly harming a newly joined gateway, it is calculated as:

Weight Calculation and Normalization

For each gateway, a composite weight (CW) is computed, combining the Stake Weight, Tenure Weight, Gateway Performance Ratio Weight, and Observer Performance Ratio Weight.

The formula used is:

These weights are then normalized across the network to create a continuous range, allowing for proportional random selection based on the weighted scores. The normalized composite weight (N_CW) for each gateway indicates its likelihood of being chosen as an observer and is calculated by dividing the gateway's CW by the sum of all CWs. Any gateway with a composite weight equal to zero shall be ineligible for selection as an observer during the associated epoch.

Random Selection Process

The selection of observers is randomized within the framework of these weights. A set of unique random numbers is generated with entropy within the total range of normalized weights. For each random number, the gateway whose normalized weight range encompasses this number is selected. This system ensures that while gateways with higher weights are more likely to be chosen, all gateways maintain a non-zero chance of selection, preserving both fairness and meritocracy in the observer assignment process. The current epoch’s selected / prescribed observers as well as prescribed ArNS names to be evaluated shall be saved in the contract state at the beginning of the epoch to ensure that any activities during that epoch do not affect the selection of observers or awards distribution.

Performance Evaluation

Consider the following classifications:

• Functional or Passed Gateways: are gateways that meet or surpass the network’s performance and quality standards.
• Deficient or Failed Gateways: are gateways that fall short of the network's performance expectations.
• Functional or Submitted Observers: are selected observers who diligently perform their duties and submit observation reports and contract interactions.
• Deficient or Failed Observers: are selected observers who do not fulfill their duty of submitting observation reports and contract interactions.

At the end of an epoch, the smart contract will assess the results from the observers and determine a pass / fail score for each gateway:

• If greater than or equal to 50% of submitted observer contract interactions indicate a PASS score, then that gateway is considered Functional and eligible for gateway rewards.
• Else, if greater than 50% of submitted observer contract interactions indicate a FAIL score, then that gateway is considered Deficient and ineligible for gateway rewards.

These results will determine how reward distributions are made for that epoch. Rewards shall be distributed after forty (40) minutes (approx. twenty (20) Arweave blocks) in the following epoch have elapsed. This delay ensures that all observation contract interactions are safely confirmed by the Arweave network without risk of “forking out” prior to the evaluation and reward distribution process.

Reward Distribution

Each epoch, a portion of the protocol balance is earmarked for distribution as rewards. This value shall begin at 0.1% per epoch for the first year of operation, then linearly decline down to and stabilize at 0.05% over the following 6 months. From this allocation, two distinct reward categories are derived:

1. Base Gateway Reward (BGR): This is the portion of the reward allocated to each Functional Gateway within the network and is calculated as:

2. Base Observer Reward (BOR): Observers, due to their additional responsibilities, have a separate reward calculated as:

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. Furthermore, if they are also Functional Gateways, their gateway reward is reduced by 25% for that epoch as a consequence for not performing their observation duty.

Gateways shall be given the option to have their reward tokens “auto-staked” to their existing stake or sent to their wallet as unlocked tokens. The default setting shall be “auto-staked”.

Distribution to Delegates

The protocol will automatically distribute a Functional Gateway’s shared rewards with its delegates. The distribution will consider the gateway’s total reward for the period (including observation rewards), the gateway’s “Delegate Reward Share Ratio”, and each delegate’s stake proportional to the total delegation. Each individual delegate reward is calculated as:

Unlike gateways, token reward distributions to delegated stakers will only be “auto-staked” in that they will be automatically added to the delegate’s existing stake associated with the rewarded gateway. The delegated staker is then free to withdraw their staked rewards at any time (subject to withdrawal delays).

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 contract state bloat, gateways that are marked as deficient, and thus fail to receive rewards, for thirty (30) consecutive epochs will automatically trigger a “Network Leave” action and be subjesct to the associated stake withdrawal durations for both gateway stake and any delegated stake. In addition, the gateway shall have its minimum network-join stake slashed by 100%. The slashed stake shall be immediately sent to the protocol balance.