Problem
Pioneer feedback reports that public faucets become slow and difficult to reinitialize as usage grows.
When a public faucet has accumulated a large amount of history, client re-initialization and sync can take several minutes. Developers end up implementing custom sync logic to avoid full or unnecessary sync work.
Why this matters
Faucets are one of the first account types app developers use. If the simple faucet path works only for small examples, every production-ish app has to rediscover the same sync strategy under load.
This is especially painful for public test faucets, where high usage is expected and where new clients may need to initialize from an already-large account.
Proposed scope
Define the recommended sync strategy for large public faucets and improve the client where the current APIs make that strategy hard to implement.
Potential areas to cover:
- avoid unnecessary full sync work for large public faucet accounts,
- clarify when nullifier sync is required for faucet operators vs. ordinary users,
- expose or document a lighter initialization path for faucet clients,
- document how account storage/vault sync should be handled for large faucets,
- align with ongoing
StateSync and large-account sync refactors.
Acceptance criteria
- The client team has a documented recommended strategy for initializing/syncing large public faucets.
- Developers do not need custom ad hoc sync logic for common high-volume faucet use.
- Any required client API changes are identified or implemented.
- The docs explain which sync operations faucet operators actually need.
- The issue is linked to broader large-account /
StateSync work.
Related context
Problem
Pioneer feedback reports that public faucets become slow and difficult to reinitialize as usage grows.
When a public faucet has accumulated a large amount of history, client re-initialization and sync can take several minutes. Developers end up implementing custom sync logic to avoid full or unnecessary sync work.
Why this matters
Faucets are one of the first account types app developers use. If the simple faucet path works only for small examples, every production-ish app has to rediscover the same sync strategy under load.
This is especially painful for public test faucets, where high usage is expected and where new clients may need to initialize from an already-large account.
Proposed scope
Define the recommended sync strategy for large public faucets and improve the client where the current APIs make that strategy hard to implement.
Potential areas to cover:
StateSyncand large-account sync refactors.Acceptance criteria
StateSyncwork.Related context
StateSyncfromStoreand fix sync error #2102