VAULT Y TESORERÍA
Cuatro direcciones de contrato, cuatro saldos, cuatro conjuntos de reglas para moverlos. El collateral del usuario, la tesorería operativa que mantiene los ingresos por comisiones, la reserva de seguros que absorbe los residuos de liquidación y el desbordamiento de bad debt, y el pool de recompensas que financia el efectivo de la tabla de clasificación viven todos en contratos separados en Base, con políticas de firmantes separadas y rastros contables separados. Ninguno puede vaciarse para recargar a otro. Esa separación es la razón estructural por la que el pipeline de pagos de Dexter es creíble — tu retiro de reparto de beneficios 90 / 10 no depende de que la wallet operativa sea solvente, el bracket del premio de temporada no depende del collateral del usuario, y una sucesión de liquidaciones no puede retrasar un retiro legítimo porque la pérdida se cubre con seguros, no con la misma dirección donde está tu USDC.
Los cuatro saldos responden a cuatro preguntas distintas y se mueven bajo cuatro conjuntos distintos de permisos. La tabla es el layout del contrato, no una abstracción de marketing — cada fila es una dirección desplegada en Base con su propia política de firmantes y su propio rastro contable.
| Vault | Lo que contiene | Cómo está pensado para moverse |
|---|---|---|
| Vault de collateral del usuario | Depósitos en USDC, margen abierto, solicitudes de retiro pendientes y el rastro de nonces por cuenta | Liberado sólo contra una raíz de estado publicada y una prueba Merkle coincidente; ninguna clave de operador puede saltarse la puerta de la prueba |
| Tesorería operativa | Ingresos por comisiones devengados de la actividad de trading y capital de trabajo propiedad del protocolo | Las salidas por encima de $10K requieren multi-sig 2 de 3; los destinatarios están gobernados y son visibles en Basescan |
| Reserva de seguros | La porción del 50% del residuo de liquidación, más cualquier buffer sembrado para condiciones de estrés | Las retiradas requieren multi-sig 3 de 5 incluyendo un firmante externo; cada ajuste está explícitamente categorizado |
| Pool de recompensas | Efectivo de la tabla de clasificación de temporada y brackets de premio publicados, financiados antes de que se abra la temporada | Liberado contra el bracket publicado al cierre de temporada; los puestos del podio (top 3) se revisan antes de que el lote salga de tesorería |
#Custodia, settlement y saldos del protocolo
El collateral del usuario se mantiene en el contrato de vault dedicado en Base. Los depósitos, las solicitudes de retiro, el rastro de nonces por cuenta y el paso de finalize que libera USDC de vuelta a la wallet pasan todos por la lógica del contrato — nunca a través del runtime solo. El runtime es lo suficientemente rápido para coordinar matching y riesgo en tiempo real, pero no puede reescribir resultados de custodia, porque cada liberación está protegida por una prueba Merkle contra una raíz de estado que el contrato del vault ya ha aceptado. El flujo completo de petición a liberación se documenta en Settlement y retiros; lo que importa aquí es que el runtime y el vault están deliberadamente desacoplados.
El vault almacena más que saldos de tokens. También almacena las referencias de settlement que describen lo que el runtime creía cuando cada actualización de estado se selló: la raíz de estado activa, el id de raíz, la marca temporal de publicación, la versión del schema, el commitment de secuencia, el hash de fuente de oracle de la capa de precios y el commitment del batch de órdenes. El historial de raíces se retiene on-chain para que cualquier transacción de settlement pueda atarse de vuelta a un estado de exchange publicado específico — no a una afirmación vaga de que el operador dice que el ledger cambió.
Las otras tres direcciones de vault viven en paralelo, con sus propias políticas de permisos y sus propios cubos contables. La tesorería operativa mantiene los ingresos por comisiones de la actividad de trading. La reserva de seguros mantiene la porción del 50% del residuo de liquidación más cualquier buffer sembrado utilizado para absorber resultados estresados — el otro 50% de cada residuo de liquidación va al keeper que disparó la rutina. El pool de recompensas mantiene el efectivo publicado de la tabla de clasificación para la temporada activa, financiado antes de que se abra la temporada para que el bracket no pueda reducirse silenciosamente a mitad de temporada. Ninguno de estos es margen del usuario, y ninguno se libera bajo las reglas de retiro del usuario.
#Por qué la custodia y el valor del protocolo permanecen separados
Esta arquitectura no afirma que el vault sea imposible de atacar — ninguna plataforma seria debería prometer eso. Sí hace que cualquier compromiso único sea menos poderoso que un compromiso de todo el sistema. Un fallo del runtime no puede mover el collateral del usuario, porque el vault sólo libera contra una prueba que coincida con una raíz ya aceptada. Un compromiso de firmante sobre la tesorería operativa no puede pagar el pool de recompensas, porque el pool de recompensas es un contrato distinto con un conjunto de firmantes distinto. Un pico de liquidaciones sobre una sola cuenta financiada no puede vaciar la tesorería operativa, porque la pérdida sale del seguro bajo un cubo contable separado.
La política de permisos es explícita en cada capa. Las salidas de la tesorería operativa por encima de $10K requieren multi-sig 2 de 3 del grupo de operaciones. Las retiradas de la reserva de seguros requieren multi-sig 3 de 5 que debe incluir un firmante externo fuera del grupo de operaciones, para que un quórum sólo de insiders no pueda agotar la reserva. Las acciones de gobernanza — cambios de parámetros, actualizaciones de contratos, cambios de destinatario — corren bajo el mismo requisito de 3 de 5 con firmante externo. Las banderas de pausa y la lógica de root-guard dan a la capa de contratos una manera de congelar liberaciones mientras se investiga una disputa o incidente, sin que esas banderas también habiliten movimientos unilaterales.
El resultado es un layout que un revisor puede leer en tres preguntas: dónde está el dinero del usuario (el vault de collateral, liberado por prueba), qué pertenece al protocolo (tesorería operativa y reserva de seguros, con sus propias políticas de firmantes), y qué debe ser cierto antes de que se mueva cualquier saldo (las reglas on-chain listadas arriba). Ninguna parte de la respuesta requiere confiar en la palabra del operador.
#Cómo esto protege tus pagos
- Tu collateral no puede financiar el pago de otra persona. El vault de collateral del usuario libera USDC sólo contra una raíz de estado publicada y una prueba Merkle coincidente. La tesorería operativa no puede meterle mano para cubrir un bracket de la tabla de clasificación, un lote de efectivo de referidos o un déficit de seguros. La UI de la caja muestra el id de raíz y la prueba en el momento de finalize; puedes verificar la liberación on-chain contra la misma raíz tú mismo en Basescan.
- El seguro es un contrato separado con su propia política de firmantes. Cada residuo de liquidación se reparte 50% al keeper que lo disparó, 50% al seguro. El desbordamiento de bad debt de una cuenta financiada fallida sale del seguro, no de la tesorería operativa y no del collateral del usuario — que es por lo que una cadena de liquidaciones no ralentiza retiros legítimos. Las propias retiradas del seguro requieren multi-sig 3 de 5 incluyendo un firmante externo.
- El pool de recompensas se financia al inicio de la temporada, no al cierre. El efectivo de la tabla de clasificación para la temporada activa se mueve al contrato dedicado de pool de recompensas antes de que se abra la temporada. Los brackets publicados ($X para #1, $Y para #2–3, etc.) no pueden reducirse silenciosamente a mitad de temporada porque el efectivo ya no está en la wallet operativa. Los puestos del podio (top 3) se revisan antes de que la transacción del lote de cierre de temporada salga de tesorería; los retiros individuales por encima de $5K disparan la misma revisión de alto valor.
- El multi-sig protege cada movimiento del lado del protocolo. Las salidas de la tesorería operativa por encima de $10K requieren 2 de 3; las retiradas de la reserva de seguros y las acciones de gobernanza requieren 3 de 5 con un firmante externo. Cada transacción se publica en Base, por lo que un movimiento súbito fuera de cualquiera de los cuatro vaults es visible para cualquiera que vigile la dirección.
Cada dirección de vault se publica en la página de controles de seguridad y se puede fijar a una watchlist de Basescan. Si el total "Verified Rewards" de la tabla de clasificación de dexter.market alguna vez discrepa de la suma de transacciones que salen de la dirección del pool de recompensas, el registro on-chain gana — y verás la discrepancia antes de que te la contemos. Las mecánicas de settlement que liberan el collateral del usuario se documentan en Settlement y retiros; los flujos contables de comisiones y seguros se documentan en Tesorería y contabilidad.