Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

XDoor Info

xdoor.vercel.app

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.

XDoor Logo
Onboarded date 04/12/2025

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.

15.98
Poor Excellent

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

Select the audit
"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2025/12/04
Revision date 2025/12/05

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:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. 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 exclude the addresses from dividends by manually providing their token balance.
  • The owner can add or remove any address from the dividend exclusion list at any time.
  • The owner can update the excluded values.
  • The owner can set the round end time.

Note - This Audit report consists of a security analysis of the Dividend Distributor 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

Critical
High
2
Medium
Low
Optimization
Informational
medium Issues | 4 findings

Resolved

#1 medium Issue
Unprotected DEX Interactions in endRound
DividendDistributor.sol
L104-147
Description

The endRound function, which processes all unclaimed ETH from a dividend round, is critically vulnerable to exploitation. It swaps ETH for XDOOR tokens and adds liquidity to Uniswap with the minimum output/input parameters (amountOutMin, amountTokenMin, amountETHMin) hardcoded to 0. This complete lack of slippage protection is a direct invitation for MEV bots to perform sandwich attacks. These bots will front-run the endRound transaction to manipulate the price, force the swap and liquidity provision to execute at a disastrously unfavorable rate, and then back-run it to capture the value difference as pure profit. This is not a theoretical risk; it is a guarantee that a significant portion of the unclaimed community funds will be stolen by automated bots every time the round ends.

Comments

The endRound function and its helper _buyTaxTokenWithETH must be re-engineered to enforce slippage protection. Before executing a swap or liquidity provision, the contract must query the Uniswap router to get the expected output amounts based on the current price. It must then calculate a minimum acceptable amount based on a tight slippage tolerance (e.g., 1-3%) and use this dynamic, non-zero value in the calls to the router. This will cause the transaction to revert if the price is manipulated beyond the acceptable bound, thereby securing the unclaimed dividend funds from theft.

Resolved

#2 medium Issue
Flawed Reward Accounting in updateExcludedTotal
DividendDistributor.sol
L207-219
Description

The updateExcludedTotal function, designed to maintain an accurate count of tokens held by dividend-ineligible addresses, contains a critical logic flaw. During a transfer between two already-excluded addresses, the function's logic incorrectly processes the balance changes for both the sender and the recipient, causing the same balances to be double-counted. This error permanently inflates and corrupts the excludedTotal variable. An incorrect excludedTotal breaks the getTotalShares() calculation, which in turn leads to the accTokenPerShare being miscalculated for all subsequent reward distributions. This will systematically break the dividend mechanism and ensure that all holders receive incorrect reward amounts.

Comments

The logic within updateExcludedTotal must be fundamentally revised to correctly handle all transfer scenarios. The most robust solution is to add a check at the beginning of the function to see if both the from and to addresses are already excluded. If they are, no change to excludedTotal is necessary, and the function should exit early. This will prevent the double-counting error and preserve the integrity of the reward accounting system.

Acknowledged

#3 medium Issue
Unvalidated Inputs in Administrative Functions
DividendDistributor.sol
L74-82
Description

The administrative onlyOwner functions, particularly setExcludeHoldProvider and setRoundEndTime, were initially implemented without proper input validation. The setExcludeHoldProvider function allowed the owner to set address(0) as an excluded provider, which would corrupt the excludedTotal calculation by including the zero address balance. Additionally, the setRoundEndTime function previously permitted the owner to supply an arbitrarily large extendTime, creating a significant centralization risk: the owner could set the round end time far into the future, effectively preventing users from ever calling the claim function and permanently locking all ETH within the contract. Such behavior could unintentionally or maliciously disrupt the dividend system. However, the end-time issue has now been resolved by adding proper validation to restrict excessively large extensions and ensuring that the round end time cannot be set in a way that permanently disables user claims. This update mitigates the risk of indefinite lockup and restores the intended functionality and safety of the dividend process.

Comments

Implement strict require statements at the beginning of all administrative functions. The setExcludeHoldProvider function must ensure the provided address is not address(0). These checks are essential to protect the contract's core functionality from being compromised by invalid administrative inputs.

Acknowledged

#4 medium Issue
Corrupted Reward Calculations Due to Flawed Accounting Logic
DividendDistributor.sol
L74-82
Description

The integrity of the entire dividend distribution system hinges on the accurate calculation of accTokenPerShare, the variable that determines how much reward each user earns. This variable's calculation is critically dependent on getTotalShares(), which is derived from totalSupply - excludedTotal. The contract, however, contains a severe flaw that allows the excludedTotal variable to become permanently corrupted. The administrative function setExcludeHoldProvider lacks input validation, permitting the owner to add address(0) to the exclusion list. This action would incorrectly add the massive token balance of the zero address to excludedTotal, irreversibly corrupting it. Once excludedTotal is incorrect, every subsequent calculation of accTokenPerShare will also be incorrect. This will cause the dividend system to fail, leading to all users receiving systematically incorrect and unfair reward payouts for all future dividend rounds.

Comments

To prevent the corruption of the core accounting logic, strict input validation must be implemented on all administrative functions that modify the excludedTotal. Specifically, the setExcludeHoldProvider function must be updated with a require statement to prohibit address(0) from being passed as an input. As a defense-in-depth measure, consider implementing an emergency administrative function that can forcibly recalculate the excludedTotal by iterating through the list of currently excluded providers. This would provide a mechanism to recover from a potential state corruption event.