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

[cgraph]

LATEST CASE STATUS (Updated: April 7, 2026)
Current Status: Pending Restitution - Official Offer Accepted
Days Elapsed: 80 DAYS SINCE INCIDENT (January 17, 2026)
Last Action: Formal restitution of 5,640.3878 USDT and account restoration confirmed by BC.GAME on April 7. Offer formally accepted; identity verification (KYC) in progress via email.
Case Outcome: Following 80 days of technical scrutiny and community intervention, BC.GAME has agreed to restore the full disputed amount and return account access.
Awaiting Completion: Final identity verification by the BC.GAME Recovery Team and fund transfer.

TL;DR
SVIP6 account (tempara, BC UID 33509850) with $76,000+ in historical deposits was compromised on January 17, 2026. An unauthorized withdrawal of $5,640.3878 USDT occurred despite active 2FA while the device remained in the account owner's possession. BC.GAME support stated this was “impossible”; however, the withdrawal was completed within a 32-second window and coincided with unsolicited BC.GAME security emails indicating access attempts associated with an IP geolocated to Montreal, Canada. The account has been locked, and all recovery requests have been ignored for over 72 hours.

---

LIVE EVIDENCE: I was actively logged in and captured the system notifications in real-time as the funds were drained. My authenticated session was abused without user authorization, and without any 2FA challenge being presented to my device.

---

ACCOUNT VERIFICATION
• Username: tempara (SVIP6 - restoration in progress)
• BC.GAME UID: 33509850
• Account status: Verification (KYC) update in progress
• Total deposits: $76,000+
• Amount under restitution: $5,640.3878 USDT
• Incident date: January 17, 2026
• Current Status: PENDING RESTITUTION (Full amount & account restoration confirmed April 7)

---

WHAT THIS REPORT IS ABOUT
This is not a dispute about gameplay or losses. This is a documented system-side security breach followed by silence from the operator.

---

THE "IMPOSSIBLE" CAUGHT IN REAL-TIME

I was actively using the account when the breach occurred and managed to capture the exact moment of the theft via Firefox.



Note the synchronous status: The system shows both "Withdrawal in progress" and "Successfully withdrawn" for 5,640.3878 USDT simultaneously. No 2FA prompt appeared on my screen during this hijack. This is a crop from the full dashboard capture (Image #09 in the gallery).

---

BC.GAME'S OWN SECURITY CLAIMS (DIRECT QUOTES)

During live chat, Support Agent "Sep" stated the following regarding this account:

"I actually checked your security details and it is indeed that your 2FA is enabled, which means it's impossible for anyone to withdraw on your account without having physically the device of the account owner."

"I understand, but since 2FA is enabled, the only way you can withdraw on the account is through having your physical device, the funds cannot be withdrawn online in any other way without the device itself."

"Regardless of the IP used, if the supposed hacker doesn't have the physical device itself, he cannot have access with your 2FA verification. So it's really impossible for them to do this remotely."

This is BC.GAME's own support making the same claim three times: Active 2FA requires a physical device. Withdrawal without the device is impossible.

Yet the withdrawal occurred anyway.

---

WHAT ACTUALLY HAPPENED

Despite the above assurances, an unauthorized withdrawal occurred remotely with the following conditions:
• 2FA was active
• The device remained in the account owner's possession
• 4 unsolicited security emails with verification codes were received during the incident window
• Activity correlated with unsolicited BC.GAME security emails indicating access attempts associated with an IP geolocated to Montreal, Canada (AS9009, M247 Ltd). These requests were not initiated by me.

---

INCIDENT TIMELINE (CET / UTC+1)

20:05:19 – Internal fund movement initiated
20:05:31 – Asset conversion completed
20:05:51 – Final withdrawal executed (TRON network)

All actions completed within 32 seconds.

This was:
• First-ever TRON withdrawal on this account
• 23× larger than any prior withdrawal
• Completely outside the established account behavior pattern

---

TECHNICAL NOTE ON 2FA BYPASS: On BC.GAME, a 2FA prompt is mandatory for all withdrawals. However, as I was active in the session during the breach, no 2FA prompt ever appeared on my screen. The system processed and authorized the withdrawal without requesting a code from my physical device, effectively bypassing the mandatory security layer.

---

THE LOGICAL PROBLEM

By BC.GAME's own definition: This incident was impossible.

Yet it occurred.

That leaves only one conclusion: BC.GAME's session management and/or authorization controls failed, allowing a withdrawal without user authorization despite active 2FA.

This is not an opinion. This is a technical conclusion supported by BC.GAME’s own security statements and system behavior.

---

FORENSIC EVIDENCE ALBUM

Click here to view 9 forensic screenshots
(01 Live Breach Detail • 02 SVIP6 Profile Details • 03 Historical Deposit • 04 Recent Deposit • 05 Master Theft Timeline • 06 2FA Security Emails • 07 Support Chat Admission • 08 KYC Verification • 09 Full Dashboard Capture with active server-side countdown timers)

---

EVIDENCE AVAILABLE FOR MODERATOR REVIEW

• Full chat transcripts with Agent Sep confirming active 2FA
• KYC confirmation email from BC.GAME (April 2024)
• ISP abuse report confirmation from upstream provider (M247 Ltd)
• Email timestamps and session overlap screenshots
• Blockchain transaction records: https://tronscan.org/#/address/TVZReB5upDDPhHYHhdU3dUSwHaqGS9d7kP/transfers

No credentials, recovery phrases, or 2FA codes were ever shared.
No third-party sites or tools were used.

---

BC.GAME'S RESPONSE (OR LACK THEREOF)

• Formal recovery request submitted: January 19, 2026
• Stated response SLA: 72 hours
• Actual response: None
• Technical explanation provided: None
• Interim acknowledgment: None
• Resolution offered: None

Account remains locked with no path to recovery.

---

WHY THIS MATTERS

A verified SVIP6 player reporting a documented 2FA bypass should not be ignored.

If a withdrawal can be executed under these conditions, 2FA on BC.GAME does not provide the security guarantees users are led to believe it does.

Users deserve clarity, accountability, and restitution.

---

VERIFICATION & ACCOUNTABILITY

I have been a Bitcointalk member since February 2017 (username: cgraph). I am putting my 9-year-old forum identity behind this report because I understand the stakes of making a public allegation.

I am prepared to provide unredacted forensic documentation to any trusted forum moderator.

---

Due to a current health issue, my responses may be slightly delayed, but I will provide documentation to substantiate every claim in this report.

Contact: PM me

EDIT (April 7, 2026): Case status updated to Pending Restitution. BC.GAME has formally offered full restitution of 5,640.3878 USDT and account restoration. Acceptance filed; verification in progress via email. This thread will remain active until restitution is finalized.

EDIT (April 5, 2026): Case status updated to reflect 78 days elapsed and BC.GAME's third conflicting explanation (phishing theory). Comprehensive technical rebuttals regarding WebAuthn (Passkey) protocol and Google security logs have been submitted.

[cgraph]

UPDATE #1 – On-chain Deposit Date Discrepancy / Evidence of Duplicate Fund Movement

On January 25, 2026, BC.GAME recovery support requested proof of a “deposit made by January 16”. While reviewing the on-chain records to comply with this request, I identified a critical discrepancy that requires technical clarification from BC.GAME.

1. MoonPay Deposits (Independently Verifiable On-Chain)

All of my verifiable MoonPay deposits were completed as follows:

• January 15, 2026 – 128 USDT
• January 17, 2026 – 2,285 USDT total (5 deposits: 250 + 295 + 340 + 400 + 1,000)

Total: 2,413 USDT

There are no deposits initiated by me on January 16, 2026. This is independently verifiable on-chain and the timestamps are immutable.

2. The Discrepancy: Unauthorized Outbound Movements

In my opening post, I reported an unsolicited TRON withdrawal of 5,640.3878 USDT on January 17, 2026. This amount consisted of my January 17 deposits combined with game winnings accumulated prior to the breach.

During subsequent review of the Ethereum (ERC-20) records for my BC.GAME wallet, I identified two additional unauthorized outbound USDT transfers:

• January 16, 2026 (03:04 UTC): 511.4405 USDT
  View on Etherscan
  This transfer occurred before my January 17 deposits. The source and purpose of this amount are unknown to me.
• January 18, 2026 (01:55 UTC): 2,285 USDT
  View on Etherscan
  This occurred after the unsolicited TRON withdrawal and matches the exact total of my January 17 deposits.
  My 2,285 USDT deposit formed part of the account balance that was subsequently withdrawn via the unsolicited TRON transaction.

Both transfers were sent to the same destination address:
0x74a02e3E7aA2eB3cC464A786CEA8e5CAEc8E3EbF

3. Technical Red Flag: Etherscan Warning (Delegated / Custodial Execution)

Anyone can independently verify the following by viewing my wallet’s token transfer history on Etherscan:
Wallet Token Transfers

When attempting to copy the destination address (0x74a…) for either the January 16 or January 18 transaction, Etherscan displays the following security notice:

“The transaction for this token transfer was made by a different address than the sender of the token. Verify that this is the address you intend to interact with.”

This warning indicates the transfers were executed via a delegated or custodial mechanism (e.g. smart contract or administrative control), and not directly initiated by me. A user-signed transaction would not trigger this notice.

4. Why This Matters

• Non-existent Deposit: BC.GAME is requesting proof of a “January 16 deposit” that does not exist. The blockchain instead shows an unsolicited outbound transfer on that date.
• Duplicate Fund Movement: Funds deposited on January 17 were included in the balance withdrawn via TRON on January 17, yet the same amount appears again as an outbound ERC-20 transfer on January 18.
• Unauthorized Execution: Both ERC-20 transfers were executed without my interaction, as evidenced by Etherscan’s delegated-execution warning.

As of this update, BC.GAME has not clarified these discrepancies, has not provided any investigation timeline, and the account remains locked with no restitution offered.

I have formally requested clarification from BC.GAME regarding:
• the alleged “January 16 deposit”
• the identity and role of the destination address
• and whether these movements represent internal custody operations

All correspondence and on-chain evidence are being preserved.

[cgraph]

UPDATE #2 – 30+ Days Without Technical Response, Account Status Anomalies & Call for Structured Review

It has now been over 30 days since I submitted comprehensive recovery documentation to BC.GAME (January 19, 2026).

To recap the documentation provided:
- Complete MoonPay receipts with KYC verification
- Full blockchain transaction records
- Device and IP information
- Timeline evidence with screenshots
- Live session capture during breach

CURRENT STATUS: 30+ Days Without Technical Explanation

Despite providing complete documentation, no structured technical explanation has been received addressing:

1. How a full-balance withdrawal was authorized during my confirmed active session
2. Why the system processed the withdrawal without presenting a 2FA prompt to my device
3. Why multiple verification codes were generated from Montreal IP while my Serbian session remained active
4. The nature and authorization of the ERC-20 transfers documented in UPDATE #1

NEW DEVELOPMENT: Account Profile Status Changes

Since reporting this incident, I have observed changes to my account's public-facing profile information:

Profile View (bc.game/user/profile/33509850): Now displays a blank grey placeholder, and the profile is set to "Hidden"
SVIP6 Status: No longer visible in profile view
Gaming Statistics: Historical activity data removed
Account History: Public tier indicators eliminated

TECHNICAL CLARIFICATION REQUEST

Regarding the January 18 ERC-20 transfer documented in UPDATE #1:
The 2,285 USDT transfer occurred within 6 hours of the unauthorized TRON withdrawal. This amount precisely matches my January 17 deposit total, which had already been included in the TRON withdrawal balance.

TXID: 0x1bc78dfc25e8f2d995426c18a1675b6446392b1771360f3a50cb05291759ab6e
Destination: 0x74a02e3E7aA2eB3cC464A786CEA8e5CAEc8E3EbF

I respectfully request clarification regarding the purpose and authorization of this transfer in relation to the reported incident.

DIRECT REQUEST TO BC.GAME FORUM REPRESENTATIVE (@bctokenbot)

I have observed that BC.GAME now has an active representative on this forum assisting with case escalations. I respectfully request your intervention for a structured technical review of this incident, with the objective of restoring account integrity and ensuring appropriate resolution of the disputed funds in accordance with your platform’s security standards.

Case Details:

 UID: 33509850
 Username: tempara
 Reported: January 17, 2026
 Documentation Submitted: January 19, 2026
 Status: 30+ days without a structured response

For context: This concerns an SVIP6 account with $76,000+ in lifetime deposits, where a full-balance withdrawal occurred while 2FA protection was enabled — a scenario that your own support indicated should not be possible without physical access to the registered device.

DOCUMENTATION PRESERVATION

All relevant documentation, timestamps, blockchain records, and correspondence have been preserved and organized for potential structured review. I am not making public accusations. I am requesting a formal technical explanation of the documented security anomalies and account status changes.

I remain open to resolution and cooperative engagement.

EVIDENCE UPDATES:

• Profile Status Comparison (BEFORE/AFTER screenshots):
/
• January 18 ERC-20 Transaction Details: https://etherscan.io/tx/0x1bc78dfc25e8f2d995426c18a1675b6446392b1771360f3a50cb05291759ab6e
• Complete Timeline: https://postimg.cc/gallery/NMj87c0

Thank you.

[AHOYBRAUSE]

Nasty situation so it seems. BC support is and always will be a total shitshow if you really need urgent help, that's for sure. Even the VIP support takes days just to send you a draft that has absolutely no relation to the questions asked.

About the case on hand, I wonder how they process a high withdrawal like this (which is uncommon for the user in height, currency, and login) within seconds but I ad to wait minutes all the time having had 3 digit withdrawals in the past, makes no sense.

About the 2FA, really strange how they bypassed it but obviously there was a way. Seems like the hacker got access to your email since they also got the code that was sent to you somehow. Yet without the 2fa code it should still be tough.
I remember in the past you needed to enter at least 2 codes (out of 2) to make a withdrawal. That was between regular 2fa, an email code and a sms code. Maybe all they needed was email and sms?

About this one:

I have been a Bitcointalk member since February 2017 (username: cgraph). I am putting my 9-year-old forum identity behind this report because I understand the stakes of making a public allegation.

Sorry but you don't have a forum "identity". You had 1 post until now, your thread here could just be from a newbie and it would have the same weight.

Anyway, their support on bitcointalk really should look into this quick! @BC.Game Support
This account hasn't been online since over 3 weeks though, despite them promising handling cases like this from now on. Red flag!

[cgraph]

@AHOYBRAUSE, thank you for taking the time to analyze the situation so carefully. I genuinely appreciate your perspective.

You are absolutely right that the timing is one of the most unusual aspects. The full sequence — release from Vault (BCD), conversion to USDT, and final withdrawal via TRON — was completed in approximately 32 seconds. According to the session notifications I captured, the final withdrawal step executed instantly.

In my previous experience, much smaller withdrawals have required noticeably longer processing times. That contrast is one of the key technical questions I am hoping the platform will clarify.

Regarding the notification logic:

The email I received was not an authorization request; it was a “Withdrawal Successful” notification. No TOTP prompt or email confirmation step was presented to my device during the transaction, despite my authenticated session remaining active.

As for the security configuration, TOTP-based 2FA (Google Authenticator) has been enabled on my account since April 2, 2024 (account creation). While I cannot currently confirm historical SMS settings due to lack of access, I can state that no additional verification challenge was triggered at the time of the transaction.

On the forum history - that's a fair observation. I mentioned the 2017 registration simply to clarify that this is not a throwaway account. Ultimately, the credibility of the case rests on independently verifiable timestamps, screenshots, and public blockchain records.

I appreciate your engagement. These are exactly the kinds of technical inconsistencies I’ve been asking the platform to address in a structured way.

[holydarkness]

Sorry, I didn't closely read your... wall of text. Uhh, it's a lot of alphabets and no pictures. So, if you don't mind me asking [since I can't just simply run your UID to my contact on Risk department now], bby 2FA activated, which 2FA is this? Do you mind to share me screenshot of the 2FA? To talkimg please.

[bctokenbot]

Hello,

First of all, we take any report regarding account security very seriously. Our security team has reviewed the information associated with UID 33509850 and the activity that occurred on January 17, 2026.

Based on our internal logs, the sequence of actions recorded on the account appears to be the following:

Login using Email OTP verification

A Passkey authentication method was successfully bound to the account

The withdrawal request was then authorized using the Passkey authentication

From the system perspective, the withdrawal request was processed through a valid authentication flow. In particular, the withdrawal was signed through a Passkey credential that had been bound to the account shortly before the withdrawal occurred.

At this stage, our investigation indicates that the Passkey used to authorize the withdrawal was not previously associated with the account owner’s device.

This suggests that an unauthorized party may have obtained access to the email OTP verification step, which allowed the binding of a new authentication credential (Passkey). Once the Passkey was successfully registered, withdrawals could be authorized through that credential.

However, we still need additional information from the user to fully determine how the OTP verification step may have been compromised.

Specifically, we would like to verify:

• The exact timestamps of the email OTP messages received
• Whether the email account showed any suspicious login activity around the incident time
• Whether any devices or browsers were recently compromised or infected
• Whether the phone number used for verification received any unexpected OTP requests

We have already reached out privately to the user to collect further evidence so our security team can complete the investigation.

If the user is willing to cooperate and provide the requested information, we will continue the review and provide an update once the investigation is complete.

Security of user accounts is extremely important to us, and we encourage all users to secure their email accounts and devices, as email verification is a critical step in account protection.

bctokenbot

[AHOYBRAUSE]

From the system perspective, the withdrawal request was processed through a valid authentication flow. In particular, the withdrawal was signed through a Passkey credential that had been bound to the account shortly before the withdrawal occurred.

At this stage, our investigation indicates that the Passkey used to authorize the withdrawal was not previously associated with the account owner’s device.

So your system didn't think it's odd that there is a login from a total new IP (probably from a totally different country), then immediately there was a change for 2FA and you guys still proceeded to send out a big bigger than usual withdrawal to a wallet that has also never been used before??
Sorry, but this sounds like a total security problem.

I mean why do you use several channels to confirm actions (email pass code, 2fa) when having access to one through hack or something also compromises the other. Makes no sense.

Sure, the player is ALSO at fault but his email login was compromised, but your security seriously sucks!! By the way, there must also be a reason why the "hacker" knew that this username is associated with a certain BC account. Was there a data leak recently? I mean, it's common knowledge there was a data leak on BC before, this might be the reason why certain emails got targeted in the first place.

[holydarkness]

[...]
Based on our internal logs, the sequence of actions recorded on the account appears to be the following:

Login using Email OTP verification

[...]

OP, based from their rep's explanation, it seems there was a breach in your gmail account. Luckily, gmail stores activities from devices [and from what country the account got accessed] as well as notifying the account in subject as well as associated back-up account once a new device bound [even as simple as logging in] to the account.

Mind to check this?

And bctokenbot, I am well aware that if the narrative is true and the hack happened by gmail and out of your control, there is a chance OP will deny the notification sent by google team, perhaps even deleting them. Luckily, your system do record IP that... ohh, sorry, you can no longer let me see it and get me to vouch for you, the bridge has been severed. Good luck.

[cgraph]

UPDATE #3 — Investigation in Progress

First of all, I would like to thank the community members who took the time to review the details of this case and raise important technical questions.
Special thanks to @AHOYBRAUSE and @holydarkness for their input and for helping clarify several aspects of the incident.

In particular:
@AHOYBRAUSE raised valid concerns regarding the sequence of events (new login location, authentication changes, and withdrawal behavior). These questions are currently part of the ongoing review.

@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: Support Admission - 2FA Status & Infallibility Claim

There has now been a direct response from the BC.GAME forum representative (@bctokenbot), who has reached out via PM to request additional evidence for the ongoing investigation. The requested documentation has been provided, including:

• Timestamps of the security emails received during the incident.
• Google account device security logs confirming no unauthorized devices.
• Google account activity logs for the relevant time window, proving no unauthorized email access.

I believe the case is currently under review by the BC.GAME security team. I will post further updates here as soon as new information becomes available or the case is settled.

If any other experienced members notice something relevant in the timeline or security flow described in this thread, I would appreciate any additional insights. Independent technical perspectives are always helpful in cases like this.

[rohang]

Can u confirm if the withdraw was requested and completed within 30 secs?

Is that usual time for your normal withdraws?
By my experience only stake does it that fast, kindof surprising bc did it near instant

[cgraph]

Hi @rohang, thank you for joining the discussion.

Can u confirm if the withdraw was requested and completed within 30 secs?
Is that usual time for your normal withdraws?

Yes, according to the BC.GAME transaction log, the entire sequence was executed in approximately 32 seconds.

Timeline from the system records:
- 8:05:19 PM — Vault transfer out
- 8:05:31 PM — Swap executed (BCD → USDT)
- 8:05:51 PM — Withdrawal completed
Screenshot: 05_Master_Theft_Timeline.png

Regarding your second question: this is not consistent with my experience from my only previous withdrawal.

In December 2025, the process took noticeably longer and required manual interaction with the 2FA authentication on my device. In this case, however, the sequence was so rapid that I actually caught the notifications appearing on my screen in real-time while I was logged in from my usual location.
As you can see in the detail capture below, the "Withdrawal is in progress" and "Successfully withdrawn" alerts appeared almost on top of each other, confirming the near-instant nature of the breach:
Proof (Live Breach Detail): 01_Live_Breach_Detail.png

The fact that their system approved this automated-like sequence almost instantly, while bypassing the 2FA active on my physical device, is exactly what is currently being reviewed.

[rohang]

Hi @rohang, thank you for joining the discussion.

Can u confirm if the withdraw was requested and completed within 30 secs?
Is that usual time for your normal withdraws?

Yes, according to the BC.GAME transaction log, the entire sequence was executed in approximately 32 seconds.

Timeline from the system records:
- 8:05:19 PM — Vault transfer out
- 8:05:31 PM — Swap executed (BCD → USDT)
- 8:05:51 PM — Withdrawal completed

Screenshot: 05_Master_Theft_Timeline.png

Regarding your second question: this is not consistent with my normal withdrawal activity.

In this case, the sequence was so rapid that I actually caught the notifications appearing on my screen in real-time while I was logged in from my usual location. As you can see in the detail capture below, the "Withdrawal is in progress" and "Successfully withdrawn" alerts appeared almost on top of each other, confirming the near-instant nature of the breach:

Proof (Live Breach Detail): 01_Live_Breach_Detail.png

The fact that their system approved this automated-like sequence almost instantly, while bypassing 2FA active on my physical device, is exactly what is currently being reviewed.

Thats certainly very very fishy, gave u no chance to cancel the withdraw

It looks like you know your stuff and arent easy to get hacked etc. highly likely that this was an inside job of some bc employee, especially because of the near instant withdraw

[cgraph]

Thank you @rohang for pointing that out.

The near-instant execution is exactly why I find the "system's approval" so alarming.
If an automated sequence can bypass 2FA and move funds from Vault to an external wallet in 32 seconds without triggering any risk alerts, it raises serious questions about the platform's internal security integrity.

This is precisely why I've provided comprehensive security logs to @bctokenbot to help BC.GAME's investigation determine what happened at the system level, and why these transactions were green-lit so rapidly despite active security measures.

[JollyGood]

It is somewhat annoying to read another complaint against BC Game. I hope this will be resolved in your favour as soon as possible but do you trust BC Game to investigate the matter in a competent manner?

Without commenting on the issue of the 2FA (and the email account activity logs) and concentrating on the support BC Game have provided, when do you hope or expect for this matter to be concluded? The thread was created on 24th January 2026 therefore a lot of time has passed.

Thank you @rohang for pointing that out.

The near-instant execution is exactly why I find the "system's approval" so alarming.
If an automated sequence can bypass 2FA and move funds from Vault to an external wallet in 32 seconds without triggering any risk alerts, it raises serious questions about the platform's internal security integrity.

This is precisely why I've provided comprehensive security logs to @bctokenbot to help BC.GAME's investigation determine what happened at the system level, and why these transactions were green-lit so rapidly despite active security measures.

[cgraph]

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

[AHOYBRAUSE]

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, finally leading to the final settlement.

Actually, ever since they implemented "BC bank" and pay bonuses in installments you lose those rewards even faster when you don't claim them on a daily basis, basically like "reloads" on other sites. So yeah, those rewards are long gone and I can imagine they lost "track of how big those rewards are", so they won't be able to reinstate them.

All in all it's a very bad situation, support is too slow and does nothing but sending draft replies. Exactly the reason why I left the site in the first place. Bad support, greedy bonus structure, greedy house edge and and and....

[cgraph]

@AHOYBRAUSE, thank you for sharing your experience.

I understand your point regarding the bonus structure. In my case, I mentioned it mainly as a secondary consequence of the prolonged account lock.

However, the primary goal here remains unchanged: I want my funds returned and my account fully restored.

I've provided all the requested documentation to the representative.
I noticed he has been active on other threads today, yet my case remains without a substantive update despite the 48-day delay since the incident.

I am now waiting for BC.GAME's security team to finalize their review. I expect a fair resolution that reflects the status of a SVIP6 player.

Thank you for the support.

[edbtz]

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

i'm in the same boat as you. last deposit was january 2nd, account closed jan 3rd, they're requesting a deposit receipt from jan 4th. i'm having a back and forth with them on twitter and they tell me to be "respectful and stop insulting"  lol sorry, doesn't work like that. pull stunts like this and people will get angry

i'm not getting my hopes up because their rep seems to have a rebuttal for every single complaint, including yours. it's never "we apologize for the inconvenience and we resolved your issue". this forum is filled to the brim with bc complaints, not sure what more they have to do to earn a pin right under the 1xbet one

[cgraph]

@edbtz, thank you for sharing your experience. I'm sorry you're dealing with similar issues.

I encountered exactly the same tactic during the recovery process - being asked to provide proof of a transaction that doesn't exist in my account history.

From what you describe, you were asked for a January 4 deposit that also doesn't exist in your records.

At this point, I'm not drawing conclusions, but it is certainly concerning when multiple users report being asked for proof of transactions that are not present in their account history.

For now, I've provided my full technical logs and documentation to their forum representative (@bctokenbot).

I'm currently waiting for their response and hope this can be resolved properly.