TRELYAN — first end-user falcon_verify consumer protocol (Swiss Stiftung in formation)

General
1

Hello Algorand community,

I’m Brandon Joseph Sellam, founder of TRELYAN — a post-quantum inscription protocol designed to use Algorand’s native falcon_verify opcode at consensus as a primary primitive rather than a demonstration.

What TRELYAN is, in one paragraph. TRELYAN issues 1,024 numbered non-fungible Vault Cells, each carrying the irrevocable right to inscribe one immutable artifact (≤ 4 KB payload) under a Falcon-1024 signature verified by the native falcon_verify opcode (Algorand mainnet, AVM v12). Each Cell is a unique ASA with structured transferability state. Each inscription binds artifact, Cell, and authorizing public key under a domain-separated preimage "TRELYAN-INSCRIBE-v1" ‖ cell_id ‖ artifact_hash ‖ sender, verified at consensus and persisted in box storage. Public site at https://trelyan.foundation; whitepaper there.

Why I’m posting here. TRELYAN is the natural ecosystem follow-on to the Foundation’s 11 November 2025 first post-quantum mainnet transaction. I would like the Algorand community — including the Foundation team, cryptographers, smart-contract auditors, and other builders — to know that TRELYAN exists, to read the technical materials, and to engage with the design before it ships.

(Adjacent prior art I want to flag with respect: the Algo-pqc-kit Algorand-Native PQC Developer Toolkit thread from earlier this month. Different scope — a generic PQC SDK rather than an end-user inscription protocol — but complementary, and I’d welcome a conversation about how TRELYAN’s open-source reference toolkit (Falcon-1024 signing harness, post-genesis validation script, dual-IPFS-pinning helper, threat-model + audit-RFQ templates) could plug into or extend that kit’s surface.)

Project status (27 May 2026):

  • Modern algopy / PuyaPy / AVM v12 inscription contract is feature-complete and internally threat-modelled (T1–T28 enumerated)
  • Deploy + mint + ceremony pipeline written; TestNet rehearsal runbook drafted
  • Public surface live: site, status dashboard, whitepaper
  • Foundation forming as a Swiss Stiftung in Zug; counsel LEXR Zürich
  • TRELYAN trademark filed at IGE Zürich under application 08601/2026 (Nice classes 9 / 36 / 42; protected scope explicitly names NIST FIPS 206)
  • Founder personal capital invested: zero (by signed and witnessed commitment letter)

Gates remaining for genesis (Q2 2028 target):

  • Founding cryptographer engagement (outreach in motion to Falcon-team alumni)
  • Third-party smart-contract audit (Runtime Verification recommended; RFQ sent today)
  • FINMA pre-ruling on Cell classification (LEXR-led, post-Stiftung-formation)
  • Cell pre-sale opening (Q4 2027, post-audit)

What I’m asking of the community:

  1. Read the technical materials. The whitepaper is at https://trelyan.foundation and explains the cryptographic substrate, the Cell economics, and the protocol invariants.

  2. If you’re a cryptographer or have experience with lattice signatures, I would value your read on the binding between Algorand’s opcode implementation and the reference Falcon spec — particularly with FIPS 206 still in development. The architecture spec §6 questions are the substantive items I would most welcome PhD-level engagement on.

  3. If you’re a smart-contract auditor active on Algorand, I would welcome an introduction. The RFQ goes to Runtime Verification as primary, with CertiK and Halborn as backups; competing quotes are encouraged.

  4. If you’re a builder working on adjacent post-quantum or inscription protocols, I would like to be aware of each other’s design choices. TRELYAN’s open-source reference tooling will be released on a schedule that benefits the ecosystem more than the protocol.

  5. If you’re with the Foundation, I would welcome direct contact at brandonjsellam@releone.io. The full submission packet (15 PDFs + contract source) is assembled and ready when the next Accelerator cohort opens.

Not asking for in this post:

  • Pre-sale interest (the pre-sale opens Q4 2027 with KYC-gated tiers; this is too early)
  • Investment (the funding stack is grant + F&F bridge + Cell pre-sale, by signed commitment letter — and pre-Stiftung-formation I cannot receive bound investment)
  • Endorsements

I’m here to engage. Critiques of the design, hard questions about the cryptographic substrate, and recommendations for advisors / auditors / co-fiduciaries are all welcome.

Brandon Joseph Sellam
Founder, TRELYAN Foundation (in formation, Zug)
brandonjsellam@releone.io · https://trelyan.foundation

2

Hi Brandon - I’m the author of algo-pqc-kit, which you referenced. Thanks for the kind words.

A few notes from the infrastructure side:

On positioning: You called algo-pqc-kit “generic” - I’d reframe that as foundational. algo-pqc-kit provides the account model (FalconLsig), the threshold vault (FalconVault), and the DAO governance primitive (PQCDao). TRELYAN, if I understand it correctly, is an end-user inscription protocol that would naturally consume these primitives. That’s actually a healthy stack relationship, not a parallel one.

On the Falcon encoding question you raised in our issue: I’ve replied in detail there. Short version align on the AVM compressed format (≤ 1232 B, no custom header), and the C FFI dependency likely becomes unnecessary.

On interop: We’re open to a reference integration once encoding is confirmed. An inscription authorized by a FalconLsig account is a natural showcase for what AVM v12 enables.

On the broader PQC ecosystem: The Algorand Foundation’s falcon_verify opcode is genuinely groundbreaking. The right outcome for the ecosystem is a clear stack:

  • AVM v12 falcon_verify (Foundation layer)
  • algo-pqc-kit (account / vault / governance primitives)
  • End-user protocols like TRELYAN (inscription, DeFi, etc.) built on top

We’re committed to keeping algo-pqc-kit the open, MIT-licensed foundation that any protocol can build on. Looking forward to seeing what you ship.

- @falcon / QuantaLabs