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


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

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


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


---

In the contract `Policy` the role `_newPolicy` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-Policy-_newPolicy.svg)

In the contract `Policy` the role `_policy` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-Policy-_policy.svg)

---

In the contract `StakingWarmup` the role `staking` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-StakingWarmup-staking.svg)

---

In the contract `UniversalStaking` the role `locker` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-UniversalStaking-locker.svg)

---

In the contract `UniversalTreasury` the role `isDebtor` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-UniversalTreasury-isDebtor.svg)

In the contract `UniversalTreasury` the role `isLiquidityDepositor` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-UniversalTreasury-isLiquidityDepositor.svg)

In the contract `UniversalTreasury` the role `isLiquidityManager` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-UniversalTreasury-isLiquidityManager.svg)

In the contract `UniversalTreasury` the role `isReserveDepositor` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-UniversalTreasury-isReserveDepositor.svg)

In the contract `UniversalTreasury` the role `isReserveManager` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-UniversalTreasury-isReserveManager.svg)

In the contract `UniversalTreasury` the role `isRewardManager` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-UniversalTreasury-isRewardManager.svg)

---

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


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

---


In the contract `sUniversal` the role `initializer` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-sUniversal-initializer.svg)

In the contract `sUniversal` the role `stakingContract` has authority over the functions shown in the diagram below.


![](https://accelerator-tasks-prod.s3.amazonaws.com/ef26d7a1bde74c65a6a109a61d3db39a/diagrams/centralization-sUniversal-stakingContract.svg)



Any compromise to the privileged accounts may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the project.


Centralization Related Risks

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. 



Potential Reentrancy Attack

In function `deposit` of contract `BarterDepository`, there is a check `totalDebt <= terms.maxDebt`. We think the variable `totalDebt` should be the updated value but not the old one.

Similar function happened in L839 in the contract `wETHBarterDepository.sol`

Incorrect Position Of Check

The function `_beforeTokenTransfer()` and event `Transfer` in the `_mint()` function generally use 0 address as a parameter, but here is `address(this)`.

Wrong Address In `_mint()` Function

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

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

Missing Emit Events

According to the logic of this project, the function `distribute` of contract `StakingDistributor` can only be called by `Staking.rebase()`. So it's better to add an access control of function `distribute`.

Missing Access Control Of Function `distribute`

In function `incurDebt` of contract `Treasury`, if one user have `maximumDebt` `USV`, he can borrow total of `maximumDebt` `_token`. This may cause a problem. Consider A,B,C in `isDebtor`, A has 100 `USV`, so he borrows 100 `_token`. Then A transfers these `USV` to B, then B can also borrow 100 `_token`. B can transfer these `USV` to C， and so on. The reserve token in `Treasury` may suffer a loss. 

Users don't need to repay the debt, because they don't mortgage anything.


Defects Of IncurDebt

There is a check in Line295 of contract `Treasury`, which allows liquidity token to stake in `Treasury`. But in function `withdraw`, only reserve tokens can be withdrawn. No withdrawal method is provided in this contract to withdraw the liquidity token.

Besides, the user will burn one `USV` to withdraw one `_token`. As the price of `USV` is unknown before the launch, there's no confirmation that anyone will withdraw `_token` with `USV`. The reason is `USV` is publicly traded. The price is not under the control of the project party. So exchanging USV to `_token` may bring unexpected fluctuation of the tokenomic.

Defects Of The Function `withdraw`

`totalReserves` should be reduced after mint after calling `mintRewards()`.

Not Update `totalReserves`

The given input is missing the check for the non-zero address.

Missing Input Validation

In contract `UniversalERC20`, Line181, Line246, Line318 shows a similar loop. Line185 uses a condition `_length( set_._inner ) > iteration_`, Line246 and Line318 use a condition `_length( set_._inner ) >= iteration_`. We think the correct operator should be `>`.

Atlas USV

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

14

0

11

0

3