Factory contracts

[typedarray]

Background

Quick background: Subgraphs allow you to register new child contracts at will inside event handler functions. This means you can use the database and generally write any logic you want around registering child contracts. (In subgraph lingo these are Data Source Templates https://thegraph.com/docs/en/developing/creating-a-subgraph/#data-source-templates).

This approach has a very large hidden cost which is that the "sync" service (fetch & cache raw blockchain data) becomes coupled with the "indexing" service (run user code). In Ponder these are completely decoupled. So, it would require major rework to support this way of doing factory contracts/dynamic data sources.

Proposal

Instead, we can support a slightly less powerful way of registering child contracts that looks like this:

export const config: Config = {
  networks: [ /* ... */ ],
  contracts: [
    {
      name: "UniswapV3Factory",
      network: "mainnet",
      abi: "./abis/UniswapV3Factory.json",
      address: "0x1F98431c8aD98523631AE4a59f267346ea31F984",
      startBlock: 12369621,
      factory: {
        name: "UniswapV3Pool",
        abi: "./abis/UniswapV3Pool.json",
        event: parseAbiItem("PoolCreated(indexed address token0, indexed address token1, indexed uint24 fee, int24 tickSpacing, address pool)"),
        getAddress: (event) => event.params.pool
     }
    },
  ],
};

Here, the getAddress required option is a synchronous function that extracts the child contract address from the factory contract event. Now, you can register event handlers that will run for every instance of the child contract:

ponder.on("UniswapV3Pool:Swap", async ({ event }) => {
  // This will be the address of the child contract that emitted this event.
  console.log(event.log.address)
})

If you want, you could use the getAddress function to filter for specific hard-coded child contracts by returning undefined. But note that you CANNOT use entity store API methods, and the function must be synchronous (cannot make HTTP requests etc).

{
  // ...
  getAddress: (event) => {
    if (event.params.pool === "0xabc...") {
      return event.params.pool
    } else {
      return undefined
    }
  }
}

Edge cases / limitations

Factories of factories

Not supported. Key tradeoff. If your app/protocol uses this pattern, please say something.

I only want to index a subset of child contracts

Supported via a custom getAddress function.

Also, this use case can often be solved by custom log filter with a list of known contract addresses rather than a factory.

I want to use the database to decide if/when to register a child contract

Not supported. The only way to register a child contract is an event log on a factory contract as described above.

Factories that create more than one kind of child contract

Supported. The factory field also accepts an array of child contract configs.

Register child contracts based on transaction calls

Eventually, Ponder will support indexing based on transaction calls (in addition to event logs). Haven't fully explored this, but it seems likely that we could support a similar pattern here where the getAddress function gets the decoded transaction input as an argument.

[peterferguson]

Hey @0xOlias any update on the status?

[peterferguson]

/ do you have a recommended approach to doing something like this in the current version?

we were thinking of dynamically updating the ponder.config.ts & then redeploying on the update but that isn't really ideal

[typedarray]

Hey @peterferguson, just updated the original message, please take a look and LMK what you think. Can't recommend that workaround tbh.

[nftchance]

This would work for me!

[shrugs]

I like this proposal

[neokry]

Is the factory wording in the config a bit confusing for anyone else. I keep thinking that is specifying the factory the contract comes from instead of the children that are spawned.

[typedarray]

Yea I also noticed this. Any ideas for how it could be clearer?

[neokry]

Maybe children as the property name would make more sense here? Can't think of anything better

[piavgh]

I think most projects that use the factory contract pattern only need to be able to do something like UniswapV2Factory + UniswapV2Pool (V3 is the same)

So I think what in this proposal is enough for most use cases

Is there an ETA for this?

[shrugs]

i've run into a protocol that's deploying multiple contracts as part of its factory and emitting an event like NewBlahBlah(address firstThing, address secondThing), and it'd be nice to be able to model this in ponder as a factory with multiple children ala

      children: [{
        factoryEventAddressArgument: "firstThing",
        name: "FirstThing",
        abi: FirstThingAbi,
      }, {
        factoryEventAddressArgument: "secondThing",
        name: "SecondThing",
        abi: SecondThingAbi,
      }],

[typedarray]

i've run into a protocol that's deploying multiple contracts as part of its factory and emitting an event like NewBlahBlah(address firstThing, address secondThing), and it'd be nice to be able to model this in ponder as a factory with multiple children ala

Thanks SO much for mentioning this, very timely. I also noticed this on a protocol I've been using for testing.

Will update the API accordingly, and make sure the sync engine doesn't duplicate work when handling multiple children.

I have factory contracts working and tested on this branch. Will release an alpha version within the next day or so.

[piavgh]

I have factory contracts working and tested on #361. Will release an alpha version within the next day or so.

Love to try this