The same cryptography, turned inward.

A product of the protocol, not a second protocol.

TRELYAN is the Swiss foundation (in formation in Zug) and the Falcon-1024 inscription protocol it stewards; that protocol, and the on-chain primitive it depends on, are documented on the Protocol page. THRONDAR is a product TRELYAN owns: a governed-AI system whose individual decisions the foundation wishes to make verifiable after the fact. The relationship is one of containment, not partnership — the protocol provides the cryptography; the product consumes it.

The distinction matters for what is claimed here. The on-chain inscription primitive is Falcon-1024, the NIST-selected (2022) lattice signature designated FN-DSA, whose standard — FIPS 206 — is in development and not yet published. The assurance controls described below do not depend on that forthcoming document. They are built from standards that are already published, so that nothing on this page waits on a draft to be true.

This is a subordinate page. It does not change what TRELYAN is, and it does not place THRONDAR beside the protocol as an equal. It records how the protocol's discipline extends to one product the foundation runs.

Every governed decision is signed evidence.

A THRONDAR governance decision — an action taken, an action refused, the inputs that were considered, the policy that was applied — is serialised into a canonical record and signed with ML-DSA-87, the highest parameter set of the Module-Lattice Digital Signature Algorithm standardised in FIPS 204 (published 13 August 2024). ML-DSA is a Fiat-Shamir-with-aborts lattice scheme whose existential unforgeability reduces, in the random-oracle model, to Module-LWE and Module-SIS — structured-lattice assumptions with no known efficient quantum attack. We use the published standard for these attestations precisely because it is published; the on-chain inscription primitive remains Falcon-1024 / FN-DSA, and the two roles are kept separate.

The choice of the highest parameter set is deliberate rather than rhetorical: ML-DSA-87 targets NIST security category 5, the level associated with AES-256-equivalent classical and quantum resistance, at the cost of a larger signature (≈4,627 bytes) than the category-2 and category-3 sets. A governance attestation is written once and may need to be checked decades later; the marginal size is acceptable against that horizon. Where confidentiality of a decision payload is required in transit, key establishment uses ML-KEM (FIPS 203), typically in a hybrid construction alongside X25519 so that the combination is no weaker than its strongest component.

An attestation is not a guarantee that a decision was correct. It is a guarantee that the decision, its inputs, and the policy version under which it was taken were fixed at the moment of signing and cannot be silently altered afterward. The verification key is published; anyone may check a THRONDAR attestation independently, without trusting the foundation, the product, or any intermediary.

Append-only, with proofs you can check.

Signed attestations are committed to an append-only log structured after RFC 6962, the Certificate Transparency design. The log is a Merkle tree over the ordered sequence of attestations; its head is a signed tree head over the current root and size. Two proofs make the structure auditable without trusting the operator. An inclusion proof demonstrates that a specific attestation is present at a specific position under a given signed tree head. A consistency proof demonstrates that a later tree head is an append-only extension of an earlier one — that nothing previously logged was removed, reordered, or rewritten.

The property this delivers is narrow and exact: a decision, once logged, cannot be unlogged or back-dated without detection by any party holding an earlier signed tree head. It does not make decisions public by itself, nor does it adjudicate whether a decision was good. It makes the record of decisions tamper-evident in the same way the public web's certificate ecosystem is made tamper-evident — by the same construction, cited to the same RFC.

The code that decided is traceable to its source.

An attestation over a decision is only as trustworthy as the software that produced it. THRONDAR's build pipeline emits supply-chain provenance under the SLSA framework: signed in-toto attestations that bind a deployed artifact to the exact source revision, build instructions, and builder identity that produced it. Each release carries a Software Bill of Materials (SBOM) enumerating its components and their versions, so that a given THRONDAR decision can, in principle, be traced from the signed record back through the running binary to the source commit and dependency set behind it.

This work follows the United States Government's secure-software-development guidance — NIST SP 800-218 (the Secure Software Development Framework), issued under Executive Order 14028 — as a published reference for practices, not as a certification we hold. The aim is provenance that an external reviewer can follow, so that a question of the form "which code took this action, and where did that code come from" has a cryptographically anchored answer rather than an assurance.

Tested against a named threat model.

Cryptographic integrity protects the record of a decision; it does not protect the decision process from manipulation of its inputs. THRONDAR is therefore red-teamed against the published taxonomy of attacks on AI systems. NIST AI 100-2e2025 — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations — provides the vocabulary and the attack classes: evasion, poisoning, privacy, and, for generative systems, prompt-injection and related abuses. MITRE ATLAS supplies the adversary tactics-and-techniques matrix against which exercises are structured and reported.

Red-teaming is a process, not a proof. It cannot establish that a system is free of weaknesses; it can only establish that specific, named classes of attack were attempted against it and the results recorded. Framing the exercise against NIST AI 100-2 and MITRE ATLAS keeps the threat model public and the findings legible to an outside reviewer, rather than resting on an internal and unstated notion of "tested."

Not a description — a running system you can check.

The controls above are operational today, and each is independently verifiable without trusting the foundation. The bridge that runs THRONDAR's governed council publishes the post-quantum verification keys and the exact canonicalisation needed to check a decision; verification therefore needs no privileged access and no secret — only a decision record and the published keys.

Every governed answer is dual-signed, ML-DSA-87 and Falcon-1024, over its canonical payload, against the keys at /v1/provenance/pubkeys. The decision record — which models deliberated, the governance verdict, the cost, the digest of the answer — is dual-signed under a separate, pinnable identity at /v1/ledger/pubkey and appended to the RFC 6962 Merkle log; the log's current signed tree head is served at /v1/ledger/sth, and an inclusion proof for any decision at /v1/ledger/inclusion. Each decision also carries a provenance_ref binding it to the exact build that produced it, published at /v1/provenance/ref. The transport beneath all of this is itself post-quantum: the connection negotiates a hybrid X25519 + ML-KEM-768 key exchange, so the channel resists harvest-now-decrypt-later capture.

None of this asks for trust. An open verifier — verify_decision.py — re-derives the signed bytes from first principles and checks both signatures, the SHA-384 and SHA3-512 digests, the inclusion and consistency proofs, and that the keys embedded in a decision match the published identity. Tamper with any field and verification fails. It depends on nothing from us but the public keys.

One limit, stated rather than hidden: the log runs on a single host today, which makes it tamper-evident but not yet equivocation-proof — a host with full control could, in principle, present different histories to different observers. The standard remedy is independent witnesses that co-sign each tree head; the /v1/ledger/sth endpoint exists precisely so they can, and standing them up is the next step on this layer.

A bounded claim, stated plainly.

The controls on this page are aligned to public NIST and NSA standards, not certified against them. ML-DSA-87 (FIPS 204), ML-KEM (FIPS 203), the RFC 6962 log construction, the SLSA / in-toto / SBOM provenance discipline (NIST SP 800-218, Executive Order 14028), and the NIST AI 100-2 / MITRE ATLAS red-teaming frame are chosen because they are published and externally checkable. The selection — category-5 post-quantum signatures, hybrid post-quantum key establishment, an append-only transparency log — is consistent with the direction of the NSA Commercial National Security Algorithm Suite 2.0; it is defense-grade-aligned, and no compliance certification is asserted.