Overview
This module manages the validators’ related transactions and state for Heimdall.Validators stake their tokens on the Ethereum chain and send the transactions on Heimdall using the necessary parameters to acknowledge the Ethereum stake change.
Once the majority of the validators agree on the change on the stake, this module saves the validator information on Heimdall state.

Flow
The x/stake module manages validator-related transactions and validator set management for Heimdall. Validators stake their tokens on the Ethereum chain to participate in consensus. To synchronize these changes with Heimdall, the bridge processor broadcasts the corresponding transaction for an Ethereum-emitted event, choosing from one of the following messages each with the necessary parameters:MsgValidatorJoin: This message is triggered when a new validator joins the system by interacting withStakingManager.solon Ethereum. The action emits aStakedevent to recognize and process the validator’s participation.MsgStakeUpdate: Used to handle stake modifications, this message is sent when a validator re-stakes or receives additional delegation. Both scenarios trigger aStakeUpdateevent on Ethereum, ensuring Heimdall accurately updates the validator’s stake information.MsgValidatorExit: When a validator decides to exit, they initiate the process on Ethereum, leading to the emission of aUnstakeInitevent. This message ensures that Heimdall records the validator’s departure accordingly.MsgSignerUpdate: This message is responsible for processing changes to a validator’s signer key. When a validator updates their signer key on Ethereum, it emits aSignerUpdateevent, prompting Heimdall to reflect the new signer key in its records.
PreCommit phase, side transaction handlers are triggered, and a vote is injected after validating the Ethereum-emitted event and ensuring its alignment with the data in the processed message.
Once a majority of validators confirm that the action described in the message has occurred on Ethereum, the x/stake module updates the validator’s state in Heimdall during the FinalizeBlock’s PreBlocker execution.
Replay Prevention Mechanism
Heimdall employs a replay prevention mechanism in the post-tx handler functions to ensure that validator update messages derived from Ethereum events are not processed multiple times. This mechanism prevents replay attacks by assigning a unique sequence number to each transaction and verifying whether it has already been processed.The sequence number is constructed using the Ethereum block number and log index, following the formula:
sequence = (block number × DefaultLogIndexUnit) + log indexwhere:msg.BlockNumberrepresents the Ethereum block where the event was emitted.msg.LogIndexis the position of the log entry within that block.DefaultLogIndexUnitensures uniqueness when combining block numbers and log indexes.
Updating the Validator Set
In the x/stakeEndBlocker, Heimdall updates the validator set (through the ApplyAndReturnValidatorSetUpdatesfunction), ensuring consensus reflects the latest validator changes.
Before any updates, the current block’s validator set is stored as the previous block’s set. The system retrieves all existing validators, the current validator set, and the acknowledgment count from the x/checkpoint state.
Using GetUpdatedValidators, a list of validators that require updates (setUpdates) is identified and applied through UpdateWithChangeSet, storing the new set under CurrentValidatorSetKey.
To maintain fair block proposer selection, Heimdall implements a proposer priority system, ensuring all validators have a fair chance to propose new blocks.
The proposer priority is dynamically adjusted using IncrementProposerPriority(times int), which prevents any validator from monopolizing block proposals.
This function limits priority differences by re-scaling priorities (RescalePriorities(diffMax)) and shifting values based on the average proposer priority (shiftByAvgProposerPriority()).
During each round, the validator with the highest priority is selected as the proposer, after which their priority is adjusted to prevent indefinite accumulation.These mechanisms collectively ensure efficient and fair validator rotation, maintaining a balanced consensus process while preventing priority overflows and unfair selection biases.

Messages
MsgValidatorJoin
MsgValidatorJoin defines a message for a node to join the network as validator.
Here is the structure for the transaction message:
MsgStakeUpdate
MsgStakeUpdate defines a message for a validator to perform a stake update on Ethereum network.
MsgSignerUpdate
MsgSignerUpdate defines a message for updating the signer of the existing validator.
MsgValidatorExit
MsgValidatorExit defines a message for a validator to exit the network.
Interact with the Node
Tx Commands
Validator Join
Signer Update
Stake Update
Validator Exit
CLI Query Commands
One can run the following query commands from the stake module:current-validator-set- Query all validators that are currently active in the validators’ setsigner- Query validator info for given validator addressvalidator- Query validator info for a given validator idvalidator-status- Query validator status for given validator addresstotal-power- Query total power of the validator setis-old-tx- Check if a tx is old (already submitted)