Smart contract factories are already a key piece of infrastructure in the current development landscape and can become an even more important tool in the future as a way to store standards on-chain and allow them to be cloned and initialized by project developers. Cloned contracts’ ability to inherit the trust from their parent model contract allows the benefit of audits of a single model contract to extend to any number of cloned implementations of that contract. If you haven’t already read our article on factories, you can find it here. As factories become more popular and prevalent as a way to deploy more types of contracts a new problem arises: aggregation.

In order for factories to be widely used by developers, a database of all factories would need to be maintained. Tracking all implementations of factories, either by scraping data or having a form for factory developers to submit would suffice, but both of these add an unnecessary level of complexity to the wider adoption of factories. The better, blockchain based solution, is a single contract that all factories can be deployed through. This contract could then maintain organized lists of factory contract addresses that they have deployed and enable versioning of the factories deployed through it. At Ethereans Labs we deployed this such a contract and aptly named it the Factory of Factories.

We will describe how to integrate your factory with Ethereans OS by deploying it using the Factory of Factories, which aggregates all EthOS factories and facilitates a customizable fee that is triggered when a model contract is cloned or used. Any factories deployed this way will automatically be visible from the EthOS Factories website, which will provide a hub for integration with all EthOS tools.

The Factory of Factories is the basis on which a factory marketplace front end can be readily developed. By keeping a list of all the factories, their addresses, their different versions, and by routing fees, all the information from individual factories can be pulled directly from the blockchain. Pulling in metadata that contains descriptions, audits, reputation (say via the Attestation Station on Optimism), and more could all be readily found through this on-chain factory aggregator. While Ethereans Labs is designing such a front end, other front ends could be developed as well for specific purposes or for particular factory deployers. These front ends can also provide forms that allow creation of clone and initialization transactions within a browser, allowing cloned contracts to be deployed simply by anyone with a wallet, removing the need for deploying these contracts with other specialized software.

As discussed in our last article, a Factory is a contract that clones and initializes its model contract.

Our github provides abstract templates for model contracts with customizable initialization and permissions (lazyInitCapableElement) and support for Dynamic On-Chain Metadata (dynamicMetadataCapableElement).

The Factory of Factories (FoF) is a Factory deployer and aggregator.

To integrate your factory with EthOS, deploy it using the Factory of Factories, which aggregates all factories deployed through it and facilitates a customizable fee that is triggered when a model contract is cloned or used. Any factories deployed this way will automatically be visible on the EthOS Factories dApp, which will provide a hub for integration with all EthOS tools.

The FoF keeps track of all factories it has deployed with two internal lists: address[] _hosts and address[][] factoryLists. For each host in _hosts there is a corresponding list of factories owned by that host in _factoryLists. A host can maintain multiple factory lists, each list ideally containing the addresses of all versions of that factory.

There are two functions that are used to deploy a factory through the FoF: create and add.

• The create function appends one or more new entries to _hosts while populating their corresponding lists in _factoryLists with the deployed factory(s). This can be used to deploy a new factory(s) for multiple host addresses.

• The add function appends a new factory to an existing host’s entry in _factoryLists. Only the host is able to add a new factory to its list in _factoryLists.

Both of these functions require you to pass the bytecode of your factory to allow the FoF to deploy it directly.

The host can also call setFactoryListsMetadata to change its address in _hosts.

Using create, add, and setFactoryListsMetadata, anyone can manage multiple lists of factories through the FoF. The Factory of Factories can be used as a powerful version control system, keeping a list of versions for each factory that allows protocols to easily plug-and-play using their preferred version.

The FoF provides two functions that transfer a fee that is split between a designated address (99.92%)* and the OS Treasury (0.08%)*. These functions are payFee and burnOrTransferTokenAmount. The former takes a fixed percent of some transacted value, and the latter takes a fixed amount of a designated token, which is then either burned or sent to the designated address. If the fee is paid in OS token, the FoF automatically burns the amount that would go to the OS Treasury.

These fees are designed to be used in two ways:

Creation fee: A fixed fee (burnOrTransferTokenAmount) that a user must pay when cloning the model contract from the Factory. The fee function is called from within the factory’s deploy function.

Usage fee: A fixed (burnOrTransferTokenAmount) or percentage (payFee) fee that users must pay when using a contract cloned from the Factory. The fee function is called from within the model contract.

The value of these percentages is decided by OS holders via subDAO vote (governance tab, FoF Fee).

To create a Factory, you must:

1. Code the model contract, i.e. the smart contract that your Factory will clone. The model contract must inherit lazyInitCapableElement, which provides several useful features for developers.

2. Deploy the model contract. It is necessary to deploy but not initialize the model contract. If it is initialized, its state variables will be ignored when cloned by the factory.

3. Code your Factory contract and compile its bytecode. Your custom factory will inherit Factory.sol, which provides additional features on top of dynamicMetadataCapableElement.

4. Deploy your Factory by passing the bytecode to the Factory-of-Factories.

The business model for a factory takes the form of an embedded fee in either the model contract being cloned (Usage Fee) or in the factory contract when cloning (Creation Fee).

Both model contracts and factory contracts inherit lazyInitCapableElement. This contract uses lazyInit to save the address which initialized it as its initializer, which we will use to call the fee methods as described below.

The FoF is the initializer of each factory deployed through it. Your custom factory contract can safely make calls to the fee functions of the FoF:

1. Call payFee using IFactoryOfFactories(initializer).payFee

2. Call burnOrTransferTokenAmount using IFactoryOfFactories(initializer).burnOrTransferTokenAmount

To make a static Creation Fee, place the second call above inside the deploy function of your factory.

The FoF is the initializer of a factory, and the factory becomes the initializer of each model contract it clones. Therefore, you can safely obtain the FoF address from within a model contract in this way:

fofAddress = ILazyInitCapableElement(initializer).initializer()

To implement a Usage Fee in your model contract, you can simply make calls from within any function of your model contract to the fee functions of the FoF in the same way as above:

1. Call payFee using IFactoryOfFactories(fofAddress).payFee

2. Call burnOrTransferTokenAmount using IFactoryOfFactories(fofAddress).burnOrTransferTokenAmount

A factory marketplace is going to greatly reduce the barrier to entry for projets looking to build in the space while also allowing developers to monetize their contributions to the code repository. In the next article, we will discuss the DeFi tools and contracts that Ethereans Labs has deployed to the factory marketplace already.

Smart contract factories are already a key piece of infrastructure in the current development landscape and can become an even more important tool in the future as a way to store standards on-chain and allow them to be cloned and initialized by project developers. Cloned contracts’ ability to inherit the trust from their parent model contract allows the benefit of audits of a single model contract to extend to any number of cloned implementations of that contract. If you haven’t already read our article on factories, you can find it here. As factories become more popular and prevalent as a way to deploy more types of contracts a new problem arises: aggregation.

In order for factories to be widely used by developers, a database of all factories would need to be maintained. Tracking all implementations of factories, either by scraping data or having a form for factory developers to submit would suffice, but both of these add an unnecessary level of complexity to the wider adoption of factories. The better, blockchain based solution, is a single contract that all factories can be deployed through. This contract could then maintain organized lists of factory contract addresses that they have deployed and enable versioning of the factories deployed through it. At Ethereans Labs we deployed this such a contract and aptly named it the Factory of Factories.

We will describe how to integrate your factory with Ethereans OS by deploying it using the Factory of Factories, which aggregates all EthOS factories and facilitates a customizable fee that is triggered when a model contract is cloned or used. Any factories deployed this way will automatically be visible from the EthOS Factories website, which will provide a hub for integration with all EthOS tools.

The Factory of Factories is the basis on which a factory marketplace front end can be readily developed. By keeping a list of all the factories, their addresses, their different versions, and by routing fees, all the information from individual factories can be pulled directly from the blockchain. Pulling in metadata that contains descriptions, audits, reputation (say via the Attestation Station on Optimism), and more could all be readily found through this on-chain factory aggregator. While Ethereans Labs is designing such a front end, other front ends could be developed as well for specific purposes or for particular factory deployers. These front ends can also provide forms that allow creation of clone and initialization transactions within a browser, allowing cloned contracts to be deployed simply by anyone with a wallet, removing the need for deploying these contracts with other specialized software.

As discussed in our last article, a Factory is a contract that clones and initializes its model contract.

Our github provides abstract templates for model contracts with customizable initialization and permissions (lazyInitCapableElement) and support for Dynamic On-Chain Metadata (dynamicMetadataCapableElement).

The Factory of Factories (FoF) is a Factory deployer and aggregator.

To integrate your factory with EthOS, deploy it using the Factory of Factories, which aggregates all factories deployed through it and facilitates a customizable fee that is triggered when a model contract is cloned or used. Any factories deployed this way will automatically be visible on the EthOS Factories dApp, which will provide a hub for integration with all EthOS tools.

The FoF keeps track of all factories it has deployed with two internal lists: address[] _hosts and address[][] factoryLists. For each host in _hosts there is a corresponding list of factories owned by that host in _factoryLists. A host can maintain multiple factory lists, each list ideally containing the addresses of all versions of that factory.

There are two functions that are used to deploy a factory through the FoF: create and add.

• The create function appends one or more new entries to _hosts while populating their corresponding lists in _factoryLists with the deployed factory(s). This can be used to deploy a new factory(s) for multiple host addresses.

• The add function appends a new factory to an existing host’s entry in _factoryLists. Only the host is able to add a new factory to its list in _factoryLists.

Both of these functions require you to pass the bytecode of your factory to allow the FoF to deploy it directly.

The host can also call setFactoryListsMetadata to change its address in _hosts.

Using create, add, and setFactoryListsMetadata, anyone can manage multiple lists of factories through the FoF. The Factory of Factories can be used as a powerful version control system, keeping a list of versions for each factory that allows protocols to easily plug-and-play using their preferred version.

The FoF provides two functions that transfer a fee that is split between a designated address (99.92%)* and the OS Treasury (0.08%)*. These functions are payFee and burnOrTransferTokenAmount. The former takes a fixed percent of some transacted value, and the latter takes a fixed amount of a designated token, which is then either burned or sent to the designated address. If the fee is paid in OS token, the FoF automatically burns the amount that would go to the OS Treasury.

These fees are designed to be used in two ways:

Creation fee: A fixed fee (burnOrTransferTokenAmount) that a user must pay when cloning the model contract from the Factory. The fee function is called from within the factory’s deploy function.

Usage fee: A fixed (burnOrTransferTokenAmount) or percentage (payFee) fee that users must pay when using a contract cloned from the Factory. The fee function is called from within the model contract.

The value of these percentages is decided by OS holders via subDAO vote (governance tab, FoF Fee).

To create a Factory, you must:

1. Code the model contract, i.e. the smart contract that your Factory will clone. The model contract must inherit lazyInitCapableElement, which provides several useful features for developers.

2. Deploy the model contract. It is necessary to deploy but not initialize the model contract. If it is initialized, its state variables will be ignored when cloned by the factory.

3. Code your Factory contract and compile its bytecode. Your custom factory will inherit Factory.sol, which provides additional features on top of dynamicMetadataCapableElement.

4. Deploy your Factory by passing the bytecode to the Factory-of-Factories.

The business model for a factory takes the form of an embedded fee in either the model contract being cloned (Usage Fee) or in the factory contract when cloning (Creation Fee).

Both model contracts and factory contracts inherit lazyInitCapableElement. This contract uses lazyInit to save the address which initialized it as its initializer, which we will use to call the fee methods as described below.

The FoF is the initializer of each factory deployed through it. Your custom factory contract can safely make calls to the fee functions of the FoF:

1. Call payFee using IFactoryOfFactories(initializer).payFee

2. Call burnOrTransferTokenAmount using IFactoryOfFactories(initializer).burnOrTransferTokenAmount

To make a static Creation Fee, place the second call above inside the deploy function of your factory.

The FoF is the initializer of a factory, and the factory becomes the initializer of each model contract it clones. Therefore, you can safely obtain the FoF address from within a model contract in this way:

fofAddress = ILazyInitCapableElement(initializer).initializer()

To implement a Usage Fee in your model contract, you can simply make calls from within any function of your model contract to the fee functions of the FoF in the same way as above:

1. Call payFee using IFactoryOfFactories(fofAddress).payFee

2. Call burnOrTransferTokenAmount using IFactoryOfFactories(fofAddress).burnOrTransferTokenAmount

A factory marketplace is going to greatly reduce the barrier to entry for projets looking to build in the space while also allowing developers to monetize their contributions to the code repository. In the next article, we will discuss the DeFi tools and contracts that Ethereans Labs has deployed to the factory marketplace already.