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 | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Amara |
| Audited By | , Panagiotis Konstantinidis |
| Approved By | |
| Website | https://www.amara.exchange/→ |
| Changelog | 23/09/2025 - Preliminary Report |
| 09/10/2025 - Final Report | |
| Platform | EVM |
| Language | Solidity |
| Tags | Staking |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Amara
- Audited By
- , Panagiotis Konstantinidis
- Approved By
- Website
- https://www.amara.exchange/→
- Changelog
- 23/09/2025 - Preliminary Report
- 09/10/2025 - Final Report
- Platform
- EVM
- Language
- Solidity
- Tags
- Staking
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/DioneProtocol/Amara-Staking→ |
| Initial Commit | 6c0507f |
| Remediation Commit | af5ff72 |
Review Scope
- Initial Commit
- 6c0507f
- Remediation Commit
- af5ff72
Audit Summary
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-1306 | Reward Calculation Reverts When Halving Timestamp Is After a Stake’s Lock End Due to Underflow in _calculateReward Function | fixed | High | |
| F-2025-1305 | Principal Haircut Under-Applied Near Expiry Due to Month Flooring | fixed | High | |
| F-2025-1304 | Double Division and Rounding in _calculateEarlyExitPenalty() Zeroes principalHaircut Nullifying the Intended Early-Exit Penalty | fixed | High | |
| F-2025-1314 | Mixed-Unit Calculation of effectivePenaltyRate() Produces Invalid Penalty Rates | fixed | Medium | |
| F-2025-1314 | Overcounted Post-Halving Window in getTotalLockPeriodRewards() function Overstates Projected Rewards | fixed | Medium | |
| F-2025-1308 | Unrestricted Modification of Reward Halving Threshold and Timestamp | fixed | Medium | |
| F-2025-1308 | Incomplete Implementation of Emergency Withdrawal Logic | fixed | Medium | |
| F-2025-1304 | Emergency Token Recovery Function Enables Asset Drain | mitigated | Medium | |
| F-2025-1304 | Staking Tier Updates Alter Active Stake Rewards | fixed | Medium | |
| F-2025-1303 | Missing Reward Validation Can Lead to Blocks Stake Withdrawals | accepted | Medium |
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 | |
|---|---|
| Repository | https://github.com/DioneProtocol/Amara-Staking→ |
| Initial Commit | 6c0507f8d2d48482d5c270564b4ecd3a98e9729d |
| Remediation Commit | af5ff72c2f41b26b69e5ae5afe2655c2af23b4b7 |
| Whitepaper | N/A |
| Requirements | README.md |
| Technical Requirements | README.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
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 haircut | Passed | 10K+ |
Claiming rewards before MIN_CLAIM_INTERVAL should revert | Passed | 10K+ |
Claiming rewards after MIN_CLAIM_INTERVAL should succeed | Passed | 10K+ |
| Contract pause should block stake/claim/withdraw | Passed | 10K+ |
| Max stake count per user must not exceed configured maximum | Passed | 10K+ |
| Inactive tiers should revert on stake | Passed | 10K+ |
| Emergency token recovery restricted to owner | Passed | 10K+ |
| Claim must revert if reward reserve is insufficient | Passed | 10K+ |
Claim at exactly MIN_CLAIM_INTERVAL updates lastClaimTime | Passed | 10K+ |
| Reward halving triggers automatically when threshold crossed | Passed | 10K+ |
Invariant
- Stake and Withdraw must preserve principal minus haircut
Test Result
- Passed
Run Count
- 10K+
Invariant
- Claiming rewards before
MIN_CLAIM_INTERVALshould revert Test Result
- Passed
Run Count
- 10K+
Invariant
- Claiming rewards after
MIN_CLAIM_INTERVALshould 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_INTERVALupdates 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.