Voice

Voice runs token-based polls on Solana and keeps voter deposits separate from rewards. We reviewed its Anchor program, including Merkle-proof reward claims and how voters get their deposits back once a poll ends.

report id

0998

1 Executive Summary

This document presents the results of the security review conducted by Nethermind Security for Voice protocol's token-based voting system on the Solana blockchain. The primary focus of the engagement has been the vote_system Anchor program and its mechanisms for managing user deposits, off-chain reward commitments, and token validation.

Voice is a polling protocol that isolates user principal from system payout mechanisms by utilizing a two-vault architecture for every poll. Voting requires users to deposit base tokens into a dedicated poll_vault, while a trusted off-chain Rewarder funds a separate poll_reward_vault upon publishing a Merkle root containing the final reward distribution. The program implements a permissionless pull-based model, allowing anyone to execute claim_reward by presenting a valid cryptographic proof against the committed root, while ensuring users can withdraw their original deposits via withdraw_vote based purely on a poll's expiration time.

The audit comprises approximately 2386 lines of Rust code. The audit was performed using (a) manual analysis of the codebase, and (b) automated analysis tools.

Audit assessment
Audit Type	Security Review
Initial Report	Aug 10, 2026
Final Report	Aug 20, 2026
Initial Commit	cde83d8
Final Commit	bfc65bf
Documentation Assessment	High
Test Suite Assessment	High

Total findings: 2
Fixed: 2
Acknowledged: 0
Mitigated: 0
Unresolved: 0

Findings by severity

Critical0
High0
Medium0
Low0
Undetermined0
Informational2
Best Practices0

2 Audited Files

#	File	LoC	Comments	Ratio	Blank	Total
1	`programs/vote-system/src/validate_mint_tests.rs`	257	39	15.2%	29	325
2	`programs/vote-system/src/merkle.rs`	275	78	28.4%	61	414
3	`programs/vote-system/src/lib.rs`	1854	576	31.1%	331	2761
	Total	2386	693	29.0%	421	3500

3 Summary of Issues

#	Finding	Severity	Update
1	Flawed recommit logic can lead to double funding	Info	Fixed
2	Price cliff in poll creation fee allows users to pay less for 1 day Polls	Info	Fixed

4 System Overview

Voice is a token-based voting system deployed on the Solana blockchain and built utilizing the Anchor framework. The protocol enables users to participate in decentralized polls by depositing SPL or Token-2022 tokens into isolated, per-poll vaults. An architectural characteristic of Voice is its hybrid execution model: while voting and fund custody are handled on-chain, reward allocations are computed off-chain by a designated backend service and subsequently pushed on-chain via a Merkle root.

4.1 System Actors

The protocol defines several roles with specific permissions and responsibilities:

Admins: maintain global oversight of the protocol via the SystemCore account. They configure the system's parameters such as claim windows, maximum poll durations, and daily reward budgets. Furthermore, admins hold the authority to disable polls, shorten active poll durations via edit_poll(...), and perform reward root corrections before claims begin.
Rewarder: The Rewarder is a trusted off-chain entity responsible for computing the reward distributions based on poll outcomes. This actor interacts with the chain to publish Merkle roots and fund the reward vaults through the commit_rewards_root(...) function.
Creators: Creators initiate new polls, define their operational timeframe (start and end times), and pay a required creation fee.
Users (Voters): Users interact with active polls by locking tokens in exchange for voting power. They are responsible for retrieving their own deposits once a poll ends and can claim their allocated rewards using Merkle proofs.
Promo Funder: An optional role permitted to distribute promotional rewards directly to users alongside the Admin.

4.2 Poll Creation and Voting Lifecycle

The lifecycle of a poll begins with its initialization and continues through an active voting phase.

Poll Initialization: A creator invokes create_poll(...) to instantiate a new Poll account. This process assesses a dynamic creation fee that is split 15% to the Admin and 85% to the Rewarder, with a 10% discount automatically applied for polls lasting longer than one day.
Vault Segregation: Upon creation, the protocol derives two distinct Program Derived Address (PDA) vaults for the poll. The poll_vault is dedicated exclusively to holding user deposits, while the poll_reward_vault is reserved strictly for payout funds.
Voting Mechanics: Users cast votes by calling make_vote(...), which transfers base tokens from the user's associated token account into the poll_vault. A user's voting choice (variant 1 or 2) is permanently locked upon their first deposit for that poll. However, a user may repeatedly call the function to top-up their voting power before the poll concludes.

4.3 Reward Commitment and Claims

The protocol utilizes a pull-based Merkle tree architecture to distribute rewards.

Reward Commitment: After a poll reaches its end_time, the Rewarder calls commit_rewards_root(...) to publish a Merkle root representing the complete payout set for both voters and the creator. In this same transaction, the Rewarder transfers the total reward amount from their own account into the poll_reward_vault.
Daily Budget Limits: To bound the impact of a compromised Rewarder key, commitments are constrained by a daily_reward_budget tracked inside the SystemCore account.
Permissionless Claims: Users execute claim_reward(...) or claim_creator_reward(...) by providing a valid Merkle proof. The claim validates the proof against the committed root and transfers the tokens from the poll_reward_vault to the recipient's ATA. Claims require no signature from the recipient because the proof binds both the amount and the destination account. Furthermore, the system lacks a global pause mechanism for claims; once claims have started, neither the Admin nor the Rewarder can halt the process or recommit a new root.

4.4 Withdrawals and Account Cleanup

The recovery of deposits and the management of stale state are treated as entirely independent operational paths.

Deposit Withdrawals: The extraction of principal deposits via withdraw_vote(...) is time-gated. As soon as the poll's end_time is reached, a voter can retrieve their tokens from the poll_vault. This mechanism is structurally isolated from the reward state, meaning voters can recover their principal regardless of whether rewards were ever calculated, committed, or claimed.
Reward Sweeping: Rewards must be claimed within a snapshotted claim window. Once the effective_close_deadline passes, any unclaimed funds remaining in the poll_reward_vault can be permissionlessly swept back to the Rewarder via close_reward_vault(...).
State Closure: To reclaim rent, fully settled Vote accounts can be closed after deposits are withdrawn and rewards are either claimed or forfeited. Similarly, an empty poll_vault can be closed permissionlessly after the poll ends, returning the stored rent to the original poll creator.

4.5 Token Validations and Promotional Rewards

Voice employs validation for the tokens it supports and offers a parallel distribution channel for promotional campaigns.

Mint Vetting: During system initialization, the validate_mint(...) function checks the chosen token mint. The protocol rejects mints possessing a freeze_authority, which could otherwise be abused to lock the deposit vaults. For Token2022 mints, the system utilizes an allowlist of extensions, rejecting any features that alter transfer mechanics or allow account pausing.
Promo Mechanism: Independent of the poll reward logic, Admins and Promo Funders can invoke distribute_promo_reward(...) to allocate funds directly to a user's UserProfile account. These tokens are stored in the global system_core_ata and can be retrieved by users at any time using the withdraw_promo(...) function.

5 Risk Rating Methodology

The risk rating methodology used by Nethermind Security follows the principles established by the OWASP Foundation. The severity of each finding is determined by two factors: Likelihood and Impact.

Likelihood measures how likely the finding is to be uncovered and exploited by an attacker. This factor will be one of the following values:

High: the issue is trivial to exploit and has no specific conditions that need to be met;
Medium: the issue is moderately complex and may have some conditions that need to be met;
Low: the issue is very complex and requires very specific conditions to be met.

When defining the likelihood of a finding, other factors are also considered. These can include but are not limited to motive, opportunity, exploit accessibility, ease of discovery, and ease of exploit.

Impact is a measure of the damage that may be caused if an attacker exploits the finding. This factor will be one of the following values:

High: the issue can cause significant damage, such as loss of funds or the protocol entering an unrecoverable state;
Medium: the issue can cause moderate damage, such as impacts that only affect a small group of users or only a particular part of the protocol;
Low: the issue can cause little to no damage, such as bugs that are easily recoverable or cause unexpected interactions that cause minor inconveniences.

When defining the impact of a finding, other factors are also considered. These can include but are not limited to data and state integrity, loss of availability, financial loss, and reputation damage. After defining the likelihood and impact of an issue, the severity is determined according to the table below.

Impact / Likelihood	Low	Medium	High
High	Medium	High	Critical
Medium	Low	Medium	High
Low	Info / Best Practices	Low	Medium
Undetermined	Undetermined	Undetermined	Undetermined

To address issues that do not fit a High, Medium or Low severity, Nethermind Security also uses three more finding severities: Informational, Best Practices, and Undetermined.

Informational findings do not pose any risk to the application, but they carry some information that the audit team intends to pass to the client formally;
Best Practice findings are used when some piece of code does not conform with smart contract development best practices;
Undetermined findings are used when we cannot predict the impact or likelihood of the issue.

6 Issues

6.1 Flawed recommit logic can lead to double funding

File	Fix commit	Type	Status
`src/lib.rs`	—	Info	Fixed

The commit_rewards_root(...) function allows the admin to correct a committed reward root by replacing it and updating the total reward amount. However, if an admin performs a downward correction, the surplus remains in the vault but the rewards_total is lowered. If the admin later performs an upward correction, the required funding is calculated against the lowered rewards_total rather than the actual vault balance. This causes the admin to unnecessarily double-fund the vault for the difference, which will also consume more from the daily_reward_budget and causes a temporary freezing of funds for the rewarder.

pub fn commit_rewards_root(...) -> Result<()> {
    // ...
    let funding = if ctx.accounts.poll.rewards_committed_at == 0 {
        total
    } else {
        // ...
        // @audit-issue The funding is calculated using the tracked variable rather than the actual vault balance.
        total.saturating_sub(ctx.accounts.poll.rewards_total)
    };

    if funding > 0 {
        // @audit This consumes the daily budget based on the flawed funding calculation.
        check_and_consume_daily_reward_budget(&mut ctx.accounts.system_core, now_ts, funding)?;
        // ...
    }
    // ...
}

Recommendation

Consider calculating the required funding delta by checking the actual balance of the reward vault rather than the tracked rewards_total state variable.

6.2 Price cliff in poll creation fee allows users to pay less for 1 day Polls

File	Fix commit	Type	Status
`src/lib.rs`	—	Info	Fixed

The calculate_poll_creation_fee(...) function calculates the fee required to create a new poll based on its duration. A 10% discount is applied to the total base_cost as soon as the duration strictly exceeds 1 day ( 86,400 seconds). This step-function logic breaks the pricing curve. For example, a poll lasting exactly 1 day costs full price, but a poll lasting 1 day and 1 second receives a 10% discount on its entire duration. Users are economically incentivized to slightly extend their 1-day polls to receive the discount, which means that the protocol will get fewer fees.

pub fn calculate_poll_creation_fee(...) -> Result<u64> {
    // ...
    let base_cost = duration_seconds
        .checked_mul(price_per_second)
        .ok_or(VoteError::ArithmeticOverflow)?;
    if duration_seconds <= 86400 {
        return Ok(base_cost);
    }
    // ...
    // @audit-issue The discount is applied to the entire base cost if the duration exceeds 1 day.
    let discount = base_cost
        .checked_div(10) // 0.1
        .ok_or(VoteError::ArithmeticOverflow)?;

    let final_fee = base_cost
        .checked_sub(discount)
        .ok_or(VoteError::ArithmeticOverflow)?;
    Ok(final_fee)
}

Recommendation

Consider applying the discount only to the portion of the duration that exceeds 1 day.

7 Documentation Evaluation

Software documentation refers to the written or visual information that describes the functionality, architecture, design, and implementation of software. It provides a comprehensive overview of the software system and helps users, developers, and stakeholders understand how the software works, how to use it, and how to maintain it. Software documentation can take different forms, such as user manuals, system manuals, technical specifications, requirements documents, design documents, and code comments. Software documentation is critical in software development, enabling effective communication between developers, testers, users, and other stakeholders. It helps to ensure that everyone involved in the development process has a shared understanding of the software system and its functionality. Moreover, software documentation can improve software maintenance by providing a clear and complete understanding of the software system, making it easier for developers to maintain, modify, and update the software over time. Smart contracts can use various types of software documentation. Some of the most common types include:

Technical whitepaper: A technical whitepaper is a comprehensive document describing the smart contract’s design and technical details. It includes information about the purpose of the contract, its architecture, its components, and how they interact with each other;
User manual: A user manual is a document that provides information about how to use the smart contract. It includes step-by-step instructions on how to perform various tasks and explains the different features and functionalities of the contract;
Code documentation: Code documentation is a document that provides details about the code of the smart contract. It includes information about the functions, variables, and classes used in the code, as well as explanations of how they work;
API documentation: API documentation is a document that provides information about the API (Application Programming Interface) of the smart contract. It includes details about the methods, parameters, and responses that can be used to interact with the contract;
Testing documentation: Testing documentation is a document that provides information about how the smart contract was tested. It includes details about the test cases that were used, the results of the tests, and any issues that were identified during testing;
Audit documentation: Audit documentation includes reports, notes, and other materials related to the security audit of the smart contract. This type of documentation is critical in ensuring that the smart contract is secure and free from vulnerabilities.

These types of documentation are essential for smart contract development and maintenance. They help ensure that the contract is properly designed, implemented, and tested, and they provide a reference for developers who need to modify or maintain the contract in the future.

8 Remarks & Test Suite

The Voice team provided a comprehensive overview of the main system components during the kick-off call with a detailed explanation of the intended functionalities along with a written specification for the different modules and roles. Additionally, the team addressed all questions and concerns raised by the Nethermind Security team, providing valuable insights and in depth understanding of the project's technical aspects.

Test suite

180Tests passed

0Failed

The complete test output is in the full report.

General advisory to clients

As auditors, we recommend that any changes or updates made to the audited codebase undergo a re-audit or security review to address potential vulnerabilities or risks introduced by the modifications. By conducting a re-audit or security review of the modified codebase, you can significantly enhance the overall security of your system and reduce the likelihood of exploitation. However, we do not possess the authority or right to impose obligations or restrictions on our clients regarding codebase updates, modifications, or subsequent audits. Accordingly, the decision to seek a re-audit or security review lies solely with you.

Disclaimer

This report is based on the scope of materials and documentation provided by you to Nethermind in order that Nethermind could conduct the security review outlined in 1. Executive Summary and 2. Audited Files. The results set out in this report may not be complete nor inclusive of all vulnerabilities. Nethermind has provided the review and this report on an as-is, where-is, and as-available basis. You agree that your access and/or use, including but not limited to any associated services, products, protocols, platforms, content, and materials, will be at your sole risk. Blockchain technology remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond the programming language, or other programming aspects that could present security risks. This report does not indicate the endorsement of any particular project or team, nor guarantee its security. No third party should rely on this report in any way, including for the purpose of making any decisions to buy or sell a product, service or any other asset. To the fullest extent permitted by law, Nethermind disclaims any liability in connection with this report, its content, and any related services and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement. Nethermind does not warrant, endorse, guarantee, or assume responsibility for any product or service advertised or offered by a third party through the product, any open source or third-party software, code, libraries, materials, or information linked to, called by, referenced by or accessible through the report, its content, and the related services and products, any hyperlinked websites, any websites or mobile applications appearing on any advertising, and Nethermind will not be a party to or in any way be responsible for monitoring any transaction between you and any third-party providers of products or services. As with the purchase or use of a product or service through any medium or in any environment, you should use your best judgment and exercise caution where appropriate. FOR AVOIDANCE OF DOUBT, THE REPORT, ITS CONTENT, ACCESS, AND/OR USAGE THEREOF, INCLUDING ANY ASSOCIATED SERVICES OR MATERIALS, SHALL NOT BE CONSIDERED OR RELIED UPON AS ANY FORM OF FINANCIAL, INVESTMENT, TAX, LEGAL, REGULATORY, OR OTHER ADVICE.