Xprotocol

QuillAudits1 Aug 2024Files named in the report

Audit · firm’s term: audit report

QuillAudits reviewed XProtocol on 1 Aug 2024: 10 findings, 0 critical; 8 marked fixed, 2 open.

No open critical findings

Open the report Open XProtocol’s security record

Report hosted on quillaudits.com.

Trustblock does not review code.

Findings10

Statuses are the security firm’s own, from its report.

Severity	Open	Fixed
Critical	0	0
High	0	0
Medium	0	3
Low	2	5

MediumMissing validation in function `setOrAddPricingTier`Fixed

The Tier.whitelistSoldQuantity should constantly be less than or equal to Tier.whitelistQuantity. However, the setOrAddPricingTier function, which updates price tiers, may not always enforce this constraint. Consequently, this could lead to an inconsistent state within the system.

MediumMissing validation of `referralDiscountPercentage`Fixed

The PromoCode.referralDiscountPercentage must always be maintained at a value less than 100%. Setting this value to 100% would result in the issuance of an NFT at no cost.

MediumValues in `_promoCodesByRecipient` might get staleFixed

The updatePromoCode function is designed to modify existing promo codes. While it successfully updates the _promoCodes data structure, it does not perform the requisite updates to the _promoCodesByRecipient data structure. This oversight may lead to potential inconsistencies in the system's state. Similar updates should be done in removePromoCode.

LowConditional ChecksFixed

Conditional check in claimableNodeAmounts[msg.sender] <= 0 of claimNode function can be == instead of <0

LowDeas Commented CodeFixed

Remove dead commented code of _getWhitelistByAddrAndTier function.

LowInconsistent namingFixed

Inconsistent naming of the function removePromoCode, it’s deactivating Promo code but name implies that it removed Promo code.

LowUnclear administrative responsibility of function `withdrawFunds`Fixed

The withdrawFunds function possesses significant administrative capabilities and should not be managed by an Externally Owned Account (EOA). It is advisable to utilize a multisignature (multisig) wallet for this purpose. Additionally, to mitigate issues when transferring funds to a contract, employ the .send or .call methods with a specified gas limit or the nonReentrant modifier, rather than using the .transfer method.

LowUse `nonReentrant` modifier of ReentrancyGuardUpgradeable contractFixed

The contract contains numerous functions that are susceptible to reentrancy attacks, given the extensive use of .send and .call opcodes. To robustly address this issue, it is advisable to implement a non-reentrancy guard across all functions. This approach would effectively mitigate reentrancy vulnerabilities and enhance the contract's security.