Singular 0.11.0 — nine-request folds, closed-datum registries and a wallet vault

Singular is a permissionless registry of unique keys on Cardano: each active key is held as one token in an output of the application that uses the registry, and a key can be registered and then terminated for good. This release lets one fold — the transaction that applies pending requests to the registry — settle up to nine requests, so participants who book at the same time no longer block each other. It adds closed-datum registries, whose payload is written once, a registry page that anyone can read from a state token, commands that fund themselves from a wallet with a single output, and an encrypted wallet vault with offline signing.

What changed

Folding

• One fold settles every pending request that passes, up to nine, in ledger order and at most one per key. The receipt lists the settled requests in settled and the ones left out, with their reasons, in excluded; the capacity of nine is stated with its provenance. Recovery of an interrupted fold reads every transition it made (#569, #622, #626, #627).
• A fold is admitted only inside the processing window of every request it includes. A fold whose validity would pass a request's deadline is refused before signing and named not-phase1, and a batch that terminates a key it registers in the same fold is refused as token-missing. Both rules are now in the Lean model (the formal specification) and in the fold builders (#630, #634, #646).

Closed-datum registries

• The open-datum application gains a second validator, open_datum.closed_datum: a key's payload is written once at registration and every update is refused on chain. Registration, termination and the deposit's return work as in open-datum; the open-datum validator hash is unchanged (#653).
• open-datum create --closed creates such a registry. Every later open-datum command follows the registry's mode with no flag, and update on a closed registry stops before anything is built or signed (#657). A hosted job runs this scene from the release archive on a development network (#662).

Reading a registry

• singular registry describe --state-token … prints a page built from the state token's public history and the packaged release: the registry, the release it runs, its rules and what it holds now. --json prints the same facts as a receipt. The command reads only and takes no wallet (#614).
• The create receipt carries describeCommand, the exact command to read the new registry's page. The on-chain archive ships onchain/version.txt, so describe run from the extracted archive names the release (#628).

Funding writes

• create works from a wallet with one ada-only output: when the state script must be published, the seed is the change of that first publication, and create --preview names the state token before anything is submitted. --seed is now optional (#625).
• create publishes each reference script from the fewest of the wallet's largest outputs, and refuses a wallet that cannot fund the whole run before anything is submitted, naming the short step and the total needed (#613).
• fold, reject, reclaim, insert and terminate make one preparation transaction first when no wallet output can fund them (for example when the ada sits beside tokens), leaving tokens and published scripts untouched; the receipt names the preparation (#645, #658).
• The fixed 100 ada wallet floor is gone: a booking is judged against its measured cost, and an empty wallet is refused with the faucet step (#619).

Wallet vault

• singular wallet create --vault FILE --network-magic N generates a fresh signing key into a passphrase-encrypted vault (an ordinary age file) and prints the address; singular wallet address prints it again from the vault (#647).
• singular wallet sign --vault FILE BUNDLE signs a bundle of unsigned transactions offline and writes one witness file per transaction. The bundle is checked first: identities, deadlines and signers (#665).

A second application

• The repository gains applications/keri-stub, a stub of a KERI (Key Event Receipt Infrastructure) application built only on the registry library, with create, register, convict, fold and status and its own hosted journey. It shows that an application other than open-datum can use the registry (#561).

Evidence that the chain refuses

• singular-negative adds the owner's reclaim of a booking stranded by a refused insertion, a pair in which the node refuses an update on a closed-datum registry, and mutants for the registry's occupied-key rule and the closed-datum rule. The new page docs/negative-host.md describes every pair, what refuses it and how to run it (#567, #577, #664).

Release and test machinery

• The Lean library builds with Lean 4.27.0 (#589). The development network uses 20 000-slot epochs, so a fold's validity ends at its deadline rather than at the epoch end (#602). Every declared check now has a hosted job, recovery controls run as parallel jobs, and a hosted job checks the release review archive.

Use it

1. Download singular-onchain-0.11.0.tar.gz and SHA256SUMS. The checksum file also covers singular-docs-0.11.0.tar.gz; download it too to check every listed file.
2. Run sha256sum --check SHA256SUMS, extract the on-chain archive, then run bash verify-identities.sh inside it to check the compiled validators. To check the whole release from its downloaded bytes, including a run of the commands on a development network, run nix run github:lambdasistemi/singular/v0.11.0#verify-release -- v0.11.0 (https://github.com/lambdasistemi/singular/blob/v0.11.0/docs/verify-release.md).
3. Follow DEMO1.md in the archive. It builds singular, open-datum and a private development node with Nix, then runs a registry end to end: create, read the registry page, insert, fold by another wallet, inspect, update, terminate, reject and reclaim, plus the closed-datum scene. A wallet with one ada-only output is enough for create; the public-network section of the archive's DEMO1.md still asks for two, which is out of date (https://github.com/lambdasistemi/singular/blob/v0.11.0/docs/demo1-preprod.md#funding-a-create-from-one-output).
4. To read any registry's page, see https://github.com/lambdasistemi/singular/blob/v0.11.0/docs/registry-page.md. The vault, the signing of bundles and every flag are described in https://github.com/lambdasistemi/singular/blob/v0.11.0/docs/singular-node.md.
5. To run against a test network with your own Koios endpoint (Koios is a public Cardano chain-data API) and wallet, follow https://github.com/lambdasistemi/singular/blob/v0.11.0/docs/consumer-onboarding.md. For what a preprod run checks, see https://github.com/lambdasistemi/singular/blob/v0.11.0/docs/demo1-preprod.md.
6. To watch the chain refuse forbidden transactions, run singular-negative from a checkout at this tag as https://github.com/lambdasistemi/singular/blob/v0.11.0/docs/negative-host.md describes.

Limits

• The fold capacity of nine is an estimate of what fits under preprod's execution budget, not a measurement on a real network.
• The registry page relies on Koios answers that are not verified; its release label is the archive's own claim, and the page is unsigned.
• No public-network run of Demo 1 has happened for this release; the preprod page is a reviewer's map, not a record of a run.
• A reject refund is accepted by the chain only as one output to the request's owner (issue #361).
• The archive still carries the row runners of the earlier naming design. They are not buildable or verified against this release's source and must not be relied on.

Full list of changes: v0.10.1...v0.11.0