OpenRTB 3.0 was released in 2018 as a complete reimagining of the programmatic protocol. Technically superior in almost every way. Yet years later, the overwhelming majority of exchanges — InMobi included — still run on 2.5 or 2.6. Understanding why tells you about how adtech actually works.
What 3.0 Proposed
A layered architecture: transaction layer (OpenRTB 3.0) for auction mechanics, ad object layer (AdCOM) for creative and format descriptions, regulatory layer for privacy and consent — all separated. This is elegant. In 2.x, everything is mashed into one monolithic protocol. OpenRTB 3.0 also introduced better emerging format support, cleaner device/media enumerations, and a more extensible architecture. On paper, the clear winner.
Why Migration Has Not Happened
Coordination, not technology. Hundreds of SSPs and DSPs need to interoperate. For an exchange to adopt 3.0, its DSP partners need to accept 3.0 requests. For DSPs to accept 3.0, exchanges need to send them. Classic chicken-and-egg. At InMobi, we have evaluated 3.0 migration multiple times — cost of dual protocol support, engineering to rebuild bid request generation, risk of demand loss from non-adopting DSPs always outweighs benefits. Product leaders at Magnite, PubMatic, and Index Exchange reach similar conclusions.
The Extension Field Reality
Innovation happens through ext fields. Exchanges pass proprietary signals — contextual enrichment, attention predictions, quality scores — through extensions. DSPs have their own. The ext field is an escape valve allowing protocol evolution without formal spec changes. Not standardized, but far more agile than waiting for committee approvals. At InMobi, our exchange uses extensive extensions for signal enrichment.
What Will Actually Happen
OpenRTB 2.x will remain dominant through at least 2028. When a major shift occurs, it will not be migration to current 3.0 — it will be a new protocol for an AI-agent-driven ecosystem where buyers are autonomous systems with different communication requirements. The lesson: backward compatibility and incremental evolution beat clean-slate redesigns. Build for the protocol the market actually uses.
Practical Advice
Build on OpenRTB 2.6 with extensive extension field support. Design architecture to be protocol-agnostic where possible — abstract bid request generation so future migration does not require rewriting core auction logic. Invest in your extension taxonomy: richer and more consistent extensions help demand partners optimize better. This is what we do at InMobi.
Building Toward the Future
At InMobi, where I lead Web and CTV Exchange product strategy, every aspect of this topic connects to our exchange product roadmap. The decisions we make about auction design, signal enrichment, demand routing, and yield optimization are all informed by deep understanding of these fundamentals. Having built monetization systems scaling to $200M+ at Glance, I know that getting the basics right compounds into massive revenue impact at scale.
The programmatic industry is evolving toward AI-native, server-side, cross-surface architecture. By 2030, exchanges will consolidate, AI agents will participate in auctions, attention-based signals will supplement viewability, and CTV will be the dominant ad surface. The product builders who understand today's fundamentals deeply — and invest in building for tomorrow's requirements — will lead this transformation. That is exactly what I am doing at InMobi and at adsgupta.com, where I am building AI-powered advertising intelligence tools drawing on everything I have learned across Google, Automatad, Glance, and InMobi over the past decade.
If you are building in programmatic advertising, I encourage you to go beyond surface-level understanding. Read the OpenRTB specification. Study bid request logs. Analyze auction dynamics. Trace the supply chain from publisher to advertiser. This depth of understanding is what separates good ad products from great ones — and it is the perspective I bring to everything I build.