SEGURIDAD
Dexter es la primera prop firm on-chain. Los traders pagan $49, $99, $199 o $299 por un paquete de challenge, alcanzan el objetivo +10% sin romper los límites del -4% diario o del -8% trailing, y reciben una cuenta financiada 90 / 10 cuyo pago se publica todo en Base. El modelo de seguridad detrás de esa caja es lo que determina si aterriza el reparto de beneficios. Esta página establece los límites — un runtime de un único escritor, superficies de permisos de gateway separadas, retiros protegidos por prueba, controles de vault con multi-sig 2 de 3 de operaciones por encima de $10K y 3 de 5 de gobernanza con al menos un firmante externo, banderas de pausa de guardián y ventanas de disputa y challenge sobre cada raíz de settlement publicada. Las mecánicas más profundas viven en las tres páginas que siguen.
La autoridad se divide en cinco capas para que ningún componente único pueda mover valor de tesorería ni finalizar un retiro con su propia aserción. Cada capa tiene un conjunto distinto de firmantes, un radio de impacto distinto y una ruta de recuperación distinta.
| Límite de seguridad | Lo que protege |
|---|---|
| Disciplina del runtime | Ordenación de único escritor sobre fills, funding, liquidaciones y actualizaciones de marca; ningún escritor en competencia puede alterar el estado del exchange |
| Límites del gateway | Las lecturas públicas, las vistas autenticadas de cuenta, las rutas de trading firmadas y las rutas exclusivas de operador llevan cada una auth distinta — un token público nunca alcanza una superficie de tesorería |
| Raíles de prueba y challenge | Los retiros finalizan sólo contra una raíz publicada, una prueba Merkle coincidente, un nonce vinculado y una ventana de disputa satisfecha |
| Multi-sig de vault y gobernanza | Multi-sig 2 de 3 de operaciones sobre movimientos por encima de $10K; 3 de 5 de gobernanza y seguros con al menos un firmante externo para cambios de parámetros y de reserva |
| Monitorización y recuperación | Señales continuas de freshness de feed, liveness de raíz, salud del gateway y reconciliación de tesorería con autoridad de pausa de guardián sobre cualquiera de ellas |
#La seguridad no es un único plano de control
El estado del exchange avanza a través de un runtime de un único escritor que posee los devengos de funding, las actualizaciones de marca, los disparadores de liquidación, el control de skew y la publicación del estado de settlement. Nada más tiene permitido mutar ese estado en paralelo, lo cual es el prerrequisito para cada garantía downstream — una prueba sólo se puede confiar si hay exactamente una historia canónica contra la que pueda demostrar.
El gateway expone luego ese estado a través de cinco superficies de permisos distintas: lecturas anónimas de mercado, vistas de cuenta autenticadas con wallet, flujo de trading firmado, rutas de telemetría sólo para operadores, y rutas de transferencia de valor que requieren tanto firma como una allowlist del lado del servidor. Ningún token emitido para una superficie es honrado por otra, por lo que una sesión de producto comprometida nunca hereda autoridad de tesorería y una clave de lectura pública nunca hereda visibilidad de operador.
En Base, la capa de contratos añade un segundo perímetro que el runtime no puede anular. Las banderas de pausa del guardián pueden detener depósitos, retiros o todo el pipeline de settlement dentro de una sola transacción. Los root guards rechazan cualquier commit cuyo timestamp, nonce o padre referenciado discrepe con la historia on-chain. Los hooks de fraud-verifier y el disputeWindowSec configurable mantienen las raíces cuestionables en un estado disputable hasta que la ventana expire. Juntos garantizan que el settlement siempre se ralentiza o detiene cuando las condiciones del runtime son obsoletas, disputadas o están bajo revisión — incluso si el propio runtime cree que todo está bien.
#Por qué las salidas basadas en prueba importan
El USDC sale del vault sólo cuando cuatro condiciones independientes coinciden en el mismo bloque: el nonce requestWithdraw del usuario existe on-chain, el runtime ha incluido esa solicitud en una raíz de settlement, la prueba Merkle enviada reconstruye la hoja del usuario contra esa raíz exacta, y disputeWindowSec ha transcurrido sin un challenge exitoso. Un saldo que el runtime cree que te debe no es suficiente. El contrato debe verificar independientemente que el estado publicado dice realmente eso.
Esto importa porque la autenticación de rutas y la corrección de estado son amenazas distintas. Una clave de operador robada le permitiría a un atacante llamar a endpoints privilegiados, pero no puede fabricar una prueba Merkle contra una raíz cuyas hojas son reconstruibles públicamente. Un runtime con bugs podría publicar una raíz incorrecta, pero la ventana de disputa la mantiene impugnable a través de challengeRootFraudProof, challengeRootInvalidLeaf o challengeRootConflict antes de que se mueva ningún USDC. Ambos perímetros tienen que fallar al mismo tiempo para que aterrice un pago erróneo.
el runtime permanece de un único escritor
-> el gateway expone superficies de auth separadas
-> la raíz y el contexto de commitment se publican en Base
-> los retiros requieren nonce + prueba + historial de raíces
-> disputeWindowSec permanece abierto para challenges de fraud-proof
-> sólo entonces finalizeWithdraw libera USDC#Qué significa la seguridad en la práctica
Para un trader financiado, el modelo de seguridad determina un pequeño número de cosas concretas. Los retiros de reparto de beneficios hasta $5K y fuera del podio top tres de la tabla de clasificación se ponen en cola para procesamiento automático y apuntan a liberación dentro de 24 horas tras superar el KYC tipo Sumsub. Cualquier cosa por encima de $5K, cualquier pago del podio top tres y cualquier primer pago por encima de $50 acumulados se enrutan a revisión manual por el multi-sig de operaciones — el mismo umbral 2 de 3 que firma cada movimiento de tesorería por encima de $10K. Las wallets de las jurisdicciones IR, KP, SY y CU se bloquean en el momento de la petición, y cada petición se criba contra las listas de sanciones OFAC, EU y UK antes de que llegue a la cola. Nada en ese flujo es opcional o negociable.
Lo que deberías esperar de una plataforma digna de confiar con capital financiado: un precio obsoleto nunca parece operable, un mercado restringido nunca parece live, una ruta de tesorería nunca hereda los permisos de una lectura pública, y un retiro nunca finaliza sólo con una aserción del operador. Dexter está diseñado para que el fallo sea ruidoso e impugnable en lugar de silencioso — y para que cada transición sensible tenga que pasar por más de una suposición sana al mismo tiempo.