TECHNICAL WHITEPAPER

Metriplex Protocol
Order from chaosOrden desde el caos

Version 2.4 May 31, 2026 Last updated: May 31, 2026 NTellezM (Nelson Tellez) CC BY 4.0

Abstract ABSTRACT Metriplex is a Layer 1 blockchain that replaces elliptic curve cryptography with fractal geometry as the foundation for cryptographic identity. Each account is represented by a unique strange attractor derived from a private Iterated Function System (IFS) in ℝ⁴. Transaction validity is proven through a composite geometric criterion (c1–c8) evaluated against this attractor, making forgery equivalent to solving the Inverse IFS Problem (IIFSP) — a problem conjectured to be computationally hard in the average case and structurally resistant to Shor's quantum algorithm. A working implementation with a live ERC-20 token on Base mainnet is available at github.com/NTellezM/Metriplex.Metriplex es una blockchain Layer 1 que reemplaza la criptografía de curva elíptica con geometría fractal como base para la identidad criptográfica. Cada cuenta está representada por un atractor extraño único derivado de un Sistema de Funciones Iteradas (IFS) privado en ℝ⁴. La validez de las transacciones se prueba mediante un criterio geométrico compuesto (c1–c8) evaluado contra este atractor, haciendo que la falsificación sea equivalente a resolver el Problema IFS Inverso (IIFSP) — un problema conjeturado como computacionalmente difícil en el caso promedio y estructuralmente resistente al algoritmo cuántico de Shor. Una implementación funcional con token ERC-20 en vivo en Base mainnet está disponible en github.com/NTellezM/Metriplex.

1.The Identity Problem in Traditional BlockchainsEl Problema de Identidad en Blockchains Tradicionales

In Bitcoin, Ethereum, and most existing blockchains, account identity is derived from elliptic curve cryptography (ECDSA or EdDSA). A private key is a 256-bit random integer; the public key is a point on an elliptic curve; the address is a hash of that point.En Bitcoin, Ethereum y la mayoría de las blockchains existentes, la identidad de cuenta se deriva de la criptografía de curva elíptica (ECDSA o EdDSA). Una clave privada es un entero aleatorio de 256 bits; la clave pública es un punto en una curva elíptica; la dirección es un hash de ese punto.

This system has three fundamental limitations:Este sistema tiene tres limitaciones fundamentales:

1. Dimensional poverty Identity is a 1-dimensional object (a number). Two accounts cannot be distinguished geometrically — only numerically. 2. Quantum vulnerability Shor's algorithm breaks ECDSA in polynomial time on a sufficiently large quantum computer. 3. No structural binding The private key has no mathematical relationship to the space in which transactions operate.1. Pobreza dimensional La identidad es un objeto 1-dimensional (un número). Dos cuentas no pueden distinguirse geométricamente — solo numéricamente. 2. Vulnerabilidad cuántica El algoritmo de Shor rompe ECDSA en tiempo polinomial en una computadora cuántica suficientemente grande. 3. Sin vinculación estructural La clave privada no tiene relación matemática con el espacio en que operan las transacciones.

Metriplex addresses all three by grounding identity in the geometry of fractal attractors — objects with no known group structure exploitable by quantum period-finding, intrinsically bound to the algebraic parameters that define them.Metriplex aborda las tres fundamentando la identidad en la geometría de atractores fractales — objetos sin estructura de grupo conocida explotable por la búsqueda de períodos cuántica, intrínsecamente ligados a los parámetros algebraicos que los definen.

2.Fractal IdentityIdentidad Fractal

2.1 The IFS Private Key

A Metriplex private key is a set of n affine contractions in ℝ^d:Una clave privada Metriplex es un conjunto de n contracciones afines en ℝ^d:

K_{\text{priv}} = \{\,(A_i,\, b_i)\,\}_{i=1}^{n}$$ $$A_i \in \mathbb{R}^{d \times d},\quad \rho(A_i) \in [0.30,\, 0.70] \quad \text{(spectral radius)}$$ $$b_i \in \mathbb{R}^d \quad \text{(translation vector)}$$ $$\det(A_i) > 0 \quad \text{(orientation-preserving, R1)}$$ $$\|\varphi_{3,\text{ref}}\| > \varepsilon_{\text{sym}} \quad \text{(minimum asymmetry, R2)}$$ $$n \leq \left\lfloor\frac{d+2}{2}\right\rfloor \cdot \left\lfloor\frac{d+1}{2}\right\rfloor \cdot \left\lfloor\frac{d}{2}\right\rfloor \Big/ 3 \quad \text{(Kruskal bound)}

For the production parameters (n=4, d=4), these conditions guarantee a unique strange attractor μ_Q — the invariant measure of the system, whose existence follows from Banach's fixed-point theorem applied to the Hutchinson operator.Para los parámetros de producción (n=4, d=4), estas condiciones garantizan un atractor extraño único μ_Q — la medida invariante del sistema, cuya existencia se deriva del teorema del punto fijo de Banach aplicado al operador de Hutchinson.

2.2 The M₃ Public Key

The public key is the third-order moment tensor of the attractor:La clave pública es el tensor de momento de tercer orden del atractor:

M_3 = \mathbb{E}_{\mu}\!\left[(x - \hat{\mu}) \otimes (x - \hat{\mu}) \otimes (x - \hat{\mu})\right]

Dimensions: 4×4×4 = 64 elements · Encoding: float64 → 512 bytes · Algorithm: chaos game (50,000 iter, 300 burn-in, pᵢ = 1/n)

The Kruskal-Comon theorem guarantees that M₃ uniquely identifies the IFS under generic conditions — no two distinct IFS systems in the constrained parameter space can produce identical moment tensors.El teorema de Kruskal-Comon garantiza que M₃ identifica unívocamente el IFS bajo condiciones genéricas — no hay dos sistemas IFS distintos en el espacio de parámetros restringido que puedan producir tensores de momento idénticos.

2.3 Security Reduction

The security of the scheme reduces to the hardness of the Inverse IFS Problem (IIFSP): given M₃, find {(Aᵢ, bᵢ)} that produces it.La seguridad del esquema se reduce a la dureza del Problema IFS Inverso (IIFSP): dado M₃, encontrar {(Aᵢ, bᵢ)} que lo produce.

\text{IIFSP} \leq_p \text{Tensor-Decomp-Sym}

Tensor-Decomp-Sym is NP-hard in the worst case (Hillar & Lim, 2013, Journal of the ACM 60(6)).

Quantum resistance argument: Shor's algorithm exploits the periodic group structure of ℤ/nℤ via Quantum Fourier Transform. The map IFS → M₃ is not a group homomorphism and has no known periodic structure. Period-finding has no entry point. This is a structural argument, not a formal proof.Argumento de resistencia cuántica: El algoritmo de Shor explota la estructura de grupo periódico de ℤ/nℤ mediante la Transformada de Fourier Cuántica. El mapa IFS → M₃ no es un homomorfismo de grupo y no tiene estructura periódica conocida. La búsqueda de períodos no tiene punto de entrada. Este es un argumento estructural, no una prueba formal.

⚠ Open problem: Average-case hardness of IIFSP has not been formally proven. A formal proof would constitute a significant cryptographic result.⚠ Problema abierto: La dureza en el caso promedio del IIFSP no ha sido formalmente probada. Una prueba formal constituiría un resultado criptográfico significativo.

2.4 Mathematical Background

The construction rests on three independent mathematical results:La construcción se basa en tres resultados matemáticos independientes:

2.4.1 Hutchinson Operator and Fixed-Point Theorem

Given an IFS W = {wᵢ}ᵢ₌₁ⁿ of contractive maps on a complete metric space (ℝᵈ, ‖·‖), the Hutchinson operator is defined as:Dado un IFS W = {wᵢ}ᵢ₌₁ⁿ de mapas contractivos en un espacio métrico completo (ℝᵈ, ‖·‖), el operador de Hutchinson se define como:

H(S) = \bigcup_{i} w_i(S) \quad \text{for } S \subseteq \mathbb{R}^d

By Banach's fixed-point theorem, H has a unique fixed point A* in the space of compact non-empty subsets of ℝᵈ (equipped with the Hausdorff metric). This attractor A* satisfies H(A*) = A*, and the chaos game algorithm converges to it with probability 1 under the invariant measure μ_W.Por el teorema del punto fijo de Banach, H tiene un único punto fijo A* en el espacio de subconjuntos compactos no vacíos de ℝᵈ (dotado de la métrica de Hausdorff). Este atractor satisface H(A*) = A*, y el algoritmo del chaos game converge a él con probabilidad 1 bajo la medida invariante μ_W.

2.4.2 Kruskal-Comon Uniqueness

The public key M₃ is the third-order cumulant tensor of μ_W. The Kruskal-Comon theorem states that a symmetric tensor T ∈ ℝᵈ⊗ᵈ⊗ᵈ has a unique symmetric rank decomposition when:La clave pública M₃ es el tensor de cumulante de tercer orden de μ_W. El teorema de Kruskal-Comon establece que un tensor simétrico T ∈ ℝᵈ⊗ᵈ⊗ᵈ tiene una descomposición de rango simétrico única cuando:

\text{rank}(T) \leq \left\lfloor\frac{d+2}{2}\right\rfloor \cdot \left\lfloor\frac{d+1}{2}\right\rfloor \cdot \left\lfloor\frac{d}{2}\right\rfloor \Big/ 3$$ $$\text{For } d=4:\quad \text{bound} = \frac{3 \cdot 2 \cdot 2}{3} = 4 \;\checkmark\; \text{(matches } n=4 \text{ maps)}

This guarantees that M₃ is an injective function of the IFS parameters under generic conditions — the map W → M₃(μ_W) is generically one-to-one. Two distinct IFS systems in the constrained parameter space produce distinct moment tensors with probability 1 over the parameter space.Esto garantiza que M₃ es una función inyectiva de los parámetros IFS bajo condiciones genéricas — el mapa W → M₃(μ_W) es genéricamente uno a uno. Dos sistemas IFS distintos en el espacio de parámetros restringido producen tensores de momento distintos con probabilidad 1.

2.4.3 Hausdorff Dimension and Entropy

Each attractor carries two geometric invariants that function as identity metrics:Cada atractor porta dos invariantes geométricos que funcionan como métricas de identidad:

\dim_H(A^*) = \frac{\log n}{\log(1/\bar{\rho})}, \qquad \bar{\rho} = \left(\prod_i \rho(A_i)\right)^{1/n}$$ $$h(\mu_W) = -\sum_i p_i \log p_i - \sum_i p_i \log \rho(A_i), \qquad p_i = \tfrac{1}{n}

For the production parameters (n=4, d=4, ρ ∈ [0.30, 0.70]), Hausdorff dimensions range continuously in [1.02, 1.89] — providing a geometric fingerprint unique to each private key.Para los parámetros de producción (n=4, d=4, ρ ∈ [0.30, 0.70]), las dimensiones de Hausdorff varían continuamente en [1.02, 1.89] — proporcionando una huella geométrica única para cada clave privada.

2.4.4 Parameter Space and Key Entropy

$$w_i = (A_i, b_i): \quad A_i \in \mathbb{R}^{4 \times 4}\;\text{(16 params)},\quad b_i \in \mathbb{R}^4\;\text{(4 params)}$$ $$\text{Total: } 20 \times 4 = 80 \text{ real parameters} \quad \Rightarrow \quad |\mathcal{K}| \approx 2^{512} \approx 10^{154}$$ $$\text{RSA-2048: } 2^{2048} \qquad \text{ECC-256: } 2^{256}$$ Clarification: The key space of 2512 represents the measure-theoretic entropy of the parameter space in ℝ80 — a continuous space with positive Lebesgue measure — not a discrete enumeration. The comparison with ECC and RSA is conceptually valid but structurally distinct: an adversary does not iterate over 2512 integers but over a continuous manifold in ℝ80.Aclaración: El espacio de claves 2512 representa la entropía medida de Lebesgue del espacio de parámetros en ℝ80 — un espacio continuo con medida positiva — no una enumeración discreta. La comparación con ECC y RSA es conceptualmente válida pero estructuralmente distinta: un adversario no itera sobre 2512 enteros sino sobre una variedad continua en ℝ80.

2.5 Key Generation — Step by Step

// 1. Sample IFS parameters for i in 1..n: Aᵢ ← random 4×4 matrix, scale until ρ(Aᵢ) ∈ [0.30, 0.70] bᵢ ← random vector in ℝ⁴ assert det(Aᵢ) > 0 // R1: orientation-preserving // 2. Verify asymmetry constraint assert ‖φ₃_ref‖ > ε_sym // R2: minimum asymmetry // 3. Run chaos game → attractor sample x ← random point in ℝ⁴ for t in 1..300: x ← wᵢ(x) where i ~ Uniform(1..n) // burn-in for t in 1..50000: x ← wᵢ(x); record x // pᵢ = 1/n uniform // 4. Compute M₃ — third-order moment tensor μ̂ ← mean of recorded points M₃[a,b,c] ← E[(xₐ−μ̂ₐ)(x_b−μ̂_b)(x_c−μ̂_c)] // 64 elements, float64 // 5. Derive address address ← sha256(M₃.bytes)[:20] // 20-byte fractal address K_priv = { (Aᵢ, bᵢ) } // keep secret — 80 float64 parameters K_pub = M₃ // publish — 512 bytes

2.6 Tensor Glyph — The Public Key Made Visible

The M₃ tensor is a 4×4×4 array of 64 float64 values encoding the third-order geometry of the attractor. Unlike a 256-bit integer, M₃ has intrinsic visual structure that can be rendered as a 2D identity image.El tensor M₃ es un arreglo de 4×4×4 = 64 valores float64 que codifica la geometría de tercer orden del atractor. A diferencia de un entero de 256 bits, M₃ tiene estructura visual intrínseca que puede renderizarse como imagen de identidad 2D.

The Tensor Glyph is the canonical visual representation of a Metriplex identity. Each pixel is computed by bilinear interpolation of three M₃ slices projected onto a continuous color field:El Glifo Tensor es la representación visual canónica de una identidad Metriplex. Cada píxel se calcula mediante interpolación bilineal de tres cortes de M₃ proyectados sobre un campo de color continuo:

For each pixel (px, py) in canvas of size S: gx = (px/S) × 4, gy = (py/S) × 4 ← map to grid coords [0,4) r = bilinear(M₃[i][j][0], gx, gy) ← k=0 slice → R channel g = bilinear(M₃[i][j][1], gx, gy) ← k=1 slice → G channel b = bilinear(M₃[i][j][2], gx, gy) ← k=2 slice → B channel R = r×125 + b×42 ← cyan/purple blend G = r×212 + g×174 + b×20 B = r×248 + (1−r)×250×g

PropertyPropiedad	DescriptionDescripción
DeterministicDeterminista	Same M₃ always produces the same imageEl mismo M₃ siempre produce la misma imagen
UniqueÚnico	By Kruskal-Comon theorem, no two valid IFS produce identical M₃ — no two Tensor Glyphs are identicalPor el teorema de Kruskal-Comon, no hay dos IFS válidos que produzcan M₃ idéntico — no hay dos Glifos Tensor idénticos
Non-reversibleNo reversible	The image cannot be used to reconstruct M₃ or the private IFSLa imagen no puede usarse para reconstruir M₃ ni el IFS privado
PublicPública	Derived entirely from the public key — reveals no information about the private IFSDerivada íntegramente de la clave pública — no revela información sobre el IFS privado
ContinuousContinua	Bilinear interpolation produces smooth gradients reflecting attractor geometryLa interpolación bilineal produce gradientes suaves que reflejan la geometría del atractor

The Tensor Glyph replaces the conventional QR code in the Metriplex wallet. It is implemented in the browser wallet and Chrome extension as the visual avatar of each fractal identity. This is, to the authors’ knowledge, the first instance of a cryptographic public key rendered as a continuous color field derived directly from its mathematical structure.El Glifo Tensor reemplaza el código QR convencional en la wallet Metriplex. Está implementado en la wallet del navegador y la extensión Chrome como avatar visual de cada identidad fractal. Este es, a conocimiento de los autores, el primer caso de una clave pública criptográfica renderizada como campo de color continuo derivado directamente de su estructura matemática.

2.6.1 Holographic Glyph — Identity Verification Layer

As of May 26, 2026, the Tensor Glyph is rendered as a Holographic Glyph — a deterministic fractal visualization with an embedded steganographic layer encoding the validator's m3_hash. The rendering uses a seeded PRNG (LCG seeded by the hash of the IFS parameters) ensuring pixel-perfect reproducibility across all clients.Desde el 26 de mayo de 2026, el Glifo Tensor se renderiza como un Glifo Holográfico — una visualización fractal determinista con una capa esteganográfica embebida que codifica el m3_hash del validador. El renderizado usa un PRNG sembrado (LCG sembrado por el hash de los parámetros IFS) garantizando reproducibilidad píxel a píxel en todos los clientes.

The holographic layer consists of three components:La capa holográfica consta de tres componentes:

Fractal attractorAtractor fractal — 8,000 IFS iterations rendered in three depth layers (outer glow, mid glow, bright core) using canvas shadowBlur for visual depth8.000 iteraciones IFS renderizadas en tres capas de profundidad (resplandor externo, medio y núcleo brillante) usando canvas shadowBlur
Steganographic gridCuadrícula esteganográfica — an 8×6 grid of 48 bits encoding the first 48 bits of the m3_hash as bright purple dots (bit=1) or empty cells (bit=0)una cuadrícula de 8×6 = 48 bits que codifica los primeros 48 bits del m3_hash como puntos morados brillantes (bit=1) o celdas vacías (bit=0)
Calibration markersMarcadores de calibración — three corner squares enabling future camera-based scanning and perspective correctiontres cuadrados en las esquinas que permitirán escaneo por cámara y corrección de perspectiva

Property — Deterministic Visual Identity: The same m3_hash always produces the same Holographic Glyph, pixel-perfect, on any client. The glyph is scannable: given a captured image, the 8×6 grid can be decoded to recover the first 48 bits of the m3_hash, which is sufficient to identify the validator in the FVR. Full camera-based scanning with perspective correction is a Phase 3 milestone.Propiedad — Identidad Visual Determinista: El mismo m3_hash siempre produce el mismo Glifo Holográfico, píxel a píxel, en cualquier cliente. El glifo es escaneable: dada una imagen capturada, la cuadrícula 8×6 puede decodificarse para recuperar los primeros 48 bits del m3_hash, suficiente para identificar al validador en el FVR. El escaneo completo por cámara con corrección de perspectiva es un hito de la Fase 3.

3.The Composite ZK Criterion (c1–c8)El Criterio ZK Compuesto (c1–c8)

Every transaction includes a zero-knowledge proof that the prover controls an IFS whose attractor satisfies 7 active geometric criteria simultaneously. The criteria are calibrated during key generation and published as public parameters.Cada transacción incluye una prueba de conocimiento cero que demuestra que el probador controla un IFS cuyo atractor satisface 7 criterios geométricos activos simultáneamente. Los criterios se calibran durante la generación de claves y se publican como parámetros públicos.

c1 — Δ_AS

Auto-similarity

‖φ̂ − Σᵢ pᵢ φ̄(fᵢ(pos))‖² < θ_IFS

c2 — Var

Anti-concentration

Var(φ̂) > σ²_min

c3 — Frac

Fragment completeness

N_act / N > 0.50

c4 — [RESERVED v3]

Skewness of φ̂

bit 3 = 0 (reserved)

c5 — Skew

Asymmetry fingerprint

‖φ₃(μ̂) − φ₃_ref‖ < τ

c6 — Disp

Pair dispersion

μ₂(d_pairs) > d²_min

c7 — Inv

Mean invariance

ε_μ < θ_μ

c8 — Ratio

Min/mean ratio

P₅/μ(d_pairs) > thresh

Empirical soundness: In a preliminary evaluation, 0 out of 9 adversarial attack strategies passed all 7 active criteria simultaneously. The 9 categories tested: (1) random IFS with valid spectral radius, (2) cloned M₃ with perturbed IFS, (3) gradient descent on c1 only, (4) exhaustive search in low-dimensional subspace, (5) replay of valid proofs with modified amount, (6) linear interpolation between two valid keystores, (7) criterion stripping (6/7 satisfied), (8) statistical mimicry of attractor moments, (9) deterministic chaos game with fixed seed. Formal soundness probability remains an open problem (Q2).Solidez empírica: En una evaluación preliminar, 0 de 9 estrategias de ataque adversarial pasaron los 7 criterios activos simultáneamente. Las 9 categorías evaluadas: (1) IFS aleatorio con radio espectral válido, (2) M₃ clonado con IFS perturbado, (3) descenso de gradiente solo sobre c1, (4) búsqueda exhaustiva en subespacio de baja dimensión, (5) repetición de pruebas válidas con monto modificado, (6) interpolación lineal entre dos keystores válidos, (7) eliminación de criterios (6/7 satisfechos), (8) mimetismo estadístico de momentos del atractor, (9) chaos game determinista con semilla fija. La probabilidad formal de solidez sigue siendo un problema abierto (Q2).

On c4 (RESERVED): Criterion c4 was removed in protocol v3 due to structural correlation with c5 under the constrained parameter space. The bit is reserved at position 3 for backward compatibility with v2 — always zero in v3+. External implementers should treat this bit as a version flag.Sobre c4 (RESERVADO): El criterio c4 fue eliminado en el protocolo v3 por correlación estructural con c5 en el espacio de parámetros restringido. El bit se reserva en la posición 3 para compatibilidad con v2 — siempre cero en v3+. Los implementadores externos deben tratar este bit como un indicador de versión.

Packed bit field encoding

4.ConsensusConsenso

4.1 Lyapunov Consensus — Active as of May 25, 2026 Consenso de Lyapunov — Activo desde el 25 de Mayo de 2026

Metriplex uses Lyapunov Consensus — the first blockchain consensus mechanism where the leader is selected by geometric proximity in the parameter space of a dynamical system, not by hash or stake.Metriplex utiliza el Consenso de Lyapunov — el primer mecanismo de consenso blockchain donde el líder se selecciona por proximidad geométrica en el espacio de parámetros de un sistema dinámico, no por hash ni por stake.

Lyapunov Invariant

$$\lambda(\mathcal{W}) = \frac{1}{n}\sum_{i=1}^{n} \log \rho(A_i) \quad\text{where}\quad \rho(A_i) = \max|\text{eigenvalue}(A_i)|$$

Epoch Target

$$\lambda_E = \lambda_{\min} + (\lambda_{\max} - \lambda_{\min}) \cdot \frac{H(h_E)}{2^{256}}$$

Leader Election

$$L_E = \underset{v \in \mathcal{V}}{\arg\min}\; |\lambda(\mathcal{W}_v) - \lambda_E|$$

[λ_min, λ_max] = [log 0.30, log 0.70] ≈ [−1.204, −0.357] Block time: 60 seconds Verification: O(n), n = 4 maps — O(1) in protocol parameters Liveness: argmin always defined for |V| ≥ 1

The core insight: each validator's IFS contraction matrices {A₁,…,A₄} define a unique Lyapunov exponent λ(W) — the mean contraction rate of the system. The epoch selects a target λ_E pseudorandomly from the anchor block hash. The validator whose geometry is closest wins the slot.La idea central: las matrices de contracción IFS de cada validador {A₁,…,A₄} definen un exponente de Lyapunov único λ(W) — la tasa de contracción media del sistema. El epoch selecciona un objetivo λ_E pseudoaleatoriamente del hash del bloque ancla. El validador cuya geometría esté más cercana gana el slot.

Why this is not a lottery: The cost of participation is not per-slot — it is paid once at registration by solving IIFSP: given a target λ_E, construct {Aᵢ} such that λ(W) ≈ λ_E. This is structurally equivalent to the Inverse IFS Problem. The analogy to PoS: stake has an acquisition cost; here the cost is geometric, not financial.Por qué esto no es una lotería: El costo de participación no es por slot — se paga una vez al registrarse resolviendo el IIFSP: dado un objetivo λ_E, construir {Aᵢ} tal que λ(W) ≈ λ_E. Esto es estructuralmente equivalente al Problema IFS Inverso. La analogía con PoS: el stake tiene un costo de adquisición financiero; aquí el costo es geométrico.

Property 1 — Voronoi Distribution: Let V = {v₁,…,vₙ} be the active validator set with Lyapunov invariants λ₁,…,λₙ ∈ [λ_min, λ_max]. The expected fraction of slots assigned to validator vᵢ is |Rᵢ| / (λ_max − λ_min), where Rᵢ = {x : |x − λᵢ| < |x − λⱼ| ∀j≠i} is its Voronoi cell.

Corollary: A validator maximizes its expected participation by maximizing its geometric distance to all other validators. The constraint d_min guarantees minimum participation (1/N_target) for every registered validator. The distribution is unequal by design — this inequality is the incentive mechanism that drives geometric diversity.Propiedad 1 — Distribución de Voronoi: Sea V = {v₁,…,vₙ} el conjunto activo de validadores con invariantes de Lyapunov λ₁,…,λₙ ∈ [λ_min, λ_max]. La fracción esperada de slots asignada al validador vᵢ es |Rᵢ| / (λ_max − λ_min), donde Rᵢ = {x : |x − λᵢ| < |x − λⱼ| ∀j≠i} es su celda de Voronoi.

Corolario: Un validador maximiza su participación esperada maximizando su distancia geométrica a todos los demás. La restricción d_min garantiza participación mínima (1/N_target) para cada validador registrado. La distribución es desigual por diseño — esta desigualdad es el mecanismo de incentivo que impulsa la diversidad geométrica.

4.2 Geometric Diversity Constraint Restricción de Diversidad Geométrica

New validators must register contraction matrices with λ values sufficiently distant from existing validators:Los nuevos validadores deben registrar matrices de contracción con valores λ suficientemente distantes de los validadores existentes:

Geometric Diversity Constraint (Definition 5)

$$\min_{v \in \mathcal{V}}\; |\lambda(\mathcal{W}_{\text{new}}) - \lambda(\mathcal{W}_v)| \geq d_{\min} = \frac{\lambda_{\max} - \lambda_{\min}}{N_{\text{target}}}$$

$N_{\text{target}} = 200 \Rightarrow d_{\min} \approx 0.00424$

This prevents geometric clustering and ensures that the epoch target finds a well-distributed validator set. The three genesis validators — with λ values within a 0.013 interval of a 0.847 range (1.6% coverage) — empirically motivated this constraint.Esto previene el agrupamiento geométrico y garantiza que el objetivo del epoch encuentre un conjunto de validadores bien distribuido. Los tres validadores génesis — con valores λ dentro de un intervalo de 0.013 en un rango de 0.847 (1.6% de cobertura) — motivaron empíricamente esta restricción.

4.3 Liveness Guarantee Garantía de Vivacidad

Theorem 2 — Liveness

For $|\mathcal{V}| \geq 1$ validators with $\lambda(\mathcal{W}_v) \in [\lambda_{\min}, \lambda_{\max}]$, the Lyapunov Consensus mechanism guarantees a leader in every epoch.

Proof: $L_E = \arg\min_v |\lambda(\mathcal{W}_v) - \lambda_E|$ always exists for finite non-empty $\mathcal{V}$. Since $[\lambda_{\min}, \lambda_{\max}]$ is compact and $\mathcal{V}$ is finite, the minimum is always achieved. $\square$

Fork resolution uses the longest-chain rule. Full BFT finality (Fractal BFT) is a Phase 3 milestone. See Section 8.La resolución de forks usa la regla de cadena más larga. La finalidad BFT completa (BFT Fractal) es un hito de la Fase 3. Ver Sección 8.

5.Cross-Chain BridgePuente Cross-Chain

The Ethereum bridge uses a lock-and-mint / burn-and-release architecture operated by relayer.py:

Native → Ethereum (Base mainnet)Nativo → Ethereum (Base mainnet)

1. User sends MPX to the Vault address (special IFS account) 2. User includes target_eth_address in the transaction payload 3. Relayer detects TX via polling (/blocks?limit=100) 4. Relayer converts: amount_wei = amount_raw × 10¹⁸ ÷ 2³⁰ 5. Relayer calls mint(to, amount_wei) on ERC-20 contract1. El usuario envía MPX a la dirección del Vault (cuenta IFS especial) 2. El usuario incluye target_eth_address en el payload de la transacción 3. El relayer detecta la TX vía polling (/blocks?limit=100) 4. El relayer convierte: amount_wei = amount_raw × 10¹⁸ ÷ 2³⁰ 5. El relayer llama mint(to, amount_wei) en el contrato ERC-20

Scale conversion: L1 native uses CAF_SCALE = 2³⁰ = 1,073,741,824 — ERC-20 Base uses 18 decimal places.
Native→ERC-20: amount_wei = amount_raw × 10¹⁸ ÷ 2³⁰
ERC-20→Native: amount_raw = amount_wei × 2³⁰ ÷ 10¹⁸Conversión de escala: La cadena nativa L1 usa CAF_SCALE = 2³⁰ = 1,073,741,824 — ERC-20 en Base usa 18 decimales.
Nativo→ERC-20: amount_wei = amount_raw × 10¹⁸ ÷ 2³⁰
ERC-20→Nativo: amount_raw = amount_wei × 2³⁰ ÷ 10¹⁸

Ethereum → NativeEthereum → Nativo

1. User calls burnForNative(amount, nativeRecipient) nativeRecipient = JSON serialization of user's M₃ tensor 2. Contract emits BridgeBurn event 3. Relayer detects event and submits ZK-signed release TX1. El usuario llama burnForNative(amount, nativeRecipient) nativeRecipient = serialización JSON del tensor M₃ del usuario 2. El contrato emite el evento BridgeBurn 3. El relayer detecta el evento y envía TX de liberación firmada con ZK

Gas cost note: The nativeRecipient field serializes M₃ as JSON — approximately 2–4 KB of calldata. At Base mainnet rates (~0.001 gwei), this adds roughly $0.01–0.05 per bridge operation, negligible relative to the transfer amount. A compact binary encoding (512 raw bytes) is planned for protocol v4 to reduce this further.Nota sobre costo de gas: El campo nativeRecipient serializa M₃ como JSON — aproximadamente 2–4 KB de calldata. A las tarifas de Base mainnet (~0.001 gwei), esto añade aproximadamente $0.01–0.05 por operación de bridge, insignificante frente al monto transferido. Se planea una codificación binaria compacta (512 bytes) para el protocolo v4.

Live contract on Base mainnet:
0x22D3f414438556d1B071cCfE52513d4d829400fd

Full bidirectional cycle — May 30, 2026Ciclo bidireccional completo — 30 Mayo 2026

StepPaso	TX hash	AmountMonto
ERC-20 burn (Base)	0xd23078fc15d938f7...	5 MPX
Native release (L1)	63b3920e3e58fb0c...	5 MPX
Native transfer (L1)	ad866d73a5235063...	5 MPX
ERC-20 mint (Base)	0x9f553b7c660443a6...	5 MPX
Balance verified	+5.0000 MPX ERC-20 — 1:1 parity ✓

6.Token EconomicsEconomía del Token

ParameterParámetro	ValueValor
Max supplySuministro máx.	21,000,000 MPX — fixed forever21.000.000 MPX — fijo para siempre
NetworkRed	Base (Ethereum L2)
ExchangeExchange	Uniswap V4 (ETH/MPX, 1%)
DistributionDistribución	40% Uniswap liquidity / 60% Founder + development40% liquidez Uniswap / 60% Fundador + desarrollo
Block rewardRecompensa por bloque	Fractal emission — R₀ × e^−αn × \|R_v\|/Λ (converges to 21M total)Emisión fractal — R₀ × e^−αn × \|R_v\|/Λ (converge a 21M total)
Native TX feeComisión TX nativa	1 MPX per transaction (to block validator)1 MPX por transacción (al validador del bloque)
Bridge feeComisión del puente	1 MPX per cross-chain transfer (native side)1 MPX por transferencia cross-chain (lado nativo)
Private saleVenta privada	NoneNinguna
VestingVesting	NoneNinguno

6.1 Convergent Emission Model6.1 Modelo de Emisión Convergente

Block rewards follow an exponential decay whose total supply ceiling is not a fixed number — it is a function of the geometric diversity of the active validator set. The more geometrically diverse the validators, the larger the network's monetary capacity. Convergence is guaranteed by IFS stability, not by an arbitrary cap.Las recompensas por bloque siguen un decaimiento exponencial cuyo techo total de supply no es un número fijo — es una función de la diversidad geométrica del conjunto de validadores activos. Cuanto más diversos geométricamente, mayor la capacidad monetaria de la red. La convergencia está garantizada por la estabilidad del IFS, no por un cap arbitrario.

Base emissionEmisión base

$$ ext{reward}(n) = R_0 \cdot e^{-lpha n} \cdot rac{|R_v|}{\Lambda_{ ext{range}}}$$

ParameterParámetro	ValueValor	DescriptionDescripción
T_scale	7,059,101 blocks (13.4 years)	Fixed calibration constant — anchors current supply to ~21MConstante de calibración fija — ancla el supply actual a ~21M
λ_mean	(1/\|V\|) × Σ λ(Wᵥ) [dynamic]	Mean Lyapunov exponent of active validators — recalculated each epochExponente de Lyapunov medio de validadores activos — recalculado cada epoch
R₀	\|λ_mean\| / T_scale [dynamic]	Initial reward per block — function of current validator geometryRecompensa inicial por bloque — función de la geometría actual de validadores
\|R_v\|	Voronoi cell size in λ-space	Validator's geometric territory in [λ_min, λ_max]Territorio geométrico del validador en [λ_min, λ_max]
Supply(∞)	R₀ × T_scale / \|λ_mean\|	Total supply ceiling — function of validator geometric diversityTecho total del supply — función de la diversidad geométrica de validadores

Convergent supplySupply convergente

$$ ext{Supply}(\infty) = rac{R_0 \cdot T_{ ext{scale}}}{|\lambda_{ ext{mean}}|}$$

λ_mean	ScenarioEscenario	Supply ceilingTecho de supply
−0.357	1 validator (minimum diversity)1 validador (diversidad mínima)	12.1M MPX
−0.619	Current state (3 validators) ←Estado actual (3 validadores) ←	21.0M MPX
−0.700	4–5 validators, good diversity4–5 validadores, buena diversidad	23.8M MPX
−0.850	6–8 validators, high diversity6–8 validadores, alta diversidad	28.9M MPX
−1.000	Maximum practical diversityMáxima diversidad práctica	34.0M MPX
−1.204	All validators at λ_minTodos los validadores en λ_min	40.9M MPX

Voronoi distribution — live from block 15034:
node-0 (λ=−0.4702, ~28% territory) → 0.480 MPX/block
node-2 (λ=−0.6993, ~45% territory) → 1.109 MPX/block
NT-laptop (λ=−0.6860, ~8% territory) → 0.248 MPX/block
node-3 (λ=−0.8144, ~19% territory) → new validator · June 3, 2026
node-2 (λ=−0.6993, 60.3% territory) → 1.109 MPX/block
NT-laptop (λ=−0.6860, 13.5% territory) → 0.248 MPX/block

Dual incentive: validators maximize reward by maximizing geometric distance to others — which simultaneously increases their Voronoi territory AND pushes λ_mean toward more negative values, expanding the network's total supply ceiling. Security, diversity, and monetary capacity are aligned by the same geometric objective. Distribución Voronoi — en vivo desde bloque 15034:
node-0 (λ=−0.4702, ~28% territorio) → 0.480 MPX/bloque
node-2 (λ=−0.6993, ~45% territorio) → 1.109 MPX/bloque
NT-laptop (λ=−0.6860, ~8% territorio) → 0.248 MPX/bloque
node-3 (λ=−0.8144, ~19% territorio) → nuevo validador · 3 junio 2026
node-2 (λ=−0.6993, 60.3% territorio) → 1.109 MPX/bloque
NT-laptop (λ=−0.6860, 13.5% territorio) → 0.248 MPX/bloque

Incentivo dual: los validadores maximizan su recompensa maximizando la distancia geométrica a los demás — lo que simultáneamente aumenta su territorio Voronoi Y empuja λ_mean hacia valores más negativos, expandiendo el techo total del supply de la red. Seguridad, diversidad y capacidad monetaria están alineadas por el mismo objetivo geométrico.

ERC-20 relationship evolution: The current ERC-20 cap of 21M reflects the supply ceiling at current validator geometry (λ_mean = −0.619, 3 validators). As the validator set grows and diversifies, the L1 supply ceiling naturally exceeds 21M — at which point the 1:1 bridge relationship evolves to reflect the L1/ERC-20 ratio. The ERC-20 is a liquidity access layer; the L1 native token is the canonical asset. Post-emission (Phase 3+), validators earn exclusively from TX fees — the network's long-term sustainability is anchored to real usage, not inflation. Evolución de la relación ERC-20: El cap actual de 21M en el ERC-20 refleja el techo del supply con la geometría actual de validadores (λ_mean = −0.619, 3 validadores). A medida que el conjunto de validadores crece y se diversifica, el techo del supply L1 supera naturalmente los 21M — momento en que la relación 1:1 del bridge evoluciona para reflejar el ratio L1/ERC-20. El ERC-20 es una capa de acceso a liquidez; el token nativo L1 es el activo canónico. Post-emisión (Fase 3+), los validadores ganan exclusivamente de comisiones de TX — la sostenibilidad a largo plazo de la red está anclada al uso real, no a la inflación.

Proof of convergence: Since all valid IFS satisfy ρ(Aᵢ) ∈ [0.30, 0.70], we have λ_mean ∈ [log(0.30), log(0.70)] ⊂ ℝ⁻ always. Therefore emission(n) → 0 as n → ∞ and Supply(∞) = R₀ × T_scale / |λ_mean| < ∞ for any valid validator set. The finiteness of the supply is a consequence of IFS stability — the same mathematical property that makes fractal attractors exist. Prueba de convergencia: Dado que todos los IFS válidos satisfacen ρ(Aᵢ) ∈ [0.30, 0.70], tenemos λ_mean ∈ [log(0.30), log(0.70)] ⊂ ℝ⁻ siempre. Por lo tanto emission(n) → 0 cuando n → ∞ y Supply(∞) = R₀ × T_scale / |λ_mean| < ∞ para cualquier conjunto de validadores válido. La finitud del supply es consecuencia de la estabilidad del IFS — la misma propiedad matemática que hace que existan los atractores fractales.

7.RoadmapHoja de Ruta

✓

PHASE 1 — COMPLETEFASE 1 — COMPLETA

Layer 1 Core + EVM BridgeNúcleo Layer 1 + Puente EVM

Native blockchain, ZK proof system (45 passing tests), bidirectional bridge to Ethereum, MPX live on Base mainnet + Uniswap V4, open source.Blockchain nativa, sistema de pruebas ZK (45 tests pasando), puente bidireccional a Ethereum, MPX en vivo en Base mainnet + Uniswap V4, código abierto.
✓

PHASE 2 — IN PROGRESS · Q2 2026FASE 2 — EN PROGRESO · Q2 2026

Decentralization + CommunityDescentralización + Comunidad

Multi-node testnet LIVE — 5 validators across Chile, Germany and Finland. Native browser TX live (May 16). Bidirectional bridge fully operational (May 21, TX: 0xb692612b...). GEO_HANDSHAKE protocol live. Lyapunov Consensus live (May 25, 2026) — first consensus mechanism based on IFS Lyapunov invariants; λ_real registered on-chain for all validators. Working toward: 10+ external holders, CoinGecko listing, liquidity $2,000+.Testnet multi-nodo EN VIVO — 5 validadores entre Chile, Alemania y Finlandia. TX nativa desde navegador en vivo (16 mayo). Puente bidireccional completamente operacional (21 mayo, TX: 0xb692612b...). Protocolo GEO_HANDSHAKE en vivo. Consenso de Lyapunov en vivo (25 mayo 2026) — primer mecanismo de consenso basado en invariantes de Lyapunov IFS; λ_real registrado on-chain para todos los validadores. En camino: 10+ holders externos, listing en CoinGecko, liquidez $2.000+.
3

PHASE 3 — Q3 2026FASE 3 — Q3 2026

Rust Rewrite — 100x PerformanceReescritura en Rust — 100x Rendimiento

Cryptographic core in Rust with SIMD vectorization. Rust cryptographic core LIVE — chaos_game 4.5x, M₃ tensor 147x, key derivation 64x faster. TX signing: 95ms → 1.5ms (63x). 100+ TPS on public testnet.Núcleo criptográfico en Rust con vectorización SIMD. Núcleo criptográfico Rust EN VIVO — chaos_game 4.5x, tensor M₃ 147x, derivación de clave 64x más rápido. Firma TX: 95ms → 1.5ms (63x). 100+ TPS en testnet pública.
4

PHASE 4 — Q1 2027FASE 4 — Q1 2027

Formal Security + PaperSeguridad Formal + Paper

Independent security audit. arXiv paper: IFS as post-quantum primitive. DAO governance. CEX listing.Auditoría de seguridad independiente. Paper arXiv: IFS como primitiva post-cuántica. Gobernanza DAO. Listing en CEX.

8.Fractal BFTBFT Fractal

8.1 The Fork Problem El Problema de Fork

This is not a theoretical problem. It happened on May 18, 2026:Este no es un problema teórico. Ocurrió el 18 de mayo de 2026:

Slot 29651061: node-0 sees peers: [node-0, NT-vps] → leader = node-0 → mines block A NT-laptop sees peers: [NT-laptop, node-0] → leader = NT-laptop → mines block B Both are correct according to their local view. Result: two valid blocks in the same slot → FORK

The root cause is structural: the leader election functionLa causa raíz es estructural: la función de elección de líder

leader = validators[sha256(prev_hash + slot) % |validators|]

is deterministic given a fixed validator set — but each node computes it from its local peer list. If those lists diverge by even one entry, the modulo maps to a different index. With no pre-mining communication, there is no way to prevent it. The longest-chain rule resolves forks eventually, but cannot prevent them.es determinista dado un conjunto fijo de validadores — pero cada nodo lo calcula desde su lista local de peers. Si esas listas divergen en una sola entrada, el módulo mapea a un índice diferente. Sin comunicación previa al minado, no hay forma de prevenirlo. La regla de cadena más larga resuelve los forks eventualmente, pero no puede prevenirlos.

8.2 What BFT Solves Qué Resuelve BFT

Byzantine Fault Tolerance protocols add a voting round before mining. The leader proposes; validators vote; the block is confirmed only when a supermajority agrees:Los protocolos de Tolerancia Bizantina añaden una ronda de votación antes de minar. El líder propone; los validadores votan; el bloque se confirma solo cuando una supermayoría está de acuerdo:

Slot N (with BFT): 1. Leader proposes block 2. All validators receive proposal 3. Each votes: YES or NO 4. If >2/3 vote YES → block confirmed → everyone appends it 5. Fork is structurally impossible

ProtocolProtocolo	Messages/blockMensajes/bloque	Used byUsado por	NotesNotas
PBFT (1999)	O(n²)	Early systemsSistemas tempranos	Works up to ~20 validatorsFunciona hasta ~20 validadores
Tendermint	O(n)	Cosmos	Propose → Prevote → PrecommitProponer → Prevoto → Preconfirmar
HotStuff	O(n)	Aptos	Linear BFT, most modernBFT lineal, más moderno

Metriplex Phase 2 targets a simplified Tendermint: three phases, tolerating 1 Byzantine node with 4 validators.La Fase 2 de Metriplex apunta a un Tendermint simplificado: tres fases, tolerando 1 nodo bizantino con 4 validadores.

8.3 Fractal BFT Design Diseño de BFT Fractal

Fractal BFT extends slot-PoS with two structural additions:BFT Fractal extiende el slot-PoS con dos adiciones estructurales:

1. Global validator registry — a deterministic on-chain list updated every epoch (1,000 blocks). All nodes compute leader election from the same committed set.1. Registro global de validadores — lista on-chain determinista actualizada cada epoch (1.000 bloques). Todos los nodos calculan la elección de líder desde el mismo conjunto comprometido.

2. ZK identity proof per block — the elected leader must embed a valid ZK criterion proof (c1–c8) against its own IFS attractor in the block header.2. Prueba ZK de identidad por bloque — el líder elegido debe incrustar una prueba ZK válida (c1–c8) contra su propio atractor IFS en el encabezado del bloque.

block_header { slot: uint64 leader_m3: tensor[4][4][4] // leader public key leader_proof: ZKProof // c1–c8 over leader_m3 prev_hash: bytes32 attestations: []Attestation // 2f+1 ZK votes from validator set }

8.4 Safety & Liveness Seguridad y Vivacidad

PropertyPropiedad	MechanismMecanismo
SafetySeguridad	ZK proof ties authorship to IFS identity — unforgeable by IIFSP hardnessLa prueba ZK vincula la autoría a la identidad IFS — infalsificable por dureza del IIFSP
LivenessVivacidad	If leader fails, next slot elects successor via same deterministic functionSi el líder falla, el siguiente slot elige sucesor mediante la misma función determinista
Fork preventionPrevención de forks	Global registry + ZK identity eliminate divergent leader electionRegistro global + identidad ZK eliminan la elección de líder divergente
FinalityFinalidad	2f+1 attestations from validator set (tolerates f Byzantine nodes)2f+1 atestaciones del conjunto de validadores (tolera f nodos bizantinos)
Sybil resistanceResistencia Sybil	Validator registration requires ZK identity proof — no anonymous validatorsEl registro de validador requiere prueba ZK de identidad — sin validadores anónimos

8.5 ZK Voting: Identity-Bound Attestations Votos ZK: Atestaciones Ligadas a Identidad

In Tendermint and HotStuff, a vote is an ECDSA signature. It proves who signed, but not that the signer has a cryptographic right to exist as a validator — that right is managed off-chain by a staking contract or committee.En Tendermint y HotStuff, un voto es una firma ECDSA. Prueba quién firmó, pero no que el firmante tenga derecho criptográfico de existir como validador — ese derecho se gestiona fuera de la cadena mediante un contrato de staking.

In Fractal BFT, each vote is a mini ZK proof:En BFT Fractal, cada voto es una mini prueba ZK:

Attestation { validator_m3: tensor[4][4][4] // validator public key slot: uint64 block_hash: bytes32 vote: bool zk_proof: ZKProof // c1–c8 over validator_m3 }

A single attestation simultaneously proves:Una sola atestación prueba simultáneamente:

#	PropertyPropiedad	What it meansQué significa
1	IdentityIdentidad	The signer possesses a valid IFS whose attractor matches M₃El firmante posee un IFS válido cuyo atractor coincide con M₃
2	AuthorshipAutoría	The proof was generated by the holder of the private IFS, not a copyLa prueba fue generada por el poseedor del IFS privado, no por una copia
3	MembershipMembresía	M₃ is registered in the on-chain validator setM₃ está registrado en el conjunto de validadores on-chain

Structural consequence:Consecuencia estructural: An attacker cannot forge a vote by stealing a key. They would need to reconstruct the IFS from M₃ — equivalent to solving IIFSP, conjectured NP-hard in the average case. The cost of a Byzantine vote rises from key theft to solving a hard geometric inverse problem.Un atacante no puede falsificar un voto robando una clave. Necesitaría reconstruir el IFS desde M₃ — equivalente a resolver IIFSP, conjeturado NP-difícil en el caso promedio. El costo de un voto bizantino sube de robo de clave a resolver un problema inverso geométrico difícil.

This also eliminates the need for a separate validator identity layer. The ZK criterion that authenticates transactions is the same mechanism that authenticates consensus votes. One primitive, two uses.Esto también elimina la necesidad de una capa de identidad de validador separada. El criterio ZK que autentica transacciones es el mismo mecanismo que autentica los votos de consenso. Una primitiva, dos usos.

8.6 Implementation Plan — Q3 2026 Plan de Implementación — Q3 2026

StepPaso	DescriptionDescripción	TargetObjetivo
Epoch registry	On-chain validator list, committed every 1,000 blocks	Q3 2026
Block header ZK	Leader proof required for block acceptance	Q3 2026
Attestation protocol	ZK votes; 2f+1 threshold for finality	Q3 2026
Slashing	Invalid ZK proof triggers validator ejection	Q3 2026
Rust rewrite	BFT module implemented natively for 100x performance	Q3 2026

8.7 Lyapunov Consensus as Interim Solution Consenso de Lyapunov como Solución Intermedia

While full Fractal BFT is a Q3 2026 milestone, Lyapunov Consensus (live May 25, 2026) eliminates the primary fork cause without requiring a multi-round voting protocol. The key insight: if all nodes compute the leader as argmin_v |λ(W_v) − λ_E| from the same on-chain registry, and λ_E is derived deterministically from the anchor block hash, leader election is globally consistent by construction.Mientras el BFT Fractal completo es un hito del Q3 2026, el Consenso de Lyapunov (activo desde el 25 de mayo de 2026) elimina la causa principal de forks sin requerir un protocolo de votación multi-ronda. La idea clave: si todos los nodos calculan el líder como argmin_v |λ(W_v) − λ_E| desde el mismo registro on-chain, y λ_E se deriva determinísticamente del hash del bloque ancla, la elección de líder es globalmente consistente por construcción.

Property	Hash-based (Phase 1)	Lyapunov (Phase 2)	Fractal BFT (Phase 3)
Fork prevention	Partial	Strong	Complete
Finality	Probabilistic	Probabilistic	Deterministic
Messages/blockMensajes/bloque	O(1)	O(1)	O(n)
Energy costCosto energético	NoneNinguno	NoneNinguno	NoneNinguno
Geometric identity	No	Yes — λ on-chain	Yes — full ZK

9.Open Research ProblemsProblemas Abiertos de Investigación

#	ProblemProblema	StatusEstado
Q1	Average-case hardness of IIFSP	Open
Q2	Formal ZK proof of c1–c8 criterion (sigma protocol)	Open
Q3	Quantum resistance — Grover's algorithm on IIFSPResistencia cuántica — algoritmo de Grover sobre IIFSP	OpenAbierto
Q4	Algebraic structure of map W → M₃(μ_W)	Open
Q5	Kruskal-Comon genericity conditions for n=4, d=4	Open
Q6	Rust SIMD performance for 50K chaos game iterations in 4D	Engineering
Q7	Optimal λ distribution for Lyapunov Consensus validator sets — geometric diversity vs. liveness tradeoff	Open
Q8	Holographic Glyph scanner — camera-based decoding of steganographic 8×6 grid with perspective correction and corner marker detection	Engineering
Q9	VALIDATOR_GOVERNANCE_EXIT — on-chain expulsion of inactive validators by 2/3 supermajority vote without requiring the target's keystoreVALIDATOR_GOVERNANCE_EXIT — expulsión on-chain de validadores inactivos por voto de supermayoría 2/3 sin necesitar el keystore del objetivo	✓ Resolved — May 31, 2026
Q10	Formal proof of Voronoi Distribution Property — expected slot fraction as function of geometric distance in λ space	Open

Full research brief:Documento de investigación completo: github.com/NTellezM/Metriplex/docs/

9.2 Threat Model Modelo de Amenaza

Metriplex is designed to resist the following attack classes:Metriplex está diseñado para resistir las siguientes clases de ataque:

AttackAtaque	MechanismMecanismo	ResistanceResistencia
Key forgeryFalsificación de clave	Attacker constructs IFS producing target M₃El atacante construye un IFS que produce el M₃ objetivo	Reduces to IIFSP ≤ₚ Tensor-Decomp-Sym (NP-hard worst case)Se reduce a IIFSP ≤ₚ Tensor-Decomp-Sym (NP-difícil en el peor caso)
Quantum (Shor)Cuántico (Shor)	Period-finding on key spaceBúsqueda de períodos en el espacio de claves	Map IFS → M₃ has no group structure — QFT has no entry pointEl mapa IFS → M₃ no tiene estructura de grupo — la QFT no tiene punto de entrada
Quantum (Grover)Cuántico (Grover)	Brute-force search over 2⁵¹² key spaceBúsqueda por fuerza bruta sobre espacio de claves 2⁵¹²	Reduces to 2²⁵⁶ effective — open problem Q3Se reduce a 2²⁵⁶ efectivo — problema abierto Q3
ZK criterion bypassEvasión del criterio ZK	Fake proof passing c1–c8 without valid IFSPrueba falsa que supera c1–c8 sin IFS válido	0/9 adversarial attacks passed in testing — formal proof open (Q2)0/9 ataques adversariales superaron las pruebas — demostración formal abierta (Q2)
Keystore theftRobo del keystore	Physical access to encrypted keystore + password crackingAcceso físico al keystore cifrado + crackeo de contraseña	AES-256 encryption; password not stored — resistance depends on password strengthCifrado AES-256; contraseña no almacenada — resistencia depende de la fortaleza de la contraseña
Bridge relay attackAtaque al relayer del puente	Fake mint/burn eventsEventos mint/burn falsos	On-chain event verification; ZK proof required for release; dedup via relayer_state.db (processed_mints + processed_burns); last_processed_block persisted across restartsVerificación de eventos on-chain; prueba ZK requerida para liberación; dedup via relayer_state.db (processed_mints + processed_burns); last_processed_block persistido entre reinicios
51% / Eclipse51% / Eclipse	Majority control of validator setControl mayoritario del conjunto de validadores	Slot PoS — deterministic leader election limits grinding; BFT Phase 3Slot PoS — elección de líder determinista limita el grinding; BFT Fase 3

⚠ The quantum resistance argument is structural, not formally proven. Average-case hardness of IIFSP (Q1) and Grover resistance (Q3) remain open research problems.⚠ El argumento de resistencia cuántica es estructural, no formalmente probado. La dureza en el caso promedio de IIFSP (Q1) y la resistencia a Grover (Q3) siguen siendo problemas abiertos de investigación.

10.Network Architecture — Live TestnetArquitectura de Red — Testnet en Vivo

As of May 2026, the Metriplex network operates a live multi-node testnet with five validator nodes running across three countries (Chile, Germany, and Finland). The first cross-country transaction was successfully executed on May 14, 2026 — a ZK-verified transfer propagated from Chile to a validator node in Germany, confirmed in under 10 seconds.En mayo de 2026, la red Metriplex opera una testnet multi-nodo en vivo con cinco nodos validadores en tres países (Chile, Alemania y Finlandia). La primera transacción entre países se ejecutó exitosamente el 14 de mayo de 2026 — una transferencia verificada ZK propagada desde Chile a un nodo validador en Alemania, confirmada en menos de 10 segundos.

10.1 Node Infrastructure Infraestructura de Nodos

Node	Role	Location	Status
node-0 (genesis)	Validator · Miner	Hetzner VPS · EU · Germany	Online 24/7
NT (VPS)	Observer	Hetzner VPS · EU · Germany	Online 24/7
NT (laptop)	Validator · Miner	SA · Chile	Online
node-2	Validator · Miner	SA · Chile	Online
node-3	Validator · Miner	Hetzner VPS · EU · Finland	Online 24/7

10.2 P2P Protocol Protocolo P2P

Nodes communicate via a custom TCP gossip protocol on port 65432. Each node announces its fractal identity address on handshake — establishing both a network connection and a geometric identity simultaneously. The protocol supports block sync, transaction propagation, and peer discovery.Los nodos se comunican mediante un protocolo TCP gossip personalizado en el puerto 65432. Cada nodo anuncia su dirección de identidad fractal en el handshake — estableciendo simultáneamente una conexión de red y una identidad geométrica. El protocolo soporta sincronización de bloques, propagación de transacciones y descubrimiento de peers.

The fix applied during testnet development revealed a key property: the handshake must always respond, even if the peer is already known, to support reconnection after network interruptions. This is now part of the canonical protocol specification.La corrección aplicada durante el desarrollo de la testnet reveló una propiedad clave: el handshake siempre debe responder, incluso si el peer ya es conocido, para soportar la reconexión tras interrupciones de red. Esto ahora forma parte de la especificación canónica del protocolo.

10.2.1 GEO_HANDSHAKE — Geometric P2P Authentication

As of May 21, 2026, the P2P protocol supports geometric authentication via GEO_HANDSHAKE. When a node with a valid IFS keystore connects to a peer, it sends a ZK proof (c1–c8) over a session nonce instead of a plain address string. The receiving node verifies the proof and classifies the peer:Desde el 21 de mayo de 2026, el protocolo P2P soporta autenticación geométrica mediante GEO_HANDSHAKE. Cuando un nodo con keystore IFS válido se conecta a un peer, envía una prueba ZK (c1–c8) sobre un nonce de sesión en lugar de una cadena de dirección simple. El nodo receptor verifica la prueba y clasifica al peer:

GEO_HANDSHAKE { endpoint: "IP:port" m3: tensor[4][4][4] // public key m3_hash: sha256(M₃) zk_proof: ZKProof // c1–c8 over session nonce nonce: sha256(endpoint + hour) } Peer classification: Valid ZK + FVR registered → authenticated validator Valid ZK + not in FVR → authenticated node No ZK / invalid ZK → observer (read-only)

The ZK proof is precomputed once per session (valid 1 hour) and reused for all handshakes. This eliminates the need for a separate PKI or certificate authority — geometric identity IS the network identity. This is, to the authors' knowledge, the first blockchain protocol where P2P authentication is based on fractal attractor geometry rather than elliptic curve signatures.La prueba ZK se precomputa una vez por sesión (válida 1 hora) y se reutiliza en todos los handshakes. Esto elimina la necesidad de una PKI o autoridad certificadora separada — la identidad geométrica ES la identidad de red. Este es, a conocimiento de los autores, el primer protocolo blockchain donde la autenticación P2P se basa en geometría de atractores fractales en lugar de firmas de curva elíptica.

10.3 Consensus confirmation — May 14, 2026 Confirmación de Consenso — 14 Mayo 2026

Event	Value
TX hash	70757186c9a2a788f1dfdf2f388b3bb6...
BlockBloque	5
ZK proof	ACCEPTED — c1–c8 verified
PropagationPropagación	Chile → Germany · ~10 secondsChile → Alemania · ~10 segundos
Both nodes hash	7e17618e07e95105ffa54fa93d3325a6...
Consensus	✓ Identical — 4 nodes · 2 continents

10.4 Native browser TX — May 16, 2026 TX Nativa desde Navegador — 16 Mayo 2026

The first native MPX transfer initiated entirely from a browser was executed on May 16, 2026. The ZK proof — including chaos game sampling, Merkle commitment, and Fiat-Shamir seal — was generated in JavaScript (metriplex-crypto.js) and verified by the Python validator node with no modifications to the protocol.La primera transferencia nativa de MPX iniciada completamente desde un navegador se ejecutó el 16 de mayo de 2026. La prueba ZK — incluyendo muestreo del juego del caos, compromiso Merkle y sello Fiat-Shamir — fue generada en JavaScript (metriplex-crypto.js) y verificada por el nodo validador Python sin modificaciones al protocolo.

Event	Value
Proof generatedPrueba generada	Browser (JavaScript) — metriplex-crypto.js
Proof verified	Python validator — ZK ACCEPTED
Root cause resolvedCausa raíz resuelta	`null` serialized as `{}` → tx_hash mismatch → fixed
SignificanceSignificado	Full ZK pipeline: JS → network → Python — no trusted intermediaryPipeline ZK completo: JS → red → Python — sin intermediario de confianza

10.5 Native→ETH bridge — May 21, 2026 Puente Nativo→ETH — 21 Mayo 2026

The first Native→ETH bridge transfer was confirmed on Base mainnet on May 21, 2026, completing the bidirectional bridge. MPX native tokens were sent to the vault with a target_eth_address payload; the relayer detected the deposit and executed mint() on the ERC-20 contract.La primera transferencia del puente Nativo→ETH fue confirmada en Base mainnet el 21 de mayo de 2026, completando el puente bidireccional. Los tokens MPX nativos fueron enviados al vault con un payload target_eth_address; el relayer detectó el depósito y ejecutó mint() en el contrato ERC-20.

Event	Value
DirectionDirección	Metriplex Native → Base mainnet (ERC-20)
TX hash (Base)	0xb692612b885982e9de982c0137bd8e98e0abaaa8...
BlockBloque	46302158
Status	✓ Success — confirmed by sequencer
Mint	0x000...000 → relayer
Gas costCosto de gas	$0.000472
SignificanceSignificado	Bidirectional bridge fully operationalPuente bidireccional completamente operacional

10.6 Lyapunov Consensus activation — May 25, 2026 Activación del Consenso de Lyapunov — 25 Mayo 2026

On May 25, 2026, Lyapunov Consensus was activated on the live Metriplex network. All four validators registered their canonical Lyapunov invariants on-chain via the new VALIDATOR_UPDATE transaction type, and the argmin leader election replaced the hash % n function in network/miner.py.El 25 de mayo de 2026, el Consenso de Lyapunov fue activado en la red Metriplex en vivo. Los cuatro validadores registraron sus invariantes de Lyapunov canónicos on-chain mediante el nuevo tipo de transacción VALIDATOR_UPDATE, y la elección de líder por argmin reemplazó la función hash % n en network/miner.py.

Validator	λ(W)	Type	Territory
node-0 (bdb8c1f4)	−0.4702	Real	~28%
node-2 (3542268a)	−0.6993	Real	~45%
NT-laptop (0a5e398e)	−0.6860	Real	~8%
node-3 (203a4d51)	−0.8144	Real	~19%
ee481176 (legacy)	−0.9717	✓ Expelled	— expelled via VALIDATOR_GOVERNANCE_EXIT, block 15750 (2/2 votes)— expulsado via VALIDATOR_GOVERNANCE_EXIT, bloque 15750 (2/2 votos)

Empirical observation: The three genesis validators, independently generated, have λ values within a 0.013 interval of a 0.847 range — 1.6% coverage. This clustering by construction motivated the Geometric Diversity Constraint (Definition 5 in the Lyapunov Consensus paper, Q4 2026).Observación empírica: Los tres validadores génesis, generados independientemente, tienen valores λ dentro de un intervalo de 0.013 en un rango de 0.847 — 1.6% de cobertura. Este agrupamiento motivó la Restricción de Diversidad Geométrica (Definición 5 en el paper de Consenso de Lyapunov, Q4 2026).

Update — May 30, 2026: Full bidirectional bridge cycle verified end-to-end with 1:1 parity. Scale conversion bug resolved: CAF_SCALE (2³⁰) ↔ wei (10¹⁸) now correct in both directions. Mint TX: 0x9f553b7c660443a665a9b3d7fc1e5618208608a910d7059475dfe5452f53fbd5Actualización — 30 Mayo 2026: Ciclo bidireccional completo del puente verificado extremo a extremo con paridad 1:1. Bug de conversión de escala resuelto: CAF_SCALE (2³⁰) ↔ wei (10¹⁸) ahora correcto en ambas direcciones. TX de mint: 0x9f553b7c660443a665a9b3d7fc1e5618208608a910d7059475dfe5452f53fbd5

Update — May 26, 2026: The genesis validator node-0 (44225e0c, λ=−0.6926) was retired and replaced by bdb8c1f4 with λ=−0.4702 — strategically positioned in the upper third of the [λ_min, λ_max] range to maximize Voronoi territory (~48% of slots).Actualización — 26 Mayo 2026: El validador génesis node-0 (44225e0c, λ=−0.6926) fue retirado y reemplazado por bdb8c1f4 con λ=−0.4702 — posicionado estratégicamente en el tercio superior del rango [λ_min, λ_max] para maximizar el territorio de Voronoi (~48% de los slots).

Update — May 31, 2026: The legacy validator ee481176, whose keystore was lost, was permanently expelled from the FVR via VALIDATOR_GOVERNANCE_EXIT at block 15750 — first on-chain governance action in Metriplex history. Vote: 2/2 active validators (bdb8c1f4 + 3542268a). FVR now contains exactly 3 active validators, all with real λ values.Actualización — 31 Mayo 2026: El validador legacy ee481176, cuyo keystore se perdió, fue expulsado permanentemente del FVR via VALIDATOR_GOVERNANCE_EXIT en el bloque 15750 — primera acción de gobernanza on-chain en la historia de Metriplex. Voto: 2/2 validadores activos (bdb8c1f4 + 3542268a). El FVR ahora contiene exactamente 3 validadores activos, todos con valores λ reales.

Update — June 3, 2026: node-3 (203a4d51, λ=−0.8144) registered as the 4th active validator — first node outside the genesis infrastructure. Located in Helsinki, Finland (Hetzner CPX11). FVR now spans 3 countries across Europe and South America. Bootstrap time: ~30 seconds via snapshot.Actualización — 3 Junio 2026: node-3 (203a4d51, λ=−0.8144) registrado como el 4° validador activo — primer nodo fuera de la infraestructura génesis. Ubicado en Helsinki, Finlandia (Hetzner CPX11). El FVR ahora abarca 3 países entre Europa y Sudamérica. Tiempo de bootstrap: ~30 segundos via snapshot.

Event	Value
VALIDATOR_UPDATE TX (node-0)	0f7e630f... · bloque 7921
VALIDATOR_UPDATE TX (node-2)	250bef46... · bloque 7923
VALIDATOR_REGISTER (NT-laptop)	6bf826b4... · bloque 8012
First Lyapunov blockPrimer bloque Lyapunov	Slot 29662215 — node-2 elected via argmin
Chain height at activationAltura de cadena al activar	~8,020 blocks
Status	✓ Active — all validators rotating

11.Transaction EconomicsEconomía de Transacciones

One of the most significant properties of the Metriplex native chain is its near-zero transaction cost. Unlike EVM-based chains, there is no gas auction mechanism. The consensus model is slot-based Proof of Stake — leader election is deterministic, not competitive. This eliminates the energy and fee overhead of proof-of-work and gas bidding entirely.Una de las propiedades más significativas de la cadena nativa Metriplex es su costo de transacción cercano a cero. A diferencia de las cadenas basadas en EVM, no existe mecanismo de subasta de gas. El modelo de consenso es Prueba de Participación basada en slots — la elección de líder es determinista, no competitiva. Esto elimina completamente la sobrecarga energética y de comisiones del proof-of-work y las pujas de gas.

11.1 Fee StructureEstructura de Comisiones

ComponentComponente	Metriplex	Bitcoin	Ethereum
Base feeComisión base	0 MPX	$1–50	$0.50–20
Network feeComisión de red	1 MPX per transaction (to block validator)1 MPX por transacción (al validador del bloque)	Market-basedBasado en mercado	Gas × gwei
Confirmation timeTiempo de confirmación	~10 seconds	10–60 min	~15 seconds
Energy modelModelo energético	Slot PoS — minimalSlot PoS — mínimo	Proof of Work	Proof of Stake

11.2 Why fees are structurally lowPor qué las comisiones son estructuralmente bajas

The ZK proof in Metriplex is a mathematical verification of the sender's IFS attractor — not a computational race. Verification is deterministic and fast. The 1 MPX network fee goes directly to the block validator as a reward, creating an incentive structure that scales with network activity rather than congestion.La prueba ZK en Metriplex es una verificación matemática del atractor IFS del emisor — no una carrera computacional. La verificación es determinísta y rápida. La comisión de red de 1 MPX va directamente al validador del bloque como recompensa, creando una estructura de incentivos que escala con la actividad de la red, no con la congestión.

As the Rust rewrite progresses (Phase 3), signing time is projected to drop from ~4 seconds to ~40ms, enabling throughput exceeding 700 TPS on commodity hardware (single core) — at the same near-zero cost.A medida que avanza la reescritura en Rust (Fase 3), se proyecta que el tiempo de firma caiga de ~4 segundos a ~40ms, habilitando un rendimiento superior a 700 TPS en hardware estándar (un solo núcleo) — al mismo costo cercano a cero.

11.3 Economic modelModelo económico

More validators → stronger security + better reward distribution. Each new validator node independently verifies every ZK proof. Block rewards are distributed proportionally to Voronoi territory — a validator that occupies a unique geometric position in λ-space earns more. This creates a dual incentive: security (more nodes) and diversity (more geometric spread). After the 100-year emission window, validators earn exclusively from transaction fees.Más validadores → mayor seguridad + mejor distribución de recompensas. Cada nuevo nodo validador verifica independientemente cada prueba ZK. Las recompensas por bloque se distribuyen proporcionalmente al territorio de Voronoi — un validador que ocupa una posición geométrica única en el espacio λ gana más. Esto crea un incentivo doble: seguridad (más nodos) y diversidad (mayor dispersión geométrica). Tras la ventana de emisión de 100 años, los validadores ganan exclusivamente de las comisiones de transacción.

Academic CitationCita Académica

CITE ASNTellezM (Nelson Tellez). "Metriplex: Fractal Identity as a Cryptographic Primitive on a Layer 1 Blockchain." 2026. https://github.com/NTellezM/Metriplex @misc{metriplex2026, author = {NTellezM (Nelson Tellez)}, title = {Metriplex: Fractal Identity as a Cryptographic Primitive}, year = {2026}, url = {https://github.com/NTellezM/Metriplex}, license = {CC BY 4.0} }CITAR COMONTellezM (Nelson Tellez). "Metriplex: Identidad Fractal como Primitiva Criptográfica en una Blockchain Layer 1." 2026. https://github.com/NTellezM/Metriplex @misc{metriplex2026, author = {NTellezM (Nelson Tellez)}, title = {Metriplex: Fractal Identity as a Cryptographic Primitive}, year = {2026}, url = {https://github.com/NTellezM/Metriplex}, license = {CC BY 4.0} }

GitHub — Full codebase ↗ Get MPX →

Metriplex ProtocolOrder from chaosOrden desde el caos