Closed yuriy77k closed 4 years ago
The budget of this audit: 6.295 Ether
Auditing time is 3 days
Auditing time: 7 days.
@MrCrambo @danbogd assigned.
Estimated audit time: 7 days
@RideSolo assigned
Pay attention: whitepaper atteched to description.
Tokenomics section and Auction will be the most useful
Pay attention: whitepaper atteched to description.
Here is the technical design - this could be used instead of the whitepaper md_jointer_technical_design_v4.docx
Estimated auditing time is 7 days.
@gorbunovperm assigned
My report is finished.
Estimated auditing time: 4 days
My report is finished.
@Mshuu there are enough auditors for this contract. Not assigned.
@Mshuu we are assigning a limited number of auditors for each contract. Those who comment earlier must be assigned first. "High priority" audit requests must be reviewed by 4 auditors max.
The contract contains a critical severity security issue. The developer is informed about it.
Jointer token smart contract security audit report performed by Callisto Security Audit Department
Сommit hash 35c2f9ba264ac722e8c57966ca820e8dc6b93fb0.
In total, 14 issues were reported including:
1 critical severity issues.
2 medium severity issues.
3 low severity issues.
1 notes.
7 owner privileges (the ability of an owner to manipulate contract, may be risky for investors).
When owners enforce user token swap using forceSwapWallet
, token.swapForToken
is called using balances[_address]
parameter but user balance was previously burned through and set to zero _burn(_address,balances[_address])
meaning that his balance is equal to zero, the swap will occur with zero value, user balance should be saved first in a memory variable then burned and the the newly created variable assigned for swap.
Following the document provided, as example "If Investors purchase through third party exchanges like, national stock exchanges, tZero, and other exchanges should be able to check and update the whitelist through a secure API"; however, any address added to the whitlist will be able to add other addresses following the logic implemented in addMoreWallets
function addMoreWallets(address _which) public returns (bool){
require(address_belongs[_which] == address(0));
address sender = msg.sender;
address primaryAddress = address_belongs[sender];
require(is_whiteListed[primaryAddress]);
address_belongs[_which] = primaryAddress;
emit WalletAdded(primaryAddress,_which);
return true;
}
address_belongs[_which]
is always set to primaryAddress
, meaning that the require(is_whiteListed[primaryAddress])
will never throw, since address_belongs[_which]
is always set to the first address that was whitelisted by the owner using addNewWallet
. The result of such implementation is that any address will be able to whitelist other addresses recursively.
The contract function description state that "once user whitelisted it can add more address itself", but even addresses not listed in is_whiteListed
mapping will be able to add other addresses, since whitelisting allow to manage KYC user onchain, this issue can have a bad legal impact on the project.
Developers should re-think the function logic.
setCansent
function member of WhiteList
is setting recive_block
instead of sent_block
, where canSentToken
is checking sent_block
.
The owner has a large number of privileges. This can be considered as an medium severity.
setCansent
and setCanRecive
functions.assignToken
function.forceSwapWallet
allow the owner to force user address balance swap.The owner can manipulate these parameters to his advantage.
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 the following code to the transfer(_to address, ...)
function:
require( _to != address(this) );
When using transfer
function and in case the recipient is a swappable token, then the exchange occurs. But when using transferFrom
with swappable token as recipient the exchange is no occurs but the tokens will be sent. On the part of the user it is logical to assume that these two functions work the same in this case. This may result in the loss of the sender's funds.
Incoming addresses should be checked for an empty value(0x0 address) to avoid loss of funds or blocking some functionality.
https://github.com/mak2296/JntrToken/blob/35c2f9ba264ac722e8c57966ca820e8dc6b93fb0/Token.sol#L76
https://github.com/mak2296/JntrToken/blob/35c2f9ba264ac722e8c57966ca820e8dc6b93fb0/Token.sol#L80
Doc parsing errors are raised for addMoreWallets
and setCansent
since the documentation to be generated contains invalid parameters name _address
and _recive
that should be replaced with _which
and sent
.
The audited smart contract must not be deployed. Reported issues must be fixed prior to the usage of this contract.
https://gist.github.com/gorbunovperm/543d1ea731858947c265091a1a62932d
https://gist.github.com/danbogd/064f6a441f498b28717a98fd85b0ff8b
https://gist.github.com/MrCrambo/d2d8af2b70c9f97d7084cd49482a3903
https://gist.github.com/RideSolo/29b0bc7bdf12f9512c314d7ca320daa8
The owner can block sending and receiving token for any address, so removing address is just new future and developer may decide is it necessary. Is not security issue.
Audit request
Jointer token contract.
Jointer Whitepaper-compressed.pdf
Source code
https://github.com/mak2296/JntrToken
Disclosure policy
Standard disclosure policy.
Contact information (optional)
Kyle@jointer.io
Platform
ETH