Taiko Drips

Smart Contract Audit Report

TaikoDrips Audit Report

Executive Summary

This report presents the outcomes of our collaborative engagement with the TaikoDrips team, focusing on the comprehensive evaluation of the TaikoDripsPool and TaikoDripsFactory contracts.

Our team conducted an initial security assessment from November 4th to November 8th, 2024 using code from the project team's GitHub repository.

TaikoDrips is a new project which allows users to deposit and lock their tokens for specified periods.


Audit Scope

Name

Source Code (GitHub)

Visualized

Lock

bb1fe8

Inheritance Chart.  Function Graph.

Pauser

bb1fe8

Inheritance Chart.  Function Graph.

StakingERC20, BareVaultUpgradeable, & LockupUpgradeable

bb1fe8

Inheritance Chart.  Function Graph.

Name/Source Code

Visualized

Lock
9b3bb2

Inheritance Chart.
Function Graph.

Pauser
9b3bb2

Inheritance Chart.
Function Graph.

StakingERC20, BareVaultUpgradeable, & LockupUpgradeable
9b3bb2

Inheritance Chart.
Function Graph.


Audit Findings

Medium findings were identified and the team should resolve these issues. In addition, centralized aspects are present.

Finding #1

BareVaultUpgradeable

Medium Open

Finding #1 - BareVaultUpgradeable
Medium Open

Description: The _updateLockup(), _unlock(), and getUserLockUps() functions contain unbounded loops, resulting in increased gas usage as a user's lockup list grows larger.

Risk/Impact: A user's deposits and withdrawals may become expensive or fail if they hold too many separate lockups at once.

Recommendation: Users could alternatively or additionally have the option to pass in specific Lockup IDs, tied to the index in their Lockup array, to specify the Lockup they wish to unlock or withdraw from. This could allow users to withdraw or deposit without needing to update their entire Lockup list.

Resolution: The team has not yet resolved this issue.

Finding #2

Lock

Low Open

Finding #2 - Lock
Low Open

Description: The Lock contract uses the transfer() function to withdraw native tokens to the owner, which limits the amount of available gas for receiving user.

owner.transfer(address(this).balance);

Risk/Impact: Withdrawals could fail if the owner is a contract that executes any logic upon the receival of funds. As the owner cannot be changed, these funds could become trapped in the contract.

Recommendation: The team should instead use the call() function to transfer native currency.

Resolution: The team has not yet resolved this issue.

Finding #3

BareVaultUpgradeable

Informational Open

Finding #3 - BareVaultUpgradeable
Informational Open

Description: The following logic in the withdraw function checks the users maximum available withdraw amount twice:

uint256 maxAssets = maxWithdraw(_msgSender());
if (assets > maxAssets) {
	revert ExceededMaxWithdraw(_msgSender(), assets, maxAssets);
}
(,uint256 _asset) = vault._deposit.tryGet(_msgSender());
if (assets > _asset) {
	revert ExceededWithdrawal(_msgSender(), assets, _asset);
}

Recommendation: One of these checks can be removed as it is redundant.


System Overview

STAKINGERC20

The staking contract allows users to deposit tokens by specifying an amount and a supported lock duration in days, provided they meet the minimum stake requirement. The staking asset is specified by the owner upon initialization. Deposits are restricted if they would cause the contract to exceed its maximum total deposit amount, if set. All deposits and withdrawals are paused when the Pauser contract's staking flag is active. Once a user’s lock time expires, they can withdraw the associated deposit amount, but only after the contract’s stake cooldown period has passed since their last deposit.

The Staking Operator Role can adjust the minimum stake amount, maximum total deposit, and cooldown period, as well as add or remove supported lock durations. Operators also have the authority to unlock locked tokens for users as needed. The Default Admin and Staking Operator roles are assigned upon deployment, with the Default Admin holding the ability to grant or revoke the Staking Operator Role from any address. This contract is upgradeable. The team should avoid using fee-on-transfer tokens as vault assets unless exemptions have been implemented.

PAUSER

The Pauser contract works with the StakingERC20 contract to manage the pausing of staking functions. Upon deployment, the Default Admin, Pauser, and Unpauser roles are assigned to specified addresses. The Pauser role can pause deposits and withdrawals from the StakingERC20 contract at any time, while the Unpauser role can resume these actions. Both the Pauser and Unpauser roles can also independently pause or unpause the allocation and claim flags, or all three flags simultaneously, although the allocation and claim flags are not enforced within the StakingERC20 contract. The Default Admin has the authority to grant or revoke any role from any address as needed.

LOCK

This contract is used to lock native currency until a specified date. Native tokens are provided and an owner and unlock time are specified upon deployment. These values cannot be changed after deployment. Once the unlock time has passed, the owner can withdraw all native tokens from the contract.



Vulnerability Analysis

Vulnerability Category Notes Result
Arbitrary Jump/Storage Write N/A PASS
Centralization of Control
  • The Staking Operator and other mentioned Roles have the permissions mentioned above.
  • A Staking Operator can unlock existing user locks at any time.
  • The Pauser Role can pause deposits and withdrawals at any time.
  • WARNING
    Compiler Issues N/A PASS
    Delegate Call to Untrusted Contract N/A PASS
    Dependence on Predictable Variables N/A PASS
    Ether/Token Theft N/A PASS
    Flash Loans N/A PASS
    Front Running N/A PASS
    Improper Events N/A PASS
    Improper Authorization Scheme N/A PASS
    Integer Over/Underflow N/A PASS
    Logical Issues N/A PASS
    Oracle Issues N/A PASS
    Outdated Compiler Version N/A PASS
    Race Conditions N/A PASS
    Reentrancy N/A PASS
    Signature Issues N/A PASS
    Sybil Attack N/A PASS
    Unbounded Loops
  • Deposits and withdrawals could become expensive or fail if a user's Lockup list grows too large.
  • WARNING
    Unused Code N/A PASS
    Overall Contract Safety   WARNING

    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.