Token Fleet

Fractional Ownership

6.1 Deal::cancel uses totalSupply instead of totalAssets to verify fundraising target

Each deal has two deadlines: (a) a fundraising deadline; and, (b) a closing deadline. Users can cancel a deal if either deadline is not met.

function cancel() external {
    DealStorage storage $ = _getDealStorage();
    _onlyStatus($, STATUS.RAISING_FUNDS);

    if (totalSupply() < $.target) {
        if (block.timestamp <= $.fundraisingDeadline) {
            revert FundraisingDeadlineNotReached();
        }
    } else {
        if (block.timestamp <= $.dealDeadline) {
            revert DealDeadlineNotReached();
        }
    }
    $.status = STATUS.CANCELLED;
    emit DealCancelled();
}

The issue arises in how the target is checked. It incorrectly relies on totalSupply instead of totalAssets. Given that the ratio between the asset and the supply token is not 1:1 and instead linear (for example, a malicious user can intentionally fund the Deal contract with the assets directly through a transfer), the usage of totalSupply is incorrect.

Recommendation

Modify the mentioned check to use totalAssets() instead of totalSupply():

function cancel() external {
    DealStorage storage $ = _getDealStorage();
    _onlyStatus($, STATUS.RAISING_FUNDS);
-   if (totalSupply() < $.target) {
+   if (totalAssets() < $.target) {
        if (block.timestamp <= $.fundraisingDeadline) {
            revert FundraisingDeadlineNotReached();
        }
    } else {
        if (block.timestamp <= $.dealDeadline) {
            revert DealDeadlineNotReached();
        }
    }
    $.status = STATUS.CANCELLED;
    emit DealCancelled();
}

Resolution

Fixed in commit 2d447e0

6.2 Inconsistent update of lastUpdate

Users who deposit funds into deals are entitled to proportional rewards. They claim these rewards by calling Deal::claim, which updates lastUpdate[user] to ensure the claimed portion is excluded from future claims:

function _claim(DealStorage storage $, address user, address receiver) internal returns (uint256) {
    uint256 assets = reward(user);

==>    $.lastUpdate[user] = $.totalIncome;

    if (assets > 0) {
        USDC.safeTransfer(receiver, assets);
    }

    emit Claimed(user, receiver, assets);
    return assets;
}

function reward(address user) public view returns (uint256) {
    DealStorage storage $ = _getDealStorage();
    uint256 shares = balanceOf(user);
    return Math.mulDiv(shares, $.totalIncome - $.lastUpdate[user], totalSupply(), Math.Rounding.Floor);
}

However, a rounding issue can cause the claimable assets to be zero, despite updating lastUpdate[user]. This results in the system marking the user as having claimed their income when they actually received nothing.

Consider the following example:

• The total assets deposited into the deal are 5M USDC, and the total supply is approximately 3M shares;
• Bob deposits 1.6K USDC, receiving 1K shares;
• 2.5K USDC is added to the deal contract as income;
• Bob calls claim to receive his share of the income. The reward function computes: 1K×2.5K / 3M = 0;
• Since assets is 0, Bob receives no rewards, but lastUpdate[user] is still updated, preventing him from claiming his rightful share in future distributions;

Recommendation

Update lastUpdate[user] only when the calculated rewards are greater than zero:

function _claim(DealStorage storage $, address user, address receiver) internal returns (uint256) {
    uint256 assets = reward(user);
-   $.lastUpdate[user] = $.totalIncome;
    if (assets > 0) {
+       $.lastUpdate[user] = $.totalIncome;
        USDC.safeTransfer(receiver, assets);
    }
    emit Claimed(user, receiver, assets);
    return assets;
}

Resolution

Fixed in commits 4b322a8 and 4d82b78

6.3 Referral tokens can be permanently locked for portfolio owners without referrers

When raising funds for a deal via Deal::deposit, the DealManager::registerDeposit function is invoked. This function tracks the deposited amount for each deal to account for referral rewards:

function registerDeposit(uint256 assets, address receiver) external {
    DealManagerStorage storage $ = _getDealManagerStorage();

    PortfolioRegistry registry = PortfolioRegistry($.portfolioRegistry);
    address owner = registry.onlyWhitelistedPortfolio(uint256(uint160(receiver)));
==> address referrer = registry.referrer(owner);
    $.deals[msg.sender].deposits += assets;
==>    $.deals[msg.sender].referralDeposits[referrer] += assets;
}

Later, users can call claimReferralRewards to claim their referral rewards, which are distributed proportionally:

function _referralRewards(DealManagerStorage storage $, address deal, address user)
    internal
    view
    returns (uint256)
{
    DealData storage dealData = $.deals[deal];
    return Math.mulDiv(
        dealData.referralDeposits[user],
        dealData.rewards - dealData.lastRewardClaim[user],
        dealData.deposits,
        Math.Rounding.Floor
    );
}

However, some portfolio owners may not have a referrer, causing registry.referrer(owner); to return the zero address. In such cases, referral rewards are permanently locked to the zero address.

Recommendation

Modify registerDeposit to update referralDeposits only when a valid referrer exists:

function registerDeposit(uint256 assets, address receiver) external {
    DealManagerStorage storage $ = _getDealManagerStorage();
    PortfolioRegistry registry = PortfolioRegistry($.portfolioRegistry);
    address owner = registry.onlyWhitelistedPortfolio(uint256(uint160(receiver)));
    address referrer = registry.referrer(owner);
    $.deals[msg.sender].deposits += assets;
-   $.deals[msg.sender].referralDeposits[referrer] += assets;
+   if (referrer != address(0)) $.deals[msg.sender].referralDeposits[referrer] += assets;
}

Resolution

At the moment, all users need to have a referrer when they get whitelisted, but there is no check enforcing that the referrer is not 0x0. However, only the owner or the whitelistSigner can make that mistake, and we treat them as trustworthy.

6.4 Deal::closeDeal does not check dealDealine

Each deal has two deadlines: (a) a fundraising deadline and (b) a closing deadline. Users can cancel a deal if either deadline is not met. After successful fundraising, the deal manager calls Deal::closeDeal to transition the deal to the next phase. However, the function does not check whether the dealDeadline has already passed:

function closeDeal(address dealer) external {
    DealStorage storage $ = _getDealStorage();
    _onlyDealManagerOwner($, _msgSender());
    _onlyStatus($, STATUS.RAISING_FUNDS);
    _nonZero(dealer);

    if (totalAssets() < $.target) {
        revert TargetNotMet();
    }

    uint256 treasuryFee = $.treasuryFee;
    uint256 insuranceAmount = $.insurance;
    uint256 dealAssets = totalAssets() - insuranceAmount - treasuryFee;

    // Start deal
    $.status = STATUS.IN_PROGRESS;

    USDC.approve(address($.dealManager), treasuryFee);
    $.dealManager.processFee(treasuryFee);
    USDC.safeTransfer(dealer, dealAssets);
    USDC.safeTransfer(address($.insuranceVault), $.insurance);

    emit DealClosed(dealer);
}

While the cancelDeal function allows users to cancel an expired deal and we expect them to cancel deals closely after their deadline, the closeDeal function should still validate the dealDeadline to prevent unintended deal progression past the allowed timeframe.

Recommendation

Add a check in closeDeal to check for the deal’s deadline

Resolution

Deadlines are meant as a mechanism for users to recover their assets if there are delays in executions. Given that, if there are delays and no one cancels, we are fine with closing the deal anyway, as it just means users did not want to cancel. Deadline is a safety mechanism for the user, not for the deal breaker for our processes.

6.5 Portfolio contract does not expose approve function for asset transfers to Deal contract

Users are meant to interact with deal contracts through their portfolios. For instance, portfolios can interact with the Deal contract to deposit the underlying assets. However, the issue is that depositing/minting assets on the Deal contract requires transfer approval of the asset, and the Portfolio contract does not expose an approve function to grant spending allowances to the Deal contract, which leads to transactions reverts. The current implementation of callDeal allows a workaround of this as it performs low-level calls to any address and not necessarily the Deal contract, in which the portfolio owners can leverage this function to interact with the underlying asset to approve for the deal contract.

function _call(address deal, bytes calldata data, address rewardsReceiver) internal returns (bytes memory) {
    (bool success, bytes memory result) = address(deal).call(data);
    if (!success) {
        assembly {
            revert(add(0x20, mload(0)), mload(0))
        }
    }
    _claimRewards(rewardsReceiver);
    return result;
}

However, this is not the intended behavior of the function.

Recommendation

Consider exposing a function to approve a token to be spent by a deal address

Resolution

It may be a nice-to-have, but a workaround exists using callDeal, and we may stick with this approach.