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

In the contract `contracts/discovery/src/contract.rs`, the role `owner` has authority over the following message:
- `Start` to begin fair price discovery for the Retrograde token launch.
- `OwnerWithdraw` to withdraw leftover Retrograde token from the contract.

Any compromise to the `owner` account may allow a hacker to take advantage of this authority and manipulate the project.

Centralization Related Risks in Contract `discovery`

In contract `contracts/ido/src/contract.rs`, the events in the functions `start_ido()` and `deposit_ust()` 
do not provide details of the execution messages. It would be better if the users can easily check the initial `RETRO` token deposited by Retrograde team for `start_ido()`, and the user account with the amount of UST deposited by the users for `deposit_ust()`. 

Could Add More Details to Events

The variable `phase_two_length` and `phase_three_length` are of type `cosmwasm_std::Uint128`, which implements the `Copy` trait. It is unnecessary to use the `clone()`. 

Reference: https://docs.rs/cosmwasm-std/0.16.2/cosmwasm_std/struct.Uint128.html

Redundant `clone()`

The variable `c.amount` is of type `cosmwasm_std::Uint128`, so there is no need to convert it to `cosmwasm_std::Uint128`. 

Reference: 
1. https://docs.rs/cosmwasm-std/0.16.2/cosmwasm_std/struct.MessageInfo.html
2. https://docs.rs/cosmwasm-std/0.16.2/cosmwasm_std/struct.Coin.html

Unnecessary `Uint128::from()` - No Conversion Needed Form `Uint128` To `Uint128`

In the function `claim_retro()`, users could claim their `RETRO` token based on the ratio of their existing deposit amount over the total deposit of `UST`. Due to the precision loss of rounding down when calculating the ratio, 
```rust=246
            let user_claim: Uint128 = Decimal::from_ratio(existing_amount, current_deposits_total) * total_retro_deposits;
```
The sum of all `user_claim` would be less than the `total_retro_deposits`, resulting in permanently locked `RETRO` tokens in the `ido` contract. 
Such a condition would exacerbate when the `existing_amount` is small and `current_deposits_total` is large.

Permanently Locked `RETRO` Tokens

The name and comments of function `send_ust_to_treasury()` indicate that the function is supposed to send the collected UST from the IDO to the `treasury` contract address. However, the linked code implementation actually sends the `RETRO` token to the `treasury` contract address. 

Inconsistency Between Names, Comments and Implementations

The key in the linked event does not match with the value. It is supposed to be `"phase_three_length"` to represent the value of `phase_three_length`. 

Typo in Events

In the contract `contracts/treasury/src/contract.rs`, the role `owner` has authority over the following messages:
- `UpdateOwner` to set a new owner of the contract;
- `AddNativeManager` to add new native asset manager;
- `AddTokenManager ` to add new token manager;
- `RemoveNativeManager` to remove native asset manager;
- `RemoveTokenManager` to remove token manager.

The role `native asset manager` has authority over the following message:
- `WithdrawNative` to withdraw native asset.

The role `token manager` has authority over the following message:
- `WithdrawToken` to withdraw token.

Any compromise to these accounts may allow a hacker to take advantage of this authority and manipulate the project.

Centralization Related Risks in Contract `treasury`

In the function `instantiate()` in treasury, the `STATE.owner` is set as the `msg.owner`. However, in the response attributes, the `owner` field is broadcasted as the `info.sender`, where it is not necessarily the same as the `msg.owner`.
```rust
let state = State {
        owner: deps.api.addr_validate(&msg.owner)?, // Sets initial owner to specified owner
...
    Ok(Response::new()
        .add_attribute("method", "instantiate")
        .add_attribute("owner", info.sender))        
```
The inconsistency of the `owner` value in `STATE` and the response may cause misunderstanding over time and be prone to errors.

Inconsistency Between Act and Event

The variable `token` is of type `String`, so there is no need to convert it to `String`. 

Unnecessary `.into()` - No Conversion Needed From `String` To `String`

In the contract `contracts/staking/src/contract.rs`, the role `owner` has authority over the following messages:
- `UpdateConfig` to update the configuration.
- `UpdateOwner` to update the owner.
- `UpdateUnlockTime` to update the unlock time of the staking. 

Any compromise to the `owner` account may allow a hacker to take advantage of this authority and manipulate the project.

Centralization Related Risks in Contract `staking`

In the function `instantiate()` and `update_config()`, the passed `distribution_schedule` has not been validated, which is declared as of type `Vec<(u64, u64, Uint128)>`. Each element `(u64, u64, Uint128)` is a tuple corresponding to a reward schedule, that is, `(start, end, reward amount)`.  The test case in `contracts/staking/src/testing.rs` seems to assume the following:
1. suppose the `distribution_schedule` is <$$(a_0, b_0, c_0), (a_1, b_1, c_1), (a_2, b_2, c_2), ..., (a_i, b_i, c_i), (a_{i+1}, b_{i+1}, c_{i+1}), ..., (a_{n}, b_{n}, c_{n})$$>;
2. for every two consecutive elements, the condition $$a_i < b_i = a_{i+1} < b_{i+1}$$ should be satisfied for any $$0 <= i < n$$, that is, the time intervals will perfectly cover the entire time schedule $$[a_0, b_n]$$ without any overlap or gap;
3. the total reward amount of `RETRO` token, $$\sum_{i=0}^n c_i$$ is less than the balance of the staking contract. 
   
However, there is no validation to make sure that the input value will meet these requirements. 

Lack of Input Validation of `distribution_schedule`

The usage of the block timestamp `env.block.time` gives (small) room for a miner to influence it. That is, a miner can influence, to a certain degree, the outcome of a transaction in the block it mined.

Retrograde

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

6

0

7