# Attribution Dispute - RedemptionQueueV2 DoS Vulnerability **URL:** \ **Category:** General Discussion\ **Created:** [December 17, 2025, 6:17am UTC](https://gov.frax.finance/t/attribution-dispute-redemptionqueuev2-dos-vulnerability/3818 "2025-12-17T06:17:08Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![donnyoregon](https://yyz1.discourse-cdn.com/flex031/user_avatar/gov.frax.finance/donnyoregon/32/1820_2.png) [@donnyoregon](https://gov.frax.finance/u/donnyoregon)\ **Post date:** [December 17, 2025, 6:17am UTC](https://gov.frax.finance/t/attribution-dispute-redemptionqueuev2-dos-vulnerability/3818/1 "2025-12-17T06:17:08Z")
`## Summary` ` ` `I am submitting this governance post to request community review of a bounty attribution dispute with the Frax security team regarding a critical DoS vulnerability in FraxEtherRedemptionQueueV2 (0xfDC69e6BE352BD5644C438302DE4E311AAD5565b).` ` ` ` **Core Issue:** I reported a critical vulnerability on December 4-5, 2025, which was denied as "no bug found." Subsequently, the exact mitigation I suggested was implemented in the deployed contract, yet the security team has denied making any changes and ceased all communication.` ` ` `## Timeline` ` ` `| Date | Event |` `|------|-------|` `| **Dec 4-5, 2025** | Submitted vulnerability report with complete PoC showing zero-amount redemption DoS |` `| **Dec 5, 2025** | Report denied by security team: "no bug found" |` `| **Dec 5-16, 2025** | Contract behavior changed (exact date unknown) |` `| **Dec 16, 2025** | Discovered patch when rerunning original PoC - now reverts with `CannotRedeemZero()` |` `| **Dec 17, 2025** | Requested clarification, security team claimed "We have done no such changes" |` `| **Dec 17, 2025** | Security team accused me of false accusations and ceased contact |` ` ` `## The Vulnerability Reported` ` ` ` **Vulnerability:** Zero-amount redemption tickets cause permanent FIFO queue DoS` ` ` ` **Attack Vector:** ` ````solidity` `// Attacker calls:` `redemptionQueue.enterRedemptionQueue(attackerAddress, 0)` ` ` `// Result: NFT created with 0 amount, maturity timestamp set` `// Impact: redemptionQueueAccounting[nftInformation[_nftId].hashedRedemptionData].nextNftId` `// is set to this zero-amount NFT` `// When redeemNft() is called: 0 ETH transferred, NFT stays in queue` `// Queue permanently blocked - subsequent redemptions cannot process` ````` ` ` ` **Severity:** Critical - Permanent DoS of all redemptions with minimal cost` ` ` ` **Suggested Mitigation:** Add input validation to reject zero-amount redemptions` ` ` `## Evidence of Implementation Change` ` ` `### 1. Original Test Execution (Dec 4-5, 2025)` ` ` `My original PoC test successfully created a zero-amount redemption:` ` ` ````solidity` `redemptionQueue.enterRedemptionQueue(attackerAddress, 0)` `// Result: ✅ NFT ID #29 created successfully` `// No revert, no error` ````` ` ` `### 2. Retest Results (Dec 16, 2025)` ` ` `Running the EXACT SAME test code against mainnet fork:` ` ` ````solidity` `redemptionQueue.enterRedemptionQueue(attackerAddress, 0)` `// Result: ❌ Transaction reverts` `// Error: CannotRedeemZero()` ````` ` ` `### 3. Bytecode/Source Mismatch on Etherscan` ` ` ` **Critical Finding:** The Etherscan verified source code does NOT show zero-amount validation in the entry function path.` ` ` ` **Verified Source - FraxEtherRedemptionQueueCore.sol:** ` ````solidity` `function _enterRedemptionQueueCore(` ` address _recipient,` ` uint120 _amountToRedeem` `) internal nonReentrant returns (uint256 _nftId) {` ` // Only checks MAXIMUM, not minimum` ` if (_amountToRedeem > MAX_FRXETH_PER_NFT) revert ExceedsMaxFrxEthPerNFT();` ` ` ` // ❌ NO ZERO-AMOUNT CHECK HERE` ` // The CannotRedeemZero() error is NOT used in this function` ` ` ` // Continues with NFT creation...` `}` ````` ` ` `**The `CannotRedeemZero()` error ONLY appears in:**` ````solidity` `function partialRedeemNft(..., uint120 _redeemAmt) external {` ` // 0 is reserved for full redeems only` ` if (_redeemAmt == 0) revert CannotRedeemZero();` ` ...` `}` ````` ` ` ` **Yet the deployed bytecode rejects zero-amount entries** with this exact error, proving either:` `1. The contract was upgraded but verified source was not updated, OR` `2. The verified source never matched the deployed bytecode` ` ` `## Logical Analysis` ` ` ` **If the vulnerability never existed:** ` `- My original test (Dec 4-5) would have reverted with `CannotRedeemZero()`` `- It did not - it succeeded and returned NFT ID #29` ` ` ` **If no changes were made to the contract:** ` `- My retest (Dec 16) would produce identical results` `- It did not - it now reverts with the exact error I suggested in my mitigation` ` ` ` **If the Etherscan verified source is accurate:** ` `- The contract should still accept zero-amount redemptions` `- It does not - proving bytecode/source mismatch` ` ` ` **Conclusion:** The contract implementation was changed between December 5-16, 2025, to add zero-amount validation. This change directly implements the mitigation suggested in my report.` ` ` `## Request to Frax Community` ` ` `I am requesting the Frax DAO/community review this dispute because:` ` ` `1. **I provided a complete, valid vulnerability report** with PoC demonstrating the issue` `2. **The vulnerability was real** - original tests prove zero-amount redemptions were accepted` `3. **The suggested mitigation was implemented** - current behavior proves zero-amount protection exists` `4. **There is a bytecode/source verification mismatch** that requires explanation` `5. **The security team's denial contradicts the on-chain evidence** ` ` ` `## Questions for Frax Team` ` ` `I respectfully request the Frax team provide:` ` ` `1. **On-chain proof** of when/if the RedemptionQueueV2 implementation was upgraded` `2. **Explanation** for why the deployed bytecode rejects zero-amount redemptions when the verified source does not show this validation in the entry path` `3. **Clarification** on whether Etherscan verification is current and accurate` `4. **Acknowledgment** of whether the `CannotRedeemZero()` check was added to `enterRedemptionQueue` after my report` ` ` `## Supporting Evidence` ` ` `All evidence is available in this repository:` `https://github.com/donnyoregon/frxETH-v2-public/tree/claude/fix-frax-dos-vulnerability-apVWb` ` ` `- `BYTECODE_SOURCE_MISMATCH_PROOF.md` - Detailed analysis of verification discrepancy` `- `DISPUTE_EVIDENCE_SUMMARY.md` - Complete timeline and technical evidence` `- Original PoC test code demonstrating the vulnerability` `- Test execution logs showing before/after behavior` ` ` `## Resolution Requested` ` ` `I am requesting:` ` ` `1. **Community review** of the technical evidence` `2. **Fair assessment** of the vulnerability report's validity` `3. **Attribution** for the vulnerability discovery and mitigation` `4. **Appropriate bounty** per Frax's bug bounty program terms for a Critical severity DoS vulnerability` ` ` `I have attempted to resolve this through the security team's official channels and was met with denial of the evidence and cessation of communication. I am now requesting the Frax community's involvement in reviewing this dispute.` ` ` `---` ` ` `**Submitted by: Donnyoregon` ` **Date:** December 17, 2025` ` **Contract Address:** 0xfDC69e6BE352BD5644C438302DE4E311AAD5565b` ` ` `Thank you for your time and consideration.` ` `