## 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.