Codex Cronotons

Codex Cronotons let the Ancient Admin build an arbitrary StoaChain transaction once and have the Hub run it on a schedule — or fire it on demand — entirely autonomously. The transaction is signed server-side by the Hub Codex, which is sealed under the Hub Master Key, so no key material is ever typed or held in a browser to make a scheduled transaction happen.

Where it lives

The surface is at /hub/codex-cronotons, restricted to the Ancient Admin. It is separate from the generic /hub/cronotons page: Codex Cronotons are specifically the ones the Hub signs with the codex.

Building a transaction

The builder mirrors the OuronetUI “Execute Code” experience — a Pact code editor on the left and a tabbed panel on the right:

• Config— chain, gas price (ANU, minimum 10,000—the protocol floor), gas limit (AUTO, calibrated by a simulation, or manual), the derived max transaction fee, and time-to-live (60 s–24 h).
• Payload — the environment data and keysets the Pact code reads (typed entries or a raw-JSON mode).
• Gas Payer — a codex account (which then signs coin.GAS), or the Ouronet Gas Station (where a chosen codex key signs the DALOS.GAS_PAYER capability). Either way the gas payer becomes an auto-managed, locked signer that appears at the top of the Signatures list.
• Signatures— the gas payer (shown locked) plus any additional signers chosen from the codex’s own keys, each with its capability list. Only codex keys are usable (so the Hub can reproduce the signature at fire time).
• Execute — a summary plus Simulate (a no-submit dry run that validates the transaction and calibrates the gas limit) and, in place of an immediate run, Schedule then Commit.

The schedule engine

A committed transaction can fire on any of these schedules:

• One-time — once, at a chosen date and time.
• Interval — every N minutes.
• Daily / Weekly / Monthly — at a chosen time (and weekday / day-of-month).
• Several times per day — at multiple fixed times.
• Cron — a raw cron expression for anything else.

Limbo, manual firing & the audit trail

Committed transactions sit in a list (“limbo”) showing their schedule, status (active / paused / completed / error), and next/last fire times. From there each one can be paused, resumed, edited (changes take effect at the next fire), deleted, or fired immediately with Execute Now. A recurring entry’s detail page also offers Execute Now ×N— fire it 2–60 times, once per minute, driven server-side by the worker (so it survives a closed tab or a redeploy); Execute Now is blocked while a batch runs, and the batch can be cancelled mid-run. Every fire — scheduled, manual, or part of a batch — is recorded with who triggered it, when, success or failure, the request key, the chain, the chain response, and a fingerprint of the exact transaction definition that ran. Each fire also carries a TEST / LIVE badge: it is tagged TEST while the Stoicism economy is still pre-launch, and LIVEonce an Ancient admin has locked the live state — so anyone reading a Minter’s fire history can tell the test runs from the real, post-launch mints. A cronoton whose transactions are declared real (e.g. the on-chain Ouro minter) can carry a per-cronoton override that badges all its fires LIVE regardless of the lock.

How it runs autonomously

A background worker tick checks for due transactions and fires each one through a single server-side executor: it unseals the codex, resolves the signer keys, builds and signs the Pact transaction, submits it, and waits for the result. A one-time transaction fires exactly once and then completes (or errors); a recurring one keeps its schedule and a failed run is recorded but never auto-paused. A row is claimed before it fires, so it can never be fired twice — even if a manual Execute Now and the scheduler coincide.