The bet API takes the selection, the stake, and the odds. In the window we tested, the server stored the odds value from the client. It did not replace it with the live market price.
Bets at about 10x, 36x, and 58x the quoted market price were accepted into the bet engine. Bet history showed the inflated odds and a potential payout computed from that number. A one-unit stake at the highest test price was stored with a three-digit potential win. The fair payout on that selection was under two units.
The bet status was rejected. The reason was the sandbox wallet: the balance could not subtract the stake, and that check ran after the bet had been created and priced. We did not fund a wallet. We did not settle a bet.
What we proved
Server-side bet records, on an account we own, containing the client-supplied odds and a potential win derived from them. The market price on the same selection was the control.
What this is not
Not a withdrawal and not a cashed winning ticket. Empty sandbox balance stopped settlement. The engine had already trusted the client for the price.
Why a scanner misses it
The HTTP status of a rejected bet looks like a working control. The evidence is the stored odds and the stored potential win, read back from bet history, compared with the market.
Buyer takeaway: Odds are a server price. If bet history shows the client's number, the balance check is the only thing between a test account and a priced winning bet.
