Robux Tax Rounding

tl;dr When selling something and the price times .7 = num.5, the resulting earnings should be num+1, not num.

Developers that don’t know about the tax rounding on dev products, gamepasses, or selling items are not making a full 70% when they sell something.

Example:
Every time you sell something for 15 robux, you are actually selling it for 14.2857142857 (10/.7) because that number times .7 is 10 robux, which is what you get when you sell something for 15.

Ok so let’s reverse that, since we obviously don’t want to have decimal robux.

With tax rounding up that would give 11, since 15*.7 is 10.5.
That way every time you sell something for 15 robux, it would be like selling it for 15.7142857143 (11/.7)
I understand the double standard here. But with 30% of robux already taxed, can we please get that 1 more robux each sale if we decide to sell something that rounds to some num.5?

This idea is to make the tax round up, to help out developers who do not want to make awkward prices for dev products, like 26 (you get 1 more robux than selling something for 25, and price only increased by 1)
Or 98 (you only get 1 more robux for selling it for 100, 2 more robux than 98)

3 Likes

Sounds good to me. My only fear would be that they might be reluctant to change something so ‘small’.

2 Likes

We can dream

1 Like

What is the reasoning behind this?

“Awkward prices” occur anytime you round - both rounding up and rounding down.

Additionally, if taxes rounded up, any transaction under 3 R$ would allow people to bypass the marketplace fee. People would start writing bots to transfer huge amounts of robux using developer products or game passes or t-shirts. We’d have to complicate the code even more to handle low robux amounts.

1 R$ * 0.7 = 0.7 R$ -> round up -> 1 R$
2 R$ * .7 = 1.4 R$ -> round up -> 2 R$
3 R$ * 0.7 = 2.1 R$ -> round up -> 3 R$

I personally think that this would just create problems and add complexity where it isn’t needed. This tiny amount of robux that you’re losing is way more than made up for by the fact that ROBLOX has increased the Developer’s Exchange rate twice in the last few months.

2 Likes

I didn’t mean rounding up if the resulting number is anywhere between .1 to .4, just talking about rounding up if the resulting number is .5. Currently anything over .5, but not including it, rounds up. Sorry for that confusion.

If you want to bring developer exchange rates rising into this, I could argue that - that 1 robux is worth even more and I want it even more. If a dev sells something for 15, they should get 11 not 10. Anywhere else off of Roblox 10.5 rounds to 11. Rounding consistency would be nice, all I’m trying to say here.

1 Like

Then you still have the 1-robux marketplace fee bypass. 1 * 0.7 = 0.7 -> round up -> 1

1 Like

I’ve never personally seen any issue with losing 1 robux. I’d just accept it and move on.

1 Like

How about it pays you in chunks and not immediately

If you get 10+ sales in an hour, you earn a rounded number of that.

You get less than 10, it checks until you’ve earned 10 in however many hours. Capping at a day.

So that way it’s not on a per purchase basis and more of on a broad scale. Instead of losing 1 R$ per sale, you might just lose 1 R$ per 10 or 100 sales.

2 Likes

[quote] How about it pays you in chunks and not immediately

If you get 10+ sales in an hour, you earn a rounded number of that.

You get less than 10, it checks until you’ve earned 10 in however many hours. Capping at a day.

So that way it’s not on a per purchase basis and more of on a broad scale. Instead of losing 1 R$ per sale, you might just lose 1 R$ per 10 or 100 sales. [/quote]
Oh my god, no. The last thing we need is more complexity with the way sales are rounded. It’d no longer be easy for developers to calculate their revenue from the sales page if we adopted an unintuitive “batch rounding” system.

Rounding down is consistent with the way we’ve been doing it for the last few years. Changing it would not only make things less consistent, but it would increase the complexity of transactions, since we’d have to add special edge case logic for prices less than 1 robux. Say you’re trying to calculate the income of your game passes since January 2012 - you’d have to do know the exact date that the rounding system changed, and you’d have to calculate the sales differently based on that.

And all this is because you guys are concerned about that 1 extra robuck?

1 Like

Then you still have the 1-robux marketplace fee bypass. 1 * 0.7 = 0.7 -> round up -> 1[/quote]

“since we’d have to add special edge case logic for prices less than 1 robux.”
First of all, no such thing as prices less than 1 robux.
Second, there’s already a special case for 1 robux. I don’t think or advocate that should change. I didn’t mention that lower numbers don’t follow the regular tax anyway. 2 robux = 1.4 = 1 robux, 50% tax. That’s fine, I don’t think any reasonable developer would sell something for lower than 4 robux anyway. 3 robux = 33% tax. Finally at 4 robux it gets to a great selling price (only 25% tax). It’s not going to kill the economy by giving developers a 1 robux extra per purchase reward for pricing things at 15, 25, 35, anything ending in a 5. It looks nice pricing things like that, but with the current tax system developers have to either take that 1 robux less per sale or find a different price.

Also I realize that selling something for 5, with round up would give 4 robux each time (instead of 3, since 5*.7 is 3.5) Then selling something for 10 gives 7 each time. Obviously selling for 5 has less tax. You sell 2 5 items, that’d be 8, 1 more than selling 1 item at 10.
To counter this I like Aurarus’ idea.

1 Like

That’s what I’ve done for the past about 4 years since they changed the market place fee to 30%. But there’s always room for discussion in a discussion forum. I’m learning the opposition as merely has some counter ideas for me to see who’s stance is the most logical.

With the new revenue graphs I don’t see that as a big problem in the future, but for the past I see your point. But I’m pretty sure developers would like it more if they got 1 extra robux per sale of a price ending in 5 (15*.7 = 10.5 should round up to 11) than if they didn’t. The benefits for developers out way the cost of not being able to accurately calculate revenue from January 2012.

EDIT:
Didn’t want to make 4 posts in a row so:

Here’s the extreme case of why this is a big deal.

Paid Access games have the lowest price set to 25, therefore a majority of paid access game creators set their price to 25 robux. 25*.7 = 17.5 which rounds down to 17 robux in Roblox. Whereas the real world would round that up to 18. The difference of 1 robux alone isn’t much, but for something like Welcome to Venezia with 133,453 sales, that’s 133,453 robux lost that SONIC didn’t get due to Roblox not rounding up. I’d be pretty upset at realizing the tax system has been cheating me off of that many robux if I found out about that.

1 Like

[quote]
Second, there’s already a special case for 1 robux. [/quote]
Nope. Everything is rounded down right now. There are no special cases.

local marketplaceFee = 0.70
local price = 1
print("Sold item for " .. tostring(price) .. ", received " .. tostring(math.floor(marketplaceFee * price)))

That makes sense to some extent, you want to sell items for odd multiples of 5 but you would get 1 more robux if you sold the item with a price higher by 1. I see your point here.

So basically you don’t want consistency, you just want to be able to sell at ‘neat’ numbers without losing that extra robux due to rounding down when there’s a 0.5 robux left over?

1 Like

What I mean by there’s already inconsistency with the current system and a special case for 1: 1 * .7 rounds down to 0 robux. It does not use math.floor because otherwise selling something for ie) 8 would give 5 instead of 6. By the way I think the special case for 1 is good here.

But anything selling over 10 really should round up if the result of price*.7 is equal to num.5 it already rounds up if price*.7 is > num.5

[quote]
That makes sense to some extent, you want to sell items for odd multiples of 5 but you would get 1 more robux if you sold the item with a price higher by 1. I see your point here.

So basically you don’t want consistency, you just want to be able to sell at ‘neat’ numbers without losing that extra robux due to rounding down when there’s a 0.5 robux left over? [/quote]

You win merely, I don’t know what you win, but I don’t think you are changing your mind and even if you do it’s pointless.

1 Like

I’d rather not have to worry about what I price my shit at.

I don’t care if it’s messy or inconsistent or whatever. Who cares. Hardly anyone would pay attention to it either. It’s like saying “Would you rather have 1% more income regardless of how comfortably you do whatever, in exchange for a small unnoticeable plastic bottle cap being littered on you backyard.”

1 Like

[quote]
It does not use math.floor because otherwise selling something for ie) 8 would give 5 instead of 6. By the way I think the special case for 1 is good here.

But anything selling over 10 really should round up if the result of price*.7 is equal to num.5 it already rounds up if price*.7 is > num.5 [/quote]
You’re right about it not rounding to the floor, and there must be a special case for 1 behind the scenes then. If all the logic for rounding is encapsulated in one assembly, it would be relatively easy to change. Still, not convinced that the change is warranted, since it’s only useful in the niche scenario when you’re selling an item for an odd multiple of five.

1 Like

Nope. I don’t see any reason to touch something that works. You as the developer can always adjust your price points for what you want to make on your end. We make it obvious to you on how much you are going to make. If it’s not obvious, we will fix that.

I am curious as to why you think Rounding down is not consistent? It always rounds down if there is a decimal place. It’s math.floor in Lua basically. Am I missing something?

2 Likes