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:

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

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

@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.


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.


@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.

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.

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 -

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.

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.