SupplyChain 1.1: the hops that don't get paid are about to become visible

The SupplyChain object — schain — is the part of every bid request that names the hops. It’s supposed to answer a simple question: who handled this impression on its way from the publisher to the buyer? Since 2019, it has been the backbone of programmatic transparency, the thing a DSP reads to know whether a path is clean.

But it has carried a quiet blind spot the entire time. The chain mostly accounts for the entities that get paid — and programmatic is full of entities that touch your bid request without ever touching the money. Yield optimizers. Supply-path routers. Passthrough resellers. Header-bidding tech. They take custody of the request, shape the auction, and then hand it on — invisibly, as far as the schain was concerned.

On June 23, 2026, IAB Tech Lab opened schain 1.1 for public comment to fix exactly that. The comment window closes August 21, 2026. It’s a small-looking spec change with a long tail, and it’s worth understanding before the industry settles it.

What 1.1 actually proposes

The headline change is the formal adoption of hp=0 nodes.

hp is the payment-handling flag on each node in the chain. hp=1 means the node handles payment for the impression; hp=0 means it doesn’t. The original spec technically allowed hp=0 nodes — but the market never used them, so in practice the chain only ever represented the money trail. 1.1 closes the gap between what the spec accommodated and what anyone actually implemented.

The concrete pieces:

• A new version attribute distinguishes 1.1 chains from older ones, so consumers know which rules a given chain follows.
• New enumerations for supplychain.complete to express completeness under the 1.1 model.
• hp=0 nodes do not require ads.txt validation — but referencing a sellers.json entry for them is strongly recommended.
• sellers.json 1.1 sharpens the is_passthrough field: “A passthrough seller is a facilitator of inventory from the upstream supplier to the consumer of the inventory.” The doc is explicit that is_passthrough=1 is what lets a seller be used as a non-payment (hp=0) node.
• The INTERMEDIARY definition is tightened too: inventory sold through an intermediary account isn’t owned by that entity, or the ad system doesn’t pay them directly — and all intermediaries take custody of the bid request. That last clause is the whole point. Custody, not payment, is what makes you part of the chain.
• Documentation gets consolidated: the old OpenRTB SupplyChain Object page is deprecated, the standalone ads.txt inventory-sharing explainer is deleted, and everything folds into a single Implementation Guidance document.

Why “the hops that don’t get paid” matter

It’s tempting to dismiss non-payment nodes as plumbing. They’re not — they’re where a lot of modern programmatic decisioning now lives.

A yield-optimization partner that re-routes your auction, a supply-path tool that picks which exchange to send a request through, a wrapper that decides bid order — none of these necessarily handle payment, but all of them shape what the buyer sees and what the impression earns. Until now, a buyer reading the schain couldn’t see them. The path looked shorter and cleaner than it actually was.

That’s not a rounding error in a fraud context. As we wrote in the 2026 state of supply-chain transparency, every bid request is a claim, and the unverifiable hops are where budget leaks. Making hp=0 entities representable means the chain can finally describe who actually touched the request, not just who got a cut. For a buyer trying to reason about provenance — increasingly the same problem as telling a good agent from a bad one — that’s a real upgrade in signal.

The schain told you who got paid. 1.1 lets it tell you who was involved. Those were never the same list — and the difference is exactly where transparency leaked.

The validation trade-off

There’s a tension baked into the proposal, and it’s worth being clear-eyed about.

By not requiring ads.txt validation for hp=0 nodes, 1.1 lowers the friction to declaring them — which is probably the only way adoption happens at all. But it also means these newly-visible hops sit under a softer trust regime than payment-handling nodes. A sellers.json reference is “strongly recommended,” not required. So you gain visibility into the non-payment hops while accepting that they’re declared, not hard-validated.

That is a reasonable bootstrapping choice. It is also precisely the seam where the proposal’s two biggest fights live.

The two fights that will decide how far this goes

The public comment period has two open sub-questions, and how they resolve matters more than the hp=0 mechanics themselves.

1. Do publishers’ own first-party tech have to be listed? There’s broad agreement that all third parties should appear in the chain. The open debate is whether a publisher’s own technology — its first-party stack — must be listed too. It sounds academic, but it decides what “complete” actually means. If first-party hops can be omitted, a complete chain still isn’t a full account of who touched the request.

2. Should there be independent validation — a “Custodian”? The idea of letting verification vendors independently validate the chain, via a “Custodian” concept, was, in the proposal’s own words, “hotly debated.” As written, 1.1 doesn’t support it — because doing so would force publishers to maintain distinct SSP seats for every yield-optimization partner they work with, which is operationally brutal. So independent, third-party validation of these new nodes is, for now, off the table.

Put those together and you get the honest shape of 1.1: a meaningful transparency improvement that deliberately stops short of a matching verifiability improvement. The chain will describe more. Whether you can independently trust what it describes is the fight that’s still live.

What to actually do before August 21

1. If you’re a publisher or SSP, read the proposal and comment. This is a rare window where the people who operate the supply chain get to shape the standard before it sets. The hp=0 model, the first-party-listing question, and the Custodian debate are all still movable until the comment period closes.

2. Inventory your own non-payment hops now. Whether or not the spec forces it, you should already know which yield tools, routers, and passthrough partners take custody of your requests. 1.1 is going to make that list public eventually — better to author it deliberately than have it inferred.

3. Buyers: treat declared hp=0 nodes as signal, not proof. Visibility is up; hard validation isn’t. A node you can see but can’t independently verify is useful context, not a guarantee. Keep weighting paths by how much of the chain is actually validated.

4. Don’t wait for “complete” to mean complete. Until the first-party-listing question is settled, a complete 1.1 chain may still omit the publisher’s own stack. Read completeness claims accordingly.

Transparency is a description; trust is a decision

The throughline of schain 1.1 is that the chain is getting better at describing itself — more of the hops that actually shape an auction will be nameable, including the ones that never see a dollar. That’s genuine progress, and it’s worth engaging with before the comment period closes.

But a richer description isn’t the same as a trustworthy one, and the proposal is honest about leaving independent validation unsolved. That’s the gap a buyer still has to close on its own — and it can’t be closed by reading a longer chain after the auction. It has to be evaluated in the moment, on every bid request, against everything else known about the path.

That’s the conviction Lumorrow is built on: the supply path — payment-handling and non-payment hops alike — is something to assess in real time, pre-auction, before the impression is ever bought. A better schain gives the auction more to reason about. Reasoning about it is still the exchange’s job.

---

Lumorrow evaluates supply-path quality and provenance on every bid request in real time, pre-auction, across web, CTV, and OTT. See how the platform works → or explore it for demand partners →. The schain 1.1 public comment period is open until August 21, 2026.