Verify it yourself.

Two layers, both checkable live.

Beyond the byte-level reference below, TRELYAN now publishes in-browser verifiers. They check both layers of the trust chain — THRONDAR's ML-DSA-87 signed tree head (Layer 1) and the on-chain Falcon-1024 inscription (Layer 2) — against a pinned key with self-hosted, audited post-quantum crypto. As of June 2026 the signed tree head also carries an additive SLH-DSA-256f (FIPS 205, hash-based) co-signature: ML-DSA and Falcon are both lattice schemes, so this adds a second, independent algorithm family — a lattice break would leave the hash-based leg standing. It follows the AIVD/CWI/TNO PQC Migration Handbook's guidance to prefer ML-DSA + SLH-DSA. No backend of ours sits in the middle; verification runs entirely in your browser. Open any of them and confirm, or break, the claim yourself.

Open-source (MIT), @trelyan/verify-pqc on npm — a unified ./verify dual-PQC entry (ML-DSA-87 + SLH-DSA-256f) with a FIPS-204/205 conformance KAT (npm run test:kat). TestNet, unaudited; adversarially reviewed (the verifier itself was hardened after a multi-model security review).

One application, inspectable now.

The reference contract runs on Algorand TestNet as application 763809096. It is non-upgradable and non-deletable by construction — the update and delete handlers reject unconditionally — so the approval program you inspect is the one that runs. Each cell uses three boxes keyed by uint64_be(cell_id): the committed public key (k_), the controlling owner (o_), and the write-once inscription record (i_).

What gets signed, to the byte.

The signer signs a 102-byte domain-separated message M directly — it is not pre-hashed; the opcode performs hash-to-point internally. The contract rebuilds the identical bytes on-chain, so an off-chain signature is valid only for this exact app, cell, artifact, and network:

M  =  DOMAIN_TAG            (22 B)  "TRELYAN-INSCRIPTION-v1"
   ||  app_id               ( 8 B)  uint64, big-endian
   ||  cell_id              ( 8 B)  uint64, big-endian
   ||  artifact_hash        (32 B)  SHA-512/256 of the artifact
   ||  genesis_hash         (32 B)  Global.genesis_hash  (network pin)
   ───────────────────────────────
   =  102 bytes, signed raw

Binding app_id, cell_id and the network genesis_hash into M makes a signature non-replayable across applications, cells, and networks. The artifact itself lives off-chain (e.g. IPFS/Arweave) and is tamper-evident against the 32-byte hash — it is not stored or hidden on-chain.

Deterministic Falcon-1024, stated precisely.

Base Falcon is a randomized signature scheme: it draws a 40-byte salt and achieves EUF-CMA security in the (quantum) random-oracle model resting on the NTRU key-recovery and NTRU-SIS assumptions. Algorand's native falcon_verify opcode (introduced at AVM v12 / consensus v41, go-algorand v4.3.0) accepts the deterministic, compressed encoding of the algorand/falcon library — not the randomized encoding generic libraries emit. The distinction is exact and easy to get wrong, so here it is in full:

variant         deterministic Falcon-1024 (falcon_det1024), COMPRESSED
header byte     0xBA   =  0x3A | 0x80   (high bit marks the deterministic variant)
                       (randomized Falcon would begin 0x3A — wrong here)
salt-version    1 byte, 0x00           (the nonce is excluded; a salt-version byte is added)
public key      1793 B,  leading byte 0x0A  (logn = 10)
signature       variable-length, compressed:  ≤ 1423 B,  typically ~1222–1233 B (KAT goldens 1232–1233 B)
artifact hash   SHA-512/256, 32 B
spec lineage    implements the NIST Round-3 Falcon-1024 specification —
                DISTINCT from the in-development FIPS 206 (FN-DSA) draft, which is
                not yet published and is expected to differ.

Determinism is a property of the algorand/falcon deterministic implementation (deterministic.c), which excludes Falcon's random nonce and adds a salt-version byte; the same secret key and message yield the same signature — which is what lets the build below be checked byte-for-byte. This is not a claim that the nonce is merely zeroed (which would void the security proof); the exact construction is in the linked, digest-pinned source. Falcon here is a signature scheme — it provides integrity and anti-forgery, not encryption. Nothing about an inscription is confidential.

A signer that reproduces.

All TRELYAN signing builds from one frozen upstream commit. The emulated fixed-point backend (config.h: FALCON_FPEMU=1) is what makes signing byte-reproducible across compilers and operating systems — a property an independent party can confirm:

repository        github.com/algorand/falcon
commit            ce15e75bceb372867daf6b8e81918ab6978686eb
source tree       sha512_256  c6adf4871389dfdbf3ffbd853bd9e5ce15646b821d6dc84e327ab1b3d2adc980   (27 files)
deterministic.c   sha512_256  601390dc53521fc1b00eb962ea63d64c2d65bfe774450cf4ec59a3478e0a54a4
fp backend        FALCON_FPEMU = 1   (emulated, bit-exact across platforms)

# reproduce the digests yourself (any machine, ~10 seconds)
curl -sL https://github.com/algorand/falcon/archive/ce15e75bceb372867daf6b8e81918ab6978686eb.tar.gz | tar xz
cd falcon-ce15e75b*
python3 - <<'EOF'
import hashlib, os
h = lambda p: hashlib.new('sha512_256', open(p,'rb').read()).hexdigest()
print('deterministic.c', h('deterministic.c'))
EOF
# expect: 601390dc53521fc1b00eb962ea63d64c2d65bfe774450cf4ec59a3478e0a54a4

Three executable controls guard that reproducibility — not prose, but checks our CI re-runs across Linux, macOS, and Windows, and so can you. Cross-OS byte-identity (Linux/macOS/Windows) is demonstrated: the 3-OS CI signature-KAT runs green, reproducing the goldens byte-for-byte on Linux (gcc), macOS (clang), and Windows (MSVC). Same-architecture byte-identity is shown below:

determinism      100,000 messages, -O0 vs -O3 build   →   0 mismatches
encoding sanity  re-signed vectors are byte-identical to the committed KAT goldens
memory-safety    an upstream misaligned uint64 load (inner.h:846, an OPTIONAL fast path)
                 is closed by build flags  -DFALCON_UNALIGNED=0 -fno-strict-aliasing
                   → no source edit; the pinned digest above is unchanged
                   → PROVEN byte-identical to the goldens
                   → alignment- and UBSan-clean across keygen + sign + verify
ci gate          a sanitizer job fails the build on any misaligned load or UB,
                 and asserts the default build still traps (so the gate is non-vacuous)

The memory-safety item is a portability fix, not a cryptographic one — it changes no signature byte. The full per-claim cryptographic analysis, with its honest "what this does not prove" envelope, lives in the project's reviewer-facing dossier.

Golden vectors, byte-identical.

The open-source SDK (trelyan-pq) ships a committed test fixture: a fixed keypair and fixed messages with their expected signatures and sha512_256(σ). Building the pinned library and re-signing must reproduce those bytes exactly — and the 3-OS CI job confirms this across Linux, macOS, and Windows (green), so byte-identity holds across compilers (gcc / clang / MSVC), not just one architecture. Flip a single byte of a golden and the check fails. The same malformed-encoding rejection matrix (wrong header, truncated, over-long, tampered salt-version, wrong message) is asserted both off-chain and against the on-chain opcode, and they must agree.

The vectors are deliberately labeled a public test vector — not a secret: the keypair is bound to no cell and is never used on-chain.

What is claimed — and what is not.

One table, no euphemisms. "Demonstrated on TestNet" means observed against a live AVM and unaudited; it is not a security guarantee.

What an inscription does not prove.

It is also not audited, and Falcon is a NIST-selected candidate whose FIPS 206 standard is not yet published. Those facts are stated plainly because a system whose integrity claims you cannot check is not worth your trust — and the point of this protocol is that you should not have to extend it.