This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support multiple factory events for a single contract #686
Comments
As per docs:
|
There are a few scenarios to disambiguate: 1One 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 2One 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 As a better solution, we could optionally accept an array of configs for the 3One 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. |
OK what I'm describing falls into scenario 2. Why do you think it's not worth to make
|
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. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
andAccountCreationWithoutIndex
, that are emitted when spawningAccount
instances.The text was updated successfully, but these errors were encountered: