> For the complete documentation index, see [llms.txt](https://docs.marinade.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/dynamic-bids.md). # Dynamic Bids How dynamic commission bids work and how to configure them in the validator bonds CLI. {% hint style="info" %} **TL;DR:** Configure inflation, MEV, and block commissions in basis points (validator's portion kept). The effective bid recalculates each epoch from actual rewards, keeping the validator competitive without manual updates. On-chain commission acts as a floor. A stream left unset counts as 100% kept, so it contributes nothing. {% endhint %} ## Overview Dynamic bidding allows the effective bid to recalculate automatically each epoch based on actual rewards, rather than locking the validator into a fixed lamport number that can overshoot when rewards are low or leave the validator uncompetitive when rewards are high. Commission parameters are set once. The auction adjusts the effective bid each epoch from there. *** ## How the Effective Bid Is Calculated The auction bid is determined by three commission parameters set in the validator bonds CLI. * **`--inflation-commission`:** The portion of inflation rewards the validator keeps, in basis points. * **`--mev-commission`:** The portion of MEV rewards the validator keeps, in basis points. * **`--block-commission`:** The portion of block rewards the validator keeps, in basis points. Each parameter is expressed in basis points (bps), where 10,000 bps = 100%. A value of `0` means the validator keeps 0% (shares 100% with stakers). A value of `10,000` or above means the validator keeps 100% (shares 0% with stakers). The remainder after the validator's commission is what gets shared with stakers through the auction. Together, these three settings determine the effective bid, which is the number SAM uses to rank validators in the auction each epoch. Dynamic bidding does not change how rewards work. It only changes how the auction bid is calculated. {% hint style="warning" %} **Unset is not the same as zero.** A commission the validator never configures is treated by the auction as **100% kept**, so that reward stream contributes nothing to the yield offered to stakers. This matters most for `--block-commission`, which most validators have never set: block rewards are part of the SAM eligibility floor, so leaving it unset makes the floor harder to clear. See Eligibility Criteria. {% endhint %} {% hint style="info" %} **Negative values are permitted.** A commission below `0` bps means the validator keeps nothing and subsidises stakers beyond the rewards that stream actually produced, funded from the bond. The auction enforces a lower bound on how negative a commission may go (`minimalCommission` in [`auction-config.json`](https://github.com/marinade-finance/ds-sam-pipeline/blob/main/auction-config.json)). This is an advanced setting: it increases the bond draw every epoch it is in force. {% endhint %} ### What It Costs Dynamic bidding costs exactly the rewards a validator chooses to share, nothing more. Unlike a static bid (a fixed lamport amount), the dynamic portion adjusts with actual earnings each epoch. The validator sets a ceiling through the commission settings, and the market determines what is actually paid. When rewards are low, the SOL amount paid out is lower. When rewards are high, the validator may share more in absolute terms but stays competitive without manual adjustment. *** ## Marinade-Attributable Rewards Only Commission settings apply only to rewards generated by Marinade-delegated stake. A common misunderstanding is that these commissions apply to all of a validator's rewards. They do not. The settings only affect the rewards generated by the portion of stake delegated by Marinade. The rest of the validator's stake (other delegators, self-stake, SFDP) is unaffected. **Example:** A validator sets `--block-commission` to 7,000 bps, keeping 70% of Marinade-attributable block rewards and sharing 30% with stakers. The validator produces 100 SOL in block rewards this epoch, and Marinade represents 20% of their total stake. The bond is charged on the shared portion of the Marinade-attributable rewards: ``` 30% × 100 SOL × 20% = 6 SOL ``` If the same validator had set `--block-commission` to 5,000 bps (keeping 50%, sharing 50%), their effective bid would have been higher, but if they had set it to 9,000 bps (keeping 90%, sharing only 10%), the effective bid would likely have fallen below the auction clearing price, and they would have received no Marinade stake that epoch. ### On-Chain Commission as a Floor A validator's on-chain commission settings still apply as a floor. Dynamic commission can share **more** than the on-chain commission implies, but it cannot share less than what has already been committed on-chain. For inflation, the auction uses the lower of the on-chain rate and the bond rate. For MEV, the bond rate is used only when it is strictly lower than the on-chain rate. In practice: if a validator's on-chain inflation commission is 5% (the validator keeps 5%, stakers receive 95% on-chain) and `--inflation-commission` is set to 0 bps in the bond (committing to keep 0%, share 100% with stakers), the auction will charge the bond the difference and share that extra 5% with stakers through bond settlements. *** ## Common Configurations Two configurations cover most validators' needs. ### **Maximum Competitiveness: 0 / 0 / 0** ```bash validator-bonds -um configure-bond \ --authority \ --inflation-commission 0 \ --mev-commission 0 \ --block-commission 0 ``` This shares 100% of Marinade-attributable inflation, MEV, and block rewards with stakers (validator keeps 0% across all three). The effective bid rises and falls with actual earnings, keeping the validator competitive without monitoring the auction. This is a strong starting point but is not always enough on its own. If a validator's base APY is below the auction clearing price even after sharing 100% of Marinade-attributable rewards, a static CPMPE bid may also be needed on top. ### **Margin Floor: 0 / 0 / 3,000** ```bash validator-bonds -um configure-bond \ --authority \ --inflation-commission 0 \ --mev-commission 0 \ --block-commission 3000 ``` This shares 100% of Marinade-attributable inflation and MEV with stakers, while keeping 30% of block rewards for the validator (sharing 70%). Useful for validators whose hosting costs require a guaranteed margin floor on block rewards. The bid stays competitive in most epochs while retaining a known share of block rewards. Trade-off: in high-competition epochs, the validator may fall below the clearing price. {% hint style="info" %} **CLI notes.** Commission settings are stored in a separate on-chain configuration account, so the first `configure-bond` call that sets a commission may need `--rent-payer` to fund that account. Separately, `configure-bond` refuses to decrease `--cpmpe` unless `--force` is passed, because lowering a static bid while holding Marinade stake triggers the Bid Reduction Penalty. {% endhint %} *** ## Static Bids and Dynamic Bids Together Dynamic bidding is the recommended default, but static bids still have a role. Most validators get the best result by combining both: dynamic commission to keep the bid responsive to actual rewards, plus a static CPMPE if their base APY needs an additional boost to clear the auction. The two are charged independently: * **Static bid (CPMPE):** Charged from the bond based on Marinade stake delegated and the realized yield of the auction. * **Dynamic commission:** Charged from the bond based on the difference between on-chain commissions and the configured bond commissions, applied to Marinade-attributable rewards earned that epoch. See Bonds Settlements for the full charging mechanics. #### **Example Scenario: Capturing Redistribution Events** Large redistribution events happen more often than most validators realize. When a validator with significant Marinade stake runs out of bond, withdraws from the auction, or gets removed, their stake needs to go somewhere fast. The algorithm allocates top-down by `max_yield`, and validators whose effective bid is above the clearing price at that moment receive that stake automatically. In epoch 946, a mass blacklisting removed dozens of validators at once, including one holding approximately 59,000 SOL of Marinade stake and another holding approximately 98,000 SOL. Those positions became available for redistribution in that epoch. Validators whose commission settings kept their effective bid above the clearing price received that stake. Validators with stale or insufficient bids missed the window. Dynamic bidding keeps the effective bid continuously calibrated to actual rewards, so a validator is positioned automatically when these windows open. #### **Where to View the Configuration** Two sources reflect the current bond configuration. * **CLI:** Run `validator-bonds -um show-bond ` to see the current commission settings as stored on-chain. The CLI reflects state immediately after any transaction. * **PSR dashboard:** The [PSR dashboard](https://psr.marinade.finance/) shows bond configuration under the validator's profile. The dashboard refreshes every few hours and is for reference. Use the CLI as the source of truth. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/dynamic-bids.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.