Production-oriented ElectrumX infrastructure for Ravencoin with verified Ravencoin Core 4.8.0, Fast Verified Bootstrap, signed transactional updates, optional node monitoring, Network Observer tooling, and maintained Linux amd64 / ARM64 deployment paths.
Current release: ElectrumX-RVN 1.13.13
Install · Fork features · What's new · Architecture · Security · Network Observer · Documentation · Latest release
Download the published installer first, then run the local file:
curl --fail --location --remote-name \
https://github.com/ALENOC/electrumx-ravencoin/releases/latest/download/electrumx-ravencoin-install.py
python3 electrumx-ravencoin-install.pyThe guided installer lets you choose storage, bootstrap method, and optional
monitoring. Do not use curl ... | python3 or curl ... | bash: keeping
the installer on disk makes the initial executable inspectable before it runs.
To verify the host and signed release metadata without making a persistent installation:
python3 electrumx-ravencoin-install.py --check-onlyThe guided installer defaults to:
- official
RavenProject/RavencoinCore 4.8.0; - ChainStrap Fast Verified Bootstrap;
- a mandatory full local Core validation/reindex;
- Ravencoin Node Monitor enabled;
- the privileged bandwidth/connection controller disabled unless requested;
- explicit storage selection;
- deterministic Compose project name
electrumx-ravencoin.
Ravencoin Core validates the blockchain, but lightweight wallets need efficient address-history and asset queries. ElectrumX builds that query index from the chain already validated by Core and serves wallet requests without holding wallet private keys or signing transactions.
More independently operated Electrum servers improve availability, privacy, infrastructure decentralization, and network resilience.
The maintained fork adds a production deployment and security layer around the historical ElectrumX-Ravencoin server: exact official Core identity and certification, Fast Verified Bootstrap, a signed standalone installer, revision-aware releases, host-wide anti-rollback, transactional updates and rollback, database consistency hardening, maintained amd64/ARM64 deployment, optional local monitoring, Ravencoin Network Observer, and a tested governance and succession framework.
The permanent feature map explains each subsystem, its trust boundary, and what it deliberately does not claim to prove. See Fork feature guide.
Since 1.13.1, the project has added revision-aware signed releases, host-wide anti-rollback state, transactional update/rollback, hardened ChainStrap staging, and explicit migration of legacy persistent state.
Release 1.13.13 makes 1.13.12 startable: 1.13.12 crash-looped because a cache-measurement loop read chain state before the databases had published it. Deploy 1.13.13, not 1.13.12.
Release 1.13.12 was a correctness release: the server no longer serves a
damaged header record, repairs one from the daemon when it can, scans the whole
header store at startup and through electrumx_rpc verifyheaders, and fails
the read rather than returning zeros a client cannot tell apart from real
headers. A single damaged record previously stalled every wallet that reached
its height, silently.
Release 1.13.11 introduced the optional Ravencoin Network Observer: Chain Quorum 2.0, signed multi-vantage observations, operator-aware diversity, active asset capability probes, and height-bound Asset Data Quorum. A tested N-of-M governance/succession framework is included but production threshold governance is not activated; the project is founder-independence capable, not founder-independent.
See 1.13.13 overview for the technical changes and compatibility guarantees.
The normal data and trust path is:
Wallet / Electrum client
|
v
ElectrumX-RVN 1.13.13
|
v
Ravencoin Core 4.8.0
RavenProject/Ravencoin
|
v
Ravencoin peer-to-peer network
The bundled deployment is pinned to the official Ravencoin repository:
repository : RavenProject/Ravencoin
tag : v4.8.0
version : 4.8.0
commit : 22549129888d02e0e08fcdb9f96f3c699167e774
A daemon version string alone is not treated as sufficient proof of backend identity. The deployment and validation paths bind the expected official Core source/release identity explicitly.
See Core certification and Validation status for the detailed evidence.
Fresh installations use ChainStrap Fast Verified
Bootstrap by default. ChainStrap accelerates acquisition of historical raw
block data; it is not a consensus trust source and it does not replace Core
validation. Only verified raw block files may enter staging; downloaded
chainstate and indexes are never installed. The pinned Core performs a complete
local -reindex -assumevalid=0 and an offline post-reindex chain/index gate
before ElectrumX starts. Failures remain fail-closed rather than silently
switching to P2P synchronization.
See Fast bootstrap for the archive rules, resume behavior, storage needs, P2P alternative, and complete threat model.
Running python3 electrumx-ravencoin-install.py starts the guided installer.
It supports explicit storage selection, traditional P2P bootstrap, optional
local monitoring, and an opt-in privileged controller. Persistent Core and
ElectrumX data should live on SSD or NVMe; a fresh install never silently adopts
an existing storage root.
The signed installer is the recommended production entry point. Source-checkout
deployments remain supported for development and deliberate operator workflows,
but setup.sh does not create signed-release updater state and the retired
tracked update key cannot become an active production root.
See Getting started, Storage selection, and Troubleshooting for the commands, storage model, and source-checkout trust behavior.
The maintained deployment targets 64-bit Linux on amd64 and ARM64. Raspberry Pi 5 is the physically qualified low-power ARM64 path for v1.13.11; Orange Pi 5-class systems use the supported ARM64 build path but do not inherit that complete physical qualification. Use SSD/NVMe, active cooling on SBCs, and avoid placing Docker or databases on microSD. See Hardware, Storage selection, and Validation status.
The installer can deploy the optional Ravencoin Node Monitor. It is separate from the ElectrumX peer/network monitoring logic in this repository.
The default dashboard is published only on 127.0.0.1:8899. The optional
bandwidth/connection controller is a separate privileged component and remains
disabled unless explicitly requested.
Updates are explicit and operator-driven. Availability of a newer release does not imply silent installation.
For installations made by the signed release installer, normal maintenance uses:
electrumx-update check
electrumx-update status
electrumx-update show
electrumx-update applyThe updater authenticates the candidate, proves the existing storage model, switches the release transactionally, runs health gates, and then either promotes the candidate or restores the previous release exactly. It refuses to start an ambiguous stack if exact rollback cannot be proven.
Existing blockchain and ElectrumX storage are preserved. Compose overlays
selected through COMPOSE_FILE are preserved across promotion and rollback.
ChainStrap is a fresh-install bootstrap and is not re-run by an ordinary update.
A 1.13.1 node cannot directly authenticate the manifest-v2/current-key release
line. The replacement public key must first be authenticated out of band. A
historical setup.sh 1.13.1 deployment then uses the explicit one-time
Legacy adoption procedure for the signed 1.13.11 candidate; only later
updates use the ordinary updater. Never treat a statement signed solely by the
retired 1.13.1 key as authorization for its replacement.
ElectrumX-RVN deliberately separates trust domains instead of collapsing them into one version check.
- Core identity: the deployment binds an exact official RavenProject repository/release/commit identity.
- Release/update signatures: ElectrumX releases use a dedicated Ed25519 release trust domain separate from safe-Core policy signing.
- Fail-closed bootstrap: only allowlisted raw block files reach staging and Core performs mandatory local validation before ElectrumX consumes the chain.
- Anti-rollback: host security state prevents reinstalling into another directory from silently lowering the highest accepted release floor.
- Container/network isolation: Core RPC stays private by default and public, monitoring, and administrative paths are kept separate.
- Database integrity: startup checks reject unsafe historical extent corruption while bounded crash-tail recovery remains explicit.
- Observation is not authority: Network Observer evidence cannot authorize releases, rotate governance, or replace local Ravencoin validation.
- Governance domains remain separate: release and safe-Core policy authorization use distinct keys and domains; threshold activation is pending a future independent-maintainer ceremony.
See Security model, Core certification, and Crash consistency for the
full rationale and limits. Security reports should follow SECURITY.md.
A healthy container is not the same thing as a fully synchronized node. Normal first-start progression is:
- Core configuration and private RPC credentials are prepared.
- Core starts, or ChainStrap stages verified raw blocks.
- Core performs its mandatory validation/reindex and reaches a usable chain.
- ElectrumX indexes the validated Core chain.
- ElectrumX catches up to Core.
- Backend/checkpoint/asset evidence becomes meaningful.
- Only then should an operator publish a public TLS endpoint.
Useful checks:
docker compose ps
docker compose logs --tail=100 ravencoin-core
docker compose logs --tail=100 electrumx
docker compose exec electrumx electrumx_rpc getinfo
docker compose exec ravencoin-core raven-cli \
-conf=/var/lib/ravencoin-config/raven.conf \
-datadir=/var/lib/ravencoin getblockchaininfoDuring initial synchronization, blocks < headers is normal. During local
reindex, height fields can appear static while block-file processing continues
in the Core logs.
A private ElectrumX server can serve wallets over a LAN or VPN without router port forwarding. This is the recommended first milestone.
For a public service, configure a stable hostname, external TLS, and only the ports intentionally required. Never expose Ravencoin Core JSON-RPC or unauthenticated Core REST to the public Internet. The normal public Electrum TLS service uses TCP 50002.
See Public node for DNS, CGNAT, firewall/forwarding, certificates, and external testing.
The maintained deployment uses the official RavenProject Ravencoin Core 4.8.0 release line introduced following the August 2026 consensus incident and binds the exact official identity rather than accepting a version label alone.
For incident boundaries, recovery behavior, and primary references, see the August 2026 incident guide.
Start with the guide that matches the task:
| Task | Guide |
|---|---|
| Understand what the fork adds | Fork feature guide |
| Install a first node | Getting started |
| Review 1.13.13 changes | 1.13.13 overview |
| Understand the architecture | Architecture guide |
| Understand ChainStrap | Fast bootstrap |
| Choose hardware | Hardware |
| Choose storage | Storage selection |
| Operate or update a node | Operations |
| Publish a public server | Public node |
| Understand trust boundaries | Security model |
| Understand Network Observer | Network Observer guide |
| Understand governance | Governance guide |
| Verify Core identity | Core certification |
| Diagnose a problem | Troubleshooting |
| Check qualification status | Validation status |
| Adopt an old 1.13.1 node | Legacy adoption |
| Browse all documentation | Documentation index |
This repository is maintained by ALENOC as a community ElectrumX fork for Ravencoin. The original ElectrumX/Ravencoin lineage and MIT notices are preserved; see Upstream and credits.
Special thanks to Tron Black for ChainStrap and for making Fast Verified Bootstrap available to the Ravencoin ecosystem.
See LICENCE.