Skip to main content

Keeper Incentives

Keepers are paid directly from protocol fees. Payment only occurs on successful execution. Failed attempts are unrewarded.

This creates a simple incentive: only execute when you are confident the transaction will succeed.

There is no slashing, bonding, or staking required initially.

Fee Structure​

Fee rates are resolved per module via the FeeSchedule contract. Each module may have a different tier (e.g. different protocol and keeper fee rates). The split is:

Payment Amount
├── Merchant receives: payment minus protocol fee
└── Protocol fee: resolved from FeeSchedule per module
    ├── Keeper receives: share of protocol fee (tier-dependent)
    └── Treasury receives: remainder of protocol fee

Fees are paid atomically in the same transaction. The keeper receives tokens directly from the payer via Permit2—no custody, no intermediary.

Economics in Open Execution​

In the current model, all keepers compete for every execution. Profitability depends on:

  • gas costs
  • network latency
  • luck

This is acceptable at low volume but becomes inefficient at scale.

Economics in Deterministic Mode​

With deterministic assignment, economics become predictable:

Expected income = (protocol volume * keeper fee rate) / keeper count

Reliable infrastructure directly translates to captured rewards. There is no racing, no wasted gas on losing transactions.

Why No Staking or Slashing​

The system does not require keepers to stake tokens or face slashing for several reasons:

  • Idempotency handles correctness: Double-charges are impossible regardless of keeper behavior
  • Fallback handles liveness: Missed assignments are picked up by other keepers
  • Gas is sufficient penalty: Failed attempts cost gas, naturally discouraging bad behavior

Staking would add complexity without improving safety. The on-chain validation already ensures correctness.

Future Considerations​

As the network grows, additional mechanisms may be considered:

  • Reputation scoring based on execution success rate
  • Tiered priority based on historical reliability
  • Optional bonding for premium assignment slots

These would be additive optimizations, not security requirements.