Hivello security record
As of 30 Oct 2026, Hivello has 2 audit reports by 1 security firm on Trustblock; the latest is by QuillAudits, dated 29 Jan 2025. Those reports list no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Audits2
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| Hivello V2 | Security firm: QuillAudits | Date: | Scope: Files named in the report | No open critical findings | Open · quillaudits.com |
| Hivello | Security firm: QuillAudits | Date: | Scope: Files named in the report | No open critical findings | Open · quillaudits.com |
Findings20
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 6 |
| Medium | 0 | 0 | 5 |
| Low | 1 | 0 | 8 |
HighIncorrect Default Pause State in Initialize FunctionHivello V2 · QuillAudits · 29 Jan 2025Fixed
In the process function of InitializeGlobalConfig, the is_paused flag is set to true by default when initializing the global config. This immediately blocks users from claiming rewards after deployment. Setting is_paused = true during initialization causes: Protocol starts in a non-functional state Users cannot claim rewards immediately after deployment
Open the reportHighIncorrect Time Constant Leading to Invalid Days CalculationHivello V2 · QuillAudits · 29 Jan 2025Fixed
The SECONDS_FOR_DAY constant is incorrectly set to 60 seconds instead of the correct value of 86,400 seconds (24 hours * 60 minutes * 60 seconds). This error affects the calculation of days_locked in the staking. The incorrect constant leads to significantly wrong calculations of locked days: Current: Using 60 seconds as one day When user commits for 1 day (86,400 seconds), the calculation results in: 86,400 / 60 = 1,440 days (incorrect) Expected: Using 86,400 seconds as one day 86,400 / 86,400 = 1 day (correct)
Open the reportHighMissing Ownership Validation in Reward Claiming FunctionHivello V2 · QuillAudits · 29 Jan 2025Fixed
The staking contract's reward claiming function lacks ownership validation checks, which allows unauthorized users to claim rewards belonging to other users. When calling the claim_rewards instruction, the contract does not verify if the caller is the actual owner of the UserState account. An attacker can steal staking rewards from any user by: Obtaining victim's UserState account address Executing claim_rewards with their own payer_reward_token_ata but using victim's UserState Successfully transferring victim’s rewards to their account
Open the reportHighPrecision Loss in Tier Requirements CalculationHivello V2 · QuillAudits · 29 Jan 2025Fixed
In the assign_tier function, the calculation order for tier requirements leads to precision loss. The current implementation divides token requirements by TOKENREQUIREMENTPRECISION (1000) be fore multiplication with the multiplier, causing potential rounding to zero. When tier.token_requirements values are less than 1000: Division by TOKENREQUIREMENTPRECISION (1000) first results in 0 Subsequent multiplication with any multiplier yields 0 Function reverts with InvalidAmount error as no tier matches the requirements.
Open the reportHighReversed Pausing Logic in Reward Claims ValidationHivello V2 · QuillAudits · 29 Jan 2025Fixed
The validate_claim_rewards function has incorrectly implemented logic for the pausing mechanism. While the GlobalConfig struct includes an is_paused flag to prevent reward claims, the validation function implements the opposite behavior of what's intended. The reversed logic causes: Users can claim rewards when system is paused (should be blocked) Users are blocked from claiming when system is not paused (should be allowed)
Open the reportHighPotential for Admin to Halt Operations by Closing VaultHivello · QuillAudits · 1 Oct 2024Fixed
In the close_vault function, the admin has the ability to close the vault, which could prematurely halt all staking operations. This creates a significant risk, as the vault is central to managing the staking tiers, total staked tokens, and staker profiles. If the vault is closed while there are still active stakers or unclaimed rewards, it could result in unintended consequences, such as the loss of user funds, halted staking processes, and the inability to unstake or claim rewards. pub fn close_vault(_ctx: Context<CloseVault>) -> Result<()> { let payer = _ctx.accounts.identity.key(); require!(payer != ADMIN_PUBKEY, state::ErrorCode::AdminAccountOnly); Ok(()) }
Open the reportMediumglobal_config.total_staker Not Updating on User Closure.Hivello V2 · QuillAudits · 29 Jan 2025Fixed
The total_staker field in global_config is incremented when a user is initialized but not decremented when a user account is closed. This leads to an incorrect count of active stakers.
Open the reportMediumMissing multiple state updates claiming processHivello V2 · QuillAudits · 29 Jan 2025Fixed
During the staking process ,global_config.total_staked , user_state.stake_time, user_state.to tal_staked_token are updated correctly but when in reward claiming process these fields are not updated, leading to inconsistencies in global_config and user_state accounts.
Open the reportMediumReward Vault is Not Derived from SeedsHivello V2 · QuillAudits · 29 Jan 2025Fixed
The reward_vault account in the handler_add_rewards and handler_claim_rewards instructions and is not verified to be derived from the expected seeds. This allows the function to accept any arbitrary account, which can lead to incorrect reward distribution
Open the reportMediumStake treasury and Reward treasury account creation DOSHivello V2 · QuillAudits · 29 Jan 2025Fixed
The initialization of both stake_treasury and reward_treasury accounts uses the init constraint<br>without checking if the accounts already exist. Since these accounts are PDA-derived token accounts,<br>they can be created in advance by an attacker.<br>An attacker can cause a denial of service by:<br>Calculating the PDA addresses for treasury accounts using known seeds<br>Creating token accounts at these addresses before protocol deployment<br>Preventing the protocol initialization as init will fail if accounts exist
Open the reportShow 9 more
MediumIncorrect Decimal Handling in StakingHivello · QuillAudits · 1 Oct 2024Fixed
In the stake function of the locking contract, the handling of token decimals is currently hardcoded to assume that the tokens being staked have 8 decimal places (token_decimals = 8). This approach introduces a significant flaw, as not all tokens on the Solana blockchain adhere to the same decimal structure. Different tokens can have varying numbers of decimal places, which represent the precision of the smallest divisible unit of the token. For instance, some tokens might have 6 decimals, while others could have 9 or 0. By hardcoding the decimal value, the contract assumes a fixed precision for all tokens, which can lead to miscalculations in staking amounts, rewards, and other related operations
Open the reportLowMissing Check for total_reward > 0Hivello V2 · QuillAudits · 29 Jan 2025Fixed
In the process function of the ClaimRewards implementation, there is no check to ensure that total_reward is greater than zero before executing the reward transfer logic. If total_reward is zero, the _transfer_from_vault function will still be called, leading to unnecessary computations, potential gas costs.
Open the reportLowNo Verification of user_state in stake instructionHivello V2 · QuillAudits · 29 Jan 2025Fixed
In the process function of Stake, there is no explicit check that the provided user_state account belongs to the actual staking user (payer)
Open the reportLowHardcoded Admin Key Prevents Key RotationHivello · QuillAudits · 1 Oct 2024Fixed
In the current implementation of the contract, the administrator's public key (ADMIN_PUBKEY) is hardcoded directly into the contract. This creates a significant limitation in the event that the admin key is lost, compromised, or needs to be rotated for any reason. Because the admin key is statically embedded in the contract, there is no mechanism to update or change it without redeploying the entire contract. This can result in severe operational risks, as losing access to the admin key would leave the contract without a way to perform critical management actions such as updating tiers, modifying parameters, or closing the vault.
Open the reportLowLack of Token Validation in Transfer FunctionHivello · QuillAudits · 1 Oct 2024Fixed
In the transfer_token function, the current implementation does not perform adequate validation to ensure that the correct token type is being transferred. The function is designed to facilitate token transfers between accounts, but without validating that the token involved in the transfer matches the expected token type, there is a risk of unintended consequences. Specifically, any token account could be passed into the transfer function, and tokens other than the intended one could be transferred. The function logs a message indicating the token transfer, but since the token type is not validated, the log message could be misleading, showing that a transfer has occurred without specifying the correct token type. This lack of validation can introduce confusion and undermine the integrity of the contract.
Open the reportLowMagic Numbers in Token CreationHivello · QuillAudits · 1 Oct 2024Fixed
In the create_token function, there are several instances where numeric values, such as space = 82, rent_fee = 1461600, and decimals = 8, are hardcoded directly into the function. These values, often referred to as "magic numbers," are arbitrary constants that provide no context or explanation for their purpose. Hardcoding such values can significantly reduce the readability, flexibility, and maintainability of the code. Future developers or auditors may not easily understand the significance or calculation behind these numbers, making it harder to update or debug the system. For instance, if the rent or space requirements change in the underlying Solana protocol, these hardcoded values would need to be manually adjusted in every occurrence. Additionally, the fixed decimal value might not work for tokens with different decimal precision, creating inconsistency when minting or transferring tokens.
Open the reportLowMissing Event Emissions for Critical Management Actions (e.g., Initialize, Update Tiers)Hivello · QuillAudits · 1 Oct 2024Fixed
In the current implementation of the contract, there are no event emissions for critical management actions such as initialize (vault initialization) and update_tiers (updating the staking tiers). These actions represent important state changes in the contract, particularly for system administrators and auditors who need to track how the protocol evolves over time. The absence of events for these key management functions makes it difficult to monitor changes or create a historical log of important contract activities.
Open the reportLowMissing Tests for Critical Functions and ScenariosHivello · QuillAudits · 1 Oct 2024Fixed
The current implementation of the contract lacks comprehensive unit tests and integration tests for several critical functions, particularly those related to core staking mechanisms, management actions, and edge cases.
Open the reportLowTier Not Cleared After Unstaking All TokensHivello · QuillAudits · 1 Oct 2024Fixed
In the current implementation of the staking system, when a user unstakes all their tokens, the tier information in the staker profile is not cleared. This results in a situation where the user’s staker profile still reflects their highest tier, even though they no longer have any tokens staked. This inconsistency can lead to several problems: it may falsely indicate that the user still qualifies for the highest tier benefits, potentially granting them access to features or rewards they are no longer eligible for. Moreover, since the tier information is not updated or cleared after the tokens are fully unstaked, the system does not accurately reflect the user’s staking status. This creates confusion in the user interface, reporting tools, and any systems that rely on the staker profile data.
Open the reportContracts
No deployed address is recorded for these audits.
The reports name a repository or files. Open a report to see its scope.
Show this on your site
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Content
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
Style
Format
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="hivello"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us