Assemble is coming

Archive
,
1

A quick post to share the latest on Liquid Funding! (More about the original concept here for those unfamiliar).

Launch plan

We’re not far away from launch and are working towards mid-November to go live :crossed_fingers:We have a simple launch brief and marketing plan ready - we’re not initially targeting a giant audience but rather introducing the concept to our core group of followers.

The working name for our implementation of LF is Assemble, and it will have its own look and brand, i.e. it will be a distinct project from Status, not e.g. Status Liquid Funding nor Status Assemble.

Currently Assemble is on Ropsten and we are doing some final work to: a) make it seamless to fund projects using any token, and get funded in any desired token; as well as b) adding branding aspects to present the concept.

Features

The idea with this v1 is that projects can seek funding, and funders can commit funds to projects - it’s a functional and basic MVP.

What don’t we have in this v1 and why? We haven’t yet figured out the delegate flow - the contracts support this functionality, but our first iteration doesn’t offer it because it’s complex and trying to display it in the UI in an easy-to-understand way turned out to be pretty challenging. More so than that, it’s a deliberate choice for v1 to be simple in order to get people comfortable with using it, and for those people to tell us what they would like to see in the next iteration.

Funding

We’ve set aside a small initial amount of funding from Status for trialling this out. We’re currently not looking to replace legacy services agreements that are in place with core contributors as it doesn’t make sense with the initial budget and scope of this first implementation, but the eventual aim will be to offer liquid funding as an alternative path to funding development of the Status Network.

Do you have any side projects you’d like to get funding for? Have a think and get ready to submit them for funding when Assemble launches! As a rough guide (numbers still TBC) - for core contributors and existing partnerships, funding requests for up to ~$5k will be considered, for community members, it’s ~$1k (these caps are in place while we figure out best accounting practices for how to make payments - it’s lower for community members simply because we don’t have KYC in place as we do for core contributors).

Also - if you want to act as a funder to any projects that are pitched, you’re more than welcome to do that too.

Next steps

Once the trial run is done and our first tranche of funding has been allocated out, we’ll gather feedback and see how people found it, then use the feedback for Assemble’s roadmap.

Any questions? Drop them here. Cheers!

9 Likes
2

I will spec this out further but based on some conversations today here is an initial project proposal:

To enable better community and stakeholder governance, we need a better way to conduct Community Governance votes than the current implementation of the SNT Voting DApp. With Assmeble launching, and potentially presenting a significant increase in project proposals to The Status Network, we need a fair, simple, and effective way to manage all projects that helps us make decisions as to where funds are allocated.

This can include a Governance portal similar to what MakerDAO does at vote.makerdao.com. It can be a governance section of discuss.status.im. It can be an update to the Status Voting DApp. There are many ways to go about it (not only those listed above) and should have a dedicated team to think through all scenarios and implement the best decision.

We have also discussed various forms of voting and experimenting with voting mechanism such as:

  • Quadratic Voting in SNT voting dapp
  • Incentivized voting
  • Vanilla voting

A deliverable to this proposal should be to not only build the tools to conduct community governance, but also define the means by which we do it.

As @hester explained, Community Voting and Governance will become a crucial element to Assemble and we need to figure out how best to manage proposals.

3 Likes
4

Thanks for writing this up!

5

@jonathan Just to better understand what we’re trying to solve for - what are the issues that mean the current DApp isn’t fit for purpose?

6

The current voting DApp has many UX issues:

  • The description field is limited and does not allow for a detailed breakdown of the proposal (pro’s, cons, reference material).
  • The flow to actually get to the vote is not great imo
  • If we start to conduct significantly more votes, the archive and current proposals lists are not great

Outside of the UX of the actual DApp, there are some other issues:

  • Is quadratic voting the best mechanism for this? We should experiment and leanr
  • Will an incentivization mechanism be good or bad for the community short/long term?
  • Can we introduce on chain consequences to results?

This is a significant amount of work both in research, experimentation, and implementation. My proposal is to build a dedicated team to solving and implementing this.

1 Like
7

I think we focused on the wrong part of quadratic voting, as the name implies we decided to focus on the square root of the votes which requires proof of identity which is currently not enforceable on chain.

Another part of the QV research that is enforceable on chain is voting credits and the ability of defer votes for future benefit. So any votes that an address does not use in a current poll they can accumulate and use in future polls that matter to them.

I started thinking more about what are the levers here that can be adjusted and came across the modern rational voter theory developed by Downs (1957), Tullock (1967), and Riker
and Ordeshook (1968) is the most widely applied framework when analyzing why people
vote.

Which can be expressed as: U = qB − C + T

Where:
q = the probability voter is pivotal

B = Benefits if ballot wins

C = cost of voting

T = extra benefit of voting

After factoring all these in, only when U or the utility value to the voter is positive will they be compelled to vote.

Using this model, quadratic voting & voting credits increase q or the probability the voter is pivotal.

Incentivized voting offsets C (cost of voting)

onchain consequences increases B or the benefits (my hunch)

I think this at least now gives us a framework from which to have a principled conversation about how different voting implementations potentially impacts the utility to the voter.