Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Aeva Info

aevachain.app

An asset-native L1 for programmable ownership, financial rights, and settlement.

Aeva Logo
Onboarded date 30/10/2026

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

72.16
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

Select the audit
Manual Review Static Analysis Dynamic Analysis
Contract address
N/A
Network N/A
License N/A
Compiler go1.26.10
Type Cosmos SDK chain modules (Go)
Language Go
Onboard date 2026/10/30
Revision date 2026/10/30

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Smart Contract Analysis Statement

Contract Analysis

The Aeva rewards and supply area implements the fee burn and the two reward pools that replace inflation on aeva-1 as Cosmos SDK modules written in Go (x/rewards, x/fee), including the split of the staking pool with the lock-period module. In every block the chain burns 60 percent of the AEVA fees of the previous block; a validator pool pays 0.520833 AEVA a block to the fee collector, and a staking pool pays about 0.1667 AEVA a block, 30 percent of it to the lock-period module. Fees are accepted only in AEVA, and the chain halts if the AEVA supply ever rises. This re-audit verified the remediation released in aevad v1.1.4, which runs on aeva-1 since height 2 098 922. All four issues of the first review are fixed: AEVA that the EVM destroys when a contract self-destructs in its creating transaction is now burned through the bank, so the reported supply stays the sum of the balances; a new pool schedule pays its first epoch one epoch after it starts, so a series of schedule proposals releases no faster than one schedule; the unused stablecoin fee switch is removed; and a pool can no longer be its own recipient. The original proofs of concept no longer reproduce, and the supply, the pool balances and the schedules read on aeva-1 at height 2 201 491 match the design.

Ownership Privileges

The ownership of the reward settings has been given to on-chain governance. There is no owner key; in practice any two of the four team validators can pass an expedited proposal in about five minutes. Governance retains full privileges including:

  • Moving the fee burn anywhere between 40 and 80 percent; the bounds are part of the genesis state and change only through a software upgrade.
  • Setting a new schedule or new recipients for either pool, or stopping a pool.
  • Spending the community pool.
  • Shipping a software upgrade, which can change any reward setting or balance; this is the strongest power in this area and matches the documented trust assumptions.
  • A schedule may release at most 25 percent of its pool's balance a year, measured when it is set, and since v1.1.4 it is paid in arrears, so repeated proposals cannot front-load releases.
  • A pool cannot be named as its own recipient, and module accounts that cannot receive funds are refused as recipients.
  • The function that sets recipients without the release limit is reachable only from upgrade code, and the one upgrade that used it cannot be scheduled again.
  • No governance message can mint AEVA or make a pool pay more than its schedule.

Security Features

The contract implements several positive security features:

  • The chain halts if the AEVA supply rises above the previous block's, and every 100 blocks it checks that the supply stays at or below the genesis supply less the fees burned.
  • Only two modules can mint and neither can mint AEVA; since v1.1.4 AEVA destroyed inside the EVM is burned through the bank, so the supply and the balances stay in step.
  • Each pool release is the lesser of the scheduled amount and the pool's balance, it reaches the fee collector after the burn, and shares that cannot be delivered stay in the pool.
  • Fees are paid only in AEVA on every transaction path, and the per-block reward work is fixed in size: two pools with at most eight recipients each.

Note - This Audit report consists of a security analysis of the Aeva Rewards area (the fee burn, the validator and staking reward pools, the fee denomination rule and the supply invariant) as released in aevad v1.1.4 and checked against live state. This analysis did not include economic analysis of the AEVA tokenomics. Moreover, we only audited the rewards and fee modules for the Aeva team; the bridge, the lock periods and the chain-level items are covered by their own reports, and other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.

Files and details

Findings and Audit result

Critical
High
Medium
Low
Optimization
Informational
low Issues | 2 findings

Resolved

#1 low Issue
A contract that self-destructs in its creating transaction destroys aaeva without lowering the bank supply
chain/app/evm.go
L116
Description

The EVM module commits balance changes by overwriting bank balances with UncheckedSetBalance, which does not change the bank supply. Under EIP-6780 a contract that is created and self-destructs in the same transaction, naming itself as beneficiary, has its balance removed and its account deleted. The commit then sets the balance to zero through DeleteAccount and records no burn, so the aaeva disappears from every account while the bank supply still counts it. Contract creation is permissionless on aeva-1 and the init code needed is two bytes (ADDRESS SELFDESTRUCT). The destroyed coins belong to the caller, the supply never rises, so I10 holds and no reward is overpaid. The reported supply does, however, permanently overstate real holdings, and a future sum-of-balances check written as an equality inside the halting invariant runner would let any account stop the chain with one cheap transaction. A test deploys init code 0x30ff with 5 AEVA through MsgEthereumTx; the transaction succeeds, the contract holds nothing, and supply minus the sum of balances grows by exactly 5 AEVA. This extends the disclosed known issue that I10 watches the bank supply and not a sum of balances.

Comments

If the planned sum-of-balances check for I10 is added, assert that the sum of balances is less than or equal to the bank supply and report the gap, never that the two are equal. To remove the gap, burn the destroyed amount through the bank module after each EVM transaction, or carry an upstream fix that makes the account deletion burn the remaining balance through bank. Update that known issue to say that a live, permissionless desync exists and that it only goes downward.

Alleviation

Fixed in v1.1.4: the bank keeper x/vm writes balances through adds up every change of an aaeva balance in a transient store that reverts with the state, after each EVM transaction a hook burns a net decrease through x/rewards and reverts the transaction on a net increase, and the EndBlocker settles what calls outside an EVM transaction left before the supply check runs. In cosmos/evm v0.7.3 every EVM balance write goes through that method and a failed EVM transaction runs the hook on a fresh cache context, and I10 compares with less-or-equal, so the extra burn cannot trip it. The original proof of concept now fails at its assertion that the supply stays above the sum of balances.

Resolved

#2 low Issue
Repeated schedule replacements each pass the annual release bound but pay a whole first epoch at once, so the bound does not limit a year of releases
chain/x/rewards/keeper/keeper.go
L134
Description

SetSchedule, which governance reaches through MsgSetSchedule, accepts a schedule if its annualised release is at most max_annual_release_bps (2 500 on aeva-1) of the pool's balance at that moment, which is exactly what ADR-021, the state specification and the threat analysis define. Nothing ties a new schedule to what earlier schedules already paid. A schedule pays when the blocks since its start are a multiple of its epoch, which is already true at the start height, so its first epoch is paid in full in its first block, and the epoch may be as long as max_epoch_blocks (1 000 000 on aeva-1) with the start at the next block. The largest accepted first payment is therefore one ninety-sixth of the pool, paid at once, about 623 637 AEVA from the validator pool and 207 885 AEVA from the staking pool at height 259 649, and each new proposal re-arms that payment against the remaining balance. Re-setting a schedule with a one-block epoch never beats a single schedule, because the bound shrinks with the balance, but re-setting a front-loaded schedule does. In a test on aeva-1's genesis balances and live bounds, with one proposal per expedited cycle of 176 blocks, 28 proposals, about 2.3 hours, released 25.41 percent of the 60 000 000 AEVA validator pool, more than the bound's whole year of 15 000 000 AEVA, and 440 proposals released 99 percent, while every MsgSetSchedule was accepted and the supply invariant held. The design overstates the effect: the threat analysis lists this bound as the mitigation for draining a pool, the default bounds are described as at most half a pool a year, and the audit's own roles matrix gave the worst case as about 0.62 and 0.21 AEVA a block. Every payment still needs a passed governance proposal that names its recipient, and both live schedules pay every block under the bound. This extends AUDIT-SCOPE section 9 note 13.

Comments

Pay a schedule's epochs in arrears, with the first payment at start_height plus epoch_blocks, or pro-rate a new schedule's first epoch. Better, keep a rolling released amount over blocks_per_year blocks, net of what x/stakelock returns to the staking pool, and accept a new schedule only against the budget that remains. Correct the threat analysis, ADR-021 and the DefaultBounds comment so that they say the bound applies to each schedule against the balance when it is set, not to a year of releases, and until the code changes alert on any schedule proposal whose epoch is longer than one block or whose start height is close to its execution height. The rating is low because governance can already empty the pools, and do much more, through a software upgrade in about five minutes, so this route widens the documented risk without raising its ceiling; like the consensus authority override it needs a governance vote and is not configured today, and unlike that override it cannot be handed to a single key, because x/rewards checks its own authority string.

Alleviation

Fixed in v1.1.4: a schedule starts no earlier than the block it is set in and pays its first epoch one epoch later, so a new schedule releases nothing up front and repeated re-sets release no faster than one schedule; the threat analysis, ADR-021 and the DefaultBounds comment now say the bound applies to each schedule against the balance when it is set. The original proof of concept now releases nothing in a schedule's first block, and a single schedule reaches the annual bound one epoch later than before. The live pool schedules are unchanged.

informational Issues | 2 findings

Resolved

#1 informational Issue
The accept_aeusd switch names a denom that does not exist on aeva-1
chain/x/fee/types/keys.go
L13
Description

The fee module's accept_aeusd parameter is documented as the governance switch for aeUSD fees, but when it is on the code adds only the literal native denom aeusd to the accepted fee denoms (SettlementDenom in keys.go, used by AcceptedDenoms and Accepts in params.go). On aeva-1 aeUSD is the bridged synthetic hyperlane/0x726f...0001 of the usdg-rh route, and the bank holds no aeusd at all. The warp module can only mint hyperlane/ denoms and the erc20 module only erc20: pairs, so aeusd cannot come into existence without a software upgrade. The switch therefore fails safe, and fees stay aaeva-only whichever way it is set, which is what ADR-016 requires on mainnet. A governance proposal that turns it on would pass and change nothing, and the real aeUSD can never be accepted through it.

Comments

State in the audit scope and in ADR-016 that accept_aeusd has no effect on aeva-1. If a stablecoin fee path is wanted later, replace the switch with the conversion hook that ADR-016 section 2 asks for, keyed on the live aeUSD route denom rather than a fixed string; otherwise remove the switch in a later release.

Alleviation

Fixed in v1.1.4: the switch is removed with its field number reserved, fees are paid in aaeva only, and ADR-016 and AUDIT-SCOPE section 4 state that it was inert on aeva-1 and is gone. The live fee params are empty and accept aaeva only.

Resolved

#2 informational Issue
A reward pool can be its own recipient, so its releases move nothing while the released counter grows
chain/x/rewards/types/params.go
L82
Description

ValidateRecipients accepts any valid, unique address that is not blocked, and the two reward pools are deliberately not blocked because they take top-ups. Governance through MsgSetSchedule, and an upgrade handler through SetRecipients, can therefore name a pool as its own recipient. Each release then sends the pool's coins to the pool itself: the bank send subtracts and adds the same amount and succeeds, the balance does not move, and release still adds the full amount to the pool's Released counter and emits a release event with nothing skipped. In a test the validator pool paid itself at the live rate for 100 blocks: its balance stayed exactly the same while Released grew by 52.08 AEVA, and with a split between the stakers and the pool itself the balance fell only by the stakers' half while Released counted both. Nothing on-chain reads Released, no coin moves and nobody gains, so the effect is limited to the counter, the event and the pools query, but the design property that each pool equals what was funded minus what was released no longer holds, the pool never reports itself exhausted, and monitoring that expects the balance to fall by each release is misled. No pool names itself on aeva-1.

Comments

Pass the source pool to ValidateRecipients and refuse that pool's own address in SetSchedule, SetRecipients and InitGenesis. Paying the other pool is a real transfer and can stay allowed. Add a test that every successful release lowers the source pool's balance by the amount it adds to Released.

Alleviation

Fixed in v1.1.4: ValidateRecipients refuses the pool's own address in SetSchedule, SetRecipients and genesis, and the original proof of concept is now refused. The live recipients are unchanged: the stakers for the validator pool, and the stakers and the x/stakelock module account for the staking pool.