RebateFi Hook

First Flight #53
Beginner FriendlyDeFi
100 EXP
View results
Submission Details
Impact: high
Likelihood: high
Invalid

Centralized Fee Control Exploit Potential

Description:
The RebateFi Hook allows the contract owner to change fee structures at any time. This centralization creates significant risk because the owner can set extreme buy or sell fees without limits, potentially exploiting users. Sudden fee changes can also be timed with trades to manipulate token price or liquidity.

Normal Behavior:
The hook applies asymmetric LP fees to designated ReFi tokens, encouraging accumulation and reducing sell pressure through different fees based on swap direction.

Specific Issue:
The ChangeFee() function can be called at any moment by the owner, with no governance delay or community oversight, enabling fee manipulation before major trades. The owner can also withdraw tokens directly from the contract, creating a potential rug-pull risk.

Root Cause:
Centralized control over key economic parameters without time-lock mechanisms or defined minimum and maximum fee limits.

Risk:

Likelihood: High — This is likely whenever the owner acts maliciously or if the private key is compromised.
Impact: High — Users may suffer substantial losses due to sudden extreme fee changes or liquidity removal.

Proof of Concept:
The owner sets the buy fee to 0% for their address, swaps in a large amount of base tokens to acquire ReFi at low cost, then raises the sell fee to 100% before selling, trapping liquidity.

Recommended Mitigation:

  • Add a time-lock to fee changes to allow users time to react.

  • Enforce reasonable fee limits within the smart contract.

  • Use decentralized governance for fee adjustments.

Vulnerability Location:

  • Function: ChangeFee() — Allows the owner to set buy/sell fees at any time without limits or delay.

  • Function: withdrawTokens() (or equivalent) — Allows the owner to withdraw tokens from contract storage.

  • Access Control: Any code sections where the owner role is checked for privileged actions.

Issues:

  • Unbounded Fee Changes: ChangeFee() has no minimum or maximum limits on fee percentages, allowing harmful extreme settings.

  • No Delay Mechanism: Fee changes take effect immediately, enabling front-running or malicious timing attacks.

  • Liquidity Drain Risk: The withdrawal function allows complete removal of liquidity or user funds by the owner.

Recommended Fixes:

  • Add fee bounds, such as 0–5% for buys and 0–10% for sells, in ChangeFee().

  • Implement a 24-hour timelock for fee changes.

  • Replace single-owner control with DAO or multi-signature governance to reduce centralization risk.

Vulnerability Location & Fix Recommendations:

  • Function: ChangeFee() — Enables the owner to set buy/sell fees without constraints or delay, allowing manipulation before large trades.
    Suggested Fix: Add hard limits on allowable fee percentages and apply a timelock delay to prevent instant changes.

  • Function: withdrawTokens() — Allows the owner to remove tokens from contract storage, posing a rug-pull risk.
    Suggested Fix: Require multi-signature or DAO approval for withdrawals, and limit the amount that can be withdrawn per period.

  • Access Control Blocks — Owner privileges can be abused if the private key is compromised or misused.
    Suggested Fix: Replace the single-owner model with decentralized governance or multi-sig, and log all privileged actions with events for transparency.

Codebase Modifications in src/RebateFiHook.sol:

  1. ChangeFee() Function

    • Add fee limits and implement a timelock before fees take effect.

  2. Token Withdrawal

    • Replace unrestricted withdrawals with multi-sig or DAO approval.

    • Add a withdrawal limit per period.

  3. Access Control Hardening

    • Replace onlyOwner modifier with multi-sig or DAO governance checks.

    • Emit events for all privileged actions to ensure transparency.

To integrate the fixes seamlessly into their codebase, apply the following modifications in src/RebateFiHook.sol:

  1. ChangeFee() Function

  2. Token Withdrawal

    • Replace unrestricted withdrawals with multi-sig or DAO approval.

    • Implement withdrawalLimit as a per-period cap.


      3.Access Control Hardening

      • Replace onlyOwner modifier with a multiSig or DAO governance check.

      • Emit events for all privileged actions for transparency.

        function ChangeFee(uint256 _buyFee, uint256 _sellFee) external onlyOwner {
        require(_buyFee <= 500, "Buy fee too high"); // Max 5%
        require(_sellFee <= 1000, "Sell fee too high"); // Max 10%
        pendingBuyFee = _buyFee;
        pendingSellFee = _sellFee;
        feeChangeActivation = block.timestamp + 1 days; // 24h timelock
        emit FeeChangeScheduled(_buyFee, _sellFee, feeChangeActivation);
        }
        function applyFeeChange() external {
        require(block.timestamp >= feeChangeActivation, "Too early");
        buyFee = pendingBuyFee;
        sellFee = pendingSellFee;
        emit FeeChanged(buyFee, sellFee);
        }
        function withdrawTokens(address token, uint256 amount) external onlyOwner {
        require(amount <= withdrawalLimit, "Exceeds limit");
        require(isCommunityApproved(token, amount), "Not DAO approved");
        IERC20(token).transfer(msg.sender, amount);
        emit TokensWithdrawn(token, amount);
        }
Updates

Lead Judging Commences

chaossr Lead Judge 12 days ago
Submission Judgement Published
Invalidated
Reason: Design choice

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!