`block.timestamp` is used for comparison, which can be risky since timestamp can be influenced by miners. That means the miner creating the block can manipulate the `block.timestamp`, to some degree, and change the outcome of the transaction.

Usage of `block.timestamp`

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Variables That Could Be Declared as Immutable

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to different compiler versions. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Unlocked Compiler Version

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions unless they view or pure types. 

Improper Usage of `public` and `external` Type

The `transferFrom` function transfers tokens before updating the storage variables. This does not follow the Checks-Effects-Interactions pattern.

TransferFrom Alters State After Transfer

Pure functions are used when there are no variables to be changed or read. While view functions are used to read information from state.

Pure Functions Read From State 

The functions `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens()` and `uniswapV2Router.addLiquidityETH()` in the aforementioned lines are executed without setting restrictions on slippage, which would make the swapping and liquidity-adding processes sensitive to price fluctuation from the DEX. In this case, it would be vulnerable to potential sandwich attacks, and thus the project might suffer unexpected losses.

In the case of this token, the `uniswapV2Router` calls `swapExactTokensForETHSupportingFeeOnTransferTokens()` when transfers are called. The potential loss of funds will be restricted to fees collected when `transfer` is called. Therefore, loss of funds are only at risk during large transfers.

Potential Sandwich Attack

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

In the contract `ScratchToken` the role `_owner` has authority over the functions shown in the diagram below. If the `_owner` account is compromised then the attacker is able to exclude themselves from fees and set the fees address to a personally controlled account. 

![](https://accelerator-tasks-prod.s3.amazonaws.com/b208d977015b4ce6a7372cc19429cf2b/diagrams/centralization-ScratchToken-_owner.svg)

Centralization Risk in ScratchToken.sol

Addresses should be checked before assignment or external call to make sure they are not zero addresses.

File: projects/ScratchToken/contracts/ScratchToken.sol (Line 169, Function `ScratchToken.constructor`)
```solidity
        _lpTokensWallet = exchangeWallet_;
```
- `exchangeWallet_` is not zero-checked before being used.


---
File: projects/ScratchToken/contracts/ScratchToken.sol (Line 172, Function `ScratchToken.constructor`)
```solidity
        _developmentWallet = developmentWallet_;
```
- `developmentWallet_` is not zero-checked before being used.


---
File: projects/ScratchToken/contracts/ScratchToken.sol (Line 175, Function `ScratchToken.constructor`)
```solidity
        _operationsWallet = operationsWallet_;
```
- `operationsWallet_` is not zero-checked before being used.


---
File: projects/ScratchToken/contracts/ScratchToken.sol (Line 177, Function `ScratchToken.constructor`)
```solidity
        _archaWallet = archaWallet_;
```
- `archaWallet_` is not zero-checked before being used.


---
File: projects/ScratchToken/contracts/ScratchToken.sol (Line 222, Function `ScratchToken.setArchaWallet`)
```solidity
        _archaWallet = newWallet;
```
- `newWallet` is not zero-checked before being used.


---
File: projects/ScratchToken/contracts/ScratchToken.sol (Line 266, Function `ScratchToken.setLiquidityWallet`)
```solidity
        _liquidityWallet = newWallet;
```
- `newWallet` is not zero-checked before being used.



Missing Zero Address Validation

A reentrancy attack can occur when the contract creates a function that makes an external call to another untrusted contract before resolving any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the external call resolved the effects.

While the function `_tokenTransfer` state variables are updated logically with respect to fees collected, there are instances where state variables are updated after calls to external contracts. 

Potential Reentrancy Attack

The truth statement has two conditions: that a buy or sell has occurred; the sender and recipient are both excluded from fees. The second condition is only true if both individuals are not excluded. Meaning both are intended to pay fees. 

This is a slightly different condition than what is indicated by the comment. 

Exchange	Pair	Price	Spread	24H Volume	24H Vol USD	Volume %

No Data

Tx Hash	Caller	Contract	Function	Timestamp

No Data

Scratch Engine

Highlights & Alerts

Positive Community Sentiment (top 25%)

Code Audit History

12

0

4

0

8

Skynet

Sentiment Analysis

Market Volatility

Governance & Autonomy