Closed yuriy77k closed 5 years ago
Auditing time 4 days
@MrCrambo assigned.
Estimated auditing time is 7 days.
@gorbunovperm assigned.
My report is finished.
Estimated auditing time is 7 days.
@danbogd assigned
My report is finished.
Tubiex smart contract security audit report performed by Callisto Security Audit Department
ERC-20 implementation, Presale token management (creating records of presales and allowing users to claim those records at a rate of 1% per day), Crowdsale contract - EOS model with 2 additions: 1) a hidden hard cap, and 2) dynamic daily reserve price (with the ability to rebase the ETH price daily to have an accurate reserve.
Commit hash: f162c021c0d3d4c72c2144c80968d5190086300a.
In total, 2 issues were reported including:
1 low severity issues.
1 minor observation.
No critical security issues were found.
It is possible to double withdrawal attack. More details here.
Lack of transaction handling mechanism issue. WARNING! This is a very common issue and it already caused millions of dollars losses for lots of token users! More details here.
Add into a function transfer(address _to, ... )
following code:
require( _to != address(this) );
The function () payable { revert(); }
was a pattern used to prevent implicit acceptance of ether in Solidity versions older than 0.4.0, but today this is unneeded.
The review did not show any critical issues. The smart contract can be used.
https://gist.github.com/yuriy77k/6ac37ccca58ad78ce81a717bfbdc002a
https://gist.github.com/yuriy77k/ec5f39e05fdbe62a345da9f435d9f51f
https://gist.github.com/yuriy77k/eaf23b4651e55a02e4298c7c7adb6e64
Audit request
ERC-20 implementation, Presale token management (creating records of presales and allowing users to claim those records at a rate of 1% per day), Crowdsale contract - EOS model with 2 additions: 1) a hidden hard cap, and 2) dynamic daily reserve price (with the ability to rebase the ETH price daily to have an accurate reserve
We have now completed internal testing, please run the audit on commit f162c021c0d3d4c72c2144c80968d5190086300a of the master branch at https://github.com/tubiex/smart-contracts/tree/master/contracts
Here is some documentation to help the audit if needed
ERC-20
Follows OpenZeppelin Standards
Uses the Roles design pattern - https://github.com/OpenZeppelin/openzeppelin-solidity/tree/master/contracts/access/roles
We have a Minter role who mints initial supply and then revoke self
We have a Recoverer who can recover mis-sent ERC20 tokens (anytime for ERC20-contract, for Presale/Bounty/Airdrop contracts TBN tokens can only be recovered when the updating stage is ended, and for the Crowdsale only after the Crowdsale period has ended and those tokens are not part of the current distribution)
We have a Fundkeeper role which actually follows the OpenZeppelin Ownable pattern. The Fundkeeper holds all of the tokens/ETH of a contract (unless the contract holds these funds itself to distribute them) and so we wanted it to only be a single account not multiple like the other roles.
Fundkeeper - an adapted role like https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/ownership/Ownable.sol
Most contracts have a Manager Role which generally acts like Owner in other contract schemes (generally permissioned to execute admin functions)
We have created interfaces for all major contracts to provide streamlined ABIs for external functionality/interaction
Presale, Bounty, Airdrop - are all the exact same logic, just renaming for allocation clarity
The purpose for these three is to create blockchain records of tokens allocated before the sale in our centralised architecture… only the Manager can update/adjust these records. These contracts accept an allocation of tokens from the ERC-20 Fundkeeper via the allow/transferFrom pattern
After record creation, accounts that have records created can claim their tokens at a rate of 1% per day (or 100 tokens per day) whichever is larger, until all tokens claimed (last claim may claim less than 100, just claims the remaining small balance)
Crowdsale -
Crowdsale has a Whitelister Role in addition to others.
This Crowdsale follows the EOS model with 3 major differences: 1.Whitelisting of accounts for participation - this is to enforce KYC restrictions on the contract level 2.A hidden hard cap - have implemented a hidden hard cap to curb over subscription and to incentivise earlier participation 3.Interval reserve amounts 1.If the interval reserve amount of ETH is not met, only a portion of the interval tokens are distributed and the reserve price goes down by up to three steps depending on how much the interval was off of target, until a floor price (these prices are in ETH per one token) E.g. if the reserve is 10 ETH, and only 5 ETH is contributed, then only 5/10 (or 50% of the interval's tokens are distributed) 2.If the daily reserve is met, all 100% of the interval tokens are distributed and the reserve price goes up by up to three steps, until a ceiling price 3.For this to remain accurate there is ability for the contract Manager Role to adjust the ETH price daily (rebasing of the daily reserves from this price change occurs in the next day) 4.All USD entries are 18 decimal precision (for example USD$1 = 10*18, same as ETH and WEI)
I've found that for testing, these parameters makes the math easier -
also changing INTERVAL_BLOCKS = 10 (to reduce the time per interval)
If you have any other questions feel free to ask.
Source code
https://github.com/tubiex/smart-contracts/tree/f162c021c0d3d4c72c2144c80968d5190086300a/contracts
Disclosure policy
terry@tubiex.com
Platform
ETH
Complexity
Medium