I'm not doubting the provably fair system, I'm doubting its implementation.

I understand how hmac works. But what you don't understand is that "convert into a roll" isn't included in the provably fair bit.

You can take a game seed and server seed and nonce, and generate a completely random number. This is true, and provable.

But what's the output of the hmac-sha256 hash algorithm? It's a hexadecimal string of bytes. How do you turn this into a random number? By generating say a big int, or an int, or using the string into a pseudo-random generator, it doesn't matter really, because so far, the number is still random and reproductible in the future using the same server + client + nonce input.

But this is where you can't tell me there's any provably fair bit. How do you turn this random number, into a bet? You're not telling me that just-dice generates random numbers written as integers between 1 and 100. This is just not true. So you have to take the random number, and somehow convert it into a bet between a limited interval.

THIS conversion is what a lot of websites use to take a higher house edge than what they might advertise. This also needs to be double-checked in every bet verifier script, because you can easily modify the function that maps every random bigint value to a closed bet interval.