Audit name:
[SCA] Digbi2121 | Digbi2121-Audit | Apr2026
Date:
Apr 30, 2026
Table of Content
Introduction
We express our gratitude to the Digbi2121 team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Digbi2121 is a blind-mint ERC-721A NFT collection with reveal mechanism, on-chain royalties (ERC2981), and admin controls.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Digbi2121 |
| Audited By | Khrystyna Tkachuk |
| Approved By | Kornel Światłowski |
| Website | - |
| Changelog | 21/04/2026 - Preliminary Report |
| 30/04/2026 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Non-fungible Token, ERC721, Token Sales, Centralization |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Digbi2121
- Audited By
- Khrystyna Tkachuk
- Approved By
- Kornel Światłowski
- Website
- -
- Changelog
- 21/04/2026 - Preliminary Report
- 30/04/2026 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Non-fungible Token, ERC721, Token Sales, Centralization
Review Scope | |
|---|---|
| Repository | https://github.com/digbiworld/digbi2121-audit→ |
| Commit | 5dc83f3 |
| Final Commit | 63bf613 |
Review Scope
- Commit
- 5dc83f3
- Final Commit
- 63bf613
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
Functional requirements are provided.
Technical description is provided.
Run instructions are provided.
Technical specification is provided.
The NatSpec documentation is sufficient.
Code quality
The code leverages OpenZeppelin contracts and follows established patterns.
The development environment is configured.
Test coverage
Code coverage of the project is 0%.
Test cases are not provided.
System Overview
DIGBI2121 is a blind-mint NFT collection protocol with the following contract:
Digbi2121 — an ERC-721A NFT contract that implements a fixed-supply, blind-mint drop with a delayed-reveal mechanism, on-chain royalties via ERC-2981, and owner-controlled administrative operations.
It has the following attributes:
Name: DIGBI 2121
Symbol: DIGBI2121
Max supply: 2121 tokens
The contract follows a standard NFT drop lifecycle. After deployment, all tokens display a shared hidden metadata URI. The owner activates the public sale, allowing users to mint at the fixed price (0.06 ETH) up to the per-wallet cap (3 tokens). The owner may also mint tokens for free via a separate function at any time, regardless of sale state or pause, with no per-wallet restriction. Once the collection is ready, the owner calls a one-time reveal function that switches all token URIs from the hidden placeholder to real per-token metadata. The owner may then permanently lock the base URI and the royalty configuration independently, making each immutable.
The owner additionally controls pausing and unpausing public minting, withdrawing collected ETH to an arbitrary recipient, rescuing accidentally sent ERC-20 tokens, and setting a provenance hash as a one-time write to prove metadata integrity, setting royalty recipient and fee (up to 15%).
Privileged roles
The protocol uses OpenZeppelin’s Ownable pattern with a single privileged owner role. The contract owner has the following capabilities:
Can mint up to the full
MAX_SUPPLYthroughownerMint()to arbitrary recipient addresses.Can enable or disable public minting at any time through
setSaleActive().Can pause or unpause the contract, although the pause only disables public
mint()and does not restrictownerMint()or token transfers.Can set the hidden metadata URI through
setHiddenUri().Can reveal the collection metadata through
reveal(), which acts as a one-way switch from hidden metadata to revealed metadata.Can update the base URI through
setBaseUri(), allowing metadata changes until the URI is locked.Can permanently lock the base URI through
lockBaseUri(), making the metadata configuration immutable.Can set the provenance hash through
setProvenance(), which may only be called once.Can update royalty settings through
setRoyalty(), including both the royalty receiver and fee, up to the configured 15% cap, until royalties are locked.Can permanently lock royalty settings through
lockRoyalty(), making the royalty configuration immutable.Can withdraw ETH through
withdraw(), sending the entire contract ETH balance to an arbitrary recipient chosen by the owner.Can withdraw ERC-20 tokens through
withdrawERC20(), transferring any ERC-20 tokens held by the contract to an arbitrary recipient chosen by the owner.
Potential Risks
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.
Single Points of Failure and Control: The project is fully or partially 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.
Uncapped Free Owner Minting: The owner can mint any number of tokens for free via ownerMint() up to the maximum supply of 2121, with no per-wallet limit, no payment requirement, and no restriction by sale state or pause. This function bypasses every constraint applied to public minting. The owner could allocate the entire collection to a single address before or after the public sale, leaving no supply for public participants.
Metadata Mutability Before Lock: The hidden URI can be changed at any time before reveal, and the base URI can be changed at any time before the owner calls the permanent lock. Until the base URI is explicitly locked, the owner retains full control over what metadata each token resolves to.
Royalty Enforcement Off-Chain: The contract implements ERC-2981 to signal royalty information on-chain, but this standard is advisory only. Marketplaces and secondary sale platforms are not required to query or honor the returned royalty data, meaning royalty collection cannot be enforced at the contract level.
Per-Wallet Limit Bypass via Sybil Addresses: The MAX_PER_WALLET limit is enforced using _numberMinted(msg.sender), so it applies as a lifetime mint cap per address and cannot be bypassed by transferring NFTs out. However, this restriction is address-based only and can still be bypassed through the use of multiple Sybil addresses controlled by the same user.
Limited Pause Scope: The contract inherits pausing functionality, but whenNotPaused is only enforced on the public mint() function. While paused, ownerMint() and standard token transfers can still proceed, so the pause does not provide a full emergency stop for token issuance or movement.
Scope Definition and Security Guarantees: The repository includes a flattened contract instance (flat/Digbi2121_flat.sol) that was not included in the audit scope. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts if that flattened version is accidentally used for production deployment.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1622 | Provenance Hash Can Be Set After Minting | fixed | Medium | |
| F-2026-1619 | baseUriLocked Bypass via reveal() Allows Post-Freeze _baseURI Mutation | fixed | Low | |
| F-2026-1622 | Missing Input Validation in Metadata and Provenance Setters | fixed | Observation | |
| F-2026-1621 | Redundant totalMinted() Function Duplicates Existing Functionality | fixed | Observation | |
| F-2026-1621 | Owner Mint Function Bypasses the Per-Wallet Mint Limit | fixed | Observation | |
| F-2026-1619 | 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/digbiworld/digbi2121-audit→ |
| Commit | 5dc83f37361e3674b0ed0e6c81054c92f6532eaf |
| Final Commit | 63bf613c36cb9b4a647ff3a5b1d95451b099eaf2 |
| Whitepaper | - |
| Requirements | https://github.com/digbiworld/digbi2121-audit/PRE_AUDIT→ |
| Technical Requirements | https://github.com/digbiworld/digbi2121-audit/PRE_AUDIT→ |
Scope Details
- Commit
- 5dc83f37361e3674b0ed0e6c81054c92f6532eaf
- Final Commit
- 63bf613c36cb9b4a647ff3a5b1d95451b099eaf2
- Whitepaper
- -
- Technical Requirements
- https://github.com/digbiworld/digbi2121-audit/PRE_AUDIT→
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.
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.