BlackRock Fund

Smart Contract Audit Report

Audit Summary

BlackRock Fund is releasing BTC, a new ERC-20 rebase token. Users are able to purchase and earn this token in various ways.

For this audit, we reviewed the contracts at commit ba65f611beef7ff61b66fda303646b183b009b06 on the team's GitHub repository.

Audit Findings

A low finding was identified and the team should consider resolving this issue. In addition, centralized aspects are present.
Date: February 2nd, 2024.

Finding #1 - _401k & _401k2 - Low

Description: The contract includes a supplyRewards() function which deposits BTC tokens to the contract. These tokens will never be used as BTC rewards are always minted to users.
Risk/Impact: If the owner uses this function to transfer BTC tokens to the contract, they will be locked with no way to withdraw them.
Recommendation: The team should remove this function as BTC rewards are always minted to users.
Resolution: The team has not yet addressed this issue.

---

Finding #2 - BTC - Informational

Description: The contract currently only supports and properly syncs with one LP pool.
Recommendation: The team should add an array of supported LP pools and sync each one during a rebase. This will allow support of additional LP pools in the future.

---

Finding #3 - BTC - Informational

Description: The BTC contract contains and unused btc contract.
Recommendation: The team should remove this contract as it is unused.

---

Finding #4 - ETF - Informational

Description: The constructor sets the bondCap and mints 0 tokens to the msg sender.
Recommendation: The team should remove these function calls as the bondCap defaults to a value of 0 and minting 0 tokens has no effect.

Contracts Overview

• The contracts utilize ReentrancyGuard to protect against reentrancy attacks in applicable functions.
• As the contracts are implemented with Solidity v0.8, they are safe from any possible overflows/underflows.
• The team must exercise caution to avoid using fee-on-transfer tokens in the ETF, _401k, and _401k2 contracts.
• The team must avoid using a rebase token as a staking token in the _401k2 contract.

BTC Contract:

• This contract defines the BlackrockTradingCurrency token [$BTC].
• The initial supply of 200,000 tokens is minted to the owner upon deployment.
• Any address with the Minter role may mint any amount of tokens to any address at any time.
• Users may burn their own tokens at any time.
• Tokens may not be transferred to the 0x0 address or this contract.
• Users may submit a signed message allowing another user to perform a transfer on their behalf.
• The contract features additional rebase functionality.
• Users' balance is defined based on a "scaling factor".
• As the scaling factor increases or decreases all users' token balance decreases proportionally.
• Any address with the Rebaser role may perform a positive rebase increase the scaling factor up to the "max scaling factor" at any time.
• Any address with the Rebaser role may perform a negative rebase decrease the scaling factor to any value at any time.
• Any address with the Minter role may "claim" tokens with a rebase.
• This will mint tokens and perform an additional negative rebase. The rebase will be performed based on the "rebase ratio" of the minted amount of tokens.
• The contract correctly syncs the LP pool if one has been set by the owner. The contract only supports one LP pool and the team should not create more than one.
• The owner may set the rebase ratio up to 100 percent at any time.
• The owner may set the Treasury and LP addresses at any time.

aBTCVault Contract:

• This contract allows users to redeem their BTC tokens for aBTC tokens.
• Any user may redeem their tokens at any time.
• A "mint fee" is taken from the supplied BTC tokens.
• Users are minted an equivalent amount of aBTC after fees.
• The fee amount is minted to the Buyback wallet controlled by the team.
• The supplied BTC tokens are burned.
• Users may redeem their aBTC tokens for BTC tokens at any time.
• A "redeem fee" is taken from the supplied aBTC tokens.
• The user is minted an equivalent amount of BTC tokens after fees.
• The fee amount is minted to the Buyback wallet controlled by the team.
• The supplied aBTC tokens are burned.
• The owner may set the mint fee and redeem fee up to 10% at any time.
• The owner may update the Buyback wallet address at any time.

ETF Contract:

• This contract allows users to supply bond tokens in order to be minted BTC tokens.
• Any user may "bond" tokens when bonding is open.
• Users supply a specified amount of bond tokens up to the "max transaction" amount.
• They are allocated a token amount based on the current bond price.
• The contract then mints ETF tokens to itself. The total supply of ETF tokens must not exceed the "bond cap".
• Users may claim the full amount of their allocated BTC tokens once the "vesting time" has elapsed from the last time they bonded or claimed.
• Users may claim early to receive the proportion of their allocated tokens equal to the amount of their vesting time has passed.
• The owner may open and close bonding at any time.
• The owner may set the max amount of bond tokens per transaction at any time.
• The owner may set the bond cap at any time.
• The owner may set the bond price to any value at any time.
• The owner may set the vesting period between 0 and 30 days at any time.
• The owner may withdraw any bond tokens from the contract at any time.

_401k Contract:

• This contract facilitates a staking mechanism where users can deposit tokens specified by the team and earn rewards over time.
• Rewards are intended to be distributed in the team's own BTC rebase token and USDC.
• When a user performs a deposit, the tokens being deposited are burned.
• On deposits, pending rewards for BTC are minted to the user, triggering a rebase. USDC rewards are transferred from the contract to the user.
• Due to the nature of the reward system's design and the inherent precision limitations in Solidity, users below a certain token threshold will not receive any rewards if the reward rate is too low.
• Users can only withdraw their staked tokens while withdraws are enabled; they are initially disabled.
• On withdraws, the user is minted the withdrawal amount of the specified token.
• In order to receive the withdraw amount in full, users must wait at least 2 days from their last deposit to withdraw any amount. Otherwise, there is a 10% withdrawal fee charged on the withdrawal amount and all unclaimed accumulated rewards are forfeited.
• The owner can enable or disable withdraws at any time.
• The owner can set the BTC and USDC contract addresses to any address at any time.
• The owner can set the BTC and USDC reward rates to any values at any time.
• The owner can create a new pool for any token at any time as long as one does not already exist for that token. The contract must also have permission to mint and burn that token.
• The owner can change the allocation points assigned to any pool at any time, effectively changing the pool's reward rate.

_401k2 Contract:

• This contract facilitates a staking mechanism where users can deposit tokens specified by the team and earn rewards over time.
• Rewards are intended to be distributed in the team's own BTC rebase token and USDC.
• On deposits, pending rewards for BTC are minted to the user, triggering a rebase. USDC rewards are transferred from the contract to the user.
• Due to the nature of the reward system's design and the inherent precision limitations in Solidity, users below a certain token threshold will not receive any rewards if the reward rate is too low.
• Users can only withdraw their staked tokens while withdraws are enabled; they are initially disabled.
• In order to receive the withdraw amount in full, users must wait at least 2 days from their last deposit to withdraw any amount. Otherwise, there is a 10% withdrawal fee charged on the withdrawal amount and all unclaimed accumulated rewards are forfeited.
• The owner can enable or disable withdraws at any time.
• The owner can set the BTC and USDC contract addresses to any address at any time.
• The owner can set the BTC and USDC reward rates to any values at any time.
• The owner can create a new pool for any token at any time as long as one does not already exist for that token. The contract must also have permission to mint and burn that token.
• The owner can change the allocation points assigned to any pool at any time, effectively changing the pool's reward rate.

Audit Results

Contract Source Summary and Visualizations

About SourceHat

SourceHat has quickly grown to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1800+ solidity smart contract audits covering all major project types and protocols, securing a total of over $50 billion U.S. dollars in on-chain value!
Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!

Contact us today to get a free quote for a smart contract audit of your project!

What is a SourceHat Audit?

Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A SourceHat Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.

How Do I Interpret the Findings?

Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:

• High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
• Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
• Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
• Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.

• Go Home