Development digest — 7 October 2026

State of dev as of 2b6d230da1a1, 7 October 2026. Most of these three days went into archival nodes, the machines that keep and serve the chain's history: how the chain tests that they are really serving it, and what a node says when someone asks it for data. Alongside that, a ruling on how Tor ships with the node, and another deletion of code inherited from Monero that had never run.

How the chain checks that archivers serve — RULED

Archivers put up a bond, hold parts of the chain's history, and are paid for serving them. That only works if the chain can tell an archiver that serves from one that just claims to. The hard part is the test itself. If an archiver can tell when it is being tested, it can answer the tests and ignore everyone else.

The previous design chose who to test from the previous block's hash. That draw was public, so anyone could work out in advance which archiver would be tested and when, the archiver included. It was never connected to the running node, and it has now been replaced. The new design, ratified this window, makes the draw secret. Each block's producer commits to a random seed in that block. The seed and the block's hash pick which archivers to test. The producer then fetches data from each one over its onion service, using the same request any reader sends, so the archiver cannot tell a test from ordinary traffic. The archiver signs for exactly the bytes it delivered. Within a fixed window the producer publishes the seed together with the signed receipts, and every node checks that the seed matches the commitment and that each receipt belongs to the archiver the seed picked.

Some parts of the design exist to close specific gaps. A miss is never reported by anyone. It is a test that was revealed and has no receipt, so no party can write one against an archiver. A producer that never reveals its seed creates no misses, and its draws simply do not count. Which of an archiver's tests decide its result is picked only at the end of the settlement period, so an archiver cannot learn partway through that it has passed and stop serving. The seed and the key the producer signs with are fresh random values for each block and are kept only in memory. Deriving them from the block reward's key material was considered and rejected, because whoever receives that reward could then calculate the seed. Receipts use FN-DSA, a post-quantum signature that is smaller and faster than the one used for identities. FN-DSA is not yet a final standard, so it gets a key of its own. An archiver's long-lived identity stays on a finalised standard, and the newer scheme only signs receipts that stop mattering once the period closes.

The sizing was checked before anything was built. The economics simulator modelled the draw, and the model and the predicted results were committed before the code that runs it. The target was that, with one in ten block producers failing to reveal, at most 3% of archivers end a period without enough tests to judge them. The worst of eight runs came in at 1.18%. One cost is still unmeasured: each block a producer wins now also means reading a batch of history from archivers. That will be measured on mining-class hardware. Nothing in this design is built yet. When it is, the public draw and the attestation records it replaces will be deleted in the same change.

What an archiver says when you ask it for data — LANDED

When a node asks an archiver for a piece of history, the archiver sends the data and ends the response with a signature over what it sent. The signature is mixed with a fresh value from the request, so it cannot be reused for a different request. The version that landed a few days earlier read each piece twice: once to hash and sign it, then again to send it. So a request that disconnected straight away still cost the archiver a full read, a hash and a signature. The archiver now reads once. It hashes each chunk as it sends it and signs at the end, so the expensive work happens only for bytes the requester has actually received. New tests count reads and signatures to keep it that way. Each test was checked by deliberately moving the work earlier, and the tests then failed as they should.

The other change is that each answer now means exactly one thing. A malformed request gets one fixed error, decided before the archiver checks whether it holds the data, so the reply is identical either way. "Not found" now means only "not held". A fault on the archiver's own side gets a separate "unavailable" answer. It used to report "not found" so as not to reveal the fault, but which archiver holds which data is public on chain. A "not found" for data the archiver is bonded to hold therefore revealed the fault anyway, and gave the wrong reason.

The last answer covers the case where the data went out but the signature failed. The archiver then fills the signature's space with a reserved marker that can never be a valid signature. The reason is Tor. A relay on the circuit can cut a response at any byte it chooses, and because Tor reuses the same entry relay, it can do so on every retry. It cannot insert bytes. So a response that stops early is always treated as a network problem and retried, and only a marker the archiver writes itself counts as the archiver refusing. The serving code also keeps no request logs at any level, only a few running totals.

On the project's minimum supported hardware, a Raspberry Pi 4–class board, serving the largest piece of history dropped from about 103 ms to 67 ms. Hashing what was delivered adds about 43 ms, which is under half a percent of a typical fetch over Tor. Connecting the archiver's signing key to this serving code is separate work that is still to come.

Tor ships with the node, and you have to choose to turn it off — RULED

A ruling this window says that Tor is essential to a Shekyl node. The earlier design treated it as an extra that a node could run without. The new ruling is that a node has Tor unless its operator turns it off explicitly with --no-ephemeral-tor. Running over the clearnet only is a supported choice, for example for an exchange or for infrastructure that does not rely on network-level privacy, or in places where Tor is blocked or watched. A node running that way will log a warning on every start. The ruling lists what you give up: peers can see the node's address, and the node's own transactions are relayed over the clearnet with no onion route. Nothing in the wallet or in consensus depends on the choice.

Two kinds of failure are treated differently. A Tor installation that is missing or does not match the pinned copy is an installation mistake the operator can fix, so the node will refuse to start and say what to do. That refusal is ordered last, after every published package (the GUI wallet's installers included) actually ships Tor, so that it cannot break a platform that has no bundle. A Tor that is correctly installed but cannot connect to the network is a network problem, not an installation one. The node keeps running without inbound onion connections and logs an error. Every release package will carry a pinned copy of Tor, checked against its recorded hash before it is unpacked during the build. It will include only Tor and the libraries it needs, and none of the extra transports it normally comes with. FreeBSD has no upstream Tor bundle, so operators there install Tor themselves, and there will be a guide.

The alternatives that were turned down are worth knowing. A command-line option to override the pinned hash was rejected, because it would turn a fixed check into something anyone who can edit a service file can switch off. A signed pin list that updates between releases was rejected because it is an update channel. A single key would then decide which program runs on every node, and fetching the list at startup would announce the node to whoever serves it. A security fix in Tor will instead cost a patch release, the same as a fix in any other bundled dependency. Using the operating system's own Tor was also rejected, because a distribution's build cannot match the pinned copy. None of this is implemented yet. The order of work is Linux first, then Windows and macOS, each with its own launch test, then FreeBSD, and the startup refusal last.

Code for Monero upgrades that never ran, deleted — LANDED

Monero changes its consensus rules at numbered network upgrades, and its code is full of branches that check the block version. Shekyl starts with a single block version, so every branch waiting for a higher version never runs, and the code that ships is whatever sits in its "else" case. A survey this window found every such comparison in the C++ code: 101 places, each recorded with what it actually does on Shekyl and what should happen to it. A CI check now fails if a new comparison appears that is not on that list, or if a listed one disappears without the list being updated.

Some of these went straight away. The deleted code included a peer check that had never run, checks that were always true, and two unused version constants. It also included the API for the output distribution, which wallets use to pick decoys. Its only remaining caller was its own unit test, and Shekyl's membership proofs use no decoys, so the whole API was removed rather than repaired. Nothing about how the node behaves changed.

The survey also forced a decision on the upgrade mechanism itself. The ruling is to delete Monero's upgrade table entirely: when Shekyl needs one, it will write its own instead of reusing Monero's. That deletion is ruled but not yet done. It will be a single change, because removing the mechanism piece by piece would leave a partial upgrade system in the meantime. The one real rule the table enforces today, that a block carries the current version, will stay as a direct check.

---

This post describes the state of the dev branch at 2b6d230da1a1 on 7 October 2026. Shekyl is pre-genesis and under active design; anything marked IN FLIGHT may change or be abandoned. Where a later post contradicts this one, the later post is correct.

References: PR #993, PR #992, PR #974, PR #982, PR #987, PR #986, PR #972