Indexer

The indexer is an off-chain service that observes blockchain events and reconstructs protocol state for consumption by keepers, dashboards, and integrations.

It provides:

• aggregated views of plans, subscriptions, and payments
• computed fields (next due date, remaining executions)
• APIs for querying protocol state
• feeds for keeper execution

It is:

• a read-only observer
• a convenience layer
• replaceable and rebuildable

It is not:

• a source of truth
• a settlement authority
• required for correctness

Why It Exists

Blockchains are append-only logs, not queryable databases.

To answer questions like "Which subscriptions are due right now?" or "What is this merchant's MRR?", you must either scan all historical events on every query (expensive, slow) or maintain an indexed view of state.

The indexer exists because off-chain systems need efficient access to on-chain state. It does not exist to make decisions. It exists to make information accessible.

What It Observes

The indexer listens to contract events:

Event	Data Captured
PlanCreated	Plan parameters, merchant, token
SubscriptionCreated	Subscriber, plan, initial state
EnvelopeCreated	Agent, subscriber, credit plan
ExecutionExecuted	Payment details, timestamp, fees
ExecutionFailed	Failure code, timestamp
SubscriptionPaused	State change
EnvelopeSettled	Credit consumption checkpoint

From these events, the indexer reconstructs current state, payment history, and computed metrics.

How Keepers Use It

Keepers poll the indexer to find due executions:

1. Keeper requests /due endpoint
2. Indexer returns list of items ready for execution
3. Keeper submits transactions
4. Chain validates and executes (or rejects)
5. Indexer observes execution events and updates state

Keepers use the indexer for efficiency, not authority. They trust the chain's validation, not the indexer's claims.

Why Merchants and Agents Need It

Merchants need it for viewing subscriber lists, tracking revenue, monitoring failures, and understanding churn.

Agents need it for checking authorization status efficiently and monitoring envelope state.

Both accept the tradeoff: trust the indexer for read efficiency, fall back to chain queries if needed, accept that displayed data may lag by seconds.

Relationship to RAI

The indexer is the observation layer of Recurring Authorization Infrastructure.

RAI separates:

• Authorization: on-chain, trust-minimized
• Execution: on-chain, permissionless
• Observation: off-chain, convenience

The indexer serves observation. It makes the protocol usable without compromising the trust model.

Non-Goals

The following are out of scope:

• Payment execution: The indexer suggests; keepers execute; the chain validates.

• Authorization decisions: The indexer reports authorization state; it does not determine it.

• Dispute resolution: Disputes reference chain state, not indexed state.

• Data origination: All indexer data derives from chain events.

• Privacy: The indexer observes public blockchain data. It does not add or remove privacy.