On November 20, 2025, GANA Payment was exploited for about $3.1M in liquidity on PancakeSwap, in an incident that raised serious questions about key management and admin controls.
On-chain traces indicate that the attacker obtained control over the GANA Deployer account and used its privileges to change staking parameters, rotate ownership across a chain of eight addresses, and ultimately extract about $3.1M in liquidity.
This pattern is consistent with either a private-key compromise or deliberate misuse of an admin key (rug-pull-like behavior), but the blockchain alone does not let us definitively distinguish between these scenarios.
What is clear is that the protocol’s security model relied heavily on a single high-privilege key and on EOA-only checks that can be bypassed in the presence of EIP-7702. Once that key was controlled by the attacker, the combination of unrestricted admin functions, centralized key ownership, and insufficient on-chain governance made the loss all but inevitable.
The exploit was originally flagged by on-chain investigator ZachXBT. The detailed forensic analysis in this report was prepared by Yehor Rudytsia, Head of Forensics and Incident Response at Extractor by Hacken.
Initial Breach Overview
The exploit centered on manipulating the gana_Computility reward rate. The staking contract contained a security check requiring the unstake() function to be called only by an EOA (Externally Owned Account), typically verified by checking if msg.sender == tx.origin.
The attacker bypassed this check using EIP-7702 transactions. This allowed them to run the contract code while keeping the transaction origin as an EOA. The contract treated the call as valid, letting the attacker maliciously change the reward rate and withdraw funds in a single transaction that appeared to come from a normal wallet.
GANA Payment Hack Timeline
The attack was executed using a coordinated network of 8 different accounts and a specific delegated contract. Decompiling the code revealed strict execution gating, limiting the contract to specific actors.
The contract checked whether tx.origin matched one of the following hardcoded addresses:
- 0x5d4041abd7094aa12496Ce919E88ee3E480c3e29
- 0x0b8fa3F694Adb6BBEBe83628ee4ceecE33C4821F
- 0x7b055955dc8ee2e3d4b139e42652cfb87f4eea3d
- 0x8998adaf5a05e81f414bc042a4419c2931d96776
- 0x46215669eb465970f924333e033eb0bfe4ec6c42
- 0xcdf43fc9f0f2ea640ad33b115bae231881f78a2d
- 0x7f4e661ba8ba136937ca86ec5e03a8d41e16ea10
- 0x5084c5809e14134644b1efb5b836964c141616fe
Pre-Exploit
- The attackers used 8 separate accounts to stake legitimate USDT into the protocol, accruing gana_Computility tokens.
- The GANA Deployer account, likely compromised, transferred ownership of the staking contract to a theft account.
- The attackers prepared a "delegated contract" containing the hacking logic.
Exploit
The theft account executed an EIP-7702 transaction. This transaction delegated the account's behavior to the malicious contract.
Inside this single transaction, the script:
- Updated Rates: Called setRatesPerSec to inflate the reward rate to an enormous value (10,000,000,000,000,000).
- Unstaked: Called unstake(). Because of EIP-7702, the contract viewed the caller as an EOA, allowing the withdrawal of massive rewards calculated at the inflated rate.
- Reset Rates: Immediately set the rate back to normal to hide traces or prevent front-running.
- Transferred Ownership: Transferred the staking contract ownership to the next theft account in the chain.
Post-Exploit
The function with signature 0x850 is called twice: before the unstaking and right after, so the rate is set to high and then set back to normal.
After the unstake() operation is performed and rate is set back to normal, and ownership over the contract is transferred to another theft account by executing the internal function with signature 0xaf.
This loop was repeated across the 8 accounts, draining over 3M USDT from the liquidity pool.
Funds Flow
The attacker immediately consolidated the stolen funds and began a laundering process involving cross-chain bridging and privacy protocols.
The USDT stolen by the 8 accounts was funneled to a central address (0x2e8...5C38) and then to a secondary address (0x98f...2b5a) holding $2M of stolen funds.
A portion of the funds was swapped to BNB and deposited into Tornado Cash on the BNB Chain. Approximately 346.8 ETH was bridged to the Ethereum mainnet and subsequently deposited into Tornado Cash on Ethereum.
Lessons Learned
The GANA Payment hack highlights critical lapses in administrative security and contract logic that can be addressed with actionable steps.
- Secure administrative access: Relying on a single private key for critical deployer or admin accounts is a single point of failure. Use Multi-Signature wallets (e.g., Gnosis Safe) for all administrative privileges to prevent a single compromised key from authorizing ownership transfers.
- Implement time-locks: Critical parameter changes, such as modifying reward rates or transferring ownership, should be subject to a Time-Lock. This forces a delay between a transaction request and execution, giving the community and monitoring tools time to react to malicious changes.
- Input validation & hard caps: Smart contracts should include hard caps on sensitive parameters. The ability to set a reward rate to 10,000,000,000,000,000 indicates a lack of sanity checks in the input logic.
- Secure authentication logic: As demonstrated by the EIP-7702 usage here, ensuring a caller is an EOA does not guarantee they aren't executing complex, programmatic logic.
