Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →

Audit name:

[SCA] Mogul Productions | Stars-Contracts-V2 | June2024

Date:

Jun 24, 2024

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Mogul Productions team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Mogul is a global non-fungible token (NFT) and decentralized financing (DeFi) platform for film and entertainment.

Document

NameSmart Contract Code Review and Security Analysis Report for Mogul Productions
Audited ByKornel Światłowski
Approved ByPrzemyslaw Swiatowiec
Websitehttps://www.mogulproductions.com/→
Changelog12/06/2024 - Preliminary Report; 24/06/2024 - Final Report
PlatformEthereum, Binance Smart Chain
LanguageSolidity
TagsERC20
Methodologyhttps://hackenio.cc/sc_methodology→
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Mogul Productions
    Audited By
    Kornel Światłowski
    Approved By
    Przemyslaw Swiatowiec
    Changelog
    12/06/2024 - Preliminary Report; 24/06/2024 - Final Report
    Platform
    Ethereum, Binance Smart Chain
    Language
    Solidity
    Tags
    ERC20

Review Scope

Repositoryhttps://github.com/mogulproductions/stars-contracts-v2→
Commit7ad7e72ea11353cfd0c1fe6cfc539e42e2080fc8

Audit Summary

8Total Findings
0Resolved
8Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are detailed.

  • Technical description is detailed.

Code quality

  • The development environment is configured.

  • Insufficient Gas modeling.

Test coverage

Code coverage of the project is 60% (branch coverage).

  • Deployment and some basic user interactions are covered with tests.

System Overview

MOGUL is a straightforward ERC20 token that allocates the entire initial supply to a designated holder. The contract is deployed on Ethereum chain. The contract owner has the ability to mint up to 4% of the current total supply annually. Additionally, the contract features both blacklist and whitelist mechanisms, allowing whitelisted addresses to transfer tokens even when the contract is paused. It has the following attributes:

  • Name: Mogul Productions Entertainment Token

  • Symbol: MOGUL

  • Decimals: 18

  • Initial supply: 1000000_000

MOGULBSC is a straightforward ERC20 token with no initial supply. This contract is the Binance Smart Chain equivalent of the MOGUL ERC20 contract deployed on Ethereum. Additional minting is possible by bridging tokens from the Ethereum chain. The contract also includes blacklist and whitelist mechanisms, allowing whitelisted addresses to transfer tokens even when the contract is paused. It has the following attributes:

  • Name: Mogul Productions Entertainment Token

  • Symbol: MOGUL

  • Decimals: 18

  • Initial supply: 0

BasicMetaTransaction contract enables the execution of meta-transactions, allowing users to perform operations without directly sending transactions on the blockchain. It facilitates the delegation of transaction execution to a relayer, who submits the transaction on behalf of the user.

Privileged roles

The MOGUL contract utilizes the Ownable library from OpenZeppelin for access control management. The owner has the authority to:

  • Pause and unpause the contract

  • Modify the whitelist and blacklist status of specific addresses

  • Mint up to 4% of the total supply annually

  • Initiate a new minting period each year

The MOGULBSC contract utilizes the AccessControl library from OpenZeppelin for access control management.

Then addresses with BRIDGE_ROLE can:

  • mint new tokens

Then addresses with DEFAULT_ADMIN_ROLE can:

  • Pause and unpause the contract

  • Modify the whitelist and blacklist status of specific addresses

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.

The contract owner can arbitrarily blacklist a given address, disabling them to move MOGUL ERC20 tokens.

Findings

F-2024-3770The usage of the precompile ecrecover can lead to signature mailability
Status
accepted
Severity

Medium
F-2024-3771Redundant payable keyword in the executeMetaTransaction function can lead to lock of native tokens
Status
accepted
Severity

Low
F-2024-3823Redundant variable assignment increases gas cost in BasicMetaTransaction
Status
accepted
Severity

Observation
F-2024-3796Public function should be declared as external
Status
accepted
Severity

Observation
F-2024-3769Redundant getChainID() wrapper leads to higher deployment cost
Status
accepted
Severity

Observation
F-2024-3768Gas inefficiency due to missing usage of Solidity custom errors
Status
accepted
Severity

Observation
F-2024-3765Overuse of DEFAULTADMINROLE could lead to security risks
Status
accepted
Severity

Observation
F-2024-3764Missing two-step ownership transfer process
Status
accepted
Severity

Observation
Code
―
Title
Status
Severity
F-2024-3770The usage of the precompile ecrecover can lead to signature mailability
accepted

Medium
F-2024-3771Redundant payable keyword in the executeMetaTransaction function can lead to lock of native tokens
accepted

Low
F-2024-3823Redundant variable assignment increases gas cost in BasicMetaTransaction
accepted

Observation
F-2024-3796Public function should be declared as external
accepted

Observation
F-2024-3769Redundant getChainID() wrapper leads to higher deployment cost
accepted

Observation
F-2024-3768Gas inefficiency due to missing usage of Solidity custom errors
accepted

Observation
F-2024-3765Overuse of DEFAULTADMINROLE could lead to security risks
accepted

Observation
F-2024-3764Missing two-step ownership transfer process
accepted

Observation
1-8 of 8 findings

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:

Assets in Scope

MOGUL.sol - MOGUL.sol
MOGULBSC.sol - MOGULBSC.sol
BasicMetaTransaction.sol - BasicMetaTransaction.sol

Disclaimer