[REVIEW] Jackbit Casino – Refusing Bug Bounty for Documented Relay/History Fix

[thedemiurge]

I am a VIP user (Username: thedemiurge) on Jackbit. I am posting this to document a case of bad faith regarding a technical contribution I provided that restored critical site functionality.

The Technical Issue:
Two days ago, Jackbit’s user dashboard suffered a failure in its transaction history relay logic. While backend withdrawals were processing, the user-facing history was not updating or displaying. This caused significant confusion and a surge in support tickets from users who believed their funds were missing.

The Fix Provided:
As a developer, I identified the specific relay logic error and provided the fix to Jackbit's VIP support (Agent: Jesse). Jesse acknowledged the issue, confirmed it was a known technical escalation, and forwarded my fix to the technical department.

The Result:
Today, the site history is fully restored and functioning correctly due to the logic I provided. However, when I followed up on the promised bounty/reward, I was met with extreme stonewalling.

The Support Failure:
I spoke with an agent named Marceline, who repeatedly ignored the technical nature of the escalation. Despite being told this was a database relay fix, she repeatedly copy-pasted a script claiming "all game rounds ended according to rules." She refused to transfer me to a supervisor or Jesse, eventually closing the chat while claiming "no issues were found"—even though the site is actively using the fix I implemented.

Conclusion:
Jackbit is happy to accept professional-grade technical labor to stabilize their platform but refuses to honor the rewards for those contributions. I have moved my balance out of the site for safety and strongly advise other technical users or high-stakes players to be wary of their support's handling of non-standard issues.

I have the full chat logs and technical documentation of the fix available for any Jackbit representative or forum moderator who wishes to review them.


While I don't have a visual screenshot of the dashboard erroring out, I have the raw browser console logs from the session.

The Proof:
The logs show a consistent 404 error because the site was trying to fetch user data from a malformed URL:

Code:

GET https://jackbit.co/api//Notifications/v2/user-notifications 404 (Not Found)

Notice the double slash (api//Notifications). This is a clear syntax error in their relay logic that was preventing the dashboard from fetching history. Once I pointed this out to Jesse yesterday, the 'double slash' was corrected, and the site began functioning again.

For Marceline to claim 'no issues were found' while their own API was returning 404s due to a pathing error is a flat-out lie or total technical illiteracy."


For the skeptics or any Jackbit rep claiming 'no issues were found,' here is a screen capture of the dashboard during the relay failure. As you can see, the history and notifications are completely unresponsive.

This wasn't a 'local cache' issue; this was the result of the malformed API routing and CSP violations I identified and helped resolve. Site functionality was only restored after these technical escalations were addressed.

Since I'm a new user, the image might not render, but you can see the GIF proof at this link: https://ibb.co/twQ30ykb



Jackbit has now silently implemented the fixes I provided (resolving the CSP and malformed API routing) without acknowledging the bug or providing the bounty.

To the community: This is a textbook 'Silent Patch.' I provided the diagnostic logs (see my previous post) showing 404s and script blocks. Support initially claimed 'no issues were found,' yet miraculously, the site began functioning perfectly once my specific recommendations were followed.

They are trying to gaslight a VIP user to avoid paying for the technical labor that fixed their own dashboard. If they do this to a VIP, they will do it to anyone. I have the timestamps to prove my report preceded their fix

[Darker45]

It's unfortunate that Jackbit.com has been inactive here for a few months already. It's also noticeable that it's official thread here is also inactive. But you might still consider sending him a PM. He might get a notification somewhere else. That is, if you still want to fight for what you believe you deserve.

Your image doesn't show. Anyway, was your "fix" acknowledged as the reason why things got back to normal? Can you prove that your "specific recommendations were followed"? Isn't it a canned response from a support to anybody offering suggestions that he/she will forward them to the appropriate department?

Was there really a "promised bounty/reward" to you, or you're just referring to its overall terms and conditions about providing reward to those who discover bugs and help resolve them? I don't know how complex the bug and your offered solution were, but is it possible that what you consider "miraculous" was the result of their own technical team working to address the error?

[Jackbit.com]

Hello!

We’re sorry to hear about the inconvenience.

We’ve carefully reviewed the case, and as also mentioned in your post, the issue is no longer present. We would also like to clarify that no recent changes or deployments have been made to the transaction history page on our side in the past few days. This suggests the issue may have been temporary or related to a user-side inconsistency.

If you are still experiencing any issues, please contact us directly at support@jackbit.com, and our team will be happy to assist and investigate further.

Best regards,
Jackbit.com

[thedemiurge]

[EDIT: Updated with specific technical timestamps and evidence of silent patching.]

...we would like to clarify that the issue you encountered is no longer present... related to a your-side inconsistency.

@Jackbit.com, the claim that this was a "user-side inconsistency" is impossible to maintain given the paper trail. I have time-stamped records showing I attempted to resolve this privately for weeks before posting here.

The Timeline of your "Inconsistency":

April 16, 00:07 EDT: I emailed your Compliance team (ref: Agent Layla) with logs of the 404 error on your notifications API (/api//Notifications/v2/user-notifications). 404 is a server-side "Not Found" error; it cannot be caused by a user's browser settings.

April 16, 00:30 EDT: I sent a second formal complaint flagging specific CSP violations that were breaking the transaction dashboard.

April 16, 00:43 EDT: I notified your team that I would be escalating to the Curacao Gaming Authority if a technical review wasn't conducted.

The Result: I received only automated scripts in response. However, shortly after my public post here, the dashboard miraculously began working.

If no changes were made, why was the site returning 404s on April 16th and then 200 OKs today? Why did my private emails reporting these exact technical failures receive no technical explanation?

@Darker45, it’s clear they silently pushed a fix to the API routing once the threat of regulatory escalation became public. Using a PR script to call a server-side 404 a "user inconsistency" is a clear attempt to avoid acknowledging a legitimate bug report.

VIEW EVIDENCE: Comparison of Scripted Responses & Console Logs

[thedemiurge]

...can you prove that they followed your specific findings? Or did the issue resolve itself concurrently?

@Darker45, the "concurrency" argument falls apart when you look at the technical nature of the error.

The 404 Logic: As seen in my logs, the server returned a 404 Not Found for the endpoint https://jackbit.co/api//Notifications/v2/user-notifications. In web architecture, a 404 is an authoritative response from the server stating the resource does not exist. No amount of "clearing cookies" or "changing browsers" on the user's side can resolve a missing backend route. It requires a server-side configuration change or a code deploy.

Verification of the Fix: The dashboard was non-functional for days across multiple clean environments (Arch Linux/Chromium). It only became functional again immediately after my public posts and formal escalations. The "fix" was the restoration of that specific API route—something only their devs could do.

...is it possible that the issue was indeed on your side?

I ruled that out systematically before posting:

Cross-Environment Testing: I reproduced the 404s on both my primary Arch Linux workstation and mobile devices.

Network Isolation: The errors persisted across different ISPs, ruling out local DNS or routing issues.

Console Proof: The logs show CSP (Content Security Policy) violations. These are security headers sent by Jackbit's server that tell the browser what it is allowed to load. If their own headers are misconfigured and block their own data, that is a 100% server-side failure.

Can you tell us what that endpoint was? And what kind of error did you see?

@Darker45, the specific endpoint failing was:
https://jackbit.co/api//Notifications/v2/user-notifications

The console logged a consistent 404 (Not Found) error for this route. Additionally, I captured a DOMException (Origin Mismatch) where the server was failing to handshake between .co and .com domains. These are server-side failures that only a backend patch could resolve.

VIEW CONSOLE LOGS & 404 PROOF

@Darker45, thank you for looking into this. If you or any other high-ranked member can proxy these images into the thread, it would help hold them accountable for claiming a server-side 404 is a "user-side inconsistency."


Jackbit claims this was a 'user-side inconsistency,' but anyone can click the endpoint from my logs: https://jackbit.co/api//Notifications/v2/user-notifications. It returns a 404 Not Found.

A 404 is an authoritative response from the server, not a browser glitch. They aren't 'investigating' a bug; they are trying to hide a backend failure while publicly blaming the customer. The fact that the dashboard only started working after I exposed this proves they silently patched the route while continuing to feed us scripts.

[PX-Z]

This suggests the issue may have been temporary or related to a user-side inconsistency.

Technically, that's not how it works. "User-side inconsistency" doesn't really apply here, if there's an issue, it's happening on the system's side, not the user's. So that reasoning doesn't hold up.

As for OP, if there's no bug bounty or vulnerability program from Jackbit, then your findings likely won't carry much weight in terms of getting a reward. Without an official channel or incentive, most platforms won't compensate for reported issues unless they've explicitly stated otherwise.

As for Jackbit, denying the possibility of technical errors doesn't help either. Acknowledging and properly investigating reported issues would be a much better approach regardless if you have active bounty program or not.

[thedemiurge]

You’re actually hitting the nail on the head, PX-Z, and that’s the problem.

You’re right—there is no 'official' incentive for them to pay me now that they have the diagnostics. They can just take the fix, stay silent, and keep gaslighting me about my browser cache. But that’s exactly what exposes the 'Salient' business model these guys are running.

My point isn't that they have to pay me because of some rule; it’s that a supposedly top-tier platform shouldn't be relying on 'charity QA' from its users to keep its notification APIs from throwing 404s. If they want to be taken seriously on this forum, they shouldn't be comfortable with the 'cynic's' assumption that they'll just steal the labor and hide the patch.

I’m not looking for a handout; I’m calling out the fact that they’re using technical friction as a payout barrier, and then using my own logs to fix the barrier I just called them out on.

[Zwei]

My point isn't that they have to pay me because of some rule; it’s that a supposedly top-tier platform shouldn't be relying on 'charity QA' from its users to keep its notification APIs from throwing 404s. If they want to be taken seriously on this forum, they shouldn't be comfortable with the 'cynic's' assumption that they'll just steal the labor and hide the patch.

saying they stole your labor is not a fair way to put it.
they don't have a bug bounty program, so they never asked anyone to do "charity QA" for them, and since you did it on your own, you can't expect them to give you a bug bounty they never promised in the first place.

but i do think it's stingy that they didn't give you anything at all, a small bonus on the site or something like that would have been a nice thank you, instead of just denying it.

[un_rank]

Even if they had a bug bounty program, a 404 error is already something their technical team would have identified and started working on, not a hidden bug waiting to be discovered. Making a recommendation (if it was used) to help fix an issue faster will not qualify for most programs.

Seeing they do not have any such program there is no case of a reward here, except your recommendation really helped and they chose to appreciate the effort. I have gotten a mini freebet from a casino for pointing out something I noticed wrong with their software.

- Jay -

[thedemiurge]

I appreciate the perspective, but a few points need clarification:

To Jay: The idea that their team 'would have already identified' a 404 is demonstrably false in this case. If they had identified a server-side endpoint failure, their support wouldn't have spent days insisting the issue was a 'user-side inconsistency.' A 404 sitting in production while support gaslights the customer isn't a 'known issue' being worked on; it’s a failure of both their dev-ops and their customer service.

To the idea of 'Stolen Labor': While 'stolen' is a strong word, let's look at the mechanics. If a platform denies a bug exists, forces the user to spend hours providing professional-grade logs/diagnostics, and then uses those exact logs to push a silent patch while still refusing to acknowledge the error—that is, at best, exploitative.

Whether they have a formal 'program' or not is secondary to the fact that they used a customer as a free QA engineer because their own team couldn't find a basic routing error. A 'mini freebet' is the bare minimum for a 'thanks for noticing'; a complete denial of a documented server-side failure is just poor business.

The goal here isn't to beg for a bounty—it's to highlight that Jackbit's technical integrity is currently being propped up by the very users they're trying to blame for the site's malfunctions.

[Stheory]

Lol. At least you dont have stuck money on their platform. I found a bug because they kept saying everything is good on their end when something was clearly wrong. I believe this should be reviewed as a security/account-integrity risk, not only a support issue.

My email to them.

The issue may leave users exposed because the frontend and API do not appear to handle failed wallet/game-state responses safely. During my stuck bonus session, KA Gaming still showed an active unfinished bonus state, while the spin/continue response failed. At the same time, Jackbit wallet/bonus endpoints returned 400/502 errors and the frontend threw "TypeError: r.map is not a function".

This creates a risk where a user may not be able to verify whether a bonus, wager, wallet balance, or game round was settled correctly. The message “Your balance is intact” is not enough if the provider game state still shows an unfinished bonus and the frontend/API is failing.

I am not claiming account takeover or intentional manipulation. I am saying this may be an account integrity and transaction visibility issue that should be reviewed by technical/security staff.

[thedemiurge]

Exactly, Stheory.

Your experience with the KA Gaming bonus state and those 400/502 errors reinforces the exact point I’ve been making. When the frontend throws TypeError: r.map is not a function, it means the API is returning malformed or null data that the client-side code isn't equipped to handle safely.

This isn't a 'user-side inconsistency'; it's a fundamental breakdown in how Jackbit's API communicates with game providers.

To Jay and the others: Notice the pattern. Both Stheory and I found critical errors because we refused to accept the 'everything is fine on our end' script. If we hadn't dug into the console, these issues would stay 'invisible' while users potentially lose track of bonuses, wagers, or balances.

When multiple users are independently reporting server-side failures (404s, 502s, and unhandled JS type errors), it’s no longer a 'recommendation to fix an issue faster'—it’s an emergency audit being performed by the customers because the house isn't minding the shop.

If Jackbit wants to keep its reputation on this board, it needs to stop the silent patches and start providing transparent technical post-mortems and proper compensation for those of us doing their security and QA work.

Regarding PX-Z's point: He’s absolutely right.

Whether there is a bounty program or not, a platform that values its reputation shouldn't be comfortable with users having to perform their own server-side audits just to prove a site malfunction.

The fact that I’ve provided the specific route failures and Stheory has documented the r.map type errors and 502s should have triggered an immediate technical acknowledgement. Instead, we’re met with silence while they likely scramble to push silent patches.

Transparency isn't an 'extra' feature; it's the bare minimum for any site handling user funds.

[thedemiurge]

Still no response from Jackbit on the specific 404 and API failures documented here. It seems they’ve opted for the 'silent patch' and ghosting method rather than addressing the technical instability of their platform.