Disclaimer

<aside> ⚠️

This is a first draft of this tech spec. It showcases how we could implement the protocol changes to allow us to distinguish different job categories on-chain. However, please note:

• The exact encoding depends on input from the Core Contribuotrs, Growth and Markets advisory board members based on what information is required to see on-chain.
• The go-livepeer implementation foundi n this spec is a quick example of how this could work, not a final implementation spec. </aside>

<aside> ⏩

Status: POC implemented on the protocol, needs more discussion to decide on the encoding.

</aside>

1. Overview

As Livepeer expands into new workloads like AI inference, tracking how the network is used becomes increasingly important. Currently, we rely on off-chain heuristics, like monitoring known gateways via the Dune dashboard, to distinguish job types. This approach doesn't scale and is fragile.

To improve transparency, analytics, and future capabilities like differentiated billing or prioritization, we propose embedding job type metadata directly on-chain within the Ticket structure by extending the existing auxData field.

2. Motivation

Without job type metadata:

• We can’t confidently measure protocol usage distribution across workloads like transcoding, AI, Realtime AI and BYOC jobs.
• We lack visibility into economic contribution by segment, making it harder to prioritize features and partnerships.
• Orchestrators can't make informed decisions about which workloads to serve.
• Governance and investors lack transparency, limiting informed decisions about protocol development.

3. Goals and Non-Goals

Goals:

• Encode job type metadata directly in the Ticket structure on-chain.
• Maintain backward compatibility across clients, subgraph, and third-party tools.
• Keep gas usage minimal.