Blur Finance

Smart Contract Security Assessment

January 20, 2023

SUMMARY​

ABSTRACT​

Dedaub was commissioned to perform a security audit of the Blur Protocol. We had already audited earlier versions of the protocol. The corresponding reports along with the descriptions of the protocol and its architecture overview can be found here (v1.0), here (v1.1) and here.

This audit report covers the recent changes of the contracts of the at-this-time private repository blur-io/contracts-snapshot-not-public of the Blur protocol, at commit hash d3d2eda3be83ba91c3119540ffdd07a4c185f1d5.

SETTING & CAVEATS​

The audit focussed solely on the delta of changes, which consist of the following additions. The auditors did not re-audit the whole protocol.

• Minor upgrades to the BlurExchange contract altering the fee mechanism
• New Governance infrastructure

Two auditors worked on the codebase for 3 days on the following contracts:

The developers’ specification of the audit scope can be found verbatim below:

The scope of this audit includes:

• Minor upgrades to the BlurExchange contract to alter the fee mechanism (~50 SLOC)
• New governance infrastructure including
  • BlurToken - BLUR ERC20 contract (~35 SLOC)
  • BlurGovernor - core governance contract; taken from OpenZeppelin governance (~92 SLOC)
  • TimelockController - governor execution timelock; taken from OpenZeppelin governance (~215 SLOC)
  • TokenLockup - removes tokens from circulating supply; unlocking them on a predefined schedule (~112 SLOC)
  • BlurAirdrop - airdrop distributor (~33 SLOC)

There have been architectural changes since our last audit of the BlurExchange contract. Namely, the _execute function is now public, so that it can be the target of a multicall facility, implemented using delegatecall. An execution-setup phase precedes external command execution, apparently to prevent the issue of having a single msg.value across different delegatecalls. These changes required the introduction of two different levels of reentrancy protection, implemented in modifiers setupExecution and reentrancyGuard. Although we considered these changes in the course of understanding the flow of execution (and we believe them to be safe), we did not examine them extensively, as they are explicitly outside the scope of the audit.

The Governance functionality has been audited in isolation. There is no contract code or external test cases to exercise its full integration with the protocol (i.e., a proposal, subsequent vote, approval of the proposal, and execution). Therefore, there needs to be an assumption that the code is “called correctly”. Since the mechanism uses a standard OpenZeppelin facility, it is reasonable to assume that the front-end or other external agent invokes it as-expected. Generally, the tests for the governance mechanism seem to still be work-in-progress.

The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than the regular use of the protocol. Functional correctness (i.e. issues in "regular use") is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.

VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:

Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.

CRITICAL SEVERITY​

[No critical severity issues]

HIGH SEVERITY​

[No high severity issues]

MEDIUM SEVERITY​

[No medium severity issues]

LOW SEVERITY​

function _computeUnlocked(
    uint256 locked,
    uint256 time
) internal view returns (uint256) {
    ...
    for (uint i; i < scheduleLength; i++) {
        uint256 portion = schedule[i].portion;
        uint256 end = schedule[i].endTime;
        // Dedaub: Here the loop breaks once it finds a schedule
        //         that hasn't expired yet
        if (time < end) {
            unlocked += locked * (time - start) * portion /
                ((end - start) * INVERSE_BASIS_POINTS);
            break;
        } else {
            unlocked += locked * portion / INVERSE_BASIS_POINTS;
            start = end;
        }
    }
    return unlocked;
}

function _computeUnlocked(
    uint256 locked,
    uint256 time
) internal view returns (uint256) {
    ...

    // Dedaub: This loop iterates over the schedules taking into account
    //         each schedule's portion, but there is no check that they
    //         all add up to 100%
    for (uint i; i < scheduleLength; i++) {
        uint256 portion = schedule[i].portion;
        uint256 end = schedule[i].endTime;
        if (time < end) {
            unlocked += locked * (time - start) * portion /
                ((end - start) * INVERSE_BASIS_POINTS);
            break;
        } else {
            unlocked += locked * portion / INVERSE_BASIS_POINTS;
            start = end;
        }
    }
    return unlocked;
}

CENTRALIZATION ISSUES​

It is often desirable for DeFi protocols to assume no trust in a central authority, including the protocol’s owner. Even if the owner is reputable, users are more likely to engage with a protocol that guarantees no catastrophic failure even in the case the owner gets hacked/compromised. We list issues of this kind below. (These issues should be considered in the context of usage/deployment, as they are not uncommon. Several high-profile, high-value protocols have significant centralization threats.)

OTHER / ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.

function delegates(
    address account
) public view override returns (address) {
    address _delegate = ERC20Votes.delegates(account);
    if (_delegate == address(0)) {
        _delegate = account;
    }
    return _delegate;
}

 * By default, token balance does not account for voting power.
 * This makes transfers cheaper. The downside is that it
 * requires users to delegate to themselves in order to activate
 * checkpoints and have their voting power tracked.

function setFeeRate(uint256 _feeRate) external {
    require(msg.sender == governor,
        "Fee rate can only be set by governor");
    // Dedaub: Magic constant
    require(feeRate <= 250, "Fee cannot be more than 2.5%");
    ...
}

DISCLAIMER​

The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.

ABOUT DEDAUB​

Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.