SupplyChain v1.1 is a draft that would extend the schain object from the payment path to technical custody. IAB Tech Lab announced it on June 23, 2026 and took public comment until August 21, 2026. It adds entities that take custody of a bid request as nodes marked hp=0. As of October 2, 2026, the proposed text sits on development branches, not in the main spec.

What does version 1.0 cover today?

The current SupplyChain spec describes the chain as the entities in the direct flow of payment. It says hp should always be 1 in version 1.0, and that future versions may add entities that are in the transaction but not in the payment flow. Version 1.1 is that step.

What would version 1.1 add?

The announcement says buyers would see which entities take technical custody of a bid request as it moves through systems such as Prebid, ad servers, SSAI platforms, SDKs and wrappers. The working group considered several approaches and recommended adding them directly to the main chain, using hp=0 for any entity outside the payment flow, according to the same release. The release names three things a buyer should be able to learn from a v1.1 chain: how the request originated, who took technical custody of it, and which parties were in the payment flow.

The draft text adds more detail:

  • ver takes the value “1.1”, and complete gains a proposed enum: 0 not complete, 1 payment complete, 2 payment and tech complete, per the develop-branch spec.
  • hp=0 nodes follow the order of the request, which may differ from the order of payment, and consecutive hp=0 nodes from one company collapse into one, per the draft implementation guidance.
  • An hp=0 node needs no ads.txt entry, though a sellers.json entry is strongly recommended, per the same draft.
  • Entities that only supply data or recommendations, without taking control of the request, are out of scope in the same draft.
  • Every entity that was listed under 1.0 stays in the chain, whether or not it is a technical hop, according to the same draft.

What could change for path checks?

Three effects follow from the draft.

  1. Chains get longer. The release says schains will become longer as transparency improves, and it promises rollout guidance on staged testing, parsing checks and bid-health monitoring. A node-count limit written for 1.0 would see more nodes for the same supply.
  2. ads.txt checks move to payment nodes. The draft guidance says DSP validation should skip hp=0 nodes and look for is_passthrough=1 with a matching sellers.json entry instead.
  3. First-node checks move. The same guidance expects hp=0 nodes ahead of the first payment node, so a rule that the first node must be the publisher’s DIRECT seller has to start at the first hp=1 node.

The release also quotes a buy-side supporter who says a longer chain that discloses its parties is better for buyers than a short chain that hides them, and who calls for moving beyond simple node counting.

Where does the draft stand as of October 2, 2026?

  • The comment window ended August 21, 2026, and the GitHub tracking issue shows as closed.
  • The text lives on the dev branch of the Supply Chain Validation repository and the develop branch of the OpenRTB 2.x repository. The main-branch SupplyChain spec still describes version 1.0, and the newest OpenRTB release, 2.6-202606 of June 11, 2026, predates the announcement.
  • Six pull requests that propose wording changes are open, according to the repository’s pull request list.
  • We found no announcement that v1.1 is final.

Two questions drew debate. One is whether a publisher’s own first-party technology belongs in the chain, which the question’s own description calls an open debate. The other is validation. The validation thread says a “Custodian” approach was debated and not carried into the draft, and commenters say buyers still lack a standard way to verify hp=0 disclosures. Check the repository before you build against any of this.

How does Vectravia handle this?

Path Check compares the SupplyChain object in each bid request with ads.txt, app-ads.txt and sellers.json. It flags unauthorized sellers and incomplete chains. This article makes no claim about v1.1 support, because the standard is still a draft.