Submission Details
Impact:
Likelihood:
`OrderBook` Hardcoded Token Addresses in the `Constructor` Create Permanent Contract Obsolescence Risk
Root + Impact
Description
The smart contract hardcodes critical token addresses `(WETH, WBTC, WSOL, USDC)` directly in the constructor without any upgrade mechanism. This creates an immutable dependency on specific token contract implementations that may become deprecated, migrated, or obsolete over time. Given that the contract has no upgradeability mechanisms, any changes to these token contracts in the broader ecosystem will permanently strand user funds and render the contract unusable.
@> constructor(
address _weth,
address _wbtc,
address _wsol,
address _usdc,
address _owner
) Ownable(_owner) {
//rest of function
}
Risk
Likelihood:
Historical precedent: USDC has migrated contract addresses multiple times, and other major tokens have undergone similar transitions.
Impact:
- HIGH SEVERITY: Permanent contract death with no recovery mechanism
- Fund Lock: User assets become permanently inaccessible if any referenced token migrates or is deprecated
- Business Continuity: Complete service disruption with no ability to adapt to ecosystem changes
- Regulatory Risk: Inability to comply with potential regulatory requirements for token updates
- User Trust: Catastrophic loss of user confidence and potential legal liability
Proof of Concept
// Current implementation - immutable token references
constructor(address _weth, address _wbtc, address _wsol, address _usdc, address _owner) {
iWETH = IERC20(_weth); // Permanent reference - cannot be updated
iWBTC = IERC20(_wbtc); // If WBTC migrates, contract becomes obsolete
iWSOL = IERC20(_wsol); // Wrapped SOL could change bridge implementations
iUSDC = IERC20(_usdc); // USDC has historically upgraded contracts
}
// Scenario: USDC migrates to new contract address
// Result: Contract still references old USDC, users cannot interact with new ecosystem
//
Recommended Mitigation
1. Implement Token Registry Pattern
```diff
+ mapping(bytes32 => address) public tokenAddresses;
// Replace `tokenSymbol` and `newAddress` with actual token symbol and new address respectively
+ function updateTokenAddress(bytes32 tokenSymbol, address newAddress) external onlyOwner {
+ require(newAddress != address(0), "Invalid address");
+ tokenAddresses[tokenSymbol] = newAddress;
+ emit TokenAddressUpdated(tokenSymbol, newAddress);
+}
```
2 Implement Upgradeable Proxy Pattern
- Use OpenZeppelin's upgradeable contracts
- Implement proper upgrade governance with timelock
- Maintain storage layout compatibility
Updates
Rewards breakdown
nSLOC
217This contest has a flat reward structure with the following payouts:
100 EXP
20 EXP
2 EXP
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.