I am asking the Bitcointalk community to independently review my dispute with Bitget.
I am a retail user from Brazil. My dispute involves TUTUSDT/BICOUSDT and a compensation determination of 12,712.84 USDT, which Bitget has declared “final.”
My concern is not simply that I disagree with the amount. I have repeatedly asked for the underlying records and methodology necessary to independently reproduce their calculation.
Aug. 19: I formally rejected the proposed settlement and requested preservation of orders, fills, positions, SYS/liquidation logs, mark/index prices, margin/risk records and compensation calculations.
Aug. 20: I specifically asked Bitget:
What is the official channel for submitting a Notice of Claim?
Who handles the dispute after Support declares its decision “final”?
Where are the records needed to independently reproduce the compensation calculation?
Aug. 22: Bitget again told me the compensation decision was “final” and said I could contact them if I wanted further clarification regarding the calculation.
But that clarification and the underlying records were exactly what I had already requested.
I have preserved my support communications, API/trading records, orders and fills. I am willing to provide redacted evidence here for independent examination.
I am not asking this community to automatically take my side.
I am asking experienced members to audit my evidence.
If my reconstruction is wrong, please show me where.
If it is correct, I want to understand why I cannot reproduce Bitget's 12,712.84 USDT determination from the available records.
My questions:
1. What records should I request from Bitget?
2. How should the affected cross-margin positions and SYS-classified fills be reconstructed?
3. What evidence should I publish here so experienced members can independently reproduce the calculation?
This dispute has already lasted more than two weeks and involves a substantial part of my savings. I want a technical, evidence-based review.
I will provide additional redacted evidence requested by members in this thread.
UPDATE — EVIDENCE #1: RAW BITGET API DATA / SYS EVENTS
Thank you for the questions. I agree that I need to provide the underlying evidence, not only describe the dispute.
I have now organized the first technical evidence package from data collected through Bitget's API.
For transparency, I am separating:
1. RAW API FACTS — information returned by Bitget's API
2. CALCULATIONS — calculations performed from those records
3. HYPOTHESES — interpretations that still need independent verification
I am NOT presenting my calculations as proven facts. I am asking experienced members to audit them.
----------------------------------------
1. WHAT THE API DATA SHOWS
----------------------------------------
The reconstructed records contain SYS-classified events associated with the affected accounts.
The first SYS event identified in the SUB account occurred at:
2026-08-09 07:10:22.977 UTC
For the MAIN account, SYS events identified in the dataset occur between:
2026-08-09 07:10:42.520 UTC
and
2026-08-09 07:10:51.300 UTC
For the ELITE account, a SYS event appears at:
2026-08-09 07:10:42.503 UTC
These timestamps come from the API-derived records in my evidence package.
One point I would particularly like experienced members to examine:
My reconstruction notes the first SUB SYS event at 07:10:22.977 UTC, while the TUT incident window referenced in the material I received/compiled begins at approximately 07:10:37 UTC.
I do NOT want to draw a conclusion from this timestamp difference without independent review.
I want to understand what the SYS classification represents in this context and whether these events can be reliably connected to the incident and subsequent compensation calculation.
----------------------------------------
2. REALIZED PNL ASSOCIATED WITH SYS RECORDS
----------------------------------------
When I aggregate the realized PnL fields associated with the SYS-classified records in the dataset, my reconstruction produces:
MAIN:
-30,107.61857092 USDT
SUB:
-12,838.32027004 USDT
ELITE:
-1,994.72 USDT
LINKED_KEY2:
-1,082.30625 USDT
IMPORTANT:
I am NOT claiming that the sum of these numbers automatically equals the loss Bitget is responsible for.
These are calculations derived from the SYS-classified records.
One of the reasons I am posting here is precisely to determine what these SYS records mean economically and how they should be interpreted.
----------------------------------------
3. BITGET'S COMPENSATION
----------------------------------------
Bitget ultimately determined compensation of:
12,712.84 USDT
Bitget has told me that this compensation amount was calculated according to its compensation plan/methodology and that the decision is final.
My problem is that I have not yet been able to independently reproduce that 12,712.84 USDT figure from the records available to me.
That does NOT necessarily mean Bitget's calculation is wrong.
It means I need to understand what data or methodology is missing.
----------------------------------------
4. IMPORTANT DATA I DO NOT HAVE
----------------------------------------
My evidence review identified information that does not appear to be reproducible from the user-accessible API records alone, including:
- historical equity/margin snapshots at the critical moment
- internal liquidation/ADL engine logs
- Bitget's internal compensation worksheet/calculation
- sufficiently granular historical mark/index price data for every relevant second
This distinction is important.
I do not want to claim that public/user API records prove something that they cannot prove.
Instead, I want to determine what CAN be reconstructed from the API and what requires internal exchange records.
----------------------------------------
5. QUESTIONS FOR TECHNICAL REVIEWERS
----------------------------------------
I would appreciate help from members experienced with futures exchange APIs, liquidation systems and cross-margin accounting.
Specifically:
1. What does a SYS-classified order/fill normally represent in this type of Bitget futures record?
2. Is summing realized PnL from SYS records a meaningful way to analyze the economic effect, or would that be methodologically incorrect?
3. How should the affected cross-margin positions be reconstructed from orders, fills and position history?
4. What significance, if any, should be assigned to the first SUB SYS event appearing at 07:10:22.977 UTC?
5. What additional data would be required to independently reproduce a compensation calculation?
6. Is it possible to validate or reject the 12,712.84 USDT compensation figure using only user-accessible API records?
----------------------------------------
6. EVIDENCE INTEGRITY
----------------------------------------
The evidence package contains the underlying API-derived JSON records, reconstructed tables and SHA-256 hashes so that the data used in the analysis can be tracked.
I also prepared a PUBLIC/REDACTED version specifically for independent review.
I will not publish API keys, secrets, authentication headers or unredacted account identifiers.
I can post the relevant redacted records here in smaller groups so members can examine them without downloading a huge archive.
----------------------------------------
NEXT EVIDENCE
----------------------------------------
If members agree, my next post will be:
EVIDENCE #2 — SYS EVENT TABLE
I will publish the relevant redacted SYS records with:
- UTC timestamp
- account label
- symbol
- side
- size
- execution/order price
- realized PnL
- relevant API fields
After that:
EVIDENCE #3 — position/order/fill reconstruction
Then:
EVIDENCE #4 — comparison between the reconstructed records and Bitget's 12,712.84 USDT compensation calculation.
My goal is simple:
If my reconstruction is wrong, I want someone to show me exactly where it is wrong.
If the available API data is insufficient to reproduce Bitget's calculation, I want to identify exactly which missing records are required.
I welcome criticism of the methodology and calculations.
UPDATE #2 — WHAT EXACTLY IS MY CLAIM, AND WHY IS 12,712.84 USDT IN DISPUTE?
Thank you for the recent comments.
One member raised an important criticism:
"As far as I can see, he doesn't have a case, he just expresses doubts about their algorithm and the way they calculated something. We can still only guess about some important inputs here, such as why exactly $12,712.84? whose money it is and how much he 'expected' compensation?"
I think this is a fair criticism.
So before posting EVIDENCE #2, I want to make the dispute itself much clearer.
----------------------------------------
1. THIS IS AN ACTIVE DISPUTE
----------------------------------------
This is not a historical complaint that has already been resolved.
I have been trying to resolve this matter with Bitget for more than 15 days.
The dispute concerns the TUTUSDT/BICOUSDT activity surrounding the August 9 incident and the subsequent compensation determination made by Bitget.
Bitget determined compensation of:
12,712.84 USDT
They subsequently informed me that their compensation decision and amount were "final."
I have continued requesting the records and methodology necessary to understand and independently verify that calculation.
----------------------------------------
2. WHAT AM I ACTUALLY CLAIMING?
----------------------------------------
I want to be very precise here.
I am NOT saying:
"Bitget owes me X because I added all negative PnL numbers together."
That would be an unsupported conclusion.
What I am saying is:
The user-accessible Bitget API records contain SYS-classified activity and realized PnL associated with the affected accounts.
My reconstruction of those SYS records currently produces:
MAIN:
-30,107.61857092 USDT
SUB:
-12,838.32027004 USDT
ELITE:
-1,994.72 USDT
LINKED_KEY2:
-1,082.30625 USDT
These figures are NOT my compensation demand.
They are evidence inputs that require interpretation.
This distinction is extremely important.
----------------------------------------
3. THEN HOW MUCH DO I CLAIM BITGET OWES ME?
----------------------------------------
At this stage, I do not want to invent a number simply to make the claim look stronger.
The purpose of this technical reconstruction is to determine the defensible economic loss attributable to the incident.
That requires separating:
A) normal trading losses
B) SYS/liquidation-related realized PnL
C) losses potentially associated with the TUT incident
D) BICO-related effects
E) cross-margin interactions between positions
F) amounts already compensated by Bitget
G) any losses that cannot legitimately be attributed to the incident
Only after those components are reconstructed can a technically defensible compensation figure be calculated.
That is precisely why the underlying records matter.
----------------------------------------
4. WHY DO I DISPUTE 12,712.84 USDT?
----------------------------------------
Because I cannot reproduce it.
If Bitget's 12,712.84 USDT calculation is correct, there should be some combination of:
- affected positions
- eligible loss criteria
- timestamps
- prices
- position sizes
- margin/equity state
- exclusions
- compensation rules
that mathematically produces:
12,712.84 USDT.
I have repeatedly asked for enough information to understand that calculation.
So far, using the records available to me, I have not been able to reproduce it.
This does NOT prove the figure is wrong.
It proves that, with the information currently available to me, the figure is not independently reproducible.
That is the technical question I am asking this forum to help examine.
----------------------------------------
5. WHY THE SYS DATA MATTERS
----------------------------------------
The API evidence contains SYS-classified events around the affected period.
The timestamps identified so far include:
SUB:
first identified SYS event:
2026-08-09 07:10:22.977 UTC
MAIN:
SYS events identified between:
2026-08-09 07:10:42.520 UTC
and
2026-08-09 07:10:51.300 UTC
ELITE:
SYS event:
2026-08-09 07:10:42.503 UTC
One potentially important issue is that the first SUB SYS event appears at:
07:10:22.977 UTC
while the TUT incident window referenced in the material I received/compiled begins at approximately:
07:10:37 UTC.
I am deliberately NOT claiming what this means.
I want experienced members to examine it.
----------------------------------------
6. WHY I CANNOT FINISH THE CALCULATION YET
----------------------------------------
There are several pieces of information that I do not appear to have through the user-accessible API data alone.
Among them:
- historical account equity at the critical seconds
- historical cross-margin state
- internal liquidation engine records
- ADL/internal risk-engine records
- sufficiently granular mark/index prices
- Bitget's eligibility rules for compensation
- Bitget's internal compensation worksheet
Without those records, there may be a limit to what an external reconstruction can prove.
Determining that limit is itself one of the purposes of this thread.
----------------------------------------
7. WHAT HAS HAPPENED DURING THESE 15+ DAYS
----------------------------------------
During this period I have:
- contacted Bitget Support
- preserved support communications
- requested clarification of the compensation calculation
- requested relevant underlying records
- asked about escalation after Support considered the decision final
- preserved API-derived trading records
- reconstructed orders/fills/positions
- separated raw API facts from my own calculations
- generated hashes for the evidence package
- prepared a redacted public version for independent examination
I am still trying to resolve the matter directly with Bitget.
At the same time, I am independently reconstructing the technical evidence.
----------------------------------------
8. REGARDING LEGAL ACTION
----------------------------------------
Some members suggested that legal action may ultimately be necessary.
That may be true.
However, before reaching conclusions about litigation or jurisdiction, I want to make the technical record as strong as possible.
If I eventually have to present this dispute to a lawyer, regulator, court or other dispute-resolution body, I want to be able to distinguish clearly between:
FACT:
what Bitget's API returned
CALCULATION:
what can mathematically be derived from those records
HYPOTHESIS:
what I believe may have happened but cannot yet prove
MISSING EVIDENCE:
what only Bitget may possess internally
I think that distinction is essential.
----------------------------------------
9. I AM NOT ASKING MEMBERS TO CALL BITGET A SCAM
----------------------------------------
Another member posted information about accusations/reviews involving Bitget.
I appreciate members researching the company.
However, for purposes of MY case, I would prefer that we focus primarily on evidence that can be directly connected to this dispute.
I am not asking anyone here to assume Bitget committed fraud.
I want the technical evidence tested.
If Bitget's calculation is correct, I want to understand and reproduce it.
If my reconstruction is wrong, I want the error identified.
If neither can be determined without Bitget's internal records, I want to identify exactly which records are missing.
----------------------------------------
10. NEXT: EVIDENCE #2 — SYS EVENT TABLE
----------------------------------------
My next evidence post will contain a redacted table of the relevant SYS-classified API records.
For each record I intend to provide:
- UTC timestamp
- account label
- symbol
- side
- size
- order/execution price
- realized PnL
- SYS classification
- relevant API fields
This should allow members to stop relying on my description and begin examining the actual records.
After that I will post:
EVIDENCE #3
Position / order / fill reconstruction
EVIDENCE #4
Cross-margin and economic-impact reconstruction
EVIDENCE #5
Attempt to reproduce Bitget's 12,712.84 USDT compensation
----------------------------------------
My objective remains the same:
Do not trust my conclusion.
Audit the evidence.
If I am wrong, show me where.
If Bitget's 12,712.84 USDT figure can be reproduced, I want to see the calculation.
If it cannot be reproduced without internal Bitget records, let's identify exactly what Bitget would need to disclose to make the calculation independently verifiable.
