Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.novacula.io/llms.txt

Use this file to discover all available pages before exploring further.

Novacula supports eight blockchains today, each implemented as a chain adapter inside @vos/adapter and exposed through the same ChainAdapter interface. This page is the matrix; the per-chain pages cover ports, defaults, and override surfaces in detail.

​
Matrix

ChainNetworksRolesClientsNode typesPer-chain page
Bitcoinmainnet, test, signetnodebitcoindFullBitcoin
BSCmainnet, chapelnodegeth (BSC fork)Full, ArchiveBSC
Ethereummainnet, sepolia, hoodiel + clEL: geth, reth, nethermind, erigon
CL: lighthouse, prysm, lodestar		Full, ArchiveEthereum
Igramainnet, galleon-testnetkaspad + elkaspad · igra-rethFullIgra
Inkink-mainnet, ink-sepoliael + rollupop-geth · op-nodeFullInk
Monadmainnet, testnetconsensus + execution + rpcmonad-bft · monad-execution · monad-rpcFullMonad
Suimainnet, testnetnodesui-nodeFullSui
Tronmainnet, nilenodejava-tronFullTron
Archive node type is supported on Ethereum and BSC only. The remaining chains expose Full only — for archival use cases on those, tune the chain-specific retention / pruning knobs covered on each per-chain page. The exact set of versions a given executor can run is its capabilities blob, declared on every sync. The deploy wizard intersects this matrix with the target executor’s capabilities.

​
Per-network defaults at a glance

The chain adapter ships per-network resource defaults, used by the deploy wizard to pre-fill the resource form. Lowering them surfaces a non-blocking warning.
Chain × networkDefault CPUDefault RAMDefault disk
Bitcoin mainnet2 cores4 GiB600 GiB
Bitcoin test2 cores4 GiB600 GiB
Bitcoin signet1 core2 GiB20 GiB
BSC mainnet4 cores16 GiB500 GiB
BSC chapel4 cores16 GiB500 GiB
Ethereum mainnet4 cores16 GiB2548 GiB
Ethereum sepolia2 cores8 GiB300 GiB
Ethereum hoodi2 cores8 GiB300 GiB
Igra mainnetper adapterper adapterper adapter
Igra galleon-testnetper adapterper adapterper adapter
Ink ink-mainnetper adapterper adapterper adapter
Ink ink-sepoliaper adapterper adapterper adapter
Monad mainnetper adapterper adapterper adapter
Monad testnetper adapterper adapterper adapter
Sui mainnet16 cores128 GiB4000 GiB
Sui testnet8 cores64 GiB3000 GiB
Tron mainnet16 cores32 GiB4000 GiB
Tron nile8 cores16 GiB300 GiB
Numbers above are for Full nodes. Archive (Ethereum, BSC) needs more disk — see the per-chain pages. Defaults for the L2 chains (Igra, Ink) and for Monad are tracked per-adapter; consult the deploy wizard for the live numbers your executor declares.

​
What each chain shares

All chains, regardless of client choice, share these conventions:
  • Outbound from the executor. No inbound ports need exposing for the platform; you may still want to expose RPC for your own use.
  • Single data directory per node. The chain adapter writes config + data under a single mount (Operator: one PVC; Agent: a subdirectory under data_dir). Monad is the one partial exception — triedb lives on its own volume.
  • Init steps are codified. Genesis blob downloads (Sui), JWT secret generation (Ethereum, Igra, Ink), snapshot fetches (Tron, optional), and checkpoint sync URLs (Ethereum CL) are all init-container or init-step logic owned by the adapter, not config you maintain.
  • Override schema. Every adapter declares managedPaths / managedFlags (rejected if you try to override) and knownKeys / knownFlags (typed, described, rendered with hints in the UI). See Edit node configuration.

​
Adding chain support

A new chain is a new entry under packages/adapter/src/<chain>/ implementing ChainAdapter. Once an adapter ships in an executor release, executors running that release declare it in their capabilities, and the deploy wizard exposes it. There is no control-plane-side schema change required; chains are discovered from capabilities at runtime.