Sign Up for a Code Audit Today and Get 3 Months of Skynet for Free

The address `owner` is initialized, but never assigned a value. Since there is no owner, the following functions with the `onlyOwner` modifier can not be used.

- `setTimelockAttributes()`
- `setOwner()`

`owner` is the Zero Address

There is no upper limit of `timelock_percentage`, which could be set to 100% or greater. 

`timelock_percentage` Missing Upper Limit

In the contract `WCAESAR` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and give ownership of the contract to an address he/she controls. Then, he/she can change the value of `timelock_percentage` and `timelock_duration` to any value and greatly increase the reward received for staking.

![](https://accelerator-tasks-prod.s3.amazonaws.com/18b8c6b47eb4455d8c90fbb4b77c0330/diagrams/centralization_WCAESAR__owner.svg)


Centralization Risks in `WCaesar.sol`

The variable `timelock_duration` determines how long tokens are staked for and can be changed to any amount of time.

`timelock_duration` Has No Bounds

In the functions `wrap()` and `unwrap()`, the return values of the `transfer()`/`transferFrom()` calls are not checked.

```solidity
        IERC20(CAESAR).transferFrom(msg.sender, address(this), _amount);
```

---

```solidity
        IERC20(CAESAR).transfer(msg.sender, value);
```



Unchecked ERC-20 `transfer()`/`transferFrom()` Call

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

```solidity
        owner = addr;
```
- `addr` 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.

Check Effect Interaction Pattern Violated

This contract is relying on the `CAESAR` implementation to perform important tasks. The scope of the audit treats the `CAESAR` contract as a black box and assumes its functional correctness. However, the `CAESAR` contract could potentially be compromised and this could lead to lost or stolen assets in the `wcaesar` contract.

Out of Scope Dependencies

The imported library `SafeMathInt` remains unused throughout the codebase.

Unused Imported Library

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

Missing Emit Events

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

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing Error Messages

The functions which are never called internally within the contract should have `external` visibility for gas optimization.

Function Should Be Declared `external`

Wrapped Caesar + Timelock

WCaesar.sol

The linked statements, `onlyMinter()` modifier,  do not affect the functionality and is never used in the contract.

Redundant Code Components

The linked variables could be declared as `constant` since these state variables are never modified.

Variables That Could Be Declared as `constant`

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

In the contract `Caesar` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. Indeed the `_owner` can change at his/her will crucial contract parameter.
In addition the `_owner` has authority over the `swipe` function that allows the `_owner` to send the WAVAX stored in contract balance to an arbitrary address. 

![=1000x1000](https://accelerator-tasks-prod.s3.amazonaws.com/0e037710e1044593b5603e9bf62aa669/diagrams/centralization-Caesar-_owner.svg)

In the contract `Caesar` the role `allowTransfer` has authority over the functions shown in the diagram below.

Any compromise to the `allowTransfer` account may allow the hacker to take advantage of this authority and to set arbitrary values for any of the function controlled by `InitialDistributionLock` modifier.  

![](https://accelerator-tasks-prod.s3.amazonaws.com/0e037710e1044593b5603e9bf62aa669/diagrams/centralization-Caesar-allowTransfer.svg)

In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and to transfer the ownership of the contract to an arbitrary address at his/her will. 

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

Centralization Risk in `Caesar.sol`

The input parameter `_spender` in function `approve()` should be verified as non zero value to prevent being mistakenly assigned as address(0) in function.

```solidity 
    function approve(address spender, uint256 value)
        external
        override
        initialDistributionLock
        returns (bool)
    {
        _allowedFragments[msg.sender][spender] = value;
        emit Approval(msg.sender, spender, value);
        return true;
    }
```

There are multiple `pragma` declarations with different Solidity versions on the linked lines.

Multiple `pragma` with Different Solidity Versions Being Declared

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

Contracts often need access to time values to perform certain types of functionality. Values such as `block.timestamp`, and `block.number` can give you a sense of the current time or a time delta, however, they are not safe to use for most purposes. Developers should not rely on the precision of the provided `block.timestamp` or `block.number`.


File: `Caesar.sol` (Line 640, Variable `nextRebase`)
```solidity
640        uint256 public nextRebase = block.timestamp + rebaseFrequency;
```

File: `Caesar.sol` (Line 729, Function `shouldRebase()`)
```solidity
729        return nextRebase <= block.timestamp;
```

File: `Caesar.sol` (Line 762, Function `_rebase()`)
```solidity
762        uint256 epoch = block.timestamp;
```

File: `Caesar.sol` (Line 903, 937 Function `swapBack()`)
```solidity
903        block.timestamp
...       ...
937        block.timestamp
```

Usage of `block.timestamp`

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset.

The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large:

- `swapBack()` -->
```solidity
router.swapExactTokensForAVAXSupportingFeeOnTransferTokens(
  amountToSwap,
  0,
  path,
  address(this),
  block.timestamp
);
```   

---

- `swapBack()` -->
```solidity
router.addLiquidityAVAX{value: amountAVAXLiquidity}(
  address(this),
  amountToLiquify,
  0,
  0,
  autoLiquidityReceiver,
  block.timestamp
);
```        


Caesar Finance

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

13

0

2

0

11