Skip to content

Stake Auction Market (SAM)

maxStakeWanted Parameter

Cap the maximum amount of Marinade stake a validator wants to receive through SAM.

TL;DR: Cap the Marinade stake a validator wants. The CLI takes lamports, dashboards show SOL, confirm units. A 10,000 SOL floor overrides any lower setting, 0 or unset means no cap at all, and lowering the cap below current stake does gradually shed the excess.

Overview

The maxStakeWanted parameter sets a ceiling on how much Marinade stake a validator wants to receive through the Stake Auction Marketplace. Marinade will not target above this ceiling, but reaching it is not guaranteed. Validators must still place competitive bids and meet eligibility criteria to win stake up to the configured value.

Unit mismatch alert: The CLI (configure-bond --max-stake-wanted) takes the value in lamports. The PSR (Protected Staking Rewards) and validator-facing tools display it in SOL. 1 SOL = 1,000,000,000 lamports. Always double-check units before submitting the configuration transaction. A common mistake is typing the SOL amount into the CLI, which sets the cap at 0.000000001× the intended value.

How It Works

Each epoch the auction computes an effective cap from the configured value:

effective_cap = max(minMaxStakeWanted, maxStakeWanted > 0 ? maxStakeWanted : unlimited)

minMaxStakeWanted is currently 10,000 SOL. The live value is in auction-config.json. Note what is not in that formula: the validator's current Marinade stake plays no part in it.

A few behaviors to understand before configuring:

  • 10,000 SOL minimum floor: Setting maxStakeWanted below 10,000 SOL has no effect, the floor still applies. A validator wanting to be capped below 10,000 SOL cannot achieve this through maxStakeWanted alone.
  • Zero or unset means no cap: A value of 0, or never setting the parameter, resolves to unlimited, not to zero and not to the current stake. This is the opposite of what the number suggests and is the most common misreading of this setting.
  • The cap applies to the auction target, not only to new stake: Each epoch the auction rebuilds every validator's SAM target from zero and caps it at the effective cap. A validator whose current active Marinade stake is above the cap gets a target no higher than the cap, which puts it over target. The target can land lower still if a tighter constraint, most often bond capacity, binds before the cap does.
  • Lowering the cap does shed stake, gradually: Being over target places the validator in the general redelegation tier, so the excess is redelegated over following epochs as the per-epoch rebalance budget allows. It is gradual and there is no fixed timeline, but it does happen without withdrawing the bond. See Stake Distribution and Decentralization.
  • Bids are charged on stake actually held: While the excess is being redelegated, the validator continues to pay bids on whatever Marinade stake remains active each epoch, not on the lower cap.
  • Enforced each auction cycle: The cap is applied every epoch, so it takes effect from the next auction after the configuration transaction lands.
  • No effect when already at or below the cap: If existing delegated stake is at the cap, no new stake is targeted and nothing is shed.

Setting the Cap

Use the validator bonds CLI to set or update the cap.

validator-bonds -um configure-bond <vote-account-address> \
  --authority <bond-authority-keypair> \
  --max-stake-wanted <lamports>

For example, to cap incoming Marinade stake at 25,000 SOL:

validator-bonds -um configure-bond <vote-account-address> \
  --authority <bond-authority-keypair> \
  --max-stake-wanted 25000000000000

(25,000 SOL × 1,000,000,000 lamports/SOL = 25,000,000,000,000 lamports.)

Examples

Example 1: Capped Growth

A validator sets maxStakeWanted to 25,000 SOL and currently has 22,000 SOL delegated from Marinade. Even with a competitive bid, sufficient bond, and full eligibility, Marinade will only target up to 3,000 SOL more before the cap is reached.

Example 2: Cap Below Current Stake

A validator currently has 40,000 SOL delegated from Marinade and lowers maxStakeWanted to 30,000 SOL. From the next auction, the validator's SAM target is 30,000 SOL while 40,000 SOL is still active, so the validator is 10,000 SOL over target. That excess is redelegated to other validators over the following epochs, at the pace the per-epoch rebalance budget allows. The validator keeps paying bids on whatever remains active in the meantime. Withdrawing the bond is not required for this, and is the wrong tool unless the intention is to leave SAM entirely.

Example 3: Setting Below the 10,000 SOL Floor

A new validator sets maxStakeWanted to 5,000 SOL, expecting to be capped at 5,000 SOL. The effective cap is max(10,000, 5,000) = 10,000 SOL. The validator's setting is overridden by the floor, and Marinade may target up to 10,000 SOL if the bid is competitive. To stay below 10,000 SOL, the validator must rely on bid and bond sizing rather than the cap parameter.

Start with a small cap and raise it as the bond and operations can support more stake.

Raising the cap takes effect from the next auction. Lowering it also takes effect from the next auction, but the stake above the new cap leaves gradually rather than at once, so plan bond coverage for the transition period. Starting low gives validators control over growth and avoids being surprised by a large allocation that exceeds bond capacity.

Disabling the Cap

To remove the limit entirely, set the cap to 0 or leave it unset. Either resolves to unlimited, and growth is then governed only by bid competitiveness, bond size, and decentralization constraints. Setting a very large lamport value such as 1000000000000000000 (10^18) has the same practical effect.

Common Pitfalls

A few patterns that cause support tickets.

  • Setting the cap in SOL units instead of lamports: Causes the cap to be \~1 billion times smaller than intended. Always confirm units before submitting.
  • Setting the cap to 0 to stop receiving stake: Does the opposite. 0 means unlimited. To stop receiving Marinade stake entirely, withdraw the bond. See Eligibility Criteria.
  • Setting the cap below 10,000 SOL: Has no effect. The 10,000 SOL floor overrides any lower value.
  • Setting the cap too low and missing redistribution events: When other validators exit SAM (blacklist, bond withdrawal, bond underfunding), their stake is reallocated to validators with competitive bids. A conservative cap can lock a validator out of these allocations even if the bid would have won.
  • Setting the cap without considering bond capacity: The cap is independent of the bond, so a high cap with a small bond can lead to receiving more stake than the bond can cover. Insufficient bond relative to active stake triggers the Bond Risk Reduction Mechanism.
  • Expecting the cap to shed stake immediately: It does not. The excess leaves over multiple epochs, bounded by the rebalance budget.

Where to View the Current Setting

Two sources reflect the current maxStakeWanted value.

  • CLI: validator-bonds -um show-bond <vote-account-address> returns the on-chain value immediately. The CLI is the source of truth.
  • PSR dashboard: The PSR dashboard displays the current cap in SOL under the validator's bond configuration. Refreshes every few hours.

The effective cap actually applied in a given epoch, alongside the resulting SAM target, is in that epoch's folder in the ds-sam-pipeline auctions folder.