We express our gratitude to the Aerobloc team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Aerobloc introduces a decentralized, protocol-based ecosystem tailored for the aviation industry, leveraging blockchain technology to securely share transaction data and implement publicly verifiable logic.
Document
Review Scope
The system users should acknowledge all the risks summed up in the risks section of the report
Functional requirements are limited.
Project overview is detailed.
All roles in the system are described.
Use cases are described and detailed.
For each contract all features are described.
Technical description is limited.
Run instructions are not provided.
Technical specification is provided.
The NatSpec documentation is sufficient.
The development environment is configured.
Solidity Style Guide violations.
A few variable names contain typos: StakingV2::lockUpRewardEnddTime
and StakingV2::lockUpDiscountEnddTime
in the StakerInfo
struct.
Presence of redundant code in certain functions (e.g., else if
used after a previous condition has been validated in the StakingV2::postReward()
as well as an unused input parameter in the StakingV2::notLockedUpReward()
).
Code coverage of the project is 90.95% (branch coverage).
Deployment and basic user interactions are covered by tests.
Negative case coverage is present.
Interactions involving multiple users are tested thoroughly.
Not all branches are covered by tests.
Aerobloc introduces a decentralized, protocol-based ecosystem tailored for the aviation industry, leveraging blockchain technology to securely share transaction data and implement publicly verifiable logic. It fosters collaboration by allowing industry stakeholders to design, test, and launch distributed applications that can be reused by others within the ecosystem. Aerobloc is governed by its community stakeholders, transitioning from an executive team-managed model to a fully decentralized structure. It provides a decentralized ledger for stakeholders to share data, reduce costs, and increase revenue, with incentives for data contribution.
At the heart of the Aerobloc ecosystem is the $AERRO Token, the world's first RWApp token for aviation. The $AERRO is an ERC-20 token that powers the RWApps on Aerobloc, allowing stakeholders to share in the value generated by the ecosystem. The token accrues value primarily through staking mechanisms and fee sharing. Users can stake $AERRO to earn rewards, gain governance privileges, and receive fee rebates, creating an incentive structure that encourages active participation and early adoption.
The files in the scope:
Token.sol: Implements the $AERRO ERC20 token with an initial supply minted to the owner. The contract includes a burning mechanism that reduces the token supply, helping manage inflation and enhance token value. The daoAddress
can trigger the burn functionality, ensuring that supply adjustments are controlled and governed by the DAO.
Dao.sol: The core governance contract of Aerobloc, responsible for managing proposals related to administrative changes, fee splits, and external transfers. It governs the platform through community proposals and voting, involving stakeholders in decision-making processes. It also manages fee distribution, ensuring that collected fees are split between burning, rewarding stakers, and contributing to the DAO treasury.
LandingCharges.sol: Manages landing charges within the Aerobloc ecosystem. This contract allows only admin addresses to create or update charges.
StakingV2.sol: This contract handles the staking of $AERRO tokens. Stakeholders can stake $AERRO tokens to earn rewards that are periodically distributed based on their stake size and duration.
Token.sol:
owner
: The initial supply of $AERRO tokens is minted to the contract deployer, who is also the owner. The owner can update the DAO address.
daoAddress
: Has the privilege to burn tokens, a critical function in managing token supply and value.
Dao.sol:
admins
: Authorized to create and action proposals, manage the list of admins, adjust fee splits, and approve external transfers.
LandingCharges.sol:
onlyAdmins
: Only designated admin addresses can create or update landing charges and manage the DAO address.
StakingV2.sol:
owner
: Can update the DAO address and manage contract ownership.
Centralized Minting to a Single Address: The project concentrates minting tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.
Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.
Solidity Version Compatibility and Cross-Chain Deployment: The project utilizes Solidity version 0.8.20 or higher, which includes the introduction of the PUSH0 (0x5f) opcode. This opcode is currently supported on the Ethereum mainnet but may not be universally supported across other blockchain networks. Consequently, deploying the contract on chains other than the Ethereum mainnet, such as certain Layer 2 (L2) chains or alternative networks, might lead to compatibility issues or execution errors due to the lack of support for the PUSH0 opcode. In scenarios where deployment on various chains is anticipated, selecting an appropriate Ethereum Virtual Machine (EVM) version that is widely supported across these networks is crucial to avoid potential operational disruptions or deployment failures.
Frontrunning During The Initialization Of The Implementation Contract: If the deployment and initialization of the implementation contract (Dao.sol
) are not performed within a single transaction, there is a risk that another entity could frontrun the Dao::initialize()
function.
Token Supply: Anyone can impact the total supply of the token by calling the postFee
function in the DAO contract. This function burns a portion of the tokens based on configurable fee splits.
Dependence on Off-Chain Systems: The functionality and security of system contracts may rely on external off-chain systems or processes that are not covered by this audit. This creates a risk that these off-chain dependencies could fail, be manipulated, or behave unexpectedly, potentially leading to unintended behavior of the system.
Resetting Lock-Up Periods with New Stakes: Each new stake action in the StakingV2 contract resets and extends the lock-up periods for both rewards (30 days) and discounts (7 days). This could inadvertently delay the staker's ability to claim rewards or utilize discounts, even if the lock-up requirements had already been met.
Code ― | Title | Status | Severity | |
---|---|---|---|---|
F-2024-5954 | Sandwich Attack in postReward Function Allows Attacker to Gain Disproportionate Rewards | Fixed | Critical | |
F-2024-6041 | Missing Allowance To The StakingV2 Contract Leads To Denial Of Service | Fixed | High | |
F-2024-5997 | Proposal Duration Miscalculation Leads to Extended Expiry Times | Fixed | Medium | |
F-2024-5951 | Lack of Time Dependency in calcFeeDiscount Function Allows Exploitation for Unfair Fee Discounts | Fixed | Medium | |
F-2024-6011 | Lack of Validation in createNewFeesSplitScheme Can Lead to Denial of Service (DoS) | Fixed | Low | |
F-2024-6009 | Lack of Validation in createNewAdminsScheme Function Allows for Potentially Unmanageable DAO State | Fixed | Low | |
F-2024-6040 | The totalStaked > 0 Condition Prevents Donations To The StakingV2 Contract | Fixed | Low | |
F-2024-6014 | Inadequate Validation in deleteProposal Function | Fixed | Low | |
F-2024-5996 | The Lack of Validation Can Lead To The Reverted Pending Transfers | Fixed | Low | |
F-2024-6032 | Inefficient Reuse of keccak256 Hash Calculations for Proposal Types | Fixed | Observation |
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
Severity
Description
Severity
Description
Severity
Description
The scope of the project includes the following smart contracts from the provided repository:
Scope Details
contracts/Token.sol
contracts/Dao.sol
contracts/LandingCharges.sol
contracts/StakingV2.sol