Add Validator

Adding a Validator

We’re adding a validator in a PoA setup where the ValidatorManager contract is owned by your connected wallet and deployed on your L1. The process has two L1 calls with a P-Chain registration in between.

Phase 1: Initiation (L1)

First we will call initiateValidatorRegistration(nodeID, blsPublicKey, remainingBalanceOwner, disableOwner, weight) on ValidatorManager.

Under the hood, the contract:

• Validates sizes and formats (20-byte nodeID, 48-byte blsPublicKey, owners, churn limits)
• Builds a RegisterL1ValidatorMessage with a bounded expiry
• Computes a unique validationID
• Stores pending state mapping nodeID → validationID
• Interacts with ICOM to create a warp message that can be submitted to the P-Chain

Phase 2: P-Chain Processing

We then will sign and submit the RegisterL1ValidatorMessage warped response we got from the last step to the P-Chain, this executes a RegisterL1ValidatorTx, and upon success signs and returns an L1ValidatorRegistrationMessage warped response.

The P-Chain processes the following message structure:

// RegisterL1Validator adds a validator to the subnet.
type RegisterL1Validator struct {
	payload
 
	SubnetID              ids.ID                 `serialize:"true" json:"subnetID"`
	NodeID                types.JSONByteSlice    `serialize:"true" json:"nodeID"`
	BLSPublicKey          [bls.PublicKeyLen]byte `serialize:"true" json:"blsPublicKey"`
	Expiry                uint64                 `serialize:"true" json:"expiry"`
	RemainingBalanceOwner PChainOwner            `serialize:"true" json:"remainingBalanceOwner"`
	DisableOwner          PChainOwner            `serialize:"true" json:"disableOwner"`
	Weight                uint64                 `serialize:"true" json:"weight"`
}

Phase 3: Completion (L1)

We finally will call the completeValidatorRegistration(messageIndex), where we will pass the message index of the response we received in step 2. The contract verifies it, activates the validator, sets the start time, and emits CompletedValidatorRegistration.

Anyone can call completeValidatorRegistration(messageIndex) with the signed message.

Validator Registration Expiry

When registering validators, it's important to understand the expiry field:

• Default Expiry: Validator registrations expire after 24 hours by default
• Completion Required: If a validator registration is not completed before the expiry time, the registration becomes invalid
• Pending State: Expired registrations remain in the pending registrations list in the Validator Manager contracts
• Cleanup Required: Expired registrations must be manually removed using the Remove Expired Validator Registration tool

This ensures that only active, properly configured validators remain in your Subnet's validator set.

Appendix: Adding Validator Flow