Audit name:
[SCA] Xgame | Crash Monorepo | Jun2025
Date:
Aug 19, 2025
Table of Content
Introduction
We express our gratitude to the XGame team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
XGame is a decentralized on-chain gaming platform that implements a modular casino architecture featuring crash-style betting games with provably fair randomness through commit-reveal schemes, unified multi-asset balance management across multiple games, a sophisticated multi-level affiliate commission system, and integrated tokenomics including staking and buy-and-burn mechanisms for sustainable platform economics.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for XGame |
| Audited By | Georgi Krastenov, Ataberk Yavuzer |
| Approved By | Ivan Bondar |
| Website | https://xgame.io→ |
| Changelog | 21/07/2025 - Preliminary Report |
| 19/08/2025 - Final Report | |
| Platform | Pulsechain, Base |
| Language | Solidity |
| Tags | Gambling, Play to Earn, Staking, Swaps |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for XGame
- Audited By
- Georgi Krastenov, Ataberk Yavuzer
- Approved By
- Ivan Bondar
- Website
- https://xgame.io→
- Changelog
- 21/07/2025 - Preliminary Report
- 19/08/2025 - Final Report
- Platform
- Pulsechain, Base
- Language
- Solidity
- Tags
- Gambling, Play to Earn, Staking, Swaps
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/xgame-io/crash-monorepo→ |
| Initial Commit | 9bc44d5af5a36c5eddb8024f1ef46ff94a86e05f |
| Remediation Commit | 1d172368582da38a7be2301e1fdb3f3ed1de0695 |
Review Scope
- Initial Commit
- 9bc44d5af5a36c5eddb8024f1ef46ff94a86e05f
- Remediation Commit
- 1d172368582da38a7be2301e1fdb3f3ed1de0695
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are covered.
Technical descriptions are well-provided.
Provided documentation is satisfactory.
Code quality
The development environment is well-configured.
Code architecture has a modular design with clear separation of concerns.
Test coverage
Code coverage of the project is 91.97% (branch coverage), with a mutation score of 96%.
Deployment and basic user interactions are covered with tests.
Interactions by several users are not tested thoroughly.
System Overview
XGame is a decentralized gaming platform that implements a comprehensive on-chain casino ecosystem with the following core contracts:
Core Contracts
Crash — The primary game contract implementing a round-based "crash" style betting game where players bet against an off-chain oracle. Players can cash out at increasing multipliers before the game "crashes" at a random point determined by a provably fair commit-reveal scheme.
BalanceManager — Manages in-game asset balances for both users and the house across multiple assets (ETH, ERC20 tokens). Handles deposits, withdrawals, bet reservations, and payout settlements. The house balance can intentionally go negative to prevent game interruption.
Affiliate — A sophisticated multi-level marketing (MLM) system that manages referral relationships and commission payouts across all games and assets. Supports multiple callers (different games) with independent commission structures and cross-asset commission swapping.
Staking — A tiered staking contract that allows users to stake tokens and achieve different tier levels based on USD value thresholds. Includes features like delegation, emergency shutdown, and tier-based benefits.
UniversalBuyAndBurn — A tokenomics contract that periodically buys back and burns platform tokens using accumulated fees from various input tokens. Implements MEV protection through cooldown periods and bot prevention mechanisms.
Uniswap V Integration Libraries
Oracle — Price oracle functionality for fetching time-weighted average prices (TWAP) from Uniswap V3 pools, used for accurate price feeds in token swapping and valuation.
TickMath — Mathematical utilities for Uniswap V3 tick calculations, converting between ticks and sqrt price ratios for precise liquidity position management.
LiquidityAmounts — Calculates liquidity amounts for Uniswap V3 positions, determining token amounts needed for specific liquidity ranges and price points.
PositionValue — Computes the current value of Uniswap V3 liquidity positions, including both principal and accumulated fees for portfolio valuation.
PoolAddress — Deterministically computes Uniswap V3 pool addresses from token pairs and fee tiers, adapted for Solidity 0.8+ compatibility with explicit type conversions.
PathDecoder — Decodes multi-hop swap paths for complex token routing through Uniswap V3, enabling efficient cross-asset swaps in the affiliate and buy-burn systems.
PositionKey — Utility for generating unique position identifiers in Uniswap V3 liquidity management operations.
The architecture is designed for uniform deployment across multiple blockchain networks, with each chain maintaining independent instances of all contracts while sharing the same operational logic and security model.
Privileged Roles
The system uses OpenZeppelin's AccessManager for role-based permissions:
DEFAULT_ADMIN_ROLE
Can grant and revoke all other roles
Has ultimate control over the access control system
Can modify critical system parameters
GAME_ROLE
Authorized to call reserve/release functions on BalanceManager contracts
Can process bet settlements and multiply user balances
Essential for game contract operations
GAME_ENGINE_ROLE
Can initialize, begin, and end game rounds in the Crash contract
Controls the game's oracle functionality and round state transitions
Manages the commit-reveal process and random number generation
HOUSE_MANAGER_ROLE
Can deposit and withdraw house funds from BalanceManager contracts
Manages house balance and casino bankroll operations
Can modify reserve limits and emergency pause contracts
Potential Risks
External DeFi Protocol Dependencies: The system's buy-and-burn and affiliate swap mechanisms heavily rely on Uniswap V3 contracts and liquidity, inheriting all associated risks.
Centralized Oracle Control: Game fairness depends on off-chain oracle integrity for commit-reveal scheme execution and round management.
Administrative Privilege Concentration: Multiple critical roles (admin, house manager, game engine) have extensive control over user funds and system parameters without multi-signature protection.
External Contract Integration Risks: Heavy reliance on OpenZeppelin contracts and Uniswap V3 libraries creates dependencies on external code not covered in this audit scope.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1174 | No Replay Protection in transfer() Allows Reuse of Signatures | fixed | Medium | |
| F-2025-1163 | User Can Over Stake When Upgrading Tier | fixed | Medium | |
| F-2025-1153 | Potential Underflow in pendingWins When Losses Outweigh Wins in Crash Game | fixed | Medium | |
| F-2025-1177 | Avoid Off-Chain Price Data in Staking Contract | accepted | Low | |
| F-2025-1177 | Total Commission Rates Can Exceeding 100 Percent | accepted | Low | |
| F-2025-1162 | Stale Oracle Price Signature Can Be Reused | fixed | Low | |
| F-2025-1177 | Refactor Repeated Deadline Checks | fixed | Observation | |
| F-2025-1177 | Misleading Comment | fixed | Observation | |
| F-2025-1176 | Missing Input Token Validation in Path | fixed | Observation | |
| F-2025-1173 | Missing Event Emissions in Crucial Places | 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/xgame-io/crash-monorepo→ |
| Initial Commit | 9bc44d5af5a36c5eddb8024f1ef46ff94a86e05f |
| Remediation Commit | 1d172368582da38a7be2301e1fdb3f3ed1de0695 |
| Whitepaper | N/A |
| Requirements | ./docs/Crash-Game Overview.md |
| Technical Requirements | ./docs/Crash-Game Overview.md |
Scope Details
- Initial Commit
- 9bc44d5af5a36c5eddb8024f1ef46ff94a86e05f
- Remediation Commit
- 1d172368582da38a7be2301e1fdb3f3ed1de0695
- Whitepaper
- N/A
- Requirements
- ./docs/Crash-Game Overview.md
- Technical Requirements
- ./docs/Crash-Game Overview.md
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of XGame, Hacken followed its methodology by performing invariant testing on the project's code and documentation. Foundry →, a tool used for invariant testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 37 invariants were tested over 100,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant ID | Category | Test Case | Description | Status |
|---|---|---|---|---|
| INV-001 | Financial Integrity | invariant_INV001_TotalDepositsEqualSumOfIndividualDeposits() | Total user deposits must always equal the sum of all individual user deposit balances | Passed |
| INV-002 | Financial Integrity | invariant_INV002_ReservedAmountsNeverExceedAvailableBalances() | Reserved amounts must never exceed available user balances | Passed |
| INV-003 | Financial Integrity | invariant_INV003_ContractBalanceEqualsTrackedBalanceComponents() | House balance + pending wins must equal total house deposits minus total user wins | Passed |
| INV-004 | Financial Integrity | invariant_INV004_UserBalancesNeverNegative() | User's total balance (deposits + wins - reserved) must never be negative | Passed |
| INV-005 | Financial Integrity | invariant_INV005_BetWagersEqualReservedAmounts() | Sum of all bet wagers in a round must equal total reserved amounts for that round | Passed |
| INV-006 | Financial Integrity | invariant_INV006_HouseEdgeMaintained() | House edge must be maintained: total losses > total wins over time | Passed |
| INV-007 | Financial Integrity | invariant_INV007_RandomNumberWithinBounds() | Random number must always be between 1 and BASIS (10,000) inclusive | Passed |
| INV-008 | Game Mechanics | invariant_INV008_DeterministicMultiplierCalculation() | Crash multiplier calculation must be deterministic given same random input | Passed |
| INV-009 | Game Mechanics | invariant_INV009_CommitRevealIntegrity() | Commit-reveal scheme: revealed secret must hash to the original commitment | Passed |
| INV-010 | Game Mechanics | invariant_INV010_RandomNumberDerivation() | Random number must be derived from keccak256(secret ‖ blockHash) % BASIS + 1 | Passed |
| INV-011 | Game Mechanics | invariant_INV011_BlockHashConsistency() | Block hash used must be from the committed block number | Passed |
| INV-012 | Game Mechanics | invariant_INV012_RoundTimeoutRespected() | Round timeout must be respected - no operations after timeout | Passed |
| INV-013 | State Management | invariant_INV013_ValidRoundStateTransitions() | Round states must follow valid transitions: INVALID → INITIALIZED → ACTIVE → COMPLETED | Passed |
| INV-014 | State Management | invariant_INV014_OneBetPerUserPerRound() | Only one bet per user per round is allowed | Passed |
| INV-015 | State Management | invariant_INV015_ValidBetStateTransitions() | Bet states must follow valid transitions: Invalid → Pending → {Finalized, Refunded, Failed} | Passed |
| INV-016 | State Management | invariant_INV016_MaxBetsPerRoundLimit() | Maximum bets per round must not exceed MAXBETSPER_ROUND (100) | Passed |
| INV-017 | Access Control | invariant_INV017_OnlyOracleCanCallRestrictedFunctions() | Only authorized oracle can call restricted functions (initializeRound, beginRound, endRound) | Passed |
| INV-018 | Access Control | invariant_INV018_OnlyGameRoleCanReserveReleaseFunds() | Only contracts with GAME_ROLE can reserve/release user funds | Passed |
| INV-019 | Access Control | invariant_INV019_OnlyHouseManagerCanManageHouseFunds() | Only addresses with HOUSEMANAGERROLE can manage house funds | Passed |
| INV-020 | Access Control | invariant_INV020_OnlyAuthorizedCanRegisterUsersInAffiliate() | Only authorized addresses can register users in affiliate system | Passed |
| INV-021 | Bet Processing | invariant_INV021_ExitCountMatchesBetCount() | Exit count must exactly match bet count when ending a round | Passed |
| INV-022 | Bet Processing | invariant_INV022_BetMultipliersWithinBounds() | Bet multipliers must be ≥ 0 (losses allowed) and ≤ maximum configured multiplier | Passed |
| INV-023 | Bet Processing | invariant_INV023_ReservedAmountsReleasedOnce() | Reserved amounts must be released exactly once per bet | Passed |
| INV-024 | Bet Processing | invariant_INV024_FailedBetsGetFullRefunds() | Failed bets must result in full refunds | Passed |
| INV-025 | Affiliate System | invariant_INV025_CommissionPercentagesWithinBounds() | Commission percentages must never exceed 100% (BASIS) in total | Passed |
| INV-026 | Affiliate System | invariant_INV026_AffiliateTreeAcyclic() | Affiliate tree relationships must be acyclic (no circular references) | Passed |
| INV-027 | Affiliate System | invariant_INV027_MLMCommissionsDecrease() | MLM level commissions must decrease or stay equal down the tree | Passed |
| INV-028 | Affiliate System | invariant_INV028_AffiliatePayoutsWithinHouseEdge() | Total affiliate payouts must not exceed configured percentage of house edge | Passed |
| INV-029 | Affiliate System | invariant_INV029_OneReferrerPerUser() | User can only have one referrer in the affiliate tree | Passed |
| INV-030 | Asset Management | invariant_INV030_NativeBalanceMatches() | Contract native token balance must equal tracked native balance | Passed |
| INV-031 | Asset Management | invariant_INV031_ERC20BalanceMatches() | ERC20 token balance must equal tracked token balance | Passed |
| INV-032 | Asset Management | invariant_INV032_ReserveLimitsRespected() | Minimum and maximum reserve limits must be respected | Passed |
| INV-033 | Asset Management | invariant_INV033_WithdrawalsWithinAvailableBalance() | Asset withdrawals must not exceed available (unreserved) balance | Passed |
| INV-034 | Recovery Mechanisms | invariant_INV034_TimedOutRoundsAllowFullRefunds() | Timed-out rounds must allow full refunds to all participants | Passed |
| INV-035 | Recovery Mechanisms | invariant_INV035_EmergencyPausePreservesRecovery() | Emergency pause must prevent new operations while allowing fund recovery | Passed |
| INV-036 | Multi-Asset Support | invariant_INV036_IndependentAssetBalanceTracking() | Each asset must have independent balance tracking | Passed |
| INV-037 | Multi-Asset Support | invariant_INV037_CrossAssetOperationsPrevented() | Cross-asset operations must be prevented | Passed |
Invariant ID
- INV-001
Category
- Financial Integrity
Test Case
invariant_INV001_TotalDepositsEqualSumOfIndividualDeposits()Description
- Total user deposits must always equal the sum of all individual user deposit balances
Status
- Passed
Invariant ID
- INV-002
Category
- Financial Integrity
Test Case
invariant_INV002_ReservedAmountsNeverExceedAvailableBalances()Description
- Reserved amounts must never exceed available user balances
Status
- Passed
Invariant ID
- INV-003
Category
- Financial Integrity
Test Case
invariant_INV003_ContractBalanceEqualsTrackedBalanceComponents()Description
- House balance + pending wins must equal total house deposits minus total user wins
Status
- Passed
Invariant ID
- INV-004
Category
- Financial Integrity
Test Case
invariant_INV004_UserBalancesNeverNegative()Description
- User's total balance (deposits + wins - reserved) must never be negative
Status
- Passed
Invariant ID
- INV-005
Category
- Financial Integrity
Test Case
invariant_INV005_BetWagersEqualReservedAmounts()Description
- Sum of all bet wagers in a round must equal total reserved amounts for that round
Status
- Passed
Invariant ID
- INV-006
Category
- Financial Integrity
Test Case
invariant_INV006_HouseEdgeMaintained()Description
- House edge must be maintained: total losses > total wins over time
Status
- Passed
Invariant ID
- INV-007
Category
- Financial Integrity
Test Case
invariant_INV007_RandomNumberWithinBounds()Description
- Random number must always be between 1 and BASIS (10,000) inclusive
Status
- Passed
Invariant ID
- INV-008
Category
- Game Mechanics
Test Case
invariant_INV008_DeterministicMultiplierCalculation()Description
- Crash multiplier calculation must be deterministic given same random input
Status
- Passed
Invariant ID
- INV-009
Category
- Game Mechanics
Test Case
invariant_INV009_CommitRevealIntegrity()Description
- Commit-reveal scheme: revealed secret must hash to the original commitment
Status
- Passed
Invariant ID
- INV-010
Category
- Game Mechanics
Test Case
invariant_INV010_RandomNumberDerivation()Description
- Random number must be derived from keccak256(secret ‖ blockHash) % BASIS + 1
Status
- Passed
Invariant ID
- INV-011
Category
- Game Mechanics
Test Case
invariant_INV011_BlockHashConsistency()Description
- Block hash used must be from the committed block number
Status
- Passed
Invariant ID
- INV-012
Category
- Game Mechanics
Test Case
invariant_INV012_RoundTimeoutRespected()Description
- Round timeout must be respected - no operations after timeout
Status
- Passed
Invariant ID
- INV-013
Category
- State Management
Test Case
invariant_INV013_ValidRoundStateTransitions()Description
- Round states must follow valid transitions: INVALID → INITIALIZED → ACTIVE → COMPLETED
Status
- Passed
Invariant ID
- INV-014
Category
- State Management
Test Case
invariant_INV014_OneBetPerUserPerRound()Description
- Only one bet per user per round is allowed
Status
- Passed
Invariant ID
- INV-015
Category
- State Management
Test Case
invariant_INV015_ValidBetStateTransitions()Description
- Bet states must follow valid transitions: Invalid → Pending → {Finalized, Refunded, Failed}
Status
- Passed
Invariant ID
- INV-016
Category
- State Management
Test Case
invariant_INV016_MaxBetsPerRoundLimit()Description
- Maximum bets per round must not exceed MAXBETSPER_ROUND (100)
Status
- Passed
Invariant ID
- INV-017
Category
- Access Control
Test Case
invariant_INV017_OnlyOracleCanCallRestrictedFunctions()Description
- Only authorized oracle can call restricted functions (initializeRound, beginRound, endRound)
Status
- Passed
Invariant ID
- INV-018
Category
- Access Control
Test Case
invariant_INV018_OnlyGameRoleCanReserveReleaseFunds()Description
- Only contracts with GAME_ROLE can reserve/release user funds
Status
- Passed
Invariant ID
- INV-019
Category
- Access Control
Test Case
invariant_INV019_OnlyHouseManagerCanManageHouseFunds()Description
- Only addresses with HOUSEMANAGERROLE can manage house funds
Status
- Passed
Invariant ID
- INV-020
Category
- Access Control
Test Case
invariant_INV020_OnlyAuthorizedCanRegisterUsersInAffiliate()Description
- Only authorized addresses can register users in affiliate system
Status
- Passed
Invariant ID
- INV-021
Category
- Bet Processing
Test Case
invariant_INV021_ExitCountMatchesBetCount()Description
- Exit count must exactly match bet count when ending a round
Status
- Passed
Invariant ID
- INV-022
Category
- Bet Processing
Test Case
invariant_INV022_BetMultipliersWithinBounds()Description
- Bet multipliers must be ≥ 0 (losses allowed) and ≤ maximum configured multiplier
Status
- Passed
Invariant ID
- INV-023
Category
- Bet Processing
Test Case
invariant_INV023_ReservedAmountsReleasedOnce()Description
- Reserved amounts must be released exactly once per bet
Status
- Passed
Invariant ID
- INV-024
Category
- Bet Processing
Test Case
invariant_INV024_FailedBetsGetFullRefunds()Description
- Failed bets must result in full refunds
Status
- Passed
Invariant ID
- INV-025
Category
- Affiliate System
Test Case
invariant_INV025_CommissionPercentagesWithinBounds()Description
- Commission percentages must never exceed 100% (BASIS) in total
Status
- Passed
Invariant ID
- INV-026
Category
- Affiliate System
Test Case
invariant_INV026_AffiliateTreeAcyclic()Description
- Affiliate tree relationships must be acyclic (no circular references)
Status
- Passed
Invariant ID
- INV-027
Category
- Affiliate System
Test Case
invariant_INV027_MLMCommissionsDecrease()Description
- MLM level commissions must decrease or stay equal down the tree
Status
- Passed
Invariant ID
- INV-028
Category
- Affiliate System
Test Case
invariant_INV028_AffiliatePayoutsWithinHouseEdge()Description
- Total affiliate payouts must not exceed configured percentage of house edge
Status
- Passed
Invariant ID
- INV-029
Category
- Affiliate System
Test Case
invariant_INV029_OneReferrerPerUser()Description
- User can only have one referrer in the affiliate tree
Status
- Passed
Invariant ID
- INV-030
Category
- Asset Management
Test Case
invariant_INV030_NativeBalanceMatches()Description
- Contract native token balance must equal tracked native balance
Status
- Passed
Invariant ID
- INV-031
Category
- Asset Management
Test Case
invariant_INV031_ERC20BalanceMatches()Description
- ERC20 token balance must equal tracked token balance
Status
- Passed
Invariant ID
- INV-032
Category
- Asset Management
Test Case
invariant_INV032_ReserveLimitsRespected()Description
- Minimum and maximum reserve limits must be respected
Status
- Passed
Invariant ID
- INV-033
Category
- Asset Management
Test Case
invariant_INV033_WithdrawalsWithinAvailableBalance()Description
- Asset withdrawals must not exceed available (unreserved) balance
Status
- Passed
Invariant ID
- INV-034
Category
- Recovery Mechanisms
Test Case
invariant_INV034_TimedOutRoundsAllowFullRefunds()Description
- Timed-out rounds must allow full refunds to all participants
Status
- Passed
Invariant ID
- INV-035
Category
- Recovery Mechanisms
Test Case
invariant_INV035_EmergencyPausePreservesRecovery()Description
- Emergency pause must prevent new operations while allowing fund recovery
Status
- Passed
Invariant ID
- INV-036
Category
- Multi-Asset Support
Test Case
invariant_INV036_IndependentAssetBalanceTracking()Description
- Each asset must have independent balance tracking
Status
- Passed
Invariant ID
- INV-037
Category
- Multi-Asset Support
Test Case
invariant_INV037_CrossAssetOperationsPrevented()Description
- Cross-asset operations must be prevented
Status
- Passed
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.