Pre-Proposal for a Year-Long Community Developer Contract

Governance
1

Introduction

Over the past few years the community has grown together and identified improvements in the go-livepeer codebase that are needed to keep Livepeer at the forefront of the DePIN sector. These improvements are crucial for the protocol’s expansion and scalability, but are often outside the scope of Livepeer Inc’s resource allocation.

While Livepeer Inc has played a pivotal role in developing the core codebase, it’s now time for the community to step in and bring on specialists to tackle projects that help the protocol reach its ambitious goal of becoming “The Worlds Open And Decentralized Video Infrastructure”.

This proposal outlines the terms and structure for engaging a community developer under a year-long contract to contribute to the Livepeer Protocol, funded through the public treasury. This engagement aims to leverage the developer’s previous expertise and knowledge of the protocol to maintain the go-livepeer codebase from a community point of view.

Developer Engagement Overview

Contract Duration: 1 Year (12 Months)
Time commitment: 15 hours per week
Start Date: April 1, 2024
End Date: March 31, 2025

Proposed Community Developer

Brad (@brad-ad-astra-video ) is a long time community member and go-livepeer contributor that has shown a remarkable ability to understand and improve the go-livepeer codebase. He has a robust history of dealing with go-livepeer with forked repos of dealing with bug fixes, feature requests and entire rewrites of working binaries such as the Livepeer Router. As a regular community member, we often joke of adding “another item to Brads list” since he can clearly explain the problem at hand and provide a solution with real actions to take. This proposal aims to compensate Brad for commitment over a 12 month period.

For resources on Brad’s contributions you can view some examples here:

These are some of the examples of work Brad has done which clearly demonstrates his ability to navigate and improve the go-livepeer codebase.

Major Tasks and Responsibilities

The developer will be entrusted with a range of responsibilities aimed at bolstering the protocol’s infrastructure and network reliability. This list of tasks, while not comprehensive or sequenced, provides a broad overview of some anticipated work.

  • Node reliability
    – The community has identified some reliability improvements on both the Broadcaster and Orchestrators nodes due to the need of reliable RPCs and uptime of blockchains. These potential issues can be fixed and tested before a possible outage occurs.
    – Ticket redemption and payment optimizations.
    – Continued work on the Public Stream tester.

  • Stream Routing and Load Balancing
    – Three Orchestrators are already using a forked version on the go-livepeer router. This can be implemented and pushed to the rest of the community. Some features of the router may include: handling different job types, handling load balancing, handling geo location rules and country specific rules and regulations, AI job routing and more.

  • Hardware Integrations
    – Adding support for other transcoding GPU/TPUs.

  • GitHub issues
    –Managing and pushing fixes to GitHub issues as they come up.

  • Codec support
    – Adding and maintaining support for AV1 and other GPU related tasks.

  • AI integrations
    – Working to incorporate different AI pipelines into the Livepeer AI worker. This would allow different tasks to be processed in the network such as speech-to-text, object detection, object classification, etc.

This list should not be seen as a set of fixed deliverables, but rather as a collection of accessible tasks that the community developer can undertake, given the available time and resources.

Compensation and Payment Terms

Annual Compensation: 8,000 LPT
Payment Frequency: Monthly
Payment Method: Timed release smart contract, distributes funds every month
Accountability: Three “Guardian” addresses will be added to the smart contract that will have the ability to terminate the payments and return the remaining funds back to the treasury.

Collaboration

While we aim to have the community developer in an external/auxiliary role, there may be times when it is best to collaborate with Livepeer Inc’s internal team on scope and complexity of work. While we hope to gain support from Livepeer Inc where needed, our goal is to not direct any resources away from their efforts. We want to use our treasury to hire independent help to encourage decentralized and multi driven approach to protocol robustness.

Our commitment is to the health of the protocol and progress of the mission.

6 Likes
2

Hey.
Is it okay if the payment is agreed on in dollar terms? 8k lpt is ~180k$ as of today, so can we put this figure there as the reward instead of 8k lpt?

(There is a good chance Lpt will be a lot more pricey in a year and the monthly payment could become over the top during the year)

3

Since the treasury is based in LPT, how would we manage payments in dollars?

Also what do you mean by over the top?

4

I remember rewarding the previous applicants by dollars. Like AI front app was 250k, am I remembering it wrong? :thinking:
…

Ok, just checked. Ai front app agreement was in lpt terms but cloud spe was in dollars. Please see the attached.

1000031327
10000313271080×2340 161 KB

By over the top, I mean Ai front app was for 25000 lpt which at the time was 250k$ but it is now over half a million dollars! And it’s only been a few months work. A very valuable one, true, but it could become a million very easily in another few months, which is over the top for any months-long development

5

And we want to avoid paying developers for hard work with crypto that correlate to the success of the project they are working on?

I don’t really understand. The treasury has over 153k LPT in it right now and growing every day. Why punish people working on the project by pegging their efforts to USD? They should get the upside (and downside) of working directly for the treasury and the project it supports.

It’s very similar to stock options in tradfi. The more successful the project, the greater the price of ownership, the greater reward for the people building it.

Earning LPT has the exact same upside opportunity as downside so it’s the most fair.

Also it’s not like the treasury cares about saving the spread between fluctuating USD price, it earns LPT every day, it only make sense that it pays in LPT. Much easier to calculate and forecast.

Lastly, I’d like to see “how” one would pay a monthly budget in USD to begin with. The other grants were lump sum payments (in LPT I remind) that were calculated in USD based on the current price. How do we manage monthly payments of USD when the treasury only releases LPT funds once?

1 Like
6

Using crypto as a medium of exchange and unit of account are not even advised with Bitcoin let alone other crypto. They are too volatile. Let’s make agreements in dollars and convert the corresponding lpt to dollars at the time of payment or make it a lump sum amount if monthly payments in dollars is infeasible technically by a smart contract. (Do we have Chainlink integration yet?)

I understand your points and mostly I agree, Titan. But I don’t wanna give up an arbitrary number of Lpt from the pool anymore. This is now easily going to 100 dollars.

1 Like
7

As long as the community is ok with it, we could easily do a lump sum amount of LPT based on the current price in USD. That would fix both our problems as I would view it as a payment of LPT and you would view it as a payment of LPT in equivalent USD.

But then how do we ensure the developer is meeting expectations? They can certainly get the lump sum and take off with the money. How do we combat that?

I’ve implemented a monthly release of funds with the option for guardians to terminate the contract and refund the treasury. I think this will set a nice pathway for hiring many devs into the network. So my next questions are:

How do we extend a contract beyond a year? Maybe we want to employ this person for 2-3 years, do they get a lump sum payment for the whole thing?

As for oracles on monthly payments, how do you combat price fluctuation? If LPT drops 95%, how do we top up the LPT if the treasury gets drained?

1 Like
8

Hi Titan,

Thanks for creating such a detailed proposal. This is a worthy proposition to encourage and reward an excellent community member, who has already given so much expertise and time to Livepeer. To give an opportunity to someone who is already well versed in Livepeer gives us the best chance of success in adding developer expertise.

From what I understand, the Treasury funds (in LPT) are for encouraging builders to build on Livepeer, improve our product and if we can add talented developers, who are already familiar with Livepeer, to help develop Livepeer, I think we should do it.

We have a great opportunity, especially with AI right now and timing is critical. Lets have @brad-ad-astra-video join the team formally and get compensated for his hard work.

256x256_App_Icon_Green_Circle

2 Likes
9

Fully in favour of having some specialists committed to the protocol payed for using the treasury.
While Livepeer Inc is committed to demand gen, go-livepeer has seen less and less development since the Arbitrum migration. Given his past and in-progress contributions I think that @brad-ad-astra-video is the perfect candidate for the job.

Some points:

  • peg compensation to USD or not?

I agree with @obodur that locking in the total value in LPT using the current value might not be the best choice, at least we shouldn’t lock in the current value for an entire year. Whether the price crashes or goes to the moon, there’s a risk of under/over-payment.
If the price doubles the same amount of LPT could be used for two developers, rather than paying one developer an extremely high wage. If LPT price halves, developers should still get fair compensation to keep them motivated.

I don’t see this as punishing the developer, they would get a fair compensation regardless of LPT price and can choose to convert it or keep it in LPT to reap the rewards of any price increase. Having uncertainty in compensation might make it difficult to find prospective developers.


  • balancing red tape vs accountability

One of my biggest peeves with crypto grants is the amount of overhead that comes with creating proposals, getting consensus, community updates, etc. I would like for Brad to be able to focus on development, but there has to be a little bit of accountability.
With the goal of flexibility and having more developers in the future, maybe this should be handled by a SPE? Developers could make a brief quarterly summary of items they want to tackle and the SPE can handle ‘the other stuff’ like monitor progress, request LPT from the treasury as needed, make sure payouts happen, interview with candidates, extend contract time, etc.


  • prioritisation of tasks / wishlist

If the protocol is paying for developers, network participants should have some kind of voice into what is important to work on. The end decision can be up to the developer, but something like Livepeer’s Canny page can be nice just to have an overview of wants & needs.


  • standardised wages?

8000 LPT @ $20 = $160K yearly. I’m not from the USA, but that amount of money would pay for two senior engineers (or 3-4 mediors) in the average EU country. I would prefer for compensation to be equal for all developers (taking expertise and hours worked into account), but the current proposal is a tad high in my opinion (especially for a parttime commitment).

2 Likes
10

hi! just lurking and thought maybe i could help

what if you peg half of the compensation to LPT and the other half to USD?

i imagine that it’s good to have a certain amount of risk/reward exposure for those doing the work ahead of the work being done so that they can benefit from any value increases resulting from their work

2 Likes
11

  • Calculate USD/LPT at the time of payout. Whatever happens to the price after is irrelevant, welcome to paying people in crypto, it’s great and it sucks.

  • Do not over-pay. Like @stronk said, that’s a pretty big wage. In my opinion, it doesn’t matter how volatile the asset is, that’s the game we’re in - it can go both ways. You can bridge and sell pretty quickly if you want to.

It would be great to see both @brad-ad-astra-video and @elitmik get paid for the work they do and have done, just throwing in my 2 cents.

1 Like
12

I mostly agree with @Titan-Node and think that we shouldn’t overcomplicate things.

  • The treasury is in LPT and we need an LPT amount for the on-chain vote - so whenever possible, we should also specify the proposal in LPT. Now if we had good (protocol owned :wink: ) liquidity, we’d also have to option to instantly swap those LPT to e.g. USDC and then pay a constant amount of $ each month. But right now, that’d be quite difficult since you’d have to use a CEX for that.

  • The amount of LPT should mostly be decided by @brad-ad-astra-video. He decides what he wants/needs for his commitment (calculating in the volatility of LPT in $ terms) and each of us then decides (by voting) if that is reasonable. Of course it’s nice to have a discussion about it, but nobody knows the future price of LPT.

  • IMO, we shouldn’t compare this to standardized wages but to the value it brings to the protocol instead. Sure, you might find a dev that’s willing to do those tasks for 30-50% cheaper, but maybe you’d also spend 6 months looking for this dev and the dev has to spend another few weeks to get familiar with the codebase. And after the job is done, that dev would most likely look for other opportunities again.
    So I’m happy to pay a bit more LPT for reliability, speed and to an actor who seems committed to Livepeer for longer than just this one contract.

13

So with my comments I was aiming at trying to be a bit more formal and standardised in the way this proposal is dealt with so that it is something we can re-apply in the future. I don’t think we should call it a ‘community developer contract’ if we’re not treating it as such.

I would only vote in favour to the proposal as-is since it’s a ‘insider’ where we all already know the LPT is well spent.

  • specify the proposal in LPT
    All proposals so far have been translated back to $, as for the receiver it is income and a taxable event based on the $ value at time of payout. Since we don’t know the future price of LPT, the current price is the only thing to go by for now, with any price fluctuations being a risk for the developer (not the protocol) to take on. To me, overcomplicating is writing a custom smart contract at all. Why not just put in a proposal on a quarterly basis with an immediate payout? Easy to translate to a current value and it doesn’t hamper Brad from doing work at all.

  • Standardised compensation vs network value
    The current proposal is setting a precedent for future potential developer and for future treasury proposals in general. If we’re paying an hourly wage of $250, we’re ‘devaluing’ the token and set high expectations for the next person making a request.
    It’s OK to be generous since there is no onboarding required etc, but if we’re going to compensate based on ‘value added’ rather than ‘resources committed’, we should also have proposals to pay MistServer (where currently almost all demand on the network flows through) and Livepeer Inc LPT.

14

We defiantly could do that. I was originally thinking of a 2 year commitment for brad but likely a good idea to start with one. Do you think 4 proposals a year would be too much for the LPT holders for 1 developer?
If we had 2 developers that would be 8 proposals a year to renew agreements. Just wanted to keep proposals less frequent.

Yeah that’s a great idea. I don’t see why the treasury wouldn’t fund the companies building it and driving traffic to it. I think that’s the whole point of the treasury. We just need someone to create the proposal.

And just to stick on that point for a second. The treasury earns 1k LPT per day. I’m not sure how big the MistServer team is but 8k annual compensation for a team of 10 would only take 80 days. The remaining 285 days are still free to figure out how to spend :slight_smile:

1 Like
15

Yes, maybe the title of the proposal is a bit too generalized. Personally, I don’t see this proposal as setting a standard for “hiring” devs. I see it as an individual proposal for Brad. If we plan on hiring more devs from the treasury in the future, an SPE would make more sense. So the treasury would fund the SPE and it then handles the (monthly?) payouts based on the current value of LPT.

I like the quarterly idea, but I’m not sure if we’ll see “voting fatigue” when having a vote for the same proposal every 3 months.

Sure, for features and time spent out of scope of the employment contract - why not?

3 Likes
16

Sure, for features and time spent out of scope of the employment contract - why not?

Right, but that’s exactly the inconsistency i am trying to highlight here.

Again, i am in favour of the proposal ( and would even vote in favour if it was more LPT ), but i would prefer if we would judge all treasury proposal equally and fairly. What I dislike is that we’re lowering the bar (IE no accountability or alignment of goals for when we get further into the year) and have a disproportionate payout just because we like the ‘value added’ which is not very quantifiable.

We don’t do that for other proposals. To me, this proposal is the first of it’s kind and marks the start of a new chapter in the Livepeer protocol, where we have an indepent actor of Livepeer Inc committed to the protocol (and hopefully we’ll see more proposals for like a frontend engineer or a protocol engineer so that we can finally pimp the explorer or rework incentives or whatever)

When talking about other entities like MistServer and Livepeer Inc, why is it now important that there are quantifiable features & time commited and not simply the value added? They’re the only entitities which provide exposure to the protocol at a large scale and the bigger & badder they are, the more exposure we get. Any feature or bug fix ‘adds value’ to the protocol. For example, If MistServer adds SCTE-35 support it unlocks a whole new segment of customers who require server side ad insertion.

So all I’m asking is for us all to be consistent in how we’re dealing with the treasury. Do we want to seed entities for adding value, or ask for a commitment in time or resources for a fair compensation?