Service Integration Details

The three main components that services (AVS) must define when integrating with Imua include the operator election, slashing, and reward mechanisms.

Figure 3: AVS Task Submission Flow. AVS committee executes off-chain tasks and collectively attests to the successful completion of the tasks by signing aggregate BLS signatures on reward claims which are then submitted to Exocore network.

Election

Election refers to the procedure through which specific operators from all the opt-in operators are chosen to join as AVS committee. The precise election process will be defined by the AVS developers in the operator election module or smart contract. Such rules might include, but are not limited to:

• The types of restaked tokens an operator must possess.

• The minimum value of the restaked token required for an operator.

• The number of validators to be elected in the committee.

Slashing

Slashing serves as a disincentive to deter operators from acting maliciously to the normal functioning of the AVS protocol. Slashing should be provable with cryptographic evidence, such as cryptographic signatures or zero-knowledge proofs. To initiate the slashing of a rogue operator, proof of the malicious activity must be submitted to the Imua system and authenticated by the slashing verification logic set by the AVS. A successfully verified slashing proof will lead to slashing result such as:

• Freezing of the malicious operator for that particular AVS.

• Deducting a predetermined amount of staked tokens from the operator.

The slashed tokens from an operator will also impact other AVSs in which the operator participates since the same tokens are also used in other AVSs.

Given that slashing events are expected to be rare and occur infrequently, the verification logic for slashing can be executed within the Imua network without significant concerns about performance.

For a slashing event that can’t be verified on-chain within Imua network, an off-chain verification process relying on AVS committee can be adopted. In this process, when a slash event is detected and reported within the AVS network, each operator of the AVS committee verifies the validity of the slash event and attests to it by signing on it. When more than 2/3 of the operators sign the slash event, the aggregated signature along with the event data can be submitted to Imua to trigger the actual slashing of the malicious operator.

Rewards

In contrast to slashing, rewards aim to incentivize operators to execute tasks as specified by the AVS and uphold the network’s normal operations. It is anticipated that AVSs will issue rewards for all tasks completed successfully by operators. As these tasks are typically carried out regularly, the meticulous implementation of the reward mechanism is crucial to ensure the system isn’t overloaded or incurring excessive network costs. There are several methods to integrate the reward logic:

1. On-chain Verification on Imua: Similar to the slashing mechanism, the reward logic can be natively executed within the Imua network via either smart contracts or modules.

2. Off-chain Verification by the Staked AVS Committee:

   Given that the AVS committee is expected to be majority-honest, this committee can verify task completions within the AVS network and submit a reward claim to the Imua network. A claim endorsed by over 2/3 (or a higher threshold such as 90%).

Reward Distribution

When proof of task are successfully verified and processed by Imua network, rewards from AVS will be issued to the operators and their delegators for their contribution. There are a few sources where the rewards may originate from:

1. AVS provides the reward funding in third-party tokens (ETH, USDT etc.)

2. AVS issues the native protocol reward tokens through inflation ($AVS)

3. AVS collects transaction fees and pays to the operator as rewards.

In all cases, we expect the reward token exists as a standard fungible token in the form of smart contracts. The reward token smart contract should grant permission to Imua's client chain contracts to issue and transfer tokens to re/stakers.

The steps involved in the AVS reward distribution flow, after the reward token contracts have been set up and granted permission to the Imua client chain contracts (as step 0), are:

1. AVS submits the reward claim with a BLS aggregate signature that have at least two-thirds (2/3rds) of the voting power.

2. Imua network verifies the claim, calculates the reward distribution result, and sends a reward distribution transaction to the client chain contracts on the L1 network.

3. The client chain contract verifies the reward distribution transaction sent from Imua network and calls the reward token contracts to issue the rewards.

4. The reward tokens are actually transferred to the stakers of the AVS.

Figure 4: Reward Distribution Flow. After successful verification of the reward claim, Exocore network sends a cross-chain message to the client chain contracts to trigger reward distribution among restakers through the reward token contract.