Key Takeaways

• IAB Tech Lab created three interlocking standards for supply chain transparency. ads.txt (2017), sellers.json (2019), and the SupplyChain object work together to give buyers full visibility into the programmatic supply path.
• Each standard solves a different problem. ads.txt handles authorization. sellers.json handles identity. schain handles path documentation. No single standard provides complete transparency on its own.
• Adoption is widespread but validation lags. Most publishers have ads.txt. Most SSPs have sellers.json. But consistent cross-validation by DSPs is still catching up.
• OWNERDOMAIN and MANAGERDOMAIN are the newest additions. These fields extend ads.txt and sellers.json to handle multi-domain publishers and management relationships.
• The industry is moving from adoption to enforcement. The next phase isn't getting more entities to adopt these standards but making sure buyers actually validate against them in every bid decision.

---

How IAB Supply Chain Transparency Works

The programmatic advertising supply chain has a transparency problem that took years and three separate standards to address.

The IAB Tech Lab, the technical standards body for the digital advertising industry, built a layered system where each standard handles one dimension of verification. Together, they give buyers the ability to trace a bid request from publisher to buyer and verify every entity in between.

Understanding how these pieces fit together isn't just a technical exercise. It directly affects how DSPs evaluate and price your inventory.

The Problem These Standards Solve

Before supply chain transparency standards existed, a DSP receiving a bid request had to take it on faith. The bid claimed to be inventory from a specific publisher, sold through a specific SSP. The DSP had no independent way to verify either claim.

This opacity enabled several forms of fraud and waste:

• Domain spoofing: Bad actors claiming to sell inventory from premium publishers
• Unauthorized reselling: Entities selling publisher inventory without permission
• Hidden intermediaries: Bid requests passing through undisclosed middlemen who extracted fees
• Inventory misrepresentation: Mismatches between what was claimed and what was real

The industry was losing billions. The IAB Tech Lab responded with a phased approach, introducing each standard as a layer on top of the previous one.

Layer 1: ads.txt (Authorization)

Introduced in 2017, ads.txt was the first layer. Publishers place a text file at https://their-domain.com/ads.txt that lists every SSP, exchange, and reseller authorized to sell their inventory.

What it answers: "Who has permission to sell this publisher's inventory?"

Who maintains it: The publisher.

What it contains: One line per authorized seller, with the exchange domain, account ID, relationship type (DIRECT or RESELLER), and optional TAG-ID certification.

What it solved: Domain spoofing dropped significantly after ads.txt adoption. DSPs could now check whether the SSP claiming to sell a publisher's inventory was actually authorized by that publisher.

What it left unsolved: ads.txt confirms that SSP-X account 12345 is authorized, but says nothing about who account 12345 actually is. The authorization layer exists. The identity layer doesn't.

Layer 2: sellers.json (Identity)

Introduced in 2019, sellers.json added the identity layer. SSPs and exchanges publish a JSON file at https://ssp-domain.com/sellers.json listing every seller on their platform with their verified identity.

What it answers: "Who is this seller account, and are they who they claim to be?"

Who maintains it: The SSP or exchange.

What it contains: For each seller: seller_id, business name, domain, seller_type (PUBLISHER or INTERMEDIARY), and confidentiality status.

What it solved: DSPs can now cross-reference the account ID in a publisher's ads.txt with the identity in the SSP's sellers.json. They can confirm that account 12345 on SSP-X belongs to "Publisher Corp" at publisher.com, not an unknown entity.

What it left unsolved: When a bid request passes through multiple intermediaries (SSP to exchange to another exchange), the DSP can verify the first and last entity but not the full path. The route between publisher and buyer remains opaque.

Layer 3: SupplyChain Object (Path)

The SupplyChain object (schain) completes the picture. Embedded in every OpenRTB bid request, it documents every entity that touched the bid request, in order, from the entity closest to the publisher to the entity sending the bid to the DSP.

What it answers: "What is the complete path this bid request took from publisher to buyer?"

Who maintains it: Each entity in the path adds its own node as the bid request passes through.

What it contains: An ordered list of nodes, each with the entity's domain (asi), seller ID (sid), and a flag indicating if the request originated there (hp).

What it solved: Full path visibility. DSPs can now verify every hop in the supply chain, not just the endpoints. They can see if a bid request passed through three intermediaries or one, and verify each one.

How All Three Work Together

When a DSP receives a bid request, the verification process uses all three standards:

1. Read the schain. The bid request contains a SupplyChain object documenting every entity in the path. The DSP identifies each node.

2. Verify authorization (ads.txt). The DSP checks the publisher's ads.txt to confirm the first node in the schain (the SSP with a direct relationship) is authorized to sell this inventory.

3. Verify identity (sellers.json). For each node in the schain, the DSP checks the corresponding entity's sellers.json file. It confirms the seller_id matches a real, named business.

4. Cross-validate. The DSP checks consistency across all three. The account ID in ads.txt should match the seller_id in sellers.json should match the sid in the schain node. The domain should be consistent. The relationship type should align.

5. Assess and bid. Based on the verification results, the DSP determines its confidence level and adjusts the bid accordingly. Full verification gets premium bids. Partial verification gets discounted bids. Failed verification gets excluded.

This is the full transparency stack. Three standards, three maintainers (publisher, SSP, supply path), three questions answered (authorization, identity, path).

The OWNERDOMAIN and MANAGERDOMAIN Extensions

In 2024-2025, the IAB Tech Lab introduced two new fields to ads.txt and sellers.json: OWNERDOMAIN and MANAGERDOMAIN. These address a gap in the original standards.

OWNERDOMAIN identifies the entity that owns the content. For a media company with 20 websites, all 20 ads.txt files can point to the parent company's domain as the owner. This helps DSPs understand corporate relationships.

MANAGERDOMAIN identifies the entity that manages monetization. A publisher might outsource ad operations to a third party. MANAGERDOMAIN declares that relationship transparently.

These fields handle real-world complexity that the original standards didn't cover: multi-site publishers, management companies, ownership hierarchies.

Current State: Adoption vs. Validation

The transparency standards are widely adopted, but adoption and validation are different things.

Adoption is high. The vast majority of major publishers have ads.txt files. Most big SSPs maintain sellers.json. The schain specification is supported across major programmatic platforms.

Validation is uneven. Not all DSPs validate all three standards on every bid request. Some check ads.txt but not sellers.json. Some verify the first node in schain but not every node. Some do full validation only for high-value impressions.

The IAB Tech Lab's current focus is pushing the industry from adoption to consistent validation. The standards exist. The data is available. The remaining challenge is making sure every buyer actually uses the data in every bid decision.

For publishers, this means the revenue impact of transparency is growing over time. As more DSPs roll out stricter validation, the penalty for verification failures increases and the premium for full verification grows.

What This Means for Publishers

Your ads.txt accuracy directly affects bid quality. Every error in ads.txt is a failed verification check that cuts bids. This isn't theoretical. DSPs check it.

Your SSP's sellers.json quality affects your revenue. If your SSP has stale data, missing entries, or confidential flags on your account, DSP verification fails at the identity layer. You can't fix this yourself. You need to monitor it and escalate issues.

Shorter supply paths verify better. Every intermediary in the schain is another node that must pass verification. More hops mean more potential failure points. Where possible, prioritize direct SSP relationships over multi-hop reseller chains.

Monitor all three layers. Use BeamFlow's scanner to cross-verify your ads.txt against sellers.json and spot supply chain issues. Regular monitoring catches problems before they compound.

Frequently Asked Questions

Do I need to implement all three standards?

Publishers implement ads.txt. SSPs implement sellers.json. The schain is handled by the programmatic infrastructure. As a publisher, your responsibility is keeping an accurate ads.txt and monitoring your sellers.json entries. You don't directly implement schain.

Which standard has the biggest revenue impact?

ads.txt has the widest adoption and most consistent enforcement by DSPs. Getting ads.txt wrong has the most immediate and measurable revenue impact. But sellers.json verification is catching up quickly as DSPs roll out stricter supply chain checks.

How do I know if DSPs are validating my supply chain?

You can't directly observe DSP validation behavior. The best proxy is monitoring your verification status across all three layers and correlating it with CPM performance. When verification issues are fixed, CPMs typically improve within days to weeks.