In late April 2026, our blockchain monitoring flagged a highly unusual sequence of transactions on NEAR. The exploit didn’t target Fireblocks infrastructure. It targeted SWEAT, a well-known ecosystem token, exposing any wallet holding it.
An active attacker on mainnet was silently draining millions of tokens from victim wallets. There were no phishing links, no compromised private keys, and no user signatures. In a single transaction, one victim alone was stripped of over 8.5 million SWEAT, worth roughly $170,000 to $250,000.
Our team fed the raw on-chain transaction data into our agentic research harness, which executed the following steps.
- Parsing the Receipt Graph: It mapped the complex, multi-layered smart contract calls of the exploit transaction to identify the exact flow of execution.
- Binary Decompilation: decompiling of WASM bytecode from both the attacker’s contract and the core token contract.
It took us about 20 minutes from the initial alert until we found the underlying: the token contract was failing to verify who was calling its internal functions.
Weaponizing the Refund Logic
The technical anatomy of the attack is simple. NEAR’s token standard (NEP-141) relies on a specific callback function called ft_resolve_transfer. When a user transfers tokens to a smart contract, this function checks whether the receiving contract actually consumed those tokens. If it didn’t, ft_resolve_transfer automatically triggers a “refund” and moves the unused balance back to the original sender.
In a secure implementation, this callback is strictly gated using NEAR’s #[private] macro. This macro acts as a digital bouncer, running a runtime check to ensure that the entity calling the function is the token contract itself (predecessor_account_id == current_account_id). The SWEAT contract was missing this single macro.
// The critical missing guard enabling the attack
#[private]
pub fn ft_resolve_transfer(&mut self, ...) -> ...
Since the function was exposed to the public, the attacker built a malicious contract to exploit it. The attacker’s contract executed a harmless “no-operation” (noop) call that returned completely empty bytes, then immediately chained a direct call to the victim’s ft_resolve_transfer function.
The token contract looked at the empty bytes from the previous step, interpreted it as “the receiver consumed zero tokens,” and dutifully “refunded” the victim’s entire balance to the attacker’s wallet.
Shifting From Reactive to Proactive: The HOT Zero-Day
After identifying the issue, we asked ourselves. If one major team missed this macro, who else did? We used agents and to proactive screening of the broader NEAR ecosystem for the exact same structural flaw. Using this method we detected the same flaw in the HOT token contract.
HOT is a Web3 token that governs:
- Over 22 million individual holders on NEAR.
- More than 35 million users across its broader wallet ecosystem.
- Hundreds of millions of on-chain transfers.
It was the identical class of bug. The ft_resolve_transfer callback was unguarded, meaning an attacker could have used the exact same “empty refund” attack to mint unlimited HOT tokens or drain the balance of any holder.
We reached out to the HOT token maintainers, and reported the issue. They acknowledged the issue and deployed a patch the same day.
A Definitive Lesson for Web3 Builders
Finding a subtle flaw in deployed code used to take security expert weeks. Using AI has caused a shift, enabling attackers to audit more code and find more vulnerabilities in a shorter time. Live code can now be probed for weaknesses at a pace defenders have never had to contend with before.
The same capability cuts both ways. The analysis that lets an attacker find a flaw in live code lets a defender find it first, disclose it, and get it fixed before anyone is harmed. As attackers raise their game with these tools, defenders have to match them.
This research was conducted by Oren Yomtov and Avi Bashan.
This post is for informational purposes only and does not constitute investment, financial, legal, or security advice. Fireblocks does not control third-party tokens, contracts, or protocols referenced here, and findings reflect analysis as of the date of publication.
