Onchain Tutorial (2/2): Deploy Your Airdrop Contract
Overview
This tutorial aims at describing the process behind the deployment of Sismo Connect contracts. In this context, we will recap on what a Sismo Connect Client config is and how to impersonate accounts. Once understood, these notions will allow you to confidently deploy contracts with Sismo Connect's functionalities.
To better understand the different notions highlighted in this tutorial, we strongly advise you to go through the first tutorial, which will show you how to leverage data aggregation in your app by building a Gated Airdrop for Gitcoin Passport holders.
For this tutorial, we will again use the GitHub repository used for the gated airdrop tutorial. You can clone it and install it as described in the repository's README or in the tutorial. You don't need to clone it again if you just finished the tutorial.
Prerequisites
This tutorial requires:
Node.js >= 18.15.0 (Latest LTS version)
MetaMask installed in your browser
We use Foundry for our smart contract dependencies, but we also have a Hardhat library. This tutorial is focused on how to deploy your smart contracts using Foundry.
Installation
This tutorial is based on the following tutorial repository. You can clone it with the following command:
Install contract dependencies
Once these steps are done, you are well set up to use Forge, a tool provided by Foundry to test and deploy smart contracts.
Understand the Sismo Connect config
Before deploying any Sismo Connect contract, it is better to understand the Sismo Connect config and especially how to impersonate accounts.
As you may already know, Sismo Connect is the communication layer allowing any Sismo Connect app to request ZK proofs about user data and receive the expected proofs before verifying them. To be able to produce such proofs, users are required to import accounts (i.e. Data Sources) into their Data Vaults. By doing so, they will be able to prove group membership and account ownership to apps.
Such proof generation is possible (among other things) thanks to the Commitment Mapper. Therefore, we allow any developer to impersonate accounts by automatically creating a fake Commitment Mapper in the Vault app front end if the Vault object with the impersonate field is defined in the Sismo Connect configuration.
You can learn more about the Sismo Connect configuration here.
The deployment script
Solidity scripting is a way to declaratively deploy contracts using Solidity instead of using the more limiting and less user friendly forge create
. You can look at the example displayed in the Foundry documentation if you want to learn more about it.
We are going to use a simple Solidity script to deploy our contract on our chosen network.
You can see the script used in script/Airdrop.s.sol
file. Here is it:
This script is simple; it declares a new airdrop contract between vm.startBroadcast
and vm.stopBroadcast,
two foundry cheatcodes that will simulate the contract creation in the context you will provide.
You can simply run this command to see the simulation of your contract deployment in the context of a Mumbai fork.
As you can see in the output logs, the simulation of the airdrop contract deployment was successful. You can even see the amount that will be required for you to deploy on the Mumbai Testnet. (You can use this Alchemy faucet if you need some testnet tokens: https://mumbaifaucet.com/)
Since we are happy with the script simulation, we can broadcast it on Mumbai by inputting an EOA private key in the command line.
We strongly advise you to use a private key from a developer account when developing, do not leak any private key linked to some accounts with real assets in it.
Here is how to deploy the airdrop smart contract on the Mumbai testnet network. We use a publicly known private key to show you how to do it.
If you try to run this exact command without changing the private key, you will encounter an error since the account has no funds. You should replace the private key by your own developer private key and have some funds on your dev account (Mumbai faucet link: https://mumbaifaucet.com/).
Notice the --broadcast
option, which states that you want to actually trigger the transaction on the Mumbai testnet.
Verify your contracts with --verify
option
--verify
optionTo verify your contracts, you will need to register for an Etherscan API key.
The Etherscan API Key needs to be registered from PolygonScan if you want to deploy on Mumbai: https://polygonscan.com/myaccount
You just need to directly specify the --verify
option when deploying alongside your Etherscan API key.
In clear terms:
If you deploy the exact contract from the tutorial on Mumbai, you are likely to encounter a message reading "Already verified". As long as your contract is verified, it is totally fine!
And congrats on your deployment! You should be left with a verified contract at this point. If not, don't hesitate to reach out to us on our developer Telegram.
If you want to use the tutorial front end with your contracts, you will need to add some minor changes to the front/src/app/page.tsx
file. You will first need to change how you get the contractAddress
by changing 5151111 (the fork chain id) to 80001 (the Mumbai chain id) in your imports. You also have to use the polygonMumbai
chain config from viem instead of mumbaiFork
config for the chain.
Next steps
If you have any questions about integrating Sismo Connect, don’t hesitate to reach out. The team will be happy to answer any questions you may have. Any feedback is also welcomed!
Get involved in the Sismo community! 🎭
Look out for hackathons that we are participating in
Join our Discord or our Dev Telegram
See the Sismo-hub contributing page
Last updated