Aeva Info
An asset-native L1 for programmable ownership, financial rights, and settlement.
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.
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
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:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- 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 chain area covers the parts of aeva-1, a Cosmos SDK chain written in Go with an EVM, that do not belong to the bridge, staking or rewards areas but still affect live funds, halt safety or upgrade safety: how governance and authorizations dispatch messages, which software-upgrade handlers the binary registers, the binary's dependencies and how releases are built. This re-audit verified the remediation released in aevad v1.1.3 and v1.1.4, live on aeva-1 since heights 1 795 003 and 2 098 922. Governance and authorizations now dispatch through a guarded router that refuses a consensus update handing the modules' authority to a single account and a software-upgrade plan that does not name a newer version, and on aeva-1 the binary registers only aeva-1's own upgrades, so a plan named after a testnet handler can no longer halt the chain. The binary is built with Go 1.26.10 and current gRPC and network libraries, and a reachability scan of the release binary finds no reachable gRPC advisory. Releases are built in a pinned image with a fixed module path, and their checksums are in the upgrade proposals; a rebuild by a validator outside the release team is still pending.
Ownership Privileges
The ownership of the chain has been given to on-chain governance. The four team validators hold over 99.9 percent of the bonded stake, and in practice any two of them can pass an expedited proposal in about five minutes. Governance retains full privileges including:
- Changing the parameters of every module.
- Scheduling a software upgrade, which can change any state; the plan must name a version newer than the newest upgrade the running binary carries.
- Granting authorizations on behalf of the governance account.
- Changing the governance parameters themselves, including the expedited voting period.
- Governance cannot hand the authority over the modules to a single account through a consensus parameter update.
- A plan named after an older or testnet upgrade is refused, so it can no longer halt the chain.
- One team validator alone holds more than a third of the voting power, so the chain stops while it is offline; this concentration is documented and accepted by the team.
- No validator outside the release team has rebuilt a release yet, so validators still rely on the release team's build.
Security Features
The contract implements several positive security features:
- Messages executed by governance or through authorizations pass a guarded router before they run, at any nesting depth.
- Upgrade handlers run on a protocol path that cannot fail on a lock, and on aeva-1 only aeva-1's own handlers are registered.
- Releases are built reproducibly in a pinned image, twice and again in a differently configured container, with the commit, the image digest and both checksums in the upgrade proposal.
- The node links patched versions of Go, gRPC and the network libraries, and the consensus authority is monitored.
Note - This Audit report consists of a security analysis of the Aeva Chain items of aeva-1 (message routing for governance and authorizations, upgrade registration, dependencies and the release build) 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 these chain-level items for the Aeva team; the bridge, staking and rewards areas 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
low Issues | 3 findings
Resolved
#1 low Issue
One governance proposal can hand every SDK and EVM module, software upgrades included, to a single account that governance cannot remove
Cosmos SDK v0.54 lets the consensus params name an authority that overrides each keeper's own, and every SDK module and every cosmos/evm module checks its messages with sdk.ValidateAuthority, which uses that value whenever it is set. On aeva-1 the field is empty (height 259 649), so the gov module account is the authority today. A single governance proposal carrying a consensus MsgUpdateParams with auth.authority set to an address X changes that from the next block. X alone can then schedule software upgrades, change the staking, slashing, distribution, gov, bank, auth, EVM, erc20 and fee-market parameters, spend the community pool and change the consensus params, with no proposal, no vote and no delay. Governance cannot undo it, because its own messages for those modules now fail the authority check and the gov module refuses proposal messages signed by X. Aeva's modules compare the signer with their own authority string and stay with governance, so the chain ends up with two authorities. A test on the app shows the whole sequence: after the override a user account changes the staking params, schedules an upgrade and shortens the expedited voting period, while governance is refused for the same messages and cannot clear the override. It needs the team's validators to pass one proposal and adds no power beyond what a software upgrade already gives them, but it turns a five-minute vote into permanent single-key control that later proposal monitoring would not see. This extends AUDIT-SCOPE section 9 note 13. The severity is read in the same way as for the Safe's rebalance route around the guard: in both cases the key holders can already reach the same outcome through a documented route, because section 9 note 2 of AUDIT-SCOPE says that setting the ISM is equivalent to control of the collateral and governance can already ship any software upgrade, so the undocumented route widens the documented risk without raising its ceiling, which makes this finding low because it needs a governance vote and is not configured today, and that route medium because it adds a route that bypasses the guard even while it is paused and can be delegated to a single key.
Resolved
#2 low Issue
A software-upgrade plan named after a registered testnet handler halts aeva-1 at the next block instead of running the handler
UpgradesFor registers every upgrade handler whose name is at most the binary's version, so the release v1.1.0-locks carries the nine testnet handlers v0.6.1 to v0.14.0 next to v1.1.0. None of those names ever ran on aeva-1, so the upgrade module accepts a governance plan with any of them at any height that is not in the past. The module assumes that the binary running before a plan's height does not carry its handler. When it does, the PreBlocker of every block before the plan height fails with BINARY UPDATED BEFORE TRIGGER on every node, which stops the chain. A proposal fixes its plan height at submission and executes about 300 seconds later, and the handler runs in place only when the plan height is the execution block or the next one, so in practice a passed proposal with a legacy name either fails or halts aeva-1 in the block after it executes. Restarting with the unsafe-skip-upgrades flag does not help because that branch ignores the skip list, a cancel proposal cannot pass on a stopped chain, and no released binary recovers, so a new emergency binary is needed. The handlers themselves are harmless on today's store: run in place on a mainnet-like app with aeva-1's version map, each one only writes the upgrade module's own records. A test schedules plan v0.9.0 for a later height and the next block fails with that error, also with the skip flag set. AUDIT-SCOPE section 9 note 15 says such a plan would run the handler, which is true only inside the two-block window, so this extends note 15.
Resolved
#3 low Issue
aevad v1.1.0-locks links gRPC-Go v1.82.1, whose server is open to an unauthenticated HTTP/2 memory-exhaustion attack (GO-2026-6348)
The release binary links google.golang.org/grpc v1.82.1. Advisory GO-2026-6348 (CVE-2026-84304) describes how an unauthenticated client can open gRPC streams and split the payload into millions of one-byte HTTP/2 DATA frames, each of which carries memory overhead, until the server process runs out of memory and aborts. The affected transport functions are reached in this binary, and aevad start runs the SDK gRPC server by default on localhost:9090, so every aeva-1 node runs the vulnerable code. The SDK's maximum message size does not bound the per-frame overhead. A node whose gRPC port an attacker can reach can be killed without any key: on a public RPC or sentry node this is an outage, on a validator it means missed blocks and downtime jailing, and if validators holding a third or more of the voting power expose the port, block production stops. The team validators hold about 99.6 percent of the consensus power, so the rating would be critical, a chain halt reachable without any key, if their gRPC ports were public. Host configuration was out of scope and was not checked, so the base rating stays low. No funds move and no state is corrupted. The fix is in gRPC-Go 1.83.1. The release that aeva-1 has run since 5 October 2026, v1.1.1, reports the same build dependencies, so it still links gRPC-Go v1.82.1.
informational Issues | 1 findings
Acknowledged
#1 informational Issue
The documented release build is not host-independent: the builder's module-cache path is embedded, so proposal 3's checksums cannot be reproduced on another machine
AUDIT-SCOPE section 6 gives the command that rebuilds the release binaries byte for byte. Run exactly as written with go1.26.5 in workspace mode, it produces different sha256 values on both architectures: amd64 5dcbf23be19042145b21cfd2d4ce5a0a7adb088fe9cb6cc7883b274cdd051c6e instead of proposal 3's fa43e61e609217a6202bf8d71bab4660ffdfc718ac538bb08b3fe85e6afda007, and arm64 3e95243397981b5d65e70629c06d82200dc300e2fb06cb917949321e45459703 instead of 08182a1a725f297abaa8684d9641437e2ac774120ad2b4b9d300cac2f9432f89. The published files at the plan's URLs do match proposal 3. The difference is two source file names in the Go line table: gnark-crypto v0.18.1 includes shared assembly files from another directory, the trimpath flag does not rewrite included files, and so the release builder's absolute module-cache path /Users/idealmac/go/pkg/mod is embedded, which shifts the rest of the line table and changes the build IDs. Code, read-only data, data and the embedded build information are byte-identical, and after substituting the builder's path in a same-length rebuild only the two build-ID notes differ, so the approved binaries are this export's code. The published procedure cannot show that on any other machine, which leaves trust in the upgrade binary resting on the publisher, and the release also discloses the build account name.