Rogue Developer Steals $785K in Roar Staking Contract Exploit

The staking contract associated with Roar was addressed, and a hacker drained over 785,000 from its staking pool when the staking pools were launched. The attacker used the emergencyWithdraw() flaw to withdraw 100 million $1ROR tokens immediately after staking rewards were deposited. Hacken, a prominent Web3 security auditor, was the first one to detect and report the details through its official social media platform, X account.

🚨 @th3r0ar Staking Exploit: $785K Stolen

A staking contract tied to Roar was exploited shortly after pools were created and rewards deposited.

The attacker abused a flaw in emergencyWithdraw(), specifically how withdrawal amounts were calculated, to drain 100M $1ROR – then… pic.twitter.com/CZNQA4kmU2

— Hacken🇺🇦 (@hackenclub) April 16, 2025

An early observation was made that the reward had a problem regarding calculating or miscalculating the withdrawal process. But after some research, it was found that the basic cause was the injection of some harmful code into the contract constructor. This constructor preset a staking amount for the attacker’s wallet address at deployment. This preloaded value enabled the wallet to withdraw tokens without staking tokens on multiple occasions in the first place.

Rogue Developer Behind the Incident

Yehor Rudytsia, the on-chain security researcher, analyzed the whole incident and shared his comments with the crypto community. The exploit was initiated after Roar staked rewards, after which assets were provided on the decentralized exchanges. The extracted tokens were subsequently exchanged to ETH and the funds were split among several wallet addresses simultaneously. Transactions were passed through Tornado Cash to ensure that laundering was almost invisible.

Roar stated that this attack was not carried out by an outsider but by an internal developer who exploited a process meant for early-version bug testing. The attackers remained dormant for 17 days after the signs of attack were evident, save for one attack witnessed by the investigators. This timing helped the hackers obtain sufficient market depth to sell the stolen tokens back to ETH without much price impact.

The investigators revealed that the developer preset the balance when creating the contracts. Consequently, the attacker was able to control the withdrawal function from the very start of the process. It was not an error missed while coding the second version of the app but a deliberate action by someone who had access.

Attacker Used Tornado Cash to Obscure Initial Funding Trail

The wallet procured its initial capital through Tornado Cash, which shows the subject’s desire to mask operations. Once the staking contract was empty, the attacker split and attempted to transfer the ejected tokens to different chains and wallet addresses.

Security experts also pointed out that it was not a technical vulnerability in the platforms but an operationally exploitable one. Yehor Rudytsia, the security researcher from Hacken also expressed that excessive trust in individual developers should be minimized in relation to internal controls and clear deployment specifications. He also stated,

“Projects need to implement reproducible builds, enforce separation between developers and deployers, and validate that deployed bytecode matches the audited source. But beyond that, orgs should treat dev access like a live attack surface: monitor credentials, watch for anomalies, and never store secrets in plaintext.”

Source