There exists a duality in the nature of trust surrounding smart contracts deployed to the EVM. On the one side, the contracts themselves are entities that execute code exactly without the need to trust an entity on the other end of a transaction. On the other side, you are explicitly trusting the person who deployed that contract in the first place when interacting with it. All too often the implicit trust in the deployer of the contract can lead to real harm to users, whether through human error when writing code or through malicious intent by the deployer of the contract. Audits, testing, and bug bounties all aim to increase the trustworthiness of a contract, and these methods are valuable for all deployments and necessary for new code (more on this later). This need to increase the trust of code is at odds with the system of trust that the blockchain enables, especially code that is deployed multiple times across different implementations.

A look at the development stack reveals that while standards are developed and published, they are done so on legacy infrastructure and the implementation is left to developers to correctly use and apply the standards when making their product. Take for example the ERC-20 token standard. The nine functions and two events that are required to be called an ERC-20 token contract are defined on the Ethereum Foundation's website and a simplified example implementation is given. Here is where trust can break down, as the development and implementation of this standard happen off chain (i.e., copied from Github, then possibly modified arbitrarily before deployment) requiring each implementation to be reevaluated, even if it follows the standard exactly. While there can certainly be malicious modifications to the standard during this implementation, mistakes can also be introduced in this step as copy-pasting from GitHub does not enforce immutability. Fortunately, there is a way to leverage the security provided by the EVM to quickly deploy contracts that can inherit trust: factories.

Factories are contracts that can deploy clones of model contracts that take some custom initialization data. These daughter contracts inherit their functions from the parent contract in a way that the functionality of the contract is not altered. For example, Uniswap implements a factory model for deploying liquidity pools where the factory contract takes the addresses of the tokens to pool and deploys a new liquidity pool contract for those tokens. This means that while all liquidity pools are contracts, none of the individual pools need to be audited as long as the factory is trusted.

At Ethereans Labs, we have created a generalized infrastructure for creating modular factories and model contracts. A Factory is defined as a contract that clones and initializes a model contract, whose address is saved in the Factory contract and can be managed by the Factory’s host. The host can be any address, including a contract address, such as an on-chain Organization, multi-sig, or it can even be set to a burn address to ensure that the Factory’s model contract address is permanent.

At the top of the infrastructure is the Factory of Factories (FoF), which is a factory deployer that acts as a database of all factories deployed through it. The database contains multiple lists of factory addresses, where each list defines a host address that can add to it. When deploying a factory, the host can choose to create a new list or to append the deployed factory’s address to an existing list (of which they are the host), thereby providing an on-chain history of factory versions. The FoF also contains standardized fee functions that can be optionally integrated into a custom Factory or model contract, allowing developers to easily monetize the use of their factories while contributing to the EthereansOS Organization.

A core goal of Ethereans Labs is to enable an anonymous and open-source development ecosystem based on Factories. Going back to the ERC-20 example from earlier, if a factory was created for the ERC-20 token standard and audited, then the implementation of any ERC-20 contract deployed from that factory can be automatically trusted.

This moves trust up a level in the development process - from the individual contract implementing the standard to its model contract or factory. If there exists a finite amount of auditors’ time (including casual audits by the community), this time can be focused on a single model contract where the trust is extended to the deployed clones, rather than needing to audit each implementation.

Ethereans Labs has already deployed many factories using this infrastructure that address some of the most common smart contract use cases in DeFi, NFTs, and DAOs.

The farming factory allows anyone to deploy their own farming contract. The model contract provides functions that allow users to deposit liquidity and earn their share of the designated reward tokens. The deployer can designate the reward token and amount, which is managed by the additional cloned extension contract, designed to enforce safe handling of the farm’s funds.

A common rug pull involves first attracting liquidity (usually via a farm) and then minting a huge supply and immediately selling it into the farmers’ liquidity. Participants must trust that the deployer will not abuse their ability to mint tokens; however, with factory-produced Routines contracts it is possible to safely manage a token’s supply and more. Developers can safely grant minting permission to the Routine contract, specifying an amount to be minted periodically. Alternatively, since a Routine contract uses a cloned extension contract as its treasury, that contract can hold existing tokens rather than minting them.

More generally, a Routine can specify a list of transactions that include your choice of minting, transferring, swapping via DEX, or burning. This can be used to manage token inflation, payroll in a DAO, and more.

Ethereans Labs has developed the Item, a token superstandard that includes both ERC1155 and ERC20 capabilities. From the Item Main Interface, you can clone your own Item, specifying its metadata, supply, etc. It supports all ERC20 and ERC1155 functions and can be used anywhere these standards are accepted. Furthermore, there exists a suite of wrappers, in which you can wrap existing NFTs or other tokens as an Item, granting them interoperability across NFT and DeFi platforms as well as special wrappers that combine the supply of NFTs from a collection making them fungible, much like NFTX or MUSE.

Because on-chain governance structures are themselves composed of smart contracts, the factory-based approach is the perfect framework for implementing these behaviors. Our Organizations are completely customizable and are composed of a core contract that manages attached component contracts. Factories for standardized components such as proposal manager contracts, treasury contracts, and voting rules can be created by anyone, which creates an open ecosystem in which a competitive and evolving suite of DAO components will emerge.

The use of factories in smart contract deployment offers a solution to the trust issues that arise when relying on the deployer of a contract. By allowing deployment of standards to happen on-chain via Factories, code reuse becomes ‘free’ from an auditing standpoint, allowing security to be inherited and therefore providing a more efficient development ecosystem in the Ethereans Operating System. Additionally, the Factory of Factories offers a way to manage and track all factories deployed through it providing both a database of factories and an on-chain history of factory versions. With this infrastructure in place, smart contract deployment can become more secure and trustworthy for all users. In our next post, we will dive deeper in to the contract architecture of the Factory ecosystem.

There exists a duality in the nature of trust surrounding smart contracts deployed to the EVM. On the one side, the contracts themselves are entities that execute code exactly without the need to trust an entity on the other end of a transaction. On the other side, you are explicitly trusting the person who deployed that contract in the first place when interacting with it. All too often the implicit trust in the deployer of the contract can lead to real harm to users, whether through human error when writing code or through malicious intent by the deployer of the contract. Audits, testing, and bug bounties all aim to increase the trustworthiness of a contract, and these methods are valuable for all deployments and necessary for new code (more on this later). This need to increase the trust of code is at odds with the system of trust that the blockchain enables, especially code that is deployed multiple times across different implementations.

A look at the development stack reveals that while standards are developed and published, they are done so on legacy infrastructure and the implementation is left to developers to correctly use and apply the standards when making their product. Take for example the ERC-20 token standard. The nine functions and two events that are required to be called an ERC-20 token contract are defined on the Ethereum Foundation's website and a simplified example implementation is given. Here is where trust can break down, as the development and implementation of this standard happen off chain (i.e., copied from Github, then possibly modified arbitrarily before deployment) requiring each implementation to be reevaluated, even if it follows the standard exactly. While there can certainly be malicious modifications to the standard during this implementation, mistakes can also be introduced in this step as copy-pasting from GitHub does not enforce immutability. Fortunately, there is a way to leverage the security provided by the EVM to quickly deploy contracts that can inherit trust: factories.

Factories are contracts that can deploy clones of model contracts that take some custom initialization data. These daughter contracts inherit their functions from the parent contract in a way that the functionality of the contract is not altered. For example, Uniswap implements a factory model for deploying liquidity pools where the factory contract takes the addresses of the tokens to pool and deploys a new liquidity pool contract for those tokens. This means that while all liquidity pools are contracts, none of the individual pools need to be audited as long as the factory is trusted.

At Ethereans Labs, we have created a generalized infrastructure for creating modular factories and model contracts. A Factory is defined as a contract that clones and initializes a model contract, whose address is saved in the Factory contract and can be managed by the Factory’s host. The host can be any address, including a contract address, such as an on-chain Organization, multi-sig, or it can even be set to a burn address to ensure that the Factory’s model contract address is permanent.

At the top of the infrastructure is the Factory of Factories (FoF), which is a factory deployer that acts as a database of all factories deployed through it. The database contains multiple lists of factory addresses, where each list defines a host address that can add to it. When deploying a factory, the host can choose to create a new list or to append the deployed factory’s address to an existing list (of which they are the host), thereby providing an on-chain history of factory versions. The FoF also contains standardized fee functions that can be optionally integrated into a custom Factory or model contract, allowing developers to easily monetize the use of their factories while contributing to the EthereansOS Organization.

A core goal of Ethereans Labs is to enable an anonymous and open-source development ecosystem based on Factories. Going back to the ERC-20 example from earlier, if a factory was created for the ERC-20 token standard and audited, then the implementation of any ERC-20 contract deployed from that factory can be automatically trusted.

This moves trust up a level in the development process - from the individual contract implementing the standard to its model contract or factory. If there exists a finite amount of auditors’ time (including casual audits by the community), this time can be focused on a single model contract where the trust is extended to the deployed clones, rather than needing to audit each implementation.

Ethereans Labs has already deployed many factories using this infrastructure that address some of the most common smart contract use cases in DeFi, NFTs, and DAOs.

The farming factory allows anyone to deploy their own farming contract. The model contract provides functions that allow users to deposit liquidity and earn their share of the designated reward tokens. The deployer can designate the reward token and amount, which is managed by the additional cloned extension contract, designed to enforce safe handling of the farm’s funds.

A common rug pull involves first attracting liquidity (usually via a farm) and then minting a huge supply and immediately selling it into the farmers’ liquidity. Participants must trust that the deployer will not abuse their ability to mint tokens; however, with factory-produced Routines contracts it is possible to safely manage a token’s supply and more. Developers can safely grant minting permission to the Routine contract, specifying an amount to be minted periodically. Alternatively, since a Routine contract uses a cloned extension contract as its treasury, that contract can hold existing tokens rather than minting them.

More generally, a Routine can specify a list of transactions that include your choice of minting, transferring, swapping via DEX, or burning. This can be used to manage token inflation, payroll in a DAO, and more.

Ethereans Labs has developed the Item, a token superstandard that includes both ERC1155 and ERC20 capabilities. From the Item Main Interface, you can clone your own Item, specifying its metadata, supply, etc. It supports all ERC20 and ERC1155 functions and can be used anywhere these standards are accepted. Furthermore, there exists a suite of wrappers, in which you can wrap existing NFTs or other tokens as an Item, granting them interoperability across NFT and DeFi platforms as well as special wrappers that combine the supply of NFTs from a collection making them fungible, much like NFTX or MUSE.

Because on-chain governance structures are themselves composed of smart contracts, the factory-based approach is the perfect framework for implementing these behaviors. Our Organizations are completely customizable and are composed of a core contract that manages attached component contracts. Factories for standardized components such as proposal manager contracts, treasury contracts, and voting rules can be created by anyone, which creates an open ecosystem in which a competitive and evolving suite of DAO components will emerge.

The use of factories in smart contract deployment offers a solution to the trust issues that arise when relying on the deployer of a contract. By allowing deployment of standards to happen on-chain via Factories, code reuse becomes ‘free’ from an auditing standpoint, allowing security to be inherited and therefore providing a more efficient development ecosystem in the Ethereans Operating System. Additionally, the Factory of Factories offers a way to manage and track all factories deployed through it providing both a database of factories and an on-chain history of factory versions. With this infrastructure in place, smart contract deployment can become more secure and trustworthy for all users. In our next post, we will dive deeper in to the contract architecture of the Factory ecosystem.