XDoor Info
The blockchain world is a vast universe of infinite possibilities — behind every door lies an unknown realm of opportunity and risk. You never know what awaits when you open the next door — it could be fortune and growth, or it could be danger and loss. Every door is a choice, and every push forward marks a turning point. XDOOR stands as the gateway to the unknown, a mysterious entrance at the edge of the X-Layer world. Each XDOOR represents a new beginning. Some hesitate before it. Others push forward with courage. Every brave decision can change your destiny. A choice is not merely an action — it is the key to meeting your fate.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Ownership Privileges
- The owner can set the swap pair list.
- The owner can add the swap router address.
- The owner can whitelist addresses in batches.
- The owner can add or remove the batch of addresses from the dividend exclusion list.
- The owner can change the end time of the current dividend distribution round.
Note - This Audit report consists of a security analysis of the XDoorBase smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the XDoor team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
medium Issues | 2 findings
Resolved
#1 medium Issue
Unprotected DEX Swaps Leading to Value Extraction via Sandwich Attacks
The doSwapFund function interacts with the Uniswap V2 router by calling swapExactTokensForETHSupportingFeeOnTransferTokens with the amountOutMin parameter hardcoded to 0. This configuration signals to the router that the contract will accept any amount of ETH in return for its tokens, regardless of price impact. This creates a critical vulnerability where MEV bots can execute a "sandwich attack" by front-running the transaction to manipulate the price, causing the swap to execute at an extremely unfavorable rate, and then back-running it to restore the price and extract the difference as profit. This will result in a consistent and significant drain of the protocol's tax revenues, directly impacting the funds allocated for dividends, liquidity, and the Fomo3d game. A similar vulnerability exists in all other functions that interact with the DEX, such as _addLiquidityToZero.
Resolved
#2 medium Issue
Unprotected Liquidity Functions Expose Users to Guaranteed Value Extraction
The public addLiquidity and removeLiquidity functions are critically flawed as they interact with the Uniswap V2 router with the amountTokenMin and amountETHMin parameters hardcoded to 0. This configuration completely removes slippage protection, creating a direct opportunity for MEV bots to perform sandwich attacks against any user who calls these functions. An attacker can manipulate the pool price immediately before and after the user's transaction, forcing the user to add or remove liquidity at a highly unfavorable rate. This results in the user receiving fewer LP tokens on deposit, or fewer underlying tokens on withdrawal, than they are entitled to, with the value difference being extracted by the attacker as profit. This design flaw exposes every liquidity provider using these functions to guaranteed and repeated financial loss, fundamentally undermining the security of user-deposited funds.
low Issues | 1 findings
Acknowledged
#1 low Issue
Unvalidated Inputs in Administrative Functions
Multiple administrative functions with onlyOwner privileges, including setSwapPairList, setSwapRouter, batchSetFeeWhiteList, setExcludeHoldProvider, and setDividendRoundEndTime, lack essential input validation. These functions do not check for dangerous or nonsensical values, such as setting a critical address to address(0) or setting a duration to an excessively large number. This absence of validation creates a significant risk, as a compromised or malicious owner could abuse these functions to disrupt or permanently break core protocol mechanics. For example, setting the dividend round end time to a near-infinite value would permanently lock all current and future dividend funds within the DividendDistributor contract. Similarly, setting the zero address as a swap pair could corrupt the fee-handling logic, leading to unpredictable behavior. These vulnerabilities stem from an over-reliance on the owner to always provide correct and safe inputs, creating a major centralization risk.
informational Issues | 1 findings
Acknowledged
#1 informational Issue
Centralized Fomo3d Admin Role
During deployment, the XDoorBaseToken constructor creates the Fomo3d contract and assigns its administrative role (ADMIN_ROLE) to the msg.sender. The msg.sender in this context is the externally owned account (EOA) that deploys the main XDoor contract. This results in a single EOA having privileged control over the Fomo3d game's critical parameters, including prize ratios, countdown timers, and round durations While this is a common pattern for initial project deployment, it represents a significant centralization of power. The security of the Fomo3d contract and its prize pool is entirely dependent on the security of the deployer's private key. If this key were to be compromised, an attacker could manipulate the game's rules to their advantage, potentially draining the prize pool.