sherlock-audit / 2023-04-unitasprotocol

Unitas Protocol contest details

• Join Sherlock Discord
• Submit findings using the issue page in your private contest repo (label issues as med or high)
• Read for more details

Q&A

Q: On what chains are the smart contracts going to be deployed?

Ethreum mainnet

---

Q: Which ERC20 tokens do you expect will interact with the smart contracts?

USDT

---

Q: Which ERC721 tokens do you expect will interact with the smart contracts?

None

---

Q: Which ERC777 tokens do you expect will interact with the smart contracts?

None

---

Q: Are there any FEE-ON-TRANSFER tokens interacting with the smart contracts?

No

---

Q: Are there any REBASING tokens interacting with the smart contracts?

No

---

Q: Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED?

TRUSTED

---

Q: Is the admin/owner of the protocol/contracts TRUSTED or RESTRICTED?

TRUSTED

---

Q: Are there any additional protocol roles? If yes, please explain in detail:

• MINTER_ROLE (Unitas contract)
• TIMELOCK_ROLE (OZ Contract)
  • TIMELOCK's admin == (GOVERNOR_ROLE)
• FEEDER_ROLE (EOA)
• GOVERNOR_ROLE (Multisig wallet)
• GUARDIAN_ROLE (Multisig wallet)
• PORTFOLIO_ROLE (Multisig wallet)
• WITHDRAWER_ROLE (Unitas contract)
• ProxyAdmin (OZ Contract)
• ProxyAdmin's admin (GUARDIAN_ROLE)

---

Q: Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of?

None

---

Q: Please list any known issues/acceptable risks that should not result in a valid finding.

1. OpenZeppelin #4154 Fix TransparentUpgradeableProxy's transparency

   • Risk: very low.

2. In Xoracle, there is no milliseconds check, so potential can bypass the require(prev_timestamp < timestamp, "Outdated timestamp"); and update the price on the same date. If the frontend fetches the timestamp of price updates, it will only lead to confusion.

   • Risk: very low.

3. When users are performing a swap, if they encounter an Oracle price update within the same block, they may exchange at a different price than originally expected. Our Oracle price feeder does not have a fixed update time, but the chances of encountering this situation are very low. We plan to implement checks in phase 2 to address this.

   • Risk: very low.

---

Q: Please provide links to previous audits (if any).

NA

---

Q: Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, input validation expectations, etc)?

Oracle feeder

---

Q: In case of external protocol integrations, are the risks of external contracts pausing or executing an emergency withdrawal acceptable? If not, Watsons will submit issues related to these situations that can harm your protocol's functionality.

No external contracts integration

---

Audit scope

Unitas-Protocol @ 9ef6847c5437bfe5e178355f36f9ebb19c1d0468

• Unitas-Protocol/src/ERC20Token.sol
• Unitas-Protocol/src/InsurancePool.sol
• Unitas-Protocol/src/PoolBalances.sol
• Unitas-Protocol/src/SwapFunctions.sol
• Unitas-Protocol/src/TimelockController.sol
• Unitas-Protocol/src/TokenManager.sol
• Unitas-Protocol/src/TokenPairs.sol
• Unitas-Protocol/src/TypeTokens.sol
• Unitas-Protocol/src/Unitas.sol
• Unitas-Protocol/src/UnitasProxy.sol
• Unitas-Protocol/src/UnitasProxyAdmin.sol
• Unitas-Protocol/src/XOracle.sol
• Unitas-Protocol/src/interfaces/IERC20Token.sol
• Unitas-Protocol/src/interfaces/IInsurancePool.sol
• Unitas-Protocol/src/interfaces/IOracle.sol
• Unitas-Protocol/src/interfaces/ISwapFunctions.sol
• Unitas-Protocol/src/interfaces/ITokenManager.sol
• Unitas-Protocol/src/interfaces/ITokenPairs.sol
• Unitas-Protocol/src/interfaces/ITypeTokens.sol
• Unitas-Protocol/src/interfaces/IUnitas.sol
• Unitas-Protocol/src/utils/AddressUtils.sol
• Unitas-Protocol/src/utils/Errors.sol
• Unitas-Protocol/src/utils/ScalingUtils.sol

2023-04-unitasprotocol's Issues

No slippage protection and deadline check when swapping

Summary

No slippage protection and deadline check when swapping

Vulnerability Detail

the swap function has no slippage protection and deadline check

    /**
     * @notice Swaps tokens
     * @param tokenIn The address of the token to be spent
     * @param tokenOut The address of the token to be obtained
     * @param amountType The type of the amount
     * @param amount When `amountType` is `In`, it's the number of `tokenIn` that the user wants to spend.
     *               When `amountType` is `Out`, it's the number of `tokenOut` that the user wants to obtain.
     * @return amountIn The amount of `tokenIn` spent
     * @return amountOut The amount of `tokenOut` obtained
     */
    function swap(address tokenIn, address tokenOut, AmountType amountType, uint256 amount)
        external
        whenNotPaused
        nonReentrant
        returns (uint256 amountIn, uint256 amountOut)
    {
        IERC20Token feeToken;
        uint256 fee;
        uint24 feeNumerator;
        uint256 price;
        ITokenManager.PairConfig memory pair = tokenManager.getPair(tokenIn, tokenOut);

        // @audit
        // slippage
        (amountIn, amountOut, feeToken, fee, feeNumerator, price) = _getSwapResult(pair, tokenIn, tokenOut, amountType, amount);

        _require(IERC20(tokenIn).balanceOf(msg.sender) >= amountIn, Errors.BALANCE_INSUFFICIENT);

        _swapIn(tokenIn, msg.sender, amountIn);

        _swapOut(tokenOut, msg.sender, amountOut);

        if (fee > 0) {
            address feeReceiver = surplusPool;
            feeToken.mint(feeReceiver, fee);
            emit SwapFeeSent(address(feeToken), feeReceiver, fee);
        }

        _checkReserveRatio(tokenOut == pair.baseToken ? pair.buyReserveRatioThreshold : pair.sellReserveRatioThreshold);

        emit Swapped(tokenIn, tokenOut, msg.sender, amountIn, amountOut, address(feeToken), fee, feeNumerator, price);
    }

no slippage protection means the user is subject to frontrunning

_swapIn(tokenIn, msg.sender, amountIn);

_swapOut(tokenOut, msg.sender, amountOut);

no deadline check means the transaction can be pending in the mempool for a very long time and the oracle is updated multiple times and the price / exchange already changes and combing with there is no slippage control, user can receive very suboptimal amount

Impact

No slippage protection and deadline check when swapping

Code Snippet

2023-04-unitasprotocol/Unitas-Protocol/src/Unitas.sol

Line 208 in d532842

function swap(address tokenIn, address tokenOut, AmountType amountType, uint256 amount)

Tool used

Manual Review

Recommendation

Add minAmount receive and deadline check just like other AMM pool