Lybra Finance

1 Executive Summary

This report presents the results of our engagement with Lybra Finance Team to review the Lybra Protocol.

The review was conducted over four and a half weeks, from July 10, 2023 to Aug 9, 2023, by George Kobakhidze and Sergii Kravchenko. A total of 7 person-weeks were spent.

The Lybra Protocol is a DeFi system that focuses on collateral-based stablecoin lending and management. A particular feature of this protocol is its focus on the stablecoin holders and Liquid Staking Derivative tokens for Ethereum staking as collateral. The resulting product of the system is an interest-bearing rebasing stablecoin called EUSD. With the V2 version of the protocol, which is what is in the scope of this audit, the system introduces more LSD tokens along with Lido’s stETH from the first version such as those from RocketPool and Binance. Lybra Protocol V2 also introduces PeUSD a non-rebasing USD stablecoin that features LayerZero’s Omnichain capabilities. PeUSD may be minted with EUSD or with non-rebasing LSD tokens that are introduced in the V2. PeUSD may also accommodate easier integrations with other DeFi protocols as the rebasing EUSD may cause accounting issues.

The repository is organized and the code is written well with plentiful comments and elegant design choices. As Lybra Protocol is a complex system, users should expect to understand and digest a multitude of parameters, many of which may be changed by governance and many of which are hardcoded and may not.

At the end of the audit, the engagement was extended to verify fixes and some other code changes made during the audit.

2 Scope

Our review focused on the commit hash 48c98f288c77f57fa17e87964394f98e1e2ee636. The list of files in scope can be found in the Appendix.

Following the audit, all commits between 48c98f288c77f57fa17e87964394f98e1e2ee636 and 90285107de8a6754954c303cd69d97b5fdb4e248 were reviewed as well.

2.1 Objectives

Together with the Lybra Finance team, we identified the following priorities for our review:

1. Correctness of the implementation, consistent with the intended functionality and without unintended edge cases.
2. Identify known vulnerabilities particular to smart contract systems, as outlined in our Smart Contract Best Practices, and the Smart Contract Weakness Classification Registry.
3. Review the logic of all vault types and the implementation of their core functions such as depositing, borrowing, withdrawing, liquidating, redeeming, and distributing excess income through interest realization for rebase assets.
4. The Governance checks for proposals and voting are not bypassable by a malicious actor.
5. Permission checks in the LybraConfigurator contract work as intended.
6. The rewards staking, mining, and distribution logic work as intended in contracts such as ProtocolRewardsPool and EUSDMiningIncentives.

3 System Overview

Lybra is an interest-bearing stablecoin protocol backed by different LSD (liquid staking derivatives).

3.1 Stablecoins

• EUSD - an ERC-20 rebase token representing a yield-bearing stablecoin.
• peUSD - a regular ERC-20 stablecoin that can be converted from EUSD. The peUSD token doesn’t earn any interest, but users that convert EUSD will still be getting interest from their deposited EUSD tokens. Also has an LayerZero Omnichain component making it a OFTV2 token as well for multi-chain capabilities.

3.2 Vaults

There are two types of vaults in the protocol. One of them takes a LSD as collateral and mints EUSD (LybraEUSDVaultBase), and the other type mints peUSD (LybraPeUSDVaultBase). The following vaults are implemented:

• LybraStETHVault - takes stETH (staked ETH by Lido) as collateral and mints EUSD.
• LybraWstETHVault - takes WstETH (wrapped stETH) as collateral and mints peUSD.
• LybraRETHVault - takes RETH(Rocket Pool ETH) as collateral and mints peUSD.
• LybraWbETHVault - takes WBETH(Wrapped Binance ETH) as collateral and mints peUSD.

The main difference between peUSD and EUSD vaults is that the collateral of the EUSD vault is a rebase token. So for peUSD vaults, every depositor’s collateral value is supposed to grow over time due to ETH staking rewards. Unlike that, every individual stETH collateral deposit isn’t directly growing due to its rebase nature. So the excess of stETH tokens in the vault contract is sold for EUSD to anyone willing to buy it. The shares of the profit are burnt in favor of every EUSD holder, which increases their balances due to the token’s rebase nature.

3.3 Mining

The system has two reward pools that are forked from Synthetix StakingRewards with some changes made:

• EUSDMiningIncentives - a staking contract that rewards borrowers of EUSD and peUSD. The users are getting rewards in the form of esLBR (escrowed LBR tokens).
• esLBRBoost - a contract allowing users to lock their LBR in exchange for boosted rewards in EUSDMiningIncentives.
• ProtocolRewardsPool - a staking contract that rewards holders of esLBR with peUSD or other external stablecoins.

3.4 System Diagram

Please find below a non-exhaustive diagram of the Lybra Protocol system that focuses on calls and data flow within the system.

1. Configurator - Miner.
   • Reward logic such as notifyRewardAmount and refreshReward.
2. Configurator - Governance.
   • Access control checks like checkRole and checkOnlyRole.
3. Configurator - Vaults.
   • Vault information such as getVaultType.
4. Configurator - Tokens.
   • Token transfer logic that happens during reward distribution such as approve and safeTransfer, as well as convertToPeUSD.
5. Governance - Tokens.
   • Voting logic, specifically getPastVotes from esLBR tokens.
6. Vaults - Configurator.
   • Parameter retrievals such as getEUSDAddress, getPeUSDAddress, isRedemptionProvider, mintVaultMaxSupply, and others for successful vault management.
   • Reward distribution logic through calls like refreshMintReward and distributeReward.
7. Vaults - Tokens.
   • Token administration logic such as transfer and allowance calls but also highly privileged methods such as burn and mint.
8. Tokens - Configurator.
   • Vault parameter retrieval such as vaultMintPaused, mintVault[], getProtocolRewardsPool, tokenMiner.
9. Tokens - Miner.
   • Reward logic through calls such as refreshReward.
10. Miner - Configurator.
    • Information retrieval such as getEUSDAddress, isRedemptionProvider, mintVault[].
11. Miner - Vaults.
    • Token and vault information retrieval such as getPoolTotalCirculation and getBorrowedOf.
12. Miner - Tokens.
    • Token information retrieval such as balanceOf, totalSupply, and getUserBoost.
    • Token administration such as transfer and highly privileged calls such as mint and burn.
13. Miner - Miner.
    • External calls between miner contracts such as totalSupply, totalStaked, stakedOf, and userLockStatus.

4 Security Specification

This section describes, from a security perspective, the expected behavior of the system under audit. It is not a substitute for documentation. The purpose of this section is to identify specific security properties that were validated by the audit team.

4.1 Actors

The relevant actors are listed below with their respective abilities:

• Lybra Finance team - contract owners and deployers. The contract team currently manages the deployment and initial configuration of the contracts.
• Lybra Governance. LBR (and esLBR) token holders who can to vote, pass, and execute proposals.
• Vault owners. The users that supply the collateral and leverage it for minting the Lybra Protocol’s stablecoins.
• Token holders. The end-user holders of the EUSD and PeUSD tokens.
• Keepers. Users and/or bots that call functions such as excess income distribution and vault liquidations of those vaults that are below the necessary collateral ratios.
• Price Oracles. Third-party contracts that provide price feeds for various tokens for the Lybra Protocol.

4.2 Trust Model

In any system, it’s important to identify what trust is expected/required between various actors. For this audit, we established the following trust model:

• Lybra Finance team (contract owners and deployers). In the current scope of this protocol, there is in fact a large amount of trust put into the deployer of the contracts to initialize them properly. As seen in the System Overview section, the LybraConfigurator contract, for example, contains numerous mission-critical variables that are used by other contracts in the system. Setting those up correctly in the beginning is the responsibility of the deployer. However, as this is all on a public blockchain, it would be possible to identify if the Lybra deployer has made a mistake in the configurations, so this is not a significant issue vector. That being said, it is important to point out that upon deployment of the GovernanceTimelock contract, the msg.sender explicitly gets a DAO and a GOV role, the former of which also allows it to bypass any checks that are protected by the checkRole function as it specifically allows a DAO role to go through. As a result, there is significant trust involved with the Lybra deployer for him not to get compromised as it could be disastrous for the system.
• Lybra Governance. As with most DAOs, the holders of governance tokens (LBR and esLBR) are trusted with voting, passing, and executing proposals as they see fit. As a result, the Governance is trusted not to pass malicious proposals.
• Vault owners. No particular trust assumptions are made about the vault owners. They are expected to maintain a healthy collateral-to-borrow ratio. However, if they fail to do so, there are incentive mechanisms to enable other users, such as keepers, to liquidate such vaults. Vault owners can also become redemption providers to earn additional fees and receive a boost in their rewards, so other users can use their vaults to redeem tokens directly. However, if the vault owner is marked as a redemption provider but in fact doesn’t have enough liquidity to support a redemption, it will simply revert and not stop the overall system from working.
• Token holders. Similarly, no specific trust assumptions are made for token holders. The interactions they can make with the protocol are all trustless.
• Keepers. While they are not explicitly trusted to maintain the Lybra Protocol system, keepers are crucial for the overall protocol health as they run liquidations and assist in staking reward distribution through purchases of excess amounts of Liquid Staking Tokens for EUSD. Industry-standard mechanisms are employed to get the keepers to interact with the system, such as Dutch Auction discounts, additional keeper fees, and so on. As a result, the overall user base of the chain where the Lybra Protocol is deployed is assumed to have enough rational actors to execute the incentives and move the mechanisms forward.

4.3 Security Properties

The following is a non-exhaustive list of security properties that were identified in this audit:

• Hardcoded properties. The Lybra Protocol is complex and maintains many of properties necessary for its operations, such as collateral ratios, fee ratios, boosts, Dutch Auction settings, and so on. Some of these are set by the Governance through the LybraConfigurator contract but some of them are hardcoded in the system. It is important for users to identify if they are comfortable with both potentially changing parameters by the governance and hardcoded parameters that will not change throughout the lifecycle of the system.
• Proxy. From the documentation, the comments, and the files in scope, it appears that a proxy deployment specifically for the LybraConfigurator contract might be possible. As mentioned throughout the report, this is a mission-critical contract and users should be aware of risks associated with its upgradeability as a faulty upgrade might critically damage the system.
• Lybra Deployer. As mentioned above, the Lybra Deployer is explicitly given the DAO and GOV roles upon deploying the GovernanceTimelock contract. While the GOV role is the admin of other roles, the DAO role allows the owner of this private key to do almost anything they want with the system. For example, they can set a new contract to be a LBR miner, mint as many LBR tokens as they want, and then take full control of the DAO’s governance. However unlikely, a malicious actor may compromise these keys, so this is a risk users need to take into account. It is understandable to approach the deployment of this system with some safeguards like this in the beginning that would allow the Lybra Finance team to surgically address issues such as those in configurations. However, it would be critical to then revoke the DAO role from that private address as the system matures. Otherwise, this poses a significant risk.

5 Post Audit Verifications

During the verification week after the audit, the following points have been identified as potential improvements to the additional changes provided:

• Improve the logic of the rigidRedemption commit. The checkWithdrawal check is introduced to ensure collateral doesn’t leave the system within the 3 day period of having been deposited. However, the check is made on the user requested the rigid redemption whereas the collateral comes from the provider. Therefore, it seems more applicable to apply the checkWithdrawal check on the provider.
• Improve the logic of the rigidRedemption commit. The emitted event RigidRedemption has an incorrect amount emitted. If the logic of the withdraw function in the same contract is to be followed, the event should emit the amount that is corrected by the checkWithdrawal function instead of what the user first requested to withdraw (or rigid redeem).
• fix getVaultWeight logic commit. The vault is now checked to be active if there is no special weight assigned to it. However, if weight is assigned but it is disabled (so mintVault gives false), this will still return a value, which may be in conflict with the new change that appears to only want to give a vaultWeight back if it is enabled.

6 Findings

Each issue has an assigned severity:

• Minor issues are subjective in nature. They are typically suggestions around best practices or readability. Code maintainers should use their own judgment as to whether to address such issues.
• Medium issues are objective in nature but are not security vulnerabilities. These should be addressed unless there is a clear reason not to.
• Major issues are security vulnerabilities that may not be directly exploitable or may require certain conditions in order to be exploited. All major issues should be addressed.
• Critical issues are directly exploitable security vulnerabilities that need to be fixed.

contract LybraWstETHVault is LybraPeUSDVaultBase {
    Ilido immutable lido;
    //WstETH = 0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0;
    //Lido = 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84;
    constructor(address _lido, address _asset, address _oracle, address _config) LybraPeUSDVaultBase(_asset, _oracle, _config) {
        lido = Ilido(_lido);
    }

    function depositEtherToMint(uint256 mintAmount) external payable override {
        require(msg.value >= 1 ether, "DNL");
        uint256 sharesAmount = lido.submit{value: msg.value}(address(configurator));
        require(sharesAmount != 0, "ZERO_DEPOSIT");
        lido.approve(address(collateralAsset), msg.value);
        uint256 wstETHAmount = IWstETH(address(collateralAsset)).wrap(msg.value);
        depositedAsset[msg.sender] += wstETHAmount;
        if (mintAmount > 0) {
            _mintPeUSD(msg.sender, msg.sender, mintAmount, getAssetPrice());
        }
        emit DepositEther(msg.sender, address(collateralAsset), msg.value,wstETHAmount, block.timestamp);
    }

contract LybraWBETHVault is LybraPeUSDVaultBase {
    //WBETH = 0xa2e3356610840701bdf5611a53974510ae27e2e1
    constructor(address _asset, address _oracle, address _config)
        LybraPeUSDVaultBase(_asset, _oracle, _config) {}

    function depositEtherToMint(uint256 mintAmount) external payable override {
        require(msg.value >= 1 ether, "DNL");
        uint256 preBalance = collateralAsset.balanceOf(address(this));
        IWBETH(address(collateralAsset)).deposit{value: msg.value}(address(configurator));
        uint256 balance = collateralAsset.balanceOf(address(this));
        depositedAsset[msg.sender] += balance - preBalance;

        if (mintAmount > 0) {
            _mintPeUSD(msg.sender, msg.sender, mintAmount, getAssetPrice());
        }

        emit DepositEther(msg.sender, address(collateralAsset), msg.value,balance - preBalance, block.timestamp);
    }

constructor(address _rocketStorageAddress, address _rETH, address _oracle, address _config)
    LybraPeUSDVaultBase(_rETH, _oracle, _config) {
    rocketStorage = IRocketStorageInterface(_rocketStorageAddress);
}

function depositEtherToMint(uint256 mintAmount) external payable override {
    require(msg.value >= 1 ether, "DNL");
    uint256 preBalance = collateralAsset.balanceOf(address(this));
    IRocketDepositPool(rocketStorage.getAddress(keccak256(abi.encodePacked("contract.address", "rocketDepositPool")))).deposit{value: msg.value}();
    uint256 balance = collateralAsset.balanceOf(address(this));
    depositedAsset[msg.sender] += balance - preBalance;

    if (mintAmount > 0) {
        _mintPeUSD(msg.sender, msg.sender, mintAmount, getAssetPrice());
    }

    emit DepositEther(msg.sender, address(collateralAsset), msg.value,balance - preBalance, block.timestamp);
}

function checkRole(bytes32 role, address _sender) public view  returns(bool){
    return hasRole(role, _sender) || hasRole(DAO, _sender);
}

function checkOnlyRole(bytes32 role, address _sender) public view  returns(bool){
    return hasRole(role, _sender);
}

constructor(uint256 minDelay, address[] memory proposers, address[] memory executors, address admin) TimelockController(minDelay, proposers, executors, admin) {
  
    _setRoleAdmin(DAO, GOV);
    _setRoleAdmin(TIMELOCK, GOV);
    _setRoleAdmin(ADMIN, GOV);
    _grantRole(DAO, address(this));
    _grantRole(DAO, msg.sender);
    _grantRole(GOV, msg.sender);
}

function convertToPeUSD(address user, uint256 eusdAmount) public {
    require(_msgSender() == user || _msgSender() == address(this), "MDM");
    require(eusdAmount != 0, "ZA");
    require(EUSD.balanceOf(address(this)) + eusdAmount <= configurator.getEUSDMaxLocked(),"ESL");

function liquidation(address provider, address onBehalfOf, uint256 assetAmount) external virtual {
    uint256 assetPrice = getAssetPrice();
    uint256 onBehalfOfCollateralRatio = (depositedAsset[onBehalfOf] * assetPrice * 100) / borrowed[onBehalfOf];
    require(onBehalfOfCollateralRatio < badCollateralRatio, "Borrowers collateral ratio should below badCollateralRatio");

    require(assetAmount * 2 <= depositedAsset[onBehalfOf], "a max of 50% collateral can be liquidated");
    require(EUSD.allowance(provider, address(this)) != 0, "provider should authorize to provide liquidation EUSD");
    uint256 eusdAmount = (assetAmount * assetPrice) / 1e18;

    _repay(provider, onBehalfOf, eusdAmount);
    uint256 reducedAsset = assetAmount * 11 / 10;
    totalDepositedAsset -= reducedAsset;
    depositedAsset[onBehalfOf] -= reducedAsset;
    uint256 reward2keeper;
    if (provider == msg.sender) {
        collateralAsset.safeTransfer(msg.sender, reducedAsset);
    } else {
        reward2keeper = (reducedAsset * configurator.vaultKeeperRatio(address(this))) / 110;
        collateralAsset.safeTransfer(provider, reducedAsset - reward2keeper);
        collateralAsset.safeTransfer(msg.sender, reward2keeper);
    }
    emit LiquidationRecord(provider, msg.sender, onBehalfOf, eusdAmount, reducedAsset, reward2keeper, false, block.timestamp);
}

require(EUSD.allowance(provider, address(this)) != 0, "provider should authorize to provide liquidation EUSD");

require(EUSD.allowance(provider, address(this)) >= eusdAmount, "provider should authorize to provide liquidation EUSD");

if (provider == msg.sender) {
    collateralAsset.safeTransfer(msg.sender, reducedAsset);
} else {
    reward2keeper = (reducedAsset * configurator.vaultKeeperRatio(address(this))) / 110;
    collateralAsset.safeTransfer(provider, reducedAsset - reward2keeper);
    collateralAsset.safeTransfer(msg.sender, reward2keeper);
}

pragma solidity ^0.8;

function setBadCollateralRatio(address pool, uint256 newRatio) external onlyRole(DAO) {
    require(newRatio >= 130 * 1e18 && newRatio <= 150 * 1e18 && newRatio <= vaultSafeCollateralRatio[pool] + 1e19, "LNA");
    vaultBadCollateralRatio[pool] = newRatio;
    emit SafeCollateralRatioChanged(pool, newRatio);
}

uint256 public immutable badCollateralRatio = 150 * 1e18;

contract esLBRBoost is Ownable {
    esLBRLockSetting[] public esLBRLockSettings;
    mapping(address => LockStatus) public userLockStatus;
    IMiningIncentives public miningIncentives;

    // Define a struct for the lock settings
    struct esLBRLockSetting {
        uint256 duration;
        uint256 miningBoost;
    }

    // Define a struct for the user's lock status
    struct LockStatus {
        uint256 lockAmount;
        uint256 unlockTime;
        uint256 duration;
        uint256 miningBoost;
    }

    // Constructor to initialize the default lock settings
    constructor(address _miningIncentives) {

function unlockPrematurely() external {
    require(block.timestamp + exitCycle - 3 days > time2fullRedemption[msg.sender], "ENW");
    uint256 burnAmount = getReservedLBRForVesting(msg.sender) - getPreUnlockableAmount(msg.sender);
    uint256 amount = getPreUnlockableAmount(msg.sender) + getClaimAbleLBR(msg.sender);
    if (amount > 0) {
        LBR.mint(msg.sender, amount);
    }
    unstakeRatio[msg.sender] = 0;
    time2fullRedemption[msg.sender] = 0;
    grabableAmount += burnAmount;
}

function setToken(address _lbr, address _eslbr) external onlyOwner {
    LBR = _lbr;
    esLBR = _eslbr;
}

function setLBROracle(address _lbrOracle) external onlyOwner {
    lbrPriceFeed = AggregatorV3Interface(_lbrOracle);
}

function setPools(address[] memory _vaults) external onlyOwner {
    require(_vaults.length <= 10, "EL");
    for (uint i = 0; i < _vaults.length; i++) {
        require(configurator.mintVault(_vaults[i]), "NOT_VAULT");
    }
    vaults = _vaults;
}

// Allows the owner to set the rewards duration
function setRewardsDuration(uint256 _duration) external onlyOwner {
    require(finishAt < block.timestamp, "reward duration not finished");
    duration = _duration;
}

// Allows the owner to set the boost contract address
function setBoost(address _boost) external onlyOwner {
    esLBRBoost = IesLBRBoost(_boost);
}

if(useLBR) {
    IesLBR(miningIncentives.LBR()).burn(msg.sender, lbrAmount);
    IesLBR(miningIncentives.esLBR()).mint(msg.sender, lbrAmount);
}

IPeUSD public EUSD;

if (address(EUSD) == address(0)) EUSD = IPeUSD(_eusd);

IesLBR public LBR;

LBR = IesLBR(_lbr);

Appendix 1 - Files in Scope

This audit covered the following files:

Appendix 2 - Disclosure

Consensys Diligence (“CD”) typically receives compensation from one or more clients (the “Clients”) for performing the analysis contained in these reports (the “Reports”). The Reports may be distributed through other means, including via Consensys publications and other distributions.

The Reports are not an endorsement or indictment of any particular project or team, and the Reports do not guarantee the security of any particular project. This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale or any other product, service or other asset. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. No Report provides any warranty or representation to any third party in any respect, including regarding the bug-free nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the Reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this Report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project. CD owes no duty to any third party by virtue of publishing these Reports.

A.2.1 Purpose of Reports

The Reports and the analysis described therein are created solely for Clients and published with their consent. The scope of our review is limited to a review of code and only the code we note as being within the scope of our review within this report. Any Solidity code itself presents unique and unquantifiable risks as the Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond specified code that could present security risks. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. In some instances, we may perform penetration testing or infrastructure assessments depending on the scope of the particular engagement.

CD makes the Reports available to parties other than the Clients (i.e., “third parties”) on its website. CD hopes that by making these analyses publicly available, it can help the blockchain ecosystem develop technical best practices in this rapidly evolving area of innovation.

A.2.2 Links to Other Web Sites from This Web Site

You may, through hypertext or other computer links, gain access to web sites operated by persons other than Consensys and CD. Such hyperlinks are provided for your reference and convenience only, and are the exclusive responsibility of such web sites’ owners. You agree that Consensys and CD are not responsible for the content or operation of such Web sites, and that Consensys and CD shall have no liability to you or any other person or entity for the use of third party Web sites. Except as described below, a hyperlink from this web Site to another web site does not imply or mean that Consensys and CD endorses the content on that Web site or the operator or operations of that site. You are solely responsible for determining the extent to which you may use any content at any other web sites to which you link from the Reports. Consensys and CD assumes no responsibility for the use of third-party software on the Web Site and shall have no liability whatsoever to any person or entity for the accuracy or completeness of any outcome generated by such software.

A.2.3 Timeliness of Content

The content contained in the Reports is current as of the date appearing on the Report and is subject to change without notice unless indicated otherwise, by Consensys and CD.