livepeer / livepeer/go-livepeer

Allow gateway or remote signer to select and verify pricing oracle policy for BYOC jobs

Open
#3,930 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

status: triage
Dominant language
Go
Stars
586
Forks
226
Avg merge
1d 17h
Merged PRs (30d)
19

Description

## Problem

For BYOC jobs, the orchestrator currently advertises a final `PriceInfo` and the gateway / remote signer can enforce maximum acceptable price caps. That protects buyers from overpaying, but it does not let the buyer decide which pricing oracle or pricing policy was used to produce the advertised price.

This is lower priority than orchestrator-side per-capability oracle selection, but it becomes useful if BYOC pricing moves toward signed offchain oracle records or multiple pricing policies.

Related primary issue: #3929

## Current behavior / research

Researched against `feat/remote-signer-byoc` at `a78e876ff6c97d935344643c2547d0f84d4b26dd`.

Relevant behavior:

- Orchestrator returns `PriceInfo` for BYOC using `Capability_BYOC` plus the registered external capability name as the constraint.
- Gateway / remote signer uses the advertised wei price and local max-price settings to decide whether payment is acceptable.
- `-maxPricePerUnit` and `-maxPricePerCapability` can use custom currency conversion, but they also rely on node-level price-feed conversion and only express buyer caps.
- There is no current metadata in the pricing response that says which oracle/policy generated the price, whether the quote is signed, or whether it is valid until a specific time.

## Proposal

Add an optional buyer-side oracle/policy selection path for BYOC jobs.

Possible shapes to evaluate:

1. Gateway / remote signer config can require an accepted oracle or policy per capability/model:

```json
{
"capability": "BYOC",
"model_id": "openai-chat-completions/Qwen3-Coder-30B-A3B-Instruct",
"accepted_oracles": ["competitive-v1"],
"max_price_per_unit": 6000000000,
"pixels_per_unit": 1
}
```

2. Orchestrator includes optional price provenance metadata with the current `PriceInfo`, for example policy id, oracle id, valid-until, and signature.

3. Gateway / remote signer verifies that metadata before generating payment. It should reject prices from unknown policies, expired signed records, invalid signatures, or records that do not match the requested `orchestrator + capability + model`.

4. If the gateway selects a policy for a job, the selected price should be locked into the job/session payment path so the orchestrator and signer agree on the same price for the work being paid.

## Non-goals for the first version

- Replacing buyer max-price caps. Caps should remain the final buyer protection layer.
- Requiring every orchestrator to publish signed oracle records. This can be optional and negotiated.
- Blocking the simpler orchestrator-side per-capability oracle work in #3929.

## Acceptance criteria

- Gateway / remote signer can optionally require a pricing oracle or policy for a BYOC capability/model.
- Existing max-price cap behavior continues to work without oracle metadata.
- A valid signed oracle record or equivalent provenance metadata can be accepted.
- Wrong oracle, wrong policy, expired quote, invalid signature, or mismatched capability/model is rejected.
- The accepted price is the same value used for the BYOC payment calculation.
- Tests cover accept/reject behavior and backward compatibility when no oracle policy is required.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the BYOC PriceInfo flow through the orchestrator, gateway, and remote signer, then compare it with the existing max-price settings and payment calculation. Done means an agreed implementation of optional oracle or policy provenance, validation and payment locking, with acceptance and backward-compatibility tests covering the listed cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend, payments
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.