PlayDoge

AUDIT
SECURITY ASSESSMENT

22. May, 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
FutureVisions Deutschland, 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 PlayDoge
Website https://playdoge.io/en
About the project PlayDoge is a mobile-based play-to-earn (P2E) game
that transforms the iconic Doge meme into a
Tamagotchi-style virtual pet. Embrace the 90s nostalgia!
Buy $PLAY tokens in presale to enjoy classic 2D
adventure games and earn more crypto!
Chain TBA
Language Solidity
Codebase https://bscscan.com/address/0xb68a20b9e9B06fDE8738
97e12Ab3372ce48F1A8A#code
Commit N/A
Unit Tests Not Provided

Social Medias
Telegram https://t.me/PlayDogeGame
Twitter https://x.com/PlayDogeGame
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 22. May 2024 • Layout Project

• Automated/ Manual-Security Testing
• Summary

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 kcgdiy853d1u8b19ea3894bf824f74e1a38fdgh76

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 2 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

24 0

External Internal Private Pure View

10 26 0 0 16

StateVariables

Total Public

13 6

7
Capabilities

Solidity Can Has

🖥 Uses
Versions Experimental Receive Destroyable
observed Assembly
Features Funds Contracts

0.8.9 ---------- 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. Hence,

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 N/A

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 ➢ There are no ownership privileges in this contract.

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
- 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.

19
Audit Result
Critical Issues
No critical issues

High Issues
No high issues

Medium Issue
No medium issues

Low Issue
No low issues

Informational Issue

#1 | NatSpec Documentation missing.

File Severity Location Status

Token.sol Informational -- Open

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

all other functions, variables, etc.

20
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.

21