NfNode Rewards Program - Wayru

1. Introduction

Wayru engaged Halborn to conduct a security assessment on their NfNode Rewards Solana program beginning on January 14th, 2025, and ending on January 16th, 2025. The security assessment was scoped to the Solana Program provided in rewards-system-program GitHub repository. Commit hashes and further details can be found in the Scope section of this report.

The NfNode Rewards Program enables users to claim rewards based on their NfNode operation and ownership. It leverages the Anchor framework to streamline the development of Solana programs. It allows administrators to establish a reward system, fund it with tokens, and manage the reward claiming process. Users, who are NfNode owners or operators, can claim rewards once per day. Each claim requires a partial signature from an administrator, enhancing security. The user claiming the reward is responsible for the transaction fees.

The Wayru team provided an updated version of the NfNode Rewards programa which introduces a new feature that requires users to make a deposit when creating a new NfNode entry. Depending on the NfNode type, the deposit is required at the time of entry creation. For BYOD and WayruHotspot types, the deposit must be made along with the creation of the NfNode entry. For the DON type, no deposit is needed for the owner to claim rewards; however, the deposit is required for the manufacturer or host to be able to claim rewards. Additionally, users must wait a 30-day cooldown period before they can withdraw the deposited amount.

2. Assessment Summary

Halborn was provided 3 days for the engagement and assigned one full-time security engineer to review the security of the Solana Programs in scope. The engineer is a blockchain and smart contract security expert with advanced smart contract hacking skills, and deep knowledge of multiple blockchain protocols. This program allows administrators to establish a reward system, fund it with tokens, and manage the reward claiming process. Users, who are NfNode owners or operators, can claim rewards once per day.

The purpose of the assessment is to:

• Identify potential security issues within the Solana Programs.

• Ensure that smart contract functionality operates as intended.

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were completely addressed by the Wayru team:

• Implement a validation to ensure that the Initialize instruction can only be executed by a known and trusted address, such as the program upgrade authority.

• Add a "owner" field in nfnode_entry to hold the user's address who initializes. Add a check in in update_nfnode and owner_claim_rewards to ensure the user who is signing is the owner of the provided nfnode_entry. Also, add a validation in init_nfnode, update_nfnode and owner_claim_rewardsto ensure the user who is signing is the authority of the user_nft_token_account provided.

• Implementing a two-step authority transfer functionality and add a validation to ensure the new authority candidate is not the current admin.

• Add a check to ensure the reward amount and fund amount is strictly greater than zero.

• Add validations to Verify that the mint's total supply is exactly 1 and its decimal is 0.

  
  

3. Test Approach and Methodology

Halborn performed a combination of a manual review of the source code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the program assessment. While manual testing is recommended to uncover flaws in business logic, processes, and implementation; automated testing techniques help enhance coverage of programs and can quickly identify items that do not follow security best practices.

The following phases and associated tools were used throughout the term of the assessment:

• Research into the architecture, purpose, and use of the platform.

• Manual program source code review to identify business logic issues.

• Mapping out possible attack vectors

• Thorough assessment of safety and usage of critical Rust variables and functions in scope that could lead to arithmetic vulnerabilities.

• Scanning dependencies for known vulnerabilities (

  cargo audit

  ).
  

• Local runtime testing (

  solana-test-framework

  )