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 differing compiler version numbers. 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 `AnylistFactory`, the role `owner` has authority over the following functions:
- function createVault()
- function setOwner()
- function setVoucher()

In the contract `AnylistVault`, the role `governance` has authority over the following functions:
- function addParticipants()
- function withdrawFund()

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

Centralization Related Risks

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

Missing Input Validation

The given input `_governance` is missing the check for the non-zero address and `_startTime` should be less than `_endTime`.

Accourding to the logic, `maxParticipate` represents the maximum number of participants, so it should be added a check to limit the number of participants in `addParticipants()` or remove the `maxParticipate` variable.

`recipients` Can Not Be Larger Than `maxParticipate`

After the event ends, when `totalReceiveRateAmount > totalProviderAmount`, participants can claim `bidToken` refund, but `governance` can withdraw all `bidToken` in the contract 1 hour after the event ends, if `governance` withdraw all `bidToken` in the contract and participants do not claim the refund in time, participants will not be able to receive refunds and purchased `askToken`, they will suffer losses.

`governance` Can Withdraw Refund

According to the logic, participants can claim `askToken` at the end of the event. Since the transactions are transferred from `askProvider` to participants, it is not possible to determine whether the `askProvider` account has enough `askToken` balance.   
Since BDO is a pre-sale method, participants should pay `bidToken` first during the activity period and claim `askToken` after the activity ends. If there is not enough `askToken` balance on `askProvider` account or `askProvider` does not give authorization to the contract, participants cannot get the purchased `askToken` and the paid `bidToken`, participants will suffer losses.

Unable To Determine If Askprovider Has Sufficient `asktoken` Balance

In the `claimAndRefund()` function, `rate` represents the ratio of `bidToken` to `askToken`. At the end of the event, the contract calculates the number of `askTokens` that should be issued (`totalReceiveRateAmount`) by multiplying the total number of `bidTokens` received (`totalReceiveAmount`) by `rate`. number . If `totalReceiveRateAmount` is greater than `totalProviderAmount`, the number of `askTokens` received by each participant is calculated based on the ratio of the two and `participant.askAmount`. Otherwise the number of `askTokens` received by the participant is `participant.askAmount`, independent of `participant.receiveAmount`, so the `askToken` can be received whether or not the participant pays the `bidToken`.  
For example:
```solidity=
rate = 1;
totalProviderAmount = 1000;
userA.askAmount = 900;
userB.askAmount = 100;
userA.receiveAmount = 900;
userB.receiveAmount = 0;
totalReceiveAmount = 900;
totalReceiveRateAmount = 900 * 1 = 900;
due totalReceiveRateAmount < totalProviderAmount ;
so userA.releasedAmount = 900;
userB.releasedAmount = 100;
```
userB did not pay the `bidToken`, but got the expected number of `askTokens`.

Participants Can Get `asktoken` For Free

If the `bidToken` is `WETH`, `msg.value` should be equal to `amount` to avoid users paying extra ETH.

`msg.value` Should Be Equal To `amount`

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 Risks

According to the documentation, the NFT represents the user's DID certificate, as his on-chain ID card, and a ticket to participate in BDO. But the user can acquire multiple NFTs and participate in BDO multiple times.  
The contract inherits the ERC721 contract from openZepplin, so NFTs can be traded, although the contract overrides `_beforeTokenTransfer()`, it can not restrict users from obtaining multiple NFTs.  
For example:  
1. userA calls `mint()` to obtain an NFT, `_safeMint()` will call `_beforeTokenTransfer()`, so `_ownerships[tokenId] = userA` and `_userMinted[userA] = tokenId`;  
2. userA calls `transferFrom()` of the ERC721 contract to transfer the NFT to others. since _ownerships is a property of the AnylistVoucher contract, `_ownerships[tokenId]` is still userA, and `transferFrom()` will call `_beforeTokenTransfer()`, so `_userMinted[userA] = 0`;
3. Repeat steps 1, 2. userA can continue to get NFT.

Anylist.Finance

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

11

0

2

0

9