Owner: @Thomas Lavaur

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

Introduction

Nomos relies on multiple services such as Data Availability, Blend Network, or Executor 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 Service Declaration Protocol Specification. 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 accumulated funds at the end of the session.

This document describes the protocol's logic for aggregating funds, and deterministically distributing rewards through Mantle Transactions.

Overview

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

1. Fund Accumulation (Session N): Leaders aggregate service fees into a dedicated note in the Mantle. This is done through a single Mantle Transaction collecting for all services.
2. Activity Tracking (Session N+1): Validators submit signed activity messages to attest to their participation through a Mantle transaction, including an activity message (see SDP_ACTIVE).
3. Reward Derivation (End of Session N+1): Nodes compute each validator’s reward based on validated activity messages and the different service reward policies.
4. 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 distributing for all services.

Core Properties:

• 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 2 reward transactions (~1kB per block as in the block proposal).
• Transparent Transfers: Rewards are distributed using standard Mantle transactions.