- Hacken
- Audits
- cosmic-signature
- [SCA] Cosmic Signature | Cosmicsignature-Contracts | Oct2025
Introduction
We express our gratitude to the Cosmic Signature team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
CosmicSignature is an on-chain gamified bidding ecosystem that combines ERC-20 tokens, ERC-721 NFTs, randomness-driven prize selection, and multiple treasury/staking wallets into a unified interactive experience.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Cosmic Signature |
| Audited By | Seher Saylik, Kaan Caglan |
| Approved By | |
| Website | https://randomwalknft.com→ |
| Changelog | 08/12/2025 - Preliminary Report |
| 09/01/2025 - Final Report | |
| Platform | EVM |
| Language | Solidity |
| Tags | ERC-20, ERC-721, Bidding |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Cosmic Signature
- Audited By
- Seher Saylik, Kaan Caglan
- Approved By
- Website
- https://randomwalknft.com→
- Changelog
- 08/12/2025 - Preliminary Report
- 09/01/2025 - Final Report
- Platform
- EVM
- Language
- Solidity
- Tags
- ERC-20, ERC-721, Bidding
Review Scope | |
|---|---|
| Repository | https://github.com/PredictionExplorer/Cosmic-Signature/tree/main→ |
| Commit | 9385ddb |
Review Scope
- Commit
- 9385ddb
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}
Documentation quality
A technical description is provided.
Natspec is sufficient.
Code quality
Some best practices are not applied across the codebase.
Several modules contain redundant logic and unnecessary initializations that reduce readability.
Critical parameters lack validation (e.g., divisors, raffle counts), increasing the risk of edge-case failures.
The presence of commented-out code, TODOs, and development artifacts suggests the code is not production-hardened.
Test coverage
Code coverage of the project is 100% (branch coverage)
Deployment workflows and basic user interactions are covered.
The implementation covers the most important functionalities
System Overview
System Overview
The CosmicSignature Protocol is a multi-contract system composed of bidding mechanics, prize distribution logic, NFT minting pathways, treasury/staking wallets, and global configuration management.
At a high level, the system includes the following major components:
Token Layer
CosmicSignatureTokensol
Standard ERC-20 token used as the core currency of the ecosystem.
Minting is strictly controlled and used for reward distribution across game/prize modules.
Burn operations occur when bids or rewards require token destruction.
CosmicSignatureNftsol
ERC-721 NFT representing in-game collectibles with configurable metadata.
Minting is performed by game contracts or staking wallets as rewards for participation.
RandomWalkNFTsol
A secondary NFT collection with its own minting and reward logic.
Used in staking wallets and donation flows.
Core Game Mechanics
CosmicSignatureGamesol
The central coordination contract orchestrating game rounds. It interacts with:
BiddingBase / Bidding.sol – handles bid placement (ETH or CST token bids), bid recording, and time-based bidding windows.
MainPrizeBase / MainPrize.sol – manages main prize selection, claiming, and reward distribution logic.
SecondaryPrizes.sol – issues secondary rewards to bidders using randomness and weighted selection.
BidStatistics.sol – stores cumulative stats used for analytics or invariant-checking.
Game logic includes:
Time-locked bidding rounds
Randomized prize awarding
Token-based reward distribution
Multiple prize tiers
Wallets Treasury Contracts
PrizesWalletsol
Holds tokens designated for rewards. Funds are transferred to winners when the main or secondary prizes are claimed.
MarketingWalletsol
Receives a fixed proportion of fees for marketing-related expenditures.
CharityWalletsol EthDonationssol NftDonationssol DonatedTokenHoldersol
A series of contracts directing ETH, ERC-20, and NFT donations. These wallets support philanthropic or promotional allocations defined by the system manager.
Staking System
The protocol includes several staking contracts:
StakingWalletNftBase.sol
StakingWalletCosmicSignatureNft.sol
StakingWalletRandomWalkNft.sol
These wallets provide staking rewards for users who lock NFTs. Reward logic may include:
CST token issuance
Randomly assigned NFT rewards
Time-weighted emission
Governance Configuration
SystemManagementsol
A privileged contract functioning as the protocol’s global configuration repository. It can:
Register/update critical system addresses
Enable/disable modules
Manage vesting schedules
Update reward parameters
Coordinate contract interactions
This contract has significant power over system behavior and must be tightly secured.
OwnableUpgradeableWithReservedStorageGapssol
Used across upgradeable contracts for storage layout safety.
Privileged Roles
System Manager / Owner Controls the SystemManagement contract and can update nearly all critical addresses in the ecosystem, including game modules, wallets, and token/NFT reward contracts. This grants broad authority and must be considered a trusted party.
Potential Risks
The protocol relies on block-dependent, predictable randomness, which can be influenced by transaction timing or block producers. Such weak RNG may enable manipulation of outcomes intended to be random, reducing the fairness and integrity of reward distributions.
The protocol relies on block-dependent and sequencer-influenced randomness sources (e.g., blockhash, basefee, and Arbitrum precompile outputs). These values can be partially controlled or predicted by block producers, allowing attackers to influence outcomes intended to be random. Additionally, if the contract is deployed on a non-Arbitrum chain, the hard-coded precompile addresses (0x64, 0x6C) may point to attacker-controlled contracts instead of real system precompiles. In such environments, an adversary could fully control the returned “randomness,” enabling deterministic manipulation of prize selection or reward distribution.
The protocol does not enforce uniqueness for the randomness seed used during NFT minting under CosmicSignatureNft. Although collisions are unlikely due to hashing, it is technically possible for two NFTs to receive the same seed, which would result in identical generated artwork or visual traits. While this does not affect core logic, users may encounter duplicate-looking NFTs in rare cases.
The deployed CosmicSignatureDao contract is present on-chain but is not used by the protocol at launch, as governance actions remain fully centralized under the team. If activated in the future, the DAO will require additional review to ensure that governance powers, quorum parameters, and upgrade workflows cannot be abused or misconfigured.
RandomWalk NFTs are permanently marked as unusable after a single bid discount, with the restriction tied to the token ID itself (not the owner), meaning the NFT remains worthless for game utility even when transferred/sold to new owners or across multiple rounds, effectively destroying secondary market value and potentially misleading buyers who acquire "used" NFTs without on-chain indication of their consumed status.
The _distributePrizes function contains deeply nested logic, multiple dynamic loops, and large in-memory array constructions whose size depends on the number of bidders and stakers. In high-load rounds with many participants, this function may exceed block gas limits or revert due to oversized memory allocations, preventing prize distribution and halting round progression.
ETH bids and CST bids operate on two completely separate Dutch auction curves with independent pricing mechanisms, allowing the cost of a CST bid to be significantly lower than a preceding ETH bid without any cross-validation or unified economic progression between the two bid types.
The CharityWallet contract allows any address to trigger the transfer of the entire contract balance to the designated charity address without owner restrictions or access control checks.
The protocol’s upgradeable contracts introduce centralization trust assumptions where the owner can modify core logic without user consent, while also exposing the system to technical risks such as storage layout collisions, initialization errors, or unintended behavioral changes during upgrades that could result in loss of funds or broken functionality.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1415 | Block-Dependent Randomness Can Be Strategically Timed by Caller to Influence Raffle Rewards | accepted | Medium | |
| F-2025-1411 | Bidding Can Continue After the Round Should Be Closed, Extending the Game Illegitimately | mitigated | Medium | |
| F-2025-1404 | CST Bidding Allows Net Token Gain When Dutch Auction Price Falls Below Reward | accepted | Medium | |
| F-2025-1416 | Division By Zero Possibility in Prize Distribution | accepted | Low | |
| F-2025-1414 | ETH Distribution Percentages Can Exceed 100% | accepted | Low | |
| F-2025-1411 | timeoutDurationToWithdrawPrizes Can Be Set To Unbounded Values | accepted | Low | |
| F-2025-1405 | ETH Rounding Loss in Raffle Prize Distribution and NFT Reward Calculation | accepted | Low | |
| F-2025-1417 | Division by Zero and Infinite Loop When Raffle Counts Set to Zero | accepted | Low | |
| F-2025-1417 | Main prize cannot be claimed if marketingWallet is not initialized | accepted | Low | |
| F-2025-1416 | Use of Extremely Large Fixed-Size Arrays | accepted | Low |
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/PredictionExplorer/Cosmic-Signature/tree/main→ |
| Commit | 9385ddbacc9a0543d19e69f33fbd96d067a6d361 |
| Whitepaper | N/A |
| Requirements | N/A |
| Technical Requirements | https://github.com/PredictionExplorer/Cosmic-Signature/tree/main/docs→ |
Scope Details
- Commit
- 9385ddbacc9a0543d19e69f33fbd96d067a6d361
- Whitepaper
- N/A
- Requirements
- N/A
- Technical Requirements
- https://github.com/PredictionExplorer/Cosmic-Signature/tree/main/docs→
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Cosmic Signature, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry →, a tool used for fuzz and 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, 14 invariants were tested over 10,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Total ETH in system should equal deposits minus withdrawals | Passed | 10k |
| After an ETH bid, the next ETH bid price must always increase | Passed | 10k |
| Round number should never decrease | Passed | 10k |
| If any bid was placed, lastBidderAddress should not be zero | Passed | 10k |
| ETH bid price should always be > 0 | Passed | 10k |
| If bids placed, mainPrizeTime should be in the future | Passed | 10k |
| Total deposited should always be >= total withdrawn | Passed | 10k |
| Total CST minted should be at least (bids * min reward) | Passed | 10k |
| System ETH should always be sufficient for theoretical obligations | Passed | 10k |
| Each bid should extend the main prize time | Passed | 10k |
| Sum of all actor bid counts should equal total bids tracked | Passed | 10k |
| If round is active, activation time should be in the past | Passed | 10k |
| CST Dutch auction price should decrease as time passes without CST bids | Passed | 10k |
| Total bids should be always equal to ETH bids + CST bids | Passed | 10k |
Invariant
- Total ETH in system should equal deposits minus withdrawals
Test Result
- Passed
Run Count
- 10k
Invariant
- After an ETH bid, the next ETH bid price must always increase
Test Result
- Passed
Run Count
- 10k
Invariant
- Round number should never decrease
Test Result
- Passed
Run Count
- 10k
Invariant
- If any bid was placed, lastBidderAddress should not be zero
Test Result
- Passed
Run Count
- 10k
Invariant
- ETH bid price should always be > 0
Test Result
- Passed
Run Count
- 10k
Invariant
- If bids placed, mainPrizeTime should be in the future
Test Result
- Passed
Run Count
- 10k
Invariant
- Total deposited should always be >= total withdrawn
Test Result
- Passed
Run Count
- 10k
Invariant
- Total CST minted should be at least (bids * min reward)
Test Result
- Passed
Run Count
- 10k
Invariant
- System ETH should always be sufficient for theoretical obligations
Test Result
- Passed
Run Count
- 10k
Invariant
- Each bid should extend the main prize time
Test Result
- Passed
Run Count
- 10k
Invariant
- Sum of all actor bid counts should equal total bids tracked
Test Result
- Passed
Run Count
- 10k
Invariant
- If round is active, activation time should be in the past
Test Result
- Passed
Run Count
- 10k
Invariant
- CST Dutch auction price should decrease as time passes without CST bids
Test Result
- Passed
Run Count
- 10k
Invariant
- Total bids should be always equal to ETH bids + CST bids
Test Result
- Passed
Run Count
- 10k
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.
Frameworks and Methodologies
This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.