Using EIP -1167 to solve Web3 Reward mechanisms

Learn how resident degens @Intract powered growth campaigns for Web3 projects by making contract deployment easier and cheaper

In a new blog series, the Intract tech team shares their degen experiments & insights - what makes the Intract Growth platform the best choice for projects looking to scale and scale fast.

In the first blog, we will cover EIP1167. A minimal proxy contract a standardized, gas-efficient way to deploy contracts.

We shall also cover how deploying EIP-1167 helped us sort one of the most clinical aspects of Growth Marketing campaigns in Web3.

Read on -

What is EIP-1167?

EIP-1167 also called the Minimal Proxy Contract, is a popular Solidity pattern that allows the creation of cheap proxy clones of contracts. This is particularly useful when needing to deploy identical or similar contracts multiple times, as it saves on gas costs. Gnosis Safe utilizes this pattern by creating a clone when deploying a new safe.

A clone contract acts like a proxy and delegates all calls to the implementation contract, but stores its own state. Unlike a regular proxy, multiple clones can point to the same implementation contract and cannot be upgraded. The implementation contract address is stored in the bytecode, which saves on gas and prevents clones from pointing to another implementation.

The minimal proxy contract is made up of a concise bytecode of only 55 bytes, including the init code, runtime code, implementation contract address, delegate call instructions, and error handling. The init code is responsible for deploying the contract and saving the runtime bytecode on-chain. After deployment, the clone copies the transaction call data to memory, pushes the implementation contract address, and performs a delegate call to the implementation contract. The result of the call is then returned or the call is reverted if an error occurs.

This pattern is considerably cheaper to deploy than the full implementation contract, as the bytecode of a clone proxy is much smaller. However, calls during execution may cost more due to the added delegate call. The article also discusses the opcodes used in the EVM for the init code and call data copying, as well as how the delegate call works.

Existing examples

UNISWAP
One of the most commonly used implementations of EIP 1167 is seen in Uniswap V1’s automated market maker (AMM) pools. These pools are managed by a single contract that distributes two assets. However, the real power of the system comes into play when a new pool is added. In this case, Uniswap V1 uses a Minimal Proxy to create a new instance of the underlying AMM contract. This process can be observed on the blockchain by examining the code of an AMM pool address.

GNOSIS
Using the clone pattern is a more gas-efficient approach when there is a need to deploy an identical or similar contract multiple times. One practical application of this is demonstrated by Gnosis Safe, which creates a new safe using the clone pattern. Essentially, when you interact with Gnosis Safe, you are actually interacting with a clone instance of it.

Where did Intract’s resident degen implement this?

We have implemented EIP-1167 in two areas of development:

• Deploying factory contracts for NFT creation

While building a web3 quest platform, we realized that it would be beneficial if the project could reward their quest users in the form of an NFT, such as a PoAP or memorabilia. All they need to do is fill in the supply, name, and URL for the NFT image.

• Deploying factory contracts for Airdrops creation

After a project deploys its NFT smart contract from our platform, the next obvious step is to airdrop or make it claimable for quest users. To do this, a separate airdrop contract is needed that can distribute the NFT rewards.

What does this development mean for the end customer @Intract?

It’s worth noting that both of these contracts require the same contracts repeatedly for all projects. Only a few initialization variables change each time for different customers.

Here, we can take advantage of EIP-1167, where we can deploy all the technical logic only once on the blockchain, and for the next set of instances created, we can refer to the same logic contract already hosted on the chain.

This deployment significantly reduces the deployment costs for all customers using our service - reducing the timeline for creating & launching a quest as well as making it cheaper for the admin to reduce the gas fee.

We hope you find this implementation useful and encourage you to deploy your next set of contracts using EIP-1167 💪💪

---

If you found this interesting, subscribe to the Intract newsletter. The next blog in the series will cover details of how to upgrade a contract to EIP1167 compatible.

For Degen experiments and Web3 Growth Marketing insights, stay tuned to Intract or follow us on the bird app @intractbuzz