Skip to main content

Deterministic Keeper Assignment (Future)

Deterministic assignment exists to reduce:

  • wasted gas from keeper collisions
  • execution contention at scale
  • unpredictable keeper economics

For MVP, open execution is sufficient. Deterministic assignment is an optimization for when the network scales.

Why Determinism Matters for Keeper Economics​

In open execution, all keepers race for every due subscription. This has tradeoffs:

  • Keepers waste gas on losing transactions
  • Rewards go to whoever submits first (often luck or latency)
  • Running reliable infrastructure provides no advantage
  • Profitability is unpredictable

Deterministic assignment changes this. Each keeper gets exclusive execution rights during their assigned window. If you run a reliable node, you capture the full reward for your assigned subscriptions.

This makes keeper economics predictable: a fixed share of protocol volume based on your position in the registered keeper set, not a race against other operators.

How Assignment Works​

For a given subscription, billing window, and epoch, the protocol computes which keeper has priority:

assignedKeeper = hash(subscriptionId, windowId, epoch) % registeredKeeperCount

This is deterministic and verifiable. No coordination, no leader election, no off-chain consensus.

Execution Windows​

Time is divided into epochs, and epochs into micro-windows.

Each micro-window has:

  • a priority phase: only the assigned keeper should execute
  • a fallback phase: execution opens to all keepers

During the priority phase, the assigned keeper has exclusive rights. They can execute without racing, knowing their transaction will succeed (assuming the subscription is valid).

After the priority window expires, any keeper can execute. This ensures liveness even if the assigned keeper is offline.

Incentive to Run Infrastructure​

In the deterministic model:

  • Assigned keepers who execute during priority keep the full keeper fee
  • Keepers who miss their window lose that reward to fallback executors
  • Reliable uptime directly translates to predictable income

This creates strong incentives to run robust, always-on keeper infrastructure. The reward scales with reliability, not with luck or latency.

Registration and the Keeper Set​

Keepers register on-chain to be included in assignment calculations. The registered keeper set determines:

  • who is eligible for priority assignment
  • how subscriptions are distributed across keepers

The expected income for a keeper is roughly:

(total protocol volume * keeper fee rate) / registered keeper count

More registered keepers means smaller individual shares but better network reliability. This self-balances: keeper registration will stabilize where profitability meets operational costs.

Determinism Is Advisory, Not Trusted​

Even in deterministic mode:

  • the chain does not trust keepers to behave
  • assignments are not permissions
  • unassigned keepers are not blocked forever

If the assigned keeper is offline, execution fails, or gas conditions change, fallback execution ensures the system continues.

Idempotency remains the core safety mechanism. Determinism is layered on top, not instead of it.

Why Not Required for MVP​

Open execution works. It is:

  • simpler to implement
  • easier to reason about
  • sufficient for moderate volume

The cost is gas waste from racing keepers. At low volume, this cost is acceptable. At scale, deterministic assignment becomes economically necessary.

The protocol is designed so that deterministic assignment can be enabled without breaking existing integrations. It is a pure optimization.