Emergency community support request: 188,932 DOT at Risk from sophisticated social engineering attack
Summary
A long-standing Polkadot community member has fallen victim to a sophisticated social engineering attack resulting in their account being compromised. Approximately 188,932 DOT (~$406,205 USD) is currently at risk. The funds are presently bonded and secure, but require governance intervention to permanently protect them from the scammer.
This discussion post is to inform the community about the situation and gather support before submitting a formal referendum proposal.
Both the Polkadot Support Team and the Polkadot Anti-Scam Team have been notified and are aware of this case.
Compromised Account
Address: 16JCybAA88yQ9t8Cus4YhB5mT5DjyBxBLEgYPCpH8HjnePTq
Subscan: https://assethub-polkadot.subscan.io/account/16JCybAA88yQ9t8Cus4YhB5mT5DjyBxBLEgYPCpH8HjnePTq
The Attack: Long-Term Social Engineering
Unlike typical phishing attacks, this was a months-long sophisticated social engineering operation:
- The attackers posed as legitimate Substrate developers, building trust with the victim over an extended period
- A keylogger was deployed to capture the victim's seed phrase
- Once the attackers had full access, they began systematically attempting to drain the account
Current Situation
| Status | Amount | Security |
|---|---|---|
| Bonded (Staking) | 188,932 DOT | Safe while bonded |
The funds remain bonded and are currently mostly secure. However:
- The scammer controls the seed phrase and can submit transactions at any time
- Any unbonding attempt by either party triggers a 28-day countdown
- The scammer is sophisticated and actively monitoring the account, executing attacks trying to unbond the funds
- Without governance intervention, this becomes an endless war of attrition
The Ongoing Battle
I am Mario Pino, member of the Polkadot community since the first testnets, former validator, and developer of Polkastats block explorer. I have been coordinating the technical defense of this account.
Defense Systems Deployed
We have implemented a defense system running across several servers with redundant RPC connections.
The scammer is not an amateur. Our battle has escalated through multiple phases:
- Phase 1: Simple TypeScript blocking scripts → Scammer bypassed
- Phase 2: Mempool sandwich attacks → Scammer adapted
- Phase 3: More sophisticated mempool defense bots → Scammer adapted
- Phase 4: Multi-layer blocking system → Currently fighting with scammer
Recent Incident: The 58,000 DOT Unbonding Battle
On January 2nd, 2025, 58,000 DOT was about to complete its unbonding period. The attacker had previously initiated this unbond in an attempt to drain funds.
What happened:
- We detected the scammer had bots prepared to attack distinct attack surfaces
- Both parties engaged in a mempool priority battle
- Through coordinated defense and community support from Asset Hub collators (thanks!!), we successfully rebonded the funds before entering a direct battle with the scammer
This battle demonstrated both the sophistication of the attacker AND the power of community coordination.
Why Governance Intervention is Needed
While our defensive systems are currently effective, this situation is unsustainable:
- Resource intensive: Running 24/7 defense across multiple servers indefinitely is not viable
- Risk of failure: One missed block, one RPC timeout, one new attack vector = funds lost forever
- Attacker persistence: The scammer has shown they will wait and adapt indefinitely
- No path to recovery: Without governance, the victim can never safely access their own funds
The ongoing battle is consuming resources that could be better used elsewhere. See https://github.com/paritytech/polkadot-sdk/issues/10719
Precedent: Parallel Finance (Referendum 1424)
A similar situation occurred with Parallel Finance where 200,000 DOT was at risk from a compromised sudo key. The community successfully passed Referendum 1424 to secure the funds through governance action.
Reference: https://polkadot.polkassembly.io/referenda/1424
Proposed Solution
We are preparing a Root track referendum to permanently secure the funds. The proposed approach:
Force Transfer to Safe Account
Use balances.forceTransfer to move the bonded funds to a new, secure account controlled by the victim.
We are open to community feedback on the best technical approach.
Request for Community Support
- Technical Review: We welcome review of our proposed solution by Fellowship members and technical experts
- Decision Deposit: Root track requires 100,000 DOT decision deposit - we may need community support for this
- Voting Commitment: When the referendum goes live, we need strong AYE votes to pass within the decision period
How You Can Help Now
- Comment on this discussion with your support or technical suggestions
- Share this post to raise awareness
- Contact us if you have relevant technical expertise or governance experience
Evidence & Verification
We are prepared to provide:
- On-chain evidence of the attack attempts
- Transaction history showing the ongoing battle
- Identity verification of the victim through trusted community members
- Signed message using victim's compromised account
I am happy to verify my identity with any community member or Fellowship member who wishes to confirm this case.
For questions or additional information, please comment below or reach out to Mario | Polkastats via the Polkadot Watercooler Matrix channel or also via email to hello@polkastats.io
Your support can help protect a community member from losing their life savings to scammers. Thank you.
Comments (2)
Congratulations to the team for their performance. I came here today to see some updates and only came across this post. It's a very delicate situation, but, to be honest, I still think that disapproval through a referendum is inevitable. Think about it: a Polkadot wallet is protected in many ways (besides words, of course). With all that money, for a user not to take due care of their information is a complete lack of common sense. We should also consider the principle: if you act for one, you must act for all. Currently, Polkadot has over a thousand reports of scams involving everything from sophisticated malware techniques to social media scams. Governance shouldn't be used for this type of problem; it seems more like a kind of favoritism towards a specific user, which raises some 'concerns' about the direction Polkadot has been taking.
Regarding the comparisons, the order of some actions becomes even more blatant, considering that the intervention on referenda/1424 aimed to regain control and not transfer funds to 'another' account of the user in question...
Look, I'm not defending an attacker nor blaming the current owner, but it seems this conversation is taking a strange and erratic turn.
I have full confidence in the Polkadot anti-fraud team and I know they can handle very robust architectures so that you can regain CONTROL of your account; there are several ways:
utility.batchAll ⇒ proxy, addProxy
staking ⇒ staking, setPaye
among thousands of other ways.
In short, this needs to be thoroughly reviewed; something doesn't seem right to me. Once again, excellent work from the support team.
Another important point that we must never overlook regarding the aforementioned incident refers precisely to a direct update in the Parallel environment, not some kind of social engineering trick.
We cannot forget that security principles can never be disregarded; a social engineering scam to steal a wallet seems more like negligence than any other malicious activity. Let's take this to the forum [https://forum.polkadot.network/] to seek support from the community, which in my view is where this topic should be.