Schain, ads.txt and sellers.json together: how a buyer verifies a supply path, node by node

Each standard answers a different question, and each is published by a different party. That separation is the point. A fraudster would have to forge three independent records at once.

Sources: ads.txt 1.1, sellers.json 1.0, SupplyChain object 1.0.

The file formats, field rules and crawler behaviour are explained on our ads.txt and sellers.json validator page, which also checks your files. This page stays on the combination: how a buyer joins the three, and what breaks the join.

Three keys link the records, and two more fields tell you how to read the result. The sellers.json specification says seller_id "is the same ID that appears in an ads.txt file and in the SupplyChain.nodes array sid property", and "in most cases" also in publisher.id (sellers.json 1.0).

The "previous hop" key is easy to miss. For an INTERMEDIARY or BOTH seller, the sellers.json domain "should be the root domain name of the seller's Sellers.json file" (sellers.json 1.0). So when a reseller sells into an exchange, the exchange's entry for it points back to the reseller's own system, which is the asi of the node before.

Here is one impression bought through a reseller. Example Media GmbH owns news.example. It sells through its seat pub-1047 on SSP Alpha. SSP Alpha resells the impression into Exchange Beta, where SSP Alpha holds seat 88123. Exchange Beta sends the request to the buyer. All names use the reserved .example domain.

The bid request (OpenRTB 2.6). Exchange Beta is the sender, so its node is last and its seat matches publisher.id.

The publisher's ads.txt at news.example.

SSP Alpha's sellers.json lists the publisher's seat as a PUBLISHER account.

Exchange Beta's sellers.json lists SSP Alpha's seat as an INTERMEDIARY whose domain is SSP Alpha's own system.

The verification, check by check.

The rules behind checks 5 to 7 come from IAB Tech Lab's implementation guidance. It tells buyers to compare the sellers.json domain with OWNERDOMAIN for an owner and with MANAGERDOMAIN for a manager, and to treat any other domain as a reseller. It also expects that, for inventory sold by a manager, "the domain listed in MANAGERDOMAIN is also that of the node representing the originating publisher in a complete supply chain object".

A chain is incomplete when an upstream seller did not support the object. The specification tells the first seller that does support it to create the object, set complete to 0 and add its own node (SupplyChain object, implementation details). The request below is the same impression arriving with only Exchange Beta's node.

The buyer can still run checks 1, 2 and 7: Exchange Beta sent it, seat 88123 exists, and the publisher's ads.txt lists the seat as RESELLER. It cannot see who sold to SSP Alpha's seat, or whether the owner is in the path at all. A buyer can price that gap or skip the impression. A buyer that declines can say why with no-bid reason 16, "Incomplete SupplyChain", from the list that OpenRTB 2.6 points to (OpenRTB 3.0, List: No-Bid Reason Codes):

Code 17, "Blocked SupplyChain Node", covers the other common decision: the chain is complete but contains a seller the buyer refuses to pay. Codes 11 and 12 report ads.txt authorisation that is unavailable or violated.

The worked example generalises into a routine. Run it from the last node backwards, because the last node is the only one you can tie to the connection you received.

1. Parse and sanity-check the object. The ver field reads "1.0" and complete is 0 or 1. Every node has asi, sid and hp set to 1. Each sid is at most 64 characters, and each asi is a root domain without https:// (OpenRTB 2.6, SupplyChainNode).
2. Tie the last node to the sender. Its asi must be the exchange you are connected to, and its sid must equal site.publisher.id or app.publisher.id.
3. Look up each node in sellers.json. Fetch https://{asi}/sellers.json from cache and find seller_id equal to sid. A missing entry makes the node unverifiable; a confidential entry hides the name but still proves the seat exists.
4. Link each hop to the one before. For node n, an INTERMEDIARY or BOTH seller's domain should equal the asi of node n-1.
5. Find the owner. When complete is 1, the first node's seller should be PUBLISHER or BOTH, with a domain that matches ads.txt OWNERDOMAIN, or MANAGERDOMAIN for the right country.
6. Check authorisation in ads.txt or app-ads.txt. Each paid node's asi and sid should appear as field 1 and field 2. DIRECT should pair with PUBLISHER, RESELLER with INTERMEDIARY.
7. Apply passthrough and policy rules. If the last node is is_passthrough 1, the spec expects you to hold an account relationship with that seller. Then apply your own blocklist, and log the outcome with the request ID.

Steps 3 to 6 depend on files you crawl, not on the request, so cache them. The specifications tell consumers to honour HTTP Expires headers and otherwise refresh after 7 days (sellers.json 1.0). Supply path teams then use the results to rank paths, which is the subject of demand path optimization and of supply path optimization in general.

The object is the same in every version; only its address changes. OpenRTB 2.6 puts it in source.schain, 2.5 in source.ext.schain, and 2.4 or earlier in ext.schain (SupplyChain object). Prebid Server converts between the 2.5 and 2.6 locations in both directions (convert_up.go). Google's OpenRTB guide documents source.schain (Google Authorized Buyers). The full version comparison is in OpenRTB 2.5 vs 2.6 vs 3.0, and the field in context in OpenRTB 2.6 explained.

Who adds a node follows one rule: each seller appends itself and never removes others. The specification calls it invalid for a reseller to copy the object without inserting its own node (SupplyChain object). An SSP cannot add an upstream intermediary it does not know about, so the publisher or its wrapper operator must declare it. Prebid's documentation says this directly for managed Prebid.js setups (Prebid schain module).

Prebid.js changed how that declaration works in version 10, released on 1 July 2025 (Prebid.js 10.0.0). Since then the schain is treated as first-party data: the module copies its config into ortb2.source.ext.schain, and ortb2.source.schain takes precedence if both are set. A bidder-specific chain is now merged after the global nodes. Prebid.js 11.45 added firstPartyData.replaceGlobalSchain to restore the old replace behaviour (Prebid schain module). Header bidding setups in general are covered in header bidding explained, and server-side hosting in the Prebid Server self-hosting guide.

For VAST tags and other non-OpenRTB calls, the chain is serialised into one URL parameter, schain, with nodes separated by !. The exact format and an example are on the validator page. CTV stitching adds its own wrinkles, described in SSAI and CTV ad serving.

Version 1.0 lists only companies in the payment flow. A server-side wrapper, an open bidding provider or an SSAI platform can route the request without being paid by the next node, so it never appears. The draft 1.1 text changes that. It says the chain "discloses any entity that has custody of the bid request", which it calls "technical hops", and marks unpaid hops with hp 0 (dev branch implementation guidance).

The draft also sets new rules. Order follows the outbound sequence. Two consecutive hp 0 nodes from the same company collapse into one. No ads.txt entry is required for hp 0 nodes, but a sellers.json entry is "strongly recommended" for every node. Its examples cover web wrappers, mobile SDKs and six CTV paths. A paired draft renames the sellers.json file to version 1.1 (commit of 18 June 2026).

Treat this as a preview. On 9 November 2026 the 1.1 texts lived only in the dev branch, and IAB Tech Lab's public comment page did not list them (IAB Tech Lab, releases in public comment). If you validate chains, make hp 0 a warning rather than an error now, so the day 1.1 ships does not break your parser.

The three files prove who is allowed to sell. They do not prove that a request really came from the system named in the last node. Cryptographic signing was meant to close that gap, and it has had two lives.

The first, ads.cert 1.0 "Signed Bid Requests", lived inside OpenRTB 3.0 as the ds, dsmap, cert and digest fields of the Source object. The 3.0 text says these "should be considered" beta, like the ads.cert document itself (OpenRTB 3.0, Object: Source). The fields exist only in 3.0, so OpenRTB 2.x traffic cannot carry them.

The second, ads.cert 2.0, signs the HTTP connection rather than the payload. Companies publish keys in DNS as "Call Signs", and "Authenticated Connections" signs server-to-server calls of any format.

IAB Tech Lab's page says Authenticated Connections "is ready for adoption", lists Authenticated Delivery and Authenticated Devices as future work, and was last updated on 14 February 2024 (IAB Tech Lab, ads.cert). The open-source code was last pushed on 5 July 2023 (IABTechLab/adscert). Index Exchange described a proof of concept with Publica, Google Display & Video 360 and Oracle Moat in January 2022 (IAB Tech Lab blog, 27 January 2022). We found no public adoption figures.

Without signing, the seven checks above and each buyer's own fraud signals are what remains. Signing is an option between partners who agree on it.

1. Copying the chain without adding your node. The specification calls this invalid. If you resell and cannot add yourself, drop the object instead.
2. Setting complete to 1 when you created the object mid-path. Only the originating seller may start a chain with complete 1. A reseller that builds a missing chain must use 0.
3. A last sid that differs from publisher.id. Buyers tie the chain to the connection through this match. Different IDs for the same seat break check 2.
4. asi written as a URL or a subdomain. Use the root domain, the same value as ads.txt field 1, for example ssp-alpha.example, not https://bid.ssp-alpha.example.
5. A seat missing from sellers.json. Every system named in a node should publish an entry for its sid. A missing entry turns a valid chain into an unverifiable one.
6. An intermediary domain that does not point back. For INTERMEDIARY and BOTH sellers, domain should be the root domain of that seller's own sellers.json, so the hop can be linked.
7. DIRECT lines for seats the publisher does not control. IAB Tech Lab's guidance tells SSPs to check field 3 because they know the real relationship (implementation guidance).
8. Two chains in one request. Sending source.schain and source.ext.schain with different nodes leaves the buyer guessing. Mirror one value.
9. Bidder-specific chains in Prebid.js after an upgrade. Since Prebid.js 10 they merge with the global chain, so a node can appear twice if you configured both. Check the output or set replaceGlobalSchain on 11.45 or later.
10. Rejecting hp 0 outright. Version 1.0 requires hp 1, but the 1.1 draft introduces hp 0 for technical hops. Flag it; do not crash on it.

Files can be generated with the ads.txt generator and checked with the validator. Running your own exchange adds a sellers.json of your own, covered in the private ad exchange setup guide. The publisher independence hub collects the related pages.

1. IAB Tech Lab, "OpenRTB SupplyChain object" (version 1.0). https://github.com/InteractiveAdvertisingBureau/openrtb/blob/main/supplychainobject.md
2. IAB Tech Lab, "Sellers.json" specification, version 1.0 (July 2019). https://github.com/InteractiveAdvertisingBureau/Supply-Chain-Validation/blob/main/sellers-json.md
3. IAB Tech Lab, "ads.txt" specification, version 1.1. https://github.com/InteractiveAdvertisingBureau/Supply-Chain-Validation/blob/main/ads.txt%20v1.1.md
4. IAB Tech Lab, "Ads.txt Implementation Guidance" (OWNERDOMAIN, MANAGERDOMAIN, buyer guidance; main branch, accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Supply-Chain-Validation/blob/main/Implementation%20Guidance.md
5. IAB Tech Lab, "Supply Chain Validation: Implementation Guidance" with SupplyChain 1.1 draft examples (dev branch, commits 18 June to 9 July 2026). https://github.com/InteractiveAdvertisingBureau/Supply-Chain-Validation/blob/dev/Implementation%20Guidance.md
6. IAB Tech Lab, Supply-Chain-Validation commit history, dev branch (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Supply-Chain-Validation/commits/dev
7. IAB Tech Lab, sellers.json and SupplyChain object page (finalised 31 July 2019). https://iabtechlab.com/sellers-json/
8. IAB Tech Lab, "OpenRTB API Specification Version 2.6", objects Source, SupplyChain and SupplyChainNode (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
9. IAB Tech Lab, "OpenRTB Specification v3.0" (Source object, ads.cert fields, no-bid reason codes). https://github.com/InteractiveAdvertisingBureau/openrtb/blob/main/OpenRTB%20v3.0%20FINAL.md
10. IAB Tech Lab Programmatic Governance Council, "Programmatic Best Practices, Version 1.0, Public Comment" (16 September 2026). https://iabtechlab.com/wp-content/uploads/2026/09/Public-Comment-Programmatic-Best-Practices-v1-1.pdf