Skip to main content
• 5 min read

Projekt Reward Vault Exploit:
$560K Drained via Reward Logic Flaw

$560,000 was drained from Projekt's Ethereum reward vault after a flash-loan-funded Uniswap V2 skim faked token purchases and inflated ETH allocations.

AUTOSEC.DEVAUTOSEC.DEV
Projekt Reward Vault Exploit: $560K Drained via Reward Logic Flaw
  • Incident Date: July 25, 2026
  • Target: Projekt (GREEN/GOLD) reward vault
  • Target Overview: The target was an unverified Ethereum contract described by Defimon Alerts and Forta Network as a "buy-to-earn" reward vault. The reviewed sources did not identify verified documentation, an official project channel, or the vault's pre-incident TVL.
  • Total Loss: Approximately $560,000 (301.7 ETH)
  • Victim Vault: 0x574fc478bc45ce144105fa44d98b4b2e4bd442cb
  • Attacker Address: 0x61e7ad696215688d274c729a4cd0fbbc88fc4f85
  • Exploit Transaction: 0x90f40d3c3b60370f7287d51d972ef54596c46e98f21af91b03a4e84c5e410f64
  • Attack Vector: Business logic flaw in buy-to-earn reward accounting

Incident Review & Technical Details​

1. Attack Path​

  1. The attacker borrowed approximately 14,000 WETH: In one atomic Ethereum transaction at 01:11:59 UTC, the attacker sourced temporary liquidity through a Morpho flash loan. The capital provided enough scale to manipulate the reward vault's purchase-accounting inputs without leaving an equivalent amount committed.
  2. Uniswap V2 skim() calls manufactured balance increases: According to Defimon Alerts, the attacker routed the flash-loaned liquidity through dozens of Uniswap V2 memecoin pairs and used skim() to move excess token balances into attacker-controlled contracts. These round trips created large token-balance increases that resembled purchases to the vault while imposing near-zero net acquisition cost beyond execution costs and market friction.
  3. Permissionless trackPurchase() credited unbacked rewards: The unverified vault exposed trackPurchase(buyer) without caller restrictions. The function sized an ETH reward allocation from the specified buyer's token-balance delta but did not verify that the buyer had spent ETH, executed a genuine market purchase, or had not already reused the same economic activity.
  4. massWithdraw() paid out the artificial allocation: After inflating its recorded entitlement, the attacker invoked massWithdraw(), which Defimon Alerts described as transferring the stored allocation to msg.sender. Approximately 301.7 ETH, valued at about $560,000, left the reward pool before the Morpho loan was repaid within the same transaction.

2. Impact Scope​

  • Protocol-Level Loss: The Projekt reward vault lost approximately 301.7 ETH (~$560,000). The reviewed sources did not report any recovery, compensation plan, or remaining vault balance.
  • Composed-Protocol Exposure: Morpho supplied the temporary WETH and Uniswap V2 pairs provided the skim() primitive used in the exploit path, but no reviewed source attributed a loss or vulnerability to Morpho, Uniswap, or the affected token-pair liquidity providers.
  • Detection Without Confirmed Prevention: Forta Network stated that Forta Firewall flagged the exploit transaction. Because the transaction still completed and drained the vault, the public statement supports detection but does not establish that an integrated policy blocked execution.
  • Ecosystem Contagion: The reported incident was confined to one unverified Ethereum reward vault. No reviewed source reported bad debt, a token depeg, a cross-chain impact, or losses at an integrated lending protocol.

3. Official Statements​

  • Projekt: No project-controlled incident statement, technical post-mortem, or compensation announcement was identified in the public sources reviewed as of July 31, 2026.
  • Forta Network: Forta reported the $560,000 drain, summarized the missing ETH-spend validation, and stated that Forta Firewall flagged the transaction.
  • Defimon Alerts: Defimon published the exploit transaction and involved addresses, attributing the loss to permissionless reward tracking based solely on token-balance changes.

4. Investigation Progress​

The available evidence identifies the primary transaction, attacker address, victim vault, flash-loan source, reward-accounting flaw, and withdrawal function. The victim contract remains unverified on Etherscan, however, so no reviewed source provides a verified source-code implementation, deployment repository, audit history, or authoritative explanation from the contract owner.

As of July 31, 2026, the reviewed sources had not published the attacker's subsequent fund movements, any exchange or mixer deposits, a freeze request, negotiated return, or recovered amount. The public analysis therefore establishes how the vault was drained but not the later laundering or recovery status.

AUTOSEC.DEV Solution​

Reward systems must preserve a simple economic invariant: payouts cannot be created from reversible balance movements that never deliver equivalent value to the protocol.

  1. Secure Code Review — Projekt's trackPurchase() reportedly converted a buyer's token-balance increase into an ETH allocation without proving that ETH had been spent or that the activity was unique. AUTOSEC.DEV reviews reward-accounting state transitions with invariant fuzzing and economic modeling, checking that every credited payout is bound to authenticated value inflow, consumed exactly once, and capped by realizable protocol revenue.
  2. Penetration Testing — The attacker combined approximately 14,000 WETH in temporary liquidity, Uniswap V2 skim() calls, a permissionless tracking function, and massWithdraw() in one transaction. AUTOSEC.DEV reproduces comparable flash-loan and balance-round-trip sequences on a fork to test whether external liquidity, callback ordering, same-transaction accounting, or direct function calls can manufacture a withdrawable reward.

Reference​