BTCFi Lending Vault - Coredao

In LendingVaultV2::captureReward(), when operators skip multiple rounds and current round has zero rewards, the fallback logic copies from uninitialized mapping slots instead of finding the last valid reward state.

if (accPerShareLog[lastRoundClaim] == 0) {
    accPerShareLog[lastRoundClaim] = accPerShareLog[lastRoundClaim - 1];
}

Attack Scenario:

• Operator skips rounds 101-104, leaving accPerShareLog[104] = 0

• Attacker observes this state and stakes a large amount when accPerShareLog[lastRoundClaim] = 0

• Next round (105) generates rewards, setting accPerShareLog[105] = X

• Attacker receives reward calculation of (X - 0) * large_stake, effectively claiming rewards from round 0 despite only staking one round

• Legitimate long-term stakers receive diluted rewards due to the attacker's disproportionate share

This enables attackers to manipulate reward calculations by staking during zero-state periods.

Implement state tracking to maintain historical continuity across consecutive zero-reward rounds:

uint256 public lastValidAccPerShare;

function captureReward(address swapHelper) external onlyOperator whenNotPaused {
    // ... existing reward claiming logic ...

    if (totalScaledBalance > 0) {
        if (reward > 0) {
            // Case 1: Normal rewards - calculate new accumulation
            uint256 rewardPerShare = (postScaledBalance - preScaledBalance) * 1 ether / totalScaledBalance;
            lastValidAccPerShare += rewardPerShare;
            accPerShareLog[lastRoundClaim] = lastValidAccPerShare;
        } else {
            // Case 2: Zero rewards - inherit last valid state
            accPerShareLog[lastRoundClaim] = lastValidAccPerShare;
        }
    }
}

SOLVED: The suggested mitigation was implemented.

LendingVaultV2::claimRevenue() performs pool withdrawals to cover revenue claims without validating the vault's health factor afterwards.

pool.withdraw(address(stakeToken), withdrawAmount, address(this));

This can lead to liquidation risk as withdrawing collateral reduces the vault's health factor below safe thresholds.

Add health factor validation after pool withdrawal:

pool.withdraw(address(stakeToken), withdrawAmount, address(this));
(,,,,, uint256 currentHealthFactor) = pool.getUserAccountData(address(this));
require(currentHealthFactor >= MINIMUM_HEALTH_FACTOR, "Health factor too low");

SOLVED: The suggested mitigation was implemented.

LendingVaultV2::withdraw() and MergeMarketplaceStrategyV2::reInvest() make external calls that don't check return values or rely on implicit revert behavior, which may not work consistently across all implementations.

File: MergeMarketplaceStrategyV2

IMarketplace(marketplace).withdrawCoreProxy(withdrawData);
IMarketplace(marketplace).stakeCoreProxy{value: stakeValue}(stakeData);

File: LendingVaultV2

pool.withdraw(address(stakeToken), amount, address(this));

Wrap external calls in try-catch blocks or verify that the called contracts properly revert on failure.

RISK ACCEPTED: The b14g team accepted the risk related to this finding.

The LendingVaultV2 contract grants excessive privileges to a single operator address without multi-signature requirements or timelock mechanisms. The operator can perform critical operations like borrowing funds (lendingInvest), investing in strategies (coreInvest), and claiming rewards (captureReward) without additional oversight, creating centralization risks.

Risk Scenarios:

• Compromised Operator: Single point of failure if operator key is compromised

• Malicious Operator: Could drain vault through excessive borrowing or malicious strategy investments

• Operational Risk: No backup mechanism if operator becomes unavailable

Implement multi-signature requirements or timelock mechanisms for critical operator functions.

SOLVED: The b14g team agreed to use multisig for operator role.

Admin functions in WBTCSwap::setSlippage() and WBTCSwap::setDeadline() don't emit events for parameter changes, reducing transparency and making it difficult to track configuration updates.

Add event emissions to all admin parameter change functions for transparency.

ACKNOWLEDGED: This finding was acknowledged.

WBTCSwap, LendingVaultV2, and MergeMarketplaceStrategyV2 use hardcoded addresses for tokens, routers, and oracles, making them inflexible for network upgrades, migrations, or multi-chain deployments.

address public constant WBTC = 0x5832f53d147b3d6Cd4578B9CBD62425C7ea9d0Bd;
address public constant WCORE = 0x191E94fa59739e188dcE837F7f6978d84727AD01;

Make critical addresses configurable through admin functions with appropriate access controls and validation checks:

function setTokenAddresses(address _wbtc, address _wcore) external onlyOwner {
    require(_wbtc != address(0) && _wcore != address(0), "Invalid addresses");
    WBTC = _wbtc;
    WCORE = _wcore;
    emit AddressesUpdated(_wbtc, _wcore);
}

ACKNOWLEDGED: This finding was acknowledged.