Security Assessment

Baby Doge - BSC

Nov 16th, 2021
 Baby Doge - BSC Security Assessment

Table of Contents
Summary

Overview
Project Summary
Audit Summary
Vulnerability Summary
Audit Scope

Findings
CTC-01 : Centralization Risk in `addLiquidity()` Function
CTC-02 : Centralization Risk in Contract `CoinToken`
CTC-03 : Possible to Regain Ownership After Renouncing the Contract Ownership
CTC-04 : Incorrect Error Message
CTC-05 : Potential Sandwich Attacks
CTC-06 : Redundant Statement
CTC-07 : Function Name Typo
CTC-08 : Variable Could Be Declared as `constant`
CTC-09 : Typos in Contract `CoinToken`
CTC-10 : Lack of Return Value Handling
CTC-11 : Function Should Be Declared External
CTC-12 : Lack of Event Emissions for Significant Transactions
CTC-13 : Function and Variable Naming Doesn’t Match the Operating Environment

Appendix

Disclaimer

About
 Baby Doge - BSC Security Assessment

Summary
This report has been prepared for Baby Doge to discover issues and vulnerabilities in the source code of
the Baby Doge - BSC project as well as any contract dependencies that were not part of an officially
recognized library. A comprehensive examination has been performed, utilizing Static Analysis and Manual
Review techniques.

The auditing process pays special attention to the following considerations:

Testing the smart contracts against both common and uncommon attack vectors.
Assessing the codebase to ensure compliance with current best practices and industry standards.
Ensuring contract logic meets the specifications and intentions of the client.
Cross referencing contract structure and implementation against similar smart contracts produced
by industry leaders.
Thorough line-by-line manual review of the entire codebase by industry experts.

The security assessment resulted in findings that ranged from critical to informational. We recommend
addressing these findings to ensure a high level of security standards and industry practices.
We suggest
recommendations that could better serve the project from the security perspective:

Enhance general coding practices for better structures of source codes;

Add enough unit tests to cover the possible use cases;
Provide more comments per each function for readability, especially contracts that are verified in
public;
Provide more transparency on privileged activities once the protocol is live.
 Baby Doge - BSC Security Assessment

Overview
Project Summary

Project Name Baby Doge - BSC

Platform BSC

Language Solidity

Codebase https://bscscan.com/address/0xc748673057861a797275cd8a068abb95a902e8de#code

Commit

Audit Summary

Delivery Date Nov 16, 2021

Audit Methodology Static Analysis, Manual Review

Key Components CoinToken

Vulnerability Summary

Vulnerability Level Total Pending Declined Acknowledged Partially Resolved Resolved

Critical 0 0 0 0 0 0

Major 2 0 0 2 0 0

Medium 1 0 0 1 0 0

Minor 2 0 0 2 0 0

Informational 8 0 0 8 0 0

Discussion 0 0 0 0 0 0
 Baby Doge - BSC Security Assessment

Audit Scope

ID File SHA256 Checksum

CTC CoinToken.sol ae564fcab5859902a0754485e1646015e226a8a75f8bef95aa2878370815ec63

 Baby Doge - BSC Security Assessment

Overview

External Dependencies

The contract serves as the underlying entity to interact with third-party Uniswap protocols (token-
swapping). The scope of the audit treats third-party entities as black boxes and assumes their functional
correctness. However, in the real world, third parties can be compromised and this may lead to lost or
stolen assets.

Privileged Functions

The contract CoinToken contains the following privileged functions that are restricted by _owner role with
the onlyOwner modifier. They are used to modify the contract configurations and address attributes. We
grouped these functions below.

CoinToken.excludeFromReward()

CoinToken.includeInReward()

CoinToken.excludeFromFee()

CoinToken.includeInFee()

CoinToken.setTaxFeePercent()

CoinToken.setLiquidityFeePercent()

CoinToken.setNumTokensSellToAddToLiquidity()

CoinToken.setMaxTxPercent()

CoinToken.setSwapAndLiquifyEnabled()

CoinToken.claimTokens()

To improve the trustworthiness of the project, dynamic runtime updates in the project should be notified to
the community. Any plan to invoke the aforementioned functions should be also considered to move to the
execution queue of the Timelock contract.
 Baby Doge - BSC Security Assessment

Findings

Critical 0 (0.00%)

Major 2 (15.38%)

13 Medium

Minor
1 (7.69%)

2 (15.38%)
Total Issues
Informational 8 (61.54%)

Discussion 0 (0.00%)

ID Title Category Severity Status

Centralization Risk in addLiquidity() Centralization /

CTC-01 Major Acknowledged
Function Privilege

Centralization /
CTC-02 Centralization Risk in Contract CoinToken Major Acknowledged
Privilege

Possible to Regain Ownership After

CTC-03 Logical Issue Medium Acknowledged
Renouncing the Contract Ownership

CTC-04 Incorrect Error Message Logical Issue Minor Acknowledged

CTC-05 Potential Sandwich Attacks Coding Style Minor Acknowledged

CTC-06 Redundant Statement Logical Issue Informational Acknowledged

CTC-07 Function Name Typo Coding Style Informational Acknowledged

CTC-08 Variable Could Be Declared as constant Gas Optimization Informational Acknowledged

CTC-09 Typos in Contract CoinToken Coding Style Informational Acknowledged

CTC-10 Lack of Return Value Handling Volatile Code Informational Acknowledged

Gas Optimization,
CTC-11 Function Should Be Declared External Informational Acknowledged
Language Specific

Lack of Event Emissions for Significant

CTC-12 Coding Style Informational Acknowledged
Transactions
 Baby Doge - BSC Security Assessment

ID Title Category Severity Status

Function and Variable Naming Doesn’t

CTC-13 Coding Style Informational Acknowledged
Match the Operating Environment
 Baby Doge - BSC Security Assessment

CTC-01 | Centralization Risk in addLiquidity() Function

Category Severity Location Status

Centralization / Privilege Major projects/CoinToken.sol (98ba012): 1103 Acknowledged

Description
The addLiquidity() function calls the uniswapV2Router.addLiquidityETH function with the to address
specified as owner() for acquiring the generated LP tokens from the corresponding pool. As a result, over
time the _owner address will accumulate a significant portion of LP tokens. If the _owner is an EOA
(Externally Owned Account), mishandling of its private key can have devastating consequences to the
project as a whole.

1098 uniswapV2Router.addLiquidityETH{value: ethAmount}(

1099 address(this),

1100 tokenAmount,

1101 0, // slippage is unavoidable

1102 0, // slippage is unavoidable

1103 owner(),

1104 block.timestamp

1105 );

Recommendation
We advise the to address of the uniswapV2Router.addLiquidityETH function call to be replaced by the
contract itself, i.e. address(this) , and to restrict the management of the LP tokens within the scope of
the contract’s business logic. This will also protect the LP tokens from being stolen if the _owner account
is compromised. In general, we strongly recommend centralized privileges or roles in the protocol to be
improved via a decentralized mechanism or via smart-contract based accounts with enhanced security
practices, f.e. Multisignature wallets.

Indicatively, here are some feasible solutions that would also mitigate the potential risk:

Time-lock with reasonable latency, i.e. 48 hours, for awareness on privileged operations;
Assignment of privileged roles to multi-signature wallets to prevent single point of failure due to the
private key;
Introduction of a DAO / governance / voting module to increase transparency and user involvement.

Alleviation
 Baby Doge - BSC Security Assessment

[BabyDoge Team]: The contract has been deployed at the address

0xc748673057861a797275CD8A068AbB95A902e8de. The contract's owner has been transfered to a
GnosisSafe Proxy deployed at the address 0x505d1180061727c59ce04e7acfc117283cf797f0, which
requires 2 out of 5 signers to sign.

The signers addresses are:

0x227982fAc9e83EE495394eA22aE89019f26a49Cf
0x67c2Ec1178725BCD749C2cfa162D6e015696BcE1
0x6d067E65Bc303d14d028425FB7cF0e0f79BA21a1
0x814E8543AdA1bD157299cDF460C67F7D319f4832
0xbDf48684035A65d05615522C71a10b1e10cADd54

All Signers are all trezor wallets password protected and all the wallets require the private key and
passwords to be accessed. The Team members have 2 wallets for daily use.
 Baby Doge - BSC Security Assessment

CTC-02 | Centralization Risk in Contract CoinToken

Category Severity Location Status

Centralization / projects/CoinToken.sol (98ba012): 846, 856, 879, 883, 887, 891,

Major Acknowledged
Privilege 895, 899, 903, 963

Description
In contract CoinToken , the owner role has the authority over the following functions:

CoinToken.excludeFromReward() : Exclude an arbitrary account from reward.

CoinToken.includeInReward() : Include an arbitrary account in reward.

CoinToken.excludeFromFee() : Exempt an arbitrary account from being taxed.

CoinToken.includeInFee() : Start to tax an arbitrary account.

CoinToken.setTaxFeePercent() : Set the tax fee percent.

CoinToken.setLiquidityFeePercent() : Set the liquidity fee percent.

CoinToken.setNumTokensSellToAddToLiquidity() : Set the number of tokens to be sold to add to

liquidity.
CoinToken.setMaxTxPercent() : Set the max transaction percentage.

CoinToken.setSwapAndLiquifyEnabled() : Enable/disable the swap and liquify.

CoinToken.claimTokens() : transfer the leftover BNB to the _owner address.

Any compromise to the _owner account may allow the hacker to take advantage of this and modify the
significant state of the contract, thus introducing centralization risk.

Recommendation
We advise the client to carefully manage the owner account private key carefully to avoid any potential
risks of being hacked.
In general, we strongly recommend centralized privileges or roles in the protocol to
be improved via a decentralized mechanism or smart-contract-based accounts with enhanced security
practices, e.g., Multisignature wallets.

Indicatively, here is some feasible suggestions that would also mitigate the potential risk at the different
level in term of short-term and long-term:

Time-lock with reasonable latency, e.g., 48 hours, for awareness on privileged operations;
Assignment of privileged roles to multi-signature wallets to prevent a single point of failure due to the
private key;
Introduction of a DAO/governance/voting module to increase transparency and user involvement.
 Baby Doge - BSC Security Assessment

Alleviation
[BabyDoge Team]: The contract has been deployed at the address
0xc748673057861a797275CD8A068AbB95A902e8de. The contract's owner has been transfered to a
GnosisSafe Proxy deployed at the address 0x505d1180061727c59ce04e7acfc117283cf797f0, which
requires 2 out of 5 signers to sign.

The signers addresses are:

0x227982fAc9e83EE495394eA22aE89019f26a49Cf
0x67c2Ec1178725BCD749C2cfa162D6e015696BcE1
0x6d067E65Bc303d14d028425FB7cF0e0f79BA21a1
0x814E8543AdA1bD157299cDF460C67F7D319f4832
0xbDf48684035A65d05615522C71a10b1e10cADd54

All Signers are all trezor wallets password protected and all the wallets require the private key and
passwords to be accessed. The Team members have 2 wallets for daily use.
 Baby Doge - BSC Security Assessment

CTC-03 | Possible to Regain Ownership After Renouncing the Contract

Ownership

Category Severity Location Status

Logical Issue Medium projects/CoinToken.sol (98ba012): 427 Acknowledged

Description
An owner is possible to gain ownership of the contract even if he calls the function renounceOwnership to
renounce the ownership. This can be achieved by performing the following operations:

1. Call lock to lock the contract. The variable _previousOwner is set to the current owner.
2. Call unlock to unlock the contract.
3. Call renounceOwnership to leave the contract without an owner.
4. Call unlock to regain ownership.

Recommendation
We advise updating/removing lock and unlock functions in the contract, or removing the
renounceOwnership if such a privilege retains at the protocol level. If timelock functionality could be

introduced, we recommend using the implementation of Compound finance as a reference.

Reference: https://github.com/compound-finance/compound-protocol/blob/master/contracts/Timelock.sol

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-04 | Incorrect Error Message

Category Severity Location Status

Logical Issue Minor projects/CoinToken.sol (98ba012): 857 Acknowledged

Description
The error message in require(_isExcluded[account], "Account is already excluded") does not
describe the error correctly.

Recommendation
The message "Account is already excluded" can be changed to "Account is not excluded" .

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-05 | Potential Sandwich Attacks

Category Severity Location Status

Coding Style Minor projects/CoinToken.sol (98ba012): 1101~1102 Acknowledged

Description
A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding
liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate
the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of
the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the
asset.

The following functions are called without setting restrictions on slippage or minimum output amount, so
transactions triggering these functions are vulnerable to sandwich attacks, especially when the input
amount is large:

1084 uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens(

1085 tokenAmount,

1086 0, // accept any amount of ETH

1087 path,

1088 address(this),

1089 block.timestamp

1090 );

1098 uniswapV2Router.addLiquidityETH{value: ethAmount}(

1099 address(this),

1100 tokenAmount,

1101 0, // slippage is unavoidable

1102 0, // slippage is unavoidable

1103 owner(),

1104 block.timestamp

1105 );

Recommendation
We recommend setting reasonable minimum output amounts, instead of 0, based on token prices when
calling the aforementioned functions.

Alleviation
 Baby Doge - BSC Security Assessment

The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-06 | Redundant Statement

Category Severity Location Status

Logical Issue Informational projects/CoinToken.sol (98ba012): 1118 Acknowledged

Description
The condition !_isExcluded[sender] && !_isExcluded[recipient] can be included in else .

Recommendation
The following code can be removed:

1117 ... else if (!_isExcluded[sender] && !_isExcluded[recipient]) {

1118 _transferStandard(sender, recipient, amount);

1119 } ...

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-07 | Function Name Typo

Category Severity Location Status

Coding Style Informational projects/CoinToken.sol (98ba012): 442 Acknowledged

Description
Function name is mistakenly set as geUnlockTime() .

Recommendation
We advise the client to fix the typo and set the correct name getUnlockTime() for the specific function.

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-08 | Variable Could Be Declared as constant

Category Severity Location Status

Gas Optimization Informational projects/CoinToken.sol (98ba012): 691, 695, 696, 697 Acknowledged

Description
Variables _tTotal , numTokensSellToAddToLiquidity , _name , _symbol and _decimals could be declared
as constant since these state variables are never to be changed.

Recommendation
We recommend declaring those variables as constant .

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-09 | Typos in Contract CoinToken

Category Severity Location Status

Coding Style Informational projects/CoinToken.sol (98ba012): 719, 908 Acknowledged

Description
There are several typos in the code and comments.

1. In the following code snippet, tokensIntoLiqudity should be tokensIntoLiquidity .

1 event SwapAndLiquify(

2 uint256 tokensSwapped,

3 uint256 ethReceived,

4 uint256 tokensIntoLiqudity

5 );

2. recieve should be receive and swaping should be swapping in the line of comment //to
recieve ETH from uniswapV2Router when swaping .

Recommendation
We recommend correcting all typos in the contract.

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-10 | Lack of Return Value Handling

Category Severity Location Status

Volatile Code Informational projects/CoinToken.sol (98ba012): 1098 Acknowledged

Description
The return values of function addLiquidityETH are not properly handled.

1098 uniswapV2Router.addLiquidityETH{value: ethAmount}(

1099 address(this),

1100 tokenAmount,

1101 0, // slippage is unavoidable

1102 0, // slippage is unavoidable

1103 owner(),

1104 block.timestamp

1105 );

Recommendation
We recommend using variables to receive the return value of the functions mentioned above and handle
both success and failure cases if needed by the business logic.

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-11 | Function Should Be Declared External

Category Severity Location Status

Gas Optimization, Language projects/CoinToken.sol (98ba012): 846, 82

Informational Acknowledged
Specific 9

Description
Functions which are never called internally within the contract should have external visibility. For example,

CoinToken.reflectionFromToken()

CoinToken.excludeFromReward()

Recommendation
We advise the client to change the visibility of the aforementioned functions to external .

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-12 | Lack of Event Emissions for Significant Transactions

Category Severity Location Status

Coding projects/CoinToken.sol (98ba012): 846, 856, 879, 883, 887, 891, 89

Informational Acknowledged
Style 5, 899, 903

Description
In the contract CoinToken there are a few functions that can change the state variables. However, these
functions do not emit events, passing the changes out of the chain. For example,

CoinToken.excludeFromReward()

CoinToken.includeInReward()

CoinToken.excludeFromFee()

CoinToken.includeInFee()

CoinToken.setTaxFeePercent()

CoinToken.setLiquidityFeePercent()

CoinToken.setNumTokensSellToAddToLiquidity()

CoinToken.setMaxTxPercent()

CoinToken.setSwapAndLiquifyEnabled()

Recommendation
We advise the client to emit events for all the essential state variables that are possible to be changed
during the runtime.

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

CTC-13 | Function and Variable Naming Doesn’t Match the Operating

Environment

Category Severity Location Status

Coding Style Informational projects/CoinToken.sol (98ba012): 1 Acknowledged

Description
There are multiple naming issues inside the current contract, which can be misleading to use Uniswap and
ETH instead of Pancakeswap and BNB if the project landing on BSC.

For example, the CoinToken contract uses Pancakeswap for swapping and adding liquidity to the
Pancakeswap pool but names it Uniswap .

Recommendation
Change "Uniswap" and "ETH" to "Pancakeswap" and "BNB" in the contract respectively to match the
operating environment and avoid confusion.

Alleviation
The development team acknowledged the finding and decided not to change the current codebase.
 Baby Doge - BSC Security Assessment

Appendix
Finding Categories

Centralization / Privilege
Centralization / Privilege findings refer to either feature logic or implementation of components that act
against the nature of decentralization, such as explicit ownership or specialized access roles in
combination with a mechanism to relocate funds.

Gas Optimization
Gas Optimization findings do not affect the functionality of the code but generate different, more optimal
EVM opcodes resulting in a reduction on the total gas cost of a transaction.

Logical Issue
Logical Issue findings detail a fault in the logic of the linked code, such as an incorrect notion on how
block.timestamp works.

Volatile Code
Volatile Code findings refer to segments of code that behave unexpectedly on certain edge cases that may
result in a vulnerability.

Language Specific
Language Specific findings are issues that would only arise within Solidity, i.e. incorrect usage of private or
delete.

Coding Style
Coding Style findings usually do not affect the generated byte-code but rather comment on how to make
the codebase more legible and, as a result, easily maintainable.

Checksum Calculation Method

The "Checksum" field in the "Audit Scope" section is calculated as the SHA-256 (Secure Hash Algorithm 2
with digest size of 256 bits) digest of the content of each file hosted in the listed source repository under
the specified commit.
 Baby Doge - BSC Security Assessment

The result is hexadecimal encoded and is the same as the output of the Linux "sha256sum" command
against the target file.
 Baby Doge - BSC Security Assessment

Disclaimer
This report is subject to the terms and conditions (including without limitation, description of services,
confidentiality, disclaimer and limitation of liability) set forth in the Services Agreement, or the scope of
services, and terms and conditions provided to you (“Customer” or the “Company”) in connection with the
Agreement. This report provided in connection with the Services set forth in the Agreement shall be used
by the Company only to the extent permitted under the terms and conditions set forth in the Agreement.
This report may not be transmitted, disclosed, referred to or relied upon by any person for any purposes,
nor may copies be delivered to any other person other than the Company, without CertiK’s prior written
consent in each instance.

This report is not, nor should be considered, an “endorsement” or “disapproval” of any particular project or
team. This report is not, nor should be considered, an indication of the economics or value of any
“product” or “asset” created by any team or project that contracts CertiK to perform a security
assessment. This report does not provide any warranty or guarantee regarding the absolute bug-free
nature of the technology analyzed, nor do they provide any indication of the technologies proprietors,
business, business model or legal compliance.

This report should not be used in any way to make decisions around investment or involvement with any
particular project. This report in no way provides investment advice, nor should be leveraged as investment
advice of any sort. This report represents an extensive assessing process intending to help our customers
increase the quality of their code while reducing the high level of risk presented by cryptographic tokens
and blockchain technology.

Blockchain technology and cryptographic assets present a high level of ongoing risk. CertiK’s position is
that each company and individual are responsible for their own due diligence and continuous security.
CertiK’s goal is to help reduce the attack vectors and the high level of variance associated with utilizing
new and consistently changing technologies, and in no way claims any guarantee of security or
functionality of the technology we agree to analyze.

The assessment services provided by CertiK is subject to dependencies and under continuing
development. You agree that your access and/or use, including but not limited to any services, reports,
and materials, will be at your sole risk on an as-is, where-is, and as-available basis. Cryptographic tokens
are emergent technologies and carry with them high levels of technical risk and uncertainty. The
assessment reports could include false positives, false negatives, and other unpredictable results. The
services may access, and depend upon, multiple layers of third-parties.

ALL SERVICES, THE LABELS, THE ASSESSMENT REPORT, WORK PRODUCT, OR OTHER MATERIALS,
OR ANY PRODUCTS OR RESULTS OF THE USE THEREOF ARE PROVIDED “AS IS” AND “AS
 Baby Doge - BSC Security Assessment

AVAILABLE” AND WITH ALL FAULTS AND DEFECTS WITHOUT WARRANTY OF ANY KIND. TO THE
MAXIMUM EXTENT PERMITTED UNDER APPLICABLE LAW, CERTIK HEREBY DISCLAIMS ALL
WARRANTIES, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE
SERVICES, ASSESSMENT REPORT, OR OTHER MATERIALS. WITHOUT LIMITING THE FOREGOING,
CERTIK SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AND ALL WARRANTIES ARISING FROM
COURSE OF DEALING, USAGE, OR TRADE PRACTICE. WITHOUT LIMITING THE FOREGOING, CERTIK
MAKES NO WARRANTY OF ANY KIND THAT THE SERVICES, THE LABELS, THE ASSESSMENT REPORT,
WORK PRODUCT, OR OTHER MATERIALS, OR ANY PRODUCTS OR RESULTS OF THE USE THEREOF,
WILL MEET CUSTOMER’S OR ANY OTHER PERSON’S REQUIREMENTS, ACHIEVE ANY INTENDED
RESULT, BE COMPATIBLE OR WORK WITH ANY SOFTWARE, SYSTEM, OR OTHER SERVICES, OR BE
SECURE, ACCURATE, COMPLETE, FREE OF HARMFUL CODE, OR ERROR-FREE. WITHOUT LIMITATION
TO THE FOREGOING, CERTIK PROVIDES NO WARRANTY OR UNDERTAKING, AND MAKES NO
REPRESENTATION OF ANY KIND THAT THE SERVICE WILL MEET CUSTOMER’S REQUIREMENTS,
ACHIEVE ANY INTENDED RESULTS, BE COMPATIBLE OR WORK WITH ANY OTHER SOFTWARE,
APPLICATIONS, SYSTEMS OR SERVICES, OPERATE WITHOUT INTERRUPTION, MEET ANY
PERFORMANCE OR RELIABILITY STANDARDS OR BE ERROR FREE OR THAT ANY ERRORS OR
DEFECTS CAN OR WILL BE CORRECTED.

WITHOUT LIMITING THE FOREGOING, NEITHER CERTIK NOR ANY OF CERTIK’S AGENTS MAKES ANY
REPRESENTATION OR WARRANTY OF ANY KIND, EXPRESS OR IMPLIED AS TO THE ACCURACY,
RELIABILITY, OR CURRENCY OF ANY INFORMATION OR CONTENT PROVIDED THROUGH THE
SERVICE. CERTIK WILL ASSUME NO LIABILITY OR RESPONSIBILITY FOR (I) ANY ERRORS, MISTAKES,
OR INACCURACIES OF CONTENT AND MATERIALS OR FOR ANY LOSS OR DAMAGE OF ANY KIND
INCURRED AS A RESULT OF THE USE OF ANY CONTENT, OR (II) ANY PERSONAL INJURY OR
PROPERTY DAMAGE, OF ANY NATURE WHATSOEVER, RESULTING FROM CUSTOMER’S ACCESS TO
OR USE OF THE SERVICES, ASSESSMENT REPORT, OR OTHER MATERIALS.

ALL THIRD-PARTY MATERIALS ARE PROVIDED “AS IS” AND ANY REPRESENTATION OR WARRANTY
OF OR CONCERNING ANY THIRD-PARTY MATERIALS IS STRICTLY BETWEEN CUSTOMER AND THE
THIRD-PARTY OWNER OR DISTRIBUTOR OF THE THIRD-PARTY MATERIALS.

THE SERVICES, ASSESSMENT REPORT, AND ANY OTHER MATERIALS HEREUNDER ARE SOLELY
PROVIDED TO CUSTOMER AND MAY NOT BE RELIED ON BY ANY OTHER PERSON OR FOR ANY
PURPOSE NOT SPECIFICALLY IDENTIFIED IN THIS AGREEMENT, NOR MAY COPIES BE DELIVERED TO,
ANY OTHER PERSON WITHOUT CERTIK’S PRIOR WRITTEN CONSENT IN EACH INSTANCE.

NO THIRD PARTY OR ANYONE ACTING ON BEHALF OF ANY THEREOF, SHALL BE A THIRD PARTY OR
OTHER BENEFICIARY OF SUCH SERVICES, ASSESSMENT REPORT, AND ANY ACCOMPANYING
 Baby Doge - BSC Security Assessment

MATERIALS AND NO SUCH THIRD PARTY SHALL HAVE ANY RIGHTS OF CONTRIBUTION AGAINST
CERTIK WITH RESPECT TO SUCH SERVICES, ASSESSMENT REPORT, AND ANY ACCOMPANYING
MATERIALS.

THE REPRESENTATIONS AND WARRANTIES OF CERTIK CONTAINED IN THIS AGREEMENT ARE

SOLELY FOR THE BENEFIT OF CUSTOMER. ACCORDINGLY, NO THIRD PARTY OR ANYONE ACTING
ON BEHALF OF ANY THEREOF, SHALL BE A THIRD PARTY OR OTHER BENEFICIARY OF SUCH
REPRESENTATIONS AND WARRANTIES AND NO SUCH THIRD PARTY SHALL HAVE ANY RIGHTS OF
CONTRIBUTION AGAINST CERTIK WITH RESPECT TO SUCH REPRESENTATIONS OR WARRANTIES OR
ANY MATTER SUBJECT TO OR RESULTING IN INDEMNIFICATION UNDER THIS AGREEMENT OR
OTHERWISE.

FOR AVOIDANCE OF DOUBT, THE SERVICES, INCLUDING ANY ASSOCIATED ASSESSMENT REPORTS
OR MATERIALS, SHALL NOT BE CONSIDERED OR RELIED UPON AS ANY FORM OF FINANCIAL, TAX,
LEGAL, REGULATORY, OR OTHER ADVICE.
 Baby Doge - BSC Security Assessment

About
Founded in 2017 by leading academics in the field of Computer Science from both Yale and Columbia
University, CertiK is a leading blockchain security company that serves to verify the security and
correctness of smart contracts and blockchain-based protocols. Through the utilization of our world-class
technical expertise, alongside our proprietary, innovative tech, we’re able to support the success of our
clients with best-in-class security, all whilst realizing our overarching vision; provable trust for all
throughout all facets of blockchain.