li yao

Posted on Oct 26

Three Roblox revenue splits, and why almost every tax calculator gets them wrong

#showdev #webdev #javascript #roblox

I was building a small calculator for Roblox payouts and did what I usually do first: looked at what already existed, to see what the competition got right.

They disagreed with each other. Same input, different answers — sometimes by more than 2x.

That's a bad sign for a category of tool whose entire job is arithmetic. So I went to the source: Roblox's creator documentation. It turns out there isn't one "Roblox tax". There are three separate payout structures, plus a fourth layer (the cash-out rate) that most calculators also get wrong.

Here they are, with the numbers straight from the docs.

1. In-experience items: a flat 30% platform commission

Game passes, developer products, private servers. Roblox takes 30% of the sale, the creator keeps 70%.

This is the structure everyone means when they say "the Roblox tax", and it's the one where the popular price * 0.7 formula happens to be correct.

2. Marketplace avatar items: a progressive revenue share

This is where it falls apart. Avatar items sold on the Marketplace (clothing, accessories, emotes) don't use a flat fee. The creator's share grows with the price relative to the item type's price floor:

Price vs floor	Creator share
1×	30%
1.3×	37%
1.5×	41%
2×	50%
3×	62%
4×	67%
6× and above	70%

At the floor price, the creator keeps 30%, not 70%. A flat-30%-fee calculator overstates a UGC seller's payout by more than double.

The docs also note that if the item is bought inside an experience rather than in the Marketplace, the split becomes three ways — 30% creator, 40% experience owner, 30% Roblox.

3. Limited resales: a four-way split

Reselling a community-created Limited splits the sale price as 50% reseller / 10% original creator / 10% seller-affiliate / 30% Roblox.

This one matters because it kills a specific fantasy: buy at 1,000 and flip at 1,000 and you get 500 back, not 1,000. Any "flipping profit" arithmetic that ignores this is fiction.

4. The cash-out rate, which has three values

Even after the platform takes its cut, "how much is this worth in dollars" has more than one answer. The Developer Exchange programme currently publishes:

Rate	Applies to
`0.0038` USD per Earned Robux	Standard rate
`0.0054`	In eligible games, purchases by US players verified 18+
`0.0035`	Earned Robux held before 5 Sep 2025, 10am PT

And the minimum is 30,000 Earned Robux — where "earned" excludes Robux you bought yourself or got from trading. A wallet full of Robux isn't the same as a wallet full of cashable Robux.

The bug: one formula, three structures

The failure mode isn't bad arithmetic. It's wrong premise: someone reads the 30% commission rule, writes payout = price * 0.7, and ships it. That code is correct for exactly one of the three structures and silently wrong for the others.

Worse, it's plausibly wrong. A user who sells game passes gets the right answer, tells a friend, and the friend — who sells UGC — gets a number that's off by 130% and assumes it's their own mistake.

The fix is embarrassingly small

The correct implementation isn't clever math. It's making the user state which structure they're under, then applying a lookup:

const SCENARIOS = {
  inExperience:     { pct: 0.70, label: 'Game pass / developer product' },
  ugcAtFloor:       { pct: 0.30, label: 'Marketplace item at its floor' },
  ugcAt2xFloor:     { pct: 0.50, label: 'Marketplace item at 2× floor' },
  ugcAt6xFloor:     { pct: 0.70, label: 'Marketplace item at 6× floor or more' },
  limitedResale:    { pct: 0.50, label: 'Reselling a Limited' },
};

function payout(price, scenario) {
  const pct = SCENARIOS[scenario].pct;
  return Math.floor(price * pct);   // Roblox floors the creator's share
}

That's it. One select, one lookup table, one multiplication. The engineering value isn't in the arithmetic — it's in refusing to guess which row of the table the user is on.

I also added the reverse direction, because "I want 1,000 Robux after the cut" is the question people actually ask:

const requiredPrice = Math.ceil(target / pct);

What I took away from this

A tool category where competitors disagree is a signal, not a problem. If ten calculators give ten answers, at least nine are wrong, and the tenth probably doesn't say why.
Copying a competitor's formula is how you inherit its bug. The only defensible source was the publisher's own docs — and they were more nuanced than any calculator I found.
Every page should state which scenario it applies to. "30% tax" isn't a fact; it's a fact conditional on what you're selling.
Ship the caveat. The page states plainly that a 1,000 Robux game-pass sale works out to about $2.66 — not the roughly $10 a player spends to buy that much Robux — and that the figure only holds for the structure you selected. Under-promising on a calculator is what makes people trust the numbers.

The tool is at gameformulas.com if you want to poke at it — it's static HTML with a few lines of vanilla JS, no framework, no backend, no analytics. Every figure on the page links to the documentation it came from and the date it was last checked.

If you've built something similar: did you handle the UGC progressive share, or did you inherit the flat-30% assumption like I almost did?

DEV Community