# Node Selection & Reward Distribution Proposal

Abstract
---

This proposal outlines a fair and transparent mechanism for selecting 10 active node operators from a pool of 100+ pre-vetted candidates. Using a simple round-robin grouping system, the design ensures that every operator gets a turn while maintaining operational continuity. Rewards are distributed in a way that covers fixed costs, enforces a 25% profit cap, and channels any excess value to $XMTP token holders. The system is also governed by upgradeable smart contracts.

Motivation
---

The XMTP network needs an efficient mechanism to:
- **Select 10 active nodes every 12 hours:** Implement a rotation mechanism that is fair and predictable.
- **Ensure a fair rotation and equal opportunity**: Use a simple round-robin process to allow all eligble nodes to be active on a rotating basis.
- **Sustain Node Operator Viability:** Cover fixed infrastructure costs and variable rewards, while capping profits to 1.25x total costs
- **Enhance Ecosystem Value:** Redirect excess rewards to $XMTP token holders through buyback/burn, staking rewards, and tresury funding.
- **Deter Bad Behavior**: Require node operators to stake a significant amount of $XMTP tokens, ensuring that the stake is high enough to discourage misconduct and incentivise reliable performance.
- **Keep Implementation Simple:** As nodes will potentially be always online, a full turnover of the active set every cycle should not result in downtime

## Specification

### Node Selection Process

**High level overview**

#### Eligibility, Registration and Staking

- **Eligibility:**
- Node operators must hold a Node Operator NFT
- Operators are required to stake a significant, predetermined amount of $XMTP tokens. The stake must exceed a minimum threshold, which can be adjusted by governance to ensure that it is a meaningful deterrent against bad behavior.
- **Registration Process:**
- Operators register via a smart contract function.
- New nodes join at the end of a candidate queue and become eligible after a 24-hour waiting period.

#### Simple Round-Robin Rotation

- **Round-Robin Mechanism:**
- All registered nodes are maintained in a candidate queue.
- Every 12 hours, 10 nodes are selected from the queue in sequential order.
- When the end of the queue is reached, selection starts again from the beginning.
- **Queue Management:**
- A pointer tracks the position in the candidate queue for the next rotation.
- New registrations are appended to the end of the queue.

#### Performance Metrics - Out of Scope

While this is out of scope of this proposal, it would be useful to maintain performance metrics for each node.

- **Data Collection:**
- Although not used for selection, performance data (e.g., uptime) can be recorded for future analysis and potential integration.
- **Transparency:**
- Operators can review their performance data, ensuring transparency and accountability within the network.

Once this data is available it could be used to implement penalties for notes that do not meet a set performance standard (e.g. 95% uptime), which can also be set by governance. Penalties can be implemented by slashing staked amounts.

---

### Reward Distribution Model

#### Reward Accumulation & Frequency

- **Reward Accumulation:**
- USDC rewards become available every 12 hours.
- Rewards are tracked on-chain for each active node as they are allocated.
- **Payout Frequency:**
- While rewards accumulate every cycle(12 hours), payouts occur on a monthly basis.
- A real-time earnings tracker ensures that nodes do not exceed a 1.25× profit cap over their total monthly operational costs.

#### Reward Breakdown

- **Fixed Base Pay:**
- Each active node is guaranteed a base pay of $1000/month to cover fixed infrastructure costs.
- **Performance-Based Bonus:**
- The remaining rewards (after covering fixed and variable node costs) are distributed evenly among active nodes.
- **Profit Cap Enforcement:**
- Continuous monitoring ensures that if a node’s earnings approach 1.25× its total costs (fixed plus variable), additional rewards are reallocated.

#### Excess Reward Allocation

- **Excess Rewards:**
- Any rewards beyond the profit cap are automatically directed to the $XMTP ecosystem.
- **Allocation Mechanisms:**
- **Buyback & Burn:** A portion is used to buy back and burn $XMTP tokens.
- **Staking Rewards:** A portion is distributed as additional rewards to long-term $XMTP holders.
- **Treasury Funding:** The remainder is allocated to a treasury for governance initiatives, ecosystem grants, or infrastructure improvements.

Note: For the initial implementation the amounts can simply be stored in the tresury contract(detailed later) with appropriate accounting.
- **Governance Oversight:**
- Allocation percentages are adjustable through on-chain governance proposals, ensuring responsiveness to market conditions.

---

### Smart Contracts & Governance

#### Contract Components

- **NodeSelectionManager.sol**:
Handles node registration, queue management, and round-robin selection.

interface INodeSelectionManager {
    event NodeRegistered(address indexed operator, uint256 timestamp);
    event NodesRotated(address[] newActiveNodes, uint256 timestamp);
    
    function register() external;
    function getActiveNodes() external view returns (address[] memory);
    function rotateNodes() external;
}

- **RewardDistributor.sol**:
Manages reward accrual, distribution, and profit cap enforcement.

interface IRewardDistributor {
    event RewardsDistributed(uint256 totalRewards, uint256 timestamp);
    
    function distributeRewards() external;
    function updateNodeEarnings(address node, uint256 amount) external;
    function enforceProfitCap(address node) external returns (uint256 excess);
}

- **NodeEarningsTracker.sol**:
Tracks per-node earnings to ensure adherence to the profit cap.

interface INodeEarningsTracker {
    event EarningsUpdated(address indexed node, uint256 newTotal, uint256 timestamp);
    
    function addRewards(address node, uint256 amount) external;
    function getTotalEarnings(address node) external view returns (uint256);
    function enforceProfitCap(address node) external returns (uint256 excess);
}

- **XMTPTreasury.sol**:
Manages excess reward allocation for ecosystem benefit.

interface IXMTPTreasury {
    event ExcessRewardsHandled(uint256 amount, uint256 timestamp);
    
    function handleExcessRewards(uint256 amount) external;
}

#### Upgradeability & Governance

- **Proxy Pattern:**
- All contracts are deployed behind proxies to allow easy upgrades.

- **Access Control:**
- Simple access control (initially via a multisig and eventually via DAO governance) restricts most state-changing functions.
- Key parameters including minimum staking requirements and profit cap settings are modifiable via governance proposals.
- **Event Logging & Transparency:**
- Each contract emits events for critical actions (e.g., node registration, rotation, reward distribution) to ensure full on-chain auditability.

---

#### Clarifications
"It is undesirable for > 20% of the active node operators to “turn over” on any given day."

I took this to mean node operators that just stop participating, however after looking back this could also mean the number of nodes switching from active to non-active. If the latter is true, then this proposal would need to be revised to meet this criteria. Currently, in any day there would have been 20 active node operators in total, with 50% turn over. Instead of a simple grouped round-robin, we could look at a staggered round robin approach.

"each have already been granted a NFT showing that they are eligible to be a node operator and have been manually vetted for sybil resistance"

My thoughts are the NFT will help us potentially identify node operators, but depending on how it is used, does not prevent Sybil attacks. If we are using vanilla NFT's malicious node operators could simply transfer ownership and perform whatever actions. However, I've assumed we will be verifying ownership on each transaction to mitigate this but which would also increase the gas cost per transaction. To get around this we could look into only allowing governance to transfer ownership of the token.