How to change a Solana staking validator

Find the position and its controlling roles

Open the stake account rather than starting from the validator's name in a list. Record its vote target, activation state, authorities and any lockup. This tells you what you control and which operations are currently available.

For direct native staking, your signing setup can hold the management role. For managed native staking, a service or proxy can hold stake authority while you retain withdrawal authority. Read the product's supported management and exit path.

If you hold an LST, you control a pool token. Selecting another validator in an unrelated wallet screen does not reassign each backing account. Pool allocation follows the pool's own policy; changing to direct staking can require a redemption or sale and a new native position.

This initial classification prevents applying a correct native procedure to the wrong kind of holding.

Verify the new target before changing state

Obtain the new validator's published vote address and compare the complete value in the proposed delegation. Check the current identity association and relevant commission information.

Use participation and yield observations with a period and source. A recently changed profile can show current settings while an older rate summarises earlier conditions. Keep those dates visible in your comparison.

For a broader distribution goal, examine whether the new vote target belongs to an independent operator and has different relevant dependencies. More addresses alone do not establish more independent control.

Save the chosen target in the position record before preparing the transition. Afterward, use it to check the actual delegation field rather than relying on a success toast.

Use the supported native transition

A standard native route requests deactivation of the old delegation and observes the account through the required transition. The wallet then uses a supported re-delegation or withdrawal-and-new-position flow when the relevant state permits it.

The exact available operations depend on the program, account state and wallet implementation. Read its actual transaction sequence rather than assuming every button called switch performs an immediate reassignment.

During a transition, effective stake and reward eligibility can differ from the unchanged position. An epoch estimate helps plan, but the actual account state determines which action can proceed.

For a withdrawal-and-new-position route, reconcile the received SOL and the new stake account separately. Network fees and account funding are part of that construction; they should not disappear from the user's movement record.

Changing all stake and changing part of it

Move only part of a position deliberately

Suppose Alice wants to move 10 SOL of an approximately 30 SOL native position to another validator while retaining the rest. This can require a supported split or separately funded stake account rather than assigning two validators to the original account.

Before signing, inspect the new account, authorities, amounts and required minimum balances. Keep the original and resulting account addresses together. The selected amount, total account balance and effective stake may be different fields.

Then follow the transition for the portion that changes target. A split records structure; it does not automatically establish the intended new delegation or complete activation.

Merging later has its own eligibility conditions. Do not treat arbitrary stake accounts with different settings or states as freely interchangeable merely because the same wallet manages them.

Check the resulting state and rewards context

Open each resulting position and confirm its vote address, authorities and relevant activation status. Compare the signatures and account movements with the chosen route.

If a managed product was involved, check whether the intended management relationship ended or changed. A wallet-interface disconnect alone is not a replacement for changing account authority.

When comparing rewards around the move, use the account history and periods of effective stake. The first observation after a transition does not necessarily describe a full period under the new validator.

A complete record can state: old account and target; selected amount; transition signatures; new or retained account; verified target; authority check; and observed status. The reward-history guide then lets you follow the result.

Common questions