EIP-5: Incentivizing Proposals

Background

One of the strong points of Emptyset Finance is having a governance model that can reinvent all aspects of the protocol.

The protocol has grown big enough that it cannot rely on team efforts alone. There’s no mechanism in place for the community to self fund the evolution of ESD.

The unique constraints around Epoch length and duration, warrants speed in pivoting when necessary.

We already have a function in place, that is being used to incentivize proposal committers.

Solution

Use the existing function incentivization() to reward proposers, coders and auditors.

Only successful proposals get these rewards. It encourages more contribution to protocol growth and will help in pivoting faster.

4 Likes

I think this is a good idea. We can either mint ESD directly, issue coupons, or take a protocol fee out of expansions into an insurance and/or dev fund

We very much support this pattern and intend for anyone creating proposal to utilize it to reward themselves for the work they’re doing.

Additional specs on how to implement this:

In Implementation.sol the function initialize() runs once when a new implementation is committed. This function is used to run start-up logic for the new implementation.

Currently we reward the committer of the proposal with 100 ESD using the mintToAccount method. This uses the same code path as the advance reward, minting new ESD and incrementing the debt.

Everyone that took part in producing the proposal should reward themselves similarly in this function by minting ESD to their own wallet. Potential examples of contributors:

  • EIP Creator
  • Coder
  • Auditor
  • Deployer
  • etc

We do not yet know what amounts should be standard for each role, please use your best judgement on what is reasonable and ask the community what they think. Too low will discourage potential future contributors, while too high will risk proposal rejection.

1 Like

I support this. I’d recommend that early use keep compensation relatively low (<2k ESD?) to ensure that it doesn’t become a point of contention that overshadows the content of a proposal. However, I certainly would love to see this ramp up and eventually standards develop based on complexity, urgency, expected impact, etc.

Something is seriously wrong if you’re having points of contention about paying devs more than $2k in a $100mil market cap software project.

While you’ll always find someone to take your crypto, most good engineers I know are not blind to their value and will walk away from a lowball without thinking twice. You can rely on people’s enthusiasm alone, but I’d recommend having a reasonably sized R&D war chest. It will get you a lot further.

1 Like

I feel that certain features could even merit a royalty. Some small % of the benefit of that feature over a fixed time period. Interesting to consider the possibilities there

1 Like

Have you spent any time around any crypto projects? There tends to be a lot of contention around this issue. I’m all for paying people fair market for their work, but I think starting there with this mechanism isn’t likely to go well. There are other ways to fund development. An R&D/dev/community fund is one way, but tends to lead to politics and capture over time. A private, ConsenSys-like company is another way. There are options. I’m just recommending starting slow with this particular mechanism based on how I’ve seen it work with similar projects.

1 Like