<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Short description of the vulnerability and the affected asset.

Vulnerability Title

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

Missing emit events

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

In the contract `HaglienNFT`, the role `owner` has authority over the following functions:
- function setURI()
- function setTreasury()
- function setSigner()
- function setPool()
- function airDropNonFungible()
The role `signer` has authority over the following functions:
- function mintFungible()
- function mintNonFungibles()
- function mintVarious()
- function burnFungible()
- function upgradeNonFungible()
- function convertNonFungibles()
- function pay()

AND

In the contract `Haglien`, the role `miner` has the authority over the following function:
- function mint()
The role `owner` has the authority over the following function:
- function setMiner()

AND

In the contract `Zombie`, the role `miner` has the authority over the following function:
- function mint()
The role `owner` has the authority over the following function:
- function setMiner()

Any compromise to the `owner` or `miner` account may allow a hacker to take advantage of this authority and mint tokens for arbitrary accounts.

Centralization related risks

The function `_charge()` requires `msg.value >= amount`. Extra money won't be returned if `msg.value > amount`. The money is stuck in the contract and can not be withdrawn forever. We would like to confirm with the client if the current implementation aligns with the original project design.

Extra eth not returned

The order of external call/transfer and storage manipulation must follow the check-effect-interaction pattern.

Check effect interaction pattern violated

The function `pay()` allows users to transfer ETH or tokens to the treasury without recording in the contract for the user. 

We would like to confirm with the client 
1. What is the purpose of the function? Why do the users call the function to transfer to the treasury?
2. What will the user get if he/she pays money to the treasury?
3. How does the project locate the user's charge record and give the corresponding rights and benefits?

The purpose of function `pay`

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 allocation mechanism of the `nonce` is not reflected in the code. The function `mintNonFungibles` and `mintFungible` both consume a nonce. The count of `nonce` that the function `mintVarious` consumes is not sure. 

We assume that minting fungible tokens and minting several non-fungible tokens are both `orders`. Orders are recorded and processed off-chain in the external server. And `mintVarious()` processes multiple orders simultaneously, consuming the same count of nonces as orders.

One order should correspond to one nonce. It should self-increase to avoid conflicts of the orders.

Allocation mechanism of `nonce`

Different transactions maybe carry signatures with the same nonce. It should be guaranteed that nonce should not be used for more than one time.

Nonce competition

Callers with valid signatures can take advantage of the privilege of the contract to mint coins for them. Also, the function does not charge for minting tokens. Is the function a privileged function, or users will be charged in the `pay` function to get the signature?

Caller can call function `mint()` via function `mintVarious()`

Financial models of blockchain protocols need to be resilient to attacks. It needs to pass simulations and verifications to guarantee the security of the overall protocol.

The contract allows users with the signer's signatures to mint, burn or convert fungible or non-fungible tokens. Users can choose not to pay or burn the token. The project is probably still mostly structured off-chain.

The financial model of this protocol is not in the scope of this audit.

Financial Models 

There is no restriction on the valid time of signatures, which may result in orders being in pending status forever. It is recommended to add expire time in the signature to give timely feedbacks on users' behaviors.

Leaderboards

Due Diligence Tools

Resources