Scribd
Upload
50 views6 pages

DGR Security Audit

This document summarizes a security audit of a smart contract. The auditor found that the contract is protected against reentrancy attacks, overflow and underflow issues, replay attacks, and reordering attacks. However, it notes that the release time of admin funds can be influenced by miners and the BURN function could allow tokens to be maliciously burned. The core functionality is tested and proved secure, but no audit can 100% guarantee the code is secure. Overall the contract is well-commented and performs as intended, with only minor risks noted.

Uploaded by

James Crash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
50 views6 pages

DGR Security Audit

This document summarizes a security audit of a smart contract. The auditor found that the contract is protected against reentrancy attacks, overflow and underflow issues, replay attacks, and reordering attacks. However, it notes that the release time of admin funds can be influenced by miners and the BURN function could allow tokens to be maliciously burned. The core functionality is tested and proved secure, but no audit can 100% guarantee the code is secure. Overall the contract is well-commented and performs as intended, with only minor risks noted.

Uploaded by

James Crash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Degare : Security Audit

Coder : Gavin Bachman


Auditor : Chad Baswick
Owner : aryan145
Reentrancy Attack:
Because this contract uses ​transfer()​ instead of ​call.value()​ , there’s
no risk of reentrancy attacks since the transfer function only
allows to use 23.000 gas which you can only use for an event to
log data and throws on failure. That way you’re unable to
recursively call again the sender function thus avoiding the
reentrancy attack

Over and under flows:


Overflow : an amount sent would be 2**256, this would set the
value to 0.
Underflow : a value of 0 causes an underflow, an underflow
happens when you try to substract 0 minus a number bigger than
0. For example, if you substract 0 -1 the result will be = 2**256
instead of -1.

No risk as ​OpenZeppelin’s SafeMath.sol​ was used for all


mathematical functions, which ensures these problems do not
happen.
Replay attack
No Risk : Fixed by Vitalik Buterin, ETH and ETHClassic no longer
communicate

Reordering attack
No Risk : There is no Racing in this contract between users.

Release difference
Warning: Block.timestamp was used to determine the release time
of the admin locked funds. This can be influenced by Miners, and
will not be on the exact 2 months mark. This is not an issue as the
range is not second specific, therefore it will release on the day but
not on the exact second.

Gas infinite
Warning: Some functions have infinite gas warnings, this can be
safely ignored as requirements have been implemented to
mitigate such problems of not being able to transact.

Only Owner Functions


Some functions are only used by the owner and contract deployer,
if the owner account is compromised and hacked all the owner
funds can be lost.
Dangerous Functions
Implemented function of BURN, burns a person's own supply of
the token if not used carefully this will cause a person to burn all
their supply losing money. Hacked and malicious accounts could
burn the persons tokens.

Gas Deployment
Contract has ERC20 functionality and can be deployed,
recommended amount of gas needed is 5000000 to deploy this
contract.

Admin Release
A custom function was implemented in the smart contract to be
able to test the functionality of the RELEASE() by setting the time
to ZERO once a locked transaction is sent. It was then released
into the Admin Account proving functionality works. This
function is removed from the final contract as it is untrustworthy
to have such a function.

Functionality
The core functionality of the contract is tested and proved to be
secure.
Fig 1. Passing all the tests proving that the core functionality works.

Summary of the audit


Overall the code is well commented and clear on what it’s
supposed to do for each function. The contract is not far from the
BOMB one, the major differences are the Buy/Sell percentages,
SimpleTransfer and Locked Funds for Admins. All functionality is
secure and shouldn’t bring any issues.

Note that this audit isn’t a legal document that verifies that the
code is secure. Nobody can 100% assure that the code won’t have
future bugs or vulnerabilities. It’s a guarantee that your code has
been revised by an expert and it’s secure.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy