[ibrajer]

Enforce a worst-case floor on the fulfillment gas limit, derived solely from the request's own callbackGasLimit and precalculated gas overheads before and after callback. The gas overhead default value was determined by comparing values across different chains where VRF is supported: Native-payment range: 110k – 164k, LINK-payment range: 121k – 164k. It's possible to override the value by using the newly introduced job spec field.

callbackGasLimit × 64/63 + GasOverhead (200k default; or override from job spec) + margin (10k)

This guarantees the transaction can always complete billing; a fully burning callback now takes the designed success=false path (still billed) instead of an out-of-gas revert.

Additionally, the subscription balance pre-check now reserves the worst-case request cost, including the premium at the gas lane max price, rather than only the simulated fee. The premium defaults to 100% and can be overridden in a job spec.

Requires

Supports

Deployment Validation Steps

[github-actions]

✅ No conflicts with other open PRs targeting develop

[Copilot]

🟡 Changes recommended

The gas floor is not applied before fulfillment simulation, allowing sender-dependent callbacks to fail on every retry and leave funded requests unfulfilled.

4 open issues

• Simulation gas is not floored before fulfillment · New
• Test does not cover callback exhausting its gas allowance · New
• Failed config refresh retries on every processing pass · New
• Failed refresh can return a cached gas bound below the fallback · New

What changed in this PR

This PR adds a worst-case gas floor to VRF fulfillment transactions, aiming to preserve enough gas for billing when a callback consumes its full allowance.

Changes:

• Calculate and apply a fulfillment gas floor using the callback allowance, proof verification cost, coordinator configuration, and margin.
• Cache the coordinator’s gas accounting configuration, with fallback handling for failed reads.
• Add unit tests for floor calculations and an integration test checking the fulfillment transaction’s gas limit.

File	Description
core/​services/​vrf/​v2/​listener_v2.go	Adds synchronized coordinator gas-config cache fields.
core/​services/​vrf/​v2/​listener_v2_log_processor.go	Applies the gas floor before enqueueing fulfillments.
core/​services/​vrf/​v2/​listener_v2_helpers.go	Defines the floor calculation, config cache, and fallback.
core/​services/​vrf/​v2/​listener_v2_helpers_test.go	Tests calculation boundaries and fallback sizing.
core/​services/​vrf/​v2/​integration_v2_plus_test.go	Adds the VRF V2 Plus gas-floor integration case.
core/​services/​vrf/​v2/​integration_helpers_test.go	Checks the mined fulfillment’s gas limit against the floor.

_{Review effort: Balanced}

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs

[Copilot]

🟡 Changes recommended

The balance check reserves only the cheaper simulated payment despite the higher callback gas limit, allowing shared subscription balances to be overcommitted and later fulfillments to fail for insufficient funds.

1 open issue

• Reserve worst-case payment for the increased callback gas limit · New

4 resolved since last review

• Simulation gas is not floored before fulfillment
• Failed refresh can return a cached gas bound below the fallback
• Failed config refresh retries on every processing pass
• Test does not cover callback exhausting its gas allowance

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Fee reservations omit applicable flat fees and configured gas overhead and ignore coordinator price-fallback rules, risking billing reverts or blocking adequately funded fulfillments.

2 open issues

• Use the configured gas overhead in worst-case fee estimates · New
• Apply coordinator fallback pricing in the fee reservation · New

1 previously missed issue

In code that hasn't changed since last review

Include flat fulfillment fees in the worst-case reservation

core/​services/​vrf/​v2/​listener_v2_helpers.go:84

On a low-gas-price lane with a nonzero flat fulfillment fee, this maximum can under-reserve the full-callback bill: maxFee includes the flat fee with simulated gas usage, while fundsNeeded includes the full callback allowance but no flat fee. If callback usage increases after simulation, a subscription funded to this reservation can pass the balance check and then revert during billing, even with the default 100% reservation premium. Include the applicable native flat fee or discounted LINK flat fee in the worst-case estimate before comparing it with the simulated charge.

1 resolved since last review

• Reserve worst-case payment for the increased callback gas limit

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Batched fulfillments bypass the per-request gas floor and can exceed the transaction gas budget, while failed LINK feed lookups and omitted flat fees can admit underfunded requests.

3 open issues

• Apply funding floors before packing batched fulfillments · New
• Include flat fees in worst-case subscription funding estimate · New
• Do not zero out required funds when feed lookup fails · New

2 resolved since last review

• Apply coordinator fallback pricing in the fee reservation
• Use the configured gas overhead in worst-case fee estimates

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Worst-case fee estimates omit coordinator flat fees and ignore feed freshness and fallback rules, risking billing reverts or blocking adequately funded fulfillments.

1 open issue

• Reservation estimate ignores stale-feed fallback pricing · New

3 resolved since last review

• Apply funding floors before packing batched fulfillments
• Do not zero out required funds when feed lookup fails
• Include flat fees in worst-case subscription funding estimate

_{Review effort: Balanced}