Whitepaper Técnico v2.3
BlazePhoenix-Dex es un agregador de liquidez on-chain construido sobre una sola afirmación: una cotización y su ejecución son el mismo cálculo. La ruta se deriva dentro de la transacción que la ejecuta, a partir del estado público de las pools, mediante una biblioteca sin estado que cualquier lector puede volver a ejecutar; el número que obliga en la liquidación lo vuelve a derivar el mismo despachador en el marco en ejecución. No hay servicio de enrutamiento, ni oráculo de precios, ni keeper, ni ruta de actualización. Este documento especifica los cinco contratos — Core, Hub, Solver, Router, Quoter — y los operadores de la Meta-Ecuación (Meta-Equation): el Despachador Óctuple Ω (Eightfold Dispatcher Ω), la Derivación Determinista 𝒟 (Deterministic Derivation 𝒟), el suelo de la Ley de Hierro Φ (Iron-Law floor Φ), el Campo de Vitalidad Ψ (Vitality Field Ψ) y el proyector anti-estafa Ξ (anti-scam projector Ξ). Detrás de ellos hay una disciplina, el Diseño Metrológico (Metrological Design): medir toda coordenada que pueda medirse y hacer monótono el resto, de modo que una entrada falsa solo perjudique a quien la suministra. Cada garantía se enuncia con su punto de imposición y su límite. El aparato de verificación se publica con sus denominadores: 1,319 de 1,320 pruebas en verde en el perfil de lanzamiento, 268 de 268 mutantes seleccionados eliminados, 14 de 15 mutantes dirigidos a 43 invariantes con estado detectados, covering arrays de fuerza 2 (63 filas, 258 pares) y 3 (168 filas, 1,636 tripletas), 14 + 5 relaciones metamórficas, tres builds del optimizador de acuerdo, y un estudio de 240 muestras sobre cómo envejece una cotización. Lo que nada de ello establece se enuncia con el mismo cuidado. El código descrito es la V2 y no está desplegado; la generación desplegada es la V1, fijada por codehash para que ambas nunca se confundan.
Estado: qué describe este documento y qué está desplegado
El árbol de la Versión 2 que describe este documento está en el repositorio y no está desplegado; la generación desplegada es la Versión 1, fijada por codehash en cada red para que ambas nunca se confundan. Cada número del documento se mide en main 8949a9d y se publica junto a su denominador; texto íntegro en español en https://blazephoenix.xyz/whitepaper/es.md; el original en inglés, que prevalece, en https://blazephoenix.xyz/whitepaper.md.
§1 El problema: una cotización es una promesa que calculó otro
Imagine vender un coche en una ciudad con veinte concesionarios. Un buen corredor visita los veinte, encuentra el mejor precio y quizá reparte la venta entre dos de ellos. La mayoría de los «corredores» on-chain consultan precios en su propia base de datos — posiblemente desactualizada — y le muestran un resultado. Usted no puede verificar que miraran los veinte, ni que le mostraran el mejor. Solo puede verificar que, hasta aquí, han sido honestos.
§2 La respuesta y la disciplina
BlazePhoenix-Dex tiene un punto de entrada que toma seis valores — los dos tokens, el importe, su mínimo, un destinatario, un plazo — y resuelve la ruta dentro de la transacción que la ejecuta, a partir de las reservas de las pools, que son estado público: qué centros de negociación, cuánto a cada uno, en qué orden. Como la ruta se derivó de estado público mediante código público, cualquiera puede volver a derivarla.
§3 La Meta-Ecuación y el presupuesto de dependencias
Todo el agregador puede leerse como la maximización de una sola expresión. Dados un token de entrada t_in, un token de salida t_out y un importe x, el Solver busca entre las rutas admisibles la que maximiza el valor neto recibido, sujeta a un suelo de viabilidad y a una puerta anti-estafa.
§4 El Despachador Óctuple Ω (Eightfold Dispatcher Ω)
En claro: una función que sabe cotizar cualquier tipo de pool. Con precisión: universalQuote(QuoteCtx, amountIn), en el Core, es el despachador de cotizaciones para el Solver y para la vista previa del Quoter; devuelve la salida esperada y una profundidad denominada en token para el asignador de división (Split Allocator), y una pool que no puede cotizar devuelve cero y se descarta antes de enviar nada.
§5 Uniswap V4 de extremo a extremo
Uniswap V4 no es un nuevo contrato de pool; es una nueva forma de centro de negociación, e invalida cuatro supuestos sobre los que se apoya todo router construido entre 2020 y 2024. Las pools no tienen direcciones — son entradas en el almacenamiento de un singleton, indexadas por un hash. Dentro del swap se ejecuta código arbitrario — un hook corre en puntos definidos de la liquidación que el router está realizando. Las comisiones no tienen por qué ser constantes. Y las pools pueden contener la moneda nativa de la cadena, que no tiene balanceOf. Esta sección responde a las cuatro de forma estructural, para que una pata V4 sea — para el Solver, para los suelos y para el operador — indistinguible de cualquier otra pata.
§6 El solver de Solidly
Algunas invariantes no tienen una forma cerrada lo bastante simple como para reproducirla con seguridad, y reproducirlas es exactamente el riesgo de replicación que el protocolo rechaza en otros puntos. Para esos centros, el despachador pregunta a la pool por el canal honesto más estrecho que el centro expone — y guarda una réplica de reserva para los forks que no responden.
§7 Derivación Determinista 𝒟 (Deterministic Derivation 𝒟)
Antes de poder cotizar una pool hay que encontrarla. La respuesta del sector es preguntar: una llamada a la factory del centro lee un mapping en almacenamiento y devuelve una dirección, y quien llama acepta la palabra de la factory. BlazePhoenix admite esa respuesta — cuatro modos de llamada a factory cubren los centros cuyos despliegues no son reproducibles — y prefiere otra más fuerte siempre que la aritmética lo permite: calcular la dirección, sin llamada externa alguna. Una dirección calculada puede verificarla cualquiera con las mismas tres entradas; una dirección obtenida solo puede creerse.
§8 El Monoslot
El almacenamiento es el coste dominante de hacer cualquier cosa en la EVM: un SLOAD en frío cuesta 2,100 gas, y un registro que dispersara los atributos de una pool en slots separados lo pagaría de nuevo por cada atributo, por cada pool, en cada ruta evaluada. BlazePhoenix empaqueta todo el estado de enrutamiento de una pool en una sola palabra de 256 bits — el Monoslot — leída una vez y decodificada por aritmética pura.
§9 El Registro Autorreparable (Self-Healing Registry) y el Campo de Vitalidad Ψ (Vitality Field Ψ)
La mayoría de los agregadores conocen sus centros porque un keeper indexa pools fuera de la cadena y publica listas en la cadena — un proceso de confianza, una ventana de desactualización y una dependencia operativa, tres cosas que un protocolo que resuelve rutas on-chain no puede aceptar. BlazePhoenix adopta la postura contraria: el registro aprende la liquidez negociándola.
§10 Enrutamiento y el Asignador de División (Split Allocator)
Una pool de producto constante fija precio con una sola regla: sus dos reservas, multiplicadas, nunca pueden encoger. Vierta Δ con retención de comisión γ (una comisión de centro del 0.30 % significa γ = 0.997) y recibe yγΔ / (x + γΔ), con su propia entrada en el denominador: cuanto más empuje por una pool, peor paga cada token adicional. El deslizamiento es aritmética, y su cura también: repartir la misma orden entre pools del mismo par mueve menos cada pool.
§11 La capa de ejecución y el suelo de la Ley de Hierro Φ (Iron-Law floor Φ)
El Solver propone; el Router dispone — atómicamente, o nada en absoluto. El Router es el único contrato que mueve fondos, no retiene ninguno entre transacciones y se apoya en un principio: un mecanismo por cada asunto, aplicado universalmente. No supone nada que pueda medir.
§12 Superficies de cotización, y cómo envejece una cotización
Hay dos lugares de los que puede venir un número llamado «su cotización», y son rutas de código distintas: el Quoter, un contrato de vista previa de solo lectura que una interfaz llama antes de que usted firme, y la vía en marco, donde el Solver y el Router calculan cotizaciones dentro de la transacción en ejecución. El §4.4 dio la verdad por tipo; esta sección da las superficies y mide la distancia entre ellas.
§13 Política de comisiones: los dos regímenes y la Regla del Excedente (Surplus Rule)
En claro: el protocolo cobra 0.28 % una sola vez, sobre un importe medido, en una moneda que la tesorería quiere mantener, y deja constancia de que lo hizo. Con precisión: PROTOCOL_FEE_BPS = 28 es una constante de compilación en el Core sin setter alguno en el bytecode desplegado; la comisión es mulDivUp(base, 28, 10,000) — redondeada hacia arriba, de modo que una comisión nula es inalcanzable para cualquier base no nula — repartida con TREASURY1_SHARE = 3,000 bps a la primera tesorería y el resto a la segunda (calculado como fee − t1, de forma que ambas siempre suman la comisión sin polvo), con las tesorerías fijadas en la construcción y congelables para siempre por la Puerta de Sentido Único (One-Way Door).
§14 Modelo de seguridad
En claro: el Router no retiene nada entre transacciones, cada swap es todo o nada, y cada clase de ataque que este repositorio ha considerado se responde con una comprobación nombrada o se declara fuera de alcance. Con precisión: el catálogo de amenazas es docs/assurance/threats.json, 23 clases tomadas del registro público de exploits; cada una nombra el símbolo de guarda que la rechaza, y un script de CI hace fallar el build si el símbolo sale de src/ o la prueba nombrada sale de test/. La cobertura de un catálogo es un suelo sobre lo que se ha considerado, nunca un techo sobre lo que existe.
§15 El aparato de verificación, medido
En claro: cada número de aquí se publica junto al denominador contra el que se midió, se recalcula desde un checkout limpio mediante un script o un comando forge nombrado (Apéndice C), y va seguido de lo que no establece. Con precisión: el árbol medido es main en 8949a9d y la rama que lo originó, en el perfil de lanzamiento (optimizer_runs = 300, via_ir), 2026-09-05.
§16 Arquitectura y tamaños
En claro: cinco contratos, uno de los cuales es matemática pura importada por los otros cuatro, y ninguna pieza de matemática está definida dos veces. Con precisión: el Core es una biblioteca sin estado, sin almacenamiento, sin propietario y sin ruta de actualización; Hub, Solver, Router y Quoter lo importan y ninguno redefine una primitiva, de modo que una sola auditoría de la matemática cubre a todos los consumidores.
§17 Rendimiento medido
En claro: todo lo de esta sección se midió en forks de cadenas reales — centros reales, reservas reales depositadas por desconocidos, un solo bytecode — y está etiquetado exactamente como eso. Con precisión: un número aparece aquí solo si un harness público del repositorio lo reproduce; el harness, la cadena y la fecha se publican junto a él. Una medición en fork es evidencia sobre el comportamiento, no un registro de despliegue; el registro de despliegue es el §19. Las mediciones del §12 y del §15 son de 2026-09-05; la campaña de esta sección se ejecutó en agosto de 2026 y sus harnesses están en test/fork/.
§18 El DEX, reducido al hueso
Diecisiete secciones de mecanismo, reducidas a una página. Un solo trabajo: recibir dos tokens, una cantidad, tu mínimo, un destinatario y un plazo, y devolver la mayor salida que la liquidez pública de la cadena puede entregar — o rechazar, con un código que dice por qué. Cinco contratos comparten una sola matemática (Core, Hub, Solver, Router, Quoter); seis tipos de venue se cotizan con un solo despachador; cuatro puertas llegan a un solo ejecutor; tres suelos y tu propio mínimo sostienen cada operación; una comisión del 0,28% está compilada y nadie puede moverla.
§19 Estado de despliegue
Este documento documenta el repositorio, y el repositorio es canónico: donde este texto y la fuente discrepen, gana la fuente. Existen dos generaciones y nunca se confunden.
§20 Token — BZPX
Mil millones de BZPX, fijos para siempre, como un ERC-20 simple: 18 decimales, sin ruta de acuñación, sin comisión por transferencia, sin rebasing, sin hooks de transferencia, sin pausa ni lista negra. Asignación en la versión 2.3: liquidez de mercado 520,000,000 (52%), emisión de staking 180,000,000 (18%), Airdrop y Bounties 130,000,000 (13% — el antiguo airdrop de 50,000,000, el antiguo fondo de investigación de 50,000,000 y 30,000,000 sacados de la liquidez de mercado), equipo 103,000,000 (10.3%), socios 60,000,000 (6%), marketing 7,000,000 (0.7%).
§21 Programa de investigación y registro de seguridad
Antes de que este proyecto tuviera un programa de investigación digno de ese nombre, investigadores independientes leyeron la fuente de forma hostil — sin que se les pidiera, sin nada prometido — y divulgaron en privado lo que vieron. El código que describe este documento es el código que sobrevivió a esa lectura. Lo que cada uno reportó, y en qué acabó, vive donde deben vivir esos registros: en SECURITY.md y SECURITY_HALL_OF_FAME.md del repositorio, junto al código, donde cada entrada puede comprobarse en ambos sentidos. Esta sección registra quiénes son, cuánto paga la lectura hostil y la forma de lo que encontró.
§22 En qué debe confiar y en qué no hace falta
Todo protocolo se declara sin confianza; casi ninguno sabe enumerar sus excepciones. Aquí está la lista completa, con cada poder enunciado junto a la línea que lo acota.
§23 Trabajo relacionado
Enrutamiento. Angeris, Evans, Chitra y Boyd plantean el enrutamiento entre creadores de mercado de función constante como un programa convexo cuyo óptimo iguala los precios marginales entre centros; Diamandis, Resnick, Chitra y Angeris aportan un algoritmo eficiente de descomposición dual para resolverlo.
§24 Conclusión
Nos propusimos construir un agregador sobre una sola disciplina — medir, no creer — y sostenerla en cada punto donde un número podría, en cambio, haberse aceptado bajo la palabra de alguien: la ruta, el precio, el suelo, la base de la comisión, el conjunto de centros, el par que una pool dice negociar, e incluso el propio modelo de costes del protocolo.
Questions, a partnership or a bug to report? Contact us or email contact@blazephoenix.xyz