dApp Security Guidelines: LSD

Threat	Impact
Threat 1: Manipulation of iBERA/BERA Exchange Rate through Mass Deposits and Withdrawals	Medium
Threat 2: Malicious Actor Profit Maximization through Mass Harvesting Before/After Fee Changes	Low
Threat 3: Contamination of the Bribe System through Tokens Susceptible to Malicious Behavior	Low
Threat 4: Reward Imbalance and Centralization Due to Fund Concentration in Specific Validators	Informational

Threat 1: Manipulation of iBERA/BERA Exchange Rate through Mass Deposits and Withdrawals

If an attacker momentarily manipulates the iBERA/BERA exchange rate with a large transaction, they can gain unfair profits while other users suffer losses. This ultimately reduces the protocol's assets and undermines user trust, harming system stability.

Impact

Medium

It is rated as Medium because it can directly affect system stability by reducing protocol assets and undermining trust.

Guideline

• To prevent the settlement of unreflected profits when calculating the exchange rate, a procedure that pre-applies accumulated rewards, similar to the Lido protocol, should be implemented by calling the compound() function before processing deposit/withdrawal transactions.

• To prevent the exchange rate from being distorted when funds flow in directly from external contracts or when internal accounting is not synchronized in real-time₅₇, apply a mechanism for real-time reflection in internal accounting, similar to the Uniswap V2 contract code.

• To prevent the exchange rate from being distorted by a very small deposit when there is no initial liquidity, deposit a minimum stake at the contract deployment stage to prevent zero total supply and zero division issues₅₆.

Best Practice

InfraredBERA.sol

function mint(address receiver) public payable returns (uint256 shares) {
    compound(); // Settle and reflect unrealized profits

    uint256 d = deposits;
    uint256 ts = totalSupply();

    uint256 amount = msg.value;
    // Synchronize external fund inflow by calling the BeaconDeposit contract via the queue function in the InfraredBERADepositor contract
    _deposit(amount);

    // Process at 1:1 during initialization, then proportionally to the deposit ratio
    shares = (d != 0 && ts != 0) ? (ts * amount) / d : amount;
    // Handle exceptions during initialization attempts
    if (shares == 0) revert Errors.InvalidShares();
    _mint(receiver, shares);

    emit Mint(receiver, amount, shares);
}

---

Threat 2: Malicious Actor Profit Maximization through Mass Harvesting Before/After Fee Changes

If a malicious actor exploits the timing of a protocol fee change to harvest a large amount of rewards just before or after the change, they can distort the fair reward distribution system, gaining unfair profits for themselves while causing losses to other users or the protocol's treasury. This ultimately undermines the fairness and trustworthiness of the system.

Impact

Low

Exploiting the timing of fee changes to harvest large rewards can lead to some users gaining unfair profits and causing losses to other users or the protocol's treasury. However, the impact on the overall stability or security of the system is limited, so it is rated Low.

Guideline

• To settle existing rewards before a fee change, automatically distribute all unsettled rewards at the first step of the smart contract function execution by running the compound() function before processing deposit/withdrawal transactions, similar to the Lido protocol, to preemptively block reward theft.

• To prevent an external contract from exploiting the system by executing a fee change and reward harvesting function simultaneously, minimize permissions to restrict unauthorized execution and do not allow transactions that execute both functions at the same time₅₄.

Best Practice

InfraredV1_2.sol

function updateFee(ConfigTypes.FeeType _t, uint256 _fee)
    external
    onlyGovernor // Restrict fee change authority
{
    // Settle for the previous fee
    uint256 prevFee = fees(uint256(_t));
    _rewardsStorage().updateFee(_t, _fee);
    emit FeeUpdated(msg.sender, _t, prevFee, _fee);
}

InfraredV1_5.sol

function claimExternalVaultRewards(address _asset, address user)
        external
        whenNotPaused
    {
        // Limit reward harvesting to Keeper role
        address sender = msg.sender;
        if (!hasRole(KEEPER_ROLE, sender) && sender != user) {
            revert Errors.Unauthorized(sender);
        }
        // ... (omitted) ...
    }

---

Threat 3: Contamination of the Bribe System through Tokens Susceptible to Malicious Behavior

Using tokens with the potential for malicious behavior as reward tokens in the Bribe system undermines the reliability and fairness of the Bribe system. This ultimately weakens the competitiveness of honest protocols and disrupts the healthy incentive flow of the ecosystem.

Impact

Low

The system's reliability and fairness are undermined, which can weaken the competitiveness of honest protocols. However, the damage is limited to incentive distortion and operational issues, so it is rated Low.

Guideline

• Regarding the whitelist of reward tokens used in the Bribe system, include a verification process similar to the Lido protocol's case to prevent system contamination and loss of trust.

• To prevent an attacker from disrupting the system by attempting multiple small bribes, set a minimum bribe amount limit₅₉ to prevent abuse. > [Source: Blockchain Bribing Attacks and the Efficacy of Counterincentives | page 11 ~ 12]

• Since granting excessive authority to the BribeCollector can lead to misuse, apply the principle of least privilege. For the use of this contract, as in the case of Uniswap, apply a 2-day timelock period.

  $\scriptsize \text{Execute Time} = \text{Request Time} + \text{2 days} \text{ (UniswapV2 Example)}$

Best Practice

RewardLib.sol

function harvestBribes(
    RewardsStorage storage $,
    address collector,
    address[] memory _tokens,
    bool[] memory whitelisted
) external returns (address[] memory tokens, uint256[] memory amounts) {
    uint256 len = _tokens.length;
    amounts = new uint256[](len);
    tokens = new address[](len);

    for (uint256 i = 0; i < len; i++) {
        // Verify if the token is whitelisted
        if (!whitelisted[i]) continue;
        // ... (omitted) ...
    }
}

BribeCollectorV1_3.sol

function claimFees(
        address _recipient,
        address[] calldata _feeTokens,
        uint256[] calldata _feeAmounts
    ) external onlyKeeper // Limit reward collection execution authority to Keeper

---

Threat 4: Reward Imbalance and Centralization Due to Fund Concentration in Specific Validators

If funds are excessively concentrated in a few validators, they will monopolize most of the rewards, discouraging other validators from participating and making it difficult for new ones to enter. This ultimately leads to the concentration of decision-making power in the network in the hands of a few, undermining decentralization and harming the overall stability and fairness of the system.

Impact

Informational

Most of the rewards could be monopolized by a few validators, and the network's decision-making power could become concentrated, undermining decentralization and system fairness. However, this is considered a structural and operational issue that affects network decentralization and participation incentives rather than a direct security threat, so it is rated Informational.

Guideline

• To address the concentration of funds in large validators, an issue raised in major PoS chains like Ethereum and Solana, prevent reward imbalance and centralization by setting a maximum staking limit₆₀ per validator.

• To prevent network instability caused by a validator's long-term abnormal behavior, it is necessary to introduce a real-time status tracking₂₀ and automatic forced exit system.

• To prevent the possibility of centralization and reward imbalance if restaking or new delegations are concentrated on a few validators, apply a delegation policy that automatically distributes₆₁ funds to multiple validators.

• To prevent the weakening of network decentralization and liquidity due to low user participation, provide activity rewards similar to Curve Finance's LP token rewards to promote participation and fund distribution.

Best Practice

InfraredBERADepositor.sol

function execute(bytes calldata pubkey, uint256 amount)
    external
    onlyKeeper
{
    // ... (omitted) ...
    address withdrawor = IInfraredBERA(InfraredBERA).withdrawor();
    // Prioritize processing funds from force-exited validators
    if (withdrawor.balance >= InfraredBERAConstants.INITIAL_DEPOSIT) {
        revert Errors.HandleForceExitsBeforeDeposits();
    }
    // Verify that current validator balance + deposit amount <= max staking limit
    if (
        IInfraredBERA(InfraredBERA).stakes(pubkey) + amount
            > InfraredBERAConstants.MAX_EFFECTIVE_BALANCE
    ) {
        revert Errors.ExceedsMaxEffectiveBalance();
    }

    address operatorBeacon =
        IBeaconDeposit(DEPOSIT_CONTRACT).getOperator(pubkey);
    address operator = IInfraredBERA(InfraredBERA).infrared();
    if (operatorBeacon != address(0)) {
        if (operatorBeacon != operator) {
            revert Errors.UnauthorizedOperator();
        }
        if (!IInfraredBERA(InfraredBERA).staked(pubkey)) {
            revert Errors.OperatorAlreadySet();
        }
        operator = address(0);
    }

    // ... (omitted) ...

    emit Execute(pubkey, amount);
}