The Hacken 2025 Yearly Security ReportCovers major Web3 breaches, their root causes, prevention insights, and key regulatory trends for 2026.
Learn more

Audit name:

[SCA] Panini America | NFT | Oct2025

Date:

Jan 8, 2026

Table of Content

Introduction
Audit Summary
System Overview
Potential Risks
Findings
Appendix 1. Definitions
Appendix 2. Scope
Appendix 3. Additional Valuables
Disclaimer

Want a comprehensive audit report like this?

Introduction

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

Panini is an on-chain collectibles platform that allows authorised operators to mint NFTs, and users to lock NFTs for bridging, and unlock escrowed tokens via signature-verified requests while enforcing marketplace-whitelisted trades. It also manages royalty funds through a dedicated custody vault that supports controlled withdrawals and Uniswap-based token swaps.

Document

NameSmart Contract Code Review and Security Analysis Report for Panini America
Audited ByPanagiotis Konstantinidis, Ataberk Yavuzer
Approved ByIvan Bondar
Websitehttps://nft.paniniamerica.net
Changelog06/10/2025 - Preliminary Report
28/10/2025 - Remediation Report
08/01/2026 - Final Report
PlatformEVM
LanguageSolidity
TagsNon-fungible Token (NFT), Signatures, ERC721
Methodologyhttps://hackenio.cc/sc_methodology
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Panini America
    Audited By
    Panagiotis Konstantinidis, Ataberk Yavuzer
    Approved By
    Ivan Bondar
    Changelog
    06/10/2025 - Preliminary Report
    28/10/2025 - Remediation Report
    08/01/2026 - Final Report
    Platform
    EVM
    Language
    Solidity
    Tags
    Non-fungible Token (NFT), Signatures, ERC721

Review Scope

Repositoryhttps://github.com/paniniamerica/SmartContracts
Initial commit4b9b35d
Remediation commitf070187
Final commit68c618b
NFT Contract Proxy Addresshttps://etherscan.io/address/0x23ae7a05f598fc234ee9dbef04033080dea8ab19
NFT Contract Contract Implementation Address:https://etherscan.io/address/0x290ae0178314705d95e504ea94ce052fb550b613
Royalty Vault Contract Proxy Address:https://etherscan.io/address/0x2033b17894bd32af9297246827d43d9d67260af3
Royalty Vault Contract Implementation Address:https://etherscan.io/address/0x71cf823dfeb46dc24ed16d91b8b5fcc7387a2c4e

Audit Summary

10Total Findings
9Resolved
1Accepted
0Mitigated

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 clearly outlined within the documentation and NatSpec comments across all contracts.

  • Technical descriptions and intended behaviour are included for core functionalities.

  • Inline comments are consistently used throughout the codebase, improving readability and developer understanding.

Code quality

  • Contract inheritance and modularity are well-structured, allowing separation between NFT logic, access control, validation, and royalty vault functionalities.

  • The implementation uses sufficient input validation, role-based access modifiers, and event logging for traceability.

  • Several template code patterns from OpenZeppelin (Ownable, AccessControl, Pausable, ReentrancyGuard) are implemented.

Test coverage

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

  • Negative cases are partially covered.

  • A comprehensive set of tests validates deployment, minting, role-based access, pausing, burning, approvals, and signature-based operations.

  • The tests execute correctly after uncommenting specific sections as instructed by the development team.

System Overview

The Panini Protocol is an on-chain collectibles and royalty management system designed to enable secure minting, transfer, locking, and unlocking of NFTs through cryptographic validation and managed fund custody. It allows authorized operators to mint NFTs, and users to bridge them across networks by locking or unlocking assets via signatures, enforce marketplace whitelisting for compliant trading, and manage royalty proceeds using a secure, role-based vault.

PaniniNFTs — an upgradeable ERC-721 collection with royalties and strict, role-based controls. It supports operator-gated minting (single or batch), optional burning with burned token ID reuse protection, and signature-based mint/unlock flows that use nonces and expirations for replay resistance. The lock flow escrows tokens to the contract for bridging, while transfers and approvals are filtered through the Panini lock and marketplace whitelisting (SmartValidator) as well as the external transfer-policy hook (CreatorTokenValidator). Managers can also pause/unpause operations and update token URIs when necessary.

SmartValidator — is an access-controlled validation module enforcing marketplace whitelisting and Panini lock logic, ensuring that only approved operators or marketplaces can execute transfers and approvals when the lock is active.

CreatorTokenValidator — is an abstract module for enforcing customizable transfer validation policies, allowing integration with external transfer validators and ensuring compatibility with the LimitBreak creator token standard.

PaniniRoyaltyVault — is a secure upgradeable vault contract that manages both ETH and ERC20 funds, allowing authorized roles to withdraw or swap tokens through Uniswap, while maintaining pausing, access control, and non-reentrancy safeguards.

Privileged roles

Privileged roles of the PaniniNFTs contract:

  • The DEFAULT_ADMIN_ROLE role can grant and revoke all AccessControl roles used by the NFT system, including PANINI_NFT_MANAGER, PANINI_NFT_OPERATOR, and WHITELISTED_MARKETPLACE, thereby controlling the contract’s role-based access system.

  • The PANINI_NFT_MANAGER role can pause and unpause transfers, force-update token metadata via updateTokenURI, and freeze or unfreeze specific user accounts for this NFT collection via the configured external transfer validator.

  • The PANINI_NFT_OPERATOR role can mint and batch mint NFTs to users (subject to the global minting flag), and also acts as the signing authority for the signature-based bridging flows (batchMintOrUnlock and batchLockNFT), since signatures are accepted only if recovered signer holds PANINI_NFT_OPERATOR.

  • The owner can configure royalties, toggle minting and burning permissions globally, and set or change the external transfer validator that enforces the collection’s transfer-policy rules (including account freeze/unfreeze behavior).

Privileged roles of the PaniniRoyaltyVault contract:

  • The DEFAULT_ADMIN_ROLE role can grant and revoke all vault roles (including VAULT_MANAGER, VAULT_PAUSER, and WHITELISTED_RECEIVER) and can update the Uniswap router address via updateUniswapRouter() function.

  • The VAULT_MANAGER role can withdraw ETH and ERC20 tokens to whitelisted receivers and can execute swaps (ETH to ERC20 and ERC20 to ERC20) through the configured Uniswap V3 router.

  • The VAULT_PAUSER role can pause and unpause vault operations, restricting withdrawals and swaps during maintenance or security incidents.

  • The owner can transfer or renounce ownership; additionally, the owner is granted DEFAULT_ADMIN_ROLE during initialization, so the owner is the initial authority for vault role administration unless this is later reconfigured.

Privileged roles of the SmartValidator contract:

  • The WHITELISTED_MARKETPLACE role allows approved marketplace or operator addresses to perform approvals and initiate transfers while the Panini lock mechanism is active, bypassing the default restriction that otherwise permits only token owners to perform these actions.

  • The DEFAULT_ADMIN_ROLE role can enable or disable the Panini lock mechanism globally via setPaniniLock() function, directly affecting whether approvals and transfers are gated by WHITELISTED_MARKETPLACE restrictions.

Privileged roles of the CreatorTokenValidator contract:

  • The owner can set or change the transfer validator contract via setTransferValidator(address), thereby defining (or replacing) the collection’s external transfer-policy enforcement logic that is invoked on transfers and is also used to apply administrative actions such as freezing and unfreezing accounts for the collection.

Potential Risks

Centralized Control of Minting, Trading Permissions, and Funds: Privileged roles (PANINI_NFT_OPERATOR, PANINI_NFT_MANAGER, DEFAULT_ADMIN_ROLE, VAULT_MANAGER) can mint/batch-mint NFTs, pause/unpause transfers via the paniniLock and pauable modules, update metadata, freeze or unfreeze specific accounts for the collection, and withdraw or swap assets from PaniniRoyaltyVault. Compromise or misuse of these keys can censor trading or drain funds.

Misconfiguration or Compromise of Signature Authority: The batchMintOrUnlock() and batchLockNFT() functions rely on an off-chain signer (address holding PANINI_NFT_OPERATOR). If that key is leaked or rotated improperly, attackers could mint/unlock/lock arbitrary tokens bypassing the current checks.

Reliance on External Transfer Validator: The  setTransferValidator() function of the CreatorTokenValidator contract lets the owner point the collection to an external validator. A malicious or faulty validator could block legitimate transfers or silently allow restricted flows, altering collection policy at any time.

Marketplace Whitelisting & Panini Lock Risks: Trading requires either ownership or a whitelisted marketplace (WHITELISTED_MARKETPLACE) while paniniLock is true. Incorrect role assignments or lock toggling can unintentionally halt secondary-market activity or enable unvetted operators.

Custodial Vault & Router Dependency: The PaniniRoyaltyVault contract holds ETH and ERC20 assets and performs swaps through an external router (IUniswapV3Router3). Router bugs, pool manipulation, or slippage can lead to losses, and a compromised VAULT_MANAGER can withdraw tokens arbitrarily.

Absence of On-chain Time-locks for Critical Changes: Immediate execution is possible for actions like granting/revoking roles, toggling paniniLock, freezing/unfreezing accounts, changing royalties, and updating the transfer validator/router. Without a delay, users have no window to react to harmful changes.

Flexibility and Risk in Contract Upgrades: The project’s contracts are upgradeable, allowing authorized administrators to update contract logic to remediate vulnerabilities or implement approved business rule changes. While this provides necessary flexibility for issue resolution and future enhancements, it introduces inherent governance risk if upgrade authority is ever misused or compromised (e.g., key compromise, misconfiguration, or execution outside the intended process), potentially enabling unsafe or unauthorized logic changes. Panini America noted that upgrades are restricted to remediation or formally approved business updates and are subject to strict controls, including an independent re-audit by Hacken, security review and validation of the upgraded logic, and formal approval prior to executing any production upgrade. This governance process materially reduces upgrade-related risk, but the upgrade mechanism remains a privileged capability whose security depends on continued adherence to these controls and secure management of the upgrade authority.

Absence of Upgrade Window Constraints: The contract suite permits upgrades to be executed immediately by authorized administrators, without an on-chain enforced timelock or mandatory waiting period. While this can be beneficial for rapid remediation of critical issues, it also increases the inherent governance risk that malicious or flawed logic could be deployed quickly if upgrade authority is misused or compromised. Panini America noted that upgrades are restricted to remediation of identified vulnerabilities or formally approved business rule changes and are subject to strict governance controls, including an independent re-audit by Hacken covering the proposed changes, security review and validation of the upgraded logic, and formal approval prior to executing any production upgrade. This off-chain governance framework materially reduces the practical likelihood of unsafe rapid upgrades, but because the upgrade mechanism lacks protocol-level delay constraints, system integrity continues to depend on secure management of privileged upgrade keys and consistent adherence to Panini America’s defined approval and audit process.

Insufficient Multi-signature Controls for Critical Functions: Sensitive operations are restricted to the owner account. Panini America clarified that ownership is held by a Safe (multi-signature) wallet, meaning critical actions require confirmation by all or a majority of the Safe’s owners (per the configured threshold). This materially reduces single-key concentration risk and improves operational security compared to an EOA owner model. However, overall safety still depends on maintaining the Safe’s signer set and threshold securely (e.g., preventing signer compromise, ensuring appropriate quorum settings, and applying strong operational procedures for key management and approvals).

Findings

Code
Title
Status
Severity
F-2025-1324Transfer/Approval Bypass and DoS Due To Missing Access Control
fixed

Critical
F-2025-1325Lack of Contract Address in Signed Payload Leads to Cross-Collection Replay Risk
fixed

Medium
F-2025-1327Missing Deadline In UniswapV3 Swaps Allows Delayed Or MEV Exploited Execution
fixed

Low
F-2025-1325Batch Mint Uses mint Instead of safeMint Risking Stuck NFTs on Contract Recipients
fixed

Low
F-2025-1325The isApprovedForAll() Function Reverts on Read for Non-Whitelisted Operators
fixed

Low
F-2025-1325Missing onlyInitializing Guard on Internal Initializer Enables Re-Invocation Outside Init Phase
fixed

Low
F-2025-1325Global Nonce Scope Causes Cross-User and Cross-Flow DoS During Signature Paths
accepted

Low
F-2025-1327NatSpec Inconsistencies and Documentation Issues
fixed

Observation
F-2025-1325Empty try/catch block in _registerTokenType Function Hides Validator Failures
fixed

Observation
F-2025-1325Unused two-parameter _validateTransfer Function Creates Dead Code and Potential Confusion
fixed

Observation
1-10 of 10 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:

Scope Details

Repositoryhttps://github.com/paniniamerica/SmartContracts
Initial commit4b9b35def995b0de48288fe22ed85fd3a934f5c0
Remediation commitf070187a1a8eb96f28f8e9c3b4b7825f233b6a1e
Final commit68c618bf5a5f6a69301819973cb474320043830a
NFT Contract Proxy Addresshttps://etherscan.io/address/0x23ae7a05f598fc234ee9dbef04033080dea8ab19
NFT Contract Contract Implementation Address:https://etherscan.io/address/0x290ae0178314705d95e504ea94ce052fb550b613
Royalty Vault Contract Proxy Address:https://etherscan.io/address/0x2033b17894bd32af9297246827d43d9d67260af3
Royalty Vault Contract Implementation Address:https://etherscan.io/address/0x71cf823dfeb46dc24ed16d91b8b5fcc7387a2c4e
WhitepaperN/A
RequirementsPaniniNftAuditDoc.md, PaniniRoyaltyVaultAuditDoc.md, README.md
Technical RequirementsPaniniNftAuditDoc.md, PaniniRoyaltyVaultAuditDoc.md, README.md

Assets in Scope

contracts
PaniniNfts
limitbreak
CreatorTokenValidator.sol - contracts › PaniniNfts › limitbreak › CreatorTokenValidator.sol
PaniniNFTs.sol - contracts › PaniniNfts › PaniniNFTs.sol
smartlocks
SmartValidator.sol - contracts › PaniniNfts › smartlocks › SmartValidator.sol
PaniniRoyaltyVault
PaniniRoyaltyVault.sol - contracts › PaniniRoyaltyVault › PaniniRoyaltyVault.sol

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.

Disclaimer

Panini America audit by Hacken