Lesson 2 of 4 · 9 min read · advanced
ads.txt, sellers.json, schain and ads.cert in depth
Four IAB Tech Lab standards that let buyers check who is really selling an ad: how ads.txt, app-ads.txt, sellers.json, schain and ads.cert work together.
Programmatic ads are sold by machines to machines in milliseconds. That makes it easy for a fraudster to claim “I am selling ads on a famous news site” when the traffic really comes from a junk site or a bot farm. The fix the industry built is a set of public files and data fields that let a buyer check every claim in the chain. None is perfect alone. Together, they make lying much harder.
Imagine buying a concert ticket from a stranger. ads.txt is the venue publishing a list of official ticket sellers. sellers.json is each ticket agency publishing who its sub-agents are. The schain is the chain of receipts showing every hand the ticket passed through. ads.cert is a tamper-proof seal proving the ticket details were not changed on the way.
ads.txt: the publisher’s list of authorised sellers
Launched by IAB Tech Lab in 2017, ads.txt is a plain text file a website places at its root, for example example-news.com/ads.txt. Each line names an ad system (such as an SSP’s domain), the publisher’s account ID in that system, whether the relationship is DIRECT or RESELLER, and optionally a TAG certification ID. A buyer receiving a bid request that claims to be from example-news.com can check whether the seller account in the request appears in that file. If not, the request is likely spoofed.
| Field | Example | Meaning |
|---|---|---|
| Ad system domain | ssp-example.com | The exchange or SSP authorised to sell |
| Seller account ID | 12345 | The publisher’s account inside that SSP |
| Relationship | DIRECT or RESELLER | Whether the publisher controls the account (direct seller) or a third party resells (reseller) |
| Certification authority ID | Optional | The seller’s TAG ID, if it has one |
app-ads.txt, released in 2019, does the same for mobile and CTV apps. Because an app has no website root, the file lives on the developer website listed in the app store. Buyers look up the app’s store listing, find the developer URL and fetch app-ads.txt from there.
sellers.json: the SSP’s list of who it pays
ads.txt tells you which accounts a publisher authorises, but not who owns those accounts. sellers.json, also from IAB Tech Lab in 2019, closes that gap. Each SSP or exchange publishes a file listing every seller account it pays, with the seller’s name, domain, and whether it is a PUBLISHER, INTERMEDIARY or BOTH. Buyers can now join the dots: account 12345 on ssp-example.com belongs to Example News Ltd, a publisher. Sellers can be marked confidential, which is allowed but reduces transparency.
schain: the receipt trail
The supplyChain object, or schain, is a field inside the OpenRTB bid request. Every company that handles the request adds a “node” describing itself: its ad system domain, the seller ID it uses, and whether the chain is complete. A buyer can then compare each node with the matching sellers.json entry and ads.txt line. A short, complete chain with known names is a good sign. A long chain, gaps, or unknown sellers are warning signs of traffic arbitrage or fraud.
ads.txt, sellers.json & schain
news.example posts a public file, ads.txt, listing every company allowed to sell its ads and the account ID it uses, marked DIRECT or RESELLER.
- The publisher declares its sellers: news.example posts a public file, ads.txt, listing every company allowed to sell its ads and the account ID it uses, marked DIRECT or RESELLER.
- A bid request arrives: The DSP receives a request “for news.example”, sent by SSP account 1234, with a SupplyChain object listing every hop it passed through.
- Check 1: is this seller authorised?: The buyer checks news.example/ads.txt: is SSP account 1234 listed? If not, the request is unauthorised and is not bought.
- Check 2: who is account 1234?: The SSP’s sellers.json names the business behind 1234 and whether it is the publisher itself or an intermediary. Hidden sellers are a warning sign.
- A spoofer tries the same trick: A fraudster sends requests claiming to be news.example from its own junk site. This is domain spoofing. Its seller ID is not in news.example’s ads.txt.
- Only verified paths get bought: Requests whose seller, ads.txt entry and schain all line up get bought; the spoofed ones fail. Simple public files closed one of the biggest fraud loopholes of the 2010s.
ads.cert: signing the request
Files can be checked, but the bid request itself can still be altered in transit. ads.cert uses public-key cryptography so that companies can prove who sent a message. The current version, ads.cert 2.0, focuses on Authenticated Connections: each participant publishes a public key in its DNS records, and messages between partners carry a signature that the other side can verify. Adoption has been slower than for ads.txt, because it requires engineering work on both ends.
Putting it together
- Read the claimThe bid request says the impression is on example-news.com, sold through account 12345 at ssp-example.com.
- Check ads.txtDoes example-news.com/ads.txt list ssp-example.com with account 12345? If not, reject.
- Check sellers.jsonDoes ssp-example.com/sellers.json say account 12345 belongs to Example News as a PUBLISHER? If it names an unknown intermediary, look closer.
- Walk the schainIs every node in the chain known, and does the chain end at the publisher? Missing nodes are a red flag.
- Verify signatures where availableIf partners use ads.cert, confirm the request was signed by who it claims.
Supply-chain standards catch
- Domain spoofing and app spoofing by unauthorised sellers
- Hidden resellers and long, unnecessary chains
- Seller accounts owned by unknown companies
They do not catch
- Bots on a legitimate, authorised site
- Low-quality or MFA content
- Fraud by an authorised direct seller
There is a buyer-side counterpart too. buyers.json and related IAB Tech Lab work aim to let sellers see who is behind the demand, so publishers can block malicious buyers and malvertising. The principle is the same in both directions: when everyone publishes who they are, anonymous bad actors have fewer places to hide.
Key takeaways
- ads.txt and app-ads.txt let publishers and app developers list the seller accounts they authorise.
- sellers.json lets SSPs disclose who owns each seller account and whether it is a publisher or intermediary.
- schain records every hop in a bid request; ads.cert adds cryptographic signatures to prove who sent it.
- These standards stop impersonation and hidden resellers but do not detect bots on authorised inventory.
Questions people ask
What is the difference between ads.txt and sellers.json?
ads.txt is published by the publisher and lists which ad systems and account IDs are allowed to sell its inventory. sellers.json is published by the SSP or exchange and lists who owns each seller account it pays. Buyers use both together: ads.txt confirms the account is authorised, sellers.json confirms who is behind that account and whether it is a direct publisher or an intermediary.
What is a supply chain object (schain) in programmatic?
The SupplyChain object, or schain, is a field in an OpenRTB bid request that records every company that handled the ad opportunity on its way to the buyer. Each company adds a node with its domain and seller ID. Buyers check these nodes against sellers.json and ads.txt to spot unknown resellers, missing hops or suspiciously long chains that suggest arbitrage or fraud.
Does ads.txt stop ad fraud?
It stops one important kind: unauthorised sellers pretending to sell a known website’s inventory, called domain spoofing. It cannot tell whether the visitors on an authorised site are real people, so bot traffic, click farms and made-for-advertising sites can still pass. Buyers need ads.txt plus invalid traffic detection, quality measurement and careful supply path choices.