BC.GAME Security Breach: $76k SVIP6 Account, $5,640 Stolen via 2FA Bypass in 32s

[holydarkness]

[...]
@holydarkness asked about the exact 2FA configuration used on the account. For clarification: my account had TOTP-based 2FA enabled since the day it was created (April 2, 2024). BC.GAME support agent "Sep" explicitly confirmed this status on the very day of the incident, stating that a withdrawal without my physical device should have been impossible.
Proof:
[...]

Being blunt and to the point, your post addressed to me doesn't exactly answer my question.

BC informed us [and made a defense as a rebuttal] that the account got breached by 2FA through email. What I am asking you is to show us history of your gmail inbox and/or recent activities in google account, as google record everything and send you email [as well as one to the backup email address you set] if there is irregular activity.

[cgraph]

@holydarkness, thank you for the direct question and for clarifying BC.GAME's defense position.

You asked for my Gmail inbox history and Google account activity records to verify their claim that the account was "breached by 2FA through email."

Here is the complete evidence:

BC.GAME's Claim: "Account breached by 2FA through email"

This claim is directly contradicted by Google's security records, which I've already provided to @bctokenbot in our PM exchange (March 7) and am now making available publicly here.

Google Account Security Evidence:

1. Device Activity (Complete List):


Google account activity for January 17, 2026, shows only legitimate applications: MoonPay, WhatsApp, Telegram, Rakuten Viber, LinkedIn, Instagram, Gmail, Google Photos, Google Messages. No unauthorized access, no suspicious applications.

2. Authorized Devices (Your devices page):


Only two devices have accessed this Google account:
- Windows computer (Belgrade, Serbia) - Firefox, MoonPay
- Ulefone Armor X10 Pro (Belgrade, Serbia) - Android device

No unauthorized devices. No Montreal/Canada device. No irregular sessions.

3. Android Device Details (January 17, 8:05 PM):


Android device activity on January 17 at 8:05 PM - the exact time of the breach - shows activity from Belgrade, Serbia, using Google Chrome. First sign-in: February 18, 2025. Recent activity: Belgrade, Serbia, Jan 17.

Critical Points:

1. Zero unauthorized devices: Google's "Your devices" page shows only my two devices (Windows PC + Android phone), both in Belgrade, Serbia.

2. Zero irregular Gmail activity: No backup email alerts, no security warnings, no unauthorized access notifications from Google.

3. Montreal IP origin: The Montreal, Canada IP (37.120.205.115) appeared exclusively in BC.GAME's OTP verification emails sent to my Gmail inbox - not as a device accessing my email account. I received 4 unsolicited BC.GAME security codes between 19:46-19:51 CET (18:46-18:51 UTC) that I never requested or submitted.

4. Device location at breach time: At 8:05 PM on January 17 (the exact breach timestamp), Google security logs confirm my Android device was active in Belgrade, Serbia - NOT in Montreal, Canada, where BC.GAME's OTP verification emails indicated the unauthorized access attempt originated. This proves the breach did not occur through my physical devices.

Conclusion:

BC.GAME's claim that my account was "breached by 2FA through email" is factually incorrect. Google's security logs show:
- No unauthorized email access
- No device compromise
- No irregular activity
- All access from Belgrade, Serbia only

The Montreal IP appeared in BC.GAME's own OTP emails as the source requesting verification codes - suggesting the issue occurred at BC.GAME's system level, not through compromised user credentials.

This evidence was provided to @bctokenbot on March 7 for BC.GAME's internal investigation and is now publicly available for independent review.

Does this comprehensively address your request for Gmail and Google account security evidence?

Edit: Replaced PostImages links with TalkImg for better accessibility.

[holydarkness]

@holydarkness, thank you for the direct question and for clarifying BC.GAME's defense position.

You asked for my Gmail inbox history and Google account activity records to verify their claim that the account was "breached by 2FA through email."

[...]
1. Zero unauthorized devices: Google's "Your devices" page shows only my two devices (Windows PC + Android phone), both in Belgrade, Serbia.

2. Zero irregular Gmail activity: No backup email alerts, no security warnings, no unauthorized access notifications from Google.

3. Montreal IP origin: The Montreal, Canada IP (37.120.205.115) appeared exclusively in BC.GAME's OTP verification emails sent to my Gmail inbox - not as a device accessing my email account. I received 4 unsolicited BC.GAME security codes between 19:46-19:51 CET (18:46-18:51 UTC) that I never requested or submitted.

4. Device location at breach time: At 8:05 PM on January 17 (the exact breach timestamp), Google security logs confirm my Android device was active in Belgrade, Serbia - NOT in Montreal, Canada, where BC.GAME's OTP verification emails indicated the unauthorized access attempt originated. This proves the breach did not occur through my physical devices.

Conclusion:

[...]

Does this comprehensively address your request for Gmail and Google account security evidence?

I uhh... am actually a bit confused and not sure I grasp the narrative here, mostly because I can't access postimg-page-version of the first image you provided, and what I can see from the post is a very blurry text. If you don't mind to perhaps upload to talkimg?

So, that said, that I am a bit in the blind here, addressing point 3 and 4 of above-quoted highlight first... did your inbox have or have not the OTP that the hacker use to gain authorization to your account?

[cgraph]

@holydarkness, fair point on the image hosting. I have re-uploaded the relevant screenshots to TalkImg so they're directly viewable here:

Google Device Activity - Jan 17


Google Authorized Devices (Your devices)


Google Account / Device Sessions - Android Device, Belgrade, Jan 17 at 8:05 PM


Google Account / Device Sessions - Ulefone Armor X10 Pro - BC.GAME App Authorization (Serbia only)


(Note: this screenshot was in my possession throughout the investigation but was inadvertently omitted from earlier evidence posts. It is included here for completeness.)

To answer your direct question: Yes, my Gmail inbox did receive the OTP emails. Four unsolicited verification code emails arrived between 19:46-19:51 CET on January 17, all originating from a Montreal, Canada IP (37.120.205.115). I never requested them, and I never submitted any of those codes.

BC.GAME's own investigation confirmed that Email OTP verification was the method used to authorize the Passkey binding. What remains unexplained is how this was possible, given that Google's security logs show zero unauthorized access to my Gmail during that window.

The key distinction is this: those emails arrived in my inbox, but Google's security logs show that no unauthorized device accessed my Gmail account. The Montreal IP appears only as the source that triggered BC.GAME's OTP system to generate those emails - not as a source of access to my Gmail account. My Gmail itself was never accessed from Canada, from an unrecognized device, or from anywhere outside Belgrade.

The fourth screenshot adds further confirmation: Google shows that the BC.GAME application was authorized exclusively on my Ulefone Armor X10 Pro in Serbia. No Montreal or unrecognized device ever held BC.GAME authorization through Google.

An OTP-based breach requires both generation and access. Only the former is evidenced - the latter is entirely absent from all available records.

[bctokenbot]

After an initial review, it appears that your account may have been compromised due to entering your email/phone details on a phishing (fake) website. This could have allowed unauthorized access via passkey authentication, which was then used to perform the withdrawal.

We have already escalated this case with all available evidence and marked it for priority investigation. Given the seriousness of the situation, our security team may require your cooperation in providing additional information to help us complete the review and further strengthen our security measures.

Once the investigation is concluded, we will proceed with a goodwill resolution based on the findings.

We appreciate your patience and cooperation while we handle this matter.

[JollyGood]

@JollyGood, thank you for engaging with this case.

Regarding your questions:

Trust in the investigation:

I'm approaching this with realistic expectations rather than optimism.

I initially attempted resolution through BC.GAME's internal recovery process (January 19–27). Their recovery team requested proof of a "January 16 deposit" that doesn't exist in my transaction history. After I clarified this and identified suspicious outbound transfers, communication stopped.

After that lack of response, I created this public thread (January 24).

BC.GAME's forum representative (@bctokenbot) contacted me via PM on March 6 — 48 days after the incident. I've now provided the requested technical documentation (security logs, device activity, timeline evidence), so the matter is currently under review.

At this stage I am allowing their security team time to examine the materials and provide a technical explanation for the sequence of events.

Timeline expectations:

You're correct that significant time has passed (48 days since January 17).

Timeline summary:

• January 17: Incident occurred, reported immediately.
• January 19–27: Email recovery process (ended in silence).
• January 24: Public thread created after communication stalled.
• March 6: Forum representative engagement and evidence submission.

Beyond the primary theft (5,640.3878 USDT), the extended account lock also caused wager-earned bonuses to expire due to the platform's 30-day expiration rule.

I appreciate your thoughtful questions and hope the investigation will clarify what occurred and lead to a fair resolution.

First of all it cannot go unnoticed that the issue relates to 17th January 2026 and that the thread was created on 24th january 2026. It has been quite some time and BC Game have really not shown any urgency in trying to resolve the matter.

I find it extremely odd that BC Game would want to delay this further when they already have a catalog of allegations against them (both in the Scam Accusations board in the forum as well as outside in various websites and reviews).

After an initial review, it appears that your account may have been compromised due to entering your email/phone details on a phishing (fake) website. This could have allowed unauthorized access via passkey authentication, which was then used to perform the withdrawal.

We have already escalated this case with all available evidence and marked it for priority investigation. Given the seriousness of the situation, our security team may require your cooperation in providing additional information to help us complete the review and further strengthen our security measures.

Once the investigation is concluded, we will proceed with a goodwill resolution based on the findings.

We appreciate your patience and cooperation while we handle this matter.

In order to add insult to injury, BC Game are now claiming the OP was a victim of a phishing website. Though obviously not impossible, it is almost improbable as he used the BC game website on many occasions in the past. What would have promoted him to use a fake website on that particular occasion?

I hope the OP responds to your allegation as soon as he reads your post.

[cgraph]

@JollyGood, thank you for returning to this thread and for your candid assessment.

You raise the definitive question: why would an experienced user suddenly fall for a fake domain after years of direct usage? To date, nothing in my device logs, browser history, or Google security records supports such a scenario. The shift in BC.GAME's narrative after 77 days is, as you noted, extremely odd. This pattern of changing explanations - moving from "impossible" to "email breach" and now to "phishing" - appears more consistent with liability management than with a structured technical investigation.


@bctokenbot, thank you for the update and for escalating this case for priority investigation.

I appreciate the mention of a potential goodwill resolution - I would ask for clarification on what "goodwill resolution" entails in concrete terms, specifically whether it includes restitution of the 5,640.3878 USDT and full account restoration.

I am fully prepared to cooperate and provide any additional information your security team requires.

I also want to note for the record that this represents a third distinct explanation for the incident: BC.GAME support initially stated the withdrawal was impossible with active 2FA; your March 6 communication identified Email OTP as the authorization method; today's response introduces a phishing website as the likely vector. I raise this to ensure the record remains accurate as the investigation progresses.

Regarding the phishing theory - beyond the fact that my Google security logs show zero anomalous access or unrecognized sessions during the incident window, there is a fundamental technical issue with this premise. Passkeys (WebAuthn/FIDO2) are inherently resistant to phishing by design. A passkey is cryptographically bound to the specific origin domain where it was created. Even if a user were tricked into visiting a fake website, the browser/device would not create or authenticate the passkey because the domains would not match - the WebAuthn protocol ensures a passkey is never shared with an incorrect origin. Therefore, under standard WebAuthn behavior, a phishing site should not be able to capture or bind a valid passkey to the legitimate domain.

This makes the phishing-based passkey binding scenario difficult to reconcile with standard WebAuthn behavior.

If your investigation has identified a specific phishing domain involved in this incident, I would appreciate confirmation of that domain, as well as how a passkey could have been successfully bound through it given origin-binding constraints.

I would also note that, in my private response to your March 6 inquiry, I provided all five requested items within the same day and raised one critical outstanding question of my own: from which IP address was the withdrawal executed on BC.GAME's backend? This information is exclusively available from your internal logs and would immediately clarify whether the transaction originated from Montreal or any other location, or from my Serbian session. That question remains unanswered to date, despite being central to determining the origin of the transaction.

To reconcile this explanation with both the technical standards of passkeys and my own clean security logs, I would appreciate clarification on the following from your internal records:

1. The exact timestamp when the passkey was created or bound to the account.
2. The IP address and device fingerprint associated with that action.
3. The authentication method used to approve the passkey binding.
4. Whether this action originated from a new or previously unrecognized device.

Given that passkey binding is a security-sensitive action on an SVIP6 account, I assume these events are logged in detail on your side. This information would allow me to reconcile your findings with the absence of any corresponding activity in my records.

I look forward to your team's detailed findings.

[holydarkness]

[...]
@bctokenbot, thank you for the update and for escalating this case for priority investigation.

I appreciate the mention of a potential goodwill resolution - I would ask for clarification on what "goodwill resolution" entails in concrete terms, specifically whether it includes restitution of the 5,640.3878 USDT and full account restoration.

I am fully prepared to cooperate and provide any additional information your security team requires.

I also want to note for the record that this represents a third distinct explanation for the incident: BC.GAME support initially stated the withdrawal was impossible with active 2FA; your March 6 communication identified Email OTP as the authorization method; today's response introduces a phishing website as the likely vector. I raise this to ensure the record remains accurate as the investigation progresses.

Regarding the phishing theory - beyond the fact that my Google security logs show zero anomalous access or unrecognized sessions during the incident window, there is a fundamental technical issue with this premise. Passkeys (WebAuthn/FIDO2) are inherently resistant to phishing by design. A passkey is cryptographically bound to the specific origin domain where it was created. Even if a user were tricked into visiting a fake website, the browser/device would not create or authenticate the passkey because the domains would not match - the WebAuthn protocol ensures a passkey is never shared with an incorrect origin. Therefore, under standard WebAuthn behavior, a phishing site should not be able to capture or bind a valid passkey to the legitimate domain.

This makes the phishing-based passkey binding scenario difficult to reconcile with standard WebAuthn behavior.

If your investigation has identified a specific phishing domain involved in this incident, I would appreciate confirmation of that domain, as well as how a passkey could have been successfully bound through it given origin-binding constraints.

I would also note that, in my private response to your March 6 inquiry, I provided all five requested items within the same day and raised one critical outstanding question of my own: from which IP address was the withdrawal executed on BC.GAME's backend? This information is exclusively available from your internal logs and would immediately clarify whether the transaction originated from Montreal or any other location, or from my Serbian session. That question remains unanswered to date, despite being central to determining the origin of the transaction.

To reconcile this explanation with both the technical standards of passkeys and my own clean security logs, I would appreciate clarification on the following from your internal records:

1. The exact timestamp when the passkey was created or bound to the account.
2. The IP address and device fingerprint associated with that action.
3. The authentication method used to approve the passkey binding.
4. Whether this action originated from a new or previously unrecognized device.

Given that passkey binding is a security-sensitive action on an SVIP6 account, I assume these events are logged in detail on your side. This information would allow me to reconcile your findings with the absence of any corresponding activity in my records.

I look forward to your team's detailed findings.

If I may jump in, not to defend BC, rather to share my knowledge on handling and being the eyes of the forum in the past for BC-related cases, IIRC, my contact on security explained to me that BC has many option of 2FA: SMS OTP, Google Authenticator, Email Passcode, and one other thing that I can't recall.

These 2FA works simultaneously, with one supercedes the other [IIRC, it was GA], in sense that someone with GA has full authority and can bypass other 2FA, it only needs itself to verify transaction. But if someone has access to both your email and phone number, thus can access two FA point [email verification and SMS OTP], they can work in tandem to grant access, even when they don't have access to your GA.

Just saying this because I still can't see images you tried to show us, they're still pixelated, from my side.

[cgraph]

@holydarkness, thank you for jumping in. That's a very important clarification regarding how their internal 2FA hierarchy allegedly works.

However, that specific "tandem" bypass (Email + SMS) is technically impossible in my case for one simple reason: SMS 2FA was never enabled or configured on my account.

My only active 2FA was TOTP-based (Google Authenticator/Authy). If their system allowed a bypass using only Email + a non-existent SMS layer, that would raise serious questions about their authorization logic and be directly relevant to the outstanding technical questions already submitted. This is exactly why I am pushing for the specific "authorization method" logs - if they claim an SMS was used, they would effectively be claiming that a non-existent 2FA method was used.

Regarding the images: I have moved them to TalkImg as requested. The thumbnails in the post are for bandwidth; please click them to open the full-resolution screenshot in a new tab. Let me know if they are still giving you trouble.

[holydarkness]

@holydarkness, thank you for jumping in. That's a very important clarification regarding how their internal 2FA hierarchy allegedly works.

However, that specific "tandem" bypass (Email + SMS) is technically impossible in my case for one simple reason: SMS 2FA was never enabled or configured on my account.

My only active 2FA was TOTP-based (Google Authenticator/Authy). If their system allowed a bypass using only Email + a non-existent SMS layer, that would raise serious questions about their authorization logic and be directly relevant to the outstanding technical questions already submitted. This is exactly why I am pushing for the specific "authorization method" logs - if they claim an SMS was used, they would effectively be claiming that a non-existent 2FA method was used.

Regarding the images: I have moved them to TalkImg as requested. The thumbnails in the post are for bandwidth; please click them to open the full-resolution screenshot in a new tab. Let me know if they are still giving you trouble.

Ahh yes, sorry, should have tried to click them and see if it's a full-linked-mode of talkimg in the first place, my apology for that, having a lot in my mind currently.

I've seen all, and I guess now the ball is in BC's park, bctokenbot, if you can help confirm or deny that OP's account is breached by a hacker setting SMS OTP to the hacker's phone number and use it in tandem with email verification to supercede GA, that should be your utmost interest right now, dare I say.

About who shall you show it to, to prove your point, it is no longer my concern, ask your new spearhead to find a way to prove it. Sadly but truthfully, you lost your privilege of me being the sworn eyewitness for-my-eyes-only for your casino when he ascended in absence of the more senior contact during his medical leave and tried to pull big-man pants by severing ties with me. Now the burden to find a private verificator is completely on his hand.

So, if you have that evidence as rebuttal, find a way to prove it without violating OP's data protection. Otherwise, if OP deemed your rebuttal insufficient and he decided a flag is warranted, I have to lean on supporting it due to the abundant evidence he showed that there is no breach and/or unauthorized activities from his side.

[bctokenbot]

@JollyGood, thank you for returning to this thread and for your candid assessment.

You raise the definitive question: why would an experienced user suddenly fall for a fake domain after years of direct usage? To date, nothing in my device logs, browser history, or Google security records supports such a scenario. The shift in BC.GAME's narrative after 77 days is, as you noted, extremely odd. This pattern of changing explanations - moving from "impossible" to "email breach" and now to "phishing" - appears more consistent with liability management than with a structured technical investigation.


@bctokenbot, thank you for the update and for escalating this case for priority investigation.

I appreciate the mention of a potential goodwill resolution - I would ask for clarification on what "goodwill resolution" entails in concrete terms, specifically whether it includes restitution of the 5,640.3878 USDT and full account restoration.

I am fully prepared to cooperate and provide any additional information your security team requires.

I also want to note for the record that this represents a third distinct explanation for the incident: BC.GAME support initially stated the withdrawal was impossible with active 2FA; your March 6 communication identified Email OTP as the authorization method; today's response introduces a phishing website as the likely vector. I raise this to ensure the record remains accurate as the investigation progresses.

Regarding the phishing theory - beyond the fact that my Google security logs show zero anomalous access or unrecognized sessions during the incident window, there is a fundamental technical issue with this premise. Passkeys (WebAuthn/FIDO2) are inherently resistant to phishing by design. A passkey is cryptographically bound to the specific origin domain where it was created. Even if a user were tricked into visiting a fake website, the browser/device would not create or authenticate the passkey because the domains would not match - the WebAuthn protocol ensures a passkey is never shared with an incorrect origin. Therefore, under standard WebAuthn behavior, a phishing site should not be able to capture or bind a valid passkey to the legitimate domain.

This makes the phishing-based passkey binding scenario difficult to reconcile with standard WebAuthn behavior.

If your investigation has identified a specific phishing domain involved in this incident, I would appreciate confirmation of that domain, as well as how a passkey could have been successfully bound through it given origin-binding constraints.

I would also note that, in my private response to your March 6 inquiry, I provided all five requested items within the same day and raised one critical outstanding question of my own: from which IP address was the withdrawal executed on BC.GAME's backend? This information is exclusively available from your internal logs and would immediately clarify whether the transaction originated from Montreal or any other location, or from my Serbian session. That question remains unanswered to date, despite being central to determining the origin of the transaction.

To reconcile this explanation with both the technical standards of passkeys and my own clean security logs, I would appreciate clarification on the following from your internal records:

1. The exact timestamp when the passkey was created or bound to the account.
2. The IP address and device fingerprint associated with that action.
3. The authentication method used to approve the passkey binding.
4. Whether this action originated from a new or previously unrecognized device.

Given that passkey binding is a security-sensitive action on an SVIP6 account, I assume these events are logged in detail on your side. This information would allow me to reconcile your findings with the absence of any corresponding activity in my records.

I look forward to your team's detailed findings.

Following an internal review, we will proceed with a goodwill compensation of 5,640 USDT to cover your loss, and your account access will also be restored.

Regarding the issue you raised, it has already been escalated to our technical team for a detailed investigation. Please rest assured that we are taking this matter seriously and will do our best to address your concerns.

As the technical review process can be complex and time-consuming, we kindly ask for your patience. In the meantime, we strongly advise all users to stay cautious of unfamiliar websites and always verify authenticity through **bcgame.com**.

Thank you for your understanding and continued support.

[bctokenbot]

@JollyGood, thank you for returning to this thread and for your candid assessment.

You raise the definitive question: why would an experienced user suddenly fall for a fake domain after years of direct usage? To date, nothing in my device logs, browser history, or Google security records supports such a scenario. The shift in BC.GAME's narrative after 77 days is, as you noted, extremely odd. This pattern of changing explanations - moving from "impossible" to "email breach" and now to "phishing" - appears more consistent with liability management than with a structured technical investigation.


@bctokenbot, thank you for the update and for escalating this case for priority investigation.

I appreciate the mention of a potential goodwill resolution - I would ask for clarification on what "goodwill resolution" entails in concrete terms, specifically whether it includes restitution of the 5,640.3878 USDT and full account restoration.

I am fully prepared to cooperate and provide any additional information your security team requires.

I also want to note for the record that this represents a third distinct explanation for the incident: BC.GAME support initially stated the withdrawal was impossible with active 2FA; your March 6 communication identified Email OTP as the authorization method; today's response introduces a phishing website as the likely vector. I raise this to ensure the record remains accurate as the investigation progresses.

Regarding the phishing theory - beyond the fact that my Google security logs show zero anomalous access or unrecognized sessions during the incident window, there is a fundamental technical issue with this premise. Passkeys (WebAuthn/FIDO2) are inherently resistant to phishing by design. A passkey is cryptographically bound to the specific origin domain where it was created. Even if a user were tricked into visiting a fake website, the browser/device would not create or authenticate the passkey because the domains would not match - the WebAuthn protocol ensures a passkey is never shared with an incorrect origin. Therefore, under standard WebAuthn behavior, a phishing site should not be able to capture or bind a valid passkey to the legitimate domain.

This makes the phishing-based passkey binding scenario difficult to reconcile with standard WebAuthn behavior.

If your investigation has identified a specific phishing domain involved in this incident, I would appreciate confirmation of that domain, as well as how a passkey could have been successfully bound through it given origin-binding constraints.

I would also note that, in my private response to your March 6 inquiry, I provided all five requested items within the same day and raised one critical outstanding question of my own: from which IP address was the withdrawal executed on BC.GAME's backend? This information is exclusively available from your internal logs and would immediately clarify whether the transaction originated from Montreal or any other location, or from my Serbian session. That question remains unanswered to date, despite being central to determining the origin of the transaction.

To reconcile this explanation with both the technical standards of passkeys and my own clean security logs, I would appreciate clarification on the following from your internal records:

1. The exact timestamp when the passkey was created or bound to the account.
2. The IP address and device fingerprint associated with that action.
3. The authentication method used to approve the passkey binding.
4. Whether this action originated from a new or previously unrecognized device.

Given that passkey binding is a security-sensitive action on an SVIP6 account, I assume these events are logged in detail on your side. This information would allow me to reconcile your findings with the absence of any corresponding activity in my records.

I look forward to your team's detailed findings.

After reviewing the case, we would like to clarify the sequence of events based on our records:

The account was accessed via email OTP login
A passkey was then successfully bound using mobile OTP verification
The withdrawal was completed using the authorized passkey

From a security perspective, these actions indicate that access to your email (and related verification methods) was obtained by a third party. We strongly recommend ensuring the safety of your email account and enabling all possible security protections.

While we fully understand your concerns, please note that the security of your email and external accounts is outside of BC.Game’s control, and therefore we are unable to take responsibility for the unauthorized access itself.

That said, you are a valued member of the BC.Game community, and we want to support you through this situation. As a gesture of goodwill, we are willing to apply for a full goodwill compensation for your loss.

To proceed, please contact our recovery team using your registered email address: recovery@bcgame.com; and also cc martin@bcgame.com in the email so I can expedite the process for you. Because this case involves account theft, we need to verify your identity to confirm account ownership before taking any further action.
Lastly, we kindly remind all users to avoid phishing websites and always verify the official domain via bcgame.com before logging in.

We’re here to support you.

[JollyGood]

This is a welcomed surprise. Regardless of how it has been framed, there are many positives that can be taken from the reply given by bctokenbot.

We can see that the OP is claiming one thing occurred and BC Game is claiming something else occurred. If a similar situation were reported in other scam allegations then maybe BC Game would look more closely at their security protocols. Until or unless that happens, at the end of the day if the OP is being offered the full amount he is claiming then he should accept it and close the matter. 

While we fully understand your concerns, please note that the security of your email and external accounts is outside of BC.Game’s control, and therefore we are unable to take responsibility for the unauthorized access itself.

That said, you are a valued member of the BC.Game community, and we want to support you through this situation. As a gesture of goodwill, we are willing to apply for a full goodwill compensation for your loss.

To proceed, please contact our recovery team using your registered email address: recovery@bcgame.com; and also cc martin@bcgame.com in the email so I can expedite the process for you. Because this case involves account theft, we need to verify your identity to confirm account ownership before taking any further action.
Lastly, we kindly remind all users to avoid phishing websites and always verify the official domain via bcgame.com before logging in.

We’re here to support you.

[cgraph]

@bctokenbot, thank you for the official response.

While we do not agree on the technical explanation of this breach, I acknowledge and appreciate BC.GAME’s decision to resolve this matter through full restitution of 5,640.3878 USDT and account restoration. I formally accept the proposed compensation.

I have contacted the recovery team (cc’ing Martin) to proceed with identity verification and finalize the process.

To the community: Thank you to everyone who took the time to review the case, ask questions, and contribute technical insights. Your input helped ensure that the key issues remained visible and properly examined throughout this process.

A special thanks to @holydarkness, @JollyGood, and @AHOYBRAUSE for their engagement and technical perspective.

I will keep this thread updated and mark the status as "Pending Restitution." Once the funds are received and account access is fully restored, I will close the thread as Resolved.

[bctokenbot]

Thank you for your patience and cooperation throughout this process.
Your generous compensation has been issued as a redemption code, which you can redeem directly on the platform. Please use this redemption code to claim your reward.

At the same time, we would like to remind you to be wary of phishing websites and always ensure that you are visiting the official platform. Protecting your email, password, and access key is crucial for maintaining your account security.

If you need any assistance or have any other questions while redeeming the redemption code, please feel free to contact me.

[cgraph]

Thank you for your patience and cooperation throughout this process.
Your generous compensation has been issued as a redemption code, which you can redeem directly on the platform. Please use this redemption code to claim your reward.

At the same time, we would like to remind you to be wary of phishing websites and always ensure that you are visiting the official platform. Protecting your email, password, and access key is crucial for maintaining your account security.

If you need any assistance or have any other questions while redeeming the redemption code, please feel free to contact me.

Let me clarify for the community what BC.GAME considers "generous compensation" for a verified platform security breach where $5,640.38 USDT was stolen.

Instead of a direct restitution of the stolen raw funds to my balance, BC.GAME issued a promotional bonus code locked behind a mandatory 1x wagering requirement.

I did not request a promotional casino bonus. I requested the return of the exact funds that were stolen while under your platform's custody, verified mathematically by my cryptographic signature. Forcing a victim of a security breach to wager their compromised money in the casino just to unlock it for a withdrawal is not a "goodwill resolution" — it is a predatory trap.

Stolen raw balance must be replaced with raw balance. Restitution of stolen funds cannot be subject to casino wagering conditions.

Until my raw balance is credited with the stolen $5,640.38 USDT without strings attached, this thread remains open, and this case will continue to be documented publicly until it is resolved correctly.

[rollinsweet]

Thank you for your patience and cooperation throughout this process.
Your generous compensation has been issued as a redemption code, which you can redeem directly on the platform. Please use this redemption code to claim your reward.

At the same time, we would like to remind you to be wary of phishing websites and always ensure that you are visiting the official platform. Protecting your email, password, and access key is crucial for maintaining your account security.

If you need any assistance or have any other questions while redeeming the redemption code, please feel free to contact me.

Let me clarify for the community what BC.GAME considers "generous compensation" for a verified platform security breach where $5,640.38 USDT was stolen.

Instead of a direct restitution of the stolen raw funds to my balance, BC.GAME issued a promotional bonus code locked behind a mandatory 1x wagering requirement.

I did not request a promotional casino bonus. I requested the return of the exact funds that were stolen while under your platform's custody, verified mathematically by my cryptographic signature. Forcing a victim of a security breach to wager their compromised money in the casino just to unlock it for a withdrawal is not a "goodwill resolution" — it is a predatory trap.

Stolen raw balance must be replaced with raw balance. Restitution of stolen funds cannot be subject to casino wagering conditions.

Until my raw balance is credited with the stolen $5,640.38 USDT without strings attached, this thread remains open, and this case will continue to be documented publicly until it is resolved correctly.

Yes, it's pretty stupid that they threw you a 1x wager requirement.
Then it's not a compensation, but some kind of bonus for being hacked lol

[AHOYBRAUSE]

Thank you for your patience and cooperation throughout this process.
Your generous compensation has been issued as a redemption code, which you can redeem directly on the platform. Please use this redemption code to claim your reward.

At the same time, we would like to remind you to be wary of phishing websites and always ensure that you are visiting the official platform. Protecting your email, password, and access key is crucial for maintaining your account security.

If you need any assistance or have any other questions while redeeming the redemption code, please feel free to contact me.

Let me clarify for the community what BC.GAME considers "generous compensation" for a verified platform security breach where $5,640.38 USDT was stolen.

Instead of a direct restitution of the stolen raw funds to my balance, BC.GAME issued a promotional bonus code locked behind a mandatory 1x wagering requirement.

I did not request a promotional casino bonus. I requested the return of the exact funds that were stolen while under your platform's custody, verified mathematically by my cryptographic signature. Forcing a victim of a security breach to wager their compromised money in the casino just to unlock it for a withdrawal is not a "goodwill resolution" — it is a predatory trap.

Stolen raw balance must be replaced with raw balance. Restitution of stolen funds cannot be subject to casino wagering conditions.

Until my raw balance is credited with the stolen $5,640.38 USDT without strings attached, this thread remains open, and this case will continue to be documented publicly until it is resolved correctly.

Come one man. At some point you should be happy you got something in the end. I mean clearly mistakes on both sides must have been made, otherwise nobody could enter your account. A 1x rollover is not that big of a deal, you can make this in no time with almost no risk, maybe lose like 2% or so to house edge.

I understand you are not happy about this but really, you can consider yourself lucky you basically got your money back. Other sites could have given nothing.

Don't be too greedy, they could still reverse their decision. 100% of the full funds with a 1x wager is better than 100% of nothing.

[cgraph]

@AHOYBRAUSE, the 1x wager requirement would be "not a big deal" if the funds had survived it. They didn't. The full amount was lost during forced wagering - meaning I effectively lost my money twice. That is not getting something back. That is the casino winning twice on the same stolen funds.

Additionally, BC.GAME has now shifted their position, claiming the breach originated from a compromised email account rather than a platform failure: a claim directly contradicted by the full Google account activity logs I submitted earlier in this thread, showing zero unrecognized access at any point surrounding the incident.

Yes, it's pretty stupid that they threw you a 1x wager requirement. Then it's not compensation, but some kind of bonus for being hacked lol

Exactly, and to add to your point: the funds did not survive the wagering requirement. The full $5,640.38 USDT was lost during forced wagering, and BC.GAME is now claiming the breach was caused by a compromised email account. This directly contradicts the Google account logs already submitted as evidence in this thread. The case is ongoing and unresolved.

[AHOYBRAUSE]

@AHOYBRAUSE, the 1x wager requirement would be "not a big deal" if the funds had survived it. They didn't. The full amount was lost during forced wagering - meaning I effectively lost my money twice. That is not getting something back. That is the casino winning twice on the same stolen funds.

Additionally, BC.GAME has now shifted their position, claiming the breach originated from a compromised email account rather than a platform failure: a claim directly contradicted by the full Google account activity logs I submitted earlier in this thread, showing zero unrecognized access at any point surrounding the incident.

Yes, it's pretty stupid that they threw you a 1x wager requirement. Then it's not compensation, but some kind of bonus for being hacked lol

Exactly, and to add to your point: the funds did not survive the wagering requirement. The full $5,640.38 USDT was lost during forced wagering, and BC.GAME is now claiming the breach was caused by a compromised email account. This directly contradicts the Google account logs already submitted as evidence in this thread. The case is ongoing and unresolved.

Haha, so now you want another refund? Hilarious. Now I understand your snappy reply instead of being happy you could walk away with almost no damage.
You know what the problem is, you GAMBLED the funds trying to make a profit. The safe route would have been to WAGER the funds only losing to house edge and walk away with around 5400$. Greed got the better of you and then you lost, plain and simple.

Can't even feel sorry for you because this was straight up stupid what you did.