The Potential Log-Jam for Epoch 3

Mechanism Design
1

Hello everyone!! :wave:

As Octant continues to evolve, we’re keen on fine-tuning our processes based on community feedback. Today, I’d like to open a discussion about projects rolling over into the next funding round and our capacity for new projects.

Reflecting on Our Decisions So Far: We set a minimum funding threshold for several reasons. Firstly, it allows for dynamic voting/donation changes within each allocation window, and we’re curious about how this behavior plays out. Secondly, feedback indicated that a long tail of projects often diverts funds from those with stronger community support. Our goal was to minimize this effect.

The First Allocation Window’s Threshold: We intentionally set an achievable threshold: a project needed only half the average donation per participating project to receive funding. With 24 projects in the first round, this meant surpassing just above 2%.

The Challenge with Project Rollover: Our initial thought was to automatically roll over projects meeting this threshold into the next round. However, given the ease of meeting this threshold, we now face a potential bottleneck for new projects. Currently, about 20 projects are competing for just 6 available slots in our snapshot poll.

Seeking Solutions: I’ve been mulling over a few options to address this, and I’d love to hear your thoughts:

  1. Adjusting the Minimum Threshold:
    We could eliminate the snapshot poll and instead dynamically adjust the minimum threshold based on the number of projects. Given Octant’s current capacity and ETH rates, we can adequately support around 20-24 projects. Getting rid of the snapshot poll, we could theoretically have 50ish projects eligible to participate, but then dynamically adjust what the minimum funding threshold is to capture supporting 16-24 projects out of the hypothetical 50. While getting rid of the snapshot vote would be seen as a positive, right now with Octant’s design there would be a lot on the backend for the team in terms of getting all of this information up on the app for each round. Could get very messy.

  2. Continuous Funding Projects Only Roll Over:
    We could tailor requirements based on the nature of funding needed. For projects with a clear mission and proven track record requiring continual funding (Protocol Guild etc etc), we could set rules that these projects, if valued by the community via hitting a threshold we define, can roll over into the next round. Projects with less funding required or social proof could fall into a category of perpetual funding and subsequently be asked to apply for each round. Just an idea that I’m thinking out loud with. This would be easier to manage for the team in the short term. The snapshot poll would still need to be determined if its necessary, as this idea could integrate with idea 1 above.

  3. Community-Based Threshold Decisions:
    We might consider setting an arbitrary threshold that the community feels comfortable with. Options could include raising the minimum funding threshold to 1/x, 1/(1.5x), or establishing two different parameters: a softer minimum funding threshold and a higher threshold for rollover to the next epoch. In either instance for this idea, this would create more spaces for projects next round, reducing the log jam.

With this conversation in mind, I would love to hash out the best ideas and then potentially vote on snapshot at the same time we are voting on which of the 6 projects will join us for Epoch 2.

Your input is invaluable in shaping Octant’s future here. What are your thoughts on these options? Do you have any other ideas or preferences?

Looking forward to hearing from you all and what can be a great discussion!

10 Likes
3

Hey @james thanks for bringing this up. It’s a tricky discussion. Here are some thoughts:

I think option 2 will be the hardest to implement. In my experience, most projects focusing on Public Goods are in need of continuous funding and it would be subjective to determine which project can or can’t roll over to the next round.

I think option 3 with the dual threshold feels like a good solution for Epoch 3. Although moving forward with the growth that Octant seems to be having, maybe solution 1 would also be needed.

1 Like
4

Maybe I should clarify here what this idea entails because it is something we are researching. Most of the projects coming into Octant don’t need as much funding as they can possibly get. When I look over the projects that apply, over 75% of them have a targeted amount of funding needed to produce X, Y, or Z outputs. Couple that with projects who have privately voiced to us that they only need X amount of funding, there is something here to explore. Of course many projects would love open ended and continuous funding, but from where Octant sits, there needs to be a really clear reason why your project needs a blank check.

I think the terminology that I used here is a bit misleading, so we can redefine the definitions to provide more clarity, but this is the idea. In order to be eligible for continuous or open ended funding (what should we call this instead?), there is a detailed inspection as to the merits of the application. And unless you are very confident in the merits, then applying for perpetual funding probably makes more sense.

1 Like
5

It could be interesting to have a “Git-r-done!” mini-round with just teams that have fixed targets. They publicize what they need, and we rally the GLM lockers to try to get them all to their thresholds :slight_smile:

6

There was a clear long-tail in the funding for projects in Epoch 1. Tor was the fourth most well-funded project at 26.2 ETH, but the fifth most well-funded (Giveth) only got a little more than half that amount (13.8 ETH).

The threshold for guaranteed roll-over could be projects above that cliff, leaving many slots for new projects. Maybe some of the ones below that cliff might want to re-apply and leave it to the community to decide between them and one that is applying to Octant for the first time.

2 Likes
7

So you’re suggesting a mathematical model in whatever projects are under X% of total donation need to apply for next round?

In your scenario, which I really like, the top 4 projects got about 50% of donations, with the other 15 getting about 50%. I kind of like the idea of wherever that 50% or some other % of donations lies, that is where the cutoff is for needing to apply next round.

3 Likes
8

So there are a lot of ways to “solve” this problem but I think we need a little more data from this upcoming round before we can be more confident.

We’ll let Epoch Two’s allocation window run its course and then have some suggested ideas about how to improve this shortly after the window has closed.

In the mean time, if anyone has anymore thoughts on this topic, please share at anytime!

9

When deciding on how to shortlist projects, our northstar should be collusion resistance: preventing wealthy individuals & their cartels from self-upvoting or bribing their community to vote for them en masse.

Vitalik’s 2019 article on this topic was really interesting; i’m adapting the mathematical formulas he wrote to fit Octants use case.

  • Wealthy project owner & their community acquire n GLM tokens

  • each allocation window lets them allocate k to their own project (k = reward from staking n GLM)

  • these give them a reward of k x q (q being the multiplier)

The public goods funding system thus becomes one where projects simply get an interest rate of k x q on their n holdings

Octant solves the collusion issue in a way i haven’t seen other mechanisms use: careful curation of only 24 participating projects, which are mostly well-intentioned and follow the spirit of the system.

But how do we create a system that doesn’t rely on the goodness of participating projects?

One way would be removing predictability of a project being able to participate in every single epoch, reducing incentive for system capture

This approach (no project gets to participate in all epochs for a given year) actually fits in well with this user feedback; if you’ve fulfilled your funding requirements for a year in a single epoch, there’s no reason to re-apply in 3 months.

We can optionally couple this with theme based epochs to make things more interesting for GLM stakers: careful curation of projects within a theme so as a community we collectively learn everything there is to know about that part of the crypto ecosystem during an epoch.

Based on our discord chat I know some of these experiments are going on with mini-rounds, I hope the lessons from there can help us out.

This lengthy preamble was to only underline how important the selection procedure of participating projects is, as curating only 20-24 projects per epoch is octant’s unique answer to the collusion issue laid out by Vitalik, which is prevalent in any decentralized public good funding system.

His 2017 article on blockchain governance advocates multifactorial consensus where ultimate decision depends on the collective result of a plurality of mechanisms. For octant, the different groups at hand are;

  • Octant team core contributors
  • Coin holder votes (currently in use for epoch 2 selection)
  • user votes with some form of sybil resistance
  • norms, as they develop over time
  • proposed governance council

I don’t yet have an answer on how these can all fit together to ensure a good roster of projects in an epoch. Tightly coupled coin-voting as we are currently doing on snapshot is probably not a good idea in future rounds due to relatively low participation in relation to the larger eligible pool, voter fatigue, unequal wealth distribution among holders drastically swinging votes and bribery attacks.

1 Like
10

This is already happening in Octant, so you have a strong point.

I found out the reason why 24 was chosen, and although I’m sure I’m butchering the math from Julian, the basic premise was less than 24 projects, with a minimal funding threshold of > 1/2x, that getting less than 2% of what users donate would be so achievable that there would then be no point in a minimum funding threshold in the first place.

Nevertheless, there seems to be flexibility here.

This is an idea we’ve discussed internally about Epoch themes. One that I heavily favor that the community (or maybe Gov Council first) begins to heavily influence.

Agreed. The counter point to this is, Octant is at a very early stage of growth, and one of the biggest reasons for its current growth has been the support of the projects currently participating. If it is decided upon like what @cerv1 or @mike.sylphdapps.eth suggested in another topic that Octant is on the shorter tail spectrum, then there would be a clash in execution being there are only a finite amount of projects in a given theme that would meet the short tail criteria.

@mashal has already been documenting learnings from our current round with SheFi and we will definitely share those once it concludes.

I do agree that keeping this open to token voters would work against our interests in figuring this out for Octant long term, as I doubt projects who have GLM locked and are currently voting for their self interest would reverse that trend for Octant’s greater good. Maybe core team and governance council can work on this together!

2 Likes
11

I’d love if we could start throwing out potential themes for future epochs. Regranting and Evaluation; Security Privacy Reputation and Identity; Governance and Community are some initial themes that encompass all projects applying so far, based on my first pass at it (have to break it up into multiple posts as there’s a limit of tagging only 10 per post)

4 Likes
12
1 Like
13
2 Likes
14

had to post as each account not more than 3 replies in a row

15

Would be curious to hear their thoughts on it, but prima facie i don’t see a clash between theme based epochs and short tail funding. In fact, themes might be a better way as otherwise the same few popular projects will capture the bulk of the funding round after round, leaving short other equally important but less popular projects.

If a project can get their yearly core funding needs met in a single round, that’s actually better for them than re-applying every 3 months.

I would also argue that a collusion resistant allocation mechanism is of the highest priority since we’re already seeing it happen, so the discussion should center around whether theme based epochs mitigate system capture rather than extraneous considerations like its impact on user growth.

2 Likes
16

Love this idea and would be happy to support in any way I can :slight_smile:

2 Likes
17

@thedevanshmehta Sorry for our permissions issue on this board, this has been resolved. You should be able to say as much as you want, as freely as you want :slight_smile:

2 Likes
18

These are great categories, and I like the idea. In your view, would you suggest having 4 major themes each year with somewhat consistency, and mini grant rounds outside of that to fill in gaps. Or would theme to theme be somewhat arbitrary signaled by the community or council from epoch to epoch?

1 Like
19

Yes i think those limitations were for spam protection. still getting an error when i try merging it all into one comment so gonna leave it as is

Rather than 4 static themes that run on loop, it might be better to encourage projects to apply in Octant at any time and we then categorize all applications into thematic areas. That would let us be more nimble in creating themes that don’t exist yet and also gauge which sectors in crypto are facing more demand or interest.

I also like the idea of having the community indicate via snapshot which theme to run for an epoch, with the understanding that the winning theme would not be repeatable for some time. The council should be able to suggest the theme options that the community votes on but not arbitrarily decide which one to run for an epoch. That being said, i can see the advantage in simply creating an annual schedule where all 4 themes are decided at the start of the year so projects have time to prepare.

Mini-rounds are also a great idea to fill in the gaps that would be left by projects potentially only being able to enter one octant round per year.

1 Like
20

Rather than 4 static themes that run on loop, it might be better to encourage projects to apply in Octant at any time and we then categorize all applications into thematic areas.

I like this, and if we wanted to allow projects to be in more than one themed round, depending on the project it might not be a stretch. E.g. if we had themes of (to make up something silly) “tax software” and “bird mascots”, Rotki could apply to both.

1 Like
21

So are you suggesting then that themes would be dependant upon project applications and the themes we are seeing in applications? Counter to this would be projects being discouraged from applying at all because there’s no guarantee that even if there’s community interest, that their project would be able to participate in a round.

I think the idea sounds good until you start to think about the execution side of things, it can get messy pretty quick. But I also could not be understanding it fully!!