6.1 Incorrect configuration of token time discount on Arbitrum
The xRenzoDepositNativeBridge contract implements a time-based discount mechanism through the tokenTimeDiscountBasisPoints mapping to account for the time when funds do not generate yield during the L2 to L1 bridging period.
When users deposit funds on L2, there's a time delay before these funds reach L1 and generate yield in the Renzo Protocol. To account for this period of missed yield generation, a discount is applied to the effective value of the deposited tokens (users receive less ezETH than they would if depositing directly on L1).
While this value is correctly configured for tokens on the Base L2 network (9 basis points for native ETH), it is incorrectly set to 0 on Arbitrum:
# @audit-info: Base L2 (correct configuration - 9 basis points)
$ cast call 0x766A4df76Cb091C41De22F75b6BD6733fb730357 \
"tokenTimeDiscountBasisPoints(address)(uint)" \
0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE \
--rpc-url https://base.llamarpc.com
9
# @audit-info: Arbitrum (incorrect configuration - 0 basis points)
$ cast call 0x2EfA125B4fcD5B082a4233BA55b53FeB2Fb4Ff33 \
"tokenTimeDiscountBasisPoints(address)(uint)" \
0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE \
--rpc-url https://1rpc.io/arb
0
With the discount set to 0 on Arbitrum, users depositing on this L2 do not have their tokens appropriately discounted for the bridging delay period. This results in Arbitrum users receiving more favorable exchange rates, leading to a slight economic advantage compared to users on other L2 chains.
Recommendation
Consider updating the time discount values on Arbitrum by calling the updateTokenTimeDiscount(...) function.
Resolution
Configured with the correct value (9 bps) on arbitrum.
6.2 Incorrect handling of WETH in the sweep(...) function
There's an inconsistency in how the xRenzoDepositNativeBridge contract handles WETH tokens between the deposit(...) and sweep(...) functions. In the deposit(...) function, WETH is unwrapped to native ETH before the deposit begins:
function deposit(
IERC20 _token,
uint256 _amountIn,
// ...
) external nonReentrant returns (uint256) {
// ...
// @audit If the token is WETH, unwrap to ETH.
if (_token == IERC20(address(weth))) {
weth.withdraw(_amountIn);
}
// @audit ETH will be deposited.
return _deposit(...);
}
The above code ensures that only native ETH is bridged to L1, and WETH tokens can only be bridged to L1 after unwrapping.
However, the sweep(...) function lacks similar handling for WETH. Even though wETH cannot be bridged to L1 directly, the value of the valueTransferBridges mapping for the WETH token is set to EthArbValueTransfer contract address. The same contract is also used for bridging native ETH deposits to L1 and is only designed to handle native ETH, not ERC20 tokens such as wETH. If a user donates WETH tokens to the xRenzoDepositNativeBridge and calls the sweep(...) function with the wETH address, the following will happen:
xRenzoDepositNativeBridge approves WETH to the bridge, but the transferRemote(...) function of the EthArbValueTransfer contract doesn't use this approval;- WETH tokens will remain in the
xRenzoDepositNativeBridge contract; - The function will emit a
BridgeSwept event with misleading information, suggesting funds were bridged when they were not; - Multiple calls to this function will unnecessarily increase the allowance to the bridge contract;
Recommendation
Consider setting WETH address in the valueTransferBridges mapping to the zero address since WETH shouldn't be bridged.
6.3 Incorrect oracle configuration for wstETH token on Base
In the xRenzoDepositNativeBridge contract, price oracles determine the ETH value of deposited collateral tokens. For wstETH (wrapped staked ETH), the oracle should return the wstETH/stETH conversion rate, as wstETH will be unwrapped to stETH when bridged to L1 before being deposited into the Renzo protocol.
This conversion is deterministic and handled by smart contract logic rather than being subject to market fluctuations. On Arbitrum, the oracle is correctly configured to use this conversion rate. However, on Base, the oracle is incorrectly configured to return the wstETH/ETH market rate:
# Get wstETH oracle address from `xRenzoDepositNativeBridge` on Base:
$ cast call 0x766A4df76Cb091C41De22F75b6BD6733fb730357 \
"tokenOracleLookup(address)(address)" \
0xc1cba3fcea344f92d9239c08c0568f6f2f0ee452 \
--rpc-url https://base.llamarpc.com
0x43a5C292A453A3bF3606fa856197f09D7B74251a
# Get Chainlink Oracle description
$ cast call 0x43a5C292A453A3bF3606fa856197f09D7B74251a \
"description()(string)" \
--rpc-url https://base.llamarpc.com
"WSTETH / ETH"
# Get Chainlink Oracle wstETH/ETH rate
$ cast call 0x43a5C292A453A3bF3606fa856197f09D7B74251a \
"latestAnswer()(uint)" \
--rpc-url https://base.llamarpc.com
1197860113406258300
By comparison, the Arbitrum wstETH price is 1199433727364042426 wei, which is slightly more advantageous.
The result is that users depositing wstETH on Base receive slightly less xezETH than users depositing the same amount of wstETH on Arbitrum.
Recommendation
Consider updating the price oracle for wstETH on Base to use the wstETH/stETH exchange rate.
Resolution
wstETH oracle have been updated to use wstETH/stETH price from oracle contract at 0xB88BAc61a4Ca37C43a3725912B1f472c9A5bc061.
6.4 The LidoOPValueTransfer contract unnecessarily grants the wstETH allowance to the lidoBridge address
The LidoOPValueTransfer contract is used by the xRenzoDepositNativeBridge contract to bridge the wstETH tokens deposited by users on Base to the Ethereum mainnet. The transferRemote(...) function from the LidoOPValueTransfer contract calls the withdrawTo(...) function from the L2ERC20TokenBridge contract to bridge the wstETH tokens over the OP stack's Native Bridge.
function transferRemote(
// ...
address token,
uint256 amount
) external payable returns (bytes32 transferId) {
// ...
if (token != address(wstETH)) revert InvalidTokenReceived();
// @audit wstETH tokens wait to be bridged in the LidoOPValueTransfer contract.
IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
// @audit-issue The wstETH allowance of the Lido bridge is unnecessarily
// increased. The bridge contract does not utilize the allowance logic.
IERC20(token).safeIncreaseAllowance(address(lidoBridge), amount);
// ...
// @audit The withdrawTo(...) function on the bridge calls the bridgeBurn(...)
// function, which bypasses token allowances.
lidoBridge.withdrawTo(token, l1xRenzoBridge, amount, 100000, extraData);
// ...
}
The withdrawTo(...) function will burn the wstETH tokens from the LidoOPValueTransfer contract and issue the cross-chain message to the Ethereum mainnet. Since the L2ERC20TokenBridge contract has a special minter and burner permissions, it does not require any previous ERC20 allowance to burn the wstETH tokens. The allowance provided to this contract in the transferRemote(...) function will remain unutilized. It can be observed in the current Base deployment that the LidoOPValueTransfer contract currently has 1730e18 wstETH allowance for the L2ERC20TokenBridge contract.
Recommendation
Consider adding additional test cases around sweeping the tokens on Base and after that removing the redundant call to the increaseAllowance(...) function.
Resolution
Redundant call to the increaseAllowance(...) function removed at Code Ref.
6.5 Incorrect comments
The codebase contains several comments which are incorrect. Below is a non-exhaustive list of such code comments:
EthArbValueTransfer.sol: The NatSpec for the 2nd param of the transferRemote(...) function mentions that the token should always be wstETH, while the function handles native Ether only. This is also the case for EthOPValueTransfer.sol;EthArbValueTransfer.sol: In the transferRemote(...) function there is a comment // Do not allow ETH, while the function is supposed to exclusively handle native Ether. This is also the case for EthOPValueTransfer.sol;xRenzoDepositNativeBridge.sol: The NatSpec above the setSupportedToken(...) function doesn't describe the _valueTransferBridge param;HyperlaneSender.sol: The NatSpec comments above the pause(...) and unpause(...) functions are inverted;
Recommendation
To make the code more readable, consider removing or changing the incorrect comments outlined above.
Resolution
Comments fixed at Code Ref.
6.6 Unused events
The codebase contains event declarations that are not utilized by the protocol contracts. The following is a non-exhaustive list of unused events:
xRenzoDepositNativeBridge.sol contains unused BridgeSweeperAddressUpdated event;
Recommendation
Consider removing unused events to keep the code clean and readable.
Resolution
Unused BridgeSweeperAddressUpdated event removed at Code Ref.
