OrderBook
First Flight #43
Beginner FriendlySolidity
100 EXP
View results
Previous Next
Submission Details
Impact: high
Likelihood: high
Invalid

Centralization Risk

gwish08

Centralization Risk

Description

The contract employs a governance structure dominated by a single owner address, consolidating critical administrative authority. This centralization poses systemic risks to both user safety and the protocol’s overall resilience.

  • The contract is designed with owner-only functions that control core operational parameters including token allowlists and emergency withdrawals.

  • The centralized control structure creates a single point of failure where the owner can unilaterally make decisions that affect all users' funds and trading capabilities without any delay or community oversight.


// @> Owner can add/remove any token from trading, potentially rugpulling users
function setAllowedSellToken(address _token, bool _isAllowed) external onlyOwner {
if (_token == address(0) || _token == address(iUSDC)) revert InvalidToken();
allowedSellToken[_token] = _isAllowed;
emit TokenAllowed(_token, _isAllowed);
}
​
// @> Owner can withdraw any non-core tokens, potentially including user funds
function emergencyWithdrawERC20(address _tokenAddress, uint256 _amount, address _to) external onlyOwner {
if (
_tokenAddress == address(iWETH) || _tokenAddress == address(iWBTC) || _tokenAddress == address(iWSOL)
|| _tokenAddress == address(iUSDC)
) {
revert("Cannot withdraw core order book tokens via emergency function");
}
if (_to == address(0)) {
revert InvalidAddress();
}
IERC20 token = IERC20(_tokenAddress);
token.safeTransfer(_to, _amount); // @> No timelock or community approval required
}

Risk

Likelihood:

  • The owner's key may be compromised due to phishing attacks, social engineering, or vulnerabilities in their wallet setup.

  • The owner could act maliciously or make poor decisions under external pressure, manipulation, or financial distress.

  • If the owner's private key is lost or the owner becomes unavailable, critical contract operations may be indefinitely paralyzed.

Impact:

  • Users lose confidence in the protocol leading to mass exodus and collapse of trading volume

  • Active orders become worthless when the owner removes tokens from the allowlist, trapping user funds

  • Emergency functions can be misused to extract value from tokens that users may have accidentally sent to the contract


Proof of Concept

// Scenario 1: Owner removes popular token from allowlist
// 1. Users currently have active sell orders for wETH
// 2. Owner calls setAllowedSellToken(wETH, false)
// 3. This prevents the creation of new orders and modification of existing ones involving wETH
// 4. Users must cancel their orders to retrieve tokens, potentially disrupting market operations
​
// Scenario 2: Emergency withdrawal abuse
// 1. A user mistakenly sends valuable tokens to the contract
// 2. Owner invokes emergencyWithdrawERC20(valuableToken, amount, ownerAddress)
// 3. Instead of returning the tokens, the owner retains them
// 4. The contract has no mechanism to contest or reverse this action, enabling potential misuse

Recommended Mitigation

Consider implementing a timelock.

Updates

Lead Judging Commences

yeahchibyke Lead Judge about 1 month ago
Submission Judgement Published
Invalidated
Reason: Design choice

Support

FAQs

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