Solana validator accounts: identity, vote and delegated stake

Identity identifies the validator participant

A validator uses an identity key in its network operation. Public services can associate that identity with an operator profile, endpoints and other observations. The profile's human name is presentation; the full identity address is a specific identifier.

An operator can run more than one identity over time or operate several validators. A list of identities therefore does not automatically count independent people or companies.

The identity's ordinary lamport balance and the balances of other validator-related accounts are different observations. Read the current funding model and configuration for the client and network rather than assuming an old monitoring article's spending pattern remains universal.

For a delegator, identity is useful for checking the operator association. It is not the field that replaces the vote address in a native-delegation instruction.

The vote account connects consensus participation and delegation

A vote account records validator-related state and the associated node identity under the program's rules. Native stake accounts point at a vote address to identify their delegation target.

The vote account also has authorities and settings relevant to the validator's management. An authorised withdrawer of the vote account is a different role from the withdrawal authority of a delegator's separate stake account.

Current consensus and funding changes matter when interpreting vote-related information. Alpenglow moved votes out of ordinary blocks and changed admission funding. Old transaction-count or identity-vote-fee assumptions need a date and protocol context.

When choosing a target, compare the full vote address in the wallet with the operator's publication. Then verify the onchain identity association and relevant current settings through an appropriate source.

Delegated SOL remains in separate stake accounts

Imagine Alice and Bob both delegate to the same validator. Alice has stake account A; Bob has stake account B. Each records its own authorities and state, while both name the same target vote account.

The validator's displayed delegated stake can aggregate effective amounts from many such positions. That total does not mean all those funds were transferred into the vote account's lamport balance.

A native delegation does not give the operator the withdrawal authority of A or B. A product can request additional management changes, so inspect those separately rather than attributing them to delegation itself.

The stake account address is the object to use for an individual reward or withdrawal investigation. The vote address is the shared target. Mixing them can produce a plausible-looking but irrelevant balance query.

Identify the target and identify control

Read SolanaBull’s published identifiers

The SolanaBull profile publishes identity CtvdyHYt8cMuGVHFarV2RADfoCdnrbd8e9jAsB225uMW and vote account FLCrbfbwEhFARa8nK9rnZw8BVtKNAuHujh9EhWy5A4U4. These are public starting identifiers, not private keys.

Open the vote address in an explorer for mainnet and inspect its current parsed state or a suitable RPC response. Compare its node identity with the profile. A current lookup establishes the association at that observation; a saved historical snapshot describes its own earlier date.

Next read settings such as applicable commission and the fields exposed by the current protocol and source. A profile's dated commission snapshot should stay labelled with its date rather than becoming a live rate.

Finally inspect a separate stake account you control, if you have one. Its delegation field should name the intended vote address. Its authorities should match the setup you authorised. This completes the identity→vote←stake relationship through actual account roles.

Keep collection accounts and permissions explicit

Validator income and operating requirements can involve distinct collection or funding arrangements. Identify the effective settings and any pending change before deciding which balance a monitor should observe.

A revenue destination answers where a particular stream goes. It does not necessarily identify the key that can change that setting, nor the accounts containing delegators' principal.

For operators, the funding guide examines the current admission and reserve model. For stakers, commission and reward streams explains which published percentages concern the position.

A useful public profile therefore names the identity, vote account, observation source and timestamp for changing settings. It gives readers stable lookup keys without disguising snapshots as a live data feed.

Common questions