Owner: @Thomas Lavaur

Reviewers: 🟢@David Rusu 🟢@Mehmet 🟢@Álvaro Castro-Castilla 🟢@Marcin Pawlowski 🟢@Frederico Teixeira

Revision History

Introduction

Nomos relies on multiple services, including the Data Availability and Blend Network - each operated by independent validator sets. For sustainability and fairness, these services must compensate service validators based on their participation. Validators first declare their participation through [1.0.0] Service Declaration Protocol. The Service Reward Distribution Protocol enables deterministic, efficient, and verifiable reward distribution to validators based on their activity within each service.

Each service defines a session, a fixed number of blocks during which its validator set remains unchanged. For every session, the service specifies:

• A validator activity rule that distinguishes between active and inactive validators.
• A reward formula for distributing the session’s rewards at the end of the session.

This document describes the protocol's logic for deterministically distributing rewards through Mantle Transactions for services.

Overview

The protocol unfolds over three key phases, aligned with validator sessions:

1. Service Activity Tracking (Session N+1): Service validators submit signed activity messages to attest to their participation of session N through a Mantle Transaction, including an activity message (see SDP_ACTIVE).
2. Service Reward Derivation (End of Session N+1): Nodes compute each validator’s reward based on validated activity messages and the different service reward policies.
3. Service Reward Distribution (Post-Session N+1): Rewards are distributed to validators marked as active for the service over several blocks. This is done through a single Mantle Transaction per block, potentially distributing for all services if the sessions coincide.

Core Properties:

• Service rewards are distributed to the zk_id from validator SDP declarations.
• Deterministic Validator Reward Schedule: A verifiable pseudo-random process ensures fair order of distribution and prevents manipulation.
• Minimal Block Overhead: Each block accommodates 1 reward transaction.