ads.txt, sellers.json, and schain: A Field Guide to Supply-Path Transparency

Why Programmatic Still Needs Declared Supply

Programmatic buying scales by automation—but automation rewards anyone who can make inventory look legitimate. Counterfeit supply (misrepresented domain, app, or seller relationship) has been a recurring issue for years. The industry’s response is not one silver bullet; it is a stack of public declarations that buyers can mechanically check against what they receive in the bid stream.

Three complementary mechanisms address different layers:

No single file “stops fraud.” Cross-checking all three against the live bid is what turns declarations into accountability. Treating ads.txt as a vanity exercise—updated once at launch—is how otherwise sophisticated buyers leave holes in CTV and mobile app supply, where app-ads.txt and developer URL alignment matter as much as line items.

ads.txt and app-ads.txt: Allowlists on the Open Web and in Apps

ads.txt is a plain-text file served at https://<domain>/ads.txt. It lists which advertising systems are authorized to sell that website’s inventory. Each record typically identifies an advertising system domain, a publisher account ID on that system, and whether the relationship is DIRECT or RESELLER—plus optional certification fields.

Why the format matters: Buyers and tools can fetch and parse files at scale. The value is not the file’s existence—it is continuous alignment between what the publisher declares and what appears in bids.

app-ads.txt uses the same format for mobile and CTV apps. The file is hosted on the developer website linked from the app store listing. Buyers crawl it the same way they crawl domain ads.txt—so the store → developer URL → file chain must be correct. If the developer URL is wrong, returns errors, or does not match the listing, validation fails even when the app is real.

Operational detail that saves money

• HTTPS and reachability — Redirect chains, wrong hostnames, and expired certificates cause silent failures in crawlers.
• Developer domain drift — Rebrands and acquisitions often break the store-to-site link before ops notices.
• Line sprawl — Files copied from “similar publishers” introduce wrong SSP domains or wrong account IDs.

Newer ads.txt revisions add fields such as OWNERDOMAIN and MANAGERDOMAIN to clarify ownership and delegation—useful when brands, networks, and sales reps share responsibilities.

sellers.json: Turning seller_id Into a Real Entity

Exchanges host sellers.json to map seller_id values to human-readable records: name, declared domain, and seller type (for example publisher vs intermediary vs both, depending on implementation).

Why it exists: Bids carry compact identifiers. Without sellers.json, “sid 12345” is meaningless. With it, you can ask:

• Does this name match the publisher we think we are buying?
• Is this seller typed as intermediary when we believed we were direct?
• Does the domain help disambiguate similarly named entities?

Operational pitfall: Stale entries—IDs that no longer trade but remain in the file—create noise. Incomplete files—missing IDs that still appear in bids—are a red flag for process failure on the exchange side or for misconfigured integrations.

schain: The Path, Not Just the Last Hop

The Supply Chain Object (OpenRTB Source.schain, often called schain) describes the ordered list of intermediaries involved in the transaction. Each node in the chain typically includes:

• asi — Advertising system identifier (commonly a domain-style ID)
• sid — Seller ID in that system

The object also carries a complete flag indicating whether the seller believes the chain is full. complete: 0 means the path may be truncated—sometimes for legitimate technical reasons, sometimes because intermediaries omit hops.

Why schain matters: ads.txt tells you who is authorized to sell a given publisher. schain tells you which hop actually touched this bid. Spoofing survives when those stories diverge.

Reading a chain as a buyer

1. Identify the inventory surface (site, app, placement) implied by the bid.
2. Walk nodes from impression-adjacent to root—confirm ordering matches your mental model of the supply path.
3. For each asi/sid, resolve sid against that system’s sellers.json.
4. Cross-check asi/sid against the publisher’s ads.txt or app-ads.txt with the correct DIRECT or RESELLER relationship.
5. If complete is false, treat the chain as incomplete evidence—not necessarily fraud, but not a full audit trail.

How a Clean Bid Should Line Up (Conceptually)

In an ideal reconciliation pass:

1. The final seller in schain resolves via sellers.json.
2. That asi/sid pair appears on the publisher’s ads.txt or app-ads.txt with the correct DIRECT or RESELLER relationship.
3. Intermediate nodes each have a defensible role—no unexplained hops.

When any step fails, you are not proving fraud by default—but you lack the public, auditable linkage that transparency programs are built for. Many teams treat that as “unauthorized until proven otherwise” for high-risk buying; others down-rank rather than block. Policy should match risk tolerance and deal type.

Common Operational Failures (and How They Persist)

Publishers and agencies repeatedly hit the same issues:

1. Stale files — Partners onboard and offboard; ads.txt is not updated; old RESELLER lines remain exploitable.
2. Broken app-ads.txt — Wrong developer domain, HTTP errors, or file hosted on a domain that does not match the store listing (especially painful for CTV and mobile).
3. Wrong relationship type — Everything marked RESELLER when some lines should be DIRECT; or copied blocks from unrelated sites.
4. Sprawl — Huge, duplicated files that are hard to audit and easy to poison with a single bad line.
5. Ignoring schain — Accepting inventory without path-level checks; not questioning complete: 0 or truncated chains.
6. “We trust the SSP” — Trust is fine; verification is still a contract artifact. SSPs can misconfigure integrations too.

Red-Team: How Gaps Get Exploited (Pattern-Level)

Without naming specific incidents, documented abuse patterns include:

• Unauthorized reseller lines left in ads.txt after a partnership ends—giving cover for indirect paths.
• Domain spoofing where the bid claims inventory that does not match the publisher’s declared surface.
• Truncated schain that hides arbitrage hops or makes reconciliation impossible at buyer tools.
• App identity confusion via developer URL mismatch—not necessarily fake apps, but unverifiable apps.

Defense in depth: declarations + delivery measurement + IVT analysis. Files alone are necessary, not sufficient.

CTV-Specific Considerations

CTV inventory is app-bound: store IDs, bundle IDs, and developer URLs must align. Industry commentary highlights app-ads.txt adoption and developer-site hygiene as persistent gaps—often worse than mature web publishers.

US CTV ad spend is frequently reported in the high teens to low twenties of billions of dollars annually in analyst roundups, with large variance by what counts as CTV (pure digital vs extensions of linear). Use any figure as a ballpark for context, not precision.

What Buyers Should Actually Do (Playbook)

Policy layer

• Require reachable ads.txt or app-ads.txt for inventory you pay for; treat missing or mismatched developer URLs as a red flag for apps.
• Reconcile bid asi/sid to publisher files and SSP sellers.json before treating supply as authorized.
• Down-rank or block when declarations are absent, stale, or contradictory—not only when a post-auction vendor flags IVT.
• Favor shorter, explainable paths; routine sid churn without documentation deserves scrutiny.

Operational layer

• Automate crawls on a schedule; alert on diffs, not only on absence.
• Version-control publisher allowlists internally—know what changed and when.
• Train traders to read schain before optimization, not only after a discrepancy fight.

Partner layer

• Share failure examples with publishers; most want clean files but lack ticketing priority until revenue is at risk.

Transparency infrastructure is not one magic file—it is the discipline of keeping declarations, exchange metadata, and live bid paths aligned long after launch day.

Due-Diligence Questions for Your SSPs and Publishers

1. How often do you refresh ads.txt and app-ads.txt after partner changes?
2. What monitoring alerts you when a crawl fails or a file changes?
3. How do you handle schain completeness when an intermediary cannot transmit full hops?
4. What is your policy when buyer tools flag unauthorized asi/sid pairs?

Where the Industry Is Heading

The IAB Tech Lab and ecosystem participants continue to invest in automation: crawling, validation APIs, and clearer specs for supply-chain disclosure. The direction is accountability through linkage—not a single score that replaces human review.

Advertisers who treat ads.txt + sellers.json + schain as a bundle—and who bake checks into buying workflows—catch mislabeled supply earlier than teams that only run post-campaign audits.

Closing: Pair Declarations With Demonstrated Delivery

Declarations tell you who is allowed to sell. Independent measurement tells you what happened on the glass: delivery, validity, and quality. AdProof’s verification stack is built to complement supply metadata with impression-level analysis—so you can move from “declared” to demonstrated quality. Ask us for a walkthrough of how we reconcile supply-path checks with independent measurement on your next campaign.