Last updated by Tim Delhaes 2 months ago
We are proposing a secure and privacy preserving messaging solution using XMTP and Grindery to improve voter participation in DAO proposals starting with Snapshot.
Decentralized autonomous organizations (DAOs) are seeing explosive growth as people are building companies and organizations on top of token ownership and smart contracts. Grindery’s go-to-market strategy is largely focused on providing DAO with better ways to integrate and increase productivity. Voting mechanisms, as provided by Snapshot, empower collective decision making and are at the center of the DAO ecosystem.
One major challenge of voting lies in voter participation, especially when the community size scales. While there are several different theories and approaches to achieve this one proven way is likely easy to realize: notifications. Informing eligible voters via real-time notification of proposals that are starting or ending and - even more important - of the projected outcome of a proposal can be an effective mechanism to increase voter participation. Furthermore DAO (or proposal) administrators could relay proposal notifications to discord servers and their twitter accounts to inform their followers.
Mechanism and protocols that contribute to an increase in voter participation will be of tremendous value and impact for the web3 ecosystem at large.
However, simple notifications as common in web2 are not that simple to realize in web2.
First, the triggering events for notifications can 0 in many cases - not be simply obtained from a DB or simple webhook. They often require listening to events on one or multiple blockchains as well as performing queries with subgraphs.
Second, voting platforms like Snapshot only know their voters wallet addresses and are unable to send any messages to them via Emails. This is not simply a lack of functionality but rather a highly desired privacy preserving feature inherent in the very nature of web3.
Today platforms like snapshot have implemented simple 3rd party solutions like HAL to relay messages to users messaging clients like Telegram or Slack. Solutions like HAL are a great short term “fix” but not an effective long-term solution.
The right solutions is a system that:
End users would be able to select and configure trigger criteria (like proposal creations or change of predicted vote outcome) as well as their desired client by associating their wallet address with the desired client like their email address, Slack account or browser. These configurations will be stored in Grindery as workflows waiting for trigger events to happen in Snapshot. To protect privacy we will ensure workflow configurations are encrypted and stored in a secure way via our credential manager, to avoid wallet addresses being linked to email addresses. Truly paranoid users can split their workflow into two with a “middleman” connector to minimize chances of leaking wallet identity.
In the future, we plan to allow connectors to add another layer of encryption for their configurations, this means the configuration can’t even be read by us.
To detect relevant events related to proposals the system can rely on Grindery connectors (Triggers) with IPFS and The Graph. This trigger would then execute actions to send out messages to subscribed users via XMTP. Receiving users can set up another workflow for their XMTP address to forward the message to another messaging tool they like.