> For the complete documentation index, see [llms.txt](https://vayyl.gitbook.io/vayyl-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vayyl.gitbook.io/vayyl-docs/architecture/services.md).

# Relayers and Indexing

Services improve usability and metadata resistance, but they do not replace onchain verification.

## Relayers

A relayer submits a proof-bound transaction from its own Stellar account. This prevents the connected wallet from appearing as the withdrawal transaction source and removes the need for a shielded address to hold public XLM for fees.

A production relayer network needs:

* multiple independent operators;
* explicit fee quotes bound into the proof or transaction;
* replay protection and idempotent submission;
* privacy-preserving request transport;
* rate limits and denial-of-service controls;
* batching where it measurably improves metadata resistance;
* a wallet fallback when one operator is unavailable.

Moonlight's provider-channel design is a useful Stellar-specific comparison: providers bundle user-authorized activity and become the public submitter. Vayyl's planned relayer layer borrows the submission-separation idea while retaining proof-enforced pool state. Moonlight itself labels its whitepaper a work in progress; Vayyl does not treat it as a settled standard.

## Indexer

The indexer reads public contract events and serves ordered commitments, roots, nullifiers, encrypted outputs, and transaction status. Wallets should be able to verify returned state against ledger data or switch providers.

## Keepers and oracles

Conditional applications add two services:

* **oracles** authenticate public market inputs;
* **keepers** detect when a public condition may permit execution.

Neither should be able to redirect private value. The proof and contract must bind all settlement outputs.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://vayyl.gitbook.io/vayyl-docs/architecture/services.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.