Arcanum: a privacy-first compiler layer for source code — TEE now, ZK as the long-term foundation

zk-s[nt]arks
1

I want to share a concept I’ve been developing and get feedback from this community specifically — because the people here are exactly who this needs to be stress-tested by.

The core idea: Arcanum is a proposed compiler layer where source code privacy is treated as a first principle. Developers write in the language they already know (C++, Rust, JavaScript, TypeScript, Go — anything LLVM or RISC-V compatible). Arcanum transforms it. Plaintext source never exists post-compilation.

Two-phase approach:

Phase 1 — TEE: Compiled code is wrapped inside hardware-enforced secure enclaves (Intel SGX, AMD SEV, ARM TrustZone). The source logic is unreadable even to the server owner or cloud provider. Near-native performance. Trust assumption: hardware manufacturer.

Phase 2 — ZK: As ZK compiler infrastructure matures, Arcanum transitions to transforming source into STARK-based arithmetic circuits — mathematically unreadable without the original source, no trusted hardware required, post-quantum resistant. Trust assumption: none.

The distinction from existing ZK tooling: zkLLVM, RISC Zero, and SP1 focus on verifiable execution — proving code ran correctly. Arcanum focuses on a different question: can the source code itself be made permanently unreadable, while remaining provably executable? Two different problems, two different architectures.

Honest limitations I’m aware of:

  • Phase 1 places trust in hardware manufacturers (Intel/AMD/ARM)

  • Compiler-level bugs could expose intermediate representations

  • Insider threats (developer leaking source) are out of scope

  • Side-channel attacks are only partially mitigated

    This is a pre-MVP conceptual whitepaper. I’m a non-technical founder — the architecture needs ZK and compiler engineers to pull it apart. That’s exactly why I’m here.

    What am I missing at the cryptographic or compiler level? Is the TEE → ZK transition path realistic, or does it have fundamental blockers I haven’t considered?

Whitepaper & repo: [GitHub]

2

If you mean making the source code unreadable to a zkSTARK verifier – that’s already a zkSTARK feature, nothing else to be done here.

If you mean making the source code unreadable to a zkSTARK prover – that’s impossible, the prover must perform the computation somehow.

3

That’s a really precise and fair distinction — thank you.

You’re right. On the verifier side, ZK already handles this. And on the prover side, you’re correct that someone must execute the computation and therefore “sees” the logic at some level.

This is exactly why the current version of Arcanum proposes TEE (Trusted Execution Environments) as the Phase 1 approach — the prover runs inside a hardware enclave (Intel SGX, AMD SEV) where even the operator of the machine cannot observe the computation. It’s not a cryptographic guarantee, but a hardware-enforced one.

The honest limitation: TEE places trust in the hardware manufacturer. Phase 2 (ZK) would address the verifier side more formally — but you’ve identified the core unsolved problem for the prover side correctly. That’s an open research question.

Does TEE-based execution change your assessment at all?

One follow-up: the layer I’m most interested in is the developer experience side. zkSTARK and TEE both exist as technologies, but neither is transparently integrated into a general-purpose compiler layer where a developer writes normal code and gets source privacy automatically — without learning ZK theory or configuring enclaves manually.

Would you consider that integration layer genuinely novel? Or does something already exist that solves this developer-facing problem?