SPADESOLIDITYAUDITS

Telegram:t.me/spadeaudits

Twitter:@SpadeAudits

DogeX_Migration_ClientSeptember 29, 2021

For :DogeX_Migration_Client

Disclaimer

Spade Solidity 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 or project that contracts Spade to perform a security review.

Spade Solidity Reports do not provide any warranty or guarantee regarding the absolute bug-free nature of the technology analyzed, nor do theyprovide any indication of the technologies proprietors, business, business model or legal compliance. Spade Solidity Reports should not be used in any way to make decisions aroundinvestment or involvement with any particular project.These reports in no way provide investment advice, nor should be leveraged as investmentadvice of any sort.

Spade Solidity Reports represent an extensive auditing process intending to helpour customers increase the quality of their code while reducing the highlevel of risk presented by cryptographic tokens and blockchain technology.

Blockchain technology and cryptographic assets present a high level of ongoing risk. Spade Solidity’s position is that each company and individual are responsible for their own due diligence and continuous security. Spade Solidity’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.

What is a Spade Solidity report?

A document describing in detail an in depth analysis of a particular piece(s) of source code provided to Spade Solidity by a Client.

An organized collection of testing results, analysis and inferences made about the structure, implementation and overall best practices of a particular piece of source code.

Representation that a Client of Spade Solidity has indeed completed a round of auditing with the intention to increase the quality of the company/product’s IT infrastructure and or source code.

OVERVIEW

Project Name DogeX_Migration_Client

Description Token Migration

Platform Binance Smart Chain

Codebase Received file

Commit NA

Project Summary

Delivery Date September 29, 2021

Method of Audit Static Analysis, Manual Review

Timeline Story Points - 40

Audit Summary

Total Issues 5

Total Critical 0

Total High 0

Total Medium 1

Total Low 2

Total Informational 2

Vulnerability Summary

Executive SummaryThis report has been produced for the Dogex team to assess the security and functionality of their Token Migration Client.

The intended purpose of the system is to swap Dogex v1 tokens for v2 tokens without using a smart contract since liquidity is locked. The system uses a 3 Step process that securely swaps V1 tokens for V2 tokens after validations are complete. Our detailed audit methodology was as follows:

Step 1

A detailed line by line manual code review

Step 2

Step 3

Testing using Python Crontab

Full server dry run.

Step 4

Consultation with Team regarding issues identified.

Step 5

Checking code updates made by team.

Step 6

Publication.

Grading

The following grading structure was used to assess the level of vulnerability found within The Dogex Migration Code:

Threat Level Definition

Critical Severe vulnerabilities which compromise the entire protocol and could result in immediate data manipulation or asset loss.

HighSignificant vulnerabilities which compromise the functioning of the smart contracts leading to possible data manipulation or asset loss.

Medium

Vulnerabilities which if not fixed within in a set timescale could compromise the functioning ofthe smart contracts leading to possible data manipulation or asset loss.

LowLow level vulnerabilities which may or may not have an impact on the optimal performance of the Smart contract.

InformationalIssues related to coding best practice which do not have any impact on the functionality of the Smart Contracts.

Grading

Client Architecture

Frontend

ReactJS client side rendered application

NodeJS REST API

To handle sensitive information and process regarding validaitons

Python REST API

To register users that have migrated

Python microservice

To send V2 tokens to users that just migrated.

CONTRACT

app.py

autoswap.py

SHA-256 CHECKSUM

f79dcd3bec65d3e44976b3a1b6dcb6e1f4e83cb2a11d02fe2fa1b6853d2d0fa7

8b622e09c30fdea258b4b94a4736137146a60422

DOGEX AUDIT REPORT

Step 1 - Eligibility Check

The system uses a 3 Step process that securely swaps V1 tokens for V2 tokens after validations are complete.

The holder connects their wallet:

{ web3 walletconnect modal }The holder selects "migrate":*determine if current user is a snapshot candidate*

if (userWallet does not exist in snapshot) { False == proceed, true == provide error response/silent error

return (display to front end that user is not eligible for migration);}

*determine if migration has already occurred*

if (userWallet hasMigrated){ If history > 0, set migrated false, else set migrated true False == proceed, true == provide error response/silent error}

Step 2 - Send V1 tokens to Contract Owner Address

The amount of tokens that the "migrate" function sends is up to an amount that we have in database, taken from a snapshot of holders before migration began:

snapshotBalance(){ const v1Tokens = fetch number of v1 tokens associated with the wallet address from moralis snapshot return v1Tokens}

userBalance(){ if currentBalance of userwallet <= snapShotBalance, set currentBalance as userBalance else = send the full balance amount through but only give them the snapshot balance in return}

{ web3.eth.transfer Recipient 0x0861CEd5fBC8F46c4C4938C1ff8DD2018b2c95e9 Amount = balance from snapshot (will be in a db)}

The tokens are sent to the DogeX owner wallet.

Step 3 - Send V2 tokens to User address

{ web3.eth.transfer Sender owner wallet Private key stored as environmental variable}

The DogeX owner wallet sends them the new token at the determined rate:

Send user wallet to migration complete database for permanent storage.

Audit Results and Recommendations

Rest_API

File: app.py

line 38: the exception block is redundant.

Severity: Informational

Recommendation: n/a. Resolution Status: n/a.

Conclusion: The rest api to update the user to database is working fine. No bugs or security issues were identified.

Server

File : index.jsNo errors found

Recommendation: n/a. Resolution Status: n/a.

Conclusion: The code appears to be of a high standard. No bugs or security issues were identified.

File : migration.jsNo errors found

Recommendation: n/a. Resolution Status: n/a.

Conclusion: the backend code to check the user eligibility and to submit the migration is bug-free. Testing confirmed that the code correctly updated the maximum of snapshot balance or received token amount. Hence the snapshot check is correctly implemented, and users should receive the correct number of tokens to their wallets.

Autoswap script

File autoswap.py

line 64: Approve function should not be called.

By calling the approve function, account(adr) is allowed to spend 'amount' number of tokens from the owner account(address). This approve function is not at all required to call the transfer function on line 75. In the transfer function, owner(address) is signing a transaction to transfer tokens from his account to adr account. Thus no approve is required in this case. Code is sending user(adr) '2 * amount' equivalent of dogexV2 token.

Severity: Low

Recommendation: Remove approval function.

Resolution Status: Resolved.

Source code updated by DogeX team.

line 66,77,150: Hardcoded gas price

The gas price is hardcoded to 100 gwei which is approximately 10 times the average gas price on BSC mainnet.

Severity: Medium

Recommendation: Use function w3.eth.GasPrice() to set the gas price dynamically.

Resolution Status: Team made the following changes

Line 86: hardcoded error msgError message is hardcoded.

Severity: low

Recommendation: Instead of hardcoding the error message, use the error(e) in the error msg to display the actual error.

Resolution Status: ResolvedSource code updated by DogeX team.

File autoswap.py

Issue identified: Naming Variables

On lines 49, 104,105, 137, 140, 142 there are two different variables with the same name

Severity: Informational

Recommendation: The count on line 49,104,105 should be differentiated from count on line 137,140,142. Also after successfully adding liquidity the count (line 104) should be set to 0.

Resolution Status: ResolvedSource code updated by DogeX team.

Conclusion: The migration system designed by Dogex is well written and the team appear to have carefully considered the security and functionality of their code. The Spade audit found that there was a logical error regarding calling an unnecessary approve function. There were also a few cases where best practice was overlooked. Otherwise the functions for transferring dogexV2 token, selling V1 token and adding liquidity for V2 have been implemented appropriately.

The Dogex team have resolved all issues identified during the audit prior to the launch of the platform. The Spade Audit team can never give absolute guarantees about the security and functionality of any system or protocol, but our detailed review of the Dogex Migration Client found that it functions as intended. No security issues were identified.

Appendix

Finding Categories

Gas OptimizationGas Optimization findings refer to exhibits that do not affect thefunctionality of the code but generate different, more optimal EVM opcodes resulting in a reduction on the total gas cost of a transaction.

Mathematical OperationsMathematical Operation exhibits entail findings that relate to mishandling of math formulas, such as overflows, incorrect operations etc.

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

Control FlowControl Flow findings concern the access control imposed on functions, such as owner-only functions being invoke-able by anyone under certain circumstances.

Volatile CodeVolatile Code findings refer to segments of code that behave unexpectely on certain edge cases that may result in avulnerability.

Data FlowData Flow findings describe faults in the way data is handled at rest and in memory, such as the result of a structassignment operation affecting an in-memory struct rather than an instorage one.

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

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

InconsistencyInconsistency findings refer to functions that should seemingly behave similarly yet contain different code, such as a constructor assignment imposing different require statements on the input variables than a setter function.

Magic NumbersMagic Number findings refer to numeric literals that are expressed in the codebase in their raw format and should otherwise be specified as constant contract variables aiding in their legibility and maintainability.

Compiler ErrorCompiler Error findings refer to an error in the structure of the code that renders it impossible to compile using the specified version of the project.

Dead CodeCode that otherwise does not affect the functionality of the codebase and can be safely omitted.