Rayls Docs

Axyl Technical Specs

Use this page for the specific details on how Axyl works, its layers, transactions flow, and key contracts.

Consensus Layer

The consensus layer is responsible for ordering transactions and producing a committed sequence of batches. It consists of two components:

Worker. Each validator runs one or more workers. Workers receive transactions from the mempool (WorkerTxPool), build sealed batches, and broadcast them to peer workers. A batch is considered acknowledged once 2f+1 peers have confirmed receipt (where f is the maximum number of tolerated faulty nodes). Once quorum is reached, the batch digest is forwarded to the Primary.

Primary. The Primary is responsible for building and certifying headers. Each header bundles batch digests and parent certificate references into a DAG (Directed Acyclic Graph) structure. A header becomes a Certificate once it collects enough votes from peer primaries. Certificates accumulate round by round in the DAG, and a committed sub-DAG (called a ConsensusOutput) is produced by the Bullshark commit rule.

Middleware Layer

The middleware layer bridges the consensus and execution layers. It consists of two components:

Bridge (Subscriber). The Bridge subscribes to ConsensusOutput events, validates them, fetches any missing batch payloads, deduplicates outputs, and forwards them to the Executor via an in-process channel.

Processor (ExecutorEngine). The Processor polls the channel and executes one ConsensusOutput at a time on a dedicated blocking thread, ensuring strict sequential execution.

An Orchestrator manages the full node lifecycle, including epoch transitions via a state machine (EpochManager), and exposes the rayls_* RPC bridge between the consensus bus and the execution layer.

Execution Layer

Each batch in a committed sub-DAG maps to one EVM block. Block construction is handled by RethEnv::build_block_from_batch_payload, which:

  1. Recovers raw transactions from the batch payload.
  2. Warms the sparse trie in parallel for performance.
  3. Builds a layered state from CanonicalInMemoryState and the on-disk MDBX store.
  4. Executes each transaction via RaylsEvm (revm with a native ERC-20 inspector); invalid transactions are skipped rather than reverted.
  5. Applies EIP-4788 and EIP-2935 pre-execution system calls.
  6. At epoch boundaries, triggers ConsensusRegistry.applyIncentives and concludeEpoch via system call.
  7. Computes the state root using a parallel sparse trie.
  8. Seals the block and inserts it into CanonicalInMemoryState.

Completed blocks are flushed to disk by the PersistenceService and broadcast to RPC consumers via CanonStateNotification.

Transaction flow

A transaction submitted by a client follows this path through the system:

Key invariants

  • Transactions are not executed until the consensus layer has committed them. Any transaction found to be invalid at execution time is skipped with no revert and no fee charge.
  • One ConsensusOutput maps to one EVM block per batch in the sub-DAG, or a single empty block if the output carries no batches.
  • Blocks within the same consensus round are inserted sequentially; each block reads the state produced by the previous block in the same round.
  • Base fees are constant within an epoch and only adjusted at epoch boundaries.
  • Priority fees from batch transactions are credited to the batch author's coinbase address. Block rewards at epoch close are distributed by ConsensusRegistry.applyIncentives via system call.

Epoch model

Axyl organises consensus activity into epochs. Each epoch has a fixed committee of validators. At the boundary of each epoch:

  • The EpochManager drives a transition state machine to rotate the active committee.
  • The ConsensusRegistry system contract applies validator incentives and closes the epoch.
  • An EpochRecord is produced, recording the active and next committee, the last execution block, and the last consensus header of the epoch. This record serves as the trust anchor for light clients and syncing nodes.
  • An EpochCertificate (an aggregate BLS signature from at least ⌊2n/3⌋ + 1 committee members) is generated to prove the EpochRecord is authoritative.
  • The extra_data field of the epoch-boundary block encodes a BLS signature hash used as a randomness seed for the new committee shuffle.

Block header encoding

Rather than introducing new storage tables, Axyl encodes consensus metadata into standard Ethereum block header fields. Standard reth tables remain unmodified.

Storage

Axyl uses two storage engines alongside Ethereum's standard MDBX tables. Consensus DB (redb by default, MDBX optional) stores all DAG and epoch state, including certificates, votes, batch payloads, committed consensus blocks, and epoch records. Execution DB (reth MDBX) stores standard Ethereum execution state: accounts, storage, receipts, and so on. This is managed by reth's built-in persistence layer and is unchanged from standard reth.

RPC interfaces

Standard Ethereum RPC

Every Axyl node exposes the full reth EthApi server over HTTP, WebSocket, and IPC. All standard eth_* methods are available.

Rayls namespace (rayls*)_

Four additional endpoints expose consensus state not covered by the standard Ethereum API.

System contracts

The following contracts are deployed at genesis and driven by EVM system calls at epoch boundaries.


EVM fork configuration

The Axyl chain (chain ID 2017) activates all EVM hard forks at genesis, meaning the full Ethereum feature set is available from block zero with no upgrade boundaries to account for.

The following EIPs are active from genesis and are directly relevant to dapp developers building on Axyl.

  • EIP-1559 (fee market). All transactions use the EIP-1559 fee model. On Axyl, base fees are pegged to USD and collected by the FeeAggregator system contract, which converts them to RLS and distributes them each epoch. This means gas costs are predictable regardless of RLS token price volatility.
  • EIP-1271 (contract signature validation). The isValidSignature standard is supported and already used by contracts deployed at genesis, including the Safe multisig at 0x41675c099f32341bf84bfc5382af534df5c7461a. This is a required building block for smart account implementations, including passkey accounts, where the account contract needs to validate signatures on behalf of an EOA.
  • EIP-2612 (permit). The permit function (EIP-2612) is implemented in the native RLS token and the wrapped RLS contract (0x5c78ebbcfdc8fd432c6d7581f6f8e6b82079f24a), enabling gasless token approvals via signed messages. This is useful for smart account flows where you want to approve and execute in a single transaction.
  • EIP-7212 (secp256r1 / P256 precompile at 0x0000000000000000000000000000000000000100). This enables efficient on-chain verification of WebAuthn and passkey signatures without a Solidity fallback verifier. This is the most critical EIP for passkey smart account work.
  • EIP-7702 (set EOA code). It allows an EOA to temporarily designate contract code, useful for hybrid smart account patterns where you want to upgrade an existing EOA without a full migration.

Updated about 3 hours ago