> 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

{% 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.
{% 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` 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.

### 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.

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 <vote-account> \
  --authority <bond-authority-keypair> \
  --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 <vote-account> \
  --authority <bond-authority-keypair> \
  --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.

### 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](/marinade-protocol/protocol-overview/stake-auction-market/bonds-settlements.md) 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 validator holding approximately 59,000 SOL of Marinade stake was blacklisted. Their entire position became available for redistribution 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 <bond-or-vote-account-address>` 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/dynamic-bids.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
