It is no secret that Ethereum has yet to resolve the tradeoffs that come from prioritizing transaction speed and costs over security. This has persisted for years, but fortunately some solutions have been proposed to help reduce the costliness of transactions while still leveraging the security that comes from the Ethereum Network.

"Rollups" are one such solution and perhaps the most popular L2 scaling solution. What makes it "L2"? Well, L2 refers to Layer-2 insofar as it operates as a layer outside of the Ethereum (L1) layer. Think of it as like an underworld. You go through the Underworld and come ressurect back to L1 after you have executed all the tasks you'd like to execute. These "tasks" are really transactions which are, you guessed it, rolled up into the main (L1) network.

Before these transactions are rolled up, they undergo scrutiny in the form of a validation layer that uses fancy cryptography to verify their state to prove they are valid and viable for submission to the main (L1) network.

What is this "fancy cryptography"? In the world of Optimistic Rollups, they refer to a cryptographic method called a "fraud proof", which means the state that is passed on from L2 to L1 is given the BOTD and assumed to be valid, unless another party challenges it. You might be asking, why give them the benefit of the doubt? Well, mostly because this is cheaper and because there is an 

-- in other words, there is a punishment for those sneaky snakes who try to play the system. Continuing with the Underworld metaphor, the gatekeepers of the Underworld (L2) are referred to as Sequencers.

 process, bundle, and submit L2 transactions to an L1 and are required to 

 (aka lock funds) to gaurantee authenticity of their submissions, which are 

Let's breakdown the exact sequence of events for these transactions:

 The tranasction is originally initiated on a roll-up contract, which sends the transaction to an off-chain sequencer.

 As described above, the transactions locally executed and confirmed by the sequencer are bundled into a batch.

locally executed and confirmed by the sequencer are submitted to the L1 chain via a single transaction, which reduces the cost of individual transactions. 

Just like it sounds -- optimistic solutions are optimistic about the transactions they submit, though not naïve. Just like a criminal trial (in the USA) 

it takes time to ensure you are not up to no good

As such, it takes some time for the submitted transactions to actually make it onto the main chain. In the case of optimistic solutions, when a transaction is challenged, it may take upwards to 

, which means you, as a end-user have to be willing to wait for much longer than you would compared to using an L1 solution directly. 

L2 solutions have been relatively slow to reach the level of adoption of alternative L1 solutions

, such as Avalanche and Fantom, where you can benefit from the EVM technology without having to suffer from long wait times or costly transactions. Ultimately, I prefer to stick to alternatives to Ethereum, such as Avalanche and Fantom, over waiting around for L2 solutions to process my transactions. I find them just as reliable and I am not willing to wait for up to 7 days for my transactions to confirm.

Optimistic Scaling Solutions

You cannot automate smart contracts… until now.

Surprisingly, smart contracts are not as intelligent as their name may imply. They are not machine learning algorithms on the blockchain — adapting to market conditions and mutating into an automaton surpassing the genius of their creators. No. In fact, smart contracts rely on 

 to tell them what to do. No different from any other standard machine. 

However, what do I mean when I say “us”? I mean an external agent. An external agent can be me and you, but it can also be another machine that is capable of iterating and interacting with the contract in question. Just like us, this external agent is even allowed to interact with said contract free of charge by conveniently making use of functions. 

In this article, I will walk you through, step-by-step 

how you may set up an automated task that executes smart contract methods on your behalf

. The end result? Something remarkably similar to automation on the blockchain.

In order to execute automated interactions with your smart contract, install the 

After you have installed the CLI, clone my repo containing sample materials founder on GitHub 

. In order to make the magic happen, you will need to setup a (free or pro) account on the 

. After setting up your account, navigate back to your terminal and execute the 

 command. Doing so will open your browser and direct you to your Providers page. Do not run the 

 command quite yet, we will get there soon.


 in the main directory and you will arrive at a view similar to the image below. Note that the specification are up to you. So, for example, if you want to work in the Ropsten testnet, you may update the chain_id to 3, just be sure your contract also exists on the chain of your choice. We will be working in Rinkeby for this example.


This example uses the following environment variables:

: Default gas price used when making write transactions.

: 12-word mnemonic used to derive an Ethereum address, make sure it's funded with Ether if you intend to write data to Ethereum!

: The example sends messages to Slack using 

. You can get this URL from your Slack dashboard. (

Now that you have your Serverless Framework ready, you are ready to create your first app. Before you enter the 

 command in your terminal, be sure you have install the serverless-offline plugin by running the 

 command in your cloned repo. You will be prompted with a few inquiries, which are self-explanatory. Yes, you want to enable. Name demo, since it’s your first app and we are using this one to test the out-of-the-box solution. If you are new to AWS, then you will be prompted to set up AWS credential on your machine, select yes, to proceed and if you want to setup a new AWS account, select yes. Doing so will navigate you back to your browser to setup an AWS account. Create new Root user. Enable the default selection for AWS Access: Programatic Access. Continue with all the defaults, for now. Your review page should look like the screenshot below. Be sure to download the CSV in the subsequent confirmation screen and store in a safe place.

Now that you have your login credentials, you may use this information to login to your account in your terminal. You will need your AWS Access Key ID and Secret Access Key. While your Access Key ID may be found on your online account in your browser, your secret key is stored in the CSV you downloaded when prompted to do so. After logging in, you may choose yes for the remaining prompts, until you are prompted that you command line completion was successfully setup. If you’ve made it this far, congrats! You are now able to serverless deploy your project, monitor, troubleshoot, and test it.

Before you proceed with testing locally, you will need to update your mnemonic, by creating your copy of the .env.example file. Duplicate and create a new file with the name .env to ensure your information is not shared, ensure you include .env in your .gitignore file. This is where you may securely store your environment variables. Once you have entered your MNEMONIC and FROM_ADDRESS values in your.env file, you are ready to test locally, just be sure your FROM_ADDRESS has sufficient ETH on the selected chain.

Congrats, you are now ready to test and deploy! In order to test locally, execute the following command in your terminal:

serverless invoke local —-function exec

. For further assistance, navigate to the 

Smart Contract Automation

When deciding between when to make use of 

, one must consider two key factors in their deliberation: (1) gas efficiency and (2) bytecode analysis. The functions 

 may be used to check specified conditions are met and consequently throw an exception in the event the condition is not met.

 that cannot be detected until execution time.

You may optionally provide a message for require, but not for assert.

: dividing by zero, converting a oversized value, allocating too much memory, or accessing a storage byte array that is incorrectly encoded.

: message sender must be the owner, the balance of a user must be at least the deposited amount, or the allowance must be at least the amount being sent.

because the assert function creates an error type Panic(uint256).

When used as intended, analysis tools may identify conditions wherein which function calls result in a failing assert, which should never be the case in properly-functioning code — if this happens there exists a bug.

: such as require a user inputs a value above or below a specified amount or only for a certain asset.

: prior to executing state changing operations, for example in an owned contract.

Require() is more commonly used than Assert(). In fact, I hardly ever use assert and when I do it is for good reason. Another thing to note is conventionally, require statements are used towards the beginning of a function.

: cases where the anticipated change does not occur.

 ensuring anticipated state post-changes.

Unlike with Require(), you may expect to see Assert() towards the 

 In essence, assert is primarily there as a means to prevent anything r

Assert vs. Require

, when the protocol governing the decentralized exchange 

. Faced with a decentralized governance dilemma, they ultimately decided to provide these tokens to those interested in participating in future proposals affecting the Protocol. Once the decision to move towards a truly decentralized protocol was made, Uniswap was confronted with another dilemma, but this time in regards to distribution.

How do you distribute a large number of tokens to a select group of people while minimizing spamming disinterested or abandoned accounts in a cost-effective manner?

Uniswap answers the question above with a Merkle Distributor, but I decided to take things one step further. Read more to see what I did and how I did it, so you may integrate such a tool for your community. In this article, I discuss how to replicated this process and introduced a number of elements unseen in any other Merkle Airdrop smart contract to date.

Governance is perhaps the single most important topic in the crypto industry. The reason for this is in order for decentralization to exist in a sustainable manner, there must also exist a set of rules to which all participants must agree, otherwise there truly is nothing to enter into when participants consent to being members of a protocol.

This is the reason why so many tokens can exist without a clear purpose — because purpose has, as of late, come secondary to profits. Those tokens with a 

 tend to succeed simply because inherent in that purpose is the utility of the token.

What do you get from being a participant in Bitcoin?

Being the potential for “gains”, you gain access to a 

. Each member in this economy has a role and, as such, ought to have a clear understanding of their role and thus their impact on the sustainability of the project (token) in question.

In this case, the purpose of designing an airdrop was two-fold: one to “unrug” the CBDAO Community and two, to encourage participation in an ecosystem without stakeholders having to provide a direct, upfront, monetary investment. The second component is made possible by a set of configurations I integrated into the MerkleDistributor.sol smart contract, which we will discuss in-depth when reviewing the components of the smart contract itself.

These components are designed to account for (and solve) the misfortune we witnessed with the UNI airdrop wherein which users were rushing to collect on their gains instead of considering the benefit of being an active participant in the ecosystem.

As is the case with developing smart contracts of any kind, my recommendation is to truly understand the purpose of your design and thus the elements you need to make the design come to life. In the case of the airdrop, we had a few goals in mind, but we were unsure about implementation and wanted to construct a cohesive strategy to the benefit of the community, for other projects to replicate.

We needed a means to prevent harm to the community, first and foremost, as it is often the case that airdrop recipients are incentivized to be amongst the first to sell because they were awarded money today at a value that is not guaranteed tomorrow. This is especially true in the case of a new project.

We had to design a solution to mitigate or eliminate the following:

: we had to design a mechanism that would prevent a massive “dump” on Airdrop Day, as is typically the case.

: due to the nature of the airdrop distribution as one with an increasing available amount each day, one could theoretically claim on another’s behalf so as to cut that person off from being able to claim their entire airdrop and have to settle for just a portion.

: a mechanism that would disallow one bad actor from accessing all of the $2.3M in assets in a hack for themselves.

 those who were rug pulled were provided with an airdrop and that the list cannot change.

As with any cogent strategy, a two-pronged approach is vital to ensuring one accounts not just for reasons not to do something but, on the flip side, reasons 

 do something — aka incentives. We needed to inspire airdrop recipients to not claim (and subsequently dump) what is rightfully theirs. However, we realize penalties without rewards is a bit harsh, especially when doing so to the purported benefit of an entire community that experienced a rug pull event. As such, we hypothesized a number of ways to incentivize not only forestalling one’s tendencies to “dump”, but to encourage users to actually add value to the ecosystems without having the ordinary sense of “skin in the game” via money shelled out to the ecosystem upfront.

We implemented a number of incentives, including:

: a reason to wait the full duration of the airdrop in order to secure a more smooth allocation of the reward.

we needed participants to believe us when we said the money will be theirs and cannot be scooped up by just anyone, so we identified a trustless manner of verifying claims and that enables anyone to verify that, in fact, only those listed are eligible to receive their share and that each user’s share is limited to only what they are due.

Granted, much more was taken into consideration, but these are a few examples of things that were relevant to us in our design and ones for which we were able to take into account when creating our final Airdrop smart contract.

At first glance, the MerkleDistributor.sol smart contract seemed like a fit solution for us and we considered forking it and calling it a day, but I could not get passed the very-likely scenario that recipients of the airdrop would behave in a self-interested manner. Being an economist at heart (and by degree), I knew there had to be safeguards in place to prevent the former CBDAO Community from being rug pulled (for a second time), but this time rug-pulling themselves.

In order to do so, we had to find a way to organically introduce 1.2M+ tokens into the ecosystem, which requires claiming tokens in a manner that smooths distribution. As we all know, Econ101 supply and demand, introducing new supply with demand held constant means “price go down”, so I designed a way to smooth distribution of supply (sell pressure) so as to better align with demand (buy pressure). Doing so would, ideally, enable us to protect the current price, but we needed to also ensure this was at the will of the user and not simply a forced distribution method, which comes with a bad taste in the mouths of those who were promised access to an airdrop in just a matter of a month from our liquidity generation event.

We ultimately decided to modify our original proposal and enable users to make a choice that made the most sense for them.

Are you willing to claim less of your tokens today or wait for later down the line to claim more of your tokens?

While a simple question, a much deeper psychological component is at play here that some may have missed. Users are being provided what they already consider to be “free money”, so if they are highly disinterested in the project’s success and do not believe in its potential, they may 

leave and take with them a much smaller piece of the pie on their way out

. Alternatively, if they believe in the project and are interested in participating in its outcome, then they will stick around. Not only are users incentivized to stick around, but they are also 

incentivized to add value to the community

 via contributing to the stack that will inevitably be theirs.

In this way, by allowing members to claim a larger share of what they are due by sticking it out for longer, we manage to organically “unrug” a community while, at the same time, incentivizing the community to make use of the first 90 days of inception to really get their act together and do their absolute best to add value to what very-well may be their last chance to make right all (or more) of they have been wronged. 

An Unruggable Airdrop

 make extensive use of one way hashing and are established by 

 a hash’s corresponding hash together and climbing up the tree until you obtain the root hash which is or can be publicly known.

: Demonstrating that a leaf node is a part of a given binary hash tree requires computing a number of hashes proportional to the log of the number of leaf nodes in the tree.

Merkle Tree: Example of Hashing Transactions

 represents a higher order of hashing stemming from a 

. For each block-level above the original transaction, the subsequent 

, is passed through a hash function until reaching the highest block-level represented as the combination of all the 

The lowest-level hash values are referred to as leaves — containing the 

 associated with the leaf. The resultant hashing of leaves and their subsequent hashes, levels 3 and 4, are referred to as 

, stores the summary of all of the transaction data as a singular value.

Merkle (Hash) Trees: Explained

Modern cryptography has evolved with the convenient use of 

), which is a mathematical algorithm that maps data of 

 (a “hash”). The hash function is practically infeasible to invert as it is a one-way function. The only ways to intercept the message would be via 

, which iterates through possible inputs until it produces a match, or making use of a 

The ideal cryptographic hash function has the following properties:

: the same message always results in the same hash.

: designed to swiftly compute the hash value for any given message.

: it is infeasible to generate a message that yields a given hash value, aka to 

 the process that generated the given hash value.

: it is infeasible to find two different messages with the same hash value.

: a small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value (

 exhibits good avalanche effect (shown above). When a single bit is changed the hash sum becomes completely different.

Cryptographic hash functions have many information-security applications, notably in 

 (MACs), and other forms of authentication. They may also be used as ordinary 

, to index data in hash tables, for fingerprinting, to detect duplicate data or uniquely identify files, and as 

: In information-security contexts, cryptographic hash values are occasionally referred to as (

, even though all these terms stand for more general functions with rather different properties and purposes.

Cryptographic Hash Function: Explained

 variables and functions that always exist in the namespace and are mainly used to provide information about the blockchain or are general-use utility functions. One example of such a global variable is the 

 variable, which enables you to acquire useful information regarding the properties of the 

of time — for example, an ERC20 time lock smart contract. When you are interested in time, you may be want to know the 

, which represents the current block timestamp represented in (uint) unix epoch time, which is calculated in seconds. Another potentially useful variable is 

, which represents the current block number.

More concretely, in the event that you are interested in locking tokens, you may consider using 

 to specify a require condition wherein which the 

 is ≥ lock expiration time (represented in 

Solidity makes things even more convenient by providing time units, such as 

, which are particularly useful when you are interested in computing longer time spans, so you may consider working these convenient tools to help you save… 

Time contract that does nothing beyond remembering when it was created, voila!

Each block in the blockchain includes a timestamp specified as the number of seconds since the Unix epoch. Time values are integers (uint).

Solidity smart contracts can access the timestamp of the current block as 

Solidity provides convenient time units like 

, which are helpful in computing time spans.

Time (in) Smart Contract(s)

Liquidity mining is one of the hottest topics in decentralized finance. Liquidity generally refers to the assets in an ecosystem. In the case of governance protocols, liquidity also represents your piece of the governance pie, so to speak. In this tutorial, I will review how I constructed a liquidity mine for a cryptocurrency project and how you may replicate. I managed to narrow it down to 

The benefit of providing a liquidity mine is this foregoes the need for an ICO, where tokens are purchased directly from the project, which is subject to regulatory intervention. Ultimately, there should be a reason why you are utilizing this method to distribute tokens and you should consider the following before you jump into coding the smart contract itself. Some considerations you may have are as follows:

: consider whether you will be minting tokens or whether there will be another functionality you utilize to distribute tokens.

: at what rate will your token be introduced into the ecosystem and for how long?

: while this is not apparent in the contract itself, you should ask yourself what is the purpose of the token you are creating?

In order to build a liquidity mine you need to first determine whether your mine will be 

 tokens as a reward to miners. In the case of the DAO, we wanted to ensure we eliminate the possibility of minting additional tokens, thus I had to come up with a way to transfer tokens from the contract itself to the users of the dApp. Ordinarily, as is the case with Sushi, for example, one would mint the tokens as this is how the tokens are made available to the ecosystem. Given the historical roots of the project I created this mine for (as the response to an unfortunate rug pull by CBDAO), we wanted to remove all doubt entirely, which is why we decidedly eliminated the mint function from the ERC20 contract. Let’s get into the steps I followed to implement the smart contract that will lay the foundation for the Treasury Fund, launching December 22nd, 2020.

 returns key aspects of the smart contract, for example, we use the 

 function to transfer (address sender, address recipient, uint256 amount). 

 functions wrap amount ERC20 native functions that throw on failure (i.e. when the return is false). Your contract may inherent this functionality by simply including the line: “using SafeERC20 for IERC20”. 

 enables you to store unique values, which is a handy tool in solidity, as you will see later in this article. 

 enables Solidity to throw an error in the case of overflow, eliminating an entire class of bugs. 

 is a contract module which provides a basic access control mechanism where the owner may be granted access to a suite of functions inaccessible by others via the modifier ‘onlyOwner’.

You are welcome to declare however many variables are relevant for your project. In the case of the DAO, we are utilizing the Liquidity Mine as both a means to distribute the DAO governance tokens, but also as the launchpad for the the DAO Treasury fund. As such, we include uint256 taxRate to represent the rate at which the pool is taxed. Please note that due to the nature of Solidity, I had to get creative with this number, so it is not as simple as tax rate = 0.02, as Solidity does not cooperate with decimals. As such, the taxRate = 50 and we simply divide the value being deposited by 50 to acquire 2%. This is true for any integer n.

Since every liquidity mining operation is unique, I left out a few lines as they consist of declaring a myriad of variables that may or may not be relevant to your project.

Time to get to the functionality of the contract, which is stored in, you guessed it — your functions. Let’s explore a few options for you to consider using the sample code snippet from the the DAO Liquidity Mining Smart Contract: GovTreasurer.sol. 

 declares a function and names it “deposit”, which stores two input variables: Pool ID and Amount. The Pool ID corresponds to the pool selected by the user whereas the Amount corresponds to the amount of tokens the user is elected to deposit. Do not be fooled, this contract is unlike your typical deposit function as it is designed to acquire a tax of 2% on deposit, as discussed before. As such, there is a new variable declared on 

, which corresponds to the amount that is taxed, such that taxedAmount = 2% of deposit amount. This new variable is used 4 times in the function, as a deduction from the amount deposited to the smart contract (line 189), as the amount sent to the DAO treasury (

), as an update to the amount the user is owed back upon withdraw (

), and as a deduction from the amount that is emitted from the Deposit event (

). Altogether, this function enables the desired effect. Get creative and design a function of your own.