Alchemy Working Group -- Kick off

🌱 Ecosystem
, , ,
1

Alchemy Working Group

This is a call for participation in the Alchemy working group focused on the next iteration of the Alchemy governance system.

Alchemy went live 3 years ago, since, many lessons have been learned on all stack levels-- infrastructure, UI/UX, composability, scalability, design philosophy and more.
This purpose of this WG is to structure and converge on these lessons and ideas by starting a collaborative process between DAOstack, DXdao, PrimeDAO, dOrg and potentially other DAOs (NecDAO, _Prtcl, Gnosis). And to specify, cooperate, and build the next iteration of the governance system.

image

DAOstack has done significant work in this regard and has a few design principles, most stem from feedback and lessons from DXdao, ecosystem DAOs, and general Alchemy use. We will present these thoughts in the first meeting, along with a recap of ecosystem needs (DXdao’s and PrimeDAO).

General

  • Bi-Monthly 1.5h hour meetings
  • 1800 UTC every other Tuesday – Jan 26, Feb 9, Feb 23…
    First meeting will be at 19:00 UTC due to clash with the DXdao governance call
  • The meeting will be open for the entire DAOstack, DXdao, PrimeDAO, and other relevant ecosystems.
  • All meeting notes, recordings, tasks, and produced documents will be logged in this notion

Participants:

  • @Eylon Facilitator
  • DAOstack — @ezra_w Product manager and other DAOstack members per request / requirement
  • DXdao — @powers leading the governance 2.0 initiative in DXdao, and any other community member
  • PrimeDAO – TBD
  • dOrg – TBD
  • _Prtcl – TBD
  • Almonit – TBD
  • Open for the community, Dev and Governance oriented
  • Meeting points and agenda will be published via DAOtalk / recorded on Notion.

WG topics to cover:

  • Specification and design principles for next iterations of the product
  • Align processes and roadmap
    • DAOstack will builds core contracts — Voting machine, Rep contracts, MultiCall, Competition, etc.
    • DXdao / PrimeDAO builds specific needs — (Multicall target apps, Worker dApps,
    • Collaboration on design, front-end, UX, and architecture.

First meeting - Tuesday 26, Jan. - 1900 UTC
Click here to add the event to your Calendar (gcal)

Agenda

  • @ezra_w will present the following points, feel free to share or comment ahead of the meeting.
    design principle - simple governance contracts with external design choices
    • Generic reputation contract (Allow the use of several rep contracts, Token addresses, etc)
      • This tackles both the incorporation of DXD as voters in DXDao, and future ‘DAO-to-DAO’ interactions
      • This will allow a simpler implementation of Governance 2.0 WG results and decisions.
    • Scalability
      • Short term — Incorporating Snap in the Alchemy UI
        • Incorporate REP in the snapshot proposal process
        • Incorporate ERC20 token in the proposal process
      • Long term — Deploying on Arbitrum / Optimism / else
    • Multi call for everything
      • All plugins will use the Generic multicall with global constraints / approvals
    • Complete UI overhaul
      • Add Discourse forum to the UI
    • Simple codebase.
      • No reputation flow
      • Rely on External contracts
      • Simple voting machines
      • Much cheaper gas
  • @Powers
    • Governance 2.0 needs and requirements
  • Open Discussion on further needs and requirements

Feedback and comments are most welcome, the WG, just like the intended outcomes of it, is a collaborative process between DAOstack and the Ecosystem.

3 Likes
2

This roadmap is amazing and really seems to address user needs!

5 Likes
3

Notes for 26/1/2021 Meeting

Alchemy overall roadmap:

Jan - Feb / March:

  • Low-hanging fruit improvements
  • Develop the Next Iteration (codename: Elixr)
  • Build the team/coalition

March and on:

  • Build the “Next Iteration”

Current low-hanging fruit improvements:

  • Standardized staking token for reputation feature (nearly done)
  • Clear instructions for adding multicall / competition / staking for rep to DAOs (nearly done)
  • Alchemy - snapshot integration (wireframes mostly done)
  • Competition UX improvements (make sure it is as usable as possible in its current form)
  • Mini UX-sprint
  • Integration of new layer 2s as they come out (Arbitrum, Matic?)

Next iteration thoughts:

Overall : we are still formulating this plan internally, but this gives some kind of outline of what we’re imagining.

My approach principles: simple, focused, easily modular/modifiable. Focus on making it easy to add functionality that is easily parsed in the UI.

Components:

  • Actions are multicall-based (think apps, a la Gnosis Safe, possibly literally)
  • Binary decision logic (fka voting machines)
  • Generic voting power interface (e.g. ‘balanceOfAt’ or similar)
  • Possibly: constraints, tba

Note:

  • Current scheme system goes away
  • Current required dependency on Reputation goes away (but Rep is still compatible) — more customizability

Spotlight: Scalability

  • Current plan is something like my earlier post:
    • Poll —> confirmation flow
    • Can target any on-chain network

Other areas to consider: discussion tools

  • Should it be integrated into the governance platform?
    • Argument for yes
      • Everyone knows discussion is a required first step for most proposals
    • Argument for no
      • Plenty of good apps for conversation exist: we shouldn’t reinvent the wheel

Some old wireframes that may get reused to some degree

Focuses for meeting today:

  • Feedback on Snapshot / Polling in Alchemy
  • Ways to collaborate on the “next iteration”
    • Collab on wireframes?
    • Feedback in calls like this?
4

Adding a video recording of the call for everyone.

1 Like
5

seems like a poll vote should count as an on chain vote. if not then what is the point? just to help stakers predict how to stake? but that prediction would not have much fidelity if the cost of voting on chain pushes poll voters away.

6

The poll is based on REP, this essentially allows for REP “signaling” without needing to execute an onchain transaction.

If a proposal recieved 20% REP yes signal, once it is actually executed on-Chain the DAO can be confident it will pass with only one person voting on it, saving on-chain expensive transactions.

7

Why? What I am suggesting, phrased differently, is that poll votes be recorded as normal-onchain votes simultanenous (in the same transaction) as when the “poll” is recorded onchain. Are you saying that is in fact what is intended? Otherwise I don’t understand how your statement I quoted above can be true.