This Vape-to-Earn Project Had a Hidden Flaw… We Found It First

Puffpaw operates as a cross-chain token infrastructure built on LayerZero’s Omnichain Fungible Token (OFT) standard, designed to enable seamless token interoperability across multiple blockchain networks. By leveraging smart contracts such as PPOFTAdapter for wrapping existing ERC-20 tokens and MyOFT for native token deployment on destination chains, Puffpaw ensures efficient and unified token movement.

Through LayerZero’s messaging protocol, the system facilitates secure cross-chain transfers, maintaining consistency in token supply and state while enabling scalable, interoperable asset management across diverse blockchain ecosystems.

The Future of Decentralised Health & Behaviour Incentives

Puffpaw envisions expanding its decentralised infrastructure to create a global, data-driven ecosystem for healthier lifestyle habits, starting with nicotine reduction. By combining smart hardware, blockchain technology, and gamified incentives, the platform aims to transform real-world behaviour into verifiable, on-chain activity that rewards positive change.

This vision extends beyond vaping, positioning Puffpaw as a next-generation DePIN network where connected devices generate reliable behavioural data and enable transparent, incentive-driven systems. Through secure on-chain tracking and tokenised rewards, Puffpaw seeks to ensure data integrity, user ownership, and fair participation across its ecosystem.

By bridging physical habits with digital incentives, Puffpaw aims to redefine how blockchain technology can be applied beyond finance—empowering users to improve their health while participating in a scalable, interoperable Web3 ecosystem.

PuffPaw 's Journey Through Our Audit Process

Our audit of Puffpaw uncovered key vulnerabilities that required attention, including a lack of input validation for critical parameters, the use of floating pragma leading to inconsistent compiler behaviour, and reliance on single-step ownership transfer mechanisms.

To address these issues, we implemented strict input validation to prevent misconfiguration during deployment, enforced fixed compiler versions to ensure consistent and predictable builds, and introduced a secure two-step ownership transfer process to eliminate risks associated with accidental ownership loss.

These enhancements significantly strengthened Puffpaw’s security posture, improving contract reliability, deployment safety, and overall protocol trust.

PuffPaw's Journey Through Our Audit Process

Our comprehensive audit was executed through the following steps:

1. Information Gathering
   • Collected and reviewed all relevant documentation, including whitepapers, technical specifications, and design documents.
   • Obtained a clear understanding of the Puffpaw platform's functionality and intended user interactions.
   • Discussed client concerns and specific areas of focus for the audit.
2. Manual Code Review:
   • Conducted a line-by-line review of the smart contract code, focusing on:
     • Vulnerability identification: Searching for known vulnerabilities like reentrancy, front-running, integer overflows, and access control issues.
     • Logic flaws: Identifying inconsistencies or unintended behaviours in the code logic.
     • Solidity best practices: Compliance with secure coding standards and adherence to established guidelines.
3. Functional Testing:
   • Developed and executed a comprehensive set of test cases covering various user interactions and edge cases.
   • Leveraged tools like Hardhat and Ganache to deploy and test the smart contract locally.
4. Automated Testing:
   • Employed static analysis tools like QuillShield to identify vulnerabilities through automated code scanning.
   • Utilised symbolic execution tools like Mythril to explore various code execution paths and uncover potential attack vectors.
   • Integrated unit tests are written by the Puffpaw team to verify specific contract functions and their behaviour.
5. Reporting & Remediation:
   • Prepared a detailed report outlining all identified vulnerabilities, categorised by severity and potential impact.
   • Provided clear recommendations for fixing each vulnerability, including code snippets and best practices.
   • Collaborated with the Puffpaw Protocol team to prioritise and address the identified issues.
   • Conducted additional verification testing after vulnerability fixes were implemented.

QuillAudits' Strategic Approach to PuffPaw Security Audits

Our approach to auditing PuffPaw involved a combination of threat modelling, a security-first mindset, and extensive testing. We used both white-box and black-box testing methods to ensure a thorough assessment, maintaining transparency and clear communication with the Puffpaw team throughout the process.

Comprehensive Audit Discoveries and Remediation Strategies

Our comprehensive audit of these contracts revealed a total of 3 issues, categorised by severity:

• Informational Issues (3): These findings provide valuable insights and recommendations for improvement.

Here is a breakdown of the critical vulnerabilities in audit discoveries and remediation strategies:

Audit Discoveries

1. Lack of Input Validation

Description: The constructors of the MyOFT and PPOFTAdapter contracts do not verify whether critical input addresses are non-zero.

In MyOFT, the _lzEndpoint and _delegate addresses are passed directly to the OFT and Ownable constructors without explicit zero-address validation.

Similarly, in PPOFTAdapter, the _token, _lzEndpoint, and _delegate addresses are not validated before being forwarded to the OFTAdapter and Ownable constructors.

While some LayerZero base contracts may perform internal checks, relying on upstream validation reduces clarity and increases the risk of misconfiguration during deployment. Initialising any of these addresses to address(0) could result in loss of ownership, broken cross-chain functionality, or a non-functional adapter.

2. Floating Pragma

Description: Floating pragmas allow the contract to be compiled with multiple compiler versions. This can lead to unexpected behaviour, as different compiler versions may introduce breaking changes, bug fixes, or different optimisations.

Impact: Low

Using a floating pragma can result in:

• Inconsistent bytecode across deployments
• Potential incompatibility with future compiler versions
• Increased risk during audits and production deployments

Likelihood: Low

1. Use Two-Step Ownership Transfer Instead of Standard Ownable

Description: Both contracts inherit from OpenZeppelin's Ownable contract which implements a single-step ownership transfer mechanism. This design pattern is dangerous because if the owner accidentally transfers ownership to an incorrect address (due to a typo, wrong address copied, or any other human error), the contract becomes permanently inaccessible. There is no way to recover from this mistake, and all owner-restricted functions become permanently locked.

Impact: If ownership is transferred to an incorrect address (typo, wrong network address, non-existent address, or address without private key access), all admin functions become permanently inaccessible

Likelihood: Low

Remediation Strategies

1. Lack of Input Validation: Add explicit zero-address validation for all critical constructor parameters before passing them to parent constructors.
2. Floating Pragma: ****Use a fixed Solidity compiler version instead of a floating pragma.

3.Use Two-Step Ownership Transfer Instead of Standard Ownable

Implement Two-Step Ownership Transfer using OpenZeppelin's Ownable2Step contract instead of Ownable

Conclusion:

The PuffPaw smart contracts security audit identified and addressed critical vulnerabilities, protecting user funds and ensuring platform stability. This case study demonstrates the importance of proactive security measures for blockchain-based projects, especially those dealing with financial assets. By conducting audits and addressing identified issues, the PuffPaw Team has taken a significant step towards securing its platform and safeguarding user trust.