DEV Community: FairStash

The median said every neon pays off. Splitting by price said the opposite.

FairStash — Sat, 03 Oct 2026 06:23:43 +0000

In Adopt Me, a Roblox game with a large trading economy, you can merge four copies of a pet into one neon version. Players ask the obvious question all the time: is it worth it? Is one neon worth more than the four pets it costs?

The community keeps a value list for every pet and every version, so this looks like a five-minute job: divide the neon value by four times the regular value, take the median, done.

I did that first. The answer was a confident yes, and it was wrong for exactly the pets where the question matters.

The aggregate

The values come from adoptmevalues.app, read on 3 October 2026. I took every pet with both a regular and a neon value and no potions (fly/ride change the price and would muddy the comparison). That left 783 pets.

const ratio = (p: Pet) => p.neon / (4 * p.regular)

median(pets.map(ratio)) // 1.34
pets.filter((p) => ratio(p) >= 1).length // 725 of 783

A median of ×1.34, and 93% of pets "gain" from going neon. Write that up and you have told a trader with a Frost Dragon to merge four of them.

The split

The trouble is who those 783 pets are. 566 of them, 72%, have a regular value below 1. Any statement about "the typical pet" is a statement about cheap pets.

Split the same ratio by the price of the regular version and the picture turns over:

regular value	pets	neon loses value	median neon ÷ 4 regulars
under 1	566	1	×1.53
1–5	103	1	×1.17
5–20	65	17	×1.03
20–100	32	24	×0.86
100 and up	17	15	×0.64

Among pets worth 100 or more, the neon is worth less than the four pets in 15 cases out of 17. Some examples:

pet	regular	4 × regular	neon	ratio
Frost Dragon	327	1,308	630	×0.48
Shadow Dragon	844	3,376	2,017.5	×0.60
Bat Dragon	961	3,844	2,375.75	×0.62
Giraffe	474	1,896	1,156	×0.61
Cryptid	187	748	476	×0.64

The only two exceptions at the top are Amethyst Penguin (×1.06) and Orchid Butterfly (×1.00, a dead heat).

So the honest answer is a gradient, not a yes: neon pays on cheap pets, breaks even somewhere around 5–20, and loses money on expensive ones. The overall median wasn't a summary of that gradient. It was the bottom band speaking for everyone.

Why this keeps happening

Nothing here is exotic. It's a mixture of very different groups summarised by one number, with one group outnumbering the others ten to one. What made it easy to miss:

The aggregate was true. 725 of 783 pets really do gain. The number wasn't a bug, so nothing flagged it.
The question has a hidden weight. Nobody agonises over whether to neon a pet worth 0.1. The decision matters in proportion to the value at stake, and the unweighted median gives the 0.1 pet the same vote as the Bat Dragon.
The headline answers a different question. "Does neon pay for the typical pet?" and "should I neon this pet?" sound alike and have opposite answers at the top of the list.

What I changed in practice: when a per-item ratio feeds a recommendation, I print it per band of the thing the reader is risking (here, the regular value), never just the overall figure. If one band holds most of the rows, that alone tells you the aggregate will speak for it.

One more trap in the same table

The next step up is mega neon: four neons merge into one mega. Among the 17 pets worth 100 or more, 5 have a mega worth exactly four neons, to the hundredth: Frost Dragon 630 → 2,520, Giraffe 1,156 → 4,624, Parrot 485.5 → 1,942. In the 20–100 band, none do.

Read naively, that is a market that priced the merge perfectly. It may also be a cell that was derived as "4 × neon" because nobody had a separate estimate. The data alone can't tell the two apart, and the list doesn't say. When the same exact multiple recurs across rows, ask how the cell was filled before reading it as an equilibrium, and don't let those rows vote in a median.

I run FairStash, which publishes Roblox trading values with their sources and history. The per-version values for every pet are on the Adopt Me pet list, and each pet's page shows its neon and mega neon next to the regular one, for example Frost Dragon, and the trade calculator prices neon and mega neon as separate items rather than as a multiple of the regular pet. Values are the community's, not ours: we say where each number comes from on the methodology page.

What 1,550 listings actually measure: turnover, not stock

FairStash — Wed, 09 Sep 2026 11:13:59 +0000

Every value list for a Roblox trading game answers the same question: what is this item worth? We wanted a different number — how many people are actually offering one right now — and the marketplace we read has an endpoint that looks like it gives exactly that.

It does not. Here is what it gives instead, and how we measured the difference.

The endpoint

Traderie hands out listings a page at a time:

/api/<game>/listings?limit=100&page=N

Two things are missing, and both matter:

There is no total count. No total, no count, no Link: rel="last". You page until it stops.
It stops early. Every game we tried caps out at the same place: 1,550 listings, 31 pages. Ask for page 32 and you get nothing. limit is honoured on the plain endpoint and silently ignored on the filtered one, which always returns 50.

So you get the 1,550 most recently updated listings. Not a sample — a window, sorted newest first.

The mistake we shipped

We counted how many of those 1,550 listings mentioned each item and published the result as "how many people are offering one". That reads as a stock measurement: this many exist for sale right now.

It is not. It is however many happened to be touched inside the window — and the window is a duration, not a quantity.

Measuring the window

Each listing carries updated_at. The oldest and newest in a completed run bracket exactly how much time those 1,550 listings covered. That is a free measurement: the data is already in the response.

let from = null, to = null
for (const listing of page) {
  const t = Date.parse(listing.updated_at)
  if (!from || t < from) from = t
  if (!to || t > to) to = t
}
// window in minutes
const minutes = Math.round((to - from) / 60000)

Run on 2026-09-09, three games on the same platform:

Game	Window covered by 1,550 listings
Flee the Facility	14.3 hours
Murder Mystery 2	69 minutes
Adopt Me	18 minutes

The same cap means wildly different things depending on how busy the game is. On the quiet game the window is most of a day. On the busy one it is a coffee break.

The check that settled it

If the count were stock, an item recorded as 0 would have nothing on offer. So we asked per item, using the filtered endpoint:

/api/<game>/listings?itemTags=true&item=<id>&selling=true&auction=false&page=N

Of thirty Adopt Me items sampled, twenty-eight had at least fifty active listings — including items our file had recorded as 0 that day. One item had at least 1,550 standing offers while appearing zero times in the newest 100.

Zero in the window is not an observation of absence. It is an absence of observation.

What the number actually is

It is turnover: how often an item moves through new listings. With the window duration measured alongside it, that becomes a rate — listings per hour — comparable between days and between games.

And turnover discriminates where stock does not. Two MM2 items both answer "300+ active listings" to the exact query; inside the window one appears 51 times and the other zero. The expensive exact count is the less informative number.

The cost of getting it exactly

We priced the honest alternative before rejecting it: one request per item per page, 50 per page, for a catalogue of thousands — up to 33,000 requests a day, and the answer would still be "300+" for most items. Not worth it, and not kind to someone else's servers.

Open data

The daily counts are published under CC BY 4.0, one row per item per day, with the window duration recorded beside each reading so the caveat can never outlive the data:

Live file and documentation: https://fairstash.app/data
A worked example for one game: https://fairstash.app/mm2/supply
Kaggle mirror: https://www.kaggle.com/datasets/fairstash/roblox-daily-trade-listing-counts-mm2-adopt-me

If you are reading a marketplace API that caps its result set, the lesson generalises: check what duration your cap covers before you name the number. A count with an unmeasured window is a sentence with an unknown subject.