DHC exploit analysis

The DHC "Award" staking logic on BNB Chain had no re-claim guard. createAward recorded a fixed reward with no per-award reserve or locked collateral. participateAward did not require the award to still be in its unclaimed state, so a claimed award (status 2) could be reset to status 1 by anyone holding the position, for as little as 0 or 1 wei of input. claimAward then paid out the same fixed reward again from the shared proxy DHC balance. Repeating the participate-reset + claim loop drained the proxy's DHC balance one fixed reward at a time.

The attacker (EOA 0xD3A8D0A9F55cf679fff6F277E49AfC95B49D2B07) ran the exploit in four transactions in a single block, 120055460, on BNB Chain. The transaction set was a contract-creation deploying the exploit contract at 0x226923D34A10f3D54B57b9F4b685E82c6Cba968A and three calls into it: 0xc0406226, 0x9890220b, 0x84054d3d. The vulnerable proxy sat at 0xe2A047aADbac51b0116Af1cE91EbdAe4B4202094 (a TransparentUpgradeableProxy wrapping the unverified award implementation at 0x5ABB3fe2A02E5D4320862944cd3a0B8f6Af28CE1).

The first call seeded working capital: a USDT flash loan from DODO, a small DHC purchase on PancakeSwap to register an inviter (the award system rejects participants without one), and a createAward with a fixed payout. The second call made one participateAward pledge and one claimAward, putting the award into status = 2. The third call looped participateAward(id, 0-1 wei) to reset status 2 to 1 and claimAward(id) to drain the proxy's DHC balance, then sold the drained DHC back to USDT on PancakeSwap, repaid the flash-loan principal, and kept the surplus.

The README records the net profit at ~71,851 USDT. The award selectors (0x7f200fee, 0x9ba6df97, 0xe3db9b54, 0x43609f36) are not in the public 4byte directory, so the helper names in the PoC are reconstructed from the on-chain trace rather than from verified source. The proxy owner (0x007FA7F9...) is not the caller in the trace, confirming the attack is permissionless.

The fix is to gate claimAward on the award still being in its unclaimed state, and to track a per-award balance rather than pulling from the shared proxy balance. A simpler guardrail is to remove participateAward on an award that is already in status = 2, which closes the re-entry entirely.