muzafer26
80 Публикации
muzafer26
Отправить жалобу
Заблокировать пользователя
55 подписок(и/а)
13 подписчиков(а)
20 понравилось
Посты
·
--
Binance MegaFest: It Happened Again. Show Me the Server Record.
I gave Binance the benefit of the doubt the first time.
Today, the same thing happened again, and I recorded it.
I earned my Spins through the campaign requirements. At the daily reset, the interface showed my available Spins and allowed me to press GO.
I pressed GO.
Again: Error 110006.
Binance has already explained to me that the reward pool can be exhausted while the frontend continues showing the previous state, and that actual availability is determined when the backend processes the request.
Fine. Then I have a more specific question:
If this campaign is first-come, first-served, whose request actually reached the server first?
The published Terms say rewards are distributed FCFS until the $500,000 pool is exhausted. They also say remaining Spins can still be available even after the daily pool is exhausted. �
Binance
But where does it explain:
• The server-side queue/ordering mechanism?
• The timestamp when my request was received?
• The timestamp when it was processed?
• The exact time the pool became exhausted?
• My request's position in that processing sequence?
• What exact server event triggered 110006?
If Binance says:
“Your request was processed after the pool was exhausted.”
Then I am asking for the objective record supporting that statement.
I am not asking for another user's identity or private information.I am asking Binance to provide an anonymized technical explanation of my own request.
And another question:
Where is it written that the interface can continue showing GO/available Spins after the reward pool has already been exhausted?
The campaign announcement tells users:
“Click the GO button to use your spins and reveal your reward instantly.”
Binance
Binance Support previously confirmed to me that the specific frontend behavior was not explicitly described in the published Terms.
So please don't just tell participants:
“That's how the system works.”
Tell us where that mechanism was disclosed and what server-side evidence supports the outcome.2 days
Binance MegaFest: It Happened Again. Show Me the Server Record.
I gave Binance the benefit of the doubt the first time.
Today, the same thing happened again, and I recorded it.
I earned my Spins through the campaign requirements. At the daily reset, the interface showed my available Spins and allowed me to press GO.
I pressed GO.
Again: Error 110006.
Binance has already explained to me that the reward pool can be exhausted while the frontend continues showing the previous state, and that actual availability is determined when the backend processes the request.
Fine. Then I have a more specific question:
If this campaign is first-come, first-served, whose request actually reached the server first?
The published Terms say rewards are distributed FCFS until the $500,000 pool is exhausted. They also say remaining Spins can still be available even after the daily pool is exhausted. �
Binance
But where does it explain:
• The server-side queue/ordering mechanism?
• The timestamp when my request was received?
• The timestamp when it was processed?
• The exact time the pool became exhausted?
• My request's position in that processing sequence?
• What exact server event triggered 110006?
If Binance says:
“Your request was processed after the pool was exhausted.”
Then I am asking for the objective record supporting that statement.
I am not asking for another user's identity or private information.I am asking Binance to provide an anonymized technical explanation of my own request.
And another question:
Where is it written that the interface can continue showing GO/available Spins after the reward pool has already been exhausted?
The campaign announcement tells users:
“Click the GO button to use your spins and reveal your reward instantly.”
Binance
Binance Support previously confirmed to me that the specific frontend behavior was not explicitly described in the published Terms.
So please don't just tell participants:
“That's how the system works.”
Tell us where that mechanism was disclosed and what server-side evidence supports the outcome.2 days
I gave Binance the benefit of the doubt the first time.
Today, the same thing happened again, and I recorded it.
I earned my Spins through the campaign requirements. At the daily reset, the interface showed my available Spins and allowed me to press GO.
I pressed GO.
Again: Error 110006.
Binance has already explained to me that the reward pool can be exhausted while the frontend continues showing the previous state, and that actual availability is determined when the backend processes the request.
Fine. Then I have a more specific question:
If this campaign is first-come, first-served, whose request actually reached the server first?
The published Terms say rewards are distributed FCFS until the $500,000 pool is exhausted. They also say remaining Spins can still be available even after the daily pool is exhausted. �
Binance
But where does it explain:
• The server-side queue/ordering mechanism?
• The timestamp when my request was received?
• The timestamp when it was processed?
• The exact time the pool became exhausted?
• My request's position in that processing sequence?
• What exact server event triggered 110006?
If Binance says:
“Your request was processed after the pool was exhausted.”
Then I am asking for the objective record supporting that statement.
I am not asking for another user's identity or private information.I am asking Binance to provide an anonymized technical explanation of my own request.
And another question:
Where is it written that the interface can continue showing GO/available Spins after the reward pool has already been exhausted?
The campaign announcement tells users:
“Click the GO button to use your spins and reveal your reward instantly.”
Binance
Binance Support previously confirmed to me that the specific frontend behavior was not explicitly described in the published Terms.
So please don't just tell participants:
“That's how the system works.”
Tell us where that mechanism was disclosed and what server-side evidence supports the outcome.2 days
144
·
--
Статья
I Asked Binance to Explain Its US Stocks MegaFest Spin System Here Is What They ConfirmedI want to document my experience with Binance’s US Stocks MegaFest because I believe there is a genuine transparency question here that other campaign participants should understand.
I am not writing this to accuse Binance of fraud or manipulation. I simply want to document what happened, what I asked, and what Binance Support confirmed to me in writing.
My participation
I participated in the campaign for more than 10 days, completed the required activities, and earned 2 Spins.
I was waking up around 5 AM repeatedly to complete the campaign activities and put significant time and effort into earning those Spins.
When the relevant countdown/reset occurred, my screen showed:
GO + 2 available Spins
I attempted to use the Spin immediately.
Instead of receiving a reward, I received error 110006.
I had a screen recording showing what happened and provided the evidence to Binance Support.
At first, I did not want to assume that Binance had done anything wrong. I wanted to understand exactly how the system worked, so I spent considerable time asking Support specific questions and reviewing the campaign Terms.
What Binance Support explained
Binance Support explained that the reward allocation operates on a first-come, first-served basis according to server-side processing order.
They explained that unlocking a Spin provides only provisional eligibility to attempt a redemption. It does not guarantee that a reward will still be available.
They also explained that the GO button represents the interface state only and is not confirmation that a reward remains available.
Most importantly, Binance Support confirmed that the frontend can continue showing GO and available Spins even after the daily reward pool has already been exhausted.
The actual availability is determined when the backend processes the Spin request.
Support also told me that there is currently no separate real-time mechanism for users to verify the actual reward-pool availability before submitting the Spin.
I specifically asked whether faster tapping, a faster internet connection, or refreshing earlier could have prevented what happened.
Binance Support explained that no user action could guarantee success once demand exceeded the available pool.
They also explicitly confirmed that the outcome was not caused by any fault on my end.
Then I asked about the Terms
This became the central question of my complaint.
I asked Binance Support:
If the frontend can continue displaying GO and available Spins after the reward pool has already been exhausted, and the user only discovers that the pool is exhausted after submitting the Spin, is this specific frontend behavior explicitly described in the published Terms?
Binance Support confirmed that the published Terms disclose the FCFS mechanism, provisional eligibility, and reward-pool availability, but do not explicitly describe this specific frontend behavior in those technical terms.
Support described this behavior as an internal implementation detail.
That distinction is important to me.
I am not saying the Terms completely failed to mention FCFS or reward-pool availability. They did.
My question is whether the specific way the interface behaves after the pool is exhausted is sufficiently clear to an ordinary participant.
I asked Binance to confirm the entire record
Because the conversation had become lengthy, I asked Binance to consolidate the case into one factual summary so there would be no misunderstanding about what had actually been confirmed.
Binance Support replied:
“Confirmed — your summary accurately reflects the explanations and confirmations provided by Binance Support throughout this case, and it remains part of your case record.”
They further clarified that the confirmations regarding the mechanism, Terms disclosure, feedback, and goodwill gesture reflected Binance Support's own confirmations.
This written confirmation is important because I am not trying to reconstruct the entire case from memory. I asked Binance to verify my summary, and they confirmed it.
What exactly concerns me about the Terms?
The published campaign Terms explain that rewards are distributed first-come, first-served and that redemption remains subject to reward-pool availability.
They also explain that unlocking a Spin provides provisional eligibility.
My concern is more specific.
According to Binance Support, the participant may see:
2 Spins → GO available → attempt redemption → backend determines pool is exhausted → error 110006
The interface may still show the previous state because it has not yet reflected the backend's current reward-pool status.
And according to Support, there is no separate real-time mechanism available to the participant to verify the actual pool status before submitting the Spin.
That is the transparency question I believe deserves discussion.
What about the exact server-side timing?
I also asked Binance a more technical question.
I can establish from my screen recording when I tapped GO.
I asked Binance whether they could clarify the sequence between:
T1 — I tapped GO
T2 — Binance received my request
T3 — Binance processed my request
T4 — the reward pool was exhausted
Binance confirmed that my request was received and processed and that the pool had already been exhausted when the request was processed.
However, Binance told me that it could not provide internal server logs, request timestamps, queue ordering, or pool-status records.
Therefore, I am not claiming that I know exactly what happened during those milliseconds.
I don't have the server logs, and Binance has not provided them.
That is precisely why I am keeping this article factual rather than making assumptions about latency, queueing, or server-side processing.
What happened after I raised the issue?
I continued asking Binance to address the matter.
Eventually, Binance offered me VIP+1 as a goodwill gesture, initially for 10 days and later extending it to 20 days.
I explained that I am a student and a low-volume trader, so a temporary VIP upgrade has limited practical value to me.
I asked whether the goodwill gesture could instead be something more directly useful, such as a small bStocks voucher, USDT/crypto credit, or another Binance reward.
Binance told me that the alternative had been escalated to the relevant team, but it was not approved.
The 20-day VIP+1 therefore remained the maximum goodwill gesture available.
I ultimately accepted the VIP+1 goodwill gesture because, even though it has limited practical value for me, I felt that something was better than receiving nothing.
However, accepting the goodwill gesture does not mean that I consider the underlying transparency question resolved.
The goodwill gesture and the underlying complaint are two separate matters.
Why am I sharing this?
I am not posting this to call Binance a scam.
I am not claiming that Binance admitted fraud or manipulation.
I am also not claiming that I can prove the reward pool could not have been exhausted within milliseconds.
I don't have access to Binance's internal server records, so I won't pretend that I do.
What I can document is what happened on my side and what Binance Support subsequently confirmed.
I spent more than 10 days completing the campaign, repeatedly woke up around 5 AM to participate, earned 2 Spins, followed the process as carefully as I could, recorded the redemption attempt, and then spent significant additional time trying to understand the system.
After all of that, I believe there is a reasonable question worth asking:
If a participant can see GO and available Spins even after the reward pool has already been exhausted, while actual availability is determined only when the backend processes the request, and there is no real-time way for that participant to verify the pool status beforehand, should this behavior be explicitly disclosed to participants?
That is the question I asked Binance.
I documented the answers.
And Binance Support ultimately confirmed in writing that my consolidated summary accurately reflected its explanations and confirmations.
I am sharing the evidence so other participants can understand what happened, what Binance explained, and what Binance confirmed, and make their own judgment.
My goal is not to attack Binance.
My goal is simple:
Future campaigns should be designed and communicated clearly enough that another participant does not spend days completing tasks, see a Spin available, press GO, and only then discover that the backend considers the reward pool exhausted.
#BinanceSquare #CryptoCommunitys #TrendingTopic #Transparency #Accountability
I Asked Binance to Explain Its US Stocks MegaFest Spin System Here Is What They Confirmed
I want to document my experience with Binance’s US Stocks MegaFest because I believe there is a genuine transparency question here that other campaign participants should understand.
I am not writing this to accuse Binance of fraud or manipulation. I simply want to document what happened, what I asked, and what Binance Support confirmed to me in writing.
My participation
I participated in the campaign for more than 10 days, completed the required activities, and earned 2 Spins.
I was waking up around 5 AM repeatedly to complete the campaign activities and put significant time and effort into earning those Spins.
When the relevant countdown/reset occurred, my screen showed:
GO + 2 available Spins
I attempted to use the Spin immediately.
Instead of receiving a reward, I received error 110006.
I had a screen recording showing what happened and provided the evidence to Binance Support.
At first, I did not want to assume that Binance had done anything wrong. I wanted to understand exactly how the system worked, so I spent considerable time asking Support specific questions and reviewing the campaign Terms.
What Binance Support explained
Binance Support explained that the reward allocation operates on a first-come, first-served basis according to server-side processing order.
They explained that unlocking a Spin provides only provisional eligibility to attempt a redemption. It does not guarantee that a reward will still be available.
They also explained that the GO button represents the interface state only and is not confirmation that a reward remains available.
Most importantly, Binance Support confirmed that the frontend can continue showing GO and available Spins even after the daily reward pool has already been exhausted.
The actual availability is determined when the backend processes the Spin request.
Support also told me that there is currently no separate real-time mechanism for users to verify the actual reward-pool availability before submitting the Spin.
I specifically asked whether faster tapping, a faster internet connection, or refreshing earlier could have prevented what happened.
Binance Support explained that no user action could guarantee success once demand exceeded the available pool.
They also explicitly confirmed that the outcome was not caused by any fault on my end.
Then I asked about the Terms
This became the central question of my complaint.
I asked Binance Support:
If the frontend can continue displaying GO and available Spins after the reward pool has already been exhausted, and the user only discovers that the pool is exhausted after submitting the Spin, is this specific frontend behavior explicitly described in the published Terms?
Binance Support confirmed that the published Terms disclose the FCFS mechanism, provisional eligibility, and reward-pool availability, but do not explicitly describe this specific frontend behavior in those technical terms.
Support described this behavior as an internal implementation detail.
That distinction is important to me.
I am not saying the Terms completely failed to mention FCFS or reward-pool availability. They did.
My question is whether the specific way the interface behaves after the pool is exhausted is sufficiently clear to an ordinary participant.
I asked Binance to confirm the entire record
Because the conversation had become lengthy, I asked Binance to consolidate the case into one factual summary so there would be no misunderstanding about what had actually been confirmed.
Binance Support replied:
“Confirmed — your summary accurately reflects the explanations and confirmations provided by Binance Support throughout this case, and it remains part of your case record.”
They further clarified that the confirmations regarding the mechanism, Terms disclosure, feedback, and goodwill gesture reflected Binance Support's own confirmations.
This written confirmation is important because I am not trying to reconstruct the entire case from memory. I asked Binance to verify my summary, and they confirmed it.
What exactly concerns me about the Terms?
The published campaign Terms explain that rewards are distributed first-come, first-served and that redemption remains subject to reward-pool availability.
They also explain that unlocking a Spin provides provisional eligibility.
My concern is more specific.
According to Binance Support, the participant may see:
2 Spins → GO available → attempt redemption → backend determines pool is exhausted → error 110006
The interface may still show the previous state because it has not yet reflected the backend's current reward-pool status.
And according to Support, there is no separate real-time mechanism available to the participant to verify the actual pool status before submitting the Spin.
That is the transparency question I believe deserves discussion.
What about the exact server-side timing?
I also asked Binance a more technical question.
I can establish from my screen recording when I tapped GO.
I asked Binance whether they could clarify the sequence between:
T1 — I tapped GO
T2 — Binance received my request
T3 — Binance processed my request
T4 — the reward pool was exhausted
Binance confirmed that my request was received and processed and that the pool had already been exhausted when the request was processed.
However, Binance told me that it could not provide internal server logs, request timestamps, queue ordering, or pool-status records.
Therefore, I am not claiming that I know exactly what happened during those milliseconds.
I don't have the server logs, and Binance has not provided them.
That is precisely why I am keeping this article factual rather than making assumptions about latency, queueing, or server-side processing.
What happened after I raised the issue?
I continued asking Binance to address the matter.
Eventually, Binance offered me VIP+1 as a goodwill gesture, initially for 10 days and later extending it to 20 days.
I explained that I am a student and a low-volume trader, so a temporary VIP upgrade has limited practical value to me.
I asked whether the goodwill gesture could instead be something more directly useful, such as a small bStocks voucher, USDT/crypto credit, or another Binance reward.
Binance told me that the alternative had been escalated to the relevant team, but it was not approved.
The 20-day VIP+1 therefore remained the maximum goodwill gesture available.
I ultimately accepted the VIP+1 goodwill gesture because, even though it has limited practical value for me, I felt that something was better than receiving nothing.
However, accepting the goodwill gesture does not mean that I consider the underlying transparency question resolved.
The goodwill gesture and the underlying complaint are two separate matters.
Why am I sharing this?
I am not posting this to call Binance a scam.
I am not claiming that Binance admitted fraud or manipulation.
I am also not claiming that I can prove the reward pool could not have been exhausted within milliseconds.
I don't have access to Binance's internal server records, so I won't pretend that I do.
What I can document is what happened on my side and what Binance Support subsequently confirmed.
I spent more than 10 days completing the campaign, repeatedly woke up around 5 AM to participate, earned 2 Spins, followed the process as carefully as I could, recorded the redemption attempt, and then spent significant additional time trying to understand the system.
After all of that, I believe there is a reasonable question worth asking:
If a participant can see GO and available Spins even after the reward pool has already been exhausted, while actual availability is determined only when the backend processes the request, and there is no real-time way for that participant to verify the pool status beforehand, should this behavior be explicitly disclosed to participants?
That is the question I asked Binance.
I documented the answers.
And Binance Support ultimately confirmed in writing that my consolidated summary accurately reflected its explanations and confirmations.
I am sharing the evidence so other participants can understand what happened, what Binance explained, and what Binance confirmed, and make their own judgment.
My goal is not to attack Binance.
My goal is simple:
Future campaigns should be designed and communicated clearly enough that another participant does not spend days completing tasks, see a Spin available, press GO, and only then discover that the backend considers the reward pool exhausted.
#BinanceSquare #CryptoCommunitys #TrendingTopic #Transparency #Accountability
I am not writing this to accuse Binance of fraud or manipulation. I simply want to document what happened, what I asked, and what Binance Support confirmed to me in writing.
My participation
I participated in the campaign for more than 10 days, completed the required activities, and earned 2 Spins.
I was waking up around 5 AM repeatedly to complete the campaign activities and put significant time and effort into earning those Spins.
When the relevant countdown/reset occurred, my screen showed:
GO + 2 available Spins
I attempted to use the Spin immediately.
Instead of receiving a reward, I received error 110006.
I had a screen recording showing what happened and provided the evidence to Binance Support.
At first, I did not want to assume that Binance had done anything wrong. I wanted to understand exactly how the system worked, so I spent considerable time asking Support specific questions and reviewing the campaign Terms.
What Binance Support explained
Binance Support explained that the reward allocation operates on a first-come, first-served basis according to server-side processing order.
They explained that unlocking a Spin provides only provisional eligibility to attempt a redemption. It does not guarantee that a reward will still be available.
They also explained that the GO button represents the interface state only and is not confirmation that a reward remains available.
Most importantly, Binance Support confirmed that the frontend can continue showing GO and available Spins even after the daily reward pool has already been exhausted.
The actual availability is determined when the backend processes the Spin request.
Support also told me that there is currently no separate real-time mechanism for users to verify the actual reward-pool availability before submitting the Spin.
I specifically asked whether faster tapping, a faster internet connection, or refreshing earlier could have prevented what happened.
Binance Support explained that no user action could guarantee success once demand exceeded the available pool.
They also explicitly confirmed that the outcome was not caused by any fault on my end.
Then I asked about the Terms
This became the central question of my complaint.
I asked Binance Support:
If the frontend can continue displaying GO and available Spins after the reward pool has already been exhausted, and the user only discovers that the pool is exhausted after submitting the Spin, is this specific frontend behavior explicitly described in the published Terms?
Binance Support confirmed that the published Terms disclose the FCFS mechanism, provisional eligibility, and reward-pool availability, but do not explicitly describe this specific frontend behavior in those technical terms.
Support described this behavior as an internal implementation detail.
That distinction is important to me.
I am not saying the Terms completely failed to mention FCFS or reward-pool availability. They did.
My question is whether the specific way the interface behaves after the pool is exhausted is sufficiently clear to an ordinary participant.
I asked Binance to confirm the entire record
Because the conversation had become lengthy, I asked Binance to consolidate the case into one factual summary so there would be no misunderstanding about what had actually been confirmed.
Binance Support replied:
“Confirmed — your summary accurately reflects the explanations and confirmations provided by Binance Support throughout this case, and it remains part of your case record.”
They further clarified that the confirmations regarding the mechanism, Terms disclosure, feedback, and goodwill gesture reflected Binance Support's own confirmations.
This written confirmation is important because I am not trying to reconstruct the entire case from memory. I asked Binance to verify my summary, and they confirmed it.
What exactly concerns me about the Terms?
The published campaign Terms explain that rewards are distributed first-come, first-served and that redemption remains subject to reward-pool availability.
They also explain that unlocking a Spin provides provisional eligibility.
My concern is more specific.
According to Binance Support, the participant may see:
2 Spins → GO available → attempt redemption → backend determines pool is exhausted → error 110006
The interface may still show the previous state because it has not yet reflected the backend's current reward-pool status.
And according to Support, there is no separate real-time mechanism available to the participant to verify the actual pool status before submitting the Spin.
That is the transparency question I believe deserves discussion.
What about the exact server-side timing?
I also asked Binance a more technical question.
I can establish from my screen recording when I tapped GO.
I asked Binance whether they could clarify the sequence between:
T1 — I tapped GO
T2 — Binance received my request
T3 — Binance processed my request
T4 — the reward pool was exhausted
Binance confirmed that my request was received and processed and that the pool had already been exhausted when the request was processed.
However, Binance told me that it could not provide internal server logs, request timestamps, queue ordering, or pool-status records.
Therefore, I am not claiming that I know exactly what happened during those milliseconds.
I don't have the server logs, and Binance has not provided them.
That is precisely why I am keeping this article factual rather than making assumptions about latency, queueing, or server-side processing.
What happened after I raised the issue?
I continued asking Binance to address the matter.
Eventually, Binance offered me VIP+1 as a goodwill gesture, initially for 10 days and later extending it to 20 days.
I explained that I am a student and a low-volume trader, so a temporary VIP upgrade has limited practical value to me.
I asked whether the goodwill gesture could instead be something more directly useful, such as a small bStocks voucher, USDT/crypto credit, or another Binance reward.
Binance told me that the alternative had been escalated to the relevant team, but it was not approved.
The 20-day VIP+1 therefore remained the maximum goodwill gesture available.
I ultimately accepted the VIP+1 goodwill gesture because, even though it has limited practical value for me, I felt that something was better than receiving nothing.
However, accepting the goodwill gesture does not mean that I consider the underlying transparency question resolved.
The goodwill gesture and the underlying complaint are two separate matters.
Why am I sharing this?
I am not posting this to call Binance a scam.
I am not claiming that Binance admitted fraud or manipulation.
I am also not claiming that I can prove the reward pool could not have been exhausted within milliseconds.
I don't have access to Binance's internal server records, so I won't pretend that I do.
What I can document is what happened on my side and what Binance Support subsequently confirmed.
I spent more than 10 days completing the campaign, repeatedly woke up around 5 AM to participate, earned 2 Spins, followed the process as carefully as I could, recorded the redemption attempt, and then spent significant additional time trying to understand the system.
After all of that, I believe there is a reasonable question worth asking:
If a participant can see GO and available Spins even after the reward pool has already been exhausted, while actual availability is determined only when the backend processes the request, and there is no real-time way for that participant to verify the pool status beforehand, should this behavior be explicitly disclosed to participants?
That is the question I asked Binance.
I documented the answers.
And Binance Support ultimately confirmed in writing that my consolidated summary accurately reflected its explanations and confirmations.
I am sharing the evidence so other participants can understand what happened, what Binance explained, and what Binance confirmed, and make their own judgment.
My goal is not to attack Binance.
My goal is simple:
Future campaigns should be designed and communicated clearly enough that another participant does not spend days completing tasks, see a Spin available, press GO, and only then discover that the backend considers the reward pool exhausted.
#BinanceSquare #CryptoCommunitys #TrendingTopic #Transparency #Accountability
96
·
--
🚨 I WAITED FOR MY BINANCE SPIN — AND THIS IS THE RESULT?
Honestly, this is extremely frustrating.
I completed the required task for Binance US Stocks MegaFest and earned my spins.
I waited for the opportunity to use them.
Then yesterday, when I refreshed the campaign page, I saw:
“Already Redeemed.”
Today, my spins were still showing.
So I waited, tried again, and finally pressed GO.
Instead of getting the reward I had earned the spin for, Binance gave me:
“Unfortunately, we couldn't complete this request. Please refresh and try again. 110006.”
I contacted Binance Support and provided screenshots and screen recordings.
Now the response is basically:
The rewards were already claimed by other users.
No prize was registered.
Nothing can be added or compensated.
I understand that the reward pool is first-come, first-served. I am NOT complaining because someone else got a reward before me.
My issue is that I had a spin available and spent my time waiting to use it.
If the reward pool was already exhausted, why was my spin still displayed?
Why did I see “Already Redeemed” yesterday?
And why did pressing GO today produce error 110006 instead of clearly telling me that the reward pool was exhausted?
I don't want a random compensation without investigation.
I simply want Binance to check the backend logs and tell me what actually happened to my spin.
I completed the task.
I received the spin.
I waited.
I tried to use it.
The system failed.
That's why I'm asking Binance:
Please investigate this properly.
Has anyone else experienced “Already Redeemed” + error 110006 with US Stocks MegaFest?
#BinanceSquare #USStocksMegaFest #BinanceSupportTeam #BinanceRewardsSystem #CryptoCommunity
🚨 I WAITED FOR MY BINANCE SPIN — AND THIS IS THE RESULT?
Honestly, this is extremely frustrating.
I completed the required task for Binance US Stocks MegaFest and earned my spins.
I waited for the opportunity to use them.
Then yesterday, when I refreshed the campaign page, I saw:
“Already Redeemed.”
Today, my spins were still showing.
So I waited, tried again, and finally pressed GO.
Instead of getting the reward I had earned the spin for, Binance gave me:
“Unfortunately, we couldn't complete this request. Please refresh and try again. 110006.”
I contacted Binance Support and provided screenshots and screen recordings.
Now the response is basically:
The rewards were already claimed by other users.
No prize was registered.
Nothing can be added or compensated.
I understand that the reward pool is first-come, first-served. I am NOT complaining because someone else got a reward before me.
My issue is that I had a spin available and spent my time waiting to use it.
If the reward pool was already exhausted, why was my spin still displayed?
Why did I see “Already Redeemed” yesterday?
And why did pressing GO today produce error 110006 instead of clearly telling me that the reward pool was exhausted?
I don't want a random compensation without investigation.
I simply want Binance to check the backend logs and tell me what actually happened to my spin.
I completed the task.
I received the spin.
I waited.
I tried to use it.
The system failed.
That's why I'm asking Binance:
Please investigate this properly.
Has anyone else experienced “Already Redeemed” + error 110006 with US Stocks MegaFest?
#BinanceSquare #USStocksMegaFest #BinanceSupportTeam #BinanceRewardsSystem #CryptoCommunity
Honestly, this is extremely frustrating.
I completed the required task for Binance US Stocks MegaFest and earned my spins.
I waited for the opportunity to use them.
Then yesterday, when I refreshed the campaign page, I saw:
“Already Redeemed.”
Today, my spins were still showing.
So I waited, tried again, and finally pressed GO.
Instead of getting the reward I had earned the spin for, Binance gave me:
“Unfortunately, we couldn't complete this request. Please refresh and try again. 110006.”
I contacted Binance Support and provided screenshots and screen recordings.
Now the response is basically:
The rewards were already claimed by other users.
No prize was registered.
Nothing can be added or compensated.
I understand that the reward pool is first-come, first-served. I am NOT complaining because someone else got a reward before me.
My issue is that I had a spin available and spent my time waiting to use it.
If the reward pool was already exhausted, why was my spin still displayed?
Why did I see “Already Redeemed” yesterday?
And why did pressing GO today produce error 110006 instead of clearly telling me that the reward pool was exhausted?
I don't want a random compensation without investigation.
I simply want Binance to check the backend logs and tell me what actually happened to my spin.
I completed the task.
I received the spin.
I waited.
I tried to use it.
The system failed.
That's why I'm asking Binance:
Please investigate this properly.
Has anyone else experienced “Already Redeemed” + error 110006 with US Stocks MegaFest?
#BinanceSquare #USStocksMegaFest #BinanceSupportTeam #BinanceRewardsSystem #CryptoCommunity
5
6
1.8k
·
--
$NVDAB
{spot}(NVDABUSDT)
#CryptocurrencyWealth #CryptoTradingTip $NVDAB The biggest mistake traders are making right now:
They are buying random micro-cap altcoins expecting a 100x while Bitcoin Dominance ($BTC.D) is still holding strong. 📊🚨
Before you blow up your account on low-liquidity meme coins, keep these 3 rules in mind:
1. Follow liquidity: Money flows to $BTC first ➡️ $ETH / $SOL second ➡️ Major Alts third.
2. Don't marry a token: If your altcoin is making lower lows while BTC trends up, re-evaluate your thesis.
3. Protect your principal: Always take partial profits into $USDT on the way up.
Are you accumulating $BTC, holding major L1s like $SOL, or hunting low-cap gems right now? Drop your bag below!
$NVDAB
#CryptocurrencyWealth #CryptoTradingTip $NVDAB The biggest mistake traders are making right now:
They are buying random micro-cap altcoins expecting a 100x while Bitcoin Dominance ($BTC .D) is still holding strong. 📊🚨
Before you blow up your account on low-liquidity meme coins, keep these 3 rules in mind:
1. Follow liquidity: Money flows to $BTC first ➡️ $ETH / $SOL second ➡️ Major Alts third.
2. Don't marry a token: If your altcoin is making lower lows while BTC trends up, re-evaluate your thesis.
3. Protect your principal: Always take partial profits into $USDT on the way up.
Are you accumulating $BTC , holding major L1s like $SOL, or hunting low-cap gems right now? Drop your bag below!
#CryptocurrencyWealth #CryptoTradingTip $NVDAB The biggest mistake traders are making right now:
They are buying random micro-cap altcoins expecting a 100x while Bitcoin Dominance ($BTC .D) is still holding strong. 📊🚨
Before you blow up your account on low-liquidity meme coins, keep these 3 rules in mind:
1. Follow liquidity: Money flows to $BTC first ➡️ $ETH / $SOL second ➡️ Major Alts third.
2. Don't marry a token: If your altcoin is making lower lows while BTC trends up, re-evaluate your thesis.
3. Protect your principal: Always take partial profits into $USDT on the way up.
Are you accumulating $BTC , holding major L1s like $SOL, or hunting low-cap gems right now? Drop your bag below!
1
147
Войдите, чтобы посмотреть больше материала
Присоединяйтесь к пользователям криптовалют по всему миру на Binance Square
⚡️ Получайте новейшую и полезную информацию о криптоактивах.
💬 Нам доверяет крупнейшая в мире криптобиржа.
👍 Получите достоверные аналитические данные от верифицированных создателей контента.
Эл. почта/номер телефона
В тренде
BinanceLaunchesBinanceIntelligence
Просмотров: 580,272
3,645 обсуждают
🧠 ¿Hacer trading como un fondo de inversión experto? ¡Ahora la IA lo hace gratis por ti! 🤖📈
Wilsontrader97
·Лайков: 7
·Просмотров: 7.4k
WinklevossFilesSpotZcashETFApplication
Просмотров: 613
43 обсуждают
SouthKoreaAITradeLiftsWorldcoinTo$7.41B
Просмотров: 108
8 обсуждают