Audit name:
[SCA] Backstage / ERC20 / May 2025
Date:
May 21, 2025
Table of Content
Introduction
We express our gratitude to the BKSbackstage OÜ team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Backstage is committed to revolutionizing the global entertainment industry by leveraging blockchain technology, AI, and a decentralized ecosystem.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for BKSbackstage OÜ |
| Audited By | Stepan Chekhovskoi |
| Approved By | Ataberk Yavuzer |
| Website | https://bksbackstage.io→ |
| Changelog | 13/05/2025 - Preliminary Report |
| 21/05/2025 - Final Report | |
| Platform | Binance Smart Chain |
| Language | Solidity |
| Tags | BEP-20, Centralization |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for BKSbackstage OÜ
- Audited By
- Stepan Chekhovskoi
- Approved By
- Ataberk Yavuzer
- Website
- https://bksbackstage.io→
- Changelog
- 13/05/2025 - Preliminary Report
- 21/05/2025 - Final Report
- Platform
- Binance Smart Chain
- Language
- Solidity
- Tags
- BEP-20, Centralization
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/BKSbackstage/Smart_contracs_bks→ |
| Initial Commit | 3feef73e2174175ab4c967207f2fab76d9f853a7 |
| Final Commit | c2ee200eacf88499fda85c107647bdba396dcfe4 |
Review Scope
- Initial Commit
- 3feef73e2174175ab4c967207f2fab76d9f853a7
- Final Commit
- c2ee200eacf88499fda85c107647bdba396dcfe4
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are missed.
Technical description is not provided.
NatSpec comments are not provided.
Code quality
Development environment is not set up.
Order of Layout → style guide is violated.
Configuration functions do not emit events.
The contract is developed under floating pragma.
Require statement may cause failure without a reason string.
Test coverage
Code coverage of the project is 0% (branch coverage).
No tests are provided in the repository.
System Overview
The smart contract is a simple BEP-20 token with few additional functionalities.
Decimals: 10.
Symbol: BKS.
Name: Backstage.
Total Supply: 1B * 10 ** decimals.
The burn function allows the smart contract owner to burn his funds.
Any transfer requires an external contract approval until the smart contract owner disables the validation.
Privileged roles
The Owner of the smart contract is able to burn his funds.
The Owner of the smart contract is able to update the external contract validating the transfers.
The Owner of the smart contract is able to fully disable the external contract validating the transfers functionality without ability of enabling it again.
Potential Risks
Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.
Controlled Transfers: The system implements the token transfer control by an external contract. This may lead to specific executor/from/to/amount transfer combinations are banned. E.g. some users are banned from transacting the token or non-EOA transfers are forbidden.
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.
Single Points of Failure and Control: The project is mostly centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.
Dependencies of Arbitrary Version: The contract imports OZ libraries, however, the repository does not provide development environment managing the dependencies version. This may lead to the contract is not operable in case unsupported dependency version is used for the deployment.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1030 | Lack of Overriding Function Execution | fixed | Observation | |
| F-2025-1030 | Lack Of Two-Step Ownership Transfer Pattern | fixed | Observation |
Identify vulnerabilities in your smart contracts.
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/BKSbackstage/Smart_contracs_bks→ |
| Initial Commit | 3feef73e2174175ab4c967207f2fab76d9f853a7 |
| Final Commit | c2ee200eacf88499fda85c107647bdba396dcfe4 |
| Whitepaper | https://docsend.com/view/r4678eqkbncy5nrm→ |
| Requirements | N/A |
| Technical Requirements | N/A |
Scope Details
- Initial Commit
- 3feef73e2174175ab4c967207f2fab76d9f853a7
- Final Commit
- c2ee200eacf88499fda85c107647bdba396dcfe4
- Requirements
- N/A
- Technical Requirements
- N/A
Assets in Scope
Backstage.solAppendix 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.