PeerVote

PeerVote

PeerVote: Empowering Local Communities. Sustainable governance and private voting. Extending PeerUp.

PeerVote

PeerVote

PeerVote: Empowering Local Communities. Sustainable governance and private voting. Extending PeerUp.

The problem PeerVote solves

Our solution tackles key problems faced by local communities:
Lack of Decentralized System: We enable local communities to establish their own decentralized resource-sharing and local development investment system. This empowers them to efficiently manage resources and foster development.
Complex Decision-Making: Traditional decision-making processes within communities can be time-consuming and cumbersome. Our governance system simplifies this process, allowing community members to participate in decision-making easily and privately.
Onboarding Non-Blockchain Users: Blockchain technology can be intimidating for newcomers. To address this, we utilize an Account Abstraction (AA) system that provides a user-friendly interface, making it seamless for non-blockchain users to get involved.
Incentivizing Participation: Active participation is vital for effective governance. We incentivize early voting by allowing communities to offer gassless transactions up to a set amount, calculated in US dollars with the help of API3 oracles.

Challenges we ran into

Timestamp on L2

We encountered several challenges while implementing our voting system. One significant issue we faced was related to the usage of block.timestamp for defining the start and end of the voting period. Initially, we expected the timestamps to be in the Unix timestamp format, as commonly used on Layer 1 (L1) blockchains.

However, the block.timestamp value on ZkSync seems to have a different format or representation. This inconsistency caused compatibility issues and resulted in incorrect time calculations for the start and end of the voting period. As a result, the system was unable to accurately determine the voting duration.

Frontend integration with zksync

We used wagmi library and ethers to connect users to our app with their wallets. We experienced a technical challenge while trying to employ the Paymaster and send transaction with Metamask through the Ethers and wagmi libraries.

Our objective was to engage with contracts and use Paymaster to avoid user paying gas fees, for which we followed the examples set by zkSync example repositories. In those instances, a wallet object is created by the zkSync util library.

Nevertheless, we faced a hiccup when we attempted to utilize a signer, which was generated by WAGMI following a connection with Metamask. This led to an error message specifying:
zksync client.js:1 Error: invalid object key - customData (argument="transaction:customData", value=...). This implies that the customData included in the transaction might be causing the issue.

This was not a blocker, because voting uses burner-wallets, we implemented a solution using single-use wallets, stored in the browser's memory, which satisfactorily bypassed this hurdle.
However, our goal is to seamlessly incorporate Paymaster with the regular wallet to improve efficiency across all functionalities of the smart-contracts.

Tracks Applied (4)

DAOs

Our solution is a perfect fit for the DAO track sponsor because it addresses key issues faced by local communities. We e...Read More

Public Goods, Impact, Education

Our solution aligns with the "public goods, impact, education" track by enabling decentralized resource-sharing, inclusi...Read More

zkSync

Build & Deployed on zksync, inkl. paymaster. and subgraph to get data for the frontend... Using paymaster we achieved bu...Read More

zkSync ∎

API3 - Paymasters

Using API3 Paymaster in order to set a threshhold per Proposal. Per Proposal 100USDC can be max paid by the api3 paymast...Read More

API3

Technologies used

Cheer Project

Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.

Discussion