Introduction
We express our gratitude to the Sky Coin (XSO) team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
SkyCoin (XSO) is an enhanced ERC20 token that integrates burn and pause capabilities, anti-whale protections, blacklist controls, and owner-configurable limits to provide a secure, compliant, and adaptable digital asset.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Sky Coin (XSO) |
| Audited By | Panagiotis Konstantinidis, Franco Bregante |
| Approved By | Ivan Bondar |
| Website | https://www.skyxso.com→ |
| Changelog | 11/08/2025 - Preliminary Report |
| 13/08/2025 - Remediation Report | |
| 19/08/2025 - Final Report | |
| Platform | BSC |
| Language | Solidity |
| Tags | Fungible Token, ERC-20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Sky Coin (XSO)
- Audited By
- Panagiotis Konstantinidis, Franco Bregante
- Approved By
- Ivan Bondar
- Website
- https://www.skyxso.com→
- Changelog
- 11/08/2025 - Preliminary Report
- 13/08/2025 - Remediation Report
- 19/08/2025 - Final Report
- Platform
- BSC
- Language
- Solidity
- Tags
- Fungible Token, ERC-20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/skyoption/xso→ |
| Initial Commit | 97ac21a |
| Remediation Commit | c49d600 |
| Deployed Address | https://bscscan.com/token/0xfb40a811FB2568de9709476c09935a6A0DAFA6aa→ |
Review Scope
- Repository
- https://github.com/skyoption/xso→
- Initial Commit
- 97ac21a
- Remediation Commit
- c49d600
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional and technical requirements are clearly outlined.
Security measures like access control, and input validation are well-documented.
Detailed deployment, testing, and verification procedures are provided.
Documentation is clear and whitepaper is provided.
Code quality
NatSpec comments are provided.
The development environment is configured.
Organized with separate sections for functionality.
Test coverage
Code coverage of the project is 92% (branch coverage).
Core functionality and edge cases are covered.
Negative scenarios, such as invalid inputs and unauthorized access, are tested.
System Overview
SkyCoin (XSO) is an ERC20-based token contract that incorporates burn and pause features, anti-whale protections, blacklist controls, and owner-configurable limits to enhance security and compliance. It is built on top of OpenZeppelin’s ERC20, ERC20Burnable, ERC20Pausable, and Ownable modules.
The token implements the following functionalities:
Burn: Allows holders to destroy their tokens, reducing the total supply.
Pause/Unpause: Enables the owner to halt or resume functionalities of the token in emergency situations.
Blacklist: Blocks blacklisted addresses from transferring tokens.
Anti-Whale Protections: Enforces configurable maximum transaction amounts and wallet balances.
Exemption List: Allows specified addresses to bypass anti-whale restrictions.
Configurable Limits: The owner can update transaction and wallet limits or disable them entirely.
It has the following attributes:
Name: Sky Coin
Symbol: XSO
Decimals: 18
Total Supply: 1,000,000,000,000 tokens (1 trillion XSO) minted at deployment to the specified recipient address.
Privileged roles
The owner of the SkyCoin contract holds full administrative control over all system parameters and restrictions. Specifically, the owner can:
Pause and unpause all token transfers at any time.
Blacklist or unblacklist any address, preventing them from sending or receiving tokens.
Update maximum transaction amounts and wallet balances, directly altering anti-whale protections.
Toggle the anti-whale limits on or off, or remove them entirely through the emergency function.
Grant or revoke exemption status for any address, allowing it to bypass anti-whale restrictions.
This level of control allows the owner to arbitrarily modify the operational rules governing token transfers and restrictions. As a result, the owner has the ability to significantly alter the token’s transfer behavior, disable protections, or restrict participation for any address. At present, the owner of the contract is a multi-signature wallet, which reduces the risk of a single point of failure or unilateral misuse of these privileges.
Potential Risks
Centralized Minting to a Single Address: The project concentrates minting tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.
Owner's Unrestricted State Modification: The owner can arbitrarily modify transaction limits, wallet limits, blacklist status, and exemption lists, enabling changes to anti-whale protections and transfer behavior at any time. Such unrestricted control introduces centralization risk and may affect contract integrity and user trust if misused or compromised. These privileges could also be configured in a way that prevents token holders from transferring or selling their tokens, effectively locking them or making them unsellable.
Absence of Time-lock Mechanisms for Critical Operations: The contract does not implement any delay or review mechanism for sensitive administrative actions. This allows immediate execution of potentially impactful changes, such as disabling limits or blacklisting addresses, without providing stakeholders an opportunity to review or react, increasing the risk of misuse.
Administrative Key Control Risks: All sensitive configuration changes, including blacklisting, limit adjustments, and pausing transfers, are gated by a single administrative key. If this key is compromised, the attacker could immediately alter transfer conditions, disable protections, and impact token holder activity.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1207 | Improper Wallet Limit Check in _checkLimits for DEX Pair Address Enables Anti-Whale Restriction Bypass or Blocks Token Sales | fixed | Medium | |
| F-2025-1206 | Misleading Documentation in emergencyRemoveLimits Allows Limits to Be Reinstated | fixed | Low | |
| F-2025-1206 | Inefficient Code Patterns and Unused Errors Reduce Code Efficiency | fixed | Observation | |
| F-2025-1206 | Unused ReentrancyGuard Increases Code Complexity Without Providing Protection | fixed | Observation | |
| F-2025-1206 | Floating Pragma | fixed | Observation |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/skyoption/xso→ |
| Initial Commit | 97ac21ad3c0b5630977f6bee3111e26c68613d94 |
| Remediation Commit | c49d6001c358b3855453c2cc80c1b23e2945a510 |
| Deployed Address | https://bscscan.com/token/0xfb40a811FB2568de9709476c09935a6A0DAFA6aa→ |
| Whitepaper | Shared internally |
| Requirements | README.md |
| Technical Requirements | TECHNICAL_DOCUMENTATION.md |
Scope Details
- Repository
- https://github.com/skyoption/xso→
- Initial Commit
- 97ac21ad3c0b5630977f6bee3111e26c68613d94
- Remediation Commit
- c49d6001c358b3855453c2cc80c1b23e2945a510
- Whitepaper
- Shared internally
- Requirements
- README.md
- Technical Requirements
- TECHNICAL_DOCUMENTATION.md
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.