Key Takeaways

• The SupplyChain object (schain) is embedded in every OpenRTB bid request. It documents every entity involved in the sale of a specific ad impression, from publisher to buyer.
• Each node in the chain represents one seller or intermediary. Nodes contain the advertising system identifier (asi), seller ID (sid), and whether the entity is a direct participant (hp).
• DSPs use schain to verify the entire supply path, not just individual entries. ads.txt confirms authorization. sellers.json confirms identity. schain maps the full path between publisher and buyer.
• A complete schain (complete=1) tells DSPs the full path is documented. An incomplete chain means at least one entity in the path isn't represented, which cuts buyer confidence.
• Schain is the third leg of the transparency triad. ads.txt, sellers.json, and schain together give DSPs full visibility into who's authorized, who they are, and how the bid request traveled.

---

What Is the SupplyChain Object (schain)?

When a publisher's ad impression reaches a DSP through programmatic channels, it passes through one or more intermediaries.

An SSP receives the ad request. Maybe that SSP passes it to an exchange. Maybe the exchange passes it to another exchange. By the time the DSP sees the bid request, the impression might have traveled through three, four, or five entities.

Before the SupplyChain object existed, the DSP could check ads.txt to verify the first hop (publisher to SSP) and sellers.json to verify the seller's identity. But the full path from publisher to buyer was invisible. The DSP had no way to know how many intermediaries touched the bid request or who they were.

The SupplyChain object changed that. It's a structured data object embedded in every OpenRTB bid request that maps every entity in the supply path.

How schain Is Structured

The SupplyChain object has two components.

Header properties:

• ver: The specification version (currently 1.0)
• complete: A flag indicating whether the chain represents the full path (1 = complete, 0 = incomplete)

Nodes array: A list of SupplyChainNode objects, one for each entity in the path. Each node contains:

• asi (advertising system identifier): The domain of the SSP, exchange, or intermediary (matches the exchange domain in ads.txt)
• sid (seller ID): The account identifier for the seller on that system (matches the account ID in ads.txt and seller_id in sellers.json)
• hp (hosted product): 1 if the ad request originated with this entity, 0 if it was passed from another source
• rid (request ID): Optional identifier for the specific bid request
• name: Optional display name of the entity
• domain: Optional domain of the entity

The first node in the array represents the entity closest to the publisher. The last node represents the entity that sent the bid request to the DSP.

A Concrete Example

A publisher serves an ad through two intermediaries before the bid request reaches the DSP:

Path: Publisher > SSP-A (direct) > Exchange-B (reseller) > DSP

The schain in the bid request would look like:

json
{
  "ver": "1.0",
  "complete": 1,
  "nodes": [
    {
      "asi": "ssp-a.com",
      "sid": "pub-12345",
      "hp": 1
    },
    {
      "asi": "exchange-b.com",
      "sid": "acct-67890",
      "hp": 0
    }
  ]
}

The DSP reads this and knows: the bid request originated at ssp-a.com (hp=1) with seller ID pub-12345, then was passed to exchange-b.com with seller ID acct-67890. Both entities are documented. The chain is complete.

Why "Complete" Matters

The complete flag is one of the most important signals in the schain.

When set to 1, it tells the DSP that every entity in the path is represented in the nodes array. When set to 0, it means at least one entity is missing.

An incomplete chain happens when an intermediary in the path doesn't support the schain specification or doesn't properly pass along the chain. The intermediary receives a bid request with a partial schain, fails to add its own node, and passes it on.

DSPs treat complete and incomplete chains very differently.

Complete chains let the DSP verify every hop. The DSP can check each node's asi and sid against sellers.json, confirm the path makes sense, and bid with high confidence.

Incomplete chains mean the DSP is missing information about part of the path. The supply chain has a gap. The DSP doesn't know what entity was skipped or why. This uncertainty gets priced into the bid, typically as a discount.

How DSPs Verify schain

When a DSP receives a bid request with an schain, it runs a multi-step verification.

Step 1: Check completeness. Is the complete flag set to 1? If not, the DSP notes the chain is incomplete and adjusts its confidence accordingly.

Step 2: Verify first node. The first node should match an entry in the publisher's ads.txt. The asi should be a listed exchange domain, and the sid should be a listed account ID.

Step 3: Verify each node against sellers.json. For each node in the chain, the DSP checks the corresponding SSP or exchange's sellers.json file. The sid should appear as a seller_id with matching details.

Step 4: Validate chain logic. The path should make sense. A direct publisher should be the first node with hp=1. Subsequent nodes should be intermediaries. The chain shouldn't contain loops or contradictions.

Step 5: Cross-reference with other signals. The DSP compares schain data with ads.txt authorization, sellers.json identity data, and its own historical data about the entities in the chain.

If all steps check out, the DSP has verified the full supply path. This is the highest level of transparency currently available in programmatic advertising.

schain, ads.txt, and sellers.json: The Transparency Triad

These three standards work together to answer different questions about the same bid request:

| Standard | Question | Maintained By |

|----------|----------|---------------|

| ads.txt | Is this seller authorized by the publisher? | Publisher |

| sellers.json | Who is this seller? | SSP/Exchange |

| schain | What is the complete path from publisher to buyer? | Passed through the chain |

ads.txt is the authorization layer. The publisher declares which entities can sell their inventory.

sellers.json is the identity layer. Each SSP/exchange declares the real identity of every seller on their platform.

schain is the path layer. The bid request itself documents every entity that touched it, in order.

A DSP with access to all three can fully verify a bid request: authorized sellers (ads.txt) with confirmed identities (sellers.json) through a documented path (schain). This is what "full supply chain transparency" means in practice.

Common schain Issues

Incomplete Chains

The most common issue. An intermediary in the path doesn't add its node, resulting in complete=0. This cuts DSP confidence in the entire path, not just the missing node. Publishers should prioritize SSP partners that fully support schain.

Mismatched Seller IDs

The sid in an schain node doesn't match the account in ads.txt or seller_id in sellers.json. This creates a verification failure at that specific node. Often caused by SSP migrations, account restructuring, or data entry errors.

Missing asi Domains

Some nodes include a sid but the asi domain doesn't resolve or doesn't host a sellers.json file. The DSP can't verify the identity of the entity at that node. This is basically a gap in the chain.

Stale Chain Data

If an SSP changes its domain or restructures accounts, previously valid schain nodes become invalid. The schain data in bid requests reflects the current infrastructure of every entity in the path. When infrastructure changes, schain verification failures can spike.

What Publishers Should Do

Publishers don't directly control schain. It's built and passed along by the SSPs and exchanges in the supply path. But you can influence schain quality.

Choose SSPs that support schain. SSPs that fully implement the schain specification and pass along complete chains are better partners for transparent monetization.

Verify your position in the chain. Use tools like BeamFlow's scanner to see how your inventory appears in the supply chain. Check that your SSPs are passing complete chains.

Cut unnecessary hops. Every intermediary in the chain is another node that must be verified. Shorter chains are easier to verify and more trusted by DSPs. Where possible, work directly with SSPs rather than through multiple layers of resellers.

Keep ads.txt and sellers.json accurate. schain verification depends on ads.txt and sellers.json. If those files have errors, schain verification fails even if the chain itself is complete and correct.

Frequently Asked Questions

Does schain affect my CPMs?

Yes, indirectly. DSPs use schain data to assess supply path quality. Complete, verified chains get higher bids. Incomplete or unverifiable chains get discounted. The more transparent your supply path, the higher the bids you attract.

Can I see my schain?

Publishers typically can't see the schain in their own bid requests, as it's assembled and transmitted at the SSP level. Some analytics and monitoring tools can surface schain data. BeamFlow's supply chain analysis provides visibility into how your inventory travels through the supply chain.

What if my SSP doesn't support schain?

Bid requests from that SSP will either have no schain or an incomplete one. DSPs will apply the appropriate discount. Consider whether the SSP's other strengths outweigh the transparency gap, and push for schain support.