# Ask ARB

### Title
Ask ARB

### Name

Jord (DAO Masons)

### Email

[e-mail]

### Multisig

DAO Masons Moloch Treasury on Arbitrum

0xc77a56e4ccdfe77d89312359c0ba452c70ab2ffb

### Wallet Addresses

- Jordan Lesich, (dev.jord.eth) Project Lead/Dev: 0xDE6bcde54CF040088607199FC541f013bA53C21E
- Matt, (UI369.eth) Ops: 0x27773b203954FBBb3e98DFa1a85A99e1c2f40f56
- Chris Wylde (boilerrat.eth) BD, comms: 0x67243d6c3c3bDc2F59D2f74ba1949a02973a529d
- Sun Jo, UX/UI Designer: 0xB34F249343a493793cB1e9Fe95B221B1aE6793EA

### Socials

https://x.com/daomasons

https://t.me/daomasons

https://warpcast.com/jord

### What is the range of your funding request, denominated in ARB
38K ARB

### Is this a one-time request or an ongoing, scalable project? This question is required.

Ideally, this will have one follow-up proposal. Our first phase will be to build Ask Arb. Then we plan to use (dogfood) Ask Arb to gather signal from voters on new features and voting modules.

### What immediate needs and/or high-impact areas in the Arbitrum DAO does your project address? This question is required.

#### Signal Gathering

We need to accelerate the decision-making capabilities of Arbitrum DAO. To do that, we need to expand beyond the paradigm of Y/N voting.

While other options for Multi-choice voting do exist (Jokerace, Snapshot), they present too much friction to the average DAO member to poll the delegated voting power of a DAO. Combined with the incentive and user-input review mechanisms of Thrive Protocol, Ask Arb stands to offer a seamless and powerful way to source the opinions and preferences of Arbitrum DAO.

#### GX (Governance Experience)

Any member of Arbitrum DAO -- regardless of technical capabilities -- will be able to create a multi-choice vote and gather signal from the DAO in under two minutes.
**-Cutoff**

The interface will be content-rich and will include the reasoning for each user's decision. By building a real-time interface, we can capture the liveness we see on apps like pump.fun and friend.tech and apply it to voting.

Whether we're hosting a 1-hour poll during an Arbitrum DAO community call or a 2-week idea generation contest, the UX should showcase the experience of voting in multi-player systems (ie. DAOs).

#### Super-Charged Voting.

As mentioned earlier, Ask Arb is built on Stem voting contracts. Stem is a modular framework for voting schemas (think Allo but for voting). This means that every piece of Ask Arb is configurable. Here's a breakdown:

- **Choices Module**: This module decides how we create choices (the things we vote on), who gets to create choices, and how these choices are managed (merging, branching, etc). You can also program in onchain rewards or reputation for adding choices.
- **Points Module**: How many votes each address can vote with. Our first implementation will be the Arbitrum DAO delegated weights, but in the future, we can integrate reputational scores (Thrive) or participation scores (more voting weight for past participation). It can also factor in staked or vested token balances.
- **Votes Module**: This module decides what happens when a user votes for a choice. This can incorporate voting schemas like quadratic or donation voting. This contract could also include rewards onchain rewards for voting.
- **Execution Module**: What happens as a result of a vote. This allows the contracts to autonomously perform any transaction with the results of a vote, whether that's sending funds to the top-rated choices, managing voting thresholds and quorums, or creating new rounds of Ask Arb with the results.

While the options for Ask Arb are potentially limitless, it is worth mentioning that the first implementation of Ask Arb will mostly be for gathering signal.

In the second phase of this project, we aim to use Ask Arb to see how the DAO wants us to supercharge voting.

### Summarize your project idea

Ask Arb is a simple, turbo-charged tool for voting, polling, and surveying Arbitrum DAO. It is focused on making the experience of complex decision-making as clean, fun, and simple as possible.

#### Deliverables

Conditions for success (product)

- User should be able to create a token curated contest, survey, or poll
- Users should be able to easily vote on a poll, survey, or contest using their delegated ARB balance
- User should be able to visualize all the past Ask Arb votes
- The user should be able to visualize the present vote data
- User should be able to add content and reasoning for their decisions
- User should be able to see their voting impact
- The app should track user's past votes (in the future, we can use this as a reputational score)
- Results from a user action should update quickly and reliably
- User should know what is going on. The app should display all and explain the relevant data (vote times, snapshots, how-tos, and content). The data should be live, relevant, and reliable.

Here are all the deliverables that will make this happen

##### Refined Voting Contracts

We've already written similar voting contracts for Grant Ships. However, we would like to refine and tweak the UX based on user feedback.

2 weeks

##### Factory Contracts

Factory contracts can abstract the complexity of building all the Stem Modules into one transaction. This is what will allow users to create an Ask Arb in under 2 minutes.

1 week

##### Real-Time Indexer (Envio)

During the development of Grant Ships, we happened upon Envio, a tool that makes indexing the chain far easier and faster than the subgraph. It is faster to build with and has a wider range of capabilities. We can poll Envio to get live updates and update the app as users interact with it.

In short, the user will not have to refresh the page to see what other users are doing.

1 week.

##### Real-Time Interface

This app will consume events from our indexer and display the results of voting in real time. This app will undergo user testing to ensure that it is as easy as possible to use.

4 weeks.

#### Launch and Measurement

We aim to celebrate our launch by deploying spicy polls for the hard questions for Arbitrum DAO (ex. how much sequencer revenue should we charge per TX, or how should we reward contributors).

Over two months, we aim to measure:
- Number of Ask Arbs created (by us vs. by community)
- Ask about Arb participation over time
- Ask Arb deployment speed (UX refinement until under 2 minutes)

8 weeks

#### Benchmarks for success

##### How we will measure simplicity

Any member of Arbitrum DAO should be able to deploy a contest, poll, or survey with one transaction, in under 2 minutes. (Factoring out times to write questions or options in the case of polls or surveys). We aim to gather first-time users and measure how long it takes for them to deploy an Ask Arb.

##### How we will measure stickiness

We are going to measure Ask Arb participation at the beginning of product launch and measure participation 2 months after launch. Our goal is to demonstrate that Ask Arb has stickiness and will continue to attract users far beyond the initial hype.

##### How we will measure voter empowerment

We are going to measure overall contests created by us (DAO Masons) vs. other members of the DAO. Within a couple of months, we expect far more community-created Ask Arbs, than ones created by ourselves.

#### Why are you the best person/team to run this project?

We wrote the underlying contracts, and we know which steps we to take to implement Ask Arb. Grant Ships, another project we have built for Arbitrum DAO, is already utilizing these contracts, and many of the hard technical challenges have already been worked out. I (Jord) am already deeply familiar with every part of the stack.

DAO Masons have proven themselves in implementing a complex coordination game with Grant Ships and are capable of ensuring that the operations (measuring results, launch operations) will run smoothly and are communicated well to the DAO.

##### Past Projects

- Grant Ships
- App (app.grantships.fun) repo (https://github.com/DAOmasons/grant-ships-app)
- Contract Repo https://github.com/DAOmasons/allo-v2
- Envio Indexer https://github.com/DAOmasons/gs-voting-envio
- Subgraph Indexer https://github.com/DAOmasons/grantships-subgraph
- Docs (rules.grantships.fun) https://github.com/DAOmasons/RuleBook
- Stem Voting
- Stem Repo: https://github.com/DAOmasons/stem-voting
- Used in Grant Ships
- DAOhaus
- V2 (app.daohaus.club) Repo: https://github.com/HausDAO/daohaus-app
- V3 (admin.daohaus.club) Monorepo: https://github.com/HausDAO/monorepo

##### Referrals

- DistruptionJoe: (Thrive Protocol) (TG)
- Zer8: (Gitcoin, Grant Ship Operator) (TG)
- Ali: onchaingamer.eth (Treasure DAO, Grant Ship Operator) (TG)
- Dekanbro: (Founder @ DAOhaus, PublicHaus, Raid Guild) (Discord)

#### Provide a detailed budget breakdown denominated in ARB

Total funding request 38k ARB

- Development 23k ARB
- Refining existing stem contracts (free)
- Survey contracts (5k)
- Factory contracts (2.5k)
- Real-time indexer (2.5k)
- Real-time interface (10k)
- Design (3k)
- Operations 7.5k ARB
- Measuring grant metrics (3k)
- Managing launch operations (4k)
- Marketing, Community Management & BD (7.5k)
- Product placement (using Ask Arb during community calls)
- Creating exciting contests, surveys, and polls.
- Engagement with Arbitrum social platforms
- Engaging with Arbitrum forum discussions (creating topics relevant Ask Arbs and dropping them in the forums)

### Is there anything else you would like us to know?

#### FAQ

##### Why can't we just use XYZ product?

Here is a breakdown of the existing alternatives, to demonstrate the value of this product, I aim to be as fair as I can in my assessment.

#### Existing alternatives.

**JokeRace:** Joke Race is a great product to gather signal for a token, but it doesn't factor in how ARB is currently delegated. While it is possible to upload a whitelist, it would require writing a script that queries the etherscan API for the historical records of delegations, which is far out of reach for most users. Also, JokeRace is a generalized interface and contract set geared to satisfying the needs of voters across the ecosystem. We aim to build a specialized product that hones in the particular needs and voting styles of Arbitrum DAO. This will also help us implement new Arbitrum specific voting features over time.

**Snapshot:** Creating a Snapshot proposal for Arbitrum DAO requires a delegate with an extremely high amount of ARB. The existing Arbitrum DAO can only be configured by the owner of the ENS name that is registered. Snapshot cannot record the user's reasoning behind their votes, and because it is offchain, it cannot trustlessly execute transactions based on the results of the vote.

**Other Web2, Offchain options:** Tally forms, Twitter polls, Google forms, and centralized offchain solutions are all easy to use, but they all suffer from the same issues. Web2 solutions are not Sybil resistant and they do not track the token-weighted votes of each member. The user input is not tamper-resistant, censorship-resistant, transparent, or verifiable. Therefore, the results of these surveys and polls are likely to be seen as a 'gut check' at best and illegitimate at worst. There is no reason that we cannot create a tool that is just as easy to use as Web2 solutions, with all the security and legitimacy of an onchain tool.

### All funds distributed are compliance-relevant. If your application is successful, do you agree to undergo a KYC/KYB/KYT verification? This question is required.

Yes.

### Use Cases