Squadleader Dev  /  Work  /  Zohar Token

OPS-004

Zohar Token

The heaviest binding set in our estate behind a single Worker: four caches, three databases, two object stores and a Solana program, holding a complete Aramaic corpus and the wallets entitled to read it.

zohartoken.com Active Deploy Visit the live site →
The Zohar Token home page, showing the Hebrew title and the Book of Splendor introduction
KV namespaces
4
D1 databases
3
R2 buckets
2
Editions
1 + 53

The problem

Putting a sacred text on a blockchain is easy to say and hard to do honestly. The text has to be complete and vocalized, its authenticity has to be verifiable rather than asserted, and ownership has to actually grant something — otherwise the token is a receipt for nothing.

It also has to be legible to people who do not read Aramaic, which means a preamble in English, Spanish and Hebrew that does not misrepresent what the buyer is getting.

What we built

  • A wallet-gated reader. Holding the token is what opens the text — ownership is a key, not a certificate. Sessions, preferences and an access log are kept in separate stores so reading behaviour never mixes with entitlement.
  • Cryptographic authenticity over the corpus, so the text a holder reads can be checked against the text that was minted.
  • Two edition tiers — a Master Edition of the complete work, and fifty-three Ner portions matching the traditional division — with USDC settlement.
  • A multilingual preamble in English, Spanish and Hebrew, so the offer is understood before it is bought.
  • Scheduled reconciliation running every five minutes alongside a daily cycle, keeping on-chain state and reader entitlement in agreement.

What it means

One Worker carries four KV namespaces, three D1 databases and two R2 buckets — the densest thing we run — and it does so on the edge, with no origin server anywhere in the path. A reader in Buenos Aires and a reader in Jerusalem are served from their own continent.

Stack

Workers, D1, KV, R2, Solana, USDC