What is Aevum
Aevum is a decentralized blockchain protocol built around slot-based network operation, epoch-native coordination, cryptographic state commitments and modular execution.
The current protocol is under active development. This documentation describes the current architectural direction and protocol concepts that have been defined or implemented. Features that are still being implemented or specified are explicitly marked as such.
Aevum L1 is currently under active development and testing. Mainnet has not yet launched. Explorer information may use deterministic development data until the live network API becomes available.
Why Aevum
Aevum is designed around predictable coordination, cryptographic verification, long-term security and modular execution rather than a traditional block-centric architecture.
The protocol separates continuous network activity from epoch-level finality. This allows the system to operate through deterministic slots while committing canonical state at epoch boundaries.
Design principle: protocol rules should be deterministic, independently verifiable and explicit about which components are finalized, experimental or still under development.
Architecture Overview
Aevum L1 is organized around three primary protocol abstractions:
- Slots — 30-second units of protocol activity.
- Epochs — 2,880 slots forming a 24-hour coordination period.
- EpochSnapshots — canonical cryptographic commitments finalized at epoch boundaries.
The current L1 design is epoch-native rather than block-height-native. Block height is not the monetary coordination axis of the protocol.
Slots
A slot is the smallest canonical time unit used by the Aevum L1 architecture.
Each slot has a fixed duration of 30 seconds.
Slot-based operation provides a deterministic temporal coordinate for network activity without making block height the primary monetary coordinate.
- Transaction processing
- Presence recording
- State transitions
- Fee accounting
- Scheduled emission
Epochs
An epoch contains exactly 2,880 slots.
At 30 seconds per slot, one epoch represents exactly 24 hours of protocol time.
Epochs provide the boundary at which accumulated
protocol state can be committed into an
EpochSnapshot.
- State commitment
- Presence commitment
- Reward accounting
- Fee accounting
- Emission accounting
- Epoch-level finality
Presence
Presence records participant activity within the protocol's epoch model.
Presence is represented as protocol data that can
be cryptographically committed into the
presence_root of an epoch snapshot.
The current Aevum architecture intentionally distinguishes participant presence from stake ownership. Participants are not represented by a capital-weighted staking model in the simplified L1 design.
Important: presence semantics, participant selection and reward rules remain subject to the canonical protocol implementation and test suite. The website must not invent additional weighting rules that are not present in the protocol.
EpochSnapshot
EpochSnapshot is the canonical L1
finality structure for an epoch.
It commits the important state dimensions of the completed epoch into a single cryptographically verifiable structure.
- State Root — canonical protocol state commitment.
- Presence Root — commitment to epoch presence data.
- Reward Root — commitment to reward accounting.
- Fee Root — commitment to fee accounting.
- Emission Root — commitment to monetary emission accounting.
- Snapshot Hash — cryptographic commitment to the snapshot itself.
Snapshots are linked through the previous snapshot reference, creating a canonical epoch history that can be independently verified.
Consensus
Aevum's current L1 architecture uses an equal-participant model rather than capital-weighted Proof of Stake. It is also not based on traditional Proof of Work mining.
The simplified L1 architecture treats eligible participants as equal protocol participants. Participant selection and consensus behavior are determined by the canonical implementation and consensus rules.
- Deterministic protocol state transitions
- Epoch-native coordination
- Cryptographic state commitments
- Epoch-level finality
Specification status: consensus details are still being validated through implementation and testing. This page intentionally avoids describing unverified staking, capital weighting or governance mechanics.
Finality
Aevum finality is organized around
EpochSnapshot commitments.
Once the canonical snapshot for an epoch has been produced and accepted according to the protocol's consensus rules, the corresponding epoch state is treated as finalized.
The important distinction is that slots provide continuous protocol activity, while the epoch snapshot provides the canonical finality boundary.
Genesis Supply
The Aevum monetary constitution defines a genesis supply of 21,000,000 AEV.
This genesis amount forms the initial supply from which the protocol's subsequent emission budget is defined.
- Genesis supply: 21,000,000 AEV
- Emission budget: 350,000,000 AEV
- Maximum supply: 371,000,000 AEV
Emission
Aevum emission is slot-based. The scheduled emission is determined from the protocol's epoch-based monetary schedule and is bounded by the remaining emission budget.
The initial scheduled emission is 20 AEV per slot.
Monetary invariant: actual emission cannot exceed the remaining emission budget. The maximum supply is therefore bounded by the genesis supply plus the fixed emission budget.
Halvings
The emission schedule changes at fixed epoch intervals.
One halving interval contains 1,461 epochs, equivalent to approximately four years in the protocol's 24-hour epoch model.
- Initial schedule: 20 AEV / slot
- After first halving: 10 AEV / slot
- After second halving: 5 AEV / slot
- After third halving: 2.5 AEV / slot
- After fourth halving: 1.25 AEV / slot, subject to the remaining emission budget.
The emission budget, rather than an infinite continuation of any nominal per-slot rate, is the final monetary constraint. When the remaining emission budget reaches zero, scheduled emission terminates.
Maximum Supply
Aevum defines a maximum supply of 371,000,000 AEV.
Once the emission budget has been exhausted, scheduled monetary emission terminates.
Post-Emission Economy
After the protocol's emission budget is exhausted, network economics are expected to rely primarily on protocol-generated fees and other explicitly implemented economic mechanisms.
Planned economic areas may include:
- Transaction fees
- L2 settlement fees
- Useful-computation services
These mechanisms remain subject to implementation, testing and final economic specification.
Addresses
Aevum addresses are derived from the protocol's canonical cryptographic key and address derivation specification.
The exact address encoding, key derivation and serialization rules must be treated as protocol specifications rather than assumptions made by the website.
Security note: users should only rely on address formats published by the canonical Aevum wallet and protocol implementation.
Transactions
Transactions represent state-changing operations processed during protocol slots.
A transaction may contain fields such as:
- Sender information
- Recipient information
- Amount
- Fee
- Nonce
- Cryptographic authorization
The exact transaction schema is defined by the canonical protocol implementation and may evolve while the network remains under development.
State Roots
A state root is a cryptographic commitment to the canonical state represented by the protocol at a defined point in its state-transition history.
In the epoch model, the state root is one of the
canonical roots committed by an
EpochSnapshot.
- State verification
- Snapshot validation
- Synchronization
- Deterministic state comparison
Wallet Security
Aevum wallet security is being designed around local key ownership and cryptographic primitives selected by the canonical protocol and wallet implementations.
The fundamental security rule is simple: private key material must remain under the user's control.
- Mnemonic material, when used, must never be uploaded to a website server.
- Private keys must never be transmitted to peers or application servers.
- Transaction authorization should occur locally.
- Public addresses may be shared when required.
Wallet specification status: exact mnemonic standard, derivation paths and cryptographic key hierarchy will be documented here only after they are finalized by the protocol and wallet implementation.
Nodes
Aevum nodes maintain protocol state, participate in network communication and execute the canonical state-transition rules.
Depending on the finalized node architecture, responsibilities include:
- Receiving and validating transactions
- Processing protocol slots
- Maintaining state
- Participating in consensus
- Creating and validating epoch commitments
- Serving synchronization data
P2P Network
Aevum uses a peer-to-peer networking layer to distribute protocol data between participants.
The implementation includes networking, peer discovery, synchronization and recovery components.
Privacy-oriented networking components are part of the broader Aevum architecture, but individual protocol mechanisms remain subject to their implementation and security validation.
Synchronization
Synchronization is organized around the canonical epoch history and cryptographically verifiable state commitments.
Epoch snapshots provide deterministic checkpoints from which a node can validate the canonical state before continuing protocol execution.
- Canonical epoch history
- Snapshot verification
- State-root verification
- Deterministic replay
Recovery
Aevum includes recovery-oriented mechanisms for handling node failures, restarts and network interruptions.
The architecture uses cryptographically verifiable state checkpoints and deterministic replay as core recovery primitives.
- Epoch snapshots as recovery points
- State verification
- Peer state exchange
- Deterministic recovery
L2 Overview
Aevum L2 is intended as a modular execution layer operating above L1.
Planned capabilities include:
- High-throughput transaction execution
- Smart-contract execution
- Application-specific workloads
- L1 settlement
L2 specifications remain under active development and should not be treated as mainnet guarantees until the corresponding implementation is finalized.
L2 Transactions
L2 transactions are expected to execute within the L2 environment and ultimately be represented by cryptographically verifiable commitments anchored to L1.
The exact batching, settlement frequency, fee model and proof mechanism are implementation-dependent until the L2 specification is frozen.
Smart Contracts
Smart-contract execution is part of the planned Aevum L2 architecture.
A Rust/WebAssembly execution environment is being considered for contract execution, subject to final VM specification, determinism requirements and security testing.
- Deterministic execution
- Resource accounting
- State isolation
- L1 settlement integration
L1 Finality
The intended architecture is for L2 state commitments to be anchored to Aevum L1.
Once the L2 settlement design is finalized, canonical L2 commitments can inherit the security properties provided by L1 finality.
Status: L2 settlement and finality are under development. Exact commitment formats and settlement cadence will be documented after the specification is frozen.
Ecosystem
Aevum is designed as a foundational protocol for a broader decentralized application ecosystem. The protocol provides the underlying network, security model, identity primitives, settlement, finality and execution infrastructure that compatible applications can build upon.
The Aevum protocol does not depend on any individual application. Ecosystem products may use Aevum infrastructure while remaining independently developed, deployed and operated.
Architecture principle: Aevum is the protocol layer. Applications built on top of Aevum are separate products and are not required for the operation or security of the underlying network.
Protocol → Ecosystem
Planned Ecosystem Applications
The following products represent the current direction of the Aevum ecosystem. They are planned independently from the core protocol and may evolve as development progresses.
Nexa
Nexa is a planned decentralized communication platform designed around Aevum identity and compatible network infrastructure. The long-term architecture may support secure peer-to-peer communication, user-controlled identities and protocol-native services.
Status: Planned. Nexa is not currently part of the Aevum L1 runtime and is not required for network operation.
Nova
Nova is a planned decentralized video and media platform. Its purpose is to provide an independent application layer for publishing, discovering and distributing video content using infrastructure compatible with the Aevum ecosystem.
Status: Planned. Product architecture and protocol integration are subject to future development and testing.
Vault
Vault is a planned decentralized storage platform. The intended architecture is based on encrypted user-controlled data and distributed storage infrastructure rather than a single centralized storage provider.
A future Vault implementation may use Aevum identity, payments, verification and settlement mechanisms while keeping application storage logic separate from the L1 protocol.
Status: Planned. Storage architecture, availability guarantees and protocol integration have not yet been finalized.
Marketplace
A future Aevum marketplace may connect users and providers of digital services and useful computation. Potential use cases include compute resources, storage, bandwidth and other decentralized services.
Status: Conceptual. Exact marketplace mechanics will be defined separately from the Aevum L1 consensus protocol.
Identity Across the Ecosystem
Aevum is intended to provide a protocol-level identity foundation that can be used across compatible ecosystem applications. Wallet ownership and application profiles are conceptually separate: the underlying cryptographic identity belongs to the user, while an application may optionally associate a profile, nickname or other public metadata with that identity.
This separation allows a user to interact with multiple applications without requiring each application to create a separate blockchain identity.
Design direction: wallet identity is intended to remain under user control. Application profiles are optional and should not replace the underlying cryptographic ownership model.
Independent Products, Shared Foundation
The ecosystem follows a simple architectural principle: applications may share Aevum infrastructure without becoming components of the Aevum consensus layer.
- Aevum provides the protocol foundation, settlement and finality.
- Nexa focuses on communication.
- Nova focuses on video and media.
- Vault focuses on decentralized storage.
- Marketplace can connect users with decentralized services and resources.
No ecosystem application is required for the Aevum network to function. The protocol remains an independent foundation on which applications can be built over time.
Development status: Aevum is currently under active protocol development. The ecosystem applications described in this section are planned or conceptual and should not be interpreted as launched products, production services or guaranteed roadmap commitments.
Repository
Aevum source code and public project material are maintained in the project's public repository.
Local Development
Local development instructions will follow the canonical repository configuration.
- Clone the repository.
- Install the required Rust toolchain.
- Install project dependencies.
- Build the workspace.
- Run the relevant test suites.
Important: exact Rust versions, binaries, node commands and network configuration should be taken from the repository's current toolchain and build configuration rather than hard-coded here.
Testing
Aevum development places strong emphasis on deterministic testing and recovery validation.
The test architecture includes:
- Unit tests
- Integration tests
- Crash and recovery tests
- Network simulation
- Cryptographic validation
- State-transition invariants
- Emission and monetary-boundary tests
The simulation environment is designed to make repeated runs deterministic for a given seed, allowing failures to be reproduced and investigated.
Roadmap
Aevum development is focused on protocol correctness, deterministic behavior, security and production readiness before mainnet activation.
- Current: Protocol development, testing and hardening.
- Next: Testnet preparation and public network testing.
- Later: Mainnet preparation following successful protocol validation.
Roadmap policy: dates are targets, not guarantees. Network launch timing depends on protocol stability, security audits, test results and operational readiness.
Aevum Documentation — Development specification. Protocol details may change until the corresponding implementation is frozen and released.