# Base enciende Denim con bloques de 200 ms y su blockchain cambia > Base activa Denim el 5 de noviembre a las 18:00 UTC con cinco bloques por segundo, retira Flashblocks y obliga a migrar a las apps que leían estado pendiente. > Por José Maldonado · Ethereum · 2026-10-31 Base ha puesto fecha al cambio que llevaba meses anunciando. El hard fork Denim se activa el jueves 5 de noviembre a las 18:00 UTC y cambia la unidad de tiempo de la red: donde antes había un bloque canónico cada dos segundos, habrá cinco bloques completos por segundo, cada uno con su número, su hash, su raíz de estado y sus recibos. La cifra que resume el salto es sencilla: 2.000 milisegundos pasan a 200. El detalle que convierte esto en una noticia con consecuencias y no en una nota de rendimiento es que Denim jubila Flashblocks, la capa de preconfirmaciones que Base usa desde julio de 2025. Las aplicaciones que se suscriben a esos flujos o que consultan el estado pendiente del bloque dejarán de recibir respuesta después de la activación, y tendrán que pasar a leer bloques canónicos. No es una deprecación a doce meses vista, es el mismo día. Para quien solo usa Base como usuario final, el cambio será invisible o casi. Para quien tiene un indexador, un puente o un bot que consulta el estado antes de que se confirme, la semana del 5 de noviembre es la más movida del año. La red que presume de ser la L2 de referencia para aplicaciones de consumo acaba de pedirles a sus desarrolladores que cambien la forma en que leen la cadena. ## Qué cambia exactamente el 5 de noviembre [La documentación de Base lo describe con precisión](https://docs.base.org/). Denim pasa de producir un bloque canónico cada dos segundos a producir cinco por segundo, y cada uno de esos bloques lleva su número, su hash, su raíz de estado, sus recibos y actualizaciones de forkchoice. Además, cada bloque recorre su propio ciclo de vida: inseguro, seguro y finalizado. Ya no hay un bloque gordo que agrupa transacciones, sino cinco bloques pequeños y completos por segundo. El tiempo también cambia de escala. La cabecera de Ethereum mantiene su marca temporal en segundos, así que Base añade un depósito de metadatos llamado BaseTime que aporta la parte submilisegundo. Con eso, las llamadas RPC devuelven marcas temporales con resolución de milisegundos y las aplicaciones pueden ordenar eventos que antes caían dentro del mismo segundo sin forma de distinguirlos. La consecuencia práctica es que la red gana granularidad. Un mercado que necesita saber qué pasó antes y qué después deja de depender de la posición en una lista dentro de un bloque de dos segundos, y pasa a tener un orden temporal explícito. Para los intercambios y para los sistemas de pagos, ese detalle vale más que el titular de los 200 milisegundos. ## Adiós a Flashblocks y al estado pendiente Flashblocks fue la solución intermedia. Durante más de un año, Base publicó actualizaciones incrementales del estado pendiente de un bloque para que las aplicaciones pudieran mostrar resultados antes de la confirmación. Con Denim esos bloques son canónicos, así que la capa intermedia sobra, y la compañía ha decidido retirarla en lugar de mantener dos formas de hacer lo mismo. Eso deja tres casos rotos si nadie toca el código. Suscribirse a los flujos de Flashblocks, consultar el tag `pending` en llamadas como `eth_getLogs` o `eth_getBlockTransactionCountByNumber`, y cualquier lógica que asuma que el estado pendiente y el último bloque son cosas distintas. La guía de migración de Base enumera cada patrón y su reemplazo, y conviene leerla antes de la fecha, no después. El consejo operativo es hacer inventario antes del 5 de noviembre. Cualquier integración que use el tag pendiente, cualquier webhook que dependa de una preconfirmación y cualquier panel que muestre el estado «antes de confirmar» tiene que revisarse. Si el equipo no sabe qué partes del sistema usan Flashblocks, ese es el primer trabajo y también el más urgente. ## Lo que tienen que tocar los desarrolladores La lista de tareas es corta y específica, que es lo mejor que se puede decir de una migración forzada. Base publicó [una tabla con cada llamada afectada y su sustituto](https://docs.base.org/), y el patrón general es el mismo en todos los casos: dejar de pedir estado pendiente y leer el último bloque canónico, que ahora llega cinco veces por segundo y con la misma latencia que antes tenía la preconfirmación. Patrón afectado Qué pasa tras Denim Qué usar en su lugar Suscripción a Flashblocks Deja de emitir Flujos de bloque canónico Consulta con tag `pending` Sin respuesta válida Último bloque canónico Logs con rango hasta `pending` Rango inválido Rango sobre bloques canónicos Lógica de preconfirmación propia Duplicada Ciclo unsafe, safe y finalized El cuarto punto es el que más trabajo da en equipos grandes. Muchas aplicaciones construyeron su propia capa de «creo que esto va a confirmarse» sobre las preconfirmaciones de Base, y ahora tienen que decidir si la retiran o la reconstruyen sobre los nuevos bloques. En la mayoría de los casos la respuesta correcta es retirarla, porque el bloque de 200 milisegundos ya cumple esa función. ## 200 milisegundos y el problema del histórico Hay un efecto secundario que casi nadie está comentando y que la documentación sí menciona. Al multiplicar por diez el número de bloques por segundo, el histórico que cubre una cantidad fija de bloques se reduce en la misma proporción. Una ventana que antes abarcaba varias horas pasa a cubrir una fracción, y cualquier flujo que dependa de hashes históricos o de raíces de beacon tiene que revisar sus supuestos. Ese detalle afecta a puentes y a sistemas de prueba. Un puente que valida un evento contra un bloque de hace un día tiene ahora diez veces más bloques en medio, y una prueba que espera un número de bloques como proxy de tiempo necesita cambiar de unidad. La documentación avisa de que la cantidad de valores retenidos no cambia, pero la cobertura temporal sí, y esa diferencia es la que provoca errores silenciosos. La solución pasa por dejar de usar el número de bloques como reloj. Base ofrece ahora marcas temporales con resolución de milisegundos, y cualquier lógica que necesite «esperar una hora» debería apoyarse en ellas y no en contar bloques. Es la misma lección que aprendieron las redes que aceleraron su producción en los últimos dos años. ## La carrera por el milisegundo ya no es de Ethereum Lo interesante de Denim no es el número, sino quién lo está poniendo. [Base compite con Solana](https://observatorioblockchain.com/blockchain/solana-alpenglow-consenso-150ms-finalidad/), que lleva meses vendiendo finalidad en cientos de milisegundos, y con las L2 que prometen confirmaciones cada vez más rápidas. Que una red construida sobre Ethereum dé el salto a los 200 milisegundos sin abandonar la capa uno dice bastante sobre dónde se está librando la pelea por las aplicaciones. El coste de ese salto es de complejidad para el ecosistema. Cada aceleración cambia supuestos que los desarrolladores dieron por buenos, y cada cambio de supuesto rompe integraciones que nadie está mirando. La red gana velocidad y el ecosistema paga en mantenimiento, un intercambio que se ha vuelto habitual en los últimos dos años. Si tienes una aplicación en Base, el calendario ya está fijado y no hay margen para esperar a ver qué pasa. Si solo usas la red para mover fondos, no notarás nada salvo que todo vaya un poco más rápido. Y si trabajas en otra L2, la fecha del 5 de noviembre es una buena excusa para revisar cuánta de tu lógica asume dos segundos por bloque.