Federico Carrone

Ganamos las elecciones en la Facultad de Ingeniería de la UBA

mail@fcarrone.com (Federico Carrone) — Tue, 20 Oct 2026 00:00:00 +0000

Acabo de aterrizar en Buenos Aires. Ayer estaba en Cambridge en workshops de Ethereum sobre criptografía post-cuántica, verificación formal y finalidad rápida (fast finality). Hoy volví a casa para un hito que llevó dieciocho años.

Resolver el fútbol como si fuera ajedrez

mail@fcarrone.com (Federico Carrone) — Sun, 05 Jul 2026 00:00:00 +0000

El fútbol europeo se pasó los últimos quince años resolviendo el juego como si fuera ajedrez.

Una generación de entrenadores optimizó el porcentaje de pases acertados, los gatillos de presión, el control territorial, las vigilancias y la ocupación posicional. El problema es que optimizaron lo medible. Atacar el espacio temprano, intentar el pase difícil, gambetear a un defensor, generar caos a propósito: son jugadas de alta varianza. Salen mal más veces de las que salen bien. Si evaluás a los jugadores por porcentaje de acierto, retención de la pelota o disciplina posicional, esas acciones parecen errores. Entonces los técnicos se las sacan. Con el tiempo, todos convergen hacia el mismo óptimo local.

Etiquetas nutricionales para la confianza

mail@fcarrone.com (Federico Carrone) — Sat, 13 Jun 2026 00:00:00 +0000

Vitalik Buterin quiere etiquetas nutricionales de confianza para el software. Concrete muestra cómo se ve la mitad de máquina y matemática cuando la produce el compilador en lugar de un proveedor que escribe prosa.

Una prueba vale lo que vale su spec

mail@fcarrone.com (Federico Carrone) — Sat, 06 Jun 2026 00:00:00 +0000

Quiero que Ethereum tenga más verificación formal, no menos. Por eso escribo esto.

La disciplina sin amor optimiza la variable equivocada

mail@fcarrone.com (Federico Carrone) — Thu, 21 May 2026 00:00:00 +0000

El último año y medio, pero sobre todo los últimos seis meses, fueron increíbles pero también muy, muy duros. Pasé por problemas personales difíciles y tuve que ampliar mi tolerancia al dolor hasta extremos que no sabía que existían. Al dolor no lo combatís endureciéndote. Lo combatís controlando qué dejás que se te acerque. Dejé el alcohol, bajé el café al mínimo indispensable, borré mi Instagram y saqué de mi vida a la mayoría de la gente que no me importaba, y redoblé la apuesta por vivir con los amigos, la familia y las parejas que amo.

Mi papá me dijo varias veces que viví varias vidas en una. Es muy probable que él tenga algo de responsabilidad en esto, porque de chico me obsesioné con las aventuras gracias a Julio Verne. Quería explorar. Viajé a lugares y conocí gente que solo ves en pesadillas. Después de quemarme y casi morirme varias veces creé LambdaClass</a> y ahora Ergodic Group</a>. Esas veces que casi me muero no fueron solo dolor. Cada una me enseñaba lo mismo: convertí esto en algo que te sobreviva, o fue solo daño. Estoy tratando de hacer lo mismo ahora con lo que me pasó las últimas semanas.

Blockspace Forum Cannes: Fede y Justin Drake

mail@fcarrone.com (Federico Carrone) — Wed, 22 Apr 2026 00:00:00 +0000

Conversación con Justin Drake en el Blockspace Forum Cannes

Un compilador que produce hechos

mail@fcarrone.com (Federico Carrone) — Thu, 09 Apr 2026 00:00:00 +0000

Nota de la serie: este artículo es parte de la serie Concrete y responde a Giving LLMs a Formal Reasoning Engine for Code Analysis</a>, de Dmitri Sotnikov. Relacionados: Cuando el compilador es el oráculo</a> y Por qué existe Concrete</a>. </blockquote>
Cuando un agente de IA explora una base de código, normalmente hace grep de nombres, lee algunas coincidencias, busca quién llama a qué, lee eso, y trata de armarse un modelo mental del programa a partir de fragmentos de texto. Funciona más o menos tan bien como te imaginás. El agente está haciendo preguntas estructurales sobre un programa, cosas como “¿puede la entrada del usuario llegar a esta consulta SQL?” o “¿qué cambia si toco esta función?”, pero la única herramienta que tiene es la búsqueda de texto.
Ayer leí el artículo</a> de Dmitri Sotnikov sobre darles a los LLMs un motor de razonamiento simbólico para analizar código. Su herramienta, Chiasmus</a>, parsea código fuente con tree-sitter (un parser sintáctico), convierte definiciones y llamadas en hechos lógicos, y deja que un LLM corra consultas (queries) sobre grafos en lugar de hacer grep por los archivos. Es una interfaz mucho mejor: el agente hace una pregunta estructural y recibe una respuesta estructural.
Leer el post me dio una mejor frase para parte de lo que estamos construyendo con Concrete: un compilador que produce hechos (fact-producing compiler).
Concrete es el lenguaje de programación de sistemas que estamos construyendo para programas que necesitan ser auditables. Compila el código a un ejecutable y a afirmaciones verificadas sobre lo que ese ejecutable puede hacer.

CommitLLM: cómo verificar una inferencia de un LLM

mail@fcarrone.com (Federico Carrone) — Thu, 02 Apr 2026 00:00:00 +0000

Mandás un prompt a una API de un LLM. El proveedor dice que corrió Llama 70B. Tal vez lo hizo. Tal vez sirvió un modelo más chico para ahorrar plata, cambió la cuantización, modificó la configuración de decodificación o retocó la respuesta después de generarla. Hoy en general no tenés forma de saberlo. Recibís texto, una factura y una promesa.
Para un uso casual, una promesa muchas veces alcanza. Para compras empresariales, sistemas regulados, evaluación de benchmarks o flujos de agentes que toman decisiones con consecuencias, no alcanza. Si importa qué modelo está detrás de la respuesta, “confiá en nosotros” no es una interfaz satisfactoria.

Lo que Concrete empeora

mail@fcarrone.com (Federico Carrone) — Tue, 24 Mar 2026 00:00:00 +0000

Nota de la serie: esta es la entrega sobre las concesiones (tradeoffs) en la serie Concrete. Para los fundamentos, empezá por Por qué existe Concrete</a>. Para la demo más práctica, leé Cuando el compilador es el oráculo</a>. </blockquote>
Los artículos anteriores de esta serie sostuvieron que las restricciones de diseño de Concrete valen la pena. Las capabilities (capacidades) explícitas hacen que el código sea auditable. Los tipos lineales evitan fugas de recursos en tiempo de compilación. Que no haya comportamiento oculto significa que el compilador puede informar lo que tu programa realmente hace. Creo todo eso. Pero hace suficiente tiempo que escribo código en Concrete como para saber dónde muerden las restricciones, y no fui lo bastante honesto sobre eso en público.
Este artículo es sobre lo que Concrete empeora. No en teoría, no como un abstracto “es más estricto”. Código concreto que es más feo, más largo o más penoso de escribir en Concrete que en Rust o Zig. Si estás evaluando si estas concesiones valen la pena para tu dominio, merecés ver el costo de entrada.

Cuando el compilador es el oráculo

mail@fcarrone.com (Federico Carrone) — Fri, 20 Mar 2026 00:00:00 +0000

Nota de la serie: esta es la puerta de entrada más práctica a la serie sobre Concrete. Si primero querés el manifiesto más corto, leé Por qué existe Concrete</a>. Si querés la referencia del lenguaje que está detrás de este artículo, usá la especificación de Concrete</a>. </blockquote>
Hace un tiempo que vengo construyendo Concrete</a>. Esta semana pasó algo que no tenía planeado, y puede terminar importando más que las cosas que me propuse construir a propósito.
Dejé que un agente de IA mejorara un programa en Concrete usando como feedback solamente los reportes del compilador. Sin profiler. Sin benchmarks. El agente leía lo que el compilador sabía del programa, probaba refactorizaciones, verificaba si las respuestas del compilador mejoraban, y se quedaba con el cambio o lo revertía. Funcionó mejor de lo que esperaba. El compilador había dejado el espacio de búsqueda lo suficientemente limpio como para que el agente no tuviera que andar a ciegas entre la niebla de los benchmarks.
Eso apunta a por qué Concrete es útil en primer lugar. Un lenguaje que hace explícitas la autoridad, la asignación de memoria (allocation), las fronteras de confianza (trust boundaries) y la superficie de prueba es más fácil de auditar, más fácil de optimizar y más fácil de automatizar. No tenés que reconstruir la verdad a partir de trazas de profiler, documentación desactualizada e intuición de los revisores. El compilador te puede decir qué es cierto sobre el programa, y eso cambia cómo construís software de sistemas. Para explicar por qué, tengo que empezar por qué es Concrete y qué lo hace distinto.

Tus primeras demostraciones en Lean

mail@fcarrone.com (Federico Carrone) — Fri, 20 Mar 2026 00:00:00 +0000

El primer artículo</a> de esta serie explicó la correspondencia de Curry-Howard: las proposiciones son tipos, las demostraciones son programas. El segundo</a> construyó un demostrador de teoremas (theorem prover) diminuto desde cero en Python. El tercero</a> metió las mismas ideas dentro del sistema de tipos de Julia.
Ahora usamos la herramienta de verdad. Este artículo toma exactamente los mismos teoremas que demostraste a mano en Python y los muestra en Lean 4. Vas a ver qué cambia y qué queda igual: la sintaxis se mueve, la lógica no.

Programar un mini-Lean en el sistema de tipos de Julia

mail@fcarrone.com (Federico Carrone) — Thu, 19 Mar 2026 12:00:00 +0000

Este artículo está basado en la charla de Guillermo Angeris “Programming a (mini-)Lean in Julia’s type system”</a>.
Un demostrador de teoremas (theorem prover), reducido a su motor, es un kernel de confianza chiquito, un type checker y una frontera entre los dos.
Guillermo Angeris responde a esto programando en vivo, dentro de Julia, un kernel de juguete para demostrar teoremas que ilustra cómo funciona Lean en términos de arquitectura. El resultado es un kernel chiquito que hace visible la frontera de confianza: si aceptás el kernel, entonces todo lo que se construya encima tiene que pasar por el type checker.
Este es el tercer artículo de la serie Demostración de teoremas</a>. El primer artículo</a> cubre la correspondencia de Curry-Howard. El segundo</a> implementa un demostrador chiquito de forma explícita en Python. Este artículo mete esas mismas ideas dentro del sistema de tipos de un lenguaje anfitrión.

Construyendo un pequeño demostrador de teoremas en Python

mail@fcarrone.com (Federico Carrone) — Thu, 19 Mar 2026 00:00:00 +0000

El primer artículo</a> de esta serie explicó la correspondencia de Curry-Howard: las proposiciones son tipos, las demostraciones son programas. Eso te dice por qué la demostración de teoremas encaja tan naturalmente con los lenguajes de programación. Todavía no te dice cómo es la máquina.
Un demostrador de teoremas (theorem prover), en concreto, es más chico de lo que la mayoría espera. Un pequeño demostrador de teoremas es apenas:

un lenguaje para términos</li>
un lenguaje para tipos / proposiciones</li>
un checker que decide si un término tiene un tipo</li>
un kernel de confianza, chiquito, que define las jugadas legales</li> </ol>
Este artículo construye esa arquitectura en Python puro. No estamos abusando del propio sistema de tipos de Python. Python es solo el lenguaje de implementación. El demostrador que construimos tiene sus propios términos, sus propias proposiciones y su propio checker.
Esa distinción importa. El objetivo acá no es lucirse con trucos del lenguaje anfitrión. Quiero que las piezas móviles sean imposibles de pasar por alto.

Programas autorreplicantes que emergen del ruido aleatorio

mail@fcarrone.com (Federico Carrone) — Wed, 18 Mar 2026 00:00:00 +0000

La mayoría de los programadores piensa que la Turing completitud (Turing completeness) es el umbral interesante para un sistema computacional. Se lleva toda la atención. Pero hay un umbral más bajo y más raro que importa más para el origen del comportamiento complejo: la autorreplicación.
Un paper reciente</a> de Agüera y Arcas et al. muestra que los programas autorreplicantes emergen espontáneamente de sopas de código aleatorio. Nadie los diseña. Ninguna función de fitness los selecciona. Se arman solos a partir del ruido, toman la sopa y siguen evolucionando. Reproduje el resultado central en unas 300 líneas de código.

Las proposiciones son tipos, las demostraciones son programas

mail@fcarrone.com (Federico Carrone) — Wed, 18 Mar 2026 00:00:00 +0000

En la década de 1930, Haskell Curry notó algo raro. Estaba trabajando en lógica combinatoria, un sistema para manipular funciones abstractas, y se dio cuenta de que las reglas que gobernaban sus combinadores se veían idénticas a las reglas de un sistema lógico llamado lógica proposicional intuicionista. Era como si hubiera encontrado dos mapas distintos del mismo territorio.
Tres décadas después, William Howard encontró lo mismo en un contexto más rico. Mostró que el cálculo lambda simplemente tipado, la base de la programación funcional, se corresponde exactamente con la deducción natural, un sistema estándar de demostración lógica. Cada tipo corresponde a una proposición. Cada programa corresponde a una demostración. Cada función corresponde a una implicación.
Esta es la correspondencia de Curry-Howard: una identidad estructural entre demostraciones y programas.

La guía de Fede para una vida más sana

mail@fcarrone.com (Federico Carrone) — Fri, 13 Mar 2026 00:00:00 +0000

De chico me encantaban la ciencia y la ingeniería. Como la mayoría de los nerds, pensaba que lo único que importaba era pensar. Entrenar me parecía un proyecto de vanidad, algo para gente a la que le importaba cómo se veía y poco más. No entendía para nada la conexión entre el cuerpo y la mente. Era un pibe flaco que se pasaba el día leyendo, metiéndose con computadoras y saliendo con amigos. La idea de que la salud física pudiera afectar lo bien que pienso me habría sonado a disparate.
Me llevó mucho tiempo darme cuenta de lo equivocado que estaba.

¿Puedo probar programas de Concrete en Lean?

mail@fcarrone.com (Federico Carrone) — Thu, 12 Mar 2026 00:00:00 +0000

Nota de la serie: esta es la entrega sobre la hoja de ruta de pruebas en la serie Concrete. Para una visión general del lenguaje, empezá por Por qué existe Concrete</a> y la Especificación de Concrete</a>. Para la demo más práctica de los reportes del compilador, leé Cuando el compilador es el oráculo</a>. </blockquote>
Escribí la primera versión de este ensayo cuando probar programas de Concrete</a> en Lean todavía era sobre todo un plan. La pregunta era simple y un poco arriesgada: ¿podemos tomar una función escrita en Concrete, conectarla con algo dentro del compilador y probar una propiedad real sobre ella en Lean?
Parte de esa respuesta ya existe. No para todo el lenguaje, y no para el binario final, pero sí para un subconjunto real. Concrete puede tomar un contrato en el código fuente (source contract), convertirlo en una obligación, adjuntarle una prueba verificada por Lean o el resultado de un procedimiento de decisión, y avisarte cuando esa evidencia ya no coincide con el código. Lo importante no es que cada afirmación se ponga en verde. Es que la herramienta se niega a mezclar “probado”, “asumido”, “trusted” y “todavía no hecho”.

Diseñar un lenguaje de programación para la era de la IA

mail@fcarrone.com (Federico Carrone) — Wed, 11 Mar 2026 00:00:00 +0000

Nota de la serie: este artículo da por sentado el marco básico de Concrete y se hace una pregunta más acotada sobre la adopción de lenguajes en la era de la IA. Para la base de la serie, leé Por qué existe Concrete</a>. Para la comparación principal con Rust, leé El debate sobre efectos en Rust y el argumento de Concrete a favor de un lenguaje más chico</a>. </blockquote>
Edgar Luque escribió hace poco sobre cómo la IA crea una nueva barrera de adopción para los lenguajes de programación</a>. Su argumento es que los asistentes de código con IA necesitan datos de entrenamiento, que los datos de entrenamiento solo existen para los lenguajes populares, y que entonces los lenguajes nuevos tienen mal soporte de IA, lo que impide su adopción, lo que a su vez impide que se acumulen datos de entrenamiento. Un ciclo que se refuerza solo y deja atornillado lo que ya domina.
Si estás construyendo un lenguaje nuevo de propósito general que compite con Python, Go o Rust más o menos en los mismos términos, el análisis de Luque es demoledor. Lo que lo hace peor que las barreras de adopción anteriores es que no podés salir de esto a fuerza de esfuerzo comunitario. Los pipelines de entrenamiento de IA son de un puñado de empresas, y esas empresas siempre van a priorizar los lenguajes donde ya existe más data.
Pero hay un punto ciego en el argumento.

El debate sobre efectos en Rust y el argumento de Concrete a favor de un lenguaje más chico

mail@fcarrone.com (Federico Carrone) — Mon, 09 Mar 2026 00:00:00 +0000

Nota de la serie: esta es la entrada principal de comparación con Rust en la serie sobre Concrete. Si recién llegás, empezá por Por qué existe Concrete</a>. Si querés la referencia del lenguaje, usá la Especificación de Concrete</a>. </blockquote>
Yosh Wuyts escribió hace poco sobre su “gran visión” para Rust</a>, donde plantea tres direcciones que cree que el lenguaje debería seguir: efectos, tipos subestructurales más fuertes y tipos refinados (refinement types). El hilo de Hacker News</a> que vino después se dividió de manera previsible: un bando vio tomar forma un lenguaje de sistemas más seguro y con más principios, mientras el otro vio ecos de Scala, de C++ y de un lenguaje que se vuelve más difícil de leer que el software que pretende aclarar.
Los dos bandos están viendo algo real, y creo que resolver la tensión entre ellos requiere algo distinto de agregarle más features a Rust. Ahí es donde entra Concrete</a>.

Disolución sin construcción

mail@fcarrone.com (Federico Carrone) — Fri, 06 Mar 2026 00:00:00 +0000
Cada tecnología de coordinación anterior que disolvió una forma de ser uno mismo también cultivó la siguiente. Los sistemas algorítmicos actuales solo disuelven. El problema es el desfase de velocidades.

La legibilidad mata lo que mide

mail@fcarrone.com (Federico Carrone) — Tue, 03 Mar 2026 00:00:00 +0000

En el siglo XVIII, los forestales alemanes inventaron la silvicultura científica. Miraron un bosque desordenado y diverso y vieron ineficiencia. Árboles viejos, árboles jóvenes, madera muerta, sotobosque, especies sin valor comercial. Limpiaron todo y plantaron píceas de Noruega en filas rectas, con la misma separación, de la misma edad, de la misma especie. El bosque se volvió legible. Se lo podía medir, administrar, predecir su rendimiento con precisión.
Durante una generación, funcionó de maravilla. Los rendimientos se dispararon. Después el bosque empezó a morirse. El sotobosque complejo hacía circular los nutrientes, retenía la humedad, alojaba a los insectos que polinizaban el dosel y a los hongos que alimentaban las raíces. Los forestales no habían simplificado el bosque; habían destruido el sistema que lo mantenía vivo, y conservado solo la parte que podían ver.
James Scott cuenta esta historia en Seeing Like a State para ilustrar un patrón que se repite cada vez que una autoridad central le impone legibilidad a un sistema complejo. El patrón es simple: volvés legible lo ilegible, optimizás lo que ahora podés ver y perdés lo que no podías ver pero de lo que dependías.

Las finanzas son geometría, y todo vuelve a la desigualdad de Jensen

mail@fcarrone.com (Federico Carrone) — Sun, 01 Mar 2026 00:00:00 +0000

Nunca cruces un río que tiene en promedio cuatro pies de profundidad. Si el río tiene ocho pies de profundidad en el medio y está seco en los costados, el promedio no te dice nada sobre si te vas a ahogar. Te vas a ahogar en el medio, o no. No existe un promedio entre universos paralelos en los que sobrevivís y morís a la vez.
La misma asimetría aparece en todos lados donde los resultados se capitalizan. Si perdés el 50% de tu riqueza, necesitás una ganancia del 100% solo para salir hecho, porque la pérdida golpea sobre una base más grande que aquella desde la que se construye la recuperación. Pasar de $100 a $200 y de $200 a $400 son montos distintos en dólares pero el mismo movimiento proporcional: una duplicación. La riqueza es una cuestión de razones y de escala, no de diferencias absolutas.
Esta estructura multiplicativa tiene consecuencias más profundas de lo que sugiere la intuición. La matemática que gobierna la supervivencia en entornos de capitalización compuesta se inventó hace 400 años para ayudar a los astrónomos a multiplicar números grandes, se redescubrió en parte en el siglo XVIII para resolver una paradoja sobre el juego, se formalizó de nuevo a través de la teoría de la información y después quedó en gran medida tapada por teorías que optimizaban a través de mundos hipotéticos en lugar de a lo largo de un único camino en el tiempo.
Esa es la afirmación geométrica de este ensayo: la riqueza evoluciona de forma multiplicativa, mientras que la mayor parte de la intuición común es aditiva. El logaritmo es el cambio de coordenadas que nos permite movernos entre esas dos descripciones.
Esta es la historia de por qué la geometría está en el centro de las finanzas, de por qué una sola desigualdad ata todo el cuadro y de por qué reducir la varianza puede valer más que aumentar los retornos.
Ninguna de las partes es mía. Kelly, Peters, Spitznagel y Taleb resolvieron cada uno una de ellas. Lo único que afirmo es que son el mismo cuadro, y este ensayo muestra cómo encajan las piezas.

El debate sobre la cobertura de colas: Spitznagel tiene razón, AQR responde la pregunta equivocada

mail@fcarrone.com (Federico Carrone) — Thu, 26 Feb 2026 00:00:00 +0000

Los mercados de acciones se derrumban</a>. El índice de precios del S&P 500 cayó alrededor de 57% entre el 9 de octubre de 2007 y el 9 de marzo de 2009, y alrededor de 34% entre el 19 de febrero de 2020 y el 23 de marzo de 2020. Una opción de venta (put option) es un contrato que te paga cuando el mercado cae por debajo de cierto precio (el “strike”, o precio de ejercicio). Si tenés acciones y también tenés puts, los puts pueden compensar parte de tus pérdidas durante un crash. La pregunta es si el costo de comprar puts vale la protección que dan.
Hay dos bandos. AQR Capital Management publicó “Chasing Your Own Tail (Risk)”</a> (Berger, Nielsen y Villalon, 2011</a>). Sostienen que comprar puts de forma sistemática cuesta más de lo que ahorra. Del otro lado, Mark Spitznagel, de Universa Investments, donde Nassim Taleb es asesor científico, sostiene que una asignación chica a puts mejora los retornos de largo plazo (Spitznagel, 2021</a>). Universa reportó una ganancia de 3.612% en marzo de 2020 (en una carta a inversores, según informó Bloomberg).
Pusimos a prueba las dos afirmaciones con nuestro backtester de opciones de código abierto</a> sobre 17 años de datos reales de opciones sobre SPY (2008 a 2025), que cubren tres crashes: la crisis financiera de 2008, el COVID y el mercado bajista de 2022.
La versión de la operación que sobrevive a los datos es acotada pero real: convexidad barata, en tamaño chico y elegida por strike y no por delta. La crítica publicada de AQR no prueba ninguna de las dos mitades. Usan puts cerca del dinero (la forma más cara de protección contra crashes por dólar de nocional) dentro de un enfoque que reduce la asignación (vender SPY para financiar los puts, resignando la prima de riesgo de las acciones que financia todo lo demás). En esa configuración, los puts muy fuera del dinero (deep OTM) siguen perdiendo contra SPY. El overlay financiado externamente (externally funded overlay) de Spitznagel invierte las dos elecciones: puts deep OTM, que se mantienen baratos, montados encima de una exposición completa a SPY, en tamaño chico. Dentro de esa configuración, la estrategia muestra una brecha bruta histórica positiva contra SPY a lo largo de la ventana 2008-2024: chica a la escala de 0,5%/año que describe Universa (~+1,4pp/año) y sustancial en el punto óptimo ajustado por riesgo del motor (+6pp/año con un presupuesto de 3,3%/año y roll bimestral). La ventaja depende del régimen: paga en las ventanas de 5 años que contienen un drawdown grande y resta 2-3pp/año en las que no.
Todos los números principales que siguen son antes de costos de transacción, slippage e impuestos. El lastre de ejecución en los strikes deep OTM, la objeción más fuerte de Israelov que sigue en pie, va por encima de estos números brutos; volvemos sobre eso en la sección de limitaciones.
#</a>Qué afirma realmente la tesis</h3>
Spitznagel no afirma que comprar puts OTM gane todos los años, todos los trimestres o en cada drawdown. Quienes lo leen así, incluida (de forma implícita) la crítica publicada de AQR, discuten con un hombre de paja. Su afirmación real es sobre el largo plazo. Poné una porción chica del capital en puts deep OTM encima de tu cartera de acciones, mantenelos durante los crashes, monetizá el pago convexo cuando llega y, en un horizonte lo bastante largo, capitalizás más rápido que con acciones solas. El mecanismo es que los pagos grandes y raros son lo bastante grandes, y se repiten lo bastante seguido, como para cubrir de sobra el lastre constante de la prima entre uno y otro. El alfa año por año es la prueba equivocada. La capitalización de largo plazo es la correcta.
En esa prueba, los datos dicen que tiene razón. En nuestra muestra de 17 años de SPY, todos los presupuestos de overlay de puts, de 0,5%/año a 10%/año, le ganan a SPY solo tanto en retorno anual como en drawdown máximo. La profundidad de strike que describe Spitznagel (deep OTM, no cerca del dinero) es lo que hace funcionar la operación. El enfoque que describe (financiado externamente, no reduciendo la asignación) es la mitad que AQR se pierde. En todas las configuraciones que funcionan y que probamos más abajo, la estrategia mejora el drawdown máximo entre 10 y 22 puntos porcentuales contra SPY.
Vale la pena nombrar de entrada tres propiedades de los datos, para que la forma del resultado no se confunda con un defecto. Primero, la brecha del período completo se concentra en dos años de diecisiete (2008 y 2020). Eso es exactamente lo que una cobertura de cola está hecha para hacer: quedarse dormida durante años y pagar de forma convexa cuando llega una catástrofe. Segundo, 7 de 13 ventanas móviles de 5 años son negativas. Así se ve un valor esperado positivo cuando los pagos son así de irregulares. Tercero, la validación walk-forward muestra que más o menos la mitad de la brecha dentro de muestra sobrevive fuera de muestra (out-of-sample). Ese es el descuento que hay que aplicar al dimensionar esto para una cartera real, no una refutación del resultado.
La lectura equivocada de todo esto es que la estrategia funciona solo por suerte en los años de crash. La lectura correcta es que la estrategia está hecha para pagar en años como esos y que, con el tiempo suficiente y una frecuencia de crashes realista, los pagos grandes y raros cubren de sobra las pequeñas pérdidas constantes. Esa es la tesis de Spitznagel. Los datos la respaldan.
Cada número que sigue se reproduce con un solo comando contra el motor de código abierto. La sección Código al final tiene la invocación exacta.

Detectar crashes con estadística de colas pesadas

mail@fcarrone.com (Federico Carrone) — Thu, 19 Feb 2026 00:00:00 +0000

Los mercados financieros no siguen distribuciones normales</a>. Es una afirmación sobre frecuencias, no solo sobre teoría: te dice con qué frecuencia pasan los eventos catastróficos. Bajo un modelo gaussiano ingenuo, una crisis de la escala de 2008 cae tan adentro de las colas que los modelos de riesgo estándar la tratan como prácticamente imposible. Pasó un martes.
El problema es que seguimos usando herramientas diseñadas para mundos de colas livianas. Modelos de Valor en Riesgo (Value at Risk, VaR) que asumen normalidad. Métricas de riesgo que tratan el crash de 2008 como un “outlier” en vez de como un rasgo habitual de los retornos financieros.
Armé fatcrash</a>, un toolkit en Rust+Python con 15 métodos clásicos, para probar si los métodos estadísticos de colas pesadas (fat tails) pueden detectar crashes antes de que pasen. La matemática crítica para el rendimiento (ajustes, simulación, todos los estimadores móviles) corre en Rust vía PyO3; todo lo demás (datos, visualización, CLI) es Python.

Veinte siglos de datos financieros: lo que revelan 240 países y 2.000 años

mail@fcarrone.com (Federico Carrone) — Thu, 12 Feb 2026 00:00:00 +0000

En 1252, Florencia acuñó el florín de oro. En pocas décadas se convirtió en la moneda comercial dominante de la Europa medieval. Los comerciantes de Brujas, Venecia y Constantinopla cotizaban precios contra él. Para el 1400, el dominio del florín se había apagado, reemplazado por el ducado veneciano. Después el real español. Después el florín neerlandés. Después la libra esterlina. Después el dólar. Cada transición trajo devaluaciones, defaults y crisis que arruinaron a cualquiera que tuviera la moneda equivocada en el momento equivocado.
Tenemos datos de todo esto. No estimaciones. Tipos de cambio efectivamente registrados, desde 1106. Y no solo tipos de cambio: precios del oro y la plata desde 1257, tasas de interés desde 1311, precios de materias primas desde 1260, PBI per cápita desde el año 1 d. C., ratios de deuda soberana desde 1800 e índices de crisis que cubren dos siglos de pánicos bancarios, colapsos cambiarios y defaults soberanos.
Armé forex-centuries</a>, la colección de código abierto (open source) más completa que existe de datos financieros y económicos de largo plazo. 27 fuentes, más de 1.100 archivos, unos 240 países, veinte siglos. Tipos de cambio, metales preciosos, tasas de interés, precios de materias primas, inflación, PBI, salarios reales, deuda soberana, clasificaciones de régimen y tipos de cambio efectivos reales, todo en un repositorio con un pipeline de build automatizado y análisis reproducible. Hay un job semanal de CI programado para actualizar las fuentes automatizadas; hoy está fallando, así que los datos commiteados son los que dejó la última actualización exitosa. Ningún otro repositorio gratuito combina esta amplitud de clases de activos con esta profundidad histórica. El único producto comparable es Global Financial Data</a> (comercial, con precios institucionales). El objetivo: dar la materia prima para estudiar cómo se comportan las monedas y los sistemas financieros a lo largo de siglos, no de décadas.

La fricción como lujo: qué perdemos cuando la IA nos da lo que queremos

mail@fcarrone.com (Federico Carrone) — Thu, 05 Feb 2026 00:00:00 +0000
La escasez que más importa en un mundo post AGI no va a ser el cómputo ni la energía. Va a ser el deseo mismo.

China intenta commoditizar el complemento

mail@fcarrone.com (Federico Carrone) — Thu, 22 Jan 2026 00:00:00 +0000
¿Qué pasa con la ventaja de Occidente en servicios cuando los modelos de IA potentes son gratis, portables y corren en cualquier laptop?

La guía de Fede sobre sistemas de tipos: de generics a tipos dependientes

mail@fcarrone.com (Federico Carrone) — Thu, 01 Jan 2026 00:00:00 +0000

Cada error de tipos que alguna vez te hizo renegar fue un bug atrapado antes de llegar a producción. Los sistemas de tipos rechazan disparates en tiempo de compilación para que no los descubras a las 3 de la mañana. Pero varían muchísimo en lo que pueden expresar y en las garantías que dan.

Por qué existe Concrete

mail@fcarrone.com (Federico Carrone) — Fri, 26 Dec 2025 00:00:00 +0000

Esta es la pieza fundacional de la serie sobre Concrete. Si primero querés la demostración más práctica, empezá por Cuando el compilador es el oráculo</a>. Si querés la referencia viva del lenguaje, usá la Especificación de Concrete</a>. </blockquote>
La programación de sistemas tiene un problema recurrente. Queremos escribir código cerca de la máquina, pero también queremos poder afirmar cosas fuertes sobre lo que hace ese código. ¿Asigna memoria? ¿Toca la red? ¿Pierde recursos? ¿Se puede auditar sin rastrear veinte funciones auxiliares y tres capas de convenciones de bibliotecas?
La mayoría de los lenguajes responden esas preguntas de forma indirecta. Leés la implementación. Hacés profiling. Inferís a partir del estilo. Confiás en los bloques unsafe</code>, en la documentación y en la disciplina de revisión. Incluso en lenguajes fuertes, mucho de lo que importa de un programa vive fuera del sistema de tipos.
Concrete existe porque creo que ese es el lugar equivocado para detenerse.
Concrete es un lenguaje de sistemas construido alrededor de un único principio organizador: toda propiedad importante que el compilador pueda saber sobre un programa debería ser lo bastante explícita como para que humanos y máquinas puedan actuar directamente sobre ella.
La muerte del yo interior mail@fcarrone.com (Federico Carrone) — Tue, 23 Dec 2025 00:00:00 +0000 La individualidad es una tecnología de coordinación. Surgió en condiciones históricas concretas, y esas condiciones se están debilitando a medida que el cómputo, el capital y los circuitos de retroalimentación automatizados absorben las funciones que antes cumplía. Notas sobre la permanencia, el tiempo y la ergodicidad mail@fcarrone.com (Federico Carrone) — Mon, 15 Dec 2025 00:00:00 +0000 Algunos negocios mejoran con el tiempo. Otros pierden el coraje, los estándares y la memoria. Este texto es sobre esa diferencia. El nuevo backend financiero del mundo mail@fcarrone.com (Federico Carrone) — Tue, 09 Dec 2025 00:00:00 +0000 Ethereum está surgiendo como un backend financiero neutral, que baja el costo de los servicios financieros globales al codificar la propiedad y las obligaciones en infraestructura compartida. La institución que le falta a internet mail@fcarrone.com (Federico Carrone) — Tue, 02 Dec 2025 00:00:00 +0000 Internet abarató el movimiento de la información, pero dejó la propiedad en manos de plataformas y jurisdicciones. Ethereum es un intento de arreglar esa capa faltante. Los próximos 10 años de Ethereum mail@fcarrone.com (Federico Carrone) — Sat, 15 Nov 2025 00:00:00 +0000 Charla en Devconnect sobre los próximos 10 años de Ethereum Gracias al Senado de la Nación Argentina mail@fcarrone.com (Federico Carrone) — Wed, 12 Nov 2025 00:00:00 +0000 El 12 de noviembre de 2025 recibí una Mención de Honor al Valor Científico de la Comisión de Ciencia y Tecnología del Senado argentino. Gracias. La hoja de ruta de rollups nativos de Ethereum, con Justin Drake mail@fcarrone.com (Federico Carrone) — Wed, 01 Oct 2025 00:00:00 +0000 Una charla sobre la hoja de ruta de rollups nativos de Ethereum Doctrina cripto mail@fcarrone.com (Federico Carrone) — Thu, 25 Sep 2025 00:00:00 +0000 Cripto encontró product-market fit donde la confianza es más débil: economías con inflación o censura, y comunidades nativas de internet que necesitan coordinación y mercados programables. Los mercados como puntos fijos reflexivos mail@fcarrone.com (Federico Carrone) — Sat, 14 Jun 2025 00:00:00 +0000 Los mercados son más que agregadores ruidosos de información: las creencias sobre los precios ayudan a determinar los precios, y eso convierte a la reflexividad en un problema de punto fijo con colas pesadas, no ergodicidad e histéresis. La vida como doble punto fijo mail@fcarrone.com (Federico Carrone) — Fri, 13 Jun 2025 00:00:00 +0000 Los sistemas vivos no son puntos fijos en el sentido ingenuo sino atractores robustos y máquinas que se autorreproducen, cuya descripción codificada participa en su propia continuación. Lógica, autorreferencia y teoría de categorías mail@fcarrone.com (Federico Carrone) — Thu, 12 Jun 2025 00:00:00 +0000 Una vez que la aritmética puede codificar sintaxis, un sistema puede actuar sobre descripciones de sí mismo. Ese segundo motor produce oraciones de Gödel, quines, el combinador Y, tipos recursivos y el teorema del punto fijo de Lawvere. Teoría de números y la aritmética de la recurrencia mail@fcarrone.com (Federico Carrone) — Wed, 11 Jun 2025 00:00:00 +0000 Apenas una regla se repite en el tiempo, aparecen los enteros. La recurrencia, la resonancia, las fracciones continuas y la teoría KAM muestran cómo la aritmética decide qué movimientos son estables y cuáles se desarman. Leyes de potencia, Extremistán y no ergodicidad mail@fcarrone.com (Federico Carrone) — Tue, 10 Jun 2025 00:00:00 +0000 La invariancia de escala se vuelve ley de potencia; las leyes de potencia mueven la importancia hacia los extremos; los extremos vuelven inestables los promedios a lo largo del tiempo. Caos, fractales y renormalización mail@fcarrone.com (Federico Carrone) — Mon, 09 Jun 2025 00:00:00 +0000 Cómo la duplicación de período genera caos, por qué aparece la universalidad de Feigenbaum y cómo los fractales se vuelven puntos fijos de mapas de contracción sobre conjuntos. Puntos fijos y atractores mail@fcarrone.com (Federico Carrone) — Sun, 08 Jun 2025 00:00:00 +0000 La base de la escalera: reglas repetidas, sistemas dinámicos, puntos fijos, atractores, cuencas, bifurcaciones, la iteración de Newton y el mapa logístico. Cuando los modelos de riesgo crean riesgo mail@fcarrone.com (Federico Carrone) — Fri, 06 Jun 2025 00:00:00 +0000 El ensayo anterior terminó con la objeción de Taleb. La cola es donde está el riesgo, y la cola es justo la parte de la distribución que los datos se niegan a fijar. Si no podés conocer la probabilidad de la ruina, dejá de hacer como que podés. Cambiá tu exposición. Jón Daníelsson suma una versión institucional, más fría, del mismo argumento. Dice algo más fuerte que “los modelos de riesgo son imprecisos”: en finanzas, el acto de medir el riesgo cambia el riesgo. Un modelo funciona menos como un termómetro que se levanta frente al clima y más como una regla que se les entrega a personas que después operan, cubren, desapalancan, reportan y regulan de acuerdo con ella. El número entra en el sistema que intenta describir. Ese es el giro final de esta serie. Si todos se copian entre sí, los shocks chicos se propagan en cascada. Si todos usan el mismo modelo de riesgo, el modelo mismo se vuelve una de las cosas que copian. Los límites del conocimiento mail@fcarrone.com (Federico Carrone) — Thu, 05 Jun 2025 00:00:00 +0000 Seis ensayos después, tenemos una caja de herramientas. La razón de ramificación de Bouchaud, el tiempo crítico de Sornette, el multiplicador de flujos de Gabaix y Koijen, la desaceleración de Scheffer: instrumentos distintos, todos apuntados a la misma condición, un sistema cargado cerca de su borde. Este ensayo trata sobre la trampa que estuvo sentada en la sala todo este tiempo. Esa condición, la distancia al borde, es lo más difícil de fijar justo en el tipo de sistema donde más importa. Nassim Taleb construyó una carrera sobre esta objeción, y es el argumento más fuerte contra todo lo anterior. Por qué la calma es peligrosa mail@fcarrone.com (Federico Carrone) — Wed, 04 Jun 2025 00:00:00 +0000 Hasta ahora la serie trató sobre por qué ocurren los crashes y por qué no se pueden leer a partir de sus disparadores. Este ensayo trata sobre la rara recompensa práctica: la posibilidad de ver venir una ruptura. Un sistema que se acerca a un punto de quiebre (tipping point) muchas veces emite señales de alerta, y lo raro es dónde se esconden. Se esconden en la calma, en un sentido preciso y medible: el sistema más tranquilo puede ser el que está más cerca de romperse. Qué mueve realmente los precios mail@fcarrone.com (Federico Carrone) — Tue, 03 Jun 2025 00:00:00 +0000 El ensayo anterior le puso un número a la reflexividad. Una razón de ramificación cercana a uno dice que el mercado pasa la mayor parte del tiempo reaccionando a sí mismo, con una operación que dispara la siguiente. Eso ya es un golpe duro para la imagen prolija en la que los precios mayormente digieren noticias de afuera. Pero hay un número todavía más limpio, y viene de la economía de la corriente principal y no de la econofísica. Xavier Gabaix y Ralph Koijen hicieron una pregunta directa: si un dólar entra al mercado accionario agregado, ¿cuánto sube el valor total del mercado? La intuición vieja dice que la respuesta debería estar cerca de un dólar, o quizás menos. Un mercado profundo debería absorber los flujos. Los precios deberían moverse sobre todo porque cambiaron los flujos de caja esperados, las tasas de descuento o las primas de riesgo. La presión compradora debería ser un detalle secundario. Su estimación es de unos cinco dólares. Ese es el puente reciente más importante hacia toda la historia de Al borde del caos. El mercado es un objeto inelástico, muy lejos del océano inmenso de la intuición vieja. Empujalo con flujos y se mueve todo el nivel. El número macro nuevo y la ley de microestructura más vieja cuentan la misma historia. A nivel agregado, los flujos tienen un multiplicador. A nivel de cada operación, la liquidez latente hace que el impacto sea no lineal en vez de inofensivo. La reflexividad en números mail@fcarrone.com (Federico Carrone) — Mon, 02 Jun 2025 00:00:00 +0000 Ya van tres ensayos y la misma idea sigue apareciendo con distintas palabras: los mercados reaccionan a sí mismos. Los precios se mueven porque los precios se movieron, y los grandes movimientos llegan sin una causa externa. George Soros armó toda una filosofía de inversión sobre esto y le puso nombre: reflexividad. Los mercados, decía, actúan sobre su propio reflejo, y ese reflejo vuelve a meterse en el mundo. Es una buena historia, y el problema de una buena historia es que lo explica todo y no predice nada hasta que alguien la convierte en un número. Este ensayo trata de ese número: cuánto de lo que hace un mercado es el mercado contestándose a sí mismo, y cuánto es respuesta a noticias reales de afuera. Eso se puede medir de verdad, y la herramienta viene de un lugar inesperado, el estudio de los terremotos. Más rápido que exponencial: ¿se puede ver venir un crash? mail@fcarrone.com (Federico Carrone) — Sun, 01 Jun 2025 00:00:00 +0000 Si le creés a los dos últimos ensayos, predecir es casi siempre una pérdida de tiempo. Los crashes vienen de adentro, los movimientos más grandes no tienen una causa que merezca ese nombre, y buscar el grano que desató la avalancha es buscar algo que nunca fue especial. Si te tomás eso en serio, lo único sensato es defenderse: tener margen, bajar el apalancamiento, esperar la caída. Didier Sornette pasó toda una carrera sosteniendo que eso es rendirse demasiado pronto. No para todos los crashes, sino para un tipo en particular, el estallido final de una burbuja. Su tesis es que una burbuja tiene una forma, que esa forma se puede ver mientras todavía se está armando, y que la forma te dice algo, con todas las salvedades de siempre, sobre cuándo se va a romper. Este es el caso optimista de la serie, y merece que se lo escuche con justicia, incluidos los lugares donde se cae. Pilas de arena y crashes: cómo los sistemas se afinan solos hasta el borde mail@fcarrone.com (Federico Carrone) — Sat, 31 May 2025 00:00:00 +0000 El ensayo anterior terminó con un enigma que no resolvió. Los mercados, sostenía, están cerca de un punto crítico, el filo de navaja donde un shock mínimo puede propagarse en cascada hasta convertirse en un movimiento enorme. Pero las transiciones de fase son quisquillosas. El agua se vuelve hielo a una temperatura exacta. Un imán pierde su magnetismo en un punto exacto de la perilla. Para estar cerca de un borde así, normalmente algo tiene que sostener la perilla ahí con mucho cuidado. Entonces, ¿quién sostiene la perilla del mercado? ¿Quién afina a millones de traders independientes para que se mantengan en equilibrio cerca del borde? La respuesta, que encontraron en 1987 tres físicos, es que nadie. Algunos sistemas caminan solos hasta el borde y se quedan ahí. Per Bak, Chao Tang y Kurt Wiesenfeld lo llamaron criticidad autoorganizada (self-organized criticality), y el juguete que usaron para mostrarlo fue una pila de arena. Crashes sin causa: los mercados como transiciones de fase mail@fcarrone.com (Federico Carrone) — Fri, 30 May 2025 00:00:00 +0000 El 19 de octubre de 1987, el S&P 500 perdió más del 20 por ciento. El tamaño de la caída fue solo una parte de lo raro. La explicación de siempre nunca llegó. Ningún banco quebró esa mañana. No empezó ninguna guerra. Ningún reporte de ganancias, decisión de tasas o anuncio político se acercó a explicar un movimiento de ese tamaño en un solo día. La gente buscó la causa porque se supone que los mercados necesitan causas. El Lunes Negro, en general, se negó a dar una. Bouchaud y sus colaboradores encontraron después el mismo problema a menor escala. Si mirás los saltos grandes en acciones individuales, muchas veces falta el titular que les corresponda. El movimiento es real; la noticia es demasiado chica, o no existe. Eso deja abierta una posibilidad incómoda: a veces los precios se mueven porque el mercado ya empezó a moverse. El modelo que hace que esto parezca menos misterioso no se construyó para las finanzas. Se construyó para los imanes. Antes de convertirlo en un mercado, primero tenemos que armar el imán.