Incident Report: 37,000 SOL in Losses — A Call for Investigation and Action

Well, since Marinade has decided to stay silent and not comment on the situation, even after the people from the Top 10 themselves revealed the entire scheme of receiving free stake, we will continue to bring attention to the issue that has not been solved with the new fix. Validators are not receiving any penalties and continue to receive stake from Marinade, even with bids lower than 0.01 SOL.

In epoch 785, the MIN_effective_BID was 0.078 SOL. In this epoch, Marinade missed at least 199.72 SOL.

As of epoch 785, there are 92 validators receiving stake from Marinade, while their bid is less than 0.01 SOL. Two validators have been penalized. One was completely stripped of their bond — a total of 302.987 SOL was deducted as a penalty (55d5XyCu3Ap1yLHHJd6ChBT3pgP4HE6MPmJrU7TbAwYw), and the second lost only 44.971 SOL, but still has a remaining bond of 46.932 SOL (2wUhcnViyzstvWmk7NAboKtjbFbqJPo4BvFBV37dacLc), which will likely be enough for one more epoch.

The total stake, either fully or partially unpaid by validators for epoch 785, is 2,590,198.891 SOL (this figure already excludes the two penalized validators mentioned above).

Additionally, it’s worth noting that 5 validators have set their MEV commission to 100%, meaning that stakers are not receiving any MEV income from these validators. The total stake for these validators is 410,000 SOL.

Vote Account Marinade Activated Stake (SOL) Bid Cpmpe Inflation Commission MEV Commission Stake Priority Unstake Priority
1 55d5XyCu3Ap1yLHHJd6ChBT3pgP4HE6MPmJrU7TbAwYw 362335,1618 0.0001 0.07 0.1 288 142
2 Cue647T8jgwpRSDUb8ttTYx7NiEfJCRZNiiw1qmchXsG 337320,6683 0.0 0.05 0.1 283 134
3 4m1PbxzwLdUnEwog3T9UKxgjktgriHgE1CfAhMqDw7Xx 312484,9489 0.0 0.05 0.1 283 135
4 ErJmwESSzVrDuDJcN5L47XnM84JWDwTi6bDMWkrXqHSV 197150,4497 0.0 0.05 1.0 305 146
5 9f7dqiYNBZbgPesAnLeWnKCtxYHSfMg5x1EMZCJwVwG7 138792,4167 1,00E-09 0.0 0.1 248 102
6 4WGMxMKhjKz9TSmn6NA52AVipeE3zZNPBhQuBghZBvqU 131530,4489 0.0 0.07 1.0 308 61
7 Simpj3KyRQmpRkXuBvCQFS7DBBG6vqw93SkZb9UD1hp 129468,8123 1,00E-07 0.05 0.1 280 131
8 GMiBDMmwFRZfxVuHt3bXe6ZF7mGUBGWKXHLfY97NwQ72 109470,2366 0.007 0.05 0.1 264 120
9 21wUViiyG1g47VZ39ZZsSkFX9nu6bkyfy6jryHGD2TUB 107036,269 1,00E-09 0.0 0.1 248 103
10 EARTHZeTM64X3UMYf5rcWonQkTCn3uifEwutBx6e656K 82464,06124 0.0 0.07 0.1 290 143
11 StepeLdhJ2znRjHcZdjwMWsC4nTRURNKQY8Nca82LJp 80867,89661 0.0 0.07 1.0 308 148
12 5akpkYincAbsTBXVbf2GDCg4KatMnc8BKkXZCh7MWGPK 79391,67014 8,00E-05 0.0 0.1 241 98
13 3teZKwABvB99bxZc5q8yVWJt5mbhxgUAx4teMdUbzgN4 77283,1441 0.001 0.0 0.0999 236 94
14 2w4dcnbJDcGrAh4CFAYYpAaEJiUB2q1rFMGByBuB5Cqz 75867,35702 0.001 0.0 0.08 229 89
15 HvuXZAhAqSekCFueQ92DqxhuFvdBRrWeyA6uea6ZaS8q 74775,45883 0.001 0.0 0.1 237 95
16 2wUhcnViyzstvWmk7NAboKtjbFbqJPo4BvFBV37dacLc 61003,44797 0.0 0.0 0.0 217 85
17 3ZUQekqiZoybB57y49eqtvSaoonqDwuNbeqEGwN88JkQ 55635,66671 1,00E-09 0.0 0.0 216 81
18 Hx4UJCvf8amGeuW9fPFfTckRoznDHxPSYiU9HuUSZKLT 53320,58077 0.0 0.05 0.1 283 137
19 8ztfVJM7Yf7CMXqTGMGBkXmTkGCiJTgVfh1CYDZZND5b 52900,25462 0.0 0.05 0.1 283 139
20 EJHf5N9is5spAF5Kz384tTvTV3CwTka6qzUoZrYm53SV 51722,44536 1,00E-09 0.05 0.1 282 133
21 3tjGkvUsNEk8UBUQECCTpeAoo6NovHvEG44MZDPCcZko 48487,93843 0.005 0.05 0.1 268 123
22 3CnKZPQn92W8WXG7KTVaFQRk8LJJ3KZbrVVF4ngUxqkg 46126,73379 0.001 0.0 0.1 237 97
23 Fbnesg4kSDDoFbjaSiDQJ3GXHHAnNb1CJCgLQp4dxj4C 38185,19548 0.001 0.0 0.1 237 96
24 DsT3eKbWAaX9wVZQYBsbkDwpFA9NTDtXfsYc9wXUEWpn 34036,04015 8,00E-07 0.0 0.1 246 101
25 BHuk6wv9pskvSuMxzAFksmFNxEWZDHDsYWSwvTKcCnhx 30288,36569 0.004 0.0 0.07 220 87
26 HMLfMHdETcGSqPGAr38rSiwewsSZvLPMMPALc5pggtiW 27905,4588 0.002 0.05 0.1 272 127
27 8hPk5CbKDoM7dN9LssTdVkFhDykeq7A8CZurA5AQSFJH 23910,92528 0.05 0.05 271 0
28 Anv7J9kMdJWr1aU6rQvQyd24zBp5GscP8NeDpRqGKz8e 23505,10654 8,00E-07 0.07 0.1 289 62
29 323d4ZiSqS1PwGwpJwD88jNPaGqkm7YYW2tJt2T8iFzo 21707,64198 1,00E-05 0.0 0.1 244 100
30 CatzoSMUkTRidT5DwBxAC2pEtnwMBTpkCepHkFgZDiqb 20478,89426 0.0 0.0 217 0
31 8HKqT579dAjdTy86zKUs8kAaGDHXY11wDC3ohGCkLSQH 17185,46122 0.0085 0.05 0.1 261 119
32 sBcuGeMJCRkdtMNgskLTX7MePb4CzCqZuyMKDrcPP8v 16706,19795 8,00E-07 0.07 0.1 289 64
33 8FPz3JG4E3HVXxGbPZVibarva4AGXSZWx3qKLUS5uFtN 12358,63082 0.0 0.0 0.1 249 109
34 GA2t11gJcmuZ4y7pShTzgYDkxVaJaVQJqkVUqojhPPsT 10345,50666 4,00E-09 0.04 0.1 269 124
35 DTwEEF6VSrmTBYkDcj3BKAc52qhvP8CEQUEAMMT1cG3 10047,01665 0.0 0.0 0.1 249 108
36 GB44NXtM7zGm6QnzQjzHZcRKSswkJbox8aJsKiXGbFJr 9317,851004 0.0 0.01 0.08 253 112
37 J1to3PQfXidUUhprQWgdKkQAMWPJAEqSJ7amkBDE9qhF 8137,735347 0.0 0.08 234 0
38 juicQdAnksqZ5Yb8NQwCLjLWhykvXGktxnQCDvMe6Nx 6878,668786 0.0 0.04 0.08 267 121
39 H7fXvnLCKtZqJBTipxeseabGfAZUdHJ9XuP6hCKrbvUb 6012,574225 0.0 0.0 0.08 234 93
40 EARNynHRWg6GfyJCmrrizcZxARB3HVzcaasvNa8kBS72 3736,763268 0.0 0.0 0.1 249 104
41 WENuuMXGi8adKogNbQj33Vxgia9oA2erkWAPF4szWN1 3511,816524 0.0 0.0 0.0 217 86
42 DriFTm3wM9ugxhCA1K3wVQMSdC4Dv4LNmyZMmZiuHRpp 3357,078095 0.0 0.0 217 0
43 BeSov1og3sEYyH9JY3ap7QcQDvVX8f4sugfNPf9YLkcV 2321,337787 0.0 0.0 0.1 249 106
44 EpicsoqLdDP8qRn3wQRKTSKAXbjK9dUgFfNPRQS77MQD 2007,747526 0.0 0.0 217 0
45 FyrSH4VeQidMVPQ9AE2szAbP5xBZBprRG3z1QMMLNi5X 1631,074478 1,00E-06 0.0 0.1 245 51
46 3N7s9zXMZ4QqvHQR15t5GNHyqc89KduzMP7423eWiD5g 1599,176914 0.08 0.1 294 0
47 vahVByZszdHguLa7U7GLz8UdUFN85mcwdkefiqVjtGt 1577,373274 0.0 0.0 0.099 243 99
48 FnAPJkzf19s87sm24Qhv6bHZMZvZ43gjNUBRgjwXpD4v 1537,834954 0.0 0.0 0.08 234 91
49 ErvMUdtMC7AX55zKdYSyy4DnWNCrTsWn5GwprSG7ocnx 1309,747813 0.0 0.05 0.1 283 141
50 9kkP5sRnyHD3qkyHykyWwbP9pQQcTWnzLPHtDcRxaE16 1110,513148 1,00E-05 0.05 0.1 278 0
51 he1iusunGwqrNtafDtLdhsUQDFvo13z9sUa36PauBtk 1049,927491 0.0 0.0 0.0 217 46

I did not publish the remaining validators because their stake from Marinade in epoch 785 is less than 1000 SOL (and they also do not pay for it, or pay partially). 1000 SOL of free stake — is it really that much in the context of a 37,000 SOL loss? I’m right to assume this, aren’t I?

Also, I would like to address those validators who say something like: “Oh, I didn’t know I was doing something wrong. Yes, I took advantage of the vulnerability, but it’s not my problem, it’s Marinade’s fault.”

Dear validators, if you find a vulnerability in a banking system and exploit it, you’ll likely face real criminal charges in your country. But you probably won’t exploit that vulnerability because you understand the consequences.
However, vulnerabilities in Marinade can be exploited without any fear of consequences, right? Of course, no one will punish you. This is exactly what Marinade demonstrates with its behavior and by ignoring this thread.

Well, no worries, we will continue to raise awareness of the scale of the issue to the Solana Foundation.

I want to start with a necessary clarification: Marinade only reports realized APY — meaning actual returns earned by users, not projections or theoretical estimates based on validator bids.

Thanks to everyone who’s contributed to this thread. I want to clarify a few things and correct some misleading claims that have gained traction.

The 37,000 SOL figure circulated refers to estimated missed rewards, not actual loss. No user funds were ever at risk, and no SOL was “siphoned” from stakers. Marinade reports only the realized performance. The APY shown on the app and website reflects actual mSOL appreciation — not theoretical validator bids or ideal conditions.

A small number of validators indeed reduced their bids after winning stake in the auction. That wasn’t the behavior Marinade intended to reward. A fix for that is already live: the bid reduction penalty now punishes this exact pattern by slashing rewards when validators try to undercut their original bid. So far, more than 500 SOL has been redistributed to stakers through this mechanism.

Documentation is available here: Delegation Strategy v2 | Marinade.Finance

Some context around the scale: during the same 126-epoch window, Marinade stakers earned roughly:

  • 93,000 SOL from validator bids
  • 420,000 SOL in inflation rewards
  • 80,000 SOL in MEV
  • 2,000 SOL in PSR penalties
  • ~595,000 SOL total

The inefficiency identified accounts for around 6 percent of that—not zero, but not what the headlines make it out to be either.

There’s also been discussion around how unstake priority was implemented in the auction logic. Based on internal analysis and community input, including GitHub issue #24, it appeared that the system may unintentionally deprioritize unstaking from low-paying validators.

While the GitHub issue proposed a potential fix, Marinade’s engineering team evaluated it and determined it would not fully resolve it. Instead, the team has decided to address the problem holistically as part of a broader update to the priority system. This is under active development.

The auction was never designed to be perfect from day one. Like any living mechanism, it evolves with new data and behavior patterns. What matters is that the protocol can adapt, which has happened here. This wasn’t about negligence or allowing abuse. It was about identifying where a small set of actors were pushing past the boundaries of what the system anticipated, and tightening those boundaries accordingly.

There’s also a broader point getting lost in the narrative: MEV has existed on Solana long before SAM. Validators have been participating in MEV across the network for years. Marinade didn’t introduce that — it introduced a way to redirect some of that value to stakers. Users could share in MEV for the first time through open bidding, validator competition, and transparent rewards.

That’s not an exploit. That’s alignment.

Marinade also introduced mechanisms like Protected Staking Rewards, which require validators to post a bond that can be used to compensate users in the event of reward underperformance. This is not a free market where validators can disappear after getting stake. There are penalties, obligations, and incentives structured around protecting users.

There are ways SAM can improve — and it will. But the takeaway here isn’t that the system failed. It’s working as intended. Abusive behavior was identified, quantified, and addressed through a protocol-level change. No staker was harmed. All APY was based on actual returns. And the validator auction is already stronger than it was a month ago.

Looking ahead, Marinade is focused on improving the stability of the validator set and reducing unnecessary stake rebalances. This will help increase APY for stakers and ensure more stake flows for honest validators.

Specifically, the team is:

  • Designing a validator reputation system to reward consistently reliable operators
  • Exploring auction improvements to allow honest validators to earn more
  • Continuing to evaluate priority logic, following the recent fix via the BidTooLow penalty

Each of these changes is approached systematically, with a deep understanding of how they impact the broader rebalancing process. That’s the only way to design a complex system that serves users, maintains decentralization, and adapts to validator behavior over time.

Marinade will continue publishing data, evolving the system, and enforcing fairness through code. That’s the promise — and it’s being delivered.

4 Likes

Hello Repe,

I truly appreciate that you took the time to post an official response from the Marinade team in this thread. It’s good to see some movement — and the introduction of the BidTooLow penalty mechanism is definitely a step in the right direction.

That said, I’d encourage you to scroll back and take another look at the validators I mentioned earlier. Some of them aren’t being penalized at all under your new logic — despite having tiny or even zero bids and still continuing to receive delegation.
So yes, you may have patched one bug… but it seems another one is still alive and well. Please take a serious look.

If I may ask a straightforward question:

Why did this bug go unpatched for 120 epochs?

Let’s assume, for the sake of argument, that your team only recently became aware of the issue. But I know for a fact that multiple validators reached out months ago — some of whom underpaid Marinade by up to 1,000 SOL — and even created GitHub issues describing the problem in detail.

So what happened?

  • Was the bug reported internally but never escalated to you?
  • Or did the team knowingly decide not to fix it?

Honestly, I’m struggling to understand how a protocol that manages over 9 million SOL in TVL could let a flaw like this persist for so long. Whether it’s a communication breakdown or a product decision — neither looks great from the outside.

I hope you can clarify.

Jumping in here as a follow-up to @repe earlier response.

To clarify: Marinade was aware that some validators were underpaying after delegation due to how priority logic and rebalancing worked. This was a known inefficiency — not a critical bug — and one of several areas identified for improvement in the ongoing evolution of SAM.

At the time, the team prioritized other protocol-level work. Marinade operates with limited engineering capacity and focuses on system-level improvements rather than isolated quick fixes. Public communication was made to discourage this validator behavior, though it’s fair to say the message could have been more explicit.

A few important points:

  • Marinade has never advertised inflated APY
  • All APY reflects realized performance
  • User funds have consistently remained fully secure and actively earning yield

The recently launched BidTooLow penalty now addresses this validator behavior directly at the protocol level. A broader update to unstake priority logic is also underway, with implementation planning already in motion.

The framing that Marinade knowingly allowed a bug to persist for 120 epochs isn’t accurate. This was a matter of prioritization. SAM continues to evolve as designed, with adjustments made based on observed validator behavior and protocol performance over time.

It’s true that a few validators have set their MEV commission to 100%, meaning stakers don’t currently share in those rewards. Marinade is actively working through rebalances to adjust delegation away from these validators. However, the immediate focus is on rotating out of validators with zero bond first, in line with the protocol’s Protected Staking Rewards design. That sequencing helps maintain efficient delegation management while upholding performance expectations. This isn’t just about maximizing rewards — it’s about operating a consistent and reliable delegation process.

Regarding validators with very low or near-zero bids still holding delegation: through active rebalancing and redelegation to other validators. However, Marinade also factors in reallocation cost and network conditions when shifting large volumes of stake. Moving another 1–2 million SOL all at once would be inefficient and could reduce net yield. Instead, the reallocation is being handled in a targeted and accelerated way, with active oversight to ensure meaningful progress.

Appreciate the continued engagement — and happy to provide more detail where useful.

2 Likes

What exactly is the problem with a validator setting their MEV commission to 100%?

If a validator doesn’t run the Jito client, there wouldn’t be any MEV rewards to begin with. So choosing to run Jito and then keeping 100% of the MEV rewards shouldn’t be seen as an issue—it’s entirely within the validator’s discretion.

Of course, I agree that it’s inefficient and problematic if a validator with both a low bid and a low inherent APY continues to retain delegation. That much is clear.

However, Marinade’s auction is designed to delegate based on the total APY, which includes both the validator’s inherent APY and their bid. Even if a validator has a low inherent APY, as long as they make up for it with an adequate bid, it should not matter—and from a staker’s perspective, there’s no inherent reason why MEV rewards need to be part of the APY composition.

Let’s also remember that Marinade’s eligibility criteria are clearly defined:

  • Validator is not blacklisted (e.g., running harmful mods, commission rugs)
  • Validator runs a supported node version (within the specified semver bounds)
  • Validator’s final inflation commission is ≤ 7% (with bids and MEV commission considered as offsets)
  • Validator had >80% uptime in each of the last 3 epochs (based on stake-weighted vote credits)

As long as these conditions are met, how a validator chooses to structure their commission—including MEV—is entirely up to them. There is no justification for condemning that choice.

The way you highlight “MEV 100%” suggests a negative bias against validators who choose to keep all of their MEV rewards. I would encourage you—just as you often urge others—to focus on the data and engage in calm, logically consistent analysis.


EDIT:

Just to reiterate: in the specific case you were discussing, I do understand the concern with a validator that sets MEV commission to 100%, has a low inherent APY, and also bids low—yet still retains delegation. That’s a valid issue to raise.

However, I must say I’m a bit disappointed that, despite frequently stating you’re not making ethical judgments and are simply presenting data, you consistently mix in moral arguments. Unless that approach changes, it’s difficult to fully engage on the level of purely rational, data-driven discussion you often advocate for.

I genuinely hope you’ll continue the conversation with a clear focus on logic and data, without letting emotions or implicit value judgments cloud the analysis.

Good day.

There’s absolutely no issue with setting a 100% MEV commission — technically, that’s your call. But let’s be honest: the way you’re phrasing your question feels a bit disingenuous.
It seems like you already know the answer — but sure, let me walk through it anyway.

The MIN_effective_BID is defined as the minimum bid required from a validator with 0% inflation commission and 0% MEV commission.
If you decide to set your MEV commission to 100%, then you’re effectively extracting the entire MEV revenue from stakers.
That’s fine — but in return, you should be compensating Marinade with a higher bid, which in turn helps reimburse the stakers via auction mechanics.

But when a validator sets 100% MEV commission and a bid of 0 — what we have is a validator who pays nothing for the stake, and at the same time, steals the entire MEV upside from the staker.

At that point, it’s no longer just about Marinade losing out on auction revenue — the staker ends up holding the bag, with an APY that approaches baseline inflation, i.e., what you’d get from staking to a vanilla non-Jito validator.
So let’s not pretend this isn’t a problem — I trust we’ve clarified that now.


Now, regarding the terminology I’ve used to describe validators who exploit this behavior.
You’re apparently more upset about the words than the economic damage behind them.

So here’s a genuine question:
What term would you prefer to describe a validator who actively takes advantage of a protocol loophole to receive free stake and extract full MEV at the expense of the staker?

I’ve published the full methodology, the validator list, and detailed loss estimates.
Instead of pointing out flaws in the data — or proposing a better model — you’re focusing on my choice of labels?

Seems a bit odd, no?

Still, I’m open to suggestions.
If you’ve got a more “ethically neutral” term that doesn’t hurt anyone’s feelings, I’ll gladly adopt it going forward.
But let’s please shift the focus back to the numbers, not the semantics.

I understood that validators conducting sandwich attacks were banned, but are they still around?
However, I truly don’t understand how they are maintaining such high bids and still achieving an economically rational state.

Keeping the community looped in, as always.
It’s been 5 days since the last status dump — back then we were at epoch 785, now we’re clocking in at 788. So, 3 epochs later… what’s the delta?

MIN_effective_bid for 788 epoch = 0.0899

Number of validators with bidCpmpe < MIN_effective_bid: 85
That’s down by 7 nodes — used to be 92. Looks like some folks finally read the docs.

Total delegated SOL to these underbidders: 3,413,112.97 SOL
That’s a +31% spike (compared to 2,590,198 in epoch 785).
And guess what? The system is working as intended™.

The current lost profit of the pool for the 788th epoch is - 250 SOL

Only 2 out of those 85 validators triggered the new BidTooLow penalty.
And… is anyone really surprised? Most of these validators have been hard-sticking to bidCpmpe = 0 (or close enough), so the new penalty system is just background noise to them.

Scroll down for the table of validators who are riding with 1000+ SOL from Marinade.

voteAccount marinadeActivatedStakeSol bidCpmpe Inflation Commission MEV Commission Stake Priority Unstake Priority
Cue647T8jgwpRSDUb8ttTYx7NiEfJCRZNiiw1qmchXsG 334472,4254 0 0,05 0,1 273 128
4m1PbxzwLdUnEwog3T9UKxgjktgriHgE1CfAhMqDw7Xx 309581,1751 0 0,05 0,1 273 129
vskzrzSd6owQiNb2YA52ZM4YtRzmsSyp6dJbjx2zTVN 260401,4938 0,082 0 0,1 144 37
DPhzpiNGU9C6576uLsNSHmdi2AxwxpjMsRdh2iVC4TPh 208750,3714 0,08 0 0,1 146 70
ErJmwESSzVrDuDJcN5L47XnM84JWDwTi6bDMWkrXqHSV 197364,8843 0 0,05 1 298 140
9f7dqiYNBZbgPesAnLeWnKCtxYHSfMg5x1EMZCJwVwG7 138898,6203 1,00E-09 0 0,1 240 97
4WGMxMKhjKz9TSmn6NA52AVipeE3zZNPBhQuBghZBvqU 131670,5104 0 0,07 1 300 143
Simpj3KyRQmpRkXuBvCQFS7DBBG6vqw93SkZb9UD1hp 128309,5058 1,00E-07 0,05 0,1 271 125
9gANMngbGUmAaLXL1RC3JdiaLjRowJXNbzCTh53ht7mq 114185,0991 0,08 0 0 137 65
GMiBDMmwFRZfxVuHt3bXe6ZF7mGUBGWKXHLfY97NwQ72 108339,2121 0,007 0,05 0,1 259 114
21wUViiyG1g47VZ39ZZsSkFX9nu6bkyfy6jryHGD2TUB 107158,9541 1,00E-09 0 0,1 240 98
EARTHZeTM64X3UMYf5rcWonQkTCn3uifEwutBx6e656K 82551,78148 0 0,07 0,1 281 136
StepeLdhJ2znRjHcZdjwMWsC4nTRURNKQY8Nca82LJp 81394,87546 0 0,07 1 300 142
5akpkYincAbsTBXVbf2GDCg4KatMnc8BKkXZCh7MWGPK 79482,29161 8,00E-05 0 0,1 233 93
3teZKwABvB99bxZc5q8yVWJt5mbhxgUAx4teMdUbzgN4 77371,76732 0,001 0 0,0999 228 89
2w4dcnbJDcGrAh4CFAYYpAaEJiUB2q1rFMGByBuB5Cqz 75954,35784 0,001 0 0,08 223 84
HvuXZAhAqSekCFueQ92DqxhuFvdBRrWeyA6uea6ZaS8q 74861,20702 0,001 0 0,1 229 90
2wUhcnViyzstvWmk7NAboKtjbFbqJPo4BvFBV37dacLc 61036,37503 0 0 0 210 80
8StzUMT1Kq33EHPoFx9zYhfuvzAbiqeh5nE3DftLLDPG 60103,69085 0,04 0 0 162 73
ABs7XJAwHJpmBfC2y677bH5jzNtt5cAxXc14Q5bWgQRd 59415,09976 0,01 0,05 0,1 253 110
3ZUQekqiZoybB57y49eqtvSaoonqDwuNbeqEGwN88JkQ 54708,13471 1,00E-09 0 0 209 76
Hx4UJCvf8amGeuW9fPFfTckRoznDHxPSYiU9HuUSZKLT 52330,77599 0 0,05 0,1 273 132
8ztfVJM7Yf7CMXqTGMGBkXmTkGCiJTgVfh1CYDZZND5b 51730,87296 0 0,05 0,1 273 133
EJHf5N9is5spAF5Kz384tTvTV3CwTka6qzUoZrYm53SV 49893,36157 1,00E-09 0,05 0,1 272 127
3tjGkvUsNEk8UBUQECCTpeAoo6NovHvEG44MZDPCcZko 47526,53407 0,005 0,05 0,1 261 117
3CnKZPQn92W8WXG7KTVaFQRk8LJJ3KZbrVVF4ngUxqkg 46178,63431 0,001 0 0,1 229 92
Fbnesg4kSDDoFbjaSiDQJ3GXHHAnNb1CJCgLQp4dxj4C 38228,98188 0,001 0 0,1 229 91
ANRnEc3NFWyDFkJNHPnts9XAT1odt931qbgzMsSGdE1z 35648,6937 0,01 0,05 0,05 248 109
8D8XL6ovqx15RKwC1XtFyTz6H8JYF2fUsxTnsY4b123P 34857,93898 0,075 0 0 142 69
DsT3eKbWAaX9wVZQYBsbkDwpFA9NTDtXfsYc9wXUEWpn 34027,83092 8,00E-07 0 0,1 238 96
BHuk6wv9pskvSuMxzAFksmFNxEWZDHDsYWSwvTKcCnhx 30284,08386 0,004 0 0,07 213 82
76DafWkJ6pGK2hoD41HjrM4xTBhfKqrDYDazv13n5ir1 28188,80313 0,01 0,05 0,1 253 111
HMLfMHdETcGSqPGAr38rSiwewsSZvLPMMPALc5pggtiW 27348,78789 0,002 0,05 0,1 264 121
Anv7J9kMdJWr1aU6rQvQyd24zBp5GscP8NeDpRqGKz8e 23530,14604 8,00E-07 0,07 0,1 280 50
323d4ZiSqS1PwGwpJwD88jNPaGqkm7YYW2tJt2T8iFzo 21666,60491 1,00E-05 0 0,1 236 95
8HKqT579dAjdTy86zKUs8kAaGDHXY11wDC3ohGCkLSQH 16840,81923 0,0085 0,05 0,1 254 113
sBcuGeMJCRkdtMNgskLTX7MePb4CzCqZuyMKDrcPP8v 16724,01134 8,00E-07 0,07 0 274 51
8FPz3JG4E3HVXxGbPZVibarva4AGXSZWx3qKLUS5uFtN 12372,80302 0 0 1 292 139
CSWfwhactcdyK2YcRmk3Hx1AZzNKDFnCecwiYsJDkuSm 12133,0349 0,011 0,05 0,05 247 108
GA2t11gJcmuZ4y7pShTzgYDkxVaJaVQJqkVUqojhPPsT 10356,86811 4,00E-09 0,04 0,1 262 118
GeYn4XjKycYJ6NqTFb94sYowMrtmKfHBcorE6SGAomQN 10335,13467 0,01 0,05 0 244 105
DTwEEF6VSrmTBYkDcj3BKAc52qhvP8CEQUEAMMT1cG3 10058,52348 0 0 0,1 241 103
GB44NXtM7zGm6QnzQjzHZcRKSswkJbox8aJsKiXGbFJr 9328,412354 0 0,01 0,08 245 106
8DHFGo3fDB8GudbNLZEyExLzXQPwvY4twybPbxwDnffx 8117,594564 0,085 0 0,1 141 68
juicQdAnksqZ5Yb8NQwCLjLWhykvXGktxnQCDvMe6Nx 6994,420739 0 0,04 0,08 260 115
H7fXvnLCKtZqJBTipxeseabGfAZUdHJ9XuP6hCKrbvUb 6019,449886 0 0 0,08 227 88
EARNynHRWg6GfyJCmrrizcZxARB3HVzcaasvNa8kBS72 3741,042078 0 0 0,1 241 99
WENuuMXGi8adKogNbQj33Vxgia9oA2erkWAPF4szWN1 3515,782977 0 0 0 210 81
BeSov1og3sEYyH9JY3ap7QcQDvVX8f4sugfNPf9YLkcV 3151,755416 0 0 0,1 241 100
Hoo2PaowEdA1owJ4t6uJFGdSbgyWV5qGYRtTVChHgw3x 2070,323293 0,080000222 0 0,0001 138 66
FyrSH4VeQidMVPQ9AE2szAbP5xBZBprRG3z1QMMLNi5X 1603,058266 1,00E-06 0 0,1 237 47
vahVByZszdHguLa7U7GLz8UdUFN85mcwdkefiqVjtGt 1579,182102 0 0 0,099 235 94
FnAPJkzf19s87sm24Qhv6bHZMZvZ43gjNUBRgjwXpD4v 1539,598457 0 0 0,08 227 86
ErvMUdtMC7AX55zKdYSyy4DnWNCrTsWn5GwprSG7ocnx 1311,160141 0 0,05 0,1 273 135
CogentC52e7kktFfWHwsqSmr8LiS1yAtfqhHcftCPcBJ 1143,06457 0 0 0 210 78
eondcw2upjH14EuvBzmn6HfGEGo8t9hG9JbXtPj6cym 1108,967145 0,01 0 0,1 203 44

To the Marinade team:
When are you finally going to fix your Stake Priority and Unstake Priority ranking logic for validators?
Isn’t it obvious by now that this is your core issue?

No amount of patchwork elsewhere will matter until this part of the system stops acting like a random number generator.

To be continued…

Good day. Please take a look at my last post in this thread…

This was in February, and no action has been taken yet?

We continue to maintain transparency and keep the community informed about the ongoing inefficiencies in Marinade’s ranking mechanism — an issue that, regrettably, remains unresolved.

It has now been 3 epochs since our last report (epoch 788); this update covers epoch 791.

Current MIN_effective_bid: 0.09246

  • Number of validators with bidCpmpe below this threshold: 80
    Down from 85 in the previous epoch. It appears some participants have started paying attention — albeit slowly.
  • Total SOL delegated to these validators: 2,576,289 SOL
    Previously: 3,413,112.97 SOL in epoch 788. That’s a 24.51% reduction in undercompensated stake — a welcome correction, all things considered.
  • The current lost profit of the pool for epoch 791 is 231 SOL.
  • Only one validator in this category received a BidTooLow penalty in this epoch:
    3pBPy27F1Wz3iVydZnGkdvefStrFm8UMCDakYZii8AUZ
    This validator has been excluded from the list below. All others included have not received any penalties.
voteAccount marinadeActivatedStakeSol bidCpmpe Inflation Commission MEV Commission Stake Priority Unstake Priority
Cue647T8jgwpRSDUb8ttTYx7NiEfJCRZNiiw1qmchXsG 334116,3528 0 0,05 0,1 265 106
ErJmwESSzVrDuDJcN5L47XnM84JWDwTi6bDMWkrXqHSV 197577,8264 0 0,05 1 290 118
4m1PbxzwLdUnEwog3T9UKxgjktgriHgE1CfAhMqDw7Xx 157035,8038 0 0,05 0,1 265 107
9f7dqiYNBZbgPesAnLeWnKCtxYHSfMg5x1EMZCJwVwG7 139011,6338 1,00E-09 0 0,1 234 76
4WGMxMKhjKz9TSmn6NA52AVipeE3zZNPBhQuBghZBvqU 131809,5912 0 0,07 1 292 121
Simpj3KyRQmpRkXuBvCQFS7DBBG6vqw93SkZb9UD1hp 128249,1765 1,00E-07 0,05 0,1 263 104
GMiBDMmwFRZfxVuHt3bXe6ZF7mGUBGWKXHLfY97NwQ72 107945,3794 0,007 0,05 0,1 252 93
21wUViiyG1g47VZ39ZZsSkFX9nu6bkyfy6jryHGD2TUB 107280,7471 1,00E-09 0 0,1 234 77
EARTHZeTM64X3UMYf5rcWonQkTCn3uifEwutBx6e656K 82638,96265 0 0,07 0,1 273 114
StepeLdhJ2znRjHcZdjwMWsC4nTRURNKQY8Nca82LJp 81480,80582 0 0,07 1 292 120
5akpkYincAbsTBXVbf2GDCg4KatMnc8BKkXZCh7MWGPK 79542,59847 8,00E-05 0 0,1 228 0
3teZKwABvB99bxZc5q8yVWJt5mbhxgUAx4teMdUbzgN4 77459,70459 0,001 0 0,0999 223 70
2w4dcnbJDcGrAh4CFAYYpAaEJiUB2q1rFMGByBuB5Cqz 76040,68458 0,001 0 0,08 218 65
HvuXZAhAqSekCFueQ92DqxhuFvdBRrWeyA6uea6ZaS8q 74946,29103 0,001 0 0,1 224 71
2wUhcnViyzstvWmk7NAboKtjbFbqJPo4BvFBV37dacLc 60646,54263 0 0 0 205 60
ABs7XJAwHJpmBfC2y677bH5jzNtt5cAxXc14Q5bWgQRd 59206,28294 0,01 0,05 0,1 246 88
3ZUQekqiZoybB57y49eqtvSaoonqDwuNbeqEGwN88JkQ 53171,52364 1,00E-09 0 0 204 56
Hx4UJCvf8amGeuW9fPFfTckRoznDHxPSYiU9HuUSZKLT 52059,12527 0 0,05 0,1 265 110
8ztfVJM7Yf7CMXqTGMGBkXmTkGCiJTgVfh1CYDZZND5b 51309,3643 0 0,05 0,1 265 111
EJHf5N9is5spAF5Kz384tTvTV3CwTka6qzUoZrYm53SV 49130,35677 1,00E-09 0,05 0 250 92
3tjGkvUsNEk8UBUQECCTpeAoo6NovHvEG44MZDPCcZko 47277,12558 0,005 0,05 0,1 254 96
3CnKZPQn92W8WXG7KTVaFQRk8LJJ3KZbrVVF4ngUxqkg 46231,10921 0,001 0 0,1 224 73
Fbnesg4kSDDoFbjaSiDQJ3GXHHAnNb1CJCgLQp4dxj4C 38268,10412 0,001 0 0,1 224 72
ANRnEc3NFWyDFkJNHPnts9XAT1odt931qbgzMsSGdE1z 35574,89721 0,01 0,05 0,05 241 87
8D8XL6ovqx15RKwC1XtFyTz6H8JYF2fUsxTnsY4b123P 34882,61515 0,075 0 0 137 49
BHuk6wv9pskvSuMxzAFksmFNxEWZDHDsYWSwvTKcCnhx 30318,50295 0,004 0 0,07 208 62
76DafWkJ6pGK2hoD41HjrM4xTBhfKqrDYDazv13n5ir1 27985,03971 0,01 0,05 0,1 246 89
HMLfMHdETcGSqPGAr38rSiwewsSZvLPMMPALc5pggtiW 27146,52792 0,002 0,05 0,1 257 100
Anv7J9kMdJWr1aU6rQvQyd24zBp5GscP8NeDpRqGKz8e 23555,01402 8,00E-07 0,07 0,1 272 30
323d4ZiSqS1PwGwpJwD88jNPaGqkm7YYW2tJt2T8iFzo 21688,61709 1,00E-05 0 0,1 230 75
sBcuGeMJCRkdtMNgskLTX7MePb4CzCqZuyMKDrcPP8v 16741,68613 8,00E-07 0,07 0 266 32
8HKqT579dAjdTy86zKUs8kAaGDHXY11wDC3ohGCkLSQH 16739,35973 0,0085 0,05 0,1 247 91
8FPz3JG4E3HVXxGbPZVibarva4AGXSZWx3qKLUS5uFtN 12386,86518 0 0 0,1 235 82
CSWfwhactcdyK2YcRmk3Hx1AZzNKDFnCecwiYsJDkuSm 12050,15362 0,011 0,05 0,05 240 86
GA2t11gJcmuZ4y7pShTzgYDkxVaJaVQJqkVUqojhPPsT 10367,11158 4,00E-09 0,04 0,1 255 97
DTwEEF6VSrmTBYkDcj3BKAc52qhvP8CEQUEAMMT1cG3 10069,92605 0 0 0,1 235 81
GB44NXtM7zGm6QnzQjzHZcRKSswkJbox8aJsKiXGbFJr 9338,901903 0 0,01 0,08 238 84
3xjfK9C9YNcta8MvK1US4sQ3bc6DEjoJoR3qLExGf9xE 8995,541523 0,011 0,05 0,1 245 28
8DHFGo3fDB8GudbNLZEyExLzXQPwvY4twybPbxwDnffx 8125,814569 0,085 0 0,1 135 48
juicQdAnksqZ5Yb8NQwCLjLWhykvXGktxnQCDvMe6Nx 7002,047127 0 0,04 0,08 253 94
H7fXvnLCKtZqJBTipxeseabGfAZUdHJ9XuP6hCKrbvUb 6026,283343 0 0 0,08 222 69
EARNynHRWg6GfyJCmrrizcZxARB3HVzcaasvNa8kBS72 3745,291217 0 0 0,1 235 78
WENuuMXGi8adKogNbQj33Vxgia9oA2erkWAPF4szWN1 3519,774851 0 0 0 205 61
BeSov1og3sEYyH9JY3ap7QcQDvVX8f4sugfNPf9YLkcV 3155,334593 0 0 0,1 235 79
CogentC52e7kktFfWHwsqSmr8LiS1yAtfqhHcftCPcBJ 1794,261648 0 0 0 205 58
vahVByZszdHguLa7U7GLz8UdUFN85mcwdkefiqVjtGt 1580,976227 0 0 0,099 229 74
FnAPJkzf19s87sm24Qhv6bHZMZvZ43gjNUBRgjwXpD4v 1541,348301 0 0 0,08 222 67
HLXktVmNFeELB5uL5nrpP4WL7jyi3TMyekxASVjDhZ1t 1518,734396 0,09 0 0 129 46
ErvMUdtMC7AX55zKdYSyy4DnWNCrTsWn5GwprSG7ocnx 1312,574841 0 0,05 0,1 265 113

As we can see from the table, validators holding 100k–300k SOL in stake with a bid of 0 have an Unstake Priority of around 100.
In practice, this means that — under the current auction logic — bots will never reach them to reallocate stake.
Their position effectively removes them from the competition, yet their stake remains untouched.

I believe that the emergency unstaking of these validators has progressed in the most recent epoch, leading to improved health of the system. Sooner or later, I think the remaining delegations will also be unstaked in order.

I think the community should focus on the more serious Marinade Sandwicher problem rather than this issue. Currently, it is undoubtedly serving as a breeding ground for Marinade’s Sandwichers and harming the Solana network experience, which should be improved immediately. https://x.com/chrischang43/status/1925629929900687609

Epoch 794 Report

Three epochs have passed since the last report (previously epoch 791).

MIN_effective_bid = 0.07492 SOL

  • Number of validators with bidCpmpe below MIN_effective_bid: 59
    This is a decrease of 21 from the previous count of 80.
  • Total SOL delegated to these validators: 1,541,261 SOL
    (Previously 2,576,289 SOL — a nearly 40% reduction in unpaid stake. Excellent progress!)
  • Two validators with a bid below the MIN_effective_bid in this epoch received a BidTooLow penalty:
    • 6rC1zg98a89eQurdnvXz6uJ3zZZa2f683WwCDB41Us8w
    • 8F4e1nbeC6hn9jkojtboERZGaafxUUtsqUy3MKJLohkh
      (This validator has been excluded from the list below. The list only includes validators with no penalties.)
  • Total penalties paid by these two validators: 73.46 SOL
  • Missed revenue for Marinade: 111 SOL
  • Net missed revenue after penalties: 37.54 SOL
    The core team has nearly resolved the issue.

Below is a table listing validators with over 1,000 SOL delegated from Marinade.

Vote Account Marinade Stake (SOL) Bid CPMPE Inflation Commission MEV Commission Stake Priority Unstake Priority
Cue647T8jgwpRSDUb8ttTYx7NiEfJCRZNiiw1qmchXsG 183707,8779 0,001 0,05 0,1 250 118
4m1PbxzwLdUnEwog3T9UKxgjktgriHgE1CfAhMqDw7Xx 157203,9968 0,001 0,05 0,1 250 119
9f7dqiYNBZbgPesAnLeWnKCtxYHSfMg5x1EMZCJwVwG7 138709,2406 1,00E-09 0 0,1 223 93
21wUViiyG1g47VZ39ZZsSkFX9nu6bkyfy6jryHGD2TUB 107401,7604 1,00E-09 0 0,1 223 94
GMiBDMmwFRZfxVuHt3bXe6ZF7mGUBGWKXHLfY97NwQ72 99779,53839 0,007 0,05 0,1 242 109
5akpkYincAbsTBXVbf2GDCg4KatMnc8BKkXZCh7MWGPK 77639,80223 8,00E-05 0 0,1 217 90
3teZKwABvB99bxZc5q8yVWJt5mbhxgUAx4teMdUbzgN4 77547,08012 0,001 0 0,0999 212 86
2w4dcnbJDcGrAh4CFAYYpAaEJiUB2q1rFMGByBuB5Cqz 76126,45968 0,001 0 0,08 207 81
HvuXZAhAqSekCFueQ92DqxhuFvdBRrWeyA6uea6ZaS8q 75030,83125 0,001 0 0,1 213 87
ABs7XJAwHJpmBfC2y677bH5jzNtt5cAxXc14Q5bWgQRd 57199,75578 0,01 0,05 0,1 236 105
3CnKZPQn92W8WXG7KTVaFQRk8LJJ3KZbrVVF4ngUxqkg 46283,25823 0,001 0 0,1 213 89
3ZUQekqiZoybB57y49eqtvSaoonqDwuNbeqEGwN88JkQ 45369,13897 0,002 0 0 191 72
EJHf5N9is5spAF5Kz384tTvTV3CwTka6qzUoZrYm53SV 43461,27171 0,010000001 0,05 0,1 235 104
Fbnesg4kSDDoFbjaSiDQJ3GXHHAnNb1CJCgLQp4dxj4C 38311,26991 0,001 0 0,1 213 88
ANRnEc3NFWyDFkJNHPnts9XAT1odt931qbgzMsSGdE1z 34641,13334 0,01 0,05 0,05 230 103
BHuk6wv9pskvSuMxzAFksmFNxEWZDHDsYWSwvTKcCnhx 29605,61302 0,004 0 0,07 197 78
76DafWkJ6pGK2hoD41HjrM4xTBhfKqrDYDazv13n5ir1 26022,55933 0,01 0,05 0,1 236 106
323d4ZiSqS1PwGwpJwD88jNPaGqkm7YYW2tJt2T8iFzo 21578,58392 1,00E-05 0 0,1 219 92
8HKqT579dAjdTy86zKUs8kAaGDHXY11wDC3ohGCkLSQH 15469,64918 0,0085 0,05 0,1 237 107
CSWfwhactcdyK2YcRmk3Hx1AZzNKDFnCecwiYsJDkuSm 11234,94186 0,011 0,05 0,05 229 102
GA2t11gJcmuZ4y7pShTzgYDkxVaJaVQJqkVUqojhPPsT 10315,49874 4,00E-09 0,04 0,1 245 113
DTwEEF6VSrmTBYkDcj3BKAc52qhvP8CEQUEAMMT1cG3 10081,27285 0 0 0,1 224 98
GB44NXtM7zGm6QnzQjzHZcRKSswkJbox8aJsKiXGbFJr 9349,326091 0 0,01 0,08 227 100
3tjGkvUsNEk8UBUQECCTpeAoo6NovHvEG44MZDPCcZko 8163,650764 0,005 0,05 0,1 244 112
juicQdAnksqZ5Yb8NQwCLjLWhykvXGktxnQCDvMe6Nx 7027,176591 0 0,04 0,08 243 110
H7fXvnLCKtZqJBTipxeseabGfAZUdHJ9XuP6hCKrbvUb 6033,074161 0 0 0,08 211 85
EARNynHRWg6GfyJCmrrizcZxARB3HVzcaasvNa8kBS72 3749,514019 0 0 0,1 224 95
WENuuMXGi8adKogNbQj33Vxgia9oA2erkWAPF4szWN1 3523,74207 0 0 0 194 77
BeSov1og3sEYyH9JY3ap7QcQDvVX8f4sugfNPf9YLkcV 3158,891728 0 0 0,1 224 96
CogentC52e7kktFfWHwsqSmr8LiS1yAtfqhHcftCPcBJ 1820,97979 0 0 0 194 75
vahVByZszdHguLa7U7GLz8UdUFN85mcwdkefiqVjtGt 1582,759567 0 0 0,099 218 91
FnAPJkzf19s87sm24Qhv6bHZMZvZ43gjNUBRgjwXpD4v 1543,086958 0 0 0,08 211 83
ErvMUdtMC7AX55zKdYSyy4DnWNCrTsWn5GwprSG7ocnx 1313,980672 0 0,05 0,1 256 124

But as we can see from the table, the issue with the incorrect calculation of Unstake Priority still hasn’t been resolved. :frowning:

Stay tuned for further updates…