Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Q (lolz) is a proof of stake EVM compatible blockchain. It's native currency is Q tokens that are used for voting, staking and much more.

The voting mechanism has four components:

1. A proposal is created.
2. Voters lock their Q Tokens.
3. Voters cast their votes on the proposal.
4. The proposal is either accepted or rejected.

The _vote() function counts votes that are proportional to the amount of tokens they have. After enough time the proposal is either accepted or rejected.

To use a Q token for voting, the token is locked. Users can delegate their voting power to other users as well. The voting power of a user is calculated based upon the quantity of Q tokens that have been locked until the end of the proposal voting period.

The vulnerability is about the counting the votes. Using a particular flow, we can get tokens to be counted twice.

1. User A delegates their Q tokens to User B.
2. User B votes on a proposal, with the incorporating voting power from User A.
3. User A announces the unlocking of their Q Tokens.
4. User A votes on the same proposal with the same Q tokens being counted twice.

Why does announcing the unlock make this possible? It seems like such a weird flow! The flow of operations does not seem to consider the case where a delegated entity had already voted then decided to unlock their tokens. At this point, it is assumed that the person will take their tokens out; but, they are still able to vote.

Voting bugs are always fun! Double counting bugs on voting are terrible and compromise the eco-system. Write up could have been more clear on WHY this happens instead of the teaser they include.