Feature Request: Emit reward events with candidate address for per-candidate reward tracking

[Doddanna17]

Problem

XDC masternodes receive auto-distributed rewards from the consensus engine at epoch boundaries (every 900 blocks). These rewards are deposited directly into the owner wallet balance without
any on-chain events or logs. When a single owner operates multiple masternode candidates, all rewards accumulate in one balance, making it impossible to deterministically attribute rewards to
individual candidates.

Current workaround

We currently use a balance-diff approach: reward = balanceAtEpochEnd - balanceAtEpochStart. For multi-candidate owners, we use XDPoS_getMasternodesByNumber and
XDPoS_getMissedRoundsInEpochByBlockNum to estimate per-candidate shares based on consensus participation.

Issues with balance-diff

1. Transfer contamination: If the owner sends or receives XDC during the epoch window, the balance-diff includes those transfers, corrupting the reward calculation. We have to scan blocks and
   compensate for outbound transfers using nonce-diff detection, and inbound transfers are difficult to distinguish from rewards without per-block analysis.
2. Attribution is estimated, not exact: Splitting rewards by effective blocks (expected blocks per MN minus missed rounds) is an approximation. The actual protocol reward distribution formula
   may differ.
3. Expensive RPC calls: Compensating for transfers requires scanning up to 900 blocks per epoch per owner when transfers are detected.

Proposed Solution

Emit an on-chain event/log when epoch rewards are distributed, with the following fields:

• candidate (address): The masternode candidate address that earned the reward
• owner (address): The owner wallet that received the reward
• amount (uint256): The reward amount in wei
• epochNumber (uint256): The epoch number

Example event signature:

event RewardDistributed(
    address indexed candidate,
    address indexed owner,
    uint256 amount,
    uint256 epochNumber
);

This would allow integrators to:

• Track per-candidate rewards deterministically using eth_getLogs
• Eliminate the need for balance-diff calculations and transfer compensation
• Accurately attribute rewards for multi-candidate owners
• Build reliable reward history without expensive block-scanning workarounds

Context

We are building staking infrastructure that tracks rewards for XDC masternode operators. Accurate per-candidate reward attribution is critical for:

• Reward reporting to wallet owners
• Tax and compliance reporting
• Performance monitoring per candidate

Any guidance on whether this is feasible or if there is an existing mechanism we are missing would be appreciated.