Conversation

1) Some thoughts on

/ $BAL:

18

87

234

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.

1

2

27

3) Very few of these were trading, but most were earning BAL. Any ERC20 token with pricing from

worked. So, earlier today about $100m of USDTHEDGE and USDTBEAR showed up:

3

3

17

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?

2

13

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?

2

23

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!

5

16

81

7) If you want to keep it, though, whitelisting is reasonable: it cuts off the stupidest cases while keeping a lot of the value.

1

16

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.

3

3

35

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.

11:03 PM · Jun 24, 2020Twitter Web App

Replying to

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.

1

2

25

11) So how did this play out? Well, over on the discord, people debated. discord.com/channels/63846 It was messy.

1

2

17

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.

2

5

44

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.

1

2

29

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

1

18

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

1

1

22

16) C) In the end, the conclusion was reasonable: twitter.com/BalancerLabs/s D) Whitelisting will be enacted, which I think is good for the project E) Eventually discussion became productive, civil, and understanding

Quote Tweet

According to community consensus reached over at our Discord: The current week will be divided in 2 parts for mining distribution, separated by block 10331138. Before: everything as expected. After: a whitelist of eligible tokens will be implemented until the end of the week.

Show this thread

1

1

22

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

9

5

60

Replying to

and

I see permissionlessness as applying to user-and-developer access. Anyone can access, and build upon, these financial services from anywhere in the world, and that makes them permissionless.

1

3

Replying to

and

I see permissionlessness as less having to do w/ "code is law" - these systems must evolve, and do so legitimately, as

aimed to do to address the edge case you raised. Access = permissionless; governance = time-consistent in the ethos it uses to evolve the system

2

1

4

Show replies