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

The project is using the underlying entities which implement the interfaces including:

`IERC20`, `IHPool`, `IHPoolManager`, `IHordTreasury`, `IMaintainersRegistry`, `IOrderbookConfiguration` and `IOtc`


However, the real implementation of these interfaces and functions are unknown, hence they could be changed at will.

The scope of the audit treats 3rd party entities as black boxes and assumes their functional correctness. The related codes are not in the scope of this audit.

Unknown Implementations

1. According to the `offer_simple_market`, any IERC20 token can make the pair as an offer, however, only `isValidHPoolTokenPair(pay_gem, buy_gem)` could transact.

2. What is the use of `_hordToken`, is it one of the token types in the `HPool`?

the use of various tokens

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

Improper Usage of `public` and `external` Type

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

In the contract `MatchingMarket` the role `hordCongress` has authority over the functions shown in the diagram below.

Any compromise to the `hordCongress` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/03bb55508b1b460283e4cfda458dd101/diagrams/centralization-MatchingMarket-hordCongress.svg)

Centralization Risk in MatchingMarket.sol

`MatchingMarket` maintains multiple double linked lists to sort the offer prices of all pairs, which involves the use of multiple loops and makes the whole contract consume a lot of gas.

In fact, only the most critical transaction information and steps need to be recorded on the chain, and a large number of gas-consuming steps (e.g., sorting) can be transferred to off-chain execution, which can greatly reduce the user's gas consumption.

Gas Waste in `MatchingMarket`

In the contract `OrderBookConfiguration` the role `hordCongress` has authority over the functions shown in the diagram below.

Any compromise to the `hordCongress` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/03bb55508b1b460283e4cfda458dd101/diagrams/centralization-OrderBookConfiguration-hordCongress.svg)

Centralization Risk in OrderBookConfiguration.sol

The state variables `_dustLimit` and `_totalFeePercent` can be changed and have no limitations. So they can be set to an arbitrary number. 

Key Metrics can be Changed without Limitations

The contract has one receive function but does not have a function to withdraw the fund.

Locked Ether

The `can_offer` is defined with empty implementation.

redundant modifier

In the contract `SimpleMarket` the role `_championAddress` has authority over the functions shown in the diagram below.

Any compromise to the `_championAddress` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/03bb55508b1b460283e4cfda458dd101/diagrams/centralization-SimpleMarket-_championAddress.svg)

In the contract `SimpleMarket` the role `hordCongress` has authority over the functions shown in the diagram below.

Any compromise to the `hordCongress` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/03bb55508b1b460283e4cfda458dd101/diagrams/centralization-SimpleMarket-hordCongress.svg)

Centralization Risk in SimpleMarket.sol

The function `addTradingFee()` is used to add `_amount` of `_hPoolToken` to the `hPoolToChampionFee` and `hPoolToPlatformFee` balance, yet it is an external function, which means anyone could add the fee balance, and these tokens could finally transfer to the `_championAddress` and `hordTreasury`.

Besides, when every offer is bought or sold by calling `buy_simple_market`, the fee has been already added to the `hPoolToChampionFee` and `hPoolToPlatformFee` balance, hence there is no need to design this function to add the `hPoolToChampionFee` and `hPoolToPlatformFee` balance.

Logical issue in `addTradingFee()`

When an offer created, the `pay_amt` of tokens would be transferred into the contract, and when the offer is bought, a portion of the fee would be left in the contract to withdraw.

However, in the `buy_simple_market`, when `address(offer.buy_gem) == address(dustToken)`, all of the tokens that the offer owner transferred to the contract are transferred out to the buyer, while only a `updatedSpend` amount of tokens are transferred to the offer owner, which would cause the loss of the owner, and there would not be any tokens left to add to the fee either.

Even if the balance of `hPoolToPlatformFee` and `hPoolToChampionFee` is increased, this part of the fee cannot actually be withdrawn, which may also cause the withdraw function fails.

Logical issue in `buy_simple_market`

In the function `buy_simple_market`, the `else` statement has the comment `offer.pay_gem is BUSD`, however, there are many cases to satisfy the condition of the `else` statement, just make sure `address(offer.buy_gem)! = address(dustToken)`.

logical issue in `else`

According to the following codes:

```solidity
function buy_simple_market(uint id, uint quantity)
    internal
    whenNotPaused
    can_buy(id)
    synchronized
    returns (bool)
    {
        OfferInfo memory offer = offers[id];
        uint spend = mul(quantity, offer.buy_amt) / offer.pay_amt;
```
, since using division in solidity causes division truncation issues, the decimal places in `spend` will be automatically rounded off. As a result, the `spend` will be smaller than expected, especially when `quantity` is small and `offer.buy_amt` and `offer.pay_amt` are also small and close to each other, the impact of this issue will be greater.

Hence we would like to know if `offer.buy_amt` and `offer.pay_amt` have been multiplied by the corresponding decimal to reduce the effect of division truncation.

Discussion on token decimals

Hord

MakerOtcSupportMethods.sol

IHordTreasury.sol

OrderBookConfiguration.sol

IERC20Metadata.sol

IOtc.sol

system

MatchingMarket.sol

IERC20.sol

interfaces

IOrderbookConfiguration.sol

OrderBookUpgradable.sol

libraries

DSMath.sol

SimpleMarket.sol

IHPool.sol

IHPoolManager.sol

IMaintainersRegistry.sol

Unlocked Compiler Version

Function Visibility Optimization

Check Effect Interaction Pattern Violated

Lack of Natspec Comments

Missing Emit Events

Missing Input Validation

Centralization Risk: Privileged Role, `hordCongress`, in `HordConfiguration`

No Restriction On The Caller Of `setHPoolManager()`

Centralization Risk: Privileged Role, `hordCongress`, in `HPoolFactory`

Inconsistency Between Comment and Code

Unclear Logic Of `getRequiredNumberOfTicketsToUse()`

Type Conversion

Unclear Comment

Missing Input Validation in `HPoolManager`

Struct Tight-Packing

Third Party Dependencies in `HPoolManager.sol`

Centralization Risk: Privileged Role, `hordCongress`, in ` HPoolManager`

`if` Block Optimization

Redundant code

Return value not handled

Unused Event

External Call Inside A Loop

Liquidation Occurs For All Tokens

Incomplete Function

Unoptimized Function

Logic Flaw In The Logic Of `liquidatePositionAndPullAssets()`

Missing Input Validation In  `HPool.sol`

Third Party Dependencies in `HPool.sol`

Unclear Logic

Centralization Risk: Privileged Role, `hordCongress`, in `HPool`

Initial Token Distribution

Centralization Risk: Privileged Role, `hordCongress`, in `HordTreasury`

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

Comparison to A Boolean Constant

Third Party Dependencies in `HordTicketManager.sol`

Centralization Risk: Privileged Role, `hordCongress`, in `HordTicketManager`

Centralization Risk: Privileged Role, `hordCongress`, in ` HordUpgradable`

Potential Reentrancy Risk

Inconsistency Between Code and Error Message

Error In Ether Value

Centralization Risk: Privileged Role, `hPoolManager`

Centralization Risk: Privilege Role, `maintainer`

Susceptible to Signature Malleability

Hord #2

IHordTicketManager.sol

HordTicketManager.sol

SignatureValidator.sol

IHPoolFactory.sol

HPoolToken.sol

HPool.sol

HPoolManager.sol

ISignatureValidator.sol

HordTreasury.sol

IHordCongressMembersRegistry.sol

HordConfiguration.sol

HordUpgradable.sol

AggregatorV3Interface.sol

IHordConfiguration.sol

IHordTicketFactory.sol

Context.sol

HPoolFactory.sol

SafeMath.sol

hPools

token

Top 10% Watchlisted

Hord 

Mid Market Cap (25%-50% Amongst Projects)

Hord

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

15

0

7

0

8