1) Some thoughts on @BalancerLabs / $BAL:
2) Right now people are liquidity mining. What does that mean?
Well each week about $3m worth of BAL at current prices are airdropped on people who are storing coins in pools. This is way higher than the cost of doing so, so people started putting assets in random pools.
Well each week about $3m worth of BAL at current prices are airdropped on people who are storing coins in pools. This is way higher than the cost of doing so, so people started putting assets in random pools.
3) Very few of these were trading, but most were earning BAL. Any ERC20 token with pricing from @coingecko worked.
So, earlier today about $100m of USDTHEDGE and USDTBEAR showed up:
So, earlier today about $100m of USDTHEDGE and USDTBEAR showed up:
4) This was a clear indication of what had been going on for the past few weeks: most of the usage was to mine BAL.
So what does one do about this, and how did the Balancer community handle it?
So what does one do about this, and how did the Balancer community handle it?
5) Well, the options were:
a) get rid of the BAL distributions
b) restrict the set of coins that would be eligible
c) (b), and also retroactively apply it
d) do nothing
What's the right thing for the protocol?
a) get rid of the BAL distributions
b) restrict the set of coins that would be eligible
c) (b), and also retroactively apply it
d) do nothing
What's the right thing for the protocol?
6) Well, from a usability standpoint, I think that the best answer is A > B > D > C. Why?
Really, liquidity mining is stupid. It's similar to transmining, creating effectively negative fees to create the impression of activity. People should use a product if it's useful!
Really, liquidity mining is stupid. It's similar to transmining, creating effectively negative fees to create the impression of activity. People should use a product if it's useful!
7) If you want to keep it, though, whitelisting is reasonable: it cuts off the stupidest cases while keeping a lot of the value.
8) But a key thing here to remember: _this is supposed to be DeFi_!!!
And in DeFi, you don't enact arbitrary retroactive rules. In fact in pure DeFi you _can't_ enact retroactive rules, and are really limited even in forward-looking ones.
And in DeFi, you don't enact arbitrary retroactive rules. In fact in pure DeFi you _can't_ enact retroactive rules, and are really limited even in forward-looking ones.
9) DeFi is all about creating permissionless systems that aren't at the mercy of people's whims.
That's part of what makes DeFi so hard to do well: if you decide you want to change something, often you can't, or are restricted in how. Permissionlessness is a double edged sword.
That's part of what makes DeFi so hard to do well: if you decide you want to change something, often you can't, or are restricted in how. Permissionlessness is a double edged sword.
10) So I think that, really, making any on the fly modifications here is dangerous for a DeFi project, but especially retroactive ones. And if you do, it's important to follow the governance you set out--or else that loses its importance.
11) So how did this play out?
Well, over on the discord, people debated. discord.com/channels/63846…
It was messy.
Well, over on the discord, people debated. discord.com/channels/63846…
It was messy.
12) There were a number of really bad things about the process:
A) Voting was done on discord, not by BAL tokens. So that undermines the governance of BAL and makes it seem more like a generic person-driven decision making system to modify the project.
A) Voting was done on discord, not by BAL tokens. So that undermines the governance of BAL and makes it seem more like a generic person-driven decision making system to modify the project.
13)
B) There was significant momentum for retroactively eliminating the BAL distributions. It's hard to know how to define DeFi, but "a system where peple can't arbitrarily change rules to take stuff you already have" is a pretty good definition.
B) There was significant momentum for retroactively eliminating the BAL distributions. It's hard to know how to define DeFi, but "a system where peple can't arbitrarily change rules to take stuff you already have" is a pretty good definition.
14)
C) There was never any vote, nor was there discussion of who should have been informed or voting (if a vote even was the right way to do it!)
D) Discussion was really toxic for a while
C) There was never any vote, nor was there discussion of who should have been informed or voting (if a vote even was the right way to do it!)
D) Discussion was really toxic for a while
15) On the other hand, there were a bunch of good things:
A) The project leaders consistently advocated for reasonable paths (enable a whitelist, don't make it retrospective)
B) Leaders acted quickly and were responsive to the community
A) The project leaders consistently advocated for reasonable paths (enable a whitelist, don't make it retrospective)
B) Leaders acted quickly and were responsive to the community
16)
C) In the end, the conclusion was reasonable:
D) Whitelisting will be enacted, which I think is good for the project
E) Eventually discussion became productive, civil, and understanding
C) In the end, the conclusion was reasonable:
D) Whitelisting will be enacted, which I think is good for the project
E) Eventually discussion became productive, civil, and understanding
17) In the end, I guess my takeaways are:
A) DeFi is hard!!! If you don't do things exactly right the first time it's really hard to enact changes without betraying the spirit of DeFi.
B) It's important to know what your plan will be when disputes arise
A) DeFi is hard!!! If you don't do things exactly right the first time it's really hard to enact changes without betraying the spirit of DeFi.
B) It's important to know what your plan will be when disputes arise
