NFD Reward Sybil Exploit

1. Incident Overview TL;DR

NFD suffered a public reward-claim exploit on BSC. In the canonical transaction 0x1fea385acf7ff046d928d4041db017e1d7ead66727ce7aacb3296b9d485d4a26, the attacker flash-borrowed 250 WBNB, bought NFD, rotated that NFD through freshly deployed helper contracts, repeatedly called the reward contract, sold the inflated NFD back to market liquidity, repaid the flash loan, and kept profit.

The root cause was a reward path at 0x8b068e22e9a4a9bca3c321e0ec428abf32691d1e that keyed reward eligibility to caller identity while sizing payout from the caller's live NFD balance. Because the qualifying principal was neither locked nor consumed, the same NFD could be transferred into a new helper address and used to claim again.

2. Key Background

The relevant token is NFD at 0x38c63a5d3f206314107a7a9fe8cbba29d629d4f9. Its verified source hard-codes 0x5b711b7d9567291bbc1bb505536d79124b85cce8 as tokenOwner, and collector deployment metadata shows the same owner deployed the reward contract at 0x8b068e22e9a4a9bca3c321e0ec428abf32691d1e.

The public liquidity route used by the exploit was the Pancake NFD/USDT pair at 0x26c0623847637095655b2868c3182b2285bdaeaf, the USDT/WBNB pair at 0x16b9a82891338f9ba80e2d6970fdda79d1eb0dae, and a public DODO flash-loan pool at 0xd534fae679f7f02364d177e9d44f1d15963c0dd7.

The attacker-controlled EOA 0x22c9736d4fc73a8fa0eb436d2ce919f5849d6fd2 deployed orchestrator 0xa35ef9fa2f5e0527cb9fbb6f9d3a24cfed948863 shortly before the exploit window and then used it across the observed exploit batch.

3. Vulnerability Analysis & Root Cause Summary

The vulnerable component was the protocol reward contract at 0x8b068e22e9a4a9bca3c321e0ec428abf32691d1e. Its public selector 0x6811e3b9 reads NFD.balanceOf(msg.sender) and then transfers reward NFD to msg.sender. The contract tracks the claim boundary by caller address, not by unique deposited principal or consumed entitlement. That design allows an attacker to move the same rolling NFD balance into a fresh helper contract and reset the identity gate for another reward claim. The safety invariant is straightforward: one unit of NFD principal must not be able to generate multiple reward payouts in the same reward window solely by being moved across new addresses. The concrete breakpoint is the 0x6811e3b9 reward path itself, where payout is computed from caller balance while the qualifying state is separable from economic ownership.

4. Detailed Root Cause Analysis

The reward-contract decompilation shows the critical logic directly:

function Unresolved_6811e3b9() public {
    address var_b = address(msg.sender);
    (bool success, bytes memory ret0) = address(nfd / 0x01).Unresolved_70a08231(var_b);
    ...
    (bool success, bytes memory ret0) = address(nfd / 0x01).Unresolved_a9059cbb(var_e);
    ...
    storage_map_n[var_f] = block.timestamp;
}

This path reads the caller's current NFD balance and then transfers reward NFD to that same caller. The call boundary is address-based, so a fresh helper contract presents a new identity even when the NFD principal originated from the same attacker-controlled pool.

The canonical trace confirms the exploit loop. The attacker orchestrator first acquires NFD after the DODO flash loan, then transfers NFD into a newly created helper, the helper calls 0x8B068E22...::6811e3b9(), receives more NFD, and transfers the enlarged balance back to the orchestrator. The same pattern then repeats with another newly deployed helper:

new helper -> NFD::transfer(helper, 2.125e26)
helper -> 0x8B068E22...::6811e3b9()
0x8B068E22... -> NFD::transfer(helper, 1.632e25)
helper -> NFD::transfer(0xA35ef9..., 2.302e26)

The balance-diff artifact matches the mechanism. In the canonical transaction, the reward contract lost 3902307610973871425428427156689192773183155557473726499665692717922884353080 NFD units, while the attacker EOA gained 2952685253101254291601 wei of native BNB value net of gas. The orchestrator also finished with a large positive NFD balance before the unwind, confirming that the reward loop inflated the attacker's inventory before the final swap.

The exploit was repeatable under public conditions. The same orchestrator executed additional successful exploit transactions 0xb6f9b5ef1feeadb379a2de8f79bb04dd6920bfb214136d057eed4ce23a0003f8 and 0x8b77d75efa185295b09bdf2edcb509541fdde40ed5484212331ceac41b2f4ac0, which is consistent with an ACT opportunity rather than a privileged one-off path.

5. Adversary Flow Analysis

The attacker lifecycle had three stages. First, the EOA 0x22c9736d4fc73a8fa0eb436d2ce919f5849d6fd2 deployed orchestrator 0xa35ef9fa2f5e0527cb9fbb6f9d3a24cfed948863 and enabled its own EOA through the orchestrator's membership setup transactions 0xdd058fb5a53db0e9236ad7f1b29d7c39e586a1cef53af5866794ed993b9633b7 and 0xb0059aacaf97019cc8121342a175a5bab46f617bb4641aedbe25f5664dc5ffb0.

Second, in the canonical exploit transaction 0x1fea385acf7ff046d928d4041db017e1d7ead66727ce7aacb3296b9d485d4a26 at block 21140435, the orchestrator borrowed 250 WBNB from DODO, swapped through Pancake into NFD, deployed a helper loop, repeatedly claimed from the reward contract, swapped back out through Pancake, repaid the 250 WBNB principal, and exited with profit.

Third, the attacker repeated the same public sequence in 0xb6f9b5ef1feeadb379a2de8f79bb04dd6920bfb214136d057eed4ce23a0003f8 and 0x8b77d75efa185295b09bdf2edcb509541fdde40ed5484212331ceac41b2f4ac0. No private keys, privileged admin actions, or hidden settlement channels were required; the necessary ingredients were public liquidity and a publicly callable reward path with transferable inventory.

6. Impact & Losses

The protocol-side impact was depletion of reward-contract NFD inventory and market realization of that inventory into WBNB. Across the three successful exploit transactions, the measured loss was:

[
  {
    "token_symbol": "WBNB",
    "amount": "4481324982360678881755",
    "decimal": 18
  }
]

For the canonical transaction alone, the attacker EOA's native BNB delta was 2952685253101254291601 wei net of gas. The broader economic loss is attributable to the reward contract paying repeatedly against the same NFD principal and the attacker dumping the resulting NFD into public liquidity.

7. References

• Canonical exploit tx: 0x1fea385acf7ff046d928d4041db017e1d7ead66727ce7aacb3296b9d485d4a26
• Repeated exploit txs: 0xb6f9b5ef1feeadb379a2de8f79bb04dd6920bfb214136d057eed4ce23a0003f8, 0x8b77d75efa185295b09bdf2edcb509541fdde40ed5484212331ceac41b2f4ac0
• Reward contract: 0x8b068e22e9a4a9bca3c321e0ec428abf32691d1e
• NFD token: 0x38c63a5d3f206314107a7a9fe8cbba29d629d4f9
• Attacker EOA: 0x22c9736d4fc73a8fa0eb436d2ce919f5849d6fd2
• Attacker orchestrator: 0xa35ef9fa2f5e0527cb9fbb6f9d3a24cfed948863
• Evidence used: canonical trace, canonical balance diff, reward-contract decompilation, attacker-orchestrator decompilation, attacker transaction history, and NFD verified source.