Centre’s USDC has become the second largest stablecoin in DeFi. While it has maintained its 1:1 peg with the US dollar well, its “blacklist” functionality comes with a heavy tax on users, amounting to, by my estimate, an extra $3.6M spent in transaction fees in December 2021 alone.

I propose a new version of USDC that preserves what I argue is the most salient feature of the blacklist--the ability to freeze funds--in a way that eliminates blacklist-related gas costs for users, which can be found in a pull request to the Centre token repo.

USD Coin (USDC)

Deployed in august of 2018, USDC has grown to be the second largest stablecoin by market cap (next to USDT) with 44.6 billion in circulation at the time of writing. In the beginning it existed natively on Ethereum mainnet only, but has since expanded to 6 other blockchains.

USDC is managed by an organization called Centre whose founding members are Coinbase and Circle, two providers of fiat-to-cryptocurrency conversion services.

USDC has become one of the most favored stablecoins in DeFi and it’s no wonder--it has maintained its peg well and it is easily convertible 1 for 1 to dollars via Coinbase and Circle.

One area in which USDC performs poorly, however, is the cost to use it. It costs approximately 40% more in network fees to transfer USDC compared to DAI, a decentralized stablecoin maintained by MakerDAO.

Why is that? How could USDC, which implements the same ERC20 standard as DAI, cost so much more to use?

A partial explanation is that USDC is a proxy contract. This means that there is a separation between the logic of how USDC operates and the address that people interact with. This allows USDC to be upgradeable--Centre can change the logic of the contract without requiring a migration of USDC balances. However, it also requires extra steps to look up the contract where the logic is and then call it, which requires extra gas.

Another reason is that USDC costs more to use is that it has additional checks to make sure the addresses aren’t on the the blacklist. USDC allows an admin to bar specified addresses from interacting with USDC.

When the transfer function on USDC is called, the contract checks that both the sender and receiver aren’t on this naughty list. According to the Centre whitepaper, this blacklist is meant to protect users as well as maintain regulatory compliance.

Unfortunately for users, however, checking the blacklist comes at a cost. Each check of the blacklist costs ~2100 gas or around $0.63 a pop (see the appendix for why this is). To transfer, this list is checked twice, adding ~$1.26 to the transaction.

Calling transferFrom (the call used when interacting with other contracts like Uniswap) requires 3 checks of the blacklist, for a total cost of up to ~6300 gas, or ~$1.89.

These costs add up. I estimate that in December 2021 alone, these blacklist checks added about $3.6M in gas fees for USDC users.

Slimming Down Blacklist Functionality

I would argue the ability to freeze funds is the only aspect of the blacklist that is worth saving. I discuss this in the context of the two stated aims of the blacklist according to Centre: regulatory compliance and protecting users.

Regulatory Compliance/Stopping the Bad Guys

When an address is added to the USDC blacklist, they can no longer interact with USDC directly--it can’t receive funds nor can it move funds.

If the address has an existing balance, the entity behind that address now can’t access it--that’s a real cost. However, in terms of preventing future interaction with the USDC contract, the blacklist isn’t all that binding.

Say you’re the owner of an address that gets blacklisted. If you want to continue to use USDC, you have a two options:

1. You could derive a new Ethereum address in your wallet (for free) and continue using USDC.

2. You could create a proxy contract wallet from your address, for instance a Gnosis Safe contract, and interact with USDC via that contract. The USDC blacklist contains your normal address, not the contract.

You would probably opt for 1, as it is easy and bears less risk for additional blacklisting, but the point is the blacklist is not a useful tool for stopping the entity behind an address from interacting with USDC. It’s a measure that is more theater than substance.

The logic is similar for contracts. You could blacklist a particular project’s contract, but contracts can be re-deployed.

The risk that bad actors are most likely concerned about is having their USDC frozen. If you lock their balance, that’s a real economic hit for which they have no recourse. If an actor with a frozen balance for some reason continues to use USDC and acquires a fresh balance, Centre could freeze the additional funds. This could even be done in an automated way.

Simply freezing balances doesn’t require an approach as heavy-handed as the blacklist, however, which I’ll discuss later in this post.

Protecting Users

The blacklist does effectively protect users from addresses that are determined to steal users’ funds--for example, scam accounts.

However, doing this at the smart contract level is the most expensive place to do this (i.e. $3.6M per month expensive). Building warnings into wallets is a much cheaper place to help protect users from errant behavior or interacting with scam accounts, and they’re even more effective in that they can help prevent the user from spending gas on a failed transaction.

Freezing funds also still leaves recourse for users--in theory you can freeze USDC at a scam address, thereby taking that USDC out of circulation, and Centre wanted to do so, they could mint USDC for the affected users to replace that removed USDC.

freezeBalance

In the previous section I argue that freezing funds is the sole aspect of the blacklist worth saving (or at least worth spending transaction fees on).

In my proposed USDC v3, I remove the blacklist checks from all transfer and approval functions. This would save the gas spent on these checks (the $3.6M in cost).

In its place, I introduce a new function called freezeBalance. This function allows an admin (in this case, an address that is already given the role of blacklister) to freeze an account’s funds.

Under the hood, this sets the target account’s balance to zero, removes that amount from the total supply, and updates a separate account mapping (frozenBalances) to reflect the funds that are frozen. frozenBalances makes accounting for these actions easier as well as allows the admin to unfreeze balances (calling unfreezeBalance) if the initial freeze is later deemed to have been done in error.

Concluding thoughts

My ultimate hope is that my proposed version of USDC gets adopted to save users money as well as make a (very) modest dent in Ethereum’s congestion problem by reducing USDC’s footprint in Ethereum blocks.

This code for can be in a pull request to Centre’s tokens repo.

In the high gas environment that we’ve experienced on Ethereum mainnet the past two years, it’s crucial for projects behind heavily-used contracts to scrutinize gas usage very carefully.

Appendix

Acknowledgements :)

Thanks to Noah Zinsmeister, Kelsey Dean, and Daniel Pyrathon for reviewing this post.

Blacklist Gas Costs

The most significant (though not the only) gas costs associated with checking the blacklist is the fact that it needs to read from storage (specifically looking up an address in a mapping of address to a boolean value of whether that address is blacklisted).

The cost of every action one can take in the EVM is specified in the Ethereum yellow paper. This document is updated as hard forks modify the behavior of the EVM. The relevant costs for storage access were last updated in the April 2021 Berlin hardfork due to the inclusion of EIP 2929.

The cost for a “cold sload” (“cold” meaning the storage slot has not yet been accessed in the transaction) is 2100 gas. Once a storage slot has been accessed, the cost for any subsequent access within that transaction is 100 gas.

As discussed previously, the USDC blacklist is checked twice for each transfer--once for the sender and once for the receiver--and three times for each transferFromonce for the receiver--once for the address calling transferFrom (typically a contract), once for the sender, and once for the receiver.

In theory some of these addresses within a transfer/transferFrom could be duplicates, in which case the additional read would cost only 100 gas. In practice, however, these addresses (sender, receiver, caller) will often all be different addresses, so each read will cost 2100 gas.

To put this into context, 2100 gas at $3K ETH and 100 gwei gas price costs $0.63. This may sound low, but add multiple checks per transaction and millions of transactions, the costs add up.

Blacklist Checks for Approve

In addition to transfer and transferFrom, there are two checks of the blacklist for approve. Theapprove allows a separate address (say the Uniswap router or a Compound cToken contract) to spend your balance (subject to the logic of the contract, of course).

USDC checks that the address granting the approval (msg.sender) and the address that is being granted the approval (spender) are not on the blacklist.

While in this post I argue that the most important functionality of the blacklist can be preserved while getting rid of the blacklist checks on transfer and transferFrom, the blacklist checks on approve are particularly superfluous, since even if approval is granted from or to a blacklisted address, the checks on transfer and transferFrom prevent any movement of funds.

These blacklist checks for approve impose a cost on all users calling this function and should be removed. Blacklist checks for approve alone cost users $346K in December 2021, though I note that December had a higher number of approvals than normal due to token mining with a Gearbox Protocol contract on December 16 (see Dune query). Excluding these the Gearbox approvals, the approve blacklist checks cost users ~$209K.

Source for Data Analysis

I used Dune Analytics for data analysis mentioned in this post.

You can find the source for the cost of DAI/USDC transfers in the following queries:

• DAI

• USDC

For the numbers mentioned in the post, I calculated the median gas cost of a simple transfer transaction from the last week of 2021.

I calculated the USD value of the excess ETH spent on blacklist lookups in December 2021 relative to my proposed implementation in the following query.

To make the calculations tractable without timing out, I calculated the excess ETH for approve, transfer, and transferFrom in separate queries and stored the results in tables. The queries for these tables can be found linked in the query above.

I calculate the gas spent on SLOAD related to the blacklist, taking into account the lower cost of warm access if an address is repeated.

Additional Implementation Details

When deploying v3, addresses on the blacklist with frozen balances would be able to move this balance if they aren’t frozen via freezeBalance, so it’s imperative that the deployment transaction includes this step.

I left blacklist checks on the mint functions, since they are not very frequent called and those functions only affect Centre’s costs, not the costs of USDC users.

Lots of folks may want the firework show, but there’s not enough economic incentive to go through the effort and cost of arranging it if you only reap the private benefit (the enjoyment of getting to watch the fireworks yourself) and don’t reap some of the public benefit (everyone else’s enjoyment of the fireworks).

DAO Governance free riders

In DAOs, all token holders benefit from good governance whether they participate in it (create proposals, vote on proposals) or not.

Ultimately, this doesn’t matter much as long as good governance takes place, but I am not one to rely on the goodwill of some to do work for an entire group--anyone who has suffered through a group project in school can attest that this does not always lead to desirable outcomes.

Furthermore, the current state of affairs can have a centralizing effect--you’re incentivized to participate if your private benefit is a significant chunk of the group benefit, i.e. in the case of DAOs, you own a large percentage of the tokens.

Incentivizing governance participation

What if we privatize some of the benefits of governance participation?

I say we pay people to participate in governance. Those who participate should be rewarded with a greater stake in the protocol. From another perspective, we should be punishing those that don’t participate in governance with dilution of their stake in the protocol.

There are two primary activities in on-chain governance--creating proposals and voting on proposals.

Creating proposals is hard work, and should be rewarded through bounties, one-off grants, streaming contributor grants, and one-off payments baked into proposals. Proposals are not created equally in terms of their difficulty and impact (a parameter update is much simpler and typically less impactful than rewriting a contract).

While I think it’s important to incentivize the creation of good proposals, I don’t think there should be a one size fits all solution.

Voting, on the other hand, merits a more formalized approach. Among all the DAOs I’ve seen, voting is not explicitly incentivized, and so non-voters free-ride on the diligence of voters. I think voting should come with an explicit reward of more governance tokens in proportion to one’s voting balance.

I discuss some potential incentive misalignments with voting rewards and how to address them below.

Casting uninformed votes

One way to game voting incentives would be to simply vote (either always “yes,” always “no,” or randomly) on every proposal to earn rewards regardless of the proposal. This isn’t even hypothetical at this point as, @transmissions11 implemented a lovely contract that only allows you to vote no on every proposal.

https://twitter.com/transmissions11/status/1465907960765321220

My solution here is to provide substantially higher rewards for votes that end up winning. This encourages token holders to vote the best option and incentives folks to try to persuade others to their viewpoint as well.

Voting with the majority near the end of the voting period

Another type of free rider voter could simply wait until the voting period is near complete and vote at the end once the outcome seems assured.

My solution here is to have a reward decay schedule. The voting reward should be highest at the beginning of the vote period and decay to zero at the end. This encourages token holders to stay on top of upcoming votes and diligence the proposal before the voting period begins.

Spamming nonsense proposals

Another potential way to game voting rewards is to create useless proposals and vote on them.

However, many DeFi protocols, including Uniswap and Compound, have some degree of spam prevention built in--the proposer must meet a minimum threshold of delegated voting power. Although incomplete, one solution to this problem is to exclude the proposer (and thus their delegated voting power) from voting rewards.

If it becomes an issue, the vote threshold can be raised to discourage this type of behavior.

A Renaissance in Delegation

Direct voting is not for everyone. In my opinion, it’s difficult to be informed enough about more than 2 or 3 protocols to be an active participant, and that’s assuming that you have the ability to dedicate a significant amount of time to DeFi governance (and I’ve been told that most people, unlike me, have a life outside of crypto).

For many DAO token holders, delegation to an active community member makes the most sense. The beauty of voting incentives is that it makes being a delegate not just a labor of love, but a potential occupation.

By default voting rewards would accrue to the address that voted, i.e. delegates would get rewarded not only for their own voting power but the voting power of everyone who delegated to them.

While this is great for the delegate, it doesn’t leave much incentive to delegate your tokens. It's easy to imagine delegation contracts that allow delegates to return a percentage of rewards back to the delegators. Delegates would compete along two dimensions:

1. how good of a delegate they are (high vote participation, good reputation, sound judgment, etc.)

2. what percent of rewards they return to delegators

Concluding thoughts

DAOs (and web3 in general) offer a rich design space to create incentive schemes that allow us to build better applications. The current DAO voting model, however, is uninspired from an incentive perspective.

Voting rewards can better incentivize good governance and create a competitive market for delegation.

While it’s an interesting idea, as I reflected on that post recently, I was thinking about how Uniswap already is an oracle protocol. It already provides a price feed from the largest DEX on Ethereum. UNI already is an oracle token, the UNI DAO just hasn’t done much with that fact, as of yet at least.

A history of Uniswap as an oracle

Ever since v1, Uniswap has been an oracle protocol, albeit a very crude one at the time. Uniswap v1 was a series of ETH-ERC20 pools with a simple x * y = k pricing mechanism. You could query for the values of the ETH and the respective ERC20 token in any pool, and viola, you have a spot price oracle.

v1 leaves a lot to be desired as an oracle protocol, however. First, everything was priced in ETH. In order to get a non-ETH quote, say the price of BAT in terms of USDC, you would need to chain prices together (in this case, BAT-ETH and ETH-USDC).

Second, the price was a simple point-in-time (and more specifically and tragically, point-in-a-block) spot price. This is vulnerable to manipulation, as an “unfortunately timed” liquidity withdrawal and large trade could swing the price dramatically. I wouldn’t recommend relying on that price for a sensitive task like determining if a borrow position is underwater.

v2 improved on the utility of Uniswap as an oracle. First, v2 allowed for any arbitrary ERC20-ERC20 pair. Second, each pool took a snapshot of the price at the beginning block before any trade or liquidity change had taken place, which made manipulation more difficult. Finally, the price value it stored (a running accumulator of the price multiplied by the seconds since the last block) allowed a user to calculate a time-weighted average price (TWAP) as opposed to a simple spot price.

Getting a TWAP from a v2 pool did not work out of the box, however--it required integrators to store past values of the running accumulator in a separate contract for calculation.

Uniswap v3 maintains the benefits offered in v2, but also addresses the aforementioned flaw by offering the ability to store a series of accumulator values (only 1 value is stored by default, but anyone willing to pay the gas cost can expand the number of tracked values to a maximum of 65,535 observations, or ~9 days of prices).

Oracle usage today

Uniswap v3 is already being used as an on-chain oracle in varied contexts.

A number of projects call Uniswap v3’s oracle function from their contracts, including:

• Popsicle Finance (an LP yield optimization protocol)

• keep3r network (a decentralized task runner protocol)

• Frax (an algo stablecoin)

• Lixir Finance (an LP manager for Uniswap v3)

• Rari Capital (creator of the Fuse lending protocol)

• Babylon Finance (decentralized asset management)

• Unipilot (an LP yield optimization protocol)

• Angle (a stablecoin protocol)

These oracle calls are made across a wide variety of pairs. We can see in the figure below that while USDC-WETH is the most commonly called pair, it only comprises 17% of oracle calls. There is a long tail of assets for which the oracle functionality is used. A number of these are directly related to the protocols mentioned above (.e.g FRAX, KP3R). More, however, are simply assets for which Uniswap is likely one of the most significant sources of liquidity (e.g. ENS and of course ELON).

Uniswap DAO as keeper of the oracles

The oracle functionality is already being used, and that’s despite a relative dearth of material on the the performance of Uniswap oracles (though I refer you to an excellent thread on the cost of attacking a v3 oracle by Michael Bentley).

Where is the incentive to improve and maintain the oracle experience, however? Oracle usage doesn’t currently benefit traders, LPs, or maintainers of the protocol.

Protocol trading fees are already a possible source of DAO cash flows in v2 and v3 (though no fees have been collected to date).

It’s worth considering a fee to use price oracles. While this would require some protocol changes, this could be implemented as a flat fee in ETH per call or a registration of a project’s contract on an array of approved oracle callers.

In exchange for these fees, the Uniswap DAO could become a “keeper of the oracles.” What would that mean in practice? The DAO could:

• act as a “liquidity provider of last resort”

• provide liquidity incentives to pools that are high value as price oracles

• provide data and research regarding oracle performance

• provide better documentation for best practices around oracle usage

By “liquidity provider of last resort,” I mean the DAO could create an automated strategy or appoint an LP manager to provide certain amount of passive liquidity to pools that are important oracles and running low on liquidity. This could dissuade attacks as well as respond to attacks spanning multiple blocks that involve withdrawing liquidity or affecting the liquidity balance of a pool.

The limitations of current Uniswap oracles

This discussion feels incomplete without acknowledging some of the limitations of the using Uniswap oracles as they exist today.

While using a simple spot price (as opposed to a TWAP) from an AMM is inadvisable, a TWAP reduces the freshness of your data (it adapts more slowly to changing market conditions by definition). In choosing the length of time over which to measure the TWAP, you face a dilemma:

• The shorter the time window, the more the TWAP is susceptible to manipulation.

• The longer the time window, the slower the TWAP adjusts to changing market prices.

Take a lending protocol for example. If the price of collateral hits a sudden downtrend, and the TWAP doesn’t reflect that a position is under-collateralized until 30 minutes after the start of the downtrend, the spot price by then may be even lower, which could cause the protocol to take a loss on the now possibly underwater position.

That being said, the attractive part of Uniswap oracles is they work relatively autonomously. Even without the extra assurances a DAO could provide, they would continue to work well just given the incentives of market participants.

Coming full circle back to Vitalik’s post, it could be interesting to explore how the DAO could use current pool TWAP model as one ingredient in an oracle solution that adds in fresher, off-chain sources of price data. Until then, I say a bird in the hand is worth getTWAP(birdsInBush, birdsInHand, ‘30 minutes’) in the bush.

Appendix

Image of the oracle at Delphi is ‘The Oracle’ by Camillo Miola (1880), source: Getty.

Dune analytics queries:

• Uniswap v3 oracle calls by project, by project, past 28 days from 2021-12-04

• Uniswap v3 oracle calls by pair, past 28 days from 2021-12-04

Disclaimer: this post and accompanying code is meant for educational purposes only. None of this is audited, and you should seek out audits before using contracts in production.

There has been much ado about DAOs lately--they are being used to govern financial protocols, form modern day guilds, and crowdfund the sale of historical documents.

But how do they work on-chain? This post will walk through an example of setting up governance using a variant of the popular governance contracts created by Compound Finance. The task? Deploying the U.S. federal government as smart contracts on Ethereum.

All the code discussed in this post can be found in a GitHub repo here. Hat tip to OpenZeppelin for an excellent and extensive library of contracts that I use heavily in this tutorial.

The contracts

CongressToken

link to file

The first step in on-chain governance is for determining who will be doing the governing! For the federal government, that will be Congress.

DAO voting power is typically determined by one’s balance of an ERC20 token. To create our governance token, which I’ll be calling CongressToken, we’ll use OpenZeppelin’s standard ERC20 implementation as well as an extension they’ve made called ERC20Votes.

ERC20Votes will give us the ability to keep track of voting power and exposes an interface to delegate the voting power of your tokens to yourself or someone else.

Two items to note here. First, in the constructor, I mint 3 tokens (technically there should be 535, one for each member of Congress, but I’m too lazy to simulate more than 3 members) and transfer them to the deployer address.

_mint(msg.sender, 3);

Since there is no publicly available mint() function, this will be the total supply of CONGRESS forever. I leave it up to the deployer to distribute these tokens, which is not what you want to do in prod. It would be more appropriate to grant the tokens to a separate contract that will distribute tokens according to some rule.

Second item to note is that I set decimals() to 0. Token balances are always stored as an integer on-chain, and the ERC20 standard dictates that you specify the number of decimal places used to convert these integers into the desired fractional units. 18 decimals is most common, as that is used by ether itself. Here, I don’t desire any ability to fractionalize votes (it’ll be one senator, one vote), so I set decimals to 0.

FederalGovernment

link to file

Next we need to create the logic for governance--how do proposals get created and voted on?

For this we use the OpenZeppelin Governor contract. It’s based on the popular Compound governance contracts, which are also used by Uniswap. Additionally, OpenZeppelin has made an extension called GovernorCompatabilityBravo, which can make the interface of the governance contract compatible with Compound’s GovernorBravo.

There are two constructor arguments--the first (_token) is an ERCVotes-compatible ERC20 that will serve as the governance token. For my setup this will be the address of CongressToken. The second (_timelock) is address of a timelock contract, which we’ll get to shortly.

I set a few constants in the contract. GovernorVotesQuorumFraction controls what percent of the total supply of the governance token needs to vote in order for a proposal to pass. I (somewhat arbitrarily) have 4%.

GovernorVotesQuorumFraction(4)

The votingDelay is the amount of time between when a proposal is created and when voting begins, specified in terms of number of blocks. This gives governance token holders time to review the proposal and delegate their voting power if they choose to do so. I set this at a low value (2 blocks), but this should probably be a day or two in production systems.

The votingPeriod is the amount of time allocated for voting in terms of number of blocks. Addresses with delegated voting power would need to submit an on-chain vote transaction during that amount of time. I again set this to a low value (100 blocks), but this should be probably 3-5 days in a production system for sensitive items.

Finally, I set the proposalThreshold. This ensures that not just anyone can submit a proposal--you need to have a certain amount of delegated voting power. Here, I choose 1, meaning any member of congress (delegated CONGRESS voting power of 1) can submit a proposal.

FederalGovernmentTimelock

link to file

Many DeFi protocol governance systems include a timelock contract. This contract is the one that has the ability to update critical systems, and ensures that no changes can be made without some delay that allows affected users to withdraw funds, change parameters, etc. before a change is made.

For this contract I simply use OpenZeppelin’s TimelockController, which has 3 constructor arguments. The first, _minDelay, specifies the amount of time (in seconds this time) that must pass before a change is put into effect. The second and third are arrays of addresses having to do with who can affect changes. _proposers can queue a change and _executors can enact the change.

We’ll get into how to set those values when we get into the deployment.

USDollar

link to file

Every governance system needs something to govern!

In this setup, the federal government manages an ERC20 contract representing the US Dollar.

I again use OpenZeppelin’s standard ERC20 implementation, but I don’t use the ERC20Votes extension, because USD won’t be a governance token. I make use of OpenZeppelin’s Ownable contract.

Ownable allows you to restrict certain functions to be used by an admin only. The default owner is the contract deployer. In the constructor, I add an argument to specify the owner to override the default behavior. I’ll make the timelock contract the owner during deployment.

I add two public functions here, mint and burn, that have the modifier onlyOwner. This will give the federal government the ability to mint and burn USD by proposal.

Generally, governance should have the ability to call certain admin functions (like mint and burn in this case).

Deployment

In the accompanying repo, I include a script called deploy_util that sets up the governance system.

The first step is to deploy the governance token:

This is straightforward--I print out the deployed address along with decimals and total supply.

Next step is to deploy the timelock contract, as it will be an input argument for the governance contract.

Note that I leave _proposers empty here. The governance contract will be the only proposer, but we do not yet know its address. For _executors, I include only the zero address (0x000…) which means any address can execute. This isn’t insecure, since only transactions that are proposed can be executed, and only governance can propose.

Next I deploy the governor contract, passing in the addresses for the governance token and the timelock.

At this point the deployer address is an admin on the timelock. I grant the FederalGovernment contract the role of proposer, and then renounce the deployer’s admin privilege on the timelock so that governance is in control.

Finally, I deploy the USDollar contract, passing in the timelock contract as the owner. With that, we’re ready for governance!

Creating and executing a proposal

Now we can see what the governance system can do.

The repo contains another script called proposal_scenario that walks through the creation of a proposal in a local hardhat environment.

First, some housekeeping. I need to distribute the CONGRESS tokens to some senators. I grab three spare addresses to have 3 senators (redSenator, blueSenator, and swingSenator--think Joe Manchin). In order to vote later, the token balances must be delegated to a voter. In this case, all the senators delegate to themselves.

Now we’re ready to create a proposal.

Creating a proposal

redSenator wants to propose that $2M is minted, and $1M goes to them and $1M goes to swingSenator.

The FederalGovernment contract interface has a propose function, whereby you can pass calldata to be executed by the timelock.

I create the calldata for the 2 calls to mint on the USDollar contract, and add them to the proposal. The proposal also needs the address to call for each calldata (the USDollar contract for both in this case), the amount of ETH to be sent with the call (0 in this case), and a description.

Once we create the proposal, the governance contract recognizes it as “pending.”

Voting

We can’t quite vote on the proposal yet. You might remember that I set reviewPeriod value on the governance contract that requires n blocks pass before voting begins, giving folks a chance to delegate if they choose to do so.

Since this is a local environment, we can speed through it.

Now the senators can vote. Given that they’ll receive $1M each, redSenator and swingSenator are strongly in favor. blueSenator, who will receive nothing, opposes.

If we call the governance contract, we can see the votes recorded.

Queuing the proposal

Before we can queue up the proposal with the timelock, the voting period must finish. You may recall that I set this to 100 blocks in the governance contract.

Once again, we speed through. Since the yeas have it, the proposal is in the “succeeded” state.

The next step is to queue the proposal with the timelock. The governance contract allows anyone to do this once the voting process is done, so I have swingSenator do the honors.

Executing the proposal

The final step is to go live with the changes. We have another delay, this time enforced by the timelock contract.

After the time has passed, anyone can execute the proposal. I have the original contract deployer do so.

The USD is successfully minted, governance in action!

Concluding thoughts

I hope you found this tutorial helpful!

To recap, we:

• re-created a simplified version of the federal government via on-chain governance, with a governance token (CONGRESS), a governor contract based on Compound’s popular contract, a timelock contract, and a managed ERC20 (USD)

• walked through creating, voting on, and executing an on-chain proposal in this setup.

Here are links for your reference:

• the repository

• OpenZeppelin documentation

• Ropsten deployments of the contracts:

  • CongressToken

  • FederalGovernmentTimelock

  • FederalGovernment

  • USDollar

So you want to write a Dune query for some quick and dirty analysis, but the contract isn’t verified on Dune! *starts sobbing uncontrollably 😭😭*

But degens aren’t deterred! With a little understanding of Ethereum events and a little effort, you can be on your way to querying.

In this post we’ll walk through analyzing some data from a contract that is yet to be verified on Dune--Juicebox’s Terminal V1 contract that is being used by Constitution DAO.

I realized partway through writing this tutorial that Richard Chen already used the methodology I’m discussing to create a query for summing the amount given by each contributor to ConstitutionDAO, so to give due credit to the Gandalf of Dune wizards, I’ll be breaking down the steps to get to his result.

Ethereum events

Events (also known as logs) on Ethereum are a way of storing historical information that is significantly cheaper than contract storage. While this data can’t be accessed by contracts, they can be easily queried from an application.

They are typically used as records of pertinent information from a transaction, so they are also great for analysis.

In this example, we’ll look at Pay events from the Terminal V1 contract, which have information on who paid into the DAO and how much. I pasted an example of one of these events below from Etherscan.

Getting the events we want

Dune Analytics has a table of all the events that take place on Ethereum--ethereum.logs. But how do we get the events we want?

Events have up to 4 indexed parameters to make querying from a node easier and faster. Dune stores these in ethereum.logs as topic1, topic2...

The first topic is almost always the “event signature,” an identifier for the event.

There are two ways to get this:

1. Grab it from an example event on a block explorer

2. Compute it yourself using the event information

For the first method, if you have an example transaction and the contract is verified on Etherscan, you can grab the first topic from the event log. In our on-chain example, you can see that the signature is `0x3deb3bb81c337489381f7685daa204d30e6a265dac443a718949c258e3e17317`.

Say you don’t have an example transaction handy or the contract isn’t verified on Etherscan, doesn’t matter if you’re a degen! If you know the event name and parameter types, you can compute the signature yourself!

The signature is the keccak256 hash of the event name and argument types:

keccak256('eventName(arg1 type,arg2 type…)')

For the Pay event, it’s:

keccak256('Pay(uint256,uint256,address,uint256,string,address)')

Using node and `ethers`, we can run:

const ethers = require('ethers');

ethers.utils.keccak256(ethers.utils.toUtf8Bytes('Pay(uint256,uint256,address,uint256,string,address)'));

We get the same result:

Finally, we can use the event signature and contract address to fetch these events in Dune:

Using the event data

Now that we have the event data, we can start to look at some numbers.

Looking back at our sample event, let’s look at what information we have:

We want to see the contributions to ConstitutionDAO by contributor. You can see there is a projectId field on which we’ll want to filter, a beneficiary field showing who contributed (and therefore should be the beneficiary of DAO tokens), and an amount that we’ll want to sum.

ethereum.logs has 4 columns (topic1-topic4) for each of the (up to) 4 indexed fields. projectId will be in topic3 and beneficiary will be in topic4. amount is concatenated with the other non-indexed parameters in the data field.

You’ll notice that the data fields (topic* and data) are not nice decoded values. Rather, everything is a bytes data type.

For addresses, we want to the hex string anyway, so all we want to do is effectively cut out the leading zeros in the bytes with the substring function like so:

SUBSTRING(topic4 FROM 13 FOR 20) AS address_from_topic4

For projectId, we want to get a numeric value. We can use the bytea2numeric function to convert the raw bytes to a decimal number like so:

BYTEA2NUMERIC(topic3) AS project_id_from_topic3

Last but not least, we need to combine the previous two functions to get the amount parameter. Since amount is one of the non-indexed parameters, it is concatenated with the other non-indexed parameters (note and called). Since amount is the first parameter and it’s 32 bytes long, we can clean it up like so:

BYTEA2NUMERIC(SUBSTRING(data FROM 1 FOR 32)) AS amount_wei_from_data

You’ll notice that this is a large number, because it is the amount of ether specified in its smallest denomination--wei. We need to divide it by 10^18 to get the amount in ether:

BYTEA2NUMERIC(SUBSTRING(data FROM 1 FOR 32)) / 1e18 AS amount_ether_from_data

We can check all these parameters are correct by comparing our query with our sample event.

Looks great!

If we apply everything discussed herein, we end up with Richard Chen’s query for the largest contributors:

Go forth and query, my fellow degen wizards.

Appendix

One thing to watch out for when doing this is are parameters that aren’t a fixed width in bytes. For example, in the Pay event, there is a note field of type string. The string type can be an arbitrary length, so if you’re querying in the data field for a parameter after it (like caller), it takes some extra tricks. I’ll leave that to you to figure out :)

“The distribution of COMP will become a core mechanic of the Compound protocol. All users and all applications built on top of Compound will continuously, and automatically receive governance rights, for free—in order to shape the future of the protocol.”

In other words, the initial goal of liquidity mining was to distribute governance tokens to users who would then become active participants in protocol governance.

Since that time, liquidity mining has been used by a number of DeFi protocols to distribute governance tokens from their treasuries, including Uniswap, Aave, Curve, and others.

It’s worth discussing these programs, because many aren’t cheap. Hasu and Monetsupply argue that native tokens in DAO treasures are the “crypto-equivalent of authorized but unissued shares.” Paying out these liquidity incentives puts new tokens into circulation that otherwise might have stayed in the treasury, imposing a cost to existing token holders in the form of dilution.

In this excellent financial statement put together by Ryan Watkins, we see that in Q3 2021, Compound protocol paid out $76M worth of tokens in liquidity incentives. Compare that number to the amount of grant money paid out over that same period--a measly $100K.

In this post I’ll try to answer the following questions:

• Is liquidity mining achieving one of its initial goals on Compound--have those that received large amounts of COMP become active governance participants?

• What changes should be made to Compound’s liquidity mining?

Has Liquidity Mining on Compound Distributed Governance Rights to Active Governance Participants?

Thanks to the transparency of public blockchains, this is a question we can answer with the help of data. There are two simple questions we can ask regarding whether or not those who receive liquidity mining rewards become active participants:

1. Do they retain an economic interest in Compound (or do they simply dump the COMP they accrue)?

2. Do they participate in governance (do they vote on on-chain proposals)?

To answer this, I analyze the top 100 accounts by accrued COMP from liquidity mining. To make the analysis easily reproducible, I choose a specific block height--13570000 (2021-11-07).

These top 100 accounts have accrued 809K COMP (roughly $271M at current prices), representing 69% of all COMP mined.

Yet very few of these accounts are COMP hodlers. Only 19% have kept greater than 1% of the COMP they claimed; only 7% have kept greater than 50%. Do recipients of liquidity mining rewards retain an economic interest in Compound protocol? No.

It stands to reason that if very few of these addresses are hodlers, very few vote. Indeed, only 1 address from the top 100 ever voted on a Governor Bravo proposal.

Do the users who mine the most COMP work to shape the future of the protocol? The answer is a clear “no.”

What changes should be made to Compound’s liquidity mining?

I would argue that these results demonstrate that liquidity mining on Compound is broken. Large quantities of COMP are being given out to folks with little interest in governing the protocol.

Below I list and explain some ideas for changing Compound’s distribution strategy.

Scale back liquidity mining

Right now, many large COMP accruers are engaging in recursive borrowing and lending--they deposit tokens, borrow tokens using that deposited collateral, deposit the borrowed tokens, borrow more, and so on. This practice isn’t economically useful to the protocol.

This practice is encouraged by the fact that both borrowing and lending on Compound reap liquidity mining rewards. This practice could be scaled back if only one side of the market was incentivized.

I suggest only incentivizing lending. Lenders, I believe, are more likely to be interested in passively earning yield and have an interest in good governance (likely exercised via delegation for smaller participants) of the Compound protocol in the long run so that their lent funds are safe. Only incentivizing lending could help reduce the practice of recursive borrow/lending while still attracting this target user profile.

Create a vesting schedule for accrued tokens

To better align incentives of liquidity miners with the protocol, there could be a vesting schedule specifying when the underlying COMP tokens become redeemable. This COMP with a vesting schedule could itself be tokenized, and these tokens could retain governance rights.

A counterpoint to this approach is that it’s possible to hedge away price risk from COMP by shorting it. However, hedging incurs a cost to those who do it, and so there will be a greater incentive to mine from those who wish to take on price exposure from COMP than from those who wish to immediately hedge away price exposure once mined.

Governance mining

An alternative to liquidity mining is an idea put forth by Jacob Phillips called “governance mining.” Instead of distributing governance tokens to those who lock up capital in the protocol, you could distribute tokens based on contributions in proportion to their impact on the protocol.

The underlying assumption here is that contributors--those who put time and effort into the protocol--will be much more aligned with its long-term success of the protocol than yield farmers.

One issue here is the subjectivity of determining what contributions are the “highest impact”--the simplest solution would be to use an agreed-upon community multisig to estimate impact and distribute tokens accordingly.

A simpler form of this idea would be to simply dramatically expand the grants program to reward contributors based on bounties.

Give users an explicit voice in governance

I agree that in DeFi, users of protocols should have a say in how those protocols are run. However, giving governance tokens to users doesn’t necessarily provide a “user voice” in governance if most of the tokens are being dumped on the market.

An alternative to granting governance tokens to users is to just give users an explicit voice in the protocol. A certain amount of voting power (say ⅓), could be reserved for protocol users in proportion to their economic stake (total value borrowed or lent, for instance).

Closing Thoughts

Liquidity mining programs merit more attention in DeFi governance more broadly--are they achieving their intended objectives? In the case of Compound, it seems clear that liquidity mining incentives are a poor way to turn users into stewards of the protocol.

A separate goal of liquidity mining could be to simply to attract capital and drive usage, though this use case also merits a careful cost-benefit analysis and I think that should probably be viewed as a short-term way to create network effects rather than a long-term growth strategy.

Regardless of what you think the goals of liquidity mining should be, the scales of these programs merits more careful measurement and consideration of their costs and benefits.

Appendix

For more detail on the data analysis used in the post, check out this Google sheet or this Github repo.

Addendum

Added 11/15:

h/t to Adam Cochran for suggesting to look at delegations in addition to votes. More of the top 100 addresses (16%) delegated voting power at some point than voted (only 1%).