The X DAO

Smart Contract Audit Report

Audit Summary

The X DAO Audit Report The X DAO is building a new decentralized exchange, a yield farming platform, an NFT marketplace, an NFT auctioning system, and an ERC-20 token to be used throughout the platform.

For this audit, we reviewed the XdaoERC20, XdaoPair, XdaoFactory, XdaoRouter, HertzToken, MasterChef, TheXdaoNFT, TheXdaoMarket, and TheXdaoAuction contracts provided to us by the project team.

Audit Findings

Please ensure trust in the team prior to investing as they have notable control in the ecosystem.
Date: February 10th, 2022.
Updated: February 15th, 2022 to include functionality for ERC-1155 collections and NFTs in the marketplace.
Updated: February 21st, 2022 to address additional findings.
Finding #1 - MultipleTheXdaoNFT - High (Resolved)
Description: The burn() function does not check any granted approvals prior to burning NFTs.
Risk/Impact: Users are at risk of losing their NFTs as anyone can burn any NFT from any address at any time.
Recommendation: The function should check allowances prior to burning NFTs, or restrict burning to only contents of the user's own wallet.
Resolution: The team has altered the code so that users are only able to burn NFTs in their own wallet.
Finding #2 - HertzToken - High
Description: Token transfers do not transfer delegates along with the token.
Risk/Impact: Delegatees will retain their votes even if a transfer occurs. This can result in additional votes being created through the use of transfers.
Recommendation: The transfer functions should be overridden to add the appropriate _moveDelegates() calls.
Finding #3 - TheXdaoMarket - Medium (Resolved)
Description: While only the project team or the NFT owner can delist an NFT, the NFT is transferred to the caller, rather than the NFT owner.
Risk/Impact: The NFT owner is at risk of losing their NFT if the project team decides to delist an NFT.
Recommendation: The NFT should be transferred back to the NFT owner upon delisting.
Resolution: The team has implemented the above recommendation.
Finding #4 - TheXdaoAuction - Informational (Resolved)
Description: In the getCurrentBids() function, the condition in the if statement will always be true, as bidsLength will always be at least 0.
function getCurrentBids(uint256 _auctionId) public view returns(uint256, address) {
	uint256 bidsLength = auctionBids[_auctionId].length;
	// if there are bids refund the last bid
	if (bidsLength >= 0) {
		Bid memory lastBid = auctionBids[_auctionId][bidsLength - 1];
		return (lastBid.bidPrice, lastBid.from);
	}
	return (0, address(0));
}
Risk/Impact: This function will return an error in the case that the auctionBids array is empty.
Recommendation: The condition should be revised to only evaluate to true if bidsLength > 0.
Resolution: The team has implemented the above recommendation.
Finding #5 - TheXDAO - Informational (Resolved)
Description: Several functions are declared public, but are never called internally.
HertzToken: mint
MasterChef: add, set, deposit, withdraw, emergencyWithdraw, dev, setFeeAddress, updateEmissionRate
XdaoRouter: quote, getAmountOut, getAmountIn, getAmountsOut, getAmountsIn
TheXdaoAuction: createAuction, finalizeAuction, getAuctionsLength, getBidsAmount, getOwnedAuctions, getCurrentBids, getAuctionsAmount
TheXdaoNFT: setCollectionURI, setName, setPublic, addItem, setTokenURI, creatorOf, royalties
TheXdaoMarket: list
Recommendation: These functions should be declared external for additional gas savings on each call.
Resolution: The team has implemented the above recommendation.
Finding #6 - TheXDAO - Informational (Resolved)
Description: Several state variables can never be modified, but are not declared constant.
TheXdaoAuction.feeAdmin, TheXdaoMarket.feeAdmin
Recommendation: These state variables should be declared constant for additional gas savings on each call.
Resolution: The team has implemented the above recommendation.

Contracts Overview

XdaoERC20 Contract:
This contract implements the ERC20 standard for use as an LP token.
This contract utilizes a "permit" mechanism which allows the owner of the $Xdao-LP tokens to sign a transaction that enables another user to withdraw tokens and send them to the recipient. The recipient then submits the permit on behalf of the owner.
XdaoPair Contract:
This contract is the core trading functionality.
Each XdaoPair manages a liquidity pool made up of reserves of two ERC-20 tokens.
This contract is responsible for tracking the balance of both tokens in the pair, as well as mints and burns of the LP token.
Users can add liquidity by providing an equivalent value of each token and are minted an LP token in return. The LP tokens may be burned to receive the underlying assets at any time.
Users may also exchange one token for an equivalent amount of the other token based on the current market value. A 0.25% fee is taken on an exchange between tokens and given as rewards to LP providers.
Of the 0.25% fee collected, a portion is taken on liquidity adds and burns.
XdaoFactory Contract:
This contract is responsible for the creation of liquidity pairs for two tokens, thereby enabling trading on the platform.
When creating a new trading pair, the XdaoPair initialize() function is called which allows the factory to specify the two ERC20 tokens that this pair will exchange.
Once the pool is created, its address is stored with a double mapping that takes both token addresses as input.
XdaoRouter Contract:
This contract is used to interact with liquidity pools that are created via the XdaoFactory contract.
This contract routes orders to the user-determined pair contract to swap assets.
This contract performs requirement checks needed for swapping tokens, adding liquidity, and removing liquidity.
HertzToken Contract:
The owner can mint any number of $HTZ tokens to any address at any time.
Users can transfer their $HTZ tokens to the 0x..dead address to reduce circulating supply, if desired.
Each $HTZ token represents votes intended to be used in a DAO where one token represents one vote.
In order to vote, users must delegate their votes to themselves.
Users may delegate their votes to another address allowing them to vote on behalf of the user.
Once votes are delegated, the user must explicitly delegate back to themselves to regain their votes.
Users also have the option to delegate through the use of a signed message, allowing for a gasless delegation for the user.
MasterChef Contract:
This contract allows anyone to stake various token assets determined by the project team in order to earn rewards in $HTZ tokens.
There is a fee charged on deposits; this fee is determined by the project team and may vary across staking pools.
Users will receive a reward amount on each block based on the reward rate and the amount staked; staking rewards can be calculated and minted to the user at any time.
After the last reward block for a pool has passed, rewards will no longer be distributed.
On deposits and withdrawals, pending rewards are automatically calculated and minted to the user.
Additionally, approximately 12% (11/89) of the calculated rewards is minted on top of the user's rewards and transferred to the dev address controlled by the project team.
The user can trigger an emergency withdraw on any pool at any time, which will transfer all the user's deposited tokens in the specified pool to their wallet address without calculating rewards.
The owner can add any token as a staking token at any time; Upon adding staking tokens, the owner sets the pool's allocation points, last reward block, and deposit fee rate.
The team must exercise caution when adding staking tokens to avoid fee-on-transfer and ERC777-compliant tokens. If a fee-on-transfer token is added, then the contract must be exempt from transfer fees.
The owner can set the deposit fee rate and allocation points for any existing pool to any value at any time.
The owner can set the reward rate to any value at any time.
TheXdaoNFT and MultipleTheXdaoNFT Contracts:
These contracts are used to represent NFT collections on the Xdao platform, where TheXdaoNFT is an ERC-721 collection and MultipleTheXdaoNFT is an ERC-1155 collection.
While the ERC-1155 collection is public, anyone can mint any amount of any NFT to add to the collection at any time.
Additionally, anyone with the Minter role can mint any ERC-1155 NFT at any time.
This does not apply to the ERC-721 collection; anyone can mint any ERC-721 NFT to add to the collection at any time.
Anyone can burn their own ERC-1155 tokens at any time.
Upon minting NFTs, the user specifies the supply amount (in the case of ERC-1155), token URI and the royalty value between 5% and 10%.
In the event that the user minting the NFT is a contract, the receiving contract must have implemented the onERC721Received() function in order to successfully receive the NFT.
The MultipleTheXdaoNFT contract uses the AccessControl permission scheme, in which the owner is granted the Default Admin role and the Minter role upon deployment; The owner can grant any role to any address at any time.
The NFT creator can set the token URI to any value at any time.
The Collection owner can set the Collection URI and Collection Name to any value at any time.
The Collection owner can toggle the "public" switch at any time, which allows ERC-1155 NFTs to be minted. At present, this does not impact any functionality within the ERC-721 contract.
The contracts comply with the relevant ERC-721 and ERC-1155 standards.
Along with using SafeMath, the contract is deployed with Solidity v0.8.0, which includes built-in protection against any underflow/overflow issues.
TheXdaoMarket and MultipleTheXdaoMarket Contracts:
These contract are used to facilitate NFT marketplaces where users can buy and sell NFTs; TheXdaoMarket supports only ERC-721 NFTs, while MultipleTheXdaoMarket supports only ERC-1155 NFTs.
Anyone can use these contracts to create their own TheXdaoNFT or MultipleTheXdaoNFT collections at any time; new collections are created by deploying a new TheXdaoNFT or MultipleTheXdaoNFT contract and assigning the collection owner, collection name and URI.
The platform offers a default ERC-721 NFT collection, which can be used by anyone.
The owner of an NFT within any collection can list their NFT at any time; upon listing an NFT, the user must specify the supply amount (in the case of ERC-1155) and price.
Listed NFTs are transferred and stored in the contract until they are delisted or sold.
The NFT can be delisted at any time by the user who listed the NFT or by the platform owner.
Anyone can buy any listed NFT at any time as long as they are not already the owner of the NFT.
NFTs are paid using $HTZ tokens.
Upon purchasing an NFT, 25% of the purchase price is transferred to the Fee address controlled by the project team.
Another portion (up to 10%, depending on the royalty value that was set when the NFT was minted) is transferred to the creator of the NFT as a royalty.
Any remaining amount is transferred to the user who listed the NFT for sale.
Although it is intended that users will use this contract to list TheXdaoNFT or MultipleTheXdaoNFT NFTs, these contracts can be used to facilitate the sale of any NFTs as long as the NFT contract implements the functionality required by this marketplace contract.
The project team can set the Fee address to any value at any time.
Along with using SafeMath, the contract is deployed with Solidity v0.8.0, which includes built-in protection against any underflow/overflow issues.
TheXdaoAuction Contract:
This contract is used to facilitate an NFT auction platform.
The owner of an NFT can create an auction for the NFT at any time, specifying the start price, the start time, and the end time; the NFT is transferred and stored in the contract until the auction is over.
Anyone can bid on any existing auction at any time; auction owners cannot bid on their own auctions.
The user must bid at least 5% more than the previous bid; if there are no previous bids, the minimum bid is the start price.
Upon placing a bid, bid amounts are paid in $HTZ and transferred to the contract; the previous bid is in turn transferred back to the previous bidder.
The auction owner or the project team can end any auction at any time, transferring the NFT to the highest bidder, or back to the auction owner if there are no bids.
Upon ending an auction, 25% of the purchase price is transferred to the Admin address controlled by the project team.
Another portion (up to 10%, depending on the royalty value that was set when the NFT was minted) is transferred to the creator of the NFT as a royalty.
Any remaining amount is transferred to the auction owner.
The project team can set the Admin address to any value at any time.
Along with using SafeMath, the contract is deployed with Solidity v0.8.0, which includes built-in protection against any underflow/overflow issues.