Support multiple factory events for a single contract

[Destiner]

Currently, Ponder supports a single event per factory contract.

Sometimes, contracts have multiple "spawning events" that ultimately create instances of the same type.

For example, Biconomy Account Factory V2 has two events: AccountCreation and AccountCreationWithoutIndex, that are emitted when spawning Account instances.

[Destiner]

As per docs:

Nested factory patterns: The sync engine doesn't support factory patterns that are nested beyond a single layer.

[0xOlias]

There are a few scenarios to disambiguate:

1

One factory contract emits N factory events. Each factory event creates a different kind of child contract (different ABIs).

This is currently supported, just create N items in contracts.

2

One factory contract emits N factory events. All factory events create the same kind of child contract (same ABIs). You want to write one set of indexing functions for all instances of the child contract.

You could get this working right now by creating N items in contracts and registering N sets of the same indexing functions for all.

As a better solution, we could optionally accept an array of configs for the factory option. The engine would collect all addresses matching the config and aggregate them into one "contract". But, I'm not sure the juice is worth the squeeze on this considering there's an OK workaround.

3

One factory contract emits one factory event. Then, all instances of the child contract are also factories and emit a factory event. You'd like to index all instances of that 2nd tier child contract.

Not supported, no known workaround. We could figure out how to support it, but again it seems like a tiny fraction of projects would need this.

[Destiner]

OK what I'm describing falls into scenario 2.

Why do you think it's not worth to make factory accept the array? Surely I can create multiple keys inside the contracts mapping, but that would result in additional mental load:

1. Having to keep both values in the contracts mapping in sync
2. Having to keep the indexing code in sync
3. Conceptually it feels weird to have multiple entries in contracts even though the template is actually the same.

[0xOlias]

Not ruling it out, but it would require nontrivial changes to the sync engine (which would incur a maintenance cost). It's not as easy as just changing the type.