Root Keys, Rogue Agents, Unnamed Theorems

OpenAI says an internal frontier model, not yet released, has produced "a broad range of new mathematical results." It is publishing them in a GitHub repository rather than as one paper or a benchmark score. The announcement is about process. It does not name any specific theorem, any field of mathematics, how many results there are, or what the model is called.

What is in the repository

• The papers themselves, with protocols for revisions and citations. OpenAI admits the exposition, citations and presentation need work and promises better quality in future releases.
• Lean formalizations of many of the proofs. Lean is a proof assistant that checks a mathematical proof mechanically. Not every result has been formalized yet. OpenAI says it will add formalizations "as we obtain them," so for now some results rest on informal proofs only.
• Ten summaries of the model's reasoning. These are summaries, not full reasoning traces.
• Compute estimates. Cost is expressed as equivalent ChatGPT Pro usage. On average, one result took roughly three hours of ChatGPT Pro thinking.
• Statistics on how many problems were attempted. This is the number that shows the hit rate. Without it, a list of successes says little about how reliable the model is.

How the release was shaped

OpenAI consulted the independent Advisory Group on Mathematics and Artificial Intelligence at the Institute for Advanced Study. It says it followed that group's public recommendations on how AI-generated math should be disclosed. GitHub is a stopgap: OpenAI is still looking for a community-hosted venue that meets the group's guidelines.

GitHub is rebuilding its Git storage layer for repositories where thousands of agents and CI jobs read and write at the same time. Its own numbers show the pressure. Monthly Git events rose from 218.2B to 473.3B between September 2025 and August 2026. Pushes grew 4.9x year over year, to 3.35B a month. September brought 7.38B commits, more than five times as many as a year earlier. The busiest single repository received about a billion requests in August.

Why the current design hits a ceiling

Today every repository lives in Spokes, which keeps a full copy on the local disks of several fileservers, five by default. Reference updates go through a three-phase commit with a quorum, so CI, the web UI and the API all see a consistent state. The problem, Celenza writes, is that the same mechanism provides both durability and scale. The disk copies are the source of truth, so the only way to add read capacity is to add another durable replica. Every replica takes part in every write, so a push is only as fast as the slowest replica. Adding replicas for reads therefore slows writes. Losing a replica cuts read capacity, and losing quorum stops writes entirely.

Agents make this worse in four ways:

• Each agent commits after nearly every action, so the latency of a single push limits how fast it can work.
• Merge queues and trunk-based development send everything onto one contended ref. PR merges are up nearly 4x.
• Each push triggers thousands of fetches. Actions ran 3.26B times in September, more than 4x a year earlier.

Meta's public time service now supports NTS (Network Time Security, RFC 8915) at nts.meta.com. The server, client and protocol code are open source in github.com/facebook/time. Plain NTP has had no authentication since 1985: a client sends 48 bytes and trusts whatever 48 bytes come back. Meta argues this now carries real weight. Certificate validity checks, token expiry, replay windows and log ordering all rely on the local clock. The CA/Browser Forum's ballot SC-081v3 also cuts public TLS certificate lifetimes to 200 days (March 2026), then 100 days (2027), then 47 days (2029). At that point renewal runs unattended about once a month, and a host with a skewed clock fails or reissues without anyone noticing.

How it works

NTS runs in two phases. In key exchange (NTS-KE), client and server connect over TLS 1.3 on TCP/4460 and agree on an AEAD cipher: AES-SIV-CMAC-256, AES-SIV-CMAC-512 or AES-128-GCM-SIV, with the client's preference winning. They then derive two directional session keys from the TLS session using the RFC 5705 exporter. The server hands over eight cookies and points the client at an NTP server. After that, ordinary NTPv4 on UDP/123 carries extension fields: a unique ID, a cookie and an authenticator. The server recovers the session keys from the cookie, checks the request and sends back fresh cookies encrypted inside its reply. This means an observer can't track a client across networks. Forged packets are dropped without a NAK, so to the client they look like packet loss and can't be used to force a new key exchange.

The key design choice is stateless cookies. Meta doesn't replicate a key ring. Each server derives the sealing key as . Here counts whole 24-hour periods since the Unix epoch, so there are no time zones or DST to get wrong. The day number travels in the clear as the key ID. Servers accept cookies from two days back to one day forward. The result has no session table and no replication, and nothing an attacker can exhaust. KE servers and NTP responders never talk to each other. One chrony line, , gives five independent authenticated sources, each with its own TLS-derived keys. All five come up in about 20 minutes. Clients that don't use NTS go through the same code path at the same cost as before.

On October 11, 2026, the DNS root is scheduled to change its key-signing key (KSK) for only the second time. KSK-2024 (key tag 38696) replaces KSK-2017 (key tag 20326) as the signer of the root's DNSKEY record set. A validating resolver that doesn't trust the new key will fail DNSSEC checks for names under every top-level domain.

Where trust starts

DNSSEC validation follows a chain of trust: the root publishes DS records (key fingerprints) for TLDs like .com, .com does the same for cloudflare.com, and so on down. The root has no parent, so resolvers start from a preconfigured trust anchor, which is the root KSK. The KSK signs the root's DNSKEY set. The zone-signing key (ZSK) in that set then signs everything else in the root zone, including TLD DS records.

Resolvers can learn the new anchor automatically through . The root publishes the new KSK next to the old one, and the old KSK keeps signing the set. A resolver must keep seeing the new key for at least 30 days, then verify it again before accepting it. KSK-2024 has been in the root DNSKEY set since January 11, 2025.