Economía y tokenomics de $SWAL
El detalle técnico y económico que antes vivía en la portada, ahora en su propia página — con las cifras revisadas para que coincidan con la fuente canónica y el contrato desplegable actual.
10% (10B) en 10 billeteras del laboratorio SWAL (una sola entidad) sin vesting + 50% (50B) al Emission Controller + 40% (40B) quemado en TGE.
Quema atómica del 40% (40B) mediante burnTGE() / executeTGEBurn().
Sin contratos desplegados en Polygon Amoy todavía. Último broadcast conocido: nodo local.
Sin auditoría externa. Resiliencia ante ataques: 89.6/100 (2026-09-13). Sostenibilidad económica: configuración NO ROBUSTA (2026-09-07) — APY de founders, control de precio y de supply en revalidación. Son dos análisis distintos.
Estado honesto: Testnet en preparación
- • No hay contratos desplegados en Polygon Amoy: el último broadcast se ejecutó en un nodo local (eth_getCode vacío en Amoy).
- • La Safe 2-de-3 de gobernanza no está desplegada on-chain.
- • No existe todavía una auditoría externa independiente.
- • Las cifras de este documento describen el diseño vigente, sujeto a revisión.
- • Resiliencia ante ataques (colusión, drenaje de llaves): 89.6/100 — informe del 2026-09-13. Esto es distinto de la sostenibilidad económica.
- • Sostenibilidad económica: la configuración actual está marcada como NO ROBUSTA (veredicto del 2026-09-07 — fallan el APY de founders, el control de caída de precio y el control de supply). Todas las variables económicas se están re-validando con simulaciones reproducibles.
Aviso legal
El diseño económico de $SWAL está en revisión y puede cambiar. Esta página es material informativo y técnico: no constituye una oferta, invitación ni solicitud de inversión, ni una promesa de rendimiento. Cualquier lanzamiento futuro estará sujeto a revisión legal y regulatoria antes de ejecutarse.
Cifras clave: antes → ahora → fuente
| Campo | Antes (portada) | Ahora | Fuente |
|---|---|---|---|
| Suministro génesis | 100B $SWAL | 100B $SWAL (TOTAL_SUPPLY) | SWALToken.sol — coincide con el contrato actual |
| Distribución génesis | 40% Safe multisig + 10% vesting + 10% Xavier ops + 40% quema | 10% (10B) en 10 billeteras propiedad del laboratorio SWAL, sin vesting (Decisión D4) + 50% (50B) a EmissionController (pool) + 40% (40B) quemado en TGE | SWALToken.sol (LAB_SHARE, POOL_SHARE, burnTGE) — en revisión frente al documento canónico |
| Billeteras del laboratorio (10% / 10B) | No especificado | El laboratorio SWAL es UNA sola entidad. Sus 10B $SWAL están en 10 billeteras (1B cada una), a cargo de las distintas sesiones/líneas de investigación internas del laboratorio. Ese fondo está destinado a pagar en el futuro a investigadores y compañías reales que se unan a las investigaciones — no son 10 laboratorios independientes. | SWALToken.sol: LAB_PER_WALLET = LAB_SHARE / LAB_WALLETS = 1B — coincide con el contrato |
| Quema en TGE | 40B (40%) | 40B (40%) vía burnTGE() | SWALToken.sol + simulationData.json — coherente |
| Circulante post-TGE | 60B (60%) | 60B (60% del cap máximo) | simulationData.json initial_circulating — coherente con el génesis del contrato (10B laboratorio + 50B pool) |
| Custodia de gobernanza | Safe 2-de-3 VERIFICADO en Amoy | Safe 2-de-3 diseñada, NO desplegada | Verificación directa: sin bytecode en Amoy para la Safe |
| Red de despliegue | AMOY READY | Testnet en preparación | eth_getCode vacío en Polygon Amoy; el broadcast conocido fue en un nodo local |
| Auditoría externa | Audit-Ready 95% | Sin auditoría externa todavía | No existe reporte de auditoría independiente publicado |
| Resiliencia ante ataques (simulador) | Robustez 100/100 · Solvente | Resiliencia global 89.6/100 frente a 4 escenarios históricos de ataque/estrés. El escenario más débil (choque de demanda 90% estilo Terra/Luna) saca solo 58.5/100; colusión del 30% y drenaje de llaves Safe dan 100/100 cada uno | periferia/swal-sim/reports/HISTORICAL_SCENARIOS_RESILIENCE_REPORT.md (2026-09-13) |
| Sostenibilidad económica (simulador) | No se advertía — se mostraba como "Solvente 100%" sin distinguir de la resiliencia ante ataques | CONFIGURACIÓN NO ROBUSTA: fallan el APY de founders, el control de caída de precio y el control de supply en al menos un escenario. Es un análisis distinto de la resiliencia ante ataques. Todas las variables económicas se están re-validando con simulaciones reproducibles | docs/SWAL/swal-sim/reports/sustainability_verdict.txt (2026-09-07) |
Cuando el documento canónico de tokenomics y el contrato SWALToken.sol difieren (por ejemplo, el tope de pool de venta), esta página muestra lo que coincide entre ambos y marca lo divergente como "en revisión" en vez de inventar una cifra.
La Red, los Avances y el Sistema de Karma
Descripción detallada de la operación de la malla descentralizada entre nodos, el estado formal de 52 características completadas al 100 % y el motor de reputación matemática no especulativa que rige el ecosistema.
¿Qué es la Red SWAL?
DESACOPLAMIENTO TOTAL DE LA NUBESWAL combina cómputo local-first con infraestructura en la nube: la inferencia, el AST y la memoria de cada app corren en el nodo Xavier del usuario o del equipo, mientras que el sitio y algunos servicios de borde se sirven desde Cloudflare. Lo que nunca sale del nodo local son los datos de usuario; a la malla P2P solo llegan hashes de telemetría y consenso, protegidos con criptografía asimétrica Ed25519.
Inferencia, AST y VFS se ejecutan íntegramente en la máquina local, sin coste de gas.
Solo los hashes consolidados de telemetría y consenso se asientan en Polygon PoS.
Ruido calibrado matemáticamente que impide identificar al autor del código analizado.
Topología P2P Mesh y Travesía NAT
Enrutamiento directo entre nodos sin servidores intermedios, direcciones IP públicas estáticas ni puertos abiertos. La red se autodescubre y se autorrepara.
Identidad Soberana Ed25519
Cada nodo, agente o participante posee un par de claves criptográficas generado localmente. No existen usuarios centralizados ni contraseñas en bases de datos.
Capa 0 Zero-Gas Local-First
La inferencia de microexpertos SLM, la compilación de grafos AST y el almacenamiento de memoria se ejecutan íntegramente en el dispositivo del usuario, sin tarifas de gas.
Latido y Telemetría Descentralizada
Pulsos sincronizados de disponibilidad que auditan la presencia del nodo y su capacidad computacional activa, sin exponer datos privados ni código fuente.
Xavier: Memoria RAG, Introspección y Miniexpertos
Xavier sintetiza interacciones, heurísticas de herramientas y grafos AST en datalakes de alta densidad. Antes del entrenamiento, el usuario emplea el módulo de introspección socrática para destilar la causa raíz y validar los datos, posibilitando la creación de modelos ultracompactos (0.5B a 3B) ejecutables en local o en Colab.
Módulo de Introspección Socrática: Afinamiento Preentrenamiento
El LLM actúa como facilitador socrático, mientras el usuario destila el razonamiento fundamental antes de exportar el datalake.
Protocolo de Anonimización Criptográfica
El conjunto de entrenamiento se genera y procesa directamente en la memoria local y la GPU del nodo (Nvidia RTX, Apple Silicon M1-M4 o CPUs modernas). Ningún fragmento de código, ruta o variable abandona la máquina.
$ xavier datacommons export-training-bundle --output ./datalake --seed 42 --eval-ratio 0.15Miniexpertos Bajo Demanda
0.5B a 3BModelos de peso pluma entrenados en tareas hiperespecíficas y afinadas por el usuario. Sin sobrecoste operativo y con respuesta instantánea.
Arquitectura Modular Zero-Leak
Las aplicaciones de usuario final nunca acceden a frases semilla ni manipulan balances directamente. Toda transacción económica fluye mediante contratos inmutables orquestados por el SDK.
Explorador de Sostenibilidad Económica
Dos análisis distintos y reproducidos de forma independiente: resiliencia ante ataques (Gen1b) y sostenibilidad económica del DEX interno (Gen2). Los escenarios de tesoro/quema/staking abajo son un modelo ilustrativo, no una proyección garantizada.
Hiperinflación estilo Terra/Luna, cartel estilo Bittensor, robo de llaves estilo Wormhole/Ronin, agotamiento de gas estilo Helium. No dice nada sobre si el founder pool o el LP APR sobreviven 5 años.
Evalúa la economía del DEX/LP interno de SWALswap (APY de founders, caída de precio, LP APR) bajo 4 escenarios de volumen — no la distribución de génesis de $SWAL, que es independiente de este veredicto.
Los dos veredictos conviven porque responden preguntas distintas (resiliencia a fallas sistémicas vs. sostenibilidad de fees del DEX) — no son contradictorios. Un 89.6/100 en resiliencia no significa que el tokenomics del DEX sea sostenible, y "NO ROBUSTA" en sostenibilidad no significa que la red sea vulnerable a ataques.
Escenario ilustrativo del modelo Gen2 — no es una proyección garantizada de tesoro, quema ni solvencia. Ver los dos veredictos reproducidos arriba y la sección "Cómo validamos cada variable" en Economía.
Ilustrativo — no verificado como solvente
Presión Deflacionaria
Capital Comprometido
Sostenibilidad Matemática
Cómo validamos cada variable
Ninguna decisión de variable económica de $SWAL se toma por afirmación suelta: se valida con un protocolo de simulación reproducible, versionado y con evidencia verificable.
Cada simulación vive en un archivo de parámetros con control de versiones propio, no en supuestos sueltos.
Todo script con aleatoriedad declara su SEED como constante y la imprime en el resultado (ej. seed=42).
Cada CSV/JSON de salida se hashea; el hash se publica junto al resultado para que cualquiera pueda reproducirlo y comparar.
Cada corrida se guarda en Xavier (POST /memory/add, ruta sim/<experimento>/<fecha>) con parámetros, comando, hash y métricas clave.
Un verificador automático falla si la configuración de una simulación diverge del documento canónico de tokenomics.
Ningún ADR (Architecture Decision Record) sobre una variable económica se aprueba sin su propia sección "## Simulación".
Metodología completa: docs/SWAL/SIMULACIONES_REPLICACION_2026-09-24.md
Mecanismo anti-volatilidad (en evaluación)
Cuota de venta progresiva por billetera: máx(cuota fija mínima, % del saldo propio) por época, más un límite global de salida de mercado y agregación de la cuota por identidad (IVN/Karma) — no solo por dirección — para cerrar el exploit de billeteras Sybil fragmentadas.
Está en evaluación por simulación reproducible, sin cifras de precio publicadas aquí: los valores absolutos de precio dependen de supuestos de demanda que no deben citarse fuera de la metodología completa.
Madurez del Ecosistema
Estado cualitativo real de cada capa, no un porcentaje inventado: Especificado → Implementado → Probado localmente → Auditado → Desplegado. Ninguna capa ha llegado hoy a Auditado ni a Desplegado en Amoy.
Contratos Inteligentes Core (Solidity 0.8.24)
- • SWALToken: ERC-20 con limitación dinámica de tasa del 1.5 %/24h.
- • EmissionController: vesting multitramo y presupuesto de emisión por época.
- • TierLockEscrow: custodia de 30B con quórum del 60 % y timelock de 48h.
- • Probado con suites locales de Foundry. Sin auditoría externa ni despliegue en Amoy todavía.
Consenso y Oráculos (ECDSA y Ed25519)
- • Keeper off-chain (`packages/oracle/src/keeper.ts`) y gossip Ed25519 implementados.
- • El diseño trustless on-chain está en KARMA_ORACLE_SPEC (2026-09-20, estado SPEC/PROPOSED) — hoy el flujo real depende de `onlyDistribution` (una sola llave), no de verificación on-chain de firmas del Keeper.
- • Media recortada (10 %) y rechazo de valores atípicos especificados y simulados localmente.
- • Sin auditoría externa ni despliegue en Amoy todavía.
Resistencia Sybil e Integridad (Xavier IVN)
- • Sobre HMAC-SHA256 con comparación en tiempo constante anti-manipulación.
- • Diversidad de subredes IP /24 y topes por operador.
- • Muestreo de entropía VRF determinista para comités, validado con simulación local (periferia/swal-sim/ivn_sim.py).
- • Bóveda HardwareVault con cifrado AES-256-GCM en reposo. Sin auditoría externa todavía.
Simulación y Resistencia de Cartel (Python)
- • Colusión del 30 % (estilo Bittensor/TAO): 100/100, captura de Karma limitada a 0.44 %–14.66 % según el modelo.
- • Drenaje de llaves de Safe (estilo Wormhole/Ronin): 100/100, 0 USD en pérdidas simuladas.
- • Choque de demanda del 90 % estilo Terra/Luna: solo 58.5/100 — el escenario más débil.
- • Puntaje global de resiliencia: 89.6/100, reproducido byte a byte el 2026-09-24 (36/36 PASS, seed 42). Esto es resiliencia ante ataques, no sostenibilidad económica — ver /economia.
Gobernanza Multisig y Transición DAO
Esquema de seguridad de claves y contratos diseñado y documentado. La administración de la tesorería y los parámetros del protocolo se regirá por umbrales matemáticos 2-de-3 antes de la transferencia final a la DAO, una vez se despliegue en testnet real.
Ninguna transferencia ni cambio de parámetro podrá ejecutarse con una sola firma una vez desplegada. Requiere consenso multihardware. Estado actual: en preparación, no desplegada on-chain.
Las claves maestras y semillas se resguardan fuera de línea bajo AES-256-GCM. Los agentes de IA operan exclusivamente con permisos delegados de emisión cero.
Al alcanzar el hito de madurez en Mainnet, la multisig renuncia a la administración delegando el 100 % de la gobernanza a votaciones tokenizadas on-chain.