King of Memes

AUDIT
SECURITY ASSESSMENT

11. April, 2024

FOR

SolidProof_io @solidproof_io
Introduction 3
Disclaimer 3
Project Overview 4
Summary 4
Social Medias 4
Audit Summary 5
File Overview 6
Imported packages 6
Components 7
Exposed Functions 7
Capabilities 8
Inheritance Graph 9
Audit Information 10
Vulnerability & Risk Level 10
Auditing Strategy and Techniques Applied 11
Methodology 11
Overall Security 12
Upgradeability 12
Ownership 13
Ownership Privileges 14
Minting tokens 14
Burning tokens 15
Blacklist addresses 16
Fees and Tax 17
Lock User Funds 18
Centralization Privileges 19
Audit Results 20

2
Introduction
SolidProof.io is a brand of the officially registered company MAKE
Network GmbH, based in Germany. We’re mainly focused on
Blockchain Security such as Smart Contract Audits and KYC verification
for project teams.
Solidproof.io assess potential security issues in the smart contracts
implementations, review for potential inconsistencies between the
code base and the whitepaper/documentation, and provide
suggestions for improvement.

Disclaimer
SolidProof.io reports are not, nor should be considered, an
“endorsement”or “disapproval” of any particular project or team. These
reports are not, nor should be considered, an indication of the
economics or value of any “product” or “asset” created by any team.
SolidProof.io do not cover testing or auditing the integration with
external contract or services (such as Unicrypt, Uniswap, PancakeSwap
etc’...)

SolidProof.io Audits do not provide any warranty or guarantee

regarding the absolute bug-free nature of the technology analyzed,
nor do they provide any indication of the technology proprietors.
SolidProof Audits should not be used in any way to make decisions
around investment or involvement with any particular project. These
reports in no way provide investment advice, nor should be leveraged
as investment advice of any sort.

SolidProof.io Reports represent an extensive auditing 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. SolidProof’s
position is that each company and individual are responsible for their
own due diligence and continuous security. SolidProof in no way
claims any guarantee of the security or functionality of the
technology we agree to analyze.

3
Project Overview
Summary
Project Name King of Memes
Website https://kingofmemes.vip/
About the project Welcome to the world of King Of Memes (KING), a
revolutionary memecoin project led by an experienced
developer with a trusted reputation in the crypto space.
This whitepaper dives deep into the unique features,
innovative strategies, and strong team behind KING,
showcasing why it stands out as a promising investment
opportunity in the memecoin market. Join us as we
explore the fusion of memes, technology, and
community to create a memeconomy like never before.
Chain Basescan
Language Solidity
Codebase https://basescan.org/token/0x420b0FA3dE2EFCf2b2Fd0
4152Eb1Df36a09717cD#code
Commit N/A
Unit Tests Not Provided

Social Medias
Telegram https://t.me/Kingofmemesreal
Twitter https://twitter.com/kingofmemesreal
Facebook N/A
Instagram N/A
GitHub N/A
Reddit N/A
Medium N/A
Discord N/A
YouTube N/A
TikTok N/A
LinkedIn N/A

4
Audit Summary
Version Delivery Date Change Log

v1.0 05. April 2024 • Layout Project

• Automated/ Manual-Security Testing
• Summary
v1.1 11. April 2024 • Reaudit

Note – The following audit report presents a comprehensive security

analysis of the smart contract utilized in the project that includes
outside manipulation of the contract’s functions in a malicious way.
This analysis did not include functional testing (or unit testing) of the
contract/s logic. We cannot guarantee 100% logical correctness of the
contract as we did not functionally test it. This includes internal
calculations in the formulae used in the contract.

5
 File Overview
The Team provided us with the files that should be tested in the
security assessment. This audit covered the following files listed below
with an SHA-1 Hash.

File Name SHA-1 Hash

contracts/Token.sol 47dd592d5684605f1cd5c3703967c449e86a9219

Please note: Files with a different hash value than in this table have been modified
after the security check, either intentionally or unintentionally. A different hash
value may (but need not) be an indication of a changed state or potential
vulnerability that was not the subject of this scan.

Imported packages.
Used code from other Frameworks/Smart Contracts.

N/A

Note for Investors: We only audited contracts mentioned in the scope

above. All contracts related to the project apart from that are not a part of
the audit, and we cannot comment on its security and are not responsible
for it in any way.

6
External/Public functions
External/public functions are functions that can be called from outside of a contract,
i.e., they can be accessed by other contracts or external accounts on the blockchain.
These functions are specified using the function declaration’s external or public
visibility modifier.

State variables
State variables are variables that are stored on the blockchain as part of the
contract'sstate. They are declared at the contract level and can be accessed
and modified by any function within the contract. State variables can
be needed within visibility modifier, such as public, private or internal,
which determines the access level of the variable.

Components
Contracts Libraries Interfaces Abstract

1 0 0 2

Exposed Functions
This section lists functions that are explicitly declared public or payable.
Please note that getter methods for public stateVars are not included.

Public Payable

18 1

External Internal Private Pure View

6 28 7 1 4

StateVariables

Total Public

20 15

7
Capabilities

Solidity Can Has

🖥 Uses
Versions Experimental Receive Destroyable
observed Assembly
Features Funds Contracts

0.8.19 ---------- Yes ----------

Low- Uses
Transfer Level Delegate Hash New/Create/
ECRecover
s ETH Calls Call Functions Create2
yes

8
Inheritance Graph
An inheritance graph is a graphical representation of the inheritance hierarchy
among contracts. In object-oriented programming, inheritance is a mechanism
that allows one class (or contract, in the case of Solidity) to inherit properties and
methodsfrom another class. It shows the relationships between different contracts
and how they are related to each other through inheritance.

9
Audit Information
Vulnerability & Risk Level
Risk represents the probability that a certain source threat will exploit
the vulnerability and the impact of that event on the organization or
system.The risk level is computed based on CVSS version 3.0.

Level Value Vulnerability Risk (Required Action)

A vulnerability that can disrupt the

Critical 9 - 10
contract functioning in a number Immediate action to
of scenarios, or creates a risk that reduce risk level.
the contract may be broken.

A vulnerability that affects the

desired outcome when using a Implementation of
High 7 – 8.9
contract, or provides the corrective actions as
opportunity to use a contract in an soon aspossible.
unintended way.

A vulnerability that could affect Implementation of

Medium 4 – 6.9 the desired outcome of corrective actions in a
executingthe contract in a certain period.
specific scenario.

A vulnerability that does not have

a significant impact on possible Implementation of
Low 2 – 3.9
scenarios for the use of the certain corrective
contract and is probably actions or accepting
subjective. the risk.

A vulnerability that have An observation that

Informational 0 – 1.9 informational character but is not does not determine a
effecting any of the code. level of risk

10
Auditing Strategy and Techniques Applied
Throughout the review process, care was taken to check the repository
for security-related issues, code quality, and compliance with
specifications and best practices. To this end, our team of experienced
pen-testers and smart contract developers reviewed the code line by
line and documented any issues discovered.

We check every file manually. We use automated tools only so that

they help us achieve faster and better results.

Methodology
The auditing process follows a routine series of steps:

1. Code review that includes the following:

a. Reviewing the specifications, sources, and instructions
provided to
SolidProof to ensure we understand the size, scope, and
functionality of the
smart contract.
b. Manual review of the code, i.e., reading the source code line
by line to identify potential vulnerabilities.
c. Comparison to the specification, i.e., verifying that the code
does what is described in the specifications, sources, and
instructions provided to SolidProof.

2. Testing and automated analysis that includes the following:

a. Test coverage analysis determines whether test cases cover
code and how much code is executed when those test cases
are executed.
b. Symbolic execution, which is analysing a program to
determine what inputs cause each part of a program to
execute.

3. Review best practices, i.e., review smart contracts to improve efficiency,

effectiveness, clarity, maintainability, security, and control based on
best practices, recommendations, and research from industry and
academia.

4. Concrete, itemized and actionable recommendations to help you

secure your smart contracts.

11
Overall Security
Upgradeability
Deployer cannot update the contract
Contract is not an upgradable with new functionalities.

Description The contract is not an upgradeable contract. The

Deployer is not able to change or add any
functionalities to the contract after deploying.
Comment N/A

12
Ownership
The ownership
Contract is
ownership is
The ownership is renounced.
renounced.
renounced.

Description The ownership of the token is renounced, which

means that the owner cannot change any settings
in the contract.
Comment N/A

Note – The contract cannot be considered as renounced till it is not deployed

or having some functionality that can change the state of the contract.

13
Ownership Privileges
These functions can be dangerous. Please note that abuse can lead to financial loss.
We have a guide where you can learn more about these Functions.

Minting tokens
Minting tokens refer to the process of creating new tokens in a cryptocurrency or
blockchain network. This process is typically performed by the project's owner or
designated authority, who has the ability to add new tokens to the network's total
supply.

Description The owner is not able to mint new tokens once

the contract is deployed.
Comment N/A

14
Burning tokens
Burning tokens is the process of permanently destroying a certain number of
tokens, reducing the total supply of a cryptocurrency or token. This is usually done
to increase the value of the remaining tokens, as the reduced supply can create
scarcity and potentially drive up demand.

Contract owner cannot The owner cannot burn tokens.

burn tokens

Description The owner is not able burn tokens without

any allowances.
Comment N/A

15
Blacklist addresses
Blacklisting addresses in smart contracts is the process of adding
a certain address to a blacklist, effectively preventing them from
accessing or participating in certain functionalities or transactions
within the contract. This can be useful in preventing fraudulent or
malicious activities, such as hacking attempts or money laundering.

Contract owner cannot

blacklist addresses. The owner cannot blacklist wallets.

Description The owner cannot blacklist wallets from

transferring of tokens.
Comment N/A

16
Fees and Tax
In some smart contracts, the owner or creator of the contract can
set fees for certain actions or operations within the contract. These
fees can be used to cover the cost of running the contract, such as
paying for gas fees or compensating the contract's owner for their
time and effort indeveloping and maintaining the contract.

Contract owner cannot

The owner cannot set fees more than 25%.
set fees more than 25%.

Description The owner cannot set fees of more than 25%.

Comment The owner can update the marketing and
liquidity fees of not more than 25%.

17
Lock User Funds
In a smart contract, locking refers to the process of restricting access
to certain tokens or assets for a specified period of time. When token
or assets are locked in a smart contract, they cannot be transferred or
used until the lock-up period has expired or certain conditions have
been met.

Contract owner cannot

can lock
lock function. The owner
ownercan lock lock
cannot the contract.
function.
functions.

Description The owner cannot lock the contract.

Comment N/A

18
Centralization Privileges
Centralization can arise when one or more parties have privileged access or
control over the contract's functionality, data, or decision-making. This can occur,
for example, if the contract is controlled by a single entity or if certain participants
have special permissions or abilities that others do not.

In the project, there are authorities that have access to the following
functions:

File Privileges
Token.sol ➢ The owner can update the minimum swap threshold
from 0.01% to 5% in the contract.
➢ The owner can update the marketing wallet address.
➢ The owner can update the marketing and liquidity fees
not more than 25% in the contract.
➢ The owner can exclude wallets from fees.
➢ The owner can update the AMM pair in the contract.
➢ The owner can exclude wallets from limits.
➢ The owner can update the max wallet limit to not less
than 0.1% of the total supply.
➢ The owner can update the buy and sell limit to not less
than 0.05% of the total supply.
➢ The owner can update the trade cooldown time to not
more than 12 hours.
TokenRecover.sol ➢ The owner can claim stuck tokens excluding contract’s
own tokens.

Recommendations
To avoid potential hacking risks, it is advisable for the client to manage
the private key of the privileged account with care. Additionally, we
recommend enhancing the security practices of centralized privileges
or roles in the protocol through a decentralized mechanism or smart-
contract-based accounts, such as multi-signature wallets.

Here are some suggestions of what the client can do:

- Consider using multi-signature wallets: Multi-signature wallets

require multiple parties to sign off on a transaction before it can be
executed, providing an extra layer of security e.g. Gnosis Safe
- Use of a timelock at least with a latency of e.g. 48-72 hours for
awareness of privileged operations

19
- Introduce a DAO/Governance/Voting module to increase
transparency and user involvement
- Consider Renouncing the ownership so that the owner cannot
modify any state variables of the contract anymore. Make sure to set
up everything before renouncing.

20
Audit Result
Critical Issues
No critical issues

High Issues
No high issues

Medium Issue

#1 | Missing ‘require’ check (Potential honeypot).

File Severity Location Status

Token.sol Medium L142-150 Fixed

Description – The owner can update the marketing wallet address to any
contract’s address which is not recommended as this can leads to
potential honeypot if the owner has set the marketing wallet address that
cannot receive ETH. There must be a ‘require’ check so that the owner
cannot set the address to a contract address that cannot receive ETH.

#2 | Regain ownership.
File Severity Location Status

Ownable2Step.sol Medium -- Fixed

Description – The owner can regain ownership after transferring it with the
following steps:
1. Call lock function to set _previousOwner to the own address
2. Call unlock function to get ownership back
3. Transfer/renounce ownership
4. Call unlock function to get ownership back
Make sure to set the _previousOwnership back to address zero after using
the unlock function.

Low Issue
No low issues

21
Informational Issue

#1 | NatSpec Documentation missing.

File Severity Location Status

Token.sol Informational -- ACK

Description – If you started to comment on your code, also comment on

all other functions, variables, etc.

22
Legend for the Issue Status
Attribute or Symbol Meaning

Open The issue is not fixed by the project team.

Fixed The issue is fixed by the project team.
The issue has been acknowledged or declared as
Acknowledged(ACK)
part of business logic.

23