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.