An interesting fact, little known in the community:
Roughly, half of ERC20 in the market are implementing the standard called ERC-20 Snapshot (docs.openzeppelin.com/contracts/3.x/…). 1/9
You may not believe me but @Uniswap Uni is using it, @AaveAave stAave is using it and all tokens used in Snapshot right now are implementing this standard.
Here is Uni implementation 2/9
It might sound surprising but this implementation has an annoying side effect. It adds between 20k to 100k gas per transfer. After 3 069 472 txs on UNI ERC-20, at an average of 50gwei (at current eth price), this feature costs the community a minimum of 0.3$ per transfer
3/9
Today, the Snapshot website announces 1.8k spaces, therefore at least 1.8k ERC20 with that features. I'll leave the total cost computation to the readers.
4/9
Anyway, notice also this is only used for signaling as Snapshot is not directly actually executing votes on L1.
To be clear, it is not an accusation to Uni and others, but about addressing the elephant in the room.
5/9
Voting on L1 is expensive and this cost prevents DAOs to live to their full potential.
Many have discussed solutions to offload voting. Interestingly, weeks after we started working on the project, Aragon published this post (ethresear.ch/t/experiment-i…), very close to our design
6/9
But they are usually facing the two core issues of Offchain Voting using ZKPs: 1. Voting with an Ethereum signature in a ZKP 2. Proving storage on a previous Ethereum block, known as StorageProof (medium.com/hackernoon/get…)
7/9
StarkVote on StarkNet by Snapshot solves 1 and 2, enabling practical L1 voting. No more multisig shall be required to run a DAO. The community should be fully autonomous. StarkVote is backward compatible with any existing ERC20 and does not require users to lock their tokens.
8/9
It is the ultimate voting solution for DAOs and we are very proud to work with Snapshot and bring StarkVote to life.
9/9
Also, let stop using ERC-20 Snapshot please :) The block is too small for that
Actually, more like $3.6 according to @HaymanLiron per transfer! This is insane :)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
1/n We just publish the new extension of dAMM on which I have been working for some time with @Brechtpd from Loopring. I believe it could be a groundbreaking design in the upcoming multi L2s.
A quick thread 🧵:
@Brechtpd 2/n For those who follow @StarkWareLtd work, we publish a few months back the first version of dAMM: an L2 AMM design where the restrictions are enforced on L1, simplifying greatly the AMM design of a constrained system like StarkEx.
3/n Not only it provides a simpler design, but it also provides additional advantages like the ability to lend the pool asset using an Asset Manager as proposed by BalancerV2.