CAPA DE PRECIO
Un único precio lo gobierna todo. Tu fill del challenge, la marca de tu equity, las comprobaciones de drawdown del -4% diario y -8% total, la marca de funding, el disparador de liquidación y cada número de PnL de la tabla de clasificación derivan de la misma marca publicada del oracle. No hay "marca del challenge", no hay "marca interna" y no hay un feed privado para cuentas financiadas — una wallet pública operando $100 de BTC y un trader financiado 90 / 10 con $99 de tamaño de challenge ambos valoran contra el mismo anclaje Hermes/Pyth y el mismo cross-check de HTTP-mux. Toda la capa de prop perdería su sentido si la plataforma pudiera sesgar silenciosamente la marca en cualquier dirección, por lo que la capa de precios está construida para ser reproducible por cualquier revisor a partir de datos abiertos, no sólo creíble desde dentro.
Dexter cross-checkea primero las familias de referencia, después promueve una marca al estado operable de la plataforma.
Familia de referencia principal.
Confirmación independiente.
El motor opera contra la marca de la plataforma.
Quórum reducido sólo cuando se permite.
Cada marca aceptada es explicable.
La capa de precios posee cinco decisiones: qué referencias entran en la plataforma, qué ruta de referencia está activa cuando hay múltiples fuentes sanas, cómo se deriva la marca operable a partir de esa referencia más el estado de la plataforma, cuándo un mercado debe degradarse de live a reduced, close-only, session-closed o halted, y qué postura de fuente queda estampada en la siguiente raíz de settlement para que la capa de contratos pueda demostrar posteriormente qué precios dependieron del pago. Cada decisión se aplica antes de que la marca se vuelva operable — ninguna es una divulgación a posteriori.
| Responsabilidad de la capa de precios | Lo que controla |
|---|---|
| Ingreso de fuentes | La whitelist de publicadores externos (Hermes/Pyth primario, HTTP oracle mux secundario) elegibles para alimentar la plataforma |
| Selección de fuente | La ruta de referencia activa en cada tick — impulsada por freshness, acuerdo y política de desviación, no por preferencia |
| Construcción de marca | Anclaje de referencia mezclado con skew de la plataforma, spread, depth, continuidad max-move y topes de drift respecto a la marca previa |
| Lógica de degradación | El disparador que degrada un mercado a reduced, close-only, session-closed o halted antes de que las comprobaciones de riesgo fallen |
| Contexto de settlement | El hash de fuente de oracle comprometido dentro de cada raíz de estado para que los pagos estén ligados a la misma postura contra la que las operaciones valoraron |
#Del ingreso de referencias a la marca operable
La postura normal de producción para cada mercado soportado es la misma: Hermes/Pyth como familia de referencia primaria corriendo a través de un canal push de baja latencia, y un HTTP oracle mux independiente que proporciona una ruta pull redundante que el runtime cross-checkea en cada tick. Las dos rutas deben coincidir dentro de los límites de desviación antes de que cualquiera pueda promoverse a la marca operable — una sola fuente por sí sola nunca es suficiente en operación normal. Esta es toda la razón por la que la plataforma se niega a tratar "el precio existe" como lo mismo que "el precio es operable".
El runtime explícitamente no busca maximizar el número de publicadores que contribuyen. El objetivo es el opuesto: mantener exactamente una ruta de referencia defendible en vivo por mercado en cada segundo dado, con una escalera de fallbacks pre-validada detrás para failover. Cuando una familia se debilita — Hermes pierde un publicador, un endpoint HTTP se atasca, la desviación se ensancha más allá de la tolerancia — el mux o cambia a la ruta redundante, restringe la postura o saca el mercado del trading normal. La conveniencia no es una razón válida para seguir operando con un conjunto de fuentes adelgazado.
El motor luego promueve la referencia aceptada a una marca operable en lugar de operar contra el tick crudo. El anclaje de referencia, el skew de la plataforma, la postura del spread, las comprobaciones de depth, los topes de continuidad max-move y los límites de drift respecto a la marca previa se acumulan en capas para que el precio contra el que realmente ejecuta el motor de matching refleje lo que Dexter puede llenar responsablemente — no lo que el índice externo imprime en ese instante. El funding, la liquidación y las comprobaciones de drawdown del motor de reglas leen todos la misma marca operable. La política completa de ingreso-a-marca vive en Fuentes y fallback; los detalles de construcción de marca y la lista de parámetros viven en Construcción de marca.
| Check | Purpose |
|---|---|
| Ventana de freshness | Una referencia más antigua que el tope de staleness por mercado se rechaza antes de que pueda marcar equity o disparar un stop |
| Acuerdo de fuentes y límites de desviación | El primario y el cross-check deben coincidir dentro de la banda de desviación configurada; un único publicador descontrolado no puede arrastrar la marca por sí solo |
| Comprobaciones de depth y spread | Si el libro de la plataforma está delgado o el spread se dispara, la marca se ensancha o el mercado se degrada — los libros delgados nunca definen el precio operable |
| Lag de recuperación | Tras una ventana degradada o obsoleta, el mercado no vuelve a live en el momento en que aparece un tick fresco — primero debe pasar un periodo de estabilización |
entran referencias externas
-> comprobaciones de mux y política de fuente
-> validación de freshness y desviación
-> construcción de marca a partir de referencia + estado de la plataforma
-> actualización de postura del mercado
-> el contexto de fuente de oracle se publica con el siguiente estado de settlement#Postura de precio y honestidad de sesión
Las comprobaciones de freshness, acuerdo, depth y recuperación anteriores alimentan directamente la máquina de estado del mercado. Cada mercado de Dexter vive en una de cinco posturas en cualquier momento: live (trading normal de dos lados), reduced (topes más estrechos, spread más amplio, apalancamiento máximo más bajo), close-only (las posiciones abiertas pueden reducirse pero no se permite nueva exposición), session-closed (fuera de horario para el mercado subyacente) y halted (sin ejecución, equity congelado en la última marca válida). Estas posturas no son etiquetas indicativas — el motor de matching, el motor de reglas y la caja leen todos el mismo estado.
Los perpetuos cripto corren 24/7, pero los perpetuos de equity, de metales y de energía siguen el calendario de la plataforma subyacente. Un perpetuo de equity en session-closed a las 03:00 UTC está sano; un oracle que perdió su ruta primaria a las 03:00 UTC sobre BTC está degradado. Dexter separa deliberadamente los dos para que los usuarios, el motor de reglas y el revisor post-incidente vean todos la misma distinción: off-session es un estado limpio con un tiempo de reapertura publicado, degradado es una pregunta abierta sobre la que la plataforma está trabajando activamente. El calendario de sesiones detallado y las reglas de transición de live a halted se documentan en Sesiones y estados degradados.
La postura de fuente activa — identidad de ruta primaria, engagement de fallback, desviación observada, margen de freshness — se hashea en cada raíz de settlement que publica el runtime. El contrato del vault por tanto sabe no sólo cuáles eran los saldos cuando se incluyó una solicitud de retiro, sino qué configuración de oracle los produjo. Un pago no puede liquidarse silenciosamente contra un feed distinto del que tus operaciones valoraron, porque ambos están ligados por el mismo commitment de raíz.
#Qué significa esto para tu PnL y pagos
- Una sola marca, financiada o pública. Una cuenta financiada 90 / 10, una wallet pública y el motor de ranking de la tabla de clasificación marcan todos contra el mismo precio operable de Hermes/HTTP-mux. No hay un "feed de prop" separado que la plataforma pudiera empujar para forzar a una cuenta a una infracción del -4% diario o sacarla de la revisión del podio top 3 — cada infracción del challenge, cada tick de funding y cada número de PnL es reproducible a partir de datos públicos de oracle más el hash de postura de fuente publicado.
- La postura degradada congela el riesgo nuevo, no tu cuenta. Si el primario y el cross-check discrepan más allá de los límites, o el freshness se desliza, el mercado cae a reduced o close-only. Aún puedes recortar tamaño; no puedes añadir nueva exposición hasta que el mercado vuelva a live. El motor de reglas estampa la ventana degradada en tu cronograma de evaluación para que las comprobaciones de drawdown -4% diario / -8% total no se disparen por prints obsoletos — pero la capacidad de trading dentro de la ventana de 30 días no se reembolsa.
- Los mercados basados en sesión respetan su calendario. Los perpetuos de equity, metal y energía pasan a session-closed cuando el mercado subyacente está cerrado. El equity se marca al último precio válido de sesión; la regla de drawdown diario se reanuda en la apertura de la siguiente sesión. El ruido nocturno del oracle sobre un mercado off-session no puede hacer fallar tu challenge.
- El settlement está ligado a la misma postura de fuente. Cada liberación de retiro en Base está anclada a una raíz de estado cuyo hash de fuente de oracle coincide con la postura bajo la que tus operaciones valoraron. La caja y el motor de matching no pueden divergir. Los pagos de reparto de beneficios apuntan a menos de 24h desde la solicitud hasta la llegada de USDC; las mecánicas con prueba garantizada se documentan en Settlement y retiros.