ARQUITECTURA
Para el trader, Dexter es un único producto — conecta una wallet, compra un paquete de $49 a $299, opera, cobra — y cinco capas por debajo. Cada capa posee exactamente un trabajo y mantiene exactamente la autoridad que ese trabajo requiere. Un oracle degradado no puede pausar un retiro. Una wallet operativa atascada no puede congelar las garantías. El motor del challenge no puede reescribir un fill del motor de matching. El settlement se ejecuta en Base, la custodia reside en contratos dedicados y cada pago se rastrea hasta una raíz de estado publicada que cualquiera puede verificar en un explorador.
La interfaz se siente única, pero la ejecución, la publicación y la custodia permanecen claramente separadas.
Una plataforma visible.
Política antes de la ejecución.
Pricing, matching, riesgo, funding, publicación.
El estado se publica con contexto.
Las garantías permanecen acotadas.
Lee la tabla como un mapa de permisos. La primera columna de cada capa es lo que se le permite hacer; la tercera columna es lo que no puede hacer, por diseño. Nada en la tabla mueve fondos de usuario sin la correspondiente llamada al contrato en Base.
| Capa | Tarea principal | Lo que no puede hacer |
|---|---|---|
| Superficie del producto | Renderizar mercados, gráficos, entrada de órdenes, posiciones, activos y vistas de cuenta | Sin matching, sin custodia, sin settlement |
| Gateway y modelo de lectura | Normaliza la salida persistida del runtime en una API estable única; controla el ingreso firmado con agent auth, IOC y la política de order-commit | Sin decisiones de fill, sin autoridad sobre saldos |
| Motor del runtime | Flujo de un único escritor: valida órdenes firmadas, aplica riesgo, precio, fill, avanza funding, prepara la publicación | Sin custodia directa, sin retiros unilaterales, sin cambios de parámetros |
| Publicación | Confirma las raíces de estado con secuencia, oracle, batch y bindings de configuración contra los que liquida el vault | Sin bucle de matching, sin escrituras de saldo |
| Contratos en Base | Mantener garantías, encolar retiros, preservar el historial de raíces, hacer cumplir multi-sig en acciones de tesorería | Sin matching de órdenes en vivo, sin autoridad off-chain |
#Una plataforma, capas operativas separadas
El trader ve una sola plataforma. La implementación divide esa plataforma en cinco capas porque forzar la ejecución rápida, el estado legible del producto y los permisos críticos para la custodia en un solo componente es como las plataformas de derivados pierden fondos de usuario. La superficie del producto posee la claridad. El gateway posee la normalización y la política de admisión sobre el flujo firmado. El runtime posee el estado de exchange en vivo bajo un modelo de un único escritor. La publicación posee los bindings entre el estado off-chain y el settlement on-chain. Los contratos en Base poseen la custodia y los gates multi-sig sobre los movimientos de tesorería.
Las superficies de terceros — dashboards, vías de copy-trading, clientes móviles, consumidores de API institucionales — leen del mismo gateway que la app interna. No constituyen una nueva capa de protocolo; consumen el mismo estado persistido. Esa es la razón estructural por la que un bot de copy-trading, un front-end móvil retail y una mesa quant ven fills consistentes.
Dexter se lanza en modo vAMM sin liquidez. La plataforma en vivo no depende del inventario en reposo de makers; la presión de ejecución, el skew, el spread y la postura de inventario se gestionan dentro del runtime contra la curva del vAMM. Los derechos de custodia y retiro permanecen vinculados a los contratos sin importar la postura que tome el runtime. Una mala decisión de inventario no puede costarle al trader su margen.
superficie del producto
-> gateway y modelo de lectura
-> runtime off-chain
-> commitments publicados
-> contratos de vault, tesorería y settlement en Base#Dónde se sitúa realmente el límite de confianza
Dexter no afirma que cada componente esté on-chain. Afirma algo más acotado y más útil: la ejecución puede ser rápida off-chain siempre que la custodia, las referencias de settlement y el valor propiedad del protocolo vivan on-chain con reglas explícitas. Las garantías del usuario, las solicitudes de retiro, el historial de nonces, los saldos de comisiones, la reserva de seguros y la contabilidad del lado de ingresos viven todos en almacenamiento gobernado por contratos en Base porque esos son los lugares donde la propiedad debe permanecer inequívoca.
El runtime avanza el estado y publica el contexto de settlement que el vault lee. No redefine la custodia a posteriori, y no autoriza un retiro que los contratos no honrarían por sí solos. Los movimientos de tesorería por encima de $10.000 requieren un multi-sig 2 de 3; los movimientos de seguros y gobernanza requieren 3 de 5 con un firmante externo. El runtime no puede saltarse ninguno de los dos gates. Eso es lo que convierte la división off-chain / on-chain en un límite arquitectónico real en lugar de un lenguaje de marketing superpuesto a un backend de caja negra.