How LLUMA keeps who you are apart from what you asked.

The whole design serves one sentence: no single participant ever holds both “who you are” and “what you asked.” Identity (your IP, your account) and content (your prompt) are never present together in any one party’s view.

Everything is delivered through a point-and-click desktop application — a Rust core with a Tauri UI — with a Contribute side that turns hosting a model into a one-click action, and a Chat side that sends anonymous requests into the network. A request succeeds only when it completes end-to-end with no party holding both the originator’s IP and the prompt plaintext, and when repeated requests stay unlinkable to each other and to the user.

Parties are honest-but-curious individually and may collude pairwise, with one load-bearing exception noted below. The issuer is trusted for credit integrity but not for anonymity — blindness holds even against a malicious issuer.

LLUMA torrents the model weights, but runs each inference whole-model on a single host. Cross-WAN sharding of one model across peers is out of scope — latency makes it slow and fragile.

Nested encryption: the prompt is sealed end-to-end to the host inside an Oblivious HTTP capsule to the broker. The relay strips the IP; the broker routes on metadata it can read but cannot open the prompt; only the host decrypts it.

1. Buy tokens out of band. The client blinds random nonces and the issuer blind-signs them, debiting the account. The issuer sees only blinded blobs.
2. Seal the prompt. The prompt and a fresh session key are HPKE-sealed to the host, then wrapped in an OHTTP capsule to the broker; one token is attached.
3. Relay strips identity. The relay forwards the capsule and routing metadata to the broker — without the IP it alone saw.
4. Broker verifies and routes. The token is checked with the issuer’s public key; the host is matched by latency, load, and tier. The broker never opens the prompt.
5. Host infers, responds, is credited. The host decrypts, runs inference, and streams a response sealed to the session key. A signed receipt credits the host — never the consumer.

All primitives are IETF-standardized (or Standards-Track drafts) with maintained, reviewed Rust implementations. No novel crypto.

The one place the identified ledger touches anonymous spending is redemption — and it is exactly there that the link is cut.

The issuer’s entire view of a redemption is the account key, the blinded blobs, and the blind signatures. Because RSA blinding is information-theoretically hiding, that transcript is equally consistent with every possible set of resulting tokens. When a token is later spent, no party — not even the issuer colluding with the broker and hosts — can trace it to the redeeming account. The guarantee is enforced by the shape of the API: verification accepts only an issuer public key and a token, so no function can express “consumer account + spendable token” in one place. Residual linkage is only statistical (timing, counts) — see L2 and L4.

You contribute before you consume, tiered to your hardware. Accounting is anonymous by the same mechanism as spending.

Contribution produces signed receipts aggregated into a credit balance, spent by presenting blind tokens — so “who earned” and “who spent” cannot be correlated. Credits are non-transferable and redeemable only for your own inference: no trading, no fiat. Sybil resistance falls out of this — an account is a free keypair, so a fresh account is nearly worthless (a small trial grant only); a credited account requires burning real hosted, seeded, or donated compute. Identity is cheap; credited identity is expensive.

Two tiers, honestly labeled, chosen per request.

A design that names its weaknesses is one you can evaluate. Each row is a place identity↔content could leak, and its mitigation.

This is a design whitepaper. It describes the target architecture; the anonymity network is not deployed yet.

References

$back to overview $top of paper