BEYUL Whitepaper — Pre-Testnet Edition: Arquitectura y modelo de divulgación

Esto es una traducción. La versión en inglés es la versión canónica (canonical) y prevalece en caso de conflicto. Los identificadores técnicos (BEYUL, BYL, privacychain, TDC, ADC, nullifier, commitment, viewing key, shielded pool, Groth16, etc.) permanecen sin traducir, en inglés.

Proyecto: BEYUL　Tipo: prototipo de investigación de una cadena pública con privacidad (pre-testnet). El trabajo de protocolo de BEYUL se desarrolla actualmente en el repositorio privacychain. Estado del documento: whitepaper de BEYUL, edición pre-testnet (de investigación) — describe la arquitectura del protocolo, el modelo de divulgación y los límites actuales antes del testnet público. No es una especificación de protocolo de producción, ni un documento de inversión, ni una opinión de cumplimiento, ni una auditoría de seguridad, ni material de emisión de tokens, ni un anuncio de mainnet. Las afirmaciones de capacidad siguen la disciplina de evidencia de §3.1; nada aquí se describe por encima de su madurez real. Estado del token: la tokenómica no es definitiva. BYL es solo la forma corta / el ticker del proyecto; no es una denominación congelada — la denominación y los parámetros de la cadena siguen pendientes de la aprobación explícita del Owner. Este documento no define asignación de tokens ni diseño de utilidad. Los tokens de testnet, si se usan, no tienen valor monetario ni conversión prometida a mainnet. Idioma canónico: la versión en inglés es la única versión canónica. La versión en chino (beyul-whitepaper-pretestnet.zh.md) es un texto de trabajo acompañante; en caso de conflicto, prevalece esta versión en inglés.

Caja de límites de afirmaciones (léase primero)

Este documento no hace ninguna de las siguientes afirmaciones:

• Ninguna afirmación de anonimato, no rastreabilidad o "seguridad absoluta";
• Ninguna afirmación de seguridad zero-knowledge de producción (la implementación actual usa material de development-key);
• Ninguna afirmación de privacidad de producción (los montos de depósito y retiro son actualmente públicos on-chain);
• Ninguna afirmación de aprobación regulatoria o "compliance by design";
• El diseño actual no incluye una viewing key global controlada por el proyecto; esta propiedad debe verificarse mediante implementación abierta, pruebas y auditoría externa;
• No existen testnet público ni mainnet; la preparación del testnet está en curso — el runbook multinodo y los gates relacionados aún no están completos;
• Ninguna promesa de valor del token, airdrops, rendimiento, retornos o listados en exchanges; este documento no trata productos de wallet ni DeFi;
• El 16-character disclosure code no es una credencial criptográfica de seguridad subyacente (Sección 7).

Nomenclatura e identificadores técnicos. BEYUL es el nombre del proyecto/producto; el trabajo de protocolo de BEYUL se desarrolla actualmente en el repositorio privacychain. privacychain sigue siendo el identificador técnico actual — repositorio, paquete de protocolo/módulo/proto, binario y chain-id — y se conserva sin cambios. BYL es la forma corta / el ticker; la denominación y los parámetros de la cadena siguen pendientes de la aprobación explícita del Owner, por lo que BYL no es una denominación congelada. Esta disciplina de nomenclatura es solo prospectiva: los documentos históricos no se renombran retroactivamente.

1. Resumen

BEYUL es un proyecto de cadena pública con privacidad en etapa de prototipo de investigación (pre-testnet) que explora infraestructura de pagos con privacidad por defecto (un objetivo de diseño) y divulgación controlada por el usuario. En el diseño objetivo, los detalles de la transacción no son públicamente visibles por defecto, pero el propietario del activo puede divulgar voluntariamente, con alcance acotado, a una parte elegida — un Transaction Disclosure Code (TDC) explica una sola transacción; un Asset Disclosure Code (ADC) divulga una instantánea de activos seleccionada. "Privacidad por defecto" describe el objetivo de diseño, no el prototipo actual (véase §5).

Lo que existe hoy es únicamente un prototipo de derivación de disclosure-code del lado del cliente (probado localmente; el paquete de evidencia pública está pendiente de consolidación) y un prototipo de chain-application basado en Cosmos SDK. Los grants del lado del servidor de extremo a extremo, la verificación on-chain y las ZK balance proofs no están implementados; no hay trusted setup, ni auditoría externa, ni testnet público ni mainnet; los montos de depósito y retiro son actualmente públicos on-chain. El propósito de este whitepaper (edición pre-testnet) es registrar con exactitud la dirección arquitectónica, el modelo de divulgación y los límites actuales antes del lanzamiento del testnet público — y ser reemplazado por una edición de producción solo cuando exista la evidencia y las auditorías correspondientes.

2. Posicionamiento y problema

Los ledgers públicos exponen relaciones de pago, saldos y flujos de fondos ante cualquier observador; mientras tanto, la mayoría de los sistemas de fuerte privacidad hacen que la divulgación selectiva sea operativamente difícil — explicar una transacción a una parte a menudo significa entregar la capacidad de ver todo. La brecha que BEYUL explora: hacer de la "divulgación" un primitivo de primera clase a la par del "ocultamiento", con toda divulgación iniciada por el usuario.

BEYUL no compite por — ni apunta a — una narrativa de "totalmente anónimo, no rastreable".

Visión. La privacidad financiera en los ledgers públicos está invertida: desnuda por defecto, mientras que el ocultamiento mismo parece sospechoso. El objetivo de BEYUL es invertir ese defecto — la privacidad como estado predeterminado, y la divulgación como elección deliberada y granular del usuario: qué transacción, qué campos, a quién y por cuánto tiempo.

Principios de diseño. Cada parte del protocolo se somete a estos:

1. La divulgación es un ciudadano de primera clase — los primitivos de divulgación se diseñan y prototipan al mismo rango que los primitivos de ocultamiento.
2. Mínima autoridad — cada clave y credencial porta solo la autoridad mínima que su propósito requiere.
3. La spend authority es sacrosanta — ningún flujo de divulgación puede tocar la spend authority; la mnemónica nunca entra en ningún paso de divulgación.
4. Sin privilegio global — el protocolo está diseñado para no proporcionar ningún canal de visualización global al proyecto ni a terceros; la ausencia de cualquier rama de ese tipo es una propiedad de diseño a verificar mediante implementación abierta, pruebas y auditoría externa (§6), aún no una garantía.
5. Honestidad de límites — cada capacidad declara lo que no hace; el threat model y las limitaciones se mantienen públicos.
6. Evidencia primero — las afirmaciones de capacidad se elevan solo después de que existe evidencia (código, pruebas, auditorías) — basado en gates, sin promesas de fecha.

2.1 Cómo se compara la divulgación de BEYUL

La tabla compara el diseño objetivo de BEYUL con las capacidades actuales y entregadas de otros sistemas. Los diferenciadores de BEYUL abajo (caducidad, revocación, visibilidad impuesta por consenso, alcance por-transacción/por-instantánea con verificación de servidor y on-chain) son en gran parte planeados o prototipo del lado del cliente (véase §3, §7), aún no entregados. Los hechos de los competidores se exponen de forma conservadora; los puntos no reverificados de forma independiente para este whitepaper se marcan con 【to verify】.

El diferenciador previsto no es "ocultar más fuerte" sino divulgación más granular, acotada en el tiempo y emitida por el usuario: donde una viewing key de Zcash/Monero es una concesión de lectura a nivel de cuenta, todo-o-nada e indefinida, una credencial de divulgación de BEYUL está acotada a una transacción (TDC) o una instantánea de activo (ADC), porta una caducidad y está diseñada para ser revocable — con el conjunto de campos visibles impuesto por el consenso en lugar de por una convención de wallet. Estas propiedades son objetivos de diseño; su estado de implementación se rastrea honestamente en §3 y §7.

Fuentes. Zcash/Monero: el informe de investigación profunda ZEC/XMR de este proyecto (fuentes primarias — Zcash Protocol Specification; documentación de Monero; a fecha de 2026-06-12). Las filas de Penumbra / Aztec / Namada describen la documentación oficial de cada proyecto a fecha de 2026-06 (Penumbra: protocol.penumbra.zone — viewing keys, FMD; Aztec: docs.aztec.network — keys, note discovery; Namada: docs.namada.net — shielded accounts). Los puntos 【to verify】 restantes — caducidad/revocación y semántica de transaction-perspective de Penumbra, caducidad/revocación nativa de Aztec, semántica precisa de revocación de Namada — quedan pendientes de confirmación. Estas filas exponen lo que describe la documentación de cada proyecto, no afirmaciones sobre lo que otros sistemas "no pueden hacer".

3. Estado actual

3.1 Cadena de evidencia

Cada fila "prototipo implementado" arriba está vinculada a un registro de evidencia — no afirmada en prosa. La cadena de evidencia (commit hash, registro de CI, comando de prueba y salida exactos, instrucciones de ejecución reproducibles) se lleva en el Evidence Appendix, y cada capacidad se califica en una escala de madurez de investigación L0–L5 (diseño → prototipo → reproducible → revisado → evidencia de red → producción). Este whitepaper referencia ese registro en lugar de reexponer la evidencia cruda.

Autoevaluación actual: la mayoría del material está en L1–L2, nada en L5. Hasta que las entradas del Evidence Appendix se completen (commit/CI), los materiales públicos dicen "verificado localmente; paquete de evidencia pública pendiente de consolidación", no "implementado con evidencia pública". Una capacidad sin registro de evidencia registrado no puede describirse por encima de su nivel de madurez. El Evidence Appendix se encuentra en docs/evidence-appendix.md (interno; se publicará con el paquete de evidencia pública); E1/E3/E4 se reprodujeron en solo lectura el 2026-06-19, con la vinculación de CI aún pendiente.

4. Modelo técnico

El prototipo se centra en una máquina de estados de shielded pool. Para un no-criptógrafo, el ciclo de vida de un saldo privado transcurre así:

1. Note. Un saldo gastable es una note — un registro de (propietario, monto, aleatoriedad). La note en sí nunca aparece on-chain.
2. Commitment. La cadena almacena solo un commitment sobre la note (un hash de enlace unidireccional), añadido a un Merkle commitment tree de solo-anexión. Del commitment por sí solo, un observador no aprende ni propietario ni monto.
3. Spend → nullifier. Para gastar una note, el propietario publica un nullifier derivado de ella. El nullifier está diseñado para no ser vinculable al commitment por observadores externos (bajo una suposición PRF de nullifier-key; yellow paper §7.1), pero es determinista para esa note — de modo que la misma note solo puede nulificarse una vez.
4. Rechazo de double-spend. La cadena mantiene un conjunto de nullifiers; un nullifier repetido se rechaza. Esto previene los double-spends sin revelar qué note se gastó.
5. Prueba de validez. Un spend porta una prueba zero-knowledge de que "poseo una note cuyo commitment está en el árbol y derivé su nullifier correctamente", sin revelar ninguno de esos valores. La verificación va por una ruta Groth16.

El verificador actual usa material de verifying-key development/skeleton sin trusted setup y no establece soundness ni privacidad de producción. Formulación externa estándar: "El prototipo incluye una ruta de verificación Groth16 de development-key. Aún no proporciona seguridad zero-knowledge de producción." Para las definiciones formales del formato de note, esquema de commitment, derivación de nullifier y semántica del árbol, véase el yellow paper §§5–7 y §10.

4.1 Por qué una cadena independiente y por qué Cosmos

El modelo de divulgación necesita control sobre cosas que un despliegue de smart-contract en una L1 compartida, o un rollup genérico, no otorgan limpiamente:

• La visibilidad de divulgación impuesta por consenso (§6) y las reglas de integridad de suministro del shielded pool deben residir en la capa de transición de estado / consenso, no dentro de un contrato cuyos validadores de la cadena anfitriona y mercado de comisiones están fuera del control del proyecto.
• El estado shielded nativo (commitment tree, conjunto de nullifiers, contabilidad de value-balance) es más barato y auditable como estado de cadena de primera clase que como almacenamiento de contrato, y evita que el modelo de mempool público y metadatos de la cadena anfitriona filtre más de lo previsto.
• Un conjunto de validadores bonded-PoS permite que la integridad de suministro sea reverificada por cada full node y da finalidad instantánea adecuada para pagos.

Cosmos SDK + CometBFT se elige por un stack BFT-PoS maduro con módulos de staking/slashing, governance soberana de upgrades y finalidad instantánea — no como respaldo de ningún modelo de token (ninguno es definitivo). Esto es una justificación de selección de arquitectura, no una afirmación de que la cadena independiente esté desplegada; para el estado real véase §3 y §8.

4.2 Características de rendimiento

Se mantienen separados dos tipos de cifras. Inherentes (a nivel de esquema, citables): Groth16 sobre la curva BN254 tiene proofs de tamaño constante (tres elementos de grupo: 2×G1 + 1×G2, ~128 B comprimido / ~256 B sin comprimir en BN254) y verificación en tiempo constante (un número fijo y pequeño de comprobaciones de pairing, independiente del tamaño del circuito). Esto se sigue del propio sistema de pruebas, no de la implementación de BEYUL. A nivel de sistema (aún no medidas): el tiempo de prueba, el rendimiento de transacciones (TPS) y el tamaño del circuito (número de constraints) dependen del circuito de producción, que no está construido — la ruta actual usa un verifying key dev/skeleton (§4). Por tanto, cualquier cifra de ese tipo es un target / 【to be supplied】, a medir cuando existan el circuito de producción y una ruta de trusted-setup-o-prueba-transparente (Roadmap §10, Fase 6). Por encima de esta línea no se afirma ninguna cifra de rendimiento a nivel de sistema.

5. Modelo de privacidad y límites actuales

El prototipo actual no es privacidad de producción.

En pre-testnet / bajo uso, el anonymity-set es pequeño o vacío; sin usuarios reales, la privacidad dentro del pool no queda establecida de forma significativa — la privacidad fuerte depende de un anonymity-set grande y activo, y NO se afirma hasta que exista uso real. El ordenamiento/MEV de la capa de validadores y los metadatos de red siguen sin mitigar.

Un marco formal de anonymity-set (cómo se define y acota el anonymity-set del shielded pool) se mantiene en el yellow paper (§15); esta sección declara los objetivos de privacidad y los límites actuales, no ese modelo formal.

6. Modelo de claves y divulgación

De mayor a menor autoridad: Spend Key (única autoridad de gasto; nunca abandona el dispositivo del usuario; nunca participa en flujos de divulgación) → Full View Key (solo lectura; separación entrante/saliente planeada) → Audit Key (planeado: emitida voluntariamente por el usuario; limitada en tiempo, acotada, revocable; no es un canal impuesto por el protocolo) → Disclosure Credential (la unidad mínima de divulgación, vinculada a una transacción o una instantánea de activo) → 16-character disclosure code (código corto de entrada; no es una clave).

Límite de autoridad de visualización del proyecto: el diseño actual no incluye una master viewing key controlada por el proyecto. Esta propiedad debe verificarse mediante implementación abierta, pruebas y auditoría externa en lugar de confiar en el equipo — las rutas de derivación de claves se entregan como open source, y cualquier tercero puede auditar el grafo de derivación para verificar la ausencia de cualquier rama que conduzca al proyecto. Hasta que se complete la auditoría externa, esto es una "propiedad de diseño a verificar", no una garantía.

Política de mnemónica (planeación de arquitectura, no un producto entregado): la clave raíz de la wallet usa por defecto una mnemónica de 24 palabras (BIP39), con claves derivadas mediante separación de dominio (HKDF + domain tags). La mnemónica nunca debe aparecer en ningún flujo de divulgación; ni los disclosure codes ni el link_secret pueden derivarse solo de la mnemónica — los grants TDC/ADC se generan en el momento de la divulgación voluntaria usando un CSPRNG y autorización local.

Límite de visibilidad de divulgación (requisito de diseño): el alcance visible de una credencial de divulgación — incluida la visibilidad de la dirección saliente — está planeado para ser garantizado por reglas de la capa de consenso en lugar de por convención de implementación de la wallet (una lección de la industria de Zcash, donde la visibilidad saliente depende de una convención de wallet); este requisito llega con el stack de verificación on-chain (roadmap Fase 5) y no está implementado hoy.

Capa de Disclosure Grant (pendiente de revisión independiente): la capa de Disclosure Grant — alcance, caducidad, revocación, registro de auditoría y permisos de viewer — está pendiente de una revisión independiente de producto y de seguridad. Hasta que esa revisión se complete, no se puede confiar en ninguna de estas propiedades de límite, y ningún documento puede dar a entender que estén establecidas.

7. Prototipo de divulgación TDC / ADC

7.1 Terminología y codificación

El término oficial es el "16-character Crockford Base32 disclosure code" (el alfabeto excluye los caracteres confundibles I/L/O/U; ~80 bits de entropía de código corto), abreviado "16-character disclosure code". No se usan formulaciones como "16-digit code" o "16-digit security code" — un esquema solo numérico (~53 bits) se descartó por presupuesto de entropía insuficiente.

"El 16-character disclosure code no es una credencial criptográfica de seguridad subyacente. Es un punto de entrada de acceso amigable para el usuario; la autorización real debe protegerse conjuntamente mediante una disclosure credential de alta entropía, firmas, restricciones de alcance, caducidad y lógica de verificación."

7.2 Estado actual real (lectura obligatoria)

Lo que BEYUL tiene es un prototipo de derivación TDC/ADC del lado del cliente probado localmente. Los grants de servidor de extremo a extremo, la verificación de estado de cadena y las ZK balance proofs están planeados y no implementados. Por tanto, NO debe afirmarse que: la divulgación verificable está implementada; los fondos ya pueden probarse; el ADC puede probar saldos exactos; o los disclosure codes pueden verificarse on-chain.

El prototipo del cliente cubre (probado localmente): KEK de dos factores (link_secret + código de 16 caracteres, ambos requeridos); codificación canónica; vinculación de rol emisor/receptor de TDC; separación de dominio TDC/ADC (ninguno puede abrir al otro); AEAD envelopes con protección anti-manipulación AAD (envelope TDC/ADC del lado del cliente; el AAD del envelope on-chain MsgDiscloseNote sigue siendo un target — yellow paper §2.3); un verificador de código slow-hash (suite objetivo Argon2id; adaptador de producción aún no conectado); crypto-shredding de erasure key.

7.3 Semántica de TDC y ADC

El trilema de la divulgación: un sistema de propiedad oculta no puede prometer simultáneamente completitud del saldo, sin fuga de historial y sin viewing key — un usuario puede probar la propiedad de notes seleccionadas pero, sin una fuente de completitud adicional, no puede probar que no se omitió nada. Por ello el ADC es escalonado, y un ADC divulga exactamente el saldo del conjunto de activos seleccionado a la altura seleccionada — no debe describirse como "no revela saldo".

Riesgos del ADC (mantenidos públicos): instantáneas repetidas a la misma parte revelan cambios de saldo en el tiempo; la exposición del patrimonio neto es un riesgo de seguridad física y coerción (el ADC está desactivado por defecto y requiere confirmación explícita); la rotación no puede retractar lo que un observador ya ha visto.

7.4 FAQ del disclosure code

8. Plan de testnet (foco actual)

8.1 Modelo de validador

El testnet usa un modelo de validador BFT estilo PoS: Cosmos SDK + CometBFT, un conjunto inicial de validadores y flujos de prueba del módulo de staking. No es PoW, y no es seguridad económica PoS de nivel mainnet — el modelo económico de mainnet es investigación de largo plazo fuera del alcance de este whitepaper.

8.2 Preparación del testnet (declarado con claridad)

La preparación del testnet está en curso: el runbook multinodo y los gates relacionados aún no están completos (los pull requests pertinentes no están todos fusionados y los checks no pasan). Hasta que esos gates cierren y la evidencia se registre, este proyecto no usa lenguaje "testnet-ready".

Checklist previo al lanzamiento: paquete de evidencia cerrado; chain-id y genesis del testnet; guía de onboarding de validadores; runbook multinodo de 3+ nodos; política de faucet y rate-limiting; política de RPC/API pública; dashboard de monitoreo; proceso de respuesta a incidentes; lista de limitaciones conocidas; flujo de comandos del participante; aviso de "token de testnet sin valor".

8.3 Qué puede validar el testnet / qué no puede probar

Puede validar: operación de nodos y producción de bloques, flujos del módulo de staking, faucet, RPC, monitoreo y respuesta a incidentes, el flujo de demo del disclosure-code, el flujo de prototipo del shielded module. No puede probar: privacidad de producción, seguridad económica PoS de mainnet, valor del token, aceptación regulatoria, soundness ZK de producción. El lanzamiento del testnet no debe comercializarse como "validación de producción".

8.4 Aviso al participante

Los tokens de testnet no tienen valor monetario ni conversión prometida a mainnet; no hay wallet oficial — participa solo con tooling de línea de comandos y documentación publicados oficialmente; ningún flujo requiere jamás que tu mnemónica entre en un paso de divulgación — cualquiera "oficial" que pida tu mnemónica es un estafador; actualmente no hay ninguna venta de tokens, ronda privada, whitelist ni registro de airdrop.

8.5 Governance, upgrades y límite económico

En esta etapa pre-testnet BEYUL no tiene governance descentralizada. Los upgrades del protocolo y los pins críticos de seguridad — parámetros de genesis y el verifying key fijado (pinned) — están controlados por el conjunto inicial de validadores junto con el Owner. Este es un modelo de confianza centralizado, declarado con claridad; se descentralizará progresivamente solo a medida que la red y su governance maduren (sin DAO, sin cronograma de descentralización prometido). Operar un validador no confiere por sí mismo autoridad de upgrade; el pinned VK y el genesis se cambian solo mediante la ruta de upgrade "conjunto de validadores + Owner".

Límite económico. La denominación, el suministro y los parámetros económicos son decisiones del Owner — con gate, y no definidas en este whitepaper (véase Estado del token, arriba). Nada aquí fija una denominación, un suministro o un modelo token-económico.

9. Threat Model (público hasta su mitigación)

Organizado por clase de adversario, alineado con el modelo de adversario del yellow paper (A1–A4). Este es un resumen; el yellow paper es la referencia autoritativa del threat model, y los dos documentos no deben divergir — donde difieran, prevalece el yellow paper.

• A1 — Observador pasivo de la cadena (lee solo datos públicos de la cadena): correlación de montos en depósitos/retiros públicos, correlación de timing, canales laterales de fees/gas — no mitigado. Commitments, nullifiers, anchors y la cuenta de flujo neto del pool son públicos por diseño.
• A2 — Adversario de red / infraestructura (mempool, RPC, ordenamiento de validadores, IP): observación de mempool, ordenamiento y censura de validadores, metadatos de capa de red — no mitigado (ordenamiento/censura parcialmente fuera del alcance del protocolo); metadatos de exchange/bridge fuera del protocolo — fuera de alcance.
• A3 — Adversario del lado de la divulgación (un receptor de divulgación o alguien que posee un código): el reenvío de una divulgación por un receptor es criptográficamente incontrolable; la revocación no está implementada; exposición de series temporales y patrimonio neto de ADC en instantáneas repetidas; emisión coaccionada — declarado con claridad, no mitigado.
• A4 — Adversario de endpoint / social (el dispositivo del usuario, phishing): phishing e ingeniería social por mnemónicas o códigos, wallets falsas y canales oficiales falsos — no mitigado; abordado mediante educación del usuario y la lista de canales oficiales.

Transversal, sin resolver: bugs de circuito, trusted setup, auditoría externa — no verificado / no resuelto / no completado. La integridad de suministro del pool (la puerta G-S) está abierta; la conservación y el double-spend no se afirman como propiedades de producción, pendientes de value-balance in-circuit y de keeper con consistencia de ancho 128↔64 bits (espejo del yellow paper §12.3). La confusión sobre el valor de tokens de testnet y recompensas no está permitida — los tokens de prueba no tienen valor y cualquier contabilidad de recompensas es simulada.

10. Roadmap (basado en gates, sin promesas de fecha)

Cada capacidad debe estar exactamente en un estado: Implemented / Local tested / Prototype / Documentation only / Planned / Unverified / Not implemented. Ninguna afirmación puede escribirse como "implementada" sin commit, registro de CI, comando de prueba y salida.

El orden no es reversible: testnet → TDC MVP → ADC_L1 → verificación root-bound → production ZK → ADC_L2 → auditoría → pre-mainnet.

11. Límite de cumplimiento

BEYUL no es una solución de cumplimiento: no implementa flujos de AML, KYC, travel-rule, congelamiento, screening de sanciones ni reporte, y no afirma ser "compliant by design". Toda divulgación es iniciada por el usuario; el protocolo no tiene canal de divulgación forzada; el diseño actual no incluye una viewing key global controlada por el proyecto (a verificar mediante implementación abierta y auditoría). Las instituciones e individuos deben evaluar de forma independiente la postura regulatoria de su jurisdicción frente a los activos de privacidad.

12. Declaración de riesgo y descargo de responsabilidad

Este documento tiene fines informativos únicamente y no constituye, ni debe interpretarse como: una oferta o venta de un valor, materia prima o instrumento financiero; asesoramiento de inversión, legal, fiscal o financiero; o una declaración de cumplimiento en ninguna jurisdicción. Contiene declaraciones prospectivas (objetivos de diseño, planes de testnet, roadmap) sujetas a incertidumbre material; los resultados reales pueden diferir materialmente.

Este proyecto actualmente no tiene token emitido; los tokens de testnet, si se usan, no tienen valor monetario. Participar en redes de cripto-activos implica riesgos materiales. Haz tu propia investigación y consulta a asesores profesionales. Donde cualquier traducción entre en conflicto con esta versión canónica en inglés, prevalece esta versión en inglés. Este descargo es una plantilla genérica y debe ser revisado por asesoría legal en la jurisdicción correspondiente antes de cualquier publicación pública formal.

13. Conclusión

La dirección de BEYUL es privacidad por defecto con divulgación controlada por el usuario. Sus activos creíbles hoy: un prototipo de chain-application, un prototipo de derivación TDC/ADC del lado del cliente probado localmente, y una tabla de estado y un threat model mantenidos estrictamente alineados con la implementación. El único foco actual son los requisitos previos para el lanzamiento del testnet público: cierre de evidencia, el runbook multinodo, faucet y monitoreo, y documentación del participante. Hasta que exista la evidencia correspondiente, este proyecto no hace afirmaciones de mainnet, token, privacidad de producción o cumplimiento.