TimeCapsule

Smart Contract Audit Report

Audit Summary

TimeCapsule is a new product which allows users to create their own Time Capsules which can be used to lock various funds.

For this audit, we reviewed the project team's TimeCapsuleFactory, TimeCapsule, and FeeSplitter contracts at commit 524580854480c31f9d37fc81c13b3257f9ea7467 on the team's private GitHub repository.

Audit Findings

A Medium finding was identified and the team should resolve this issue.
Date: April 21st, 2023.

Finding #1 - TimeCapsule - Medium

Description: Fee-on-transfer tokens are not compatible with TimeCapsules unless the proper exemptions are made. Upon creating a lock, its tracked locked amount will be higher than the number of tokens received.
Risk/Impact: A TimeCapsule owner may be able to withdraw more funds than intended when a lock expires if they have created multiple locks for a single fee-on-transfer token.
Recommendation: A lock's amount should reflect the amount of tokens received by the contract instead of the user specified lock amount.
Resolution: The team has not yet addressed this issue.

Contracts Overview

• As the contracts are implemented with Solidity v0.8.0, they are safe from any possible overflows/underflows.

TimeCapsuleFactory Contract:

• This contract allows users to create their own "Time Capsule".
• When creating a Time Capsule, the user specifies a "recovery address hash".
• Only one capsule can be created per user.
• A new TimeCapsule contract is created using the associated implementation contract, with the creator set as the owner and the FeeSplitter address set as this contract's associated FeeSplitter.
• A stored record of the user's TimeCapsule is stored in this contract, along with its recovery address hash.
• Ownership of the TimeCapsule can be recovered to the specified recovery address a single time, where the recovery address is set as the TimeCapsule's new owner and this contract's records are updated.
• Ownership cannot be recovered if the recovery address already owns a TimeCapsule.
• The TimeCapsule implementation and FeeSetter contracts are defined upon deployment and cannot be updated.

TimeCapsule Contract:

• This contract allows its owner to lock various funds for specified periods of time.
• When locking funds, the owner specifies a token address, lock start time, unlock time, and whether it is a "hard lock".
• The sum of the lock amount and a 0.1% fee is transferred from the owner to this contract; the fee amount is transferred to the FeeSplitter address and immediately split between the fee recipients.
• If creating a hard lock, none of the funds can be withdrawn until the unlock time has been reached.
• If creating a soft lock, the locked amount unlocks linearly throughout the lock period.
• The 0x0 address is used to lock the blockchain's native currency.
• The maximum permitted lock time is 55 years.
• In order to withdraw, the owner must first initiate their withdrawal, specifying the amount to be withdrawn.
• Once initiated, the owner must wait an additional 7 days before withdrawing the pending funds to their address.
• A user can initiate a withdrawal of a soft lock's total amount if its lock start time has not been reached yet.
• Alternatively, the owner can cancel a pending withdrawal.
• A user cannot initiate another withdrawal from the same lock until the pending withdrawal has been completed or canceled.
• The TimeCapsule owner can enter their TimeCapsule into "panic mode" at any time, which will disable all functionality apart from canceling.
• If in panic mode or one year has passed from the latest unlock time, the TimeCapsule's recovery address can be used to claim ownership of the TimeCapsule. This will also restore all contract functionality.
• Both ownership recovery and panic mode can only be executed once.

FeeSplitter Contract:

• This contract is used to split its token balances and native currency between three recipients.
• The three recipients are set upon deployment and cannot be updated.
• Anyone can initiate a token split at any time, which divides the specified token and transfers a portion to each recipient.
• Whenever the contract receives the blockchain's native token, it is automatically divided and transferred to each recipient.

Audit Results

Inheritance Chart

Function Graph

Functions Overview

 ($) = payable function
 # = non-constant function
 
 Int = Internal
 Ext = External
 Pub = Public

 + [Lib] Clones 
    - [Int] clone #
    - [Int] cloneDeterministic #
    - [Int] predictDeterministicAddress
    - [Int] predictDeterministicAddress

 + [Int] IERC20 
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Ext] transfer #
    - [Ext] allowance
    - [Ext] approve #
    - [Ext] transferFrom #

 + [Lib] Address 
    - [Int] isContract
    - [Int] sendValue #
    - [Int] functionCall #
    - [Int] functionCall #
    - [Int] functionCallWithValue #
    - [Int] functionCallWithValue #
    - [Int] functionStaticCall
    - [Int] functionStaticCall
    - [Int] functionDelegateCall #
    - [Int] functionDelegateCall #
    - [Int] verifyCallResultFromTarget
    - [Int] verifyCallResult
    - [Prv] _revert

 +  Initializable 
    - [Int] _disableInitializers #
    - [Int] _getInitializedVersion
    - [Int] _isInitializing

 + [Lib] Math 
    - [Int] max
    - [Int] min
    - [Int] average
    - [Int] ceilDiv
    - [Int] mulDiv
    - [Int] mulDiv
    - [Int] sqrt
    - [Int] sqrt
    - [Int] log2
    - [Int] log2
    - [Int] log10
    - [Int] log10
    - [Int] log256
    - [Int] log256

 + [Lib] Strings 
    - [Int] toString
    - [Int] toHexString
    - [Int] toHexString
    - [Int] toHexString

 + [Lib] ECDSA 
    - [Prv] _throwError
    - [Int] tryRecover
    - [Int] recover
    - [Int] tryRecover
    - [Int] recover
    - [Int] tryRecover
    - [Int] recover
    - [Int] toEthSignedMessageHash
    - [Int] toEthSignedMessageHash
    - [Int] toTypedDataHash

 +  TimeCapsuleFactory 
    - [Pub]  #
    - [Pub] createTimeCapsule #
    - [Pub] checkRecoveryAddress
    - [Pub] capsuleAddressOf
    - [Pub] recoverOwnership #

 +  TimeCapsuleContext (Initializable)

 +  TimeCapsule (TimeCapsuleContext)
    - [Pub]  #
    - [Pub] initialize #
       - modifiers: initializer
    - [Ext]  ($)
    - [Int] _transferNative #
    - [Int] _transferToken #
    - [Pub] vaultStatus
       - modifiers: _onlyCapsuleOwner
    - [Pub] checkRecoveryAddress
       - modifiers: _onlyCapsuleOwner
    - [Pub] lockCount
       - modifiers: _onlyCapsuleOwner
    - [Pub] lockData
       - modifiers: _onlyCapsuleOwner
    - [Pub] availableBalance
       - modifiers: _onlyCapsuleOwner
    - [Int] _storeNewLock #
    - [Int] _createLock #
    - [Pub] createLock ($)
       - modifiers: _onlyCapsuleOwner,_notPanicState
    - [Pub] createHardLock ($)
       - modifiers: _onlyCapsuleOwner,_notPanicState
    - [Pub] calculateAllowance
       - modifiers: _onlyCapsuleOwner
    - [Pub] initiateWithdrawal #
       - modifiers: _onlyCapsuleOwner,_notPanicState
    - [Pub] cancelWithdrawal #
       - modifiers: _onlyCapsuleOwner
    - [Pub] sendWithdrawal #
       - modifiers: _onlyCapsuleOwner,_notPanicState
    - [Pub] panic #
       - modifiers: _onlyCapsuleOwner
    - [Pub] recover #

 +  FeeSplitter 
    - [Pub]  #
    - [Ext]  ($)
    - [Prv] _splitNative #
    - [Pub] splitERC20 #

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