Skip the empty chatter with Tech Talks, an ongoing crypto series that covers specific technical challenges and how we’ve solved them. Tech Talks is written for (and by) galaxy brains who love digging into the details.
We’d like to shine a spotlight on Shipyard’s development team for coming up with an elegant solution to an issue we encountered following Clipper’s first community liquidity program (CLP). Our developers created a custom smart contract that streamlined operations and significantly reduced transaction costs. See the details below.
During Clipper’s inaugural CLP, some participants racked up significant gas fees when they tried to provide liquidity for pools that were already full. This was due to a bug in the CLP’s front-end interface, and the Shipyard team immediately set out to compensate the 70+ wallets who lost ETH as a result of this bug.
To avoid the costly process (in gas) of sending 70+ individual transactions through the Ethereum mainnet, we came up with a better solution. A custom smart contract designed to safely distribute all 70+ reimbursements to Clipper’s affected community members simultaneously via a single on-chain transaction. This smart contract deployment significantly reduced gas expenditures while creating a single on-chain transaction record for the entire reimbursement process.
- Forking Clipper’s mainnet through Hardhat to create a smart contract test environment. The first step was simulating Ethereum’s mainnet using Hardhat, a development environment used to test, debug, and deploy Ethereum-based dApps. This was done using the tools in Hardhat’s configuration file, which allowed us to fork the network and create an ethereum archive node testing environment using the Alchemy API.
- Creating a Python macro to compose address-specific Solidity code. We collected each failed transaction that occurred during the CLP as a .csv file. We used the csv Python library to parse the data from this address list and output a safeEthSend string with the appropriate recipient address and reimbursement amount into the constructor of the Solidity contract. These operations were explicitly written out instead of having a loop. In other words, our Python macro wrote new smart contract code out for each address instead of having a command repeat with different addresses. This was a necessary workaround due to Solidity’s coding constraints regarding external data.
- Testing the smart contract and distributing ETH reimbursements. To simulate the functionality of the smart contract, we then used the ethers.js library to run a test deployment of our custom smart contract in the forked Ethereum mainnet on Hardhat. Specifically, we used Hardhat to create an account on the forked mainnet with enough test ETH to trial run our custom reimbursement distribution solution.
We’ll continue to shine a spotlight on future challenges and our creative attempts to solve them.