Revising the Developer Mining Program

Context
The first developer mining announcement.

The second was a revision announcement.

Developer mining pays out weekly rewards to contract deployers and those deployers can pass rewards on as liquidity mining or dapp mining.

How its going right now
Developer mining has been fairly successful but its getting complicated. It’s also not been clear that rewarding at the contract level makes the most sense – Perhaps the program should be more focused on rewards at the “minting layer.”


This is how it looks right now :point_up:

  • It’s complicated: we have dev miners paying dapp miners and liquidity miners, but also dapp miners paying minters, and overall communicating of this structure is tough.
  • It’s not so permissionless
  • With very few exceptions, dev miners and dapp miners are the same. The two-layer system may not be worth the effort.

Proposed Change
What would happen if we made dev mining only work like dapp mining?

  • At the point of minting, the tokens are tagged
  • The owners of the interface receive the rewards
  • No contract ownership happens here – Anyone could get paid for minting tokens on an existing live contract.

Looking for feedback and thoughts on this design change.

1 Like

I still don’t understand how dapp mining and dev mining work in detail so simplifying the process seems like a wise decision.

Can anyone tag tokens when minting or do they still need to be whitelisted to receive rewards? I. e. can I mint tokens “manually” and tag them with my address to receive rewards without them going to the dapp first?

How would the tagging work?
Completely on chain?
Offchain where sponsor signs a message with both minting tx hash and rewards receiver address as body?
Something else?

More questions:

How would this affect non sponsors providing liquidity to synth pools (e. g. YD-USDC). If they buy the synth instead of minting it, does that mean they get no rewards at all? Wouldnt that drive away a lot of liquidity (which is necessary for the original use cases of most synths) from those pools?

If dapps decide to pass some rewards to liquidity miners, how will dapps then be able to differentiate between LP providers that minted through their dapp and other LP providers?

If dapps decide to not pass rewards to liquidity miners, what would be the incentive for sponsors to do something with their synths and not just hold them?

I like the simplicity, but I do worry about a couple of things here.

A lot of effort goes into writing UMIPs, writing price feeds, launching contracts, overall product creation. I see this as the meat to the DAPPotatoes. Not that building a dapp is easy (it’s not!), but once the first interface is up, it’s not too difficult to add new contracts in. I’m worried that teams would gravitate to only doing the dapp work, under the assumption that other teams would do the product development for them.

It seems that the largest bang for your buck would be to only focus on creating a universal UMA interface. I think this could result in rewards being monopolized by the most recognized/used UI. If I already go to BigCompany interface XYZ for all of my UMA needs, why would I ever switch to a new one?

Also, how would LM work in this new setup? Would dapp miners all be contributing to a LM pool?

I have similar concerns but none of the developers themselves seem too worried about this.

While I see your point re: a universal dapp, I also think some of the point here is that each dapp needs to do its own marketing. We don’t expect users to even need to know uma is under the hood.

I think the fact that most uma users are customers of free money, and so they come to uma for that. But people who are customers of the novel risk that the product offers would go to the UI.

As for how LM would work, well, yes dapps could either offer rewards only for minting, or they could offer for mint and LP. If they do the latter, someone else can mooch on their liquidity. But if they mooched too hard, they’d shoot themselves in the foot too - So I’m very keen to see where an economic equilibrium is reached here.

I’m going to post on behalf of YouMyChicFila from Discord:

We’re in 100% support of this. Never really liked the walled garden around px identifier ideas preemptively, especially when they don’t action upon them (i.e. torn synths, ice futs, etc.) and makes it awkward for others to work on it in parallel when it comes to EMP deploys and splitting up rewards, etc. With this new proposal, rewards end-to-end creation + user acquisition + user retention as was pointed out above. In our space, a mere idea for a “price identifier” isn’t worth as much as delivering end-to-end and maintaining engagement.

To quote another person:

“not that it’s a perfect parallel, if we proxy % rewards given back to rent seeking, they can and should be challenged. healthy competition, where user retention is top of mind for everyone. like, if you can’t retain your users then that’s probably a forcing function for you to continually iterate we see an ennumber of “c/p” forks on traditional defi dapps/protocols and vampire attacks are the norm, but if that keeps users on the original platform i see it as a notion of antifragility”

You’ve probably noticed that we’re the most generous in terms of our waterfall rewards shareback compared to most other folks here, ideally in our minds those should be driven to 0 for builders and ~100 for users (and in some cases, our users became builders), and if others want to create a user experience and economically incentivize them to roll off, so be it!

Can anyone tag tokens when minting or do they still need to be whitelisted to receive rewards? I. e. can I mint tokens “manually” and tag them with my address to receive rewards without them going to the dapp first?

Right now there is a whitelisting process for adding rewardable tags

How would the tagging work?

Tagging works by appending your payout address to the end of the data field (input parameters) on every mint transaction.Its a very simple method with low technical bar and allows rewards to be calculated offchain.

1 Like

tldr: dapp mining is not permissionless, and most likely we will have to redo entire dapp mining design if we switch over exclusively. alternatively we can build better tools towards EMP admins who run their own programs downstream of dev mining.

I have some concerns from the technical side. The great thing about dapp mining is that the attribution mechanism is robust and not gameable. It segregates each EMP into their own bucket, which makes it easy and safe to do further down stream rewards.

Dev mining on the other hand is not nearly as robust or un-gameable. What I mean here is that you can play games that unfairly attribute you a higher score or reduce someone elses score without actually providing more value to the EMP. This is possible because the tagging system is voluntary and spoofable, so its not possible to design out this flaw. This is OK now because dev mining separates the rewards between EMPs, therefore any funny business is not worth it and does not leak out from one EMP into the broader ecosystem.

Now when you consider dapp mining as the only scoring mechanism, this may make it worth it to execute some exploits that could suck rewards towards a bad dapp actor across all EMPs. I wont say exactly how, we can talk internally about that if needed. Dapp mining now is also permissioned, we whitelist addresses to reduce this issue. Basically means that they way we do tagging will need to change to a much more robust and probably expensive mechanism. This switch over probably wont be easy and will require coordination across teams who have already built this mechanism into their UI.

I think an alternate solution to this problem is to improve the tooling around running these programs as a third party. If dapp mining and liquidity mining could be rolled up into a UI with an easy 1-click interface for an EMP Admin, we could still leverage our dev mining infrastructure while making it easy for people to run their own downsteam programs.

1 Like

Hey David - Thanks for providing the reality check.

Something Sean mentioned to me on a call is that maybe we could still use the dev mining design, but just attribute 0% to the deployer? Would that at least keep the spoofing risk siloed inside of each EMP?

As for the permissionless vs. whitelist, I don’t think it needs to be truly permissionless insofar as we don’t need any interaction - I think it’s fine that we’d still solicit tag information.

Thoughts?

I agree with YouMyChicFila on walled garden of price identifier that’s registered preemptively doesn’t make sense, but I think we should still consider still a fair share of reward going to developers that put up hard work of preparing the umip.

2 Possible options here for consideration:
I) Reward ‘contract owner’, but with decreasing weightage over time as more goes to dapp mining.
II) A time limited ‘contract ownership’ for an EMP before it fully transitions to pure dApp mining, but with a twist. For as long as the EMP is used, the EMP deployer gets milestone based UMA reward.
e.g. even if the EMP goes into full dapp mining, but if the EMP gets large adoption (e.g. 100 mil TVL), a fixed amount of UMA can be airdropped to the deployer.

Depending on how this is structured this should keep the emp creator (who should also be the first dapp miner) enough time to grow, while minimising the risk of a large company ‘taking over’ it. (e.g. if Zapper or maybe Celsius doing it, leaving the dev that did the hard work not rewarded fairly)

Will put more thoughts into this, and come back with more comment.

1 Like