Squadleader Dev / Proyectos / Zohar Token
Zohar Token
El conjunto de bindings más pesado de nuestro parque detrás de un solo Worker: cuatro cachés, tres bases de datos, dos almacenes de objetos y un programa de Solana, sosteniendo un corpus arameo completo y las billeteras con derecho a leerlo.
El problema
Poner un texto sagrado en una blockchain es fácil de decir y difícil de hacer con honestidad. El texto tiene que estar completo y vocalizado, su autenticidad tiene que ser verificable y no simplemente afirmada, y la propiedad tiene que otorgar algo real — de lo contrario el token es un recibo de nada.
También tiene que ser legible para quien no lee arameo, lo que exige un preámbulo en inglés, español y hebreo que no tergiverse lo que el comprador está recibiendo.
Qué construimos
- Un lector con acceso por billetera. Tener el token es lo que abre el texto — la propiedad es una llave, no un certificado. Sesiones, preferencias y registro de acceso viven en almacenes separados, para que el comportamiento de lectura nunca se mezcle con el derecho de acceso.
- Autenticidad criptográfica sobre el corpus, de modo que el texto que lee quien lo posee pueda contrastarse con el texto que fue acuñado.
- Dos niveles de edición — una Edición Maestra de la obra completa y cincuenta y tres porciones Ner según la división tradicional — con liquidación en USDC.
- Un preámbulo multilingüe en inglés, español y hebreo, para que la oferta se entienda antes de comprarse.
- Reconciliación programada cada cinco minutos junto a un ciclo diario, manteniendo de acuerdo el estado on-chain y el derecho de lectura.
Qué significa
Un solo Worker sostiene cuatro espacios KV, tres bases D1 y dos buckets R2 — lo más denso que operamos — y lo hace en el edge, sin servidor de origen en ningún punto del camino. Un lector en Buenos Aires y un lector en Jerusalén se sirven cada uno desde su propio continente.
Stack
Workers, D1, KV, R2, Solana, USDC