Scribd
Upload
55 views8 pages

Baby Tiki - $babytiki: by Solid

This 3 page audit report summarizes the results of a security audit of the Baby Tiki smart contract. No critical vulnerabilities were found. The code performs as expected with no back doors. Minor issues around function visibility and event usage were noted. The liquidity lock is verified. Overall the code quality is good with proper checks for overflows and underflows.

Uploaded by

Ibu Sri'ah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
55 views8 pages

Baby Tiki - $babytiki: by Solid

This 3 page audit report summarizes the results of a security audit of the Baby Tiki smart contract. No critical vulnerabilities were found. The code performs as expected with no back doors. Minor issues around function visibility and event usage were noted. The liquidity lock is verified. Overall the code quality is good with proper checks for overflows and underflows.

Uploaded by

Ibu Sri'ah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

BY SOLIDSECT.

COM

BABY TIKI | $BABYTIKI


SMART-CONTRACT AUDIT REPORT
BY SOLIDSECT

CONTRACT ADDRESS:
https://bscscan.com/address/0x5E5115ce00d9f1de34454Ea6211c1412cF238ce1#code

Website: https://babytikitoken.finance
Telegram: https://t.me/babytikitoken
Twitter: https://twitter.com/realbabytiki

Page 1 of 8
BY SOLIDSECT.COM

Contents
Contents and Disclaimer ...................................................... 2
Audit Summary ............................................................... 3-4
Audit Overview ................................................................... 5
Executed Attacks to the Contract .......................................... 5
Over and Under Flows ......................................................... 5
Short Address Attack .......................................................... 6
Visibility and ‘Delegate Call’ Misuse ....................................... 6
Reentrancy / TheDAO Hack .................................................. 7
Forcing BNB to a Contract ................................................... 7
Positive Traits in The Smart Contract..................................... 8

Disclaimer
This audit makes no statements or warranties about the utility or safety of
the code, the suitability or regulatory regime of the business model, the
fairness of the token allocation or any other statements about the fitness
of the contracts regarding their purpose or bug-free status. This audit
documentation is for informative purposes only.

Page 2 of 8
BY SOLIDSECT.COM

AUDIT SUMMARY

Concluding, the inspected code is well-written and performs

as expected. There is no back door to steal funds.

Please try to check the address and value of the token externally before
sending this to the solidity code.

Our final recommendation is to pay more attention to the visibility of the


functions, the hardcoded address, and the mapping, since it is quite
important to define who is supposed to execute the functions and to follow
best practices regarding the use of ‘assert,’ ‘require,’ etc. (which you are
already doing, so great job on that).

Best Work: Code performs well and the code quality


is good.

LIQUIDITY LOCK
75% LP Tokens locked by DX Sale for 1-Year - Verified.

Page 3 of 8
BY SOLIDSECT.COM

Critical Vulnerabilities Found


=> No critical vulnerabilities found

Medium-Severity Vulnerabilities Found


=> No medium-severity vulnerabilities found

Low-Severity Vulnerabilities Found


You can add events and emit them in functions. You can use
variables to receive return value in some functions. (These
suggestions does not effect performance of the contract)

Owner Privileges
In the event when the owner is not renounced, owner can execute
owner defined functions. (excludeFromFees, updateLiquidityWallet,
transferOwnership)

Page 4 of 8
BY SOLIDSECT.COM

Audit Overview
The project has 16 files. All functions and state variables are well-
commented using natspec documentation, which that does not create
any vulnerability.

Executed Attacks to the Contract


In order to check for the security of the contract, we tested several
attacks in order to make sure that the contract is secure and follows best
practices.

Over and Under Flows


An overflow happens when the limit of the type variable uint256, 2 **
256, is exceeded. What happens is that the value resets to zero instead of
incrementing more. Yet, an underflow happens when you try to subtract 0
minus a number larger than 0. For example, if you subtract 0 - 1 the result
will be = 2 ** 256 instead of -1. This is quite dangerous. This contract does
check for overflows and underflows by using Open Zeppelin’s Safe Math to
mitigate this attack, and all the functions have strong validations, which
prevented this attack.

Page 5 of 8
BY SOLIDSECT.COM

Short Address Attack


If the token contract has enough amount of tokens and the buy function
does not check the length of the address of the sender, the Tron’s virtual
machine will add zeros to the transaction until the address is complete.
Although this contract is not vulnerable to this attack, there are some
points where users can mess themselves up due to this (please see
below). It is highly recommended to call functions after checking
validity of the address.

Visibility and ‘Delegate Call’ Misuse


This is also known as Parity Hack, which occurs during misuse of a
Delegate Call. No such issues were found in this smart contract, and the
visibility was also properly addressed. There are some places where
there is no visibility defined. The smart contract will assume ‘public’
visibility if there is no visibility defined. It is good practice to explicitly
define the visibility; but again, the contract is not prone to any
vulnerability due to that in this case.

Page 6 of 8
BY SOLIDSECT.COM

Reentrancy / TheDAO Hack


Reentrancy occurs in this case: Any interaction from a contract (A) with
another contract (B) and any transfer of Tron hands over control to that
contract (B). This makes it possible for B to call back into A before this
interaction is completed. Use of ‘require’ function in this smart contract
mitigates this vulnerability.

Forcing BNB to a Contract


While implementing ‘selfdestruct’ in a smart contract, it sends all the
BNB to the target address. Now, if the target address is a contract
address, then the fallback function of the target contract does not get
called. And thus, a hacker can bypass the ‘required’ conditions. Here, the
smart contract’s balance has never been used as a guard, which mitigates
this vulnerability.

Page 7 of 8
BY SOLIDSECT.COM

Positive Traits in The Smart Contract


SafeMath protects the contract from underflow and overflow attacks ✅

Checks if the new owner address value is a proper valid address ✅

Checks if the currentAllowance is equal or higher than subtractedValue ✅

Checks if spender address values are proper addresses ✅

The inspected code is well-written and performs as expected. ✅

END OF REPORT – 8 PAGES

Page 8 of 8

You might also like