Original | Odaily Planet Daily (@OdailyChina)
Autor | Azuma (@azuma_eth)
En la comprensión convencional, el tiempo es lineal, pero el mundo cripto tiene una "excepción".
Ayer, la hora del este (ET) completó, como es habitual (generalmente a las 2:00 a.m. del segundo domingo de marzo), el cambio de horario de invierno a horario de verano, adelantando el reloj una hora, saltando directamente de las 2:00 del 8 de marzo a las 3:00. El tiempo no se esfumó, simplemente la región de la costa este de EE.UU. cambia según la costumbre entre el horario estándar del este (EST) y el horario de verano del este (EDT), con el objetivo de ajustar artificialmente la escala de tiempo para aprovechar mejor las horas de luz diurna (y de paso ahorrar electricidad).
Para la vida cotidiana de las personas, este cambio no tiene un gran impacto, pero en el mercado de predicciones Polymarket, el cambio de horario de ayer provocó directamente una controversia inesperada.
Polymarket se topa con una controversia de cronometraje
La controversia ocurrió en el evento de predicción de "subidas y bajadas de criptomonedas" en Polymarket.
Polymarket ofrece eventos de predicción de subidas y bajadas de criptomonedas con rangos de tiempo anual, mensual, semanal, diario, de 4 horas, de 1 hora, de 15 minutos y de 5 minutos, admitiendo tokens principales como BTC, ETH, SOL, XRP, etc. Estos eventos se crean y liquidan automáticamente según la hora del este (ET), y se han convertido en una fuente importante de volumen de negociación en Polymarket.
A la 1:00 a.m. del 8 de marzo (aún en horario de invierno ET), Polymarket lanzó nuevos eventos de predicción de subidas y bajadas de 1 hora para BTC, ETH, SOL, XRP. Los enlaces a los eventos son los siguientes.
- BTC (resultado final: subida): https://polymarket.com/event/bitcoin-up-or-down-march-8-1am-et
- ETH (resultado final: bajada): https://polymarket.com/event/ethereum-up-or-down-march-8-1am-et
- SOL (resultado final: bajada): https://polymarket.com/event/solana-up-or-down-march-8-1am-et
- XRP (resultado final: bajada): https://polymarket.com/event/xrp-up-or-down-march-8-1am-et
Según las reglas de determinación del evento — comparando el precio de apertura y el precio de cierre de la vela de 1 hora desde el inicio del evento en el par USDT de Binance — los cuatro eventos mencionados ya se han liquidado.
Sin embargo, dado que la hora de finalización de este lote de eventos coincidió con el cambio al horario de verano, la hora del este saltó directamente a las 3:00 en el instante en que llegó a las 2:00 (es decir, se saltó el período de 2:00 - 3:00), lo que causó cierto caos en el cronometraje de este lote de eventos por parte de la plataforma Polymarket.
Como muestra la interfaz frontal de Polymarket, posiblemente porque las 2:00 no existieron ayer en la cronología de la hora del este, el período de tiempo que muestra actualmente este lote de eventos es "March 8, 1-1 AM ET" (es decir, 8 de marzo, 1:00 - 1:00), pero en un estado de cronometraje normal, este tipo de eventos debería mostrar un período de tiempo de 1 hora (por ejemplo, el evento similar del día anterior era "March 7, 1-2 AM ET", es decir, 1:00 - 2:00), y si se tiene en cuenta el impacto del cambio de horario de verano, el período de tiempo más razonable para este lote de eventos debería ser "March 8, 1-3 AM ET" (es decir, 1:00 - 3:00, que en esencia sigue siendo 1 hora).
Así que, mirese como se mire, el "March 8, 1-1 AM ET" que muestra actualmente el frontend es muy extraño.
El usuario de la zona china "小Z" (@richrichardoz) publicó en X al respecto, diciendo que, además del frontend, la API de Polymarket también mostraba el período de tiempo "1-1 AM ET", lo que provocó que los programas automáticos que dependen de los datos devueltos por la API "explotaran por completo", estimando pérdidas de más de 100, 000 dólares debido a esto.
"小Z" añadió explicando que la hora de inicio y la hora de finalización son exactamente iguales, un estado de mercado lógicamente imposible. Muchos sistemas de trading automatizado dependen del tiempo de finalización (end time) para determinar la ventana de trading, y este error hizo que su programa perdiera una gran suma de dinero. Por lo tanto, sugirió que Polymarket cambie el estándar de tiempo de los eventos relevantes a la hora UTC e indemnice a los usuarios afectados por el problema de datos.
Además de este usuario, muchos usuarios externos también han comentado en los eventos relevantes expresando su confusión, pero hasta la publicación de este artículo, Polymarket aún no ha respondido a través de canales oficiales.
El estándar de tiempo en los mercados financieros tradicionales
Mirando hacia atrás en esta controversia, aunque la escala del impacto no es muy grande, expuso un defecto de diseño subyacente en los eventos del "mercado de subidas y bajadas de criptomonedas" de Polymarket.
Debido a factores como las costumbres históricas, la posición económica y las prácticas de la industria, la hora del este (ET) todavía se usa ampliamente en diversos sectores. Pero esto en realidad no es amigable para los sistemas financieros, porque la hora del este cambia cada año entre el horario de verano y el de invierno — es decir, adelanta o retrasa artificialmente el reloj una hora en momentos específicos, creando respectivamente "saltos" y "superposiciones" de tiempo.
En los sistemas financieros modernos, la hora UTC se ha convertido desde hace tiempo en el estándar universal de facto. En la gran mayoría de las infraestructuras financieras, los sistemas internos suelen utilizar la marca de tiempo UTC como el único estándar de tiempo, mientras que la hora local, como la hora del este, aunque todavía se utiliza, a menudo existe a nivel lógico solo en la capa de visualización orientada al usuario. Este diseño es precisamente para evitar la incertidumbre del sistema de tiempo, asegurando que en las transacciones financieras, la liquidación y los sistemas automatizados, el tiempo siempre se mantenga monótono, único y globalmente consistente.
La contradicción clave de esta controversia de Polymarket radica en que los eventos relevantes utilizaron la hora del este como estándar de cronometraje, pero no consideraron adecuadamente las variables potenciales traídas por el cambio de horario de verano, lo que finalmente causó confusión en los datos del frontend y la API. En la base de usuarios actual del mercado de predicciones, cada vez más participantes realizan transacciones a través de API y programas automatizados, por lo que algunos pequeños problemas que originalmente solo afectaban la visualización frontal pueden amplificarse fácilmente en sistemas automatizados y convertirse en pérdidas reales de fondos.
Visto el resultado, esta controversia quizás no sea un accidente grave, y en teoría solo puede ocurrir dos veces al año como máximo, pero lo que revela es un problema de diseño más serio: a medida que los mercados de predicción se convierten gradualmente en infraestructura financiera, también deben seguir los estándares de ingeniería adoptados por la infraestructura financiera.
