Vault Takeover & Reward Exploits Fixed: Securing LifeSol’s DeFi Protocol

LifeSol is a Solana-based staking protocol that combines reward generation with a multi-level referral system and strict vault-based fund management. The protocol is designed to handle staking, reward distribution, and referral payouts while ensuring that all funds are properly accounted for and reserved within the system.

Given the complexity of its reward logic and referral structure, maintaining correctness, security, and reliability is critical. Even small inconsistencies in calculations or access control can lead to significant issues such as incorrect payouts, fund mismanagement, or denial of service scenarios.

From Vulnerabilities to Stability: Securing LifeSol

This Solana Anchor program implements a staking protocol with multi-level referral rewards and strict vault reservation accounting. When a user stakes, the contract calculates staking rewards, up to 10 levels of referral commissions, and a 5% market fee, then ensures the vault has sufficient unreserved balance before proceeding. A unique Stake PDA is derived per user using a nonce, created via CPI, and initialized manually with a discriminator and serialized data.

Tokens are transferred from the user to the vault, the market fee is distributed, and the total reserved amount is tracked in config to prevent over-allocation. Referral rewards are propagated through a verified PDA chain using remaining_accounts, updating each referrer’s accumulated rewards and active referral counts.

Reward claiming is time-proportional: users can claim accrued staking rewards incrementally, claim referral rewards based on structured eligibility thresholds, or withdraw the full stake amount (plus remaining rewards) after the staking period ends.

LifeSol'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 LifeSol 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, etc.
     • 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 LifeSol 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 LifeSol Protocol team to prioritise and address the identified issues.
   • Conducted additional verification testing after vulnerability fixes were implemented.

QuillAudits' Strategic Approach to LifeSol Security Audits

Our approach to auditing LifeSol 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 Huddle01 team throughout the process

Comprehensive Audit Discoveries and Remediation Strategies

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

• Critical Severity Issues (1): These issues pose a severe risk and can lead to immediate fund loss or protocol compromise if exploited.
• Medium Severity Issues (6): These issues pose a moderate risk and should be addressed promptly.
• Informational Issues (9): These findings provide valuable insights and recommendations for improvement.

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

Predictable stake PDA address allows griefing attack via lamport donation and hence preventing genuine users from staking again

Description:

The stake function creates the stake account using system_instruction::create_account via invoke_signed. This instruction requires the target account to have zero lamports and not exist at the time of invocation. Since the stake PDA address is fully deterministic (derived from known public seeds), any attacker can pre-compute it and send a small dust amount (e.g., 1 lamport) to that address before the user's transaction executes.

When create_account is later called on an already-funded address, the Solana runtime rejects it - permanently blocking that nonce's stake PDA.

Initialization can be frontrun, granting attacker full control over pre-funded vault

Description:

The initialize() instruction accepts admin and market as arbitrary instruction parameters with no constraint tying them to the deployer or any trusted signer. The only guard against re-initialization is a check that config.admin != Pubkey::default(), which means whoever calls initialize() first wins:

A malicious actor can submit the transaction with admin and market with their own addresses, and submit with a higher priority fee to land first and hence take our program and hence the vault.

Missing ownership validation in claim_ref_rewards allows anyone to steal referral rewards

Description:

The ClaimRefCtx account struct does not validate that the user_stats account belongs to the user signer. Any arbitrary signer can pass a victim's user_stats account and their own user_token_account to drain the victim's referral rewards.

break used instead of continue in claim_ref_rewards, permanently blocking higher-level reward claims

Description:

In claim_ref_rewards(), the protocol iterates over all 10 referral levels and gates each level's reward behind a minimum active_referrals count requirement.

The break statement exits the entire loop the moment any single level's requirement is not met. This means if a referrer does not satisfy the requirement for level i, all rewards accumulated at levels i+1 through 9 are silently skipped and can never be claimed in that call.

Recommendation:

Predictable stake PDA address allows griefing attack via lamport donation and hence preventing genuine users from staking again

Recommendation:

Replace manual create_account with Anchor's native init constraint on the stake account, which uses allocate + assign + transfer under the hood and handles pre-existing accounts gracefully:

Initialization can be frontrun, granting attacker full control over pre-funded vault

Recommendation:

Remove the admin instruction parameter entirely and derive admin directly from the transaction signer. Since only the deployer will call initialize(), the payer/signer should become the admin by definition:

Alternatively, if a specific admin address must be configurable, hardcode the expected deployer as a program constant and enforce it:

Missing ownership validation in claim_ref_rewards allows anyone to steal referral rewards

Recommendation:

Bind user_stats to the user signer using PDA seeds and add ownership validation on user_token_account:

break used instead of continue in claim_ref_rewards, permanently blocking higher-level reward claims

Recommendation:

Replace break with continue so each level is evaluated independently

Impressed by our findings and recommendations, the LifeSol Protocol developers promptly addressed all identified vulnerabilities.

Through our collaborative efforts, the LifeSol Protocol project is now significantly more secure, ensuring the protection of user funds.

Conclusion

The LifeSol Protocol’s 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 LifeSol Protocol Team has taken a significant step towards securing its platform and safeguarding user trust.