Deep Dive into the GAIN Project Incident
On September 25, 2025—just a day after its Binance Alpha launch—GAIN was exploited via its Binance Smart Chain (BSC) deployment. By abusing a misconfigured LayerZero peer, the attacker triggered an unauthorized cross-chain mint on BSC and cashed out roughly $3M in stablecoins.
Overview
Date: Sep 25, 2025
Platform: Binance Smart Chain (BSC) and Ethereum (ETH)
Attacker Address in Ethereum:
https://etherscan.io/address/0xc7494498ac24e0ab1842ee12485bbfdb9c9e8294
Malicious Contract in Ethereum:
https://etherscan.io/address/0xba159054636e69080ae7c756319e5c85498efeb0
Attack Transaction in Ethereum:
https://etherscan.io/tx/0xab395b468fcd9f1e718e44a5ec22c1e3a6e3771ab7c9291049d5964d8fe25220
Transaction Broadcast on Binance Smart Chain via LayerZero:
https://bscscan.com/tx/0xa85b18bdbd32fbe5468de38032f7f2717faaad663d33991b2c71ce0b3892e866
Attack Timeline
Sep-24-2025 04:15:23 PM UTC: Attacker deploys Malicious contract in Ethereum.
Sep-24-2025 04:17:59 PM UTC - 04:24:47 PM UTC: Attacker executes 4 sequential transactions to configure the Malicious contract according to LayerZero specifications.
Sep-24-2025 10:42:35 PM UTC: Owner of GAIN contract in BSC sets peer to Ethereum Malicious contract
Sep-24-2025 11:01:47 PM UTC: On Ethereum, the attacker calls the Malicious contract to send a cross-chain message through LayerZero, requesting that the BSC GAIN contract mint tokens for the attacker on BSC.
Sep-24-2025 11:04:59 PM UTC: On BSC, LayerZero broadcasts the minting message. The message is approved by GAIN contract. GAIN contract then mints $5M worth of GAIN for
0xF3d17326130F90c1900bc0B69323C4C7E2d58Db2Subsequently, the address
0xF3d17...8Db2exchanged these GAIN tokens for approximately $3 million in USDT.
Why Does LayerZero Appear in the Attack?
The GAIN token is an ERC20 contract initially deployed on Ethereum. To expand to Binance Smart Chain, the project utilized LayerZero as a bridge. This bridging process requires configuring two contracts—one on Ethereum and one on BSC—according to LayerZero specifications, and establishing them as peers to each other.
In this case, the contract in BSC implements the OFT standard defined by LayerZero.
To approve messages from contracts in other chains through LayerZero, the OFT contract must explicitly specify both the chainID and the sender’s origin.
Under the OFT standard, only the contract’s owner/admin has the authority to set peer contracts.
Root Cause Determination
The core vulnerability originated from the GAIN contract owner setting an incorrect peer connection to a malicious contract. This security breach was due to operational error within the project implementation rather than any flaw in the LayerZero protocol itself.
Lesson learned
Lock down peer settings: Treat “who can talk to us” as crown-jewel configuration—protect changes with multisig approval and short timelocks, implement a carefully vetted allowlist, and automatically verify that production settings match your intended configuration.
Independent checks: Avoid solo operations; ensure every high-impact configuration change receives a second review and follows a concise checklist (covering IDs, addresses, limits, and rehearsed procedures).
Regular audits: Engage external experts before launch and after major changes to verify that both code and live configuration align with the intended design.
Watch for changes: Set up alerts for configuration and role updates, new counterparties, unusual activities, and sudden liquidity movements—complemented by a straightforward dashboard and a clear, one-page emergency response guide.