ERC20Snapshot Alternative in new OZ Library

Recursive · October 17, 2023, 1:03pm

Hi Everyone.

In my smart contract, I want to take a snapshot time to time to save all the holders balances for future usage.

I was aiming to use ERC20Snapshot but I can see that it has been removed.

From my research, some people say that ERC20Votes can be used for this purpose but I really did not understand how ERC20Votes can be used to take snapshots for holder balances and retrieve them later on.

Can someone please explain me how to use ERC20Votes for this purpose or is there any alternative to ERC20Snapshot that I can use with the new OZ Libraries.

Thank you.

sam41306061 · October 17, 2023, 9:00pm

@Recursive , Have you looked over this documentation for how to implement your SnapShot?

Recursive · October 18, 2023, 3:57am

Hey Sam,
The new OZ libraries doesn’t have erc20snapshot anymore. That’s the problem

malteish · October 27, 2023, 8:36am

Hi @Recursive,

I have the similar questions and am also having difficulties finding the right answers. Apparently, ERC20Votes is somewhat considered the successor of ERC20Snapshots.
From reading the code, it appears there is no need to manually create a snapshot/checkpoint anymore. Instead, each token movement automatically creates a snapshot/checkpoint, so that all historical balances (at the end of a block) are preserved. (The only exception from that is if multiple transactions take place in the same block.)

I really wonder about the gas consumption of this. It takes a lot of storage to preserve every change, even though several tweaks are used to reduce gas cost.

Also, lookups of old voting power are now binary searches, which sounds really expensive.

So, yes, ERC20Votes could be used as replacement for ERC20Snapshots. But to me it does not look like a very good replacement.

Please keep me posted if you find out more!

Recursive · October 27, 2023, 9:27am

Hey brother.
Thank you for your reply. I am considering to keep using the old version of OZ library to be able to use erc20snapshot to be honest. Which is 4.9 version.

Somehow I couldn’t find the historical balance check on the erc20votes.
You got any deployed contracts using erc20votes so that I can check the read functions on chain

malteish · October 27, 2023, 9:35am

Hi,

here is the lookup function: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v5.0/contracts/governance/utils/Votes.sol#L89

I have not used it yet.

Recursive · October 27, 2023, 10:25am

Hey man, it says getPastVotes, votes means balance ?

malteish · October 27, 2023, 10:51am

Yes, the implementation works by defining token balance as voting power.

It also says the votes need to be delegated and not doing so would save gas. I don't fully understand that part yet. I have not seen how accounting of a token transfer changes depending on delegation.

Recursive · October 27, 2023, 11:14am

Do you have any contract addresses that you know using ercvotes? I might check the balance change of it

malteish · October 27, 2023, 11:17am

I don't have an example, sorry. But if I wanted to understand it better, I would create an example in my dev environment and interact with it.
We skipped the talk about the basics:

What is the task you are trying to solve?
What is your background/skillset regarding smart contract development?

Recursive · October 27, 2023, 11:31am

I am currently developing a smart contract that will mint and redeem tokens and at each mint and redeem we will airdrop some erc20 tokens to certain token holders at that time as reflections.

Doing reflections are not ideal on chain transactions as inline since the number of holders can get bigger and bigger causing revert.
So we are moving the reflections to backend.

I was aiming to create snapshots on the mints and redeems and create a event on the transaction with snapshot id and info for being used on backend by listening events and calculating the rewards based on the events snapshot id

malteish · October 27, 2023, 11:54am

Can you elaborate on "reflections"? I am unsure what it means in this context.

But, from an outside perspective:

airdropping tokens to many recipients with each "mint and redeem" tx will be prohibitively expensive if there are a number of recipients. Possibly better: Store `numberOfTokensMintedAndRedeemedSinceLastAirdrop" somewhere, and use it to airdrop once in a while.
If you really want to go the other route, I don't really see why you would need Snapshots or Votes. Listen to the mint events, and react to that in the backend. This means it is not provable on-chain though.

ernestognw · October 27, 2023, 9:26pm

The reason why we recommend ERC20Votes is that the "snapshot" mechanisms were abstracted away in multiple layers. This is its current inheritance graph:

The main difference is that the contract inherits from Votes, where all the logic for snapshotting happens. Given that the contract is built for governance purposes, I see there are a few important differences that makes it behave differently to ERC20Snapshot:

The "snapshots" (now called checkpoints) depend on the EIP-6372 contract clock, as opposed to an snapshotId
The Votes contract counts delegated tokens (by default to the address 0)

To replace the ERC20Snapshot behavior, you'll need to configure the contract clock (EIP-6372) to use an _snapshotId instead, and override Votes's delegates(address account) function to make each address delegate to themselves:

function delegates(address account) public view override returns (address) {
  return account;
}

Here's an example:

gist.github.com

https://gist.github.com/ernestognw/a731a75de7330c472303275f21a4d468

ERC20SnapshotVotes.sol

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.20;

import {ERC20Votes, ERC20} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import {EIP712} from "@openzeppelin/contracts/utils/cryptography/EIP712.sol";

contract ERC20Snapshot is ERC20Votes {
    uint48 private _snapshotId;

This file has been truncated. show original

Although I recognize there are a few extra things you may not need (eg. EIP5805, EIP712, Votes), the gas overhead you mention will be only during deployment. If the contract remains used only for snapshotting purposes, I'd expect around the same gas costs in runtime.

If you really want to reimplement ERC20Snapshot, that's possible using the Checkpoints but I'd keep recommending using EIP-6372 for identifying your contract clock.

Here's an example of a reimplementation:

gist.github.com

https://gist.github.com/ernestognw/6a4a8e15e9435dc67ad17f327701e397

ERC20Snapshot.sol

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.20;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {SafeCast} from "@openzeppelin/contracts/utils/math/SafeCast.sol";
import {Checkpoints} from "@openzeppelin/contracts/utils/structs/Checkpoints.sol";
import {IERC6372} from "@openzeppelin/contracts/interfaces/6372.sol";

abstract contract ERC20Snapshot is ERC20, IERC6372 {

This file has been truncated. show original

WARNING: The referenced code is not audited and is only presented as a pointer for you to evaluate the options.

jusikX · October 28, 2023, 10:40am

We need to consider it.

jusikX · October 28, 2023, 2:20pm

I took your idea and modified it a bit. Now the only problem left is lowerLookup function from CheckPoints structs

Note that the last two functions are redundant, and I use them only for test.

gist.github.com

https://gist.github.com/jusikXL/e41c94c23ab616b2ef066ca0a79a4f17

ERC20Checkpoint.sol

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.20;

import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import {SafeCast} from "@openzeppelin/contracts/utils/math/SafeCast.sol";
import {Checkpoints} from "@openzeppelin/contracts/utils/structs/Checkpoints.sol";
import {IERC6372} from "@openzeppelin/contracts/interfaces/IERC6372.sol";

abstract contract ERC20Checkpoint is ERC20, IERC6372 {

This file has been truncated. show original

jusikX · October 28, 2023, 2:30pm

I modified the Checkpoints library to return an additional bool param indicating if the value is found or not.

function lowerLookup(
        Trace208 storage self,
        uint48 key
    ) internal view returns (bool, uint208) {
        uint256 len = self._checkpoints.length;
        uint256 pos = _lowerBinaryLookup(self._checkpoints, key, 0, len);
        return
            pos == len
                ? (false, 0)
                : (true, _unsafeAccess(self._checkpoints, pos)._value);
    }

malteish · October 28, 2023, 2:34pm

Thank you for these hints, they are much appreciated!

ernestognw · October 28, 2023, 7:09pm

2**208 is more than enough. Even with an ERC20Votes that uses 18 decimals, you would have a buffer of (2**208)/1e18 = 4.11e44 for total supply. That's huge. Also this allows to save gas by packing the checkpoint id with its corresponding supply in a single slot (uint48 + uint208)

jusikX · October 31, 2023, 4:54pm

@ernestognw
What if I want to have ERC20Checkpoint and ERC20Votes extensions simultaneously. I won't be able to override two different clock() functions to return on the one hand current snapshotId and Time.blockNumber() on the other hand because clock() can return only one uint48 value.

One way to solve it is to use some getCurrentSnapshotId instead of clock() and define only CLOCK_MODE or even just forget about IERC6372 for ERC20Checkpoint

jusikX · October 31, 2023, 5:14pm

Also regaring this I will need to comment (see the line)

// Update balance and/or total supply chekpoints before the values are modified. This is implemented
    // in the _update function, which is executed for _mint, _burn, and _transfer operations.
    function _update(address from, address to, uint256 value) internal virtual override {
        if (value > type(uint208).max) {
            revert SafeCast.SafeCastOverflowedUintDowncast(208, value);
        }

        if (from == address(0)) {
            // mint
            _updateAccountCheckpoint(to);
            _updateTotalSupplyCheckpoint();
        } else if (to == address(0)) {
            // burn
            _updateAccountCheckpoint(from);
            _updateTotalSupplyCheckpoint();
        } else {
            // transfer
            _updateAccountCheckpoint(from);
            _updateAccountCheckpoint(to);
        }

        // super._update(from, to, value); THAT LINE HERE
    }

Because super._update i.e. ERC20._update is already called in ERC20Votes to transfer voting power units after the tokens transfer.

Then in MyToken which inherits from ERC20Votes and ERC20Checkpoints I will need to write such an override

function _update(
        address from,
        address to,
        uint256 value
    ) internal virtual override(ERC20, ERC20Votes, ERC20Checkpoint) {
        ERC20Checkpoint._update(from, to, value);
        ERC20Votes._update(from, to, value);
    }

Do you have any suggestions regarding this?

Topic		Replies	Views
Understanding Openzeppelin Governance contract Contracts	2	1228	October 1, 2021
Questions about snapshots and ERC20Votes voting power transfers Contracts	1	1354	October 5, 2022
Custom Voting in OZ Governance Developer Wanted erc20 , solidity	5	996	February 24, 2023
ERC20Snapshot and flash loans/swaps/mints Security	12	4125	June 25, 2020
ERC20 Snapshot extension disappeared from wizard Contracts erc20	16	1108	January 18, 2024

ERC20Snapshot Alternative in new OZ Library

Related topics