The DemandChain Object is an extension to OpenRTB, the specification governing most automated advertising transactions, that lists every entity involved in paying for an impression, from the advertiser at the top of the chain to the last system that handled the bid response. It travels in the response rather than the request, because the information belongs to the buy side and the party that needs it is the seller.

It exists to close an asymmetry. By 2021 buyers could trace an impression back to its publisher through ads.txt, sellers.json and the SupplyChain object. Sellers had no equivalent: a publisher could see which advertising system was bidding but not who stood behind the seat. The IAB Tech Lab described the consequence in its buyers.json specification as whack-a-mole, with malvertisers exploiting the weakest entry point, getting caught on one demand-side platform, and reappearing on the next under a different account.

Where the object sits

The specification places the object at BidResponse.seatbid.bid.ext.dchain for OpenRTB 2.5 and later, and at BidResponse.ext.dchain for version 2.4 and earlier. Three attributes are required: a complete flag, where 1 indicates the chain contains every node leading back to the ultimate source of payment; an ordered nodes array; and a ver string whose only valid value is "1.0", numeric values being explicitly invalid.

Order carries meaning. The first node represents the ultimate source of payment, or in an incomplete chain the first known participant. The last node always represents whichever system is sending the response, so the array grows as the bid travels back towards the publisher.

Inside a node

Two attributes do the identification work. The advertising system identifier, asi, is the canonical domain name of the demand-side platform or other buying system, expressed as a hostname rather than a full URL and pointing at the domain hosting that system's buyers.json file. The buyer seat identifier, bsid, names the seat inside it. The value must match the seat attribute of the SeatBid object used in transactions, must appear as a buyer_id in the buyers.json file, and is recommended to stay within 64 characters. A single bsid may not represent more than one entity, though one buying entity may hold several seats within a system.

Three further attributes are conditional. The rid field carries the originating bid request identifier. The name and domain fields identify the legal entity paying under the seat, and become mandatory when asi is absent or null. That is the mechanism for representing brands, holding companies and agencies sitting above the first programmatic system, which hold no seat anywhere.

The companion file

buyers.json is the lookup table that makes seat identifiers meaningful. Intermediaries publish it over HTTPS at the root domain, defined as the public suffix plus one label, under the path /buyers.json, with a maximum cache expiry of seven days recommended.

Each entry requires a buyer_id and a buyer_type drawn from three values: ADVERTISER for accounts controlled by the advertiser itself, INTERMEDIARY for accounts run by an agency or reseller, and BOTH where the account switches role by business context. The name field is required unless is_confidential is set to 1. A created_on date is recommended, and the specification is candid about why, noting that malvertising buyers tend to have short lifespans.

Passing rules

The specification is prescriptive about how a chain grows, because a chain that can be copied is a chain that can be laundered. Copying a received object without inserting a node is invalid, and a system that will not add itself must not forward what it received. A system receiving a response with no chain creates one, sets complete to 0 and inserts a single node; a system receiving an existing chain preserves the original complete flag and appends its own node. Syntax validation runs in real time, but what happens on failure is left to policy: broken syntax should at minimum be logged, and stricter operators may discard the response.

Creative source data

A second mechanism serves people who never see the bidstream. Whichever party first generates ad markup should serialise three values into a comma-delimited string in the form ver,dsp_domain,buyer_seat_id,creative_id,ext, exposed as a data-ad-creative-source attribute on the outermost HTML tag, or in VAST inside an AdCreativeSource element. One worked example reads 1.0,mydsp.example,ac1f9e,89708971. Ad operations staff and malware scanners can then identify the buyer behind a bad creative with a string match, without auction logs.

Origin

sellers.json and the SupplyChain object were unveiled in July 2019, and their success set the template. The buy-side mirror opened for a 30-day public comment period on March 30, 2021, closing on April 30. Version 1.0 of both DemandChain Object and buyers.json followed in June 2021. John Clyman, then vice president of engineering for marketplace quality and security at Magnite, is credited with leading the work; contributors came from Google, PubMatic, Xandr, Verizon Media, Confiant, Index Exchange, Cafe Media, PulsePoint and IAB Europe.

Prebid took up the object in September 2021, after a standardisation request argued that chains should be copied to the bid.meta.dchain field. Its module validates incoming objects in strict, relaxed or off modes and appends a node for the Prebid bidder.

Why it matters commercially

Buy-side transparency inverts a familiar relationship. Publishers have spent a decade supplying declarations upward while receiving little back, a gap visible in adjacent products: Integral Ad Science built Quality Connect to show publishers the media quality rules advertisers configure against their inventory precisely because publishers had no direct view of them.

Money is the second argument. Amazon's open-source bidding signal work cited research finding publishers receive 51 cents per advertising dollar, with 15 percent lost to supply chain inefficiency. Sellers able to see which intermediaries sit between a brand and their inventory can price and police those routes. The reverse capability already carries a price tag: DV360 added a seller ID blocklist in April 2025 with a 1.5% fee on media costs.

Limitations and disputes

Adoption is the central failure. IAB Europe research on 2,054 European news publishers found ads.txt on at least 72.64 percent of sampled sites, while the buy-side equivalents still required synchronised adoption across intermediaries before producing anything useful. Alliance Digitale's French technical guide classified ads.txt and sellers.json as mature and the SupplyChain object as still in adoption, placing the buy-side mirror further back again. Sources disagree even on the launch date: the Tech Lab dates version 1.0 to June 2021, the IAB Europe research to 2024.

Confidentiality is a designed escape hatch. Setting is_confidential to 1 removes name and domain from the public file. According to PubMatic, reluctance to disclose client lists is legitimate enough to warrant a different approach, and the company said it would carry buyer name, domain and identifier inside the object itself, so that only parties to a given bid response see them. That departs from the sellers.json model, in which the chain carries an identifier and the file carries the identity, and it lets two implementations both claim compliance while exposing different things. PubMatic also noted the object was not fully supported across integration types, including Prebid and tag-based paths.

Nothing in the chain is signed. The specification places cryptographic protection against manipulation, and spoofing of agency identity, outside its scope, pointing at ads.cert as the separate effort addressing authenticated bid requests. Non-programmatic nodes compound the problem, since name and domain values cannot be checked against any published file. The Tech Lab concedes this, arguing that imperfectly normalised information still helps isolate serious violations.

The threat model has moved as well. Confiant documented the SourTrade campaign in July 2026, in which malware is assembled inside the victim's browser rather than delivered as a scannable file across twelve countries. Knowing which seat bought an impression helps after the fact. It does not catch a payload that does not exist until delivery completes.

Disambiguation

The SupplyChain object, usually written schain, is the mirror image and the older sibling. It travels in the bid request and lets buyers see each hop a request took between publisher and demand-side platform. DemandChain travels in the response and lists payors.

buyers.json is a static file, not an object, fetched and cached out of band. It maps seat identifiers to legal entities; the DemandChain object carries the identifiers that make a lookup possible. Neither is useful alone.

A seat identifier is a single value, not a chain. It names one buyer account within one advertising system and appears in the wseat and bseat arrays of a bid request and the seat attribute of a SeatBid object. The bsid field is where that value enters the node.

adagents.json addresses authorisation rather than payment. Published by Brian O'Kelley on March 30, 2026, it proposes a publisher-declared model of which agents may sell which placements, where and when.

Recent developments

Version 1.0 remains current as of September 2026, more than five years after publication, with the specification page last updated on January 15, 2024. The standard has not been revised while the transaction layer around it changed substantially.

Attention has shifted to agentic infrastructure. The Tech Lab opened an Agentic RTB Framework in November 2025 and expanded an Agent Registry to ten entries in March 2026, then added a pricing provenance field and a vendor approval gate in AAMP 2.3 in July 2026. Prebid has pushed the same way, putting publisher-side authorisation at the centre of its agentic work. Each addresses the question DemandChain asks, namely who is on the other side of the transaction, in an environment where the counterparty may be software.

Contractual pressure arrives from a different direction. The IAB's standard terms framework requires sellers to reflect intermediaries in ads.txt, app-ads.txt, sellers.json and the SupplyChain object, with withheld payment as a remedy. No comparable obligation binds buyers to publish buyers.json. OpenX's claim in September 2026 that 100% of its supply is ads.txt and sellers.json compliant shows both how far the sell side has come and how the asymmetry persists.

Timeline

  • July 2019: IAB Tech Lab unveils sellers.json and the SupplyChain object, establishing the sell-side transparency template
  • March 30, 2021: buyers.json and DemandChain Object open for a 30-day public comment period
  • April 30, 2021: The comment period closes
  • June 2021: Version 1.0 of buyers.json, DemandChain Object and the joint implementation guide is published
  • September 2021: A Prebid.js standardisation request proposes carrying the object in the bid.meta.dchain field
  • April 2022: OpenRTB 2.6 is released
  • January 15, 2024: The IAB Tech Lab's buyers.json and DemandChain Object page records its most recent update
  • February 15, 2025: Google retires its proprietary Authorized Buyers bidding protocol in favour of OpenRTB
  • April 2025: PubMatic publishes its buyers.json file and describes carrying buyer identity inside the object rather than the file
  • August 2025: IAB Europe research on 2,054 European news publishers reports at least 72.64 percent ads.txt coverage
  • November 2025: IAB Tech Lab opens its Agentic RTB Framework
  • March 2026: The Tech Lab Agent Registry reaches ten entries
  • July 2026: AAMP 2.3 adds a pricing provenance field and a vendor approval gate
  • September 2026: Version 1.0 remains the current DemandChain Object release

Summary

Who. IAB Tech Lab publishes and maintains the specification, led by Amit Shetty with John Clyman of Magnite credited for the working group leadership and contributors drawn from Google, PubMatic, Xandr, Verizon Media, Confiant, Index Exchange, Cafe Media, PulsePoint and IAB Europe. Demand-side platforms initiate the object, intermediaries and supply-side platforms extend it, and publishers, exchanges and anti-malware vendors consume it.

What. An OpenRTB extension object carrying an ordered array of nodes, each identifying an entity in the flow of payment for an impression, plus a flag stating whether the chain is complete and a version string. Nodes identify programmatic participants by advertising system domain and buyer seat identifier, and non-programmatic participants such as brands and agencies by legal name and business domain.

When. Released for public comment on March 30, 2021, closing April 30 that year, with version 1.0 published in June 2021. No revision has followed; the specification page last recorded an update on January 15, 2024, and 1.0 remains current as of September 2026.

Where. In the BidResponse.seatbid.bid.ext.dchain attribute for OpenRTB 2.5 and later, in BidResponse.ext.dchain for earlier versions, in the bid.meta.dchain field in Prebid.js, and in serialised form as a data-ad-creative-source attribute inside delivered ad markup.

Why. Sellers had no way to identify who was buying their inventory, which allowed malvertisers to move between demand-side platforms faster than any single publisher or exchange could block them. The object supplies the buy-side counterpart to the SupplyChain transparency that buyers had already secured, though its value depends entirely on adoption that has not arrived, on disclosure the buy side can decline through a confidentiality flag, and on declarations that nothing in the chain cryptographically verifies.