Elysium Data Availability: AnyTrust and Batches

Last updated: November 9, 2026

Endpoint and plans: Elysium RPC endpoint.

Terms on this page: Sequencer · JSON-RPC.

At a glance

What you see

You look for Elysium's transaction data on HyperEVM and find small calls to a SequencerInbox instead of the transactions themselves; an indexer that worked on an Ethereum rollup by decoding calldata gets 178 bytes per batch; a search for "Elysium DAS" returns both a data availability server and data APIs; or you need history older than two weeks and wonder where it comes from.

Why this happens

An Arbitrum rollup normally posts its compressed transaction batches to the parent chain, so anyone can reconstruct the chain from parent data alone. AnyTrust changes one thing: a Data Availability Committee stores the batch and signs a certificate, and only the certificate goes to the parent chain. Arbitrum's AnyTrust reference describes the certificate as a hash of the data, an expiration time and proof that enough committee members signed; if the committee cannot produce one, the batcher falls back to posting the full data on chain. On Elysium the parent is HyperEVM. The batcher calls addSequencerL2BatchFromOriginDelayProof (selector 0x69cacded) on the SequencerInbox, and the batch data field is 178 bytes: a 0x88 header byte that marks a DA certificate, the 32-byte keyset hash, the 32-byte data hash, an 8-byte timeout, a version byte, an 8-byte signers mask and a 96-byte BLS signature. The valid keyset registered on the SequencerInbox decodes to one member and one assumed honest, so one signature suffices — Kinetiq's documentation says plainly that at launch AnyTrust on Elysium means the mechanism, not k-of-n committee security, with a multi-member committee to follow. The batch body lives on the data availability server and is retrieved by data hash over its REST interface (GET /get-by-hash/<hash>); a client checks the payload against the posted data hash before trusting it. A batch decompresses to at most the Nitro limit of 16 MiB — the largest seen so far was 16,777,193 bytes — and each message in it becomes one L2 block. Batches are infrequent compared with blocks: on 8 November 2026, batches 300 to 311 were posted over about 4.5 hours, so batch data trails the chain head by minutes. The timeout in every certificate read so far is 15 days after posting: the server is only required to serve data for that long, and the chain itself does not keep the body on HyperEVM.

Where each piece of Elysium data lives

What to do

1. For current data, use RPC on Elysium itself: blocks, receipts, logs and state come from Elysium nodes, not from HyperEVM. Batch data only matters when you need independent reconstruction, raw ordering or history a node will not give you.
2. To enumerate batches, filter eth_getLogs on HyperEVM by the SequencerInbox address and the SequencerBatchDelivered event, in windows the parent RPC accepts (commonly 1,000 blocks). Read each batch transaction's input to get the certificate.
3. Parse the certificate: check the 0x88 header byte, read the data hash and the timeout, and confirm the keyset hash is one the SequencerInbox marks valid. A different header byte means the batch was posted with full data on chain.
4. Fetch the body by data hash from the data availability server, verify it against the data hash before use, then decompress and decode the messages. Each message is one L2 block, and its block number follows from the batch's previous message count.
5. Archive what you need within the certificate's 15-day timeout. After it, the server may stop serving the body and HyperEVM holds only the certificate; there is no second public copy to fall back on.
6. Expect partial pictures from batch data alone: it holds signed user transactions, not execution results. Success or revert, gas used, logs and internal calls still come from receipts and traces on Elysium, and deposits arrive as parent-chain messages.

cast logs --rpc-url "$HYPEREVM_RPC_URL" \
  --address 0x7f3ff53aecb87261206ad3bdc27a88b6d8420fa6 \
  --from-block <FROM> --to-block <FROM+999> \
  'SequencerBatchDelivered(uint256 indexed,bytes32 indexed,bytes32 indexed,bytes32,uint256,(uint64,uint64,uint64,uint64),uint8)'

# data field (178 bytes) inside addSequencerL2BatchFromOriginDelayProof (0x69cacded):
# [0]      0x88            DA certificate header
# [1..33]  keyset hash
# [33..65] data hash       -> GET /get-by-hash/<data hash>
# [65..73] timeout         -> posting time + 15 days so far
# [73]     version
# [74..82] signers mask
# [82..178] BLS signature

When this is not our problem

The data availability server, its retention and the committee are run by Elysium's operators; an RPC provider cannot extend the 15-day window. Triport keeps its own archive of every Elysium batch since genesis and serves it as batch history — batch lists, single batches with decoded transactions, address history and a batch stream — under a separate scope, with coverage stated in every response. See https://triport.io/docs/elysium/das; for chain reads, the keyed URL form is https://triport.io/r/<YOUR_KEY>/elysium.