Dogesquared
AUDIT
SECURITY ASSESSMENT
04. November, 2024
FOR
SolidProof_io @solidproof_io
Introduction 4
Disclaimer 4
Project Overview 5
Summary 5
Social Medias 5
Audit Summary 6
File Overview 7
Imported packages 8
Audit Information 9
Vulnerability & Risk Level 9
Auditing Strategy and Techniques Applied 10
Methodology 10
Overall Security 11
Upgradeability 11
Ownership 12
Ownership Privileges 13
Minting tokens 13
Burning Tokens without Allowance 14
Blacklist addresses 15
Fees and Tax 16
Lock User Funds 17
Components 18
Exposed Functions 18
StateVariables 18
Capabilities 19
Inheritance Graph 20
Centralization Privileges 21
Audit Results 22
Critical issues 22
High issues 22
2
Medium issues 22
Low issues 22
Informational issues 22
3
Introduction
[Link] is a brand of the of cially registered company Future Visions
Deutschland. We’re mainly focused on Blockchain Security, such as Smart Contract
Audits and KYC veri cation for project teams.
[Link] assesses potential security issues in the smart contracts
implementations, reviews for potential inconsistencies between the code base and
the whitepaper/documentation, and provides suggestions for improvement.
Disclaimer
[Link] reports are not, nor should they be considered, an “endorsement” or
“disapproval” of any particular project or team. These reports are not, nor should
they be considered, an indication of the economics or value of any “product” or
“asset” created by any team. [Link] does not cover testing or auditing the
integration with external contracts or services (such as Unicrypt, Uniswap,
PancakeSwap, etc.).
[Link] Audits do not provide any warranty or guarantee regarding the
absolute bug-free nature of the technology analysed, 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.
[Link] 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 analyse.
4
fi
fi
Project Overview
Summary
Project Name Dogesquared
Website [Link]
About the project Rede ning the future of Dogecoin.
Chain Ethereum
Language Solidity
Codebase Link [Link]
0x64F54456Acb3787141D2dD6D0c2Df2F56318682c#code
Commit N/A
Unit Tests Not Provided
Social Medias
Telegram [Link]
Twitter [Link]
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
5
fi
Audit Summary
Version Delivery Date Changelog
• Layout Project
v1.0 30. October 2024 • Automated- /Manual-Security Testing
• Summary
v1.1 04. November 2024 • Reaudit
Note - The following audit report presents a comprehensive security analysis of the
smart contract utilized in the project that includes malicious outside manipulation of
the contract’s functions. 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.
6
File Overview
The Team provided us with the les that should be tested in the security
assessment. This audit covered the following les listed below with an SHA-1 Hash.
File Name SHA-1 Hash
[Link] 56ca21c18fb7d7d4ac57311b23b6e2a8151edf52
Please note: Files with a different hash value than in this table have been modi ed after the
security check, either intentionally or unintentionally. A different hash value may (but need not)
indicate a changed state or potential vulnerability that was not the subject of this scan.
7
fi
fi
fi
Imported packages
Used code from other Frameworks/Smart Contracts (direct imports).
Dependency / Import Path Count
@openzeppelin/contracts/access/[Link] 1
@openzeppelin/contracts/token/ERC20/[Link] 1
@openzeppelin/contracts/token/ERC20/extensions/[Link] 1
@openzeppelin/contracts/token/ERC20/extensions/[Link] 1
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
8
Audit Information
Vulnerability & Risk Level
Risk represents the probability that a certain source threat will exploit 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
contract functioning in a number of Immediate action to
Critical 9 - 10
scenarios, or creates a risk that the reduce risk level.
contract may be broken.
A vulnerability that affects the desired
Implementation of
outcome when using a contract, or
High 7 – 8.9
provides the opportunity to use a
corrective actions as
soon aspossible.
contract in an unintended way.
A vulnerability that could affect the Implementation of
Medium 4 – 6.9 desired outcome of executing the corrective actions in a
contract in a speci c scenario. certain period.
A vulnerability that does not have a
Implementation of
signi cant impact on possible
Low 2 – 3.9
scenarios for the use of the contract
certain corrective actions
or accepting the risk.
and is probably subjective.
A vulnerability that have informational An observation that does
Informational 0 – 1.9 character but is not effecting any of the not determine a level of
code. risk
9
fi
fi
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 speci cations 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 le 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. Review the speci cations, sources, and instructions provided to
SolidProof to ensure we understand the smart contract's size, scope, and
functionality.
b. Manual review of the code, i.e., reading the source code line by line to
identify potential vulnerabilities.
c. Comparison to the speci cation, i.e., verifying that the code does what is
described in the speci cations, 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 is analysing a program to determine what inputs
cause each part of a program to execute.
3. Review best practices, i.e., smart contracts to improve ef ciency, 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.
10
fi
fi
fi
fi
fi
fi
Overall Security
Upgradeability
✅ Deployer cannot update the contract with new
Contract is not an upgradeable
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
11
Ownership
Contract ownership is not
❌ The ownership is not renounced
renounced
Description The owner has not renounced the ownership that means
that the owner retains control over the contract’s
operations, including the ability to execute functions that
may impact the contract’s users or stakeholders. This can
lead to several potential issues, including:
• Centralizations
• The owner has signi cant control over contract’s
operations
Example We assume that you have funds in the contract and it has
been audited by any security audit rm. Now the audit has
passed. After that, the deployer can upgrade the contract
to allow him to transfer the funds you purchased without
any approval from you. This has the consequence that
your funds can be taken by the creator.
Comment N/A
Note - If the contract is not deployed then we would consider the ownership to be
not renounced. Moreover, if there are no ownership functionalities then the
ownership is automatically considered renounced.
12
fi
fi
Ownership Privileges
These functions can be dangerous. Please note that abuse can lead to nancial loss. We have a
guide where you can learn more about these Functions.
Minting tokens
Minting tokens refers 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
can add new tokens to the network's total supply.
Contract owner cannot mint
✅ The owner cannot mint new tokens
new tokens
Description The owner is not able to mint new tokens once the contract is
deployed.
Comment N/A
13
fi
Burning Tokens without Allowance
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 burn
✅ The owner cannot burn tokens
tokens
Description The owner is not able to burn tokens without any allowances.
Comment N/A
14
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
✅ The owner cannot blacklist addresses
blacklist addresses
Description The owner is not able to blacklist addresses to lock funds.
Comment N/A
15
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 contract's cost, such as paying for gas fees or compensating the contract's
owner for their time and effort in developing and maintaining the contract.
Contract owner cannot set
✅ The owner cannot levy unfair taxes
fees more than 25%
Description The owner is not able to set the fees above 25%
Comment N/A
16
Lock User Funds
In a smart contract, locking refers to the process of restricting access to certain
tokens or assets for a speci ed period of time. When tokens 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.
Owner cannot lock the contract ✅ The owner cannot lock the contract
Description The owner is not able to lock the contract by any functions or
updating any variables.
Comment N/A
17
fi
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
speci ed using the function declaration's external or public visibility modi er.
State variables
State variables are variables that are stored on the blockchain as part of the contract's state. They
are declared at the contract level and can be accessed and modi ed by any function within the
contract. State variables can be de ned with a visibility modi er, such as public, private, or internal,
which determines the access level of the variable.
Components
📝 Contracts 📚 Libraries 🔍 Interfaces 🎨 Abstract
1 0 0 0
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
4 0
External Internal Private Pure View
4 5 0 0 2
StateVariables
Total 🌐 Public
2 0
18
fi
fi
fi
fi
fi
Capabilities
Solidity
Transfers 💰 Can 🖥 Uses 💣 Has
Versions Receive Assembl Destroyable
ETH
observed Funds y Contracts
0.8.24
19
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 methods from another class. It shows the relationships
between different contracts and how they are related to each other through inheritance.
20
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 a single entity
controls the contract or if certain participants have special permissions or abilities that others do
not.
In the project, some authorities have access to the following functions:
File Privileges
[Link] • The owner can enable trading only once.
• The owner can whitelist wallets for transferring of tokens without
enabling trade.
Recommendations
To avoid potential hacking risks, the client should 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 can no longer modify any
state variables of the contract. Make sure to set up everything before renouncing.
21
Audit Results
Critical issues
No critical issues
High issues
No high issues
Medium issues
#1 | Transfer of tokens without enabling trade.
File Severity Location Status
[Link] Medium L125-138 Open
Description - The trading needs to be enabled by the owner in order for regular
users to transfer tokens. On the contrary, the owner can authorize addresses
manually and those addresses will be able to trade tokens. This functionality can be
exploited in the following way, For example, there is a presale and the wallets used
for the presale can be authorized by the owner. All the tokens obtained can be
consolidated into a nal wallet address and facilitate trading and selling of the
acquired tokens, the last wallet address can be authorized.
Low issues
No low issues
Informational issues
#1 | NatSpec documentation missing
File Severity Location Status
All Informational — Open
Description - If you started to comment on your code, comment on all other
functions, variables etc.
22
fi
Legend for the Issue Status
Attribute or Symbol Meaning
Open The issue is not xed by the project team.
Fixed The issue is xed by the project team.
The issue has been acknowledged or declared as part
Acknowledged(ACK)
of business logic.
23
fi
fi
24
