The DEX adapter implementation in Zaros uses a static, owner-controlled deadline
for all swap operations across UniswapV2
and UniswapV3
integrations. This design creates a single point of failure where all DEX operations could potentially fail if the deadline becomes stale, requiring active management to maintain system functionality.
The vulnerability manifests in the interaction between FeeDistributionBranch.sol
's fee conversion mechanism and the underlying DEX adapters.
_performMultiDexSwap
in FeeDistributionBranch.sol
: This function iterates through multiple swaps, creating a SwapExactInputSinglePayload for each hop but doesn't include a per-transaction deadline:
FeeDistributionBranch.sol#L402-L439
The deadline
is instead managed globally in BaseAdapter.sol
and set by the owner
:
BaseAdapter.sol#L153-L162
Both UniswapV2Adapter.sol
and UniswapV3Adapter.sol
contracts inherit from BaseAdapter
and rely on this single deadline
value for swap execution via the swap router.
UniswapV2Adapter.sol#L96-L102
The core issue is that deadline
parameter is static and there is no automatic deadline refresh mechanism in the protocol. It is managed through a single owner-controlled variable rather than dynamically calculated per transaction.
Fee conversion relies on custom swap paths configured via configureAssetCustomSwapPath
. Each hop in the conversion process uses the same static deadline
. Keeper operations for fee conversion can fail if deadline expires. This creates a dependency on active management that could affect system availability.
Keeper operations to convert accumulated fees to WETH
may fail due to expired deadline
Manual Review
Implement automatic deadline calculation in BaseAdapter
and use it while performing multi dex swaps:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.