tl;dr —While we don’t encourage pure copycats, whitelisting for rewards will not evaluate product originality.
When we announced Developer Mining months ago, we did so with some anticipation of the program being gamed in certain ways.
One of these ways was through copycats — We worried that if a team put effort into creating an UMIP, and launching a UI, they might suffer a vampire attack for their liquidity: a competing team could launch their own copy of the token, offer higher liquidity mining rewards, and steal the customers without doing original work.
Even if we took a laissez-faire attitude to this scenario (forks are a part of defi, after all), we were concerned about fractured liquidity pools.
However, after running this program for several months we have decided to pivot on this concern. We see good reason that teams should be encouraged to create different product experiences even if the underlying asset is very similar. dApp mining aims to capture this by allowing projects to share in the rewards for a particular contract, but there are occasions where a team may want their own distinct contract, and we would like to allow for that.
Another way of saying this is that that price IDs cannot be trademarked.
It is not that we intend to encourage copycats, but instead, have discovered that it really isn’t all that common. We have also discovered that there are some genuinely creative deployments that developers have avoided for fear of not getting whitelisted — We want to open the gates to these ideas.
Developer mining is an open experiment, iterative, and will shift over time. It is not meant to be accurate 100% of the time, but instead provide interesting learnings about what motivates developers to build on a protocol.
There are a few “known issues” we will iterate on in the near future:
One concern is that some developers experience developer mining as “zero-sum,” because any minted value on another synth means fewer rewards for the others. We don’t see it that way, because the value of the token itself will increase with more builders — we’re all on the same ship after all.
Still, this perception is a problem.
There are certain parameters we anticipate requiring contracts to match in order to be automatically eligible, and launching a contract outside of those parameters would require individual approval.
Scared to Share
Ideation and governance are very public activities and they must continue to migrate in this direction. The core team cannot draft UMIPs or brainstorm financial engineering in private groups, and in fact, the wider community is better at this anyway.
Teams have been reluctant to share for fear of being copied, but historically that has not happened. We would like to find ways to encourage teams to share ideas early and garner community feedback along the way.
Please join the discussion and offer feedback in Discord.