# Silo Finance V2 Audit Report – `xSILO`

**Auditor:** [@zarkk01](https://x.com/zarkk01)
**Date:** 25/5/2025
**Commit Hash:** [1a3c33efd7050d7e1b79808d1c29378b441675dd](https://github.com/silo-finance/silo-contracts-v2/commit/1a3c33efd7050d7e1b79808d1c29378b441675dd)
**Repository:** [silo-contracts-v2](https://github.com/silo-finance/silo-contracts-v2/tree/1a3c33efd7050d7e1b79808d1c29378b441675dd)

## Overview

### xSILO Overview

`xSILO` is a yield-bearing ERC4626 vault designed to manage `SILO` token deposits and distribute rewards transparently. Users deposit `SILO` and receive `xSILO` shares, which accrue rewards passively via the `Stream` smart contract so there is no need for manual claiming. Inspired heavily by Camelot DEX’s [xGRAIL](https://arbiscan.io/address/0x3CAaE25Ee616f2C8E13C74dA0813402eae3F496b) mechanism, `xSILO` introduces a flexible redemption policy: users may either redeem instantly (with a penalty) or initiate a vesting period to receive a more favorable conversion. During this vesting, `xSILO` shares are locked, and users forgo rewards.

### Audit Scope

The audit focused on verifying the security and proper functionality of :
- `XSilo.sol`
- `XRedeemPolicy.sol`
- `XSiloManagement.sol`
- `Stream.sol`
- `SiloToken.sol`

### Disclaimer

This audit is not a guarantee of the absence of vulnerabilities. While every reasonable effort has been made to identify and analyze potential issues, smart contracts carry inherent risk. This is a time, resource and expertise bound effort aimed at identifying as many vulnerabilities as possible within the given constraints.

## Findings

| Severity | Count |
|------------|-------|
| High | 1 |
| Medium | 3 |
| Low | 4 |

### High Severity

#### High-1. Locked `xSILO` Shares Retain Reward Accrual During Vesting
**Location:** [XRedeemPolicy.sol](https://github.com/silo-finance/silo-contracts-v2/blob/1a3c33efd7050d7e1b79808d1c29378b441675dd/x-silo/contracts/modules/XRedeemPolicy.sol)

**Details:**

When a user calls `redeemSilo(xSiloAmount, duration > 0)`, their `xSILO` shares are moved into the vault but remain part of `totalSupply` until `finalizeRedeem`. As a result, those shares keep accruing new rewards throughout the vesting period, without letting these rewards to be distributed to the other depositors until the finalisation of the redemption.

    function redeemSilo(uint256 _xSiloAmountToBurn, uint256 _duration)
        external
        virtual
        nonReentrant
        returns (uint256 siloAmountAfterVesting)
    {
        // ...

        // if redeeming is not immediate, go through vesting process
        if (_duration != 0) {
            // ...

@>            _transferShares(msg.sender, address(this), _xSiloAmountToBurn);
        } else {
            // immediately redeem for SILO
            // ...
        }
    }

The problem is that redeemer is not earning those rewards (since at `finalizeRedeem` the `SILO` amount is fixed), but other depositors are **not** earning them **either** until `finalizeRedeem` gets called.

In order to understand better this issue, consider this example:
- Initial state: 10 xSILO, 100 SILO
- Someone calls `redeemSilo` for 5 xSILO and six months duration
- State: 10 xSILO (5 "locked" + 5 "active"), 100 SILO (50 "locked" + 50 "active")
- New depositor A comes an deposits 100 SILO and gets minted 10 xSILO minted.
- State: 20 xSILO (5 "locked" + 15 "active"), 200 SILO (50 "locked" and 150 "active").
- 600 SILO rewards are getting distributed from `Stream`. Supposedly since depositor A holds 2/3 of the "active" xSILO shares, he must take 2/3 of the SILO rewards (400 SILO).
- However, if depositor A select to `redeemSilo` for 6 months (full) he will burn 10 xSILO shares and he will get 400 SILO (and not 500 SILO = 100 initial deposit + 400 from the rewards).

**Recommendation:**
Remove locked shares from reward‐earning immediately at redemption request. Concretely, in `redeemSilo` when `_duration > 0`:

1. Burn the user’s `xSILO` shares (via `_burnShares`) instead of transferring them into the vault.
2. Store the burned‐share amount in `RedeemInfo`.

On **cancel**, re‐mint those shares back to the user; on **finalize**, simply withdraw against the already‐burned shares. This ensures vesting shares can’t earn any rewards after the request but also these rewards are distributed to the other depositors **real-time**.

---

### Medium Severity

#### Medium-1. Attacker Can Drain All Remaining SILO If The Last Redemption Is Not Full
**Location:** [XSilo.sol](https://github.com/silo-finance/silo-contracts-v2/blob/4f2e4a3829ece0cd4a7f0258e4c062993dd61f6f/x-silo/contracts/XSilo.sol#L53)

**Details:**
When the last honest holder withdraws their entire `xSILO` balance with zero-duration vesting (which applies a 50% redemption ratio), the vault’s `totalSupply` of `xSILO` falls to zero while still holding half of its `SILO` balance. Then, an attacker can steal the remaining `SILO` by repeating deposits of tiny amounts and instant withdrawals.

To understand better the issue, consider this scenario :
1. We have 100e18 xSILO shares and 110e18 SILO.
2. Last withdrawer redeems his whole 100e18 xSILO instant so he gets a half cut and takes 55e18 SILO.
3. So, now we have 0 xSILO shares and 55e18 remaining SILO.
4. Attacker can now deposit and withdraw instantly tiny amounts, in order to take the whole 55e18 SILO rewards out of the vault.

**Recommendation:**
Seed the vault with a non-zero initial `xSILO` supply (like mint a small number of shares to the zero address or owner) so that `totalSupply` never reaches zero.

#### Medium-2. Unclaimed Stream Rewards Lost When Switching to a New Stream
**Location:** [XSiloManagement.sol](https://github.com/silo-finance/silo-contracts-v2/blob/1a3c33efd7050d7e1b79808d1c29378b441675dd/x-silo/contracts/modules/XSiloManagement.sol#L38)

**Details:**
In `XSiloManagement::setStream()`, the contract switches from an existing stream to a new one without first invoking `claimRewards()` on the old stream. Any emission rewards that have accrued but not yet been claimed will remain behind in the old `Stream` contract and become effectively unreachable by the vault. Also, the accounting system of the `XSilo` will be ruined.

    function setStream(IStream _stream) external onlyOwner {
        _setStream(_stream, false);
    }

    function _setStream(IStream _stream, bool _skipBeneficiaryCheck) internal {
        require(stream != _stream, NoChange());
        require(_skipBeneficiaryCheck || _stream.BENEFICIARY() == address(this), NotBeneficiary());

        stream = _stream;
        emit StreamUpdate(_stream);
    }

**Recommendation:**
In `setStream`, always call `stream.claimRewards()` on the existing stream before updating the reference.

#### Medium-3. Instant Redemptions Can Be Sandwiched For Profit
**Location:** [XRedeemPolicy.sol](https://github.com/silo-finance/silo-contracts-v2/blob/develop/x-silo/contracts/modules/XRedeemPolicy.sol)

**Details:**
An attacker can front-run a large “instant” redeem by first depositing, then let the victim’s instant redeem inflate the assets‐per‐share price, and finally do their own instant redeem with only the vesting penalty, locking in a profit. For example:

- Initial state: 100 xSILO shares, 1000 SILO in vault so 10 SILO/xSILO
- Attacker front-runs: deposits 10 SILO and mints 1 xSILO.
- State: 101 xSILO shares, 1010 SILO in vault so still 10 SILO/xSILO
- Victim redeem: instant burns 90 xSILO, receives 450 SILO.
- State: 11 xSILO shares, 560 SILO so ≈50 SILO/xSILO
- Attacker back-runs: instant burn 1 xSILO share for 25 SILO.
- Instant profit for attacker 25-10 SILO = 15 SILO.

**Recommendation:**
Fix not trivial. Blocking instant redemptions and introduce 1 block wait time could solve the issue but will introduce business limits.

---

### Low Severity

#### Low-1. Missing Event Emission in `emergencyWithdraw` Function

The `emergencyWithdraw` function in the `Stream` contract allows the owner to withdraw all reward assets in case of an emergency. However, the function does not emit an event when the withdrawal occurs. Consider adding this event :

+ event EmergencyWithdraw(address indexed recipient, uint256 amount);

#### Low-2. Limited Asset Support in `emergencyWithdraw` Function

The `emergencyWithdraw` function in the `Stream` contract only allows the owner to withdraw the `REWARD_ASSET` tokens in case of an emergency. This limitation could be problematic if other tokens are accidentally sent to the contract, as there would be no way to recover them.

- function emergencyWithdrawToken() external onlyOwner {
+ function emergencyWithdrawToken(address token) external onlyOwner {

#### Low-3. Possible issue in `fundingGap` Calculation in `Stream` contract

The `fundingGap` function calculates the difference between the required tokens for the entire remaining distribution period and the current balance. However, this calculation differs from the actual token requirements for the immediate `pendingRewards` function. The function calculates the gap until the end of the program `(distributionEnd - lastUpdateTimestamp)`, while `pendingRewards` calculates rewards until the current time `(Math.min(block.timestamp, distributionEnd) - lastUpdateTimestamp)`.

    function fundingGap() public view returns (uint256 gap) {
        if (lastUpdateTimestamp >= distributionEnd) return 0;

-        uint256 timeElapsed = distributionEnd - lastUpdateTimestamp;
+        uint256 timeElapsed = Math.min(block.timestamp, distributionEnd) - lastUpdateTimestamp;
        uint256 rewards = timeElapsed * emissionPerSecond;
        uint256 balanceOf = IERC20(REWARD_ASSET).balanceOf(address(this));

        gap = balanceOf >= rewards ? 0 : rewards - balanceOf;
    }

#### Low-4. Incorrect Token Parameter Usage in `XSilo` Constructor

The contract's constructor is using the token's symbol as the first parameter where the name is expected. This is a minor issue that doesn't affect functionality but could lead to confusion in the token's display name. The contract should use the token's name instead of its symbol.

    constructor(address _initialOwner, address _asset, address _stream)
        XSiloManagement(_initialOwner, _stream)
        ERC4626(IERC20(_asset))
@>        ERC20(string.concat("x", TokenHelper.symbol(_asset)), string.concat("x", TokenHelper.symbol(_asset)))
    {}

Gm sir, audit for xSILO is done and the report is ready. Good job happened with interesting issues arissed so, if any clarification is needed, please let me know. Especially for H1, if you need to understand it better. Thank you :)