The Hacken 2025 TRUST ReportKey findings on trust, security maturity, and the factors driving blockchain adoption.
Learn more

Audit name:

[SCA] Amara | Staking | Sep2025

Date:

Oct 9, 2025

Table of Content

Introduction
Audit Summary
System Overview
Potential Risks
Findings
Appendix 1. Definitions
Appendix 2. Scope
Appendix 3. Additional Valuables
Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Amara team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

AmaraStaking is a groundbreaking solution contract for the Amara token that offers fixed-APY reward tiers over predefined lock periods and applies a calibrated clawback to neutralize early exits. It uses epoch-aware accounting with a halving threshold to adjust rewards over time, supporting periodic claims and full withdrawals at lock expiry.

Document

NameSmart Contract Code Review and Security Analysis Report for Amara
Audited By, Panagiotis Konstantinidis
Approved By
Websitehttps://www.amara.exchange/
Changelog23/09/2025 - Preliminary Report
09/10/2025 - Final Report
PlatformEVM
LanguageSolidity
TagsStaking
Methodologyhttps://hackenio.cc/sc_methodology

Review Scope

Repositoryhttps://github.com/DioneProtocol/Amara-Staking
Initial Commit6c0507f
Remediation Commitaf5ff72

Audit Summary

15Total Findings
13Resolved
1Accepted
1Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}

Documentation quality

  • Project overview is clear and well-structured. Core logic is explained with examples and tables.

  • Run and deployment instructions are included.

  • Technical specification is covered.

  • Roles and access control are not explicitly documented.

Code quality

  • Development environment and scripts are well set up.

  • Code follows solidity best practices.

  • NatSpec is sufficient within the codebase.

Test coverage

Code coverage of the project is 52.27% (branch coverage).

  • Test cases cover the main functional logic and core flows.

  • A gas usage preview is included to provide an overview of method costs during execution.

System Overview

The AmaraStaking contract is a staking protocol built for the Amara token ecosystem. It enables users to lock their Amara tokens for fixed periods in exchange for rewards calculated at specific APY rates. Rewards are distributed over time and may be claimed periodically, subject to minimum claim intervals.

The system introduces a clawback mechanism designed to penalize early withdrawals. If a user exits before the lock period ends, both accrued rewards and a portion of the staked principal are subject to penalties. This ensures that short-term exits do not provide an advantage over longer-term commitments.

To preserve reward sustainability, the contract implements an epoch-aware halving mechanism. Once a specified reward distribution threshold is reached, APY rates for future rewards are automatically halved. The system splits calculations into pre-halving and post-halving segments to ensure fair allocation for all stakers.

The protocol also supports tier-based staking: each lock period (e.g., 2, 3, 6, 12, or 24 months) defines its own APY level and associated benefits. These tiers can be configured and updated by the contract owner, allowing flexibility in shaping staking incentives.

In addition, the contract provides functionality for:

  • Tracking user stakes with unique IDs, including amount, lock period, and claim history.

  • Claiming rewards periodically, provided sufficient reserve is available.

  • Withdrawing staked tokens with or without penalties, depending on lock expiry.

  • Administrative controls such as updating reward halving thresholds, modifying tier configurations, setting emergency withdrawal fees, pausing/unpausing operations, and recovering tokens mistakenly sent to the contract.

Overall, AmaraStaking enforces a structured reward system that balances long-term incentives with mechanisms to protect against abuse, while allowing controlled adaptability through owner-governed parameters.

Privileged roles

The owner of the AmaraStaking contract holds full administrative authority over the protocol. This account is the only role permitted to perform sensitive operations, including:

  • Updating staking tier configurations (APY, descriptions, and active status).

  • Adjusting the reward halving threshold or manually triggering halving events.

  • Setting the emergency withdrawal fee applied to early withdrawals.

  • Pausing or unpausing the contract, thereby enabling or disabling all core user operations.

  • Recovering any ERC-20 token from the contract.

Potential Risks

Owner’s Unrestricted Fund Control: The owner can call emergencyRecoverTokens() to withdraw any ERC20 tokens from the contract, including reward reserves. This centralizes control of all funds in a single key and creates the risk of user funds being rendered inaccessible.

Owner-Defined Economics: The owner can arbitrarily change APYs, staking tier configurations, reward halving thresholds, and emergency withdrawal fees. This introduces risks of sudden changes in expected yields or economic conditions for stakers.

Absence of Time-lock Mechanisms: Critical operations such as halving triggers, APY changes, and fund recoveries can be executed instantly without a delay or review buffer, allowing harmful changes to take effect immediately.

Lack of Multi-signature Controls: All privileged operations are executed solely by the owner, creating a single point of failure if the private key is compromised or misused.

Single Points of Failure: The system is heavily centralized around the owner account. If the owner is compromised, malicious, or becomes inactive, the staking protocol could suffer permanent loss of funds or operational deadlock.

Reward Funding Dependency: Rewards are not self-sustaining and must be manually funded by the owner. If insufficient rewards are supplied, users may be unable to claim their staking returns, undermining trust in the protocol.

Owner-Controlled Governance: The owner unilaterally governs all aspects of the staking system, including fund movements, pause functionality, and reward logic, leaving no role for decentralized community participation or checks and balances.

Inability to Exit in Low-Reserve Scenarios: Since rewards are paid directly from the contract balance, if insufficient tokens are available (due to withdrawal by the owner or poor funding), users may be unable to exit or receive their full reward entitlement.

Early Exit Haircut Risks: The clawback system applies both reward penalties and principal haircuts. If misconfigured by the owner, these could become excessively punitive, discouraging participation or unfairly punishing users.

Findings

Code
Title
Status
Severity
F-2025-1306Reward Calculation Reverts When Halving Timestamp Is After a Stake’s Lock End Due to Underflow in _calculateReward Function
fixed

High
F-2025-1305Principal Haircut Under-Applied Near Expiry Due to Month Flooring
fixed

High
F-2025-1304Double Division and Rounding in _calculateEarlyExitPenalty() Zeroes principalHaircut Nullifying the Intended Early-Exit Penalty
fixed

High
F-2025-1314Mixed-Unit Calculation of effectivePenaltyRate() Produces Invalid Penalty Rates
fixed

Medium
F-2025-1314Overcounted Post-Halving Window in getTotalLockPeriodRewards() function Overstates Projected Rewards
fixed

Medium
F-2025-1308Unrestricted Modification of Reward Halving Threshold and Timestamp
fixed

Medium
F-2025-1308Incomplete Implementation of Emergency Withdrawal Logic
fixed

Medium
F-2025-1304Emergency Token Recovery Function Enables Asset Drain
mitigated

Medium
F-2025-1304Staking Tier Updates Alter Active Stake Rewards
fixed

Medium
F-2025-1303Missing Reward Validation Can Lead to Blocks Stake Withdrawals
accepted

Medium
1-10 of 15 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.

Reference on how risk scoring is done is available through the repository in our Github organization:

Severity

Description

Critical
Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

High
High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

Medium
Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

Low
Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
  • Severity

    Critical

    Description

    Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.

    Severity

    High

    Description

    High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.

    Severity

    Medium

    Description

    Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.

    Severity

    Low

    Description

    Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/DioneProtocol/Amara-Staking
Initial Commit6c0507f8d2d48482d5c270564b4ecd3a98e9729d
Remediation Commitaf5ff72c2f41b26b69e5ae5afe2655c2af23b4b7
WhitepaperN/A
RequirementsREADME.md
Technical RequirementsREADME.md, CLAWBACK_SYSTEM.md
  • Scope Details

    Initial Commit
    6c0507f8d2d48482d5c270564b4ecd3a98e9729d
    Remediation Commit
    af5ff72c2f41b26b69e5ae5afe2655c2af23b4b7
    Whitepaper
    N/A
    Requirements
    README.md
    Technical Requirements
    README.md, CLAWBACK_SYSTEM.md

Assets in Scope

AmaraStaking.sol - AmaraStaking.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Amara staking, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry’s built-in fuzzing was employed to check how the protocol behaves under a wide range of randomized inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 10 invariants were tested over 10,000 runs each. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

Stake and Withdraw must preserve principal minus haircutPassed10K+
Claiming rewards before MIN_CLAIM_INTERVAL should revertPassed10K+
Claiming rewards after MIN_CLAIM_INTERVAL should succeedPassed10K+
Contract pause should block stake/claim/withdrawPassed10K+
Max stake count per user must not exceed configured maximumPassed10K+
Inactive tiers should revert on stakePassed10K+
Emergency token recovery restricted to ownerPassed10K+
Claim must revert if reward reserve is insufficientPassed10K+
Claim at exactly MIN_CLAIM_INTERVAL updates lastClaimTimePassed10K+
Reward halving triggers automatically when threshold crossedPassed10K+
  • Invariant

    Stake and Withdraw must preserve principal minus haircut

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Claiming rewards before MIN_CLAIM_INTERVAL should revert

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Claiming rewards after MIN_CLAIM_INTERVAL should succeed

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Contract pause should block stake/claim/withdraw

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Max stake count per user must not exceed configured maximum

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Inactive tiers should revert on stake

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Emergency token recovery restricted to owner

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Claim must revert if reward reserve is insufficient

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Claim at exactly MIN_CLAIM_INTERVAL updates lastClaimTime

    Test Result

    Passed

    Run Count

    10K+

    Invariant

    Reward halving triggers automatically when threshold crossed

    Test Result

    Passed

    Run Count

    10K+

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Disclaimer