Architecture

Saelis is organized as five logical layers. Each layer depends only on the one beneath it, so that the rules for interpreting Sigils can evolve without changing the chain, and applications can change without changing the rules.

1. ApplicationsExplorers, wallets and developer integrations that present Sigils.

   Proposed
2. IndexingDiscovers records and reconstructs Sigil state deterministically.

   Proposed
3. Saelis RulesVersioning, parsing and validation of protocol records.

   Draft
4. Data TransportHow a Sigil record is published onchain. Not yet decided.

   Open design
5. ElysiumArbitrum Orbit L2 settling to HyperEVM. Ordering, execution, gas in HYPE.

   Live on testnet

#Implementation status

The Saelis repository currently contains this documentation site. It contains no protocol implementation: no smart contracts, no parser, no indexer and no SDK. Everything on this page above the Elysium layer is a design description, not a description of running software.

#Elysium

The base layer is Elysium, an Arbitrum Orbit rollup built by Kinetiq and operated with Conduit. Saelis relies on Elysium for:

• Transaction ordering, through 100 ms canonical blocks and a single sequencer with neutral priority-fee ordering at launch.
• Execution of ordinary EVM transactions, with gas paid in HYPE.
• Data availability, through an AnyTrust data availability committee with full-data posting to HyperEVM as a fallback.
• Settlement, to HyperEVM.

Elysium testnet is live. Mainnet is pre-launch, and its chain ID and public endpoints have not been published. See Elysium Network.

#Data Transport

The transport is the mechanism by which a Sigil record is written onchain. It determines where the bytes live, what they cost and how an indexer discovers them.

A hybrid is also possible, for example calldata for content with an event marker for discovery. The decision will be documented here before any implementation is published.

#Saelis Rules

The rules layer defines what a valid Sigil is and how Sigils are interpreted:

• Versioning. Every envelope declares a protocol version. Indexers apply the rules of that version.
• Parsing. A strict grammar for the envelope, including encoding, required fields and size limits.
• Validation. Envelope-level checks, followed by the rules of any declared standard.

The current rules are a draft. See Data Structure and Validation Rules.

#Indexing

Indexers discover Sigils from chain data, order them canonically, validate them and reconstruct state: individual Sigils, references, assemblies and standard-specific state such as ELC-20 balances. A reference indexer is planned but not implemented. See Indexing & Verification.

#Applications

Applications consume indexed state: explorers that display Sigils and assemblies, wallets that show ELC-20 balances, and developer tools. Applications should treat indexer output as derived data and allow users to verify it against chain history.

#Layer boundaries