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 end an airdrop.
Note - This Audit report consists of a security analysis of the XDoorAirdrop smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited the mentioned 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
high Issues | 1 findings
Acknowledged
#1 high Issue
Missing Access Control on Administrative Functions
The XDoorAirdrop contract contains administrative functions that are intended to be privileged, but they are missing the necessary access control modifiers. Specifically, the startAirdrop and endAirdrop functions are declared as external without an onlyOwner or similar check. This flaw allows any external user or contract on the blockchain to call these critical functions at any time. A malicious actor could exploit this by calling startAirdrop with a zero amount immediately after deployment, effectively locking the contract and preventing the legitimate airdrop from ever being initiated. Similarly, anyone could call endAirdrop prematurely, disrupting the intended flow of leftover funds. This complete lack of access control on core administrative functions represents a critical vulnerability that can be used to permanently break the entire airdrop mechanism.
medium Issues | 2 findings
Resolved
#1 medium Issue
Unsigned invitor Parameter Allows Referral Hijacking
The claim function's signature verification process is critically flawed, allowing for the guaranteed theft of referral rewards. The cryptographic signature (sign) provided by the user validates the account, amount, and deadline, but it does not validate the invitor address, which is passed as a separate, untrusted parameter. This creates a signature malleability vulnerability where a malicious actor can observe a legitimate user's claim transaction in the mempool, copy all the valid signed data, and then front-run the original transaction by re-submitting it with their own address substituted as the invitor. The contract will successfully validate the signature and process the claim, but will pay the referral fee to the attacker's address instead of the legitimate inviter. This is a direct, demonstrable theft of funds that undermines the entire referral incentive system.
Acknowledged
#2 medium Issue
Malleable Signature Allows User's Choice to be Overridden
The signature verification process does not include the instant boolean flag, which determines whether a user's airdrop is claimed immediately or staked. The _PERMIT_TYPEHASH string includes "instant", but the keccak256 hash on line 146 omits it from the packed data. This allows an attacker to intercept a user's transaction from the mempool and front-run it with the same signature but a different instant value. For example, if a user intends to stake their tokens (instant = false), an attacker can force them to claim instantly (instant = true), or vice-versa. While this does not result in a direct theft of the user's main tokens, it undermines the integrity of the user's choice and forces an outcome upon them that they did not authorize with their signature.