Factory contracts
In some cases the set of contracts to be indexed by the squid is not known in advance. For example, a DEX contract typically creates a new contract for each trading pair added, and each such trading contract is of interest. While the set of handler subscriptions is static and defined at the processor creation, one can leverage wildcard subscriptions and filter for contracts of interest at runtime. Let’s consider how it works in a DEX example, with a contract emittingPoolCreated log when a new pool contract is created by the main contract. Full code is available in the examples repo.
src/processor.ts
src/main.ts
Two-pass indexing for factory contracts
Squids built with the pattern shown above get the job done, but retrieve a lot of data that ends up discarded in the process. Complete elimination of this overhead would require dynamically changing the processor configuration, which is not currently possible. However, the configuration can be changed at a fixed block and that can be used to eliminate most of the overhead, drastically reducing the sync time. The technique has a couple of limitations:- The number of newly deployed contracts should be moderate (roughly up to tens of thousands). If your factory contract deploys contracts by millions (e.g. Pancakeswap), then vanilla factory pattern will be faster.
- You will need to periodically perform an extra action to keep the syncing overhead of your squid to a minimum.
src/processor.ts
./assets. This squid should be re-ran every time the number of blocks for which the whole network data is retrieved (that is, preloadedHeight+1 to current head) becomes unacceptably large.
This approach is implemented in the squid indexing the thena.fi decentralized exchange.
