Skip to main content
Blur Finance v1.1 - Jun 10, 2022

Blur Finance - Exchange v1.1 Contracts

Smart Contract Security Assessment

June 10, 2022




Dedaub was commissioned to perform an incremental audit on Blur’s Exchange v1.1 contracts on commit hash 3701dede2c592a41a75abe3f4333fed99f75c33c. The audited contract list is the following:



The audited codebase is of small size of ~1KLoC and is the heart of Blur's core system, though only a part of it. The NFT exchange functionality is based on order matching between sellers and buyers and has been, in this version, extended to also consider orders placed in the Wyvern environment. In essence, while in version 1.0 only Blur orders could be matched to complete an exchange, in version 1.1 a mixed match of a Wyvern order and a Blur order is also possible.

The rest of the codebase has been audited in a previous round. The corresponding report can be found here. We found no issues in this extended functionality.

As in the previous version, the exchange contract is upgradeable giving the ability to the Blur team to upgrade functionality or patch potential security threats. As is typical in an upgradeable system design, some trust is required that the team will upgrade the implementation only in accordance to the users’ interest.

The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than regular use of the protocol. Functional correctness (i.e. issues in "regular use") is a secondary consideration. Functional correctness relative to low-level calculations (including units, scaling, quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.


This section details issues that affect 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:

Can be profitably exploited by any knowledgeable third-party attacker to drain a portion of the system’s or users’ funds OR the contract does not function as intended and severe loss of funds may result.
Third-party attackers or faulty functionality may block the system or cause the system or users to lose funds. Important system invariants can be violated.
  • User or system funds can be lost when third-party systems misbehave.
  • DoS, under specific conditions.
  • Part of the functionality becomes unusable due to a programming error.
  • Breaking important system invariants but without apparent consequences.
  • Buggy functionality for trusted users where a workaround exists.
  • Security issues which may manifest when the system evolves.

Issue resolution includes “dismissed”, by the client, or “resolved”, per the auditors.


[No critical severity issues]


[No high severity issues]


[No medium severity issues]



Exchange implementation contract should (also) be initialized out of the proxy’s context

Exchange implementation contract should (also) be initialized out of the proxy’s context

Contract Exchange.sol contains all the protocol’s logic for the orders to be matched and executed. This contract is upgradeable through the UUPS proxy pattern, setting its owner during initialization. It is expected that the contract will be initialized inside the proxy’s context for the whole system to bootstrap. However, it is crucial that it is also dummy-initialized in its own context as well, so as to eliminate a well-known attack vector of the UUPS proxy, where an attacker initializes the implementation contract making herself the owner and then forces it to selfdestruct using the specifics of the upgradeability mechanism.

Since this separate initialization step cannot be guaranteed by the solidity codebase, we make this note to make sure it is not going to be missed.


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


Dead code

Dead code
  1. In WyvernMatchingExchange.sol, internal function transferTokens
function transferTokens(address token, address from, address to, uint256 amount)
if (amount > 0) {
require(tokenTransferProxy.transferFrom(token, from, to, amount));

is never used.

We suggest removing this function for clarity and gas savings upon deployment.

The team resolved this issue by removing the unused function.


Compiler known issues

Compiler known issues

Solidity compiler version v0.8.13 has, at the time of writing, some known bugs. We inspected the code and found that it is not affected by these bugs.


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.


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.