Proposal for new HIP: RISC-V + Tenstorrent open-source silicon as a first-class target

[Pattermesh]

TL;DR

Proposing a new HIP that establishes linux/riscv64 as a first-class build target for the Hanzo unified binary stack and, more strategically, designates Tenstorrent open-source RISC-V silicon (Ascalon CPU cores + Wormhole/Blackhole accelerators) as the reference open-stack hardware platform.

This issue is meant to surface the direction and gather signal before drafting the actual HIP markdown. Filed under Pattermesh from the SATSCHEL side (LIQUIDITY/MLC, downstream consumers of hanzoai/{iam,gateway,kms,base,...} via hanzoai/cloud). Currently in observer mode on the Hanzo stack — won't push a HIP PR without explicit direction from @hanzoai maintainers.

Why this is a natural HIP

The existing HIP backlog already targets the surfaces RISC-V/Tenstorrent would impact:

Existing HIP	Connection to a RISC-V/Tenstorrent HIP
HIP-001 Post-Quantum Cryptography Standard (Implemented)	PQ kernels (ML-DSA, ML-KEM, threshold sigs) on RVV 1.0 are a clean canvas vs. legacy AVX/NEON paths
HIP-005 KMS Hardware Security Module Integration (Active)	Open-RTL silicon (Ascalon) is exactly the HSM substrate an "open-stack KMS" needs
HIP-006 AI Mining Protocol (Draft)	Tenstorrent boards (Wormhole, Blackhole) are the open alternative to NVIDIA for AI compute mining
HIP-007 ZAP - Zero-copy Agent Protocol (Draft)	Zero-copy semantics map cleanly onto Tenstorrent's dataflow tensor model

Why Tenstorrent specifically (vs. any RISC-V vendor)

1. Open-source CPU IP — Ascalon RISC-V cores ship with open RTL under a permissive license. No other server-class RISC-V vendor does this.
2. AI/dataflow accelerators co-resident with the CPU — Wormhole (n300) and Blackhole boards combine RISC-V CPUs with tensor units suited to:
   • PQ lattice math (NTT, polynomial mul for ML-DSA/ML-KEM)
   • FHE precompile bottlenecks (BFV/CKKS ring ops)
   • AI inference / training workloads (HIP-006 mining protocol)
3. Open software stack — TT-Metal SDK is open and low-level; not a CUDA black box. Auditable end-to-end, aligning with HIP-001's threat model.
4. Strategic alignment — Tenstorrent (Jim Keller) explicitly targets open-stack shops. The Hanzo + LUX + SATSCHEL post-quantum stack is exactly that customer.

Concrete work this implies

Tier 1 — cheap validation

• Build hanzoai/cloud (unified binary) for linux/riscv64. Go already supports GOOS=linux GOARCH=riscv64.
• QEMU-RISC-V smoke test in CI for hanzoai/{cloud,base,iam,gateway,kms,kv,mq,vfs}.

Tier 2 — PQ + AI on RVV 1.0

• Audit hanzoai/kms (HIP-005) cryptographic kernels for scalar fallback on RISC-V.
• Audit hanzoai/ai inference kernels for arch portability.

Tier 3 — Tenstorrent-accelerator-specific

• TT-Metal kernel backends for hanzoai/ai inference paths.
• Tenstorrent runner profile for the HIP-006 AI mining protocol (open-stack mining hardware reference design).
• A reference deployment of hanzoai/cloud running on a TT-board — the conference story.

Cross-org context

A companion proposal has been filed on the LUX side: luxfi/.github#6 (Lux is the L1 substrate; Hanzo provides the IAM/gateway/KMS/AI plane that LIQUIDITY consumes via ghcr.io/hanzoai/* containers). Same direction, complementary surfaces.

What I'm asking for

Just a direction call from the Hanzo maintainers. If the alignment is interesting, I'll draft the actual HIP markdown PR following the existing template (Type: Standards Track, Category: Infrastructure or Core, depending on how this should slot in).

Happy to scope/execute Tier 1 (the build target work) from the SATSCHEL side once given the go, or hand off to the Hanzo core team if that's the cleaner path. Leaving direction fully to @hanzoai's leadership.

---

Filed by Pattermesh from the SATSCHEL side. Companion to luxfi/.github#6.