How To Model Flat Rakeback in a Solver
Hey everyone,
I discovered a simple trick for accurately modeling flat rakeback in GTO solvers. As you probably know, solvers allow you to input rake percentages and caps but don't explicitly account for rakeback. I wanted a way to model rakeback in a solver. As it turns out, there's a surprisingly easy way to do it.

Just multiply the rake% and cap by (1 - Rakeback%).
For example, if your nominal rake is 5% with a 3bb cap and you have flat 10% rakeback, set your solver parameters as:
- Rake% = 5% * (1 - 10%) = 4.5%
- Cap = 3bb * (1 - 10%) = 2.7bb

This method works regardless of stack depth, ranges, or texture. It perfectly models the implications of a flat rakeback structure in cash games.
Mathematical Proof:
Spoiler
Initially, I expected this would be complicated due to varying pot sizes and the fact that not every pot hits the rake cap. However, the math is straightforward:
Net rake after rakeback (RB%) is:
- min(cap, pot × rake%) × (1 - RB%)
Since (1 - RB%) is a positive constant, it commutes with the min function, so we can rewrite as:
- min(cap × (1 - RB%), pot × rake% × (1 - RB%))
Empirical Proof:
Spoiler
I verified this empirically using solver-generated data. I exported 100k GTO hands and created a histogram of pot sizes. The results perfectly confirmed the math:
- 5% rake with 3bb cap and 10% flat RB = 4.5% rake with 2.7bb cap and no RB.

Here's the spreadsheet. Enter your rake settings in blue, and it calculates your expected rake (yellow).
I genuinely expected modeling rakeback to be difficult, involving complicated pot-size distributions. Surprisingly, the math turned out simple, yet I couldn't find any guide online explicitly explaining how to represent rakeback correctly in solvers.
Shortcomings:
This method makes two assumptions:
First, it assumes rakeback is flat. Real rakeback structures are complex, but most pros approximate their RB as a flat % anyway.
Second, it assumes everyone has identical rakeback. Theoretically if your opponent is getting a different RB deal that changes the optimal strategy.
Why?
Spoiler
As an extreme example, imagine hero pays no rake. If you're playing against someone who also pays no rake, then it's a chip EV game. However, if your opponent is paying 100% rake, then you should just open any two cards and win every pot. Strategy [cEV vs cEV] ≠ Strategy [cEV vs 100% rake]. Obviously that's unrealistic, but it illustrates the fact that your best strategy depends on how your opponent values chips, not just how you value chips. It creates similar dynamics to ICM spots in MTTs where players have different utility functions leading to new and weird strategic dynamics. Alas, none of this matters as you can't model multiple RBs in a solver anyway.
In short, if you can approximate your RB as a flat%, and your RB deal is somewhat typical (close the pool avg), then this method is a simple and effective way to model RB in a solver.
8 Replies
"Alas, none of this matters as you can't model multiple RBs in a solver anyway."
Do you think this is just a consequence of the developers not considering this situation as important, or is there an actual hard limitation to implemet something like this in the code or model it mathematically? (e.g. oop pays 5% with 4 bbs cap, ip pays 4% with 3.2 bbs cap).
One possible site where players might potentially have very different RB%s is GG with its PVI system.
This isn't correct.
4% rake isn't the same as 5% rake with 20% rakeback. The GTO solution would be different.
"Alas, none of this matters as you can't model multiple RBs in a solver anyway."Do you think this is just a consequence of the developers not considering this situation as important, or is there an actual hard limitation to implemet something like this in the code or model it mathematically? (e.g. oop pays 5% with 4 bbs cap, ip pays 4% with 3.2 bbs cap).One possible site where
Super easy to implement.
This isn't correct.
4% rake isn't the same as 5% rake with 20% rakeback. The GTO solution would be different.
It is correct. The GTO solution would be the same.
I posted a mathematical and empirical proof to support this.
"Alas, none of this matters as you can't model multiple RBs in a solver anyway."Do you think this is just a consequence of the developers not considering this situation as important, or is there an actual hard limitation to implemet something like this in the code or model it mathematically? (e.g. oop pays 5% with 4 bbs cap, ip pays 4% with 3.2 bbs cap).One possible site where
It's somewhat straightforward to implement, i just doubt many people would actually run multiple solutions just to get the RB details lined up correctly. Modeling multiple different RB settings within a single sim really hasn't been a common request.
(Fwiw, we've suggested that same cap/rake adjustment as standard rakeback work-around on our discord since i remember 😀)
It's somewhat straightforward to implement, i just doubt many people would actually run multiple solutions just to get the RB details lined up correctly. Modeling multiple different RB settings within a single sim really hasn't been a common request.
Agreed, it's one of those features that wouldn't be hard to develop, but there's just no demand for it. For those that don't know, plexiq is the developer of HRC!
(Fwiw, we've suggested that same cap/rake adjustment as standard rakeback work-around on our discord since i remember 😀)
You know, this RB adjustment is so obvious in hindsight, but no one had ever spelled it out for me so I just assumed it would be super difficult.
I think many people are in the same boat, even sharps like ZK assumed RB shouldn't be this simple 😉
Imagine a 4% rake GTO game in which we are considering bluff 5b shoving preflop with A5s.
In GTO the EV of the shove is exactly 0.
However, if we keep everything the same and only increase the rake to 5% with 20% rakeback, suddenly, 5b shoving A5s becomes slightly +EV, because we are now getting some of the money back when we lose.
Perhaps an even better example would be when we bluff shove the river with a 0% equity hand. We'd very much prefer to have higher rake and rakeback.
Point is, I don't think both of those rake structures can be considered identical. Even though in practice they are very similar and the solutions would be practically indistinguishable.
ZK, we're using different definitions. The term "flat rakeback" is ambiguous.
Imagine a pot-sized 100bb river bluff shove. Comparing [5% rake + 20% RB] against [4% rake no RB]:
- In a straightforward winner-takes-all rakeback model, the rake structures are identical. This is what I had in mind.
- By the sounds of it, you're referring to some kind of Contributed rakeback model. In this case, the rake structures are not identical.

Side note: it's not necessarily correct to say "the EV should change," because the villain should adjust their defense to make your river bluff indifferent. However, I concede that the GTO strategies would no longer be identical under the more complex weighted contribution rakeback model.
p.s. ty Zamadhi for pointing this out to me
Ah, my bad. The sites that I play on all use the contributed model for rakeback, so I automatically assumed that.
For the winner-takes-all model your math is correct.


