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.
Desacoplamiento total: Karma (Soulbound intransferible para reputación y cuota zero-gas) y (activo líquido de liquidación con DEX AMM nativo).
Quema atómica del 80% en penalizaciones y comisiones comerciales de GARA-G, Shelf y Fi'ze recompradas y quemadas en el AMM.
Nodo nativo en Rust (ADR-009). Cero dependencia de Polygon Amoy ni gas EVM. Trazabilidad inmutable de uso y telemetría.
Blockchain orientada a atestación de telemetría, auditoría de stock y Proof of Useful Work (PoUW). La solvencia proviene del uso real de la Triada Comercial.
Estado Canónico: Red Soberana en Rust (ADR-009)
- • Desacople total de Polygon Amoy: la red opera sobre una App-Chain soberana en Rust (synapse-protocol y cores/edge-mesh).
- • Cero fricción de gas para el usuario final: las transacciones operacionales legítimas se autorizan mediante cuotas de Karma Soulbound.
- • DEX AMM propio en Rust: pools de liquidez internas (x · y = k) para intercambio de por stablecoins sin depender de exchanges centralizados.
- • La blockchain se emplea para trazabilidad inmutable de uso y transparencia (telemetría de flotas GARA-G, inventario Shelf, órdenes Fi'ze y PoUW).
- • La sostenibilidad económica está anclada a la facturación de clientes reales de la Triada Comercial y al mecanismo de quema deflacionaria automática.
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 |
|---|---|---|---|
| Red de Consenso | Polygon Amoy (EVM externa) | Red Soberana en Rust (App-Chain P2P Mesh) | ADR-009 / RED_SOBERANA_RUST_SPEC.md (synapse-protocol y edge-mesh) |
| Modelo de Gas y Fricción | Gas volátil en POL/MATIC por transacción | Zero-Gas Quota respaldada por Karma Soulbound | synapse-core/src/tokenomics/karma.rs (0.1x a 5.0x multiplier) |
| Intercambio de Tokens (DEX) | Dependencia de DEX externo en Polygon | DEX AMM Nativo en Rust (x · y = k) con pools internas | RED_SOBERANA_RUST_SPEC.md — Swap directo sin CEX externos |
| Propósito de la Blockchain | Especulación financiera de tokens | Trazabilidad inmutable de uso, telemetría y PoUW | Auditorías de GARA-G (flotas), Shelf (POS) y Xavier (agentes) |
| Sostenibilidad y Flujo Económico | APY inflacionario insostenible (flag NO ROBUSTA) | 80% de quema deflacionaria y respaldo en facturación de la Triada Comercial | synapse-core/src/tokenomics/reward_engine.rs & ADR-008 |
| Criptografía y Llaves | ECDSA secp256k1 estándar | Post-Cuántica Híbrida (Dilithium3 + Kyber768 + Ed25519) | crates/synapse-immune/src/quantum_wallet.rs |
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, según nuestro seguimiento interno, de 52 características (autoinformado, sin auditar) 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 con aislamiento de datos
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.