Skip to main content

Keeper Network

Keepers are stateless executors responsible for enforcing recurring authorization on-chain.

They do not:

  • hold funds
  • make decisions about pricing
  • extend allowances
  • change subscription terms

They only:

  • observe due subscriptions
  • attempt execution within allowed windows
  • submit transactions that either succeed atomically or fail cleanly

The system assumes keepers are interchangeable and untrusted.

Correctness comes from:

  • on-chain validation
  • idempotency
  • deterministic scheduling (where enabled)

Not from keeper honesty.

Why Keepers Exist​

Blockchains do not have native cron or background execution.

Recurring authorization requires:

  • time-based enforcement
  • automated retries
  • predictable execution without user signatures

Keepers exist to bridge that gap without introducing custody or trust.

They are a mechanical necessity, not a governance role.

Keeper Responsibilities​

A keeper may:

  • Identify a subscription or credit envelope that is due
  • Call execute(module, id) on the PaymentProcessor
  • Pay gas
  • Receive a reward only if execution succeeds

A keeper may not:

  • partially execute a payment
  • charge more than allowed
  • execute early
  • execute twice for the same billing window
  • override caps or expiry
  • bypass authorization checks

All of these are enforced on-chain.

Relationship to Authorization​

Keepers do not "charge users."

They enforce authorization state transitions:

  • active → renewed
  • active → exhausted
  • active → expired
  • paused → inactive

Money movement is a side effect of authorization enforcement.

This framing is intentional and foundational to the RAI model.

Mental Model​

  • Keepers are dumb, replaceable schedulers
  • The chain is the authority
  • Idempotency is the lock
  • Determinism is an optimization
  • Authorization is the product

Keepers exist because someone must submit transactions. They have no special powers, no privileged information, and no trust relationship with users or merchants. They are interchangeable infrastructure, economically motivated to execute correctly and penalized only by wasted gas when they fail.

The system would function correctly with a single keeper or a thousand. The difference is only reliability and latency—never correctness.

Non-Goals​

The keeper system is explicitly not responsible for:

  • merchant prioritization (handled off-chain by indexer)
  • subscription discovery UX
  • plan economics
  • dispute resolution
  • credit accounting
  • agent logic

It is deliberately narrow.