[EPIC] Safer Staking

[trentmc]

What / TODOs

• [x] TE to design a solution GSlide in GFolder. [Trent, Alex]
• [x] POC in smart contract Contracts-255 [Alex]
• [ ] 1MM bot. In line with TE design / POC above
• [ ] Vesting

Motivations

As of Ocean V3, here's what's happening:

1. Publisher publishes a dataset. To not have to put in too much OCEAN stake for their initial price, they pick the minimum # DTs to publish
2. Stakers come along and stake. It drives up the price. Low supply, high demand -> high price.
3. There's no GUI affordance for the publisher to add more DT. They could do it in library, smart contract, or etherscan. But they hesitate to because they are worried about it looking like "dumping" on the market (DT minting attack).

A good example is the dialogue below between Trent & Manan (20201103). The data asset price has gone super high, and the publisher is reluctant to add more DT.

We've seen this problem before. It's the question of how do you release a crypto token to the market, to get the token into many hands that want it, to get a decent price, to get decent liquidity, etc. This is the realm of fund raising of any token project, with tools like vesting, ICOs, IEOs and more. This is what we call an "IDO". The main Ocean Market blog post goes into great detail about these in section "C2. Initial Data Offerings (IDOs)", and references to a lot of thinking on token distributions (including vesting, ICOs, etc).

The comments hold many proposals for near-term & med-term solutions. (We'd want realistic estimates for the most promising solutions. And probably a tech spike.)

Trent-Manan dialogue from 20201103

Manan: I just had a call with Thalus.ai (our another partner). There's a scammer who copied their dataset metadata and published another asset. On the other side, Thalus just created pool for their dataset and it skyrocketed in terms of value. They are now 'concerned' about skyrocketed price because no one will buy their datasets at this price and were thinking to move to 'Fixed' price datasets. I managed to convey them that team is working on these issues actively and solutions are being implemented as we speak. Also, asked them to tweet their dataset and we will help retweet and signal legitimacy. btw they are waiting for us to take action against the imposter who published their dataset with their email and website link in metadata. (edited)

Manan: yes, but that will happen when someone purchases DT and use them (thats how data provider gets hold of DT apart from ones in the pool)

Trent: Yes. But that is limited by the #DT they've minted and put into the pool in the first place. So price won't go down that much.

Trent: Have you talked to Thalus about adding more DT steadily over time, to bring price down? Also, profitable for them.

Trent: However, if they mint more and put those into the pool, it could help a lot.

Manan: yes but that creates liquidity dilution for other stakers and that creates trust issues. Looks bad for Ocean if they do this since we promoted them

Trent: Yes it does create liquidity dilution for other stakers. That's fine! The negatives won't be an issue if they set expectations that they are going to do so, and give a DT vesting schedule. It leads to a much healthier token in the long run. For example, they say "for more DT liquidity and to get prices more manageable for people who wish to consume this dataset, we plan to add in an extra x DT each day for the next 7 days. We start tomorrow". This solves the liquidity problem and the high-price problem. It gives stakers a chance to pull out their stake if they wish, before the liquidity additions. It is good for stakers in the long run because it can lead to more people actually buying the dataset to consume (stakers will get tx fees). This has a parallel to regular crypto tokens which have vesting cycles. (In the future we can make fancier versions of this easier. But for now it can be done manually.) In fact this is a practice we should seriously consider advocating for all the people adding datasets.

Manan (from slack): for a more sophisticated approach, an off-chain voting process can be implemented (most likely as a seperate app) that allows all stackholders in the pool to participate and vote on proposal by pool owner. This breeds transparency and inclusion

[trentmc]

Trent: Re idea: "Create a GUI affordance where publisher can mint another 10% of their supply on a given day, but no more. Only restrict in GUI level, not below. Why: a lightweight way to do vesting."

Manan: This can work for trusted parties like Swash (where we can ensure that they will share the minted tokens to other stakers proportionally to avoid their dilution). But this works even bad for scammer pools. And there are many. Basically with this approach we will give them weapons to game the system even more.

Trent: good point

[innopreneur]

Easiest way I see to fix this for new and existing system is this - • Fork/Add "snapshot" gov for off-chain voting as a seperate app (let's call it MintVote) • MintVote will allow pool owner/minter to create a quick proposal to get voting from stakers on 'Yay' or 'Nay' for minting ensuring no LP stake dilution. • MintVote will have a very minimalist smart contract on the backend with one function to mint exact amount of tokens that was proposed in successful proposal (which minter can trigger) and then distribute newly minted tokens proportionately to LP ensuring no liquidity dilution.

[innopreneur]

From @ssallam

• create a fixedRateExchange along side the Pool
• limit adding liquidity to adding both tokens at the same time (similar to Uniswap)
• LP has to buy from fixedrateexchange to provide Liquidity of both Ocean and DT
• FixedRateExchange charges fee on swap, the fee gets routed the pool

[trentmc]

Approach: Vesting Schedule // Liquidity Bootstrapping

UX perspective:

In minting step, give the user the choice of a vesting schedule to mint, such as the following.

• mint 20% of tokens now, and the rest over 2 months w/ linear vesting.
• mint 50% of tokens now, and the rest over 1 month w/ linear vesting
• mint 100% of tokens now.

When it vests / mints, the tokens go directly into the pool.

This is side-by-side with the user making a choice on # OCEAN to deposit, and initial token price. The longer the vesting schedule, the higher the initial price can be (for same # OCEAN). Vesting is on-chain.

Theory perspective

It's 'Liquidity Bootstrapping' in the lingo of Balancer. Main idea: vest the token over time directly into the pool, in a pre-defined schedule. The weight on the DT can shift over time to eventually be 50-50. This gives you ICO-ish properties combined with immediate exchange. Link

How to implement the vesting / minting schedule

(must be on-chain to mitigate scams)

• Use a Balancer-ish artifact: one of Balancer Configurable Rights Pools (spring 2020), the code PERP used (fall 2020), Balancer V2 (2021)
• Superfluid - Vesting via an ERC20 token that has built-in vesting. Then, balance becomes an equation rather than a stored variable. (Super cool)
• Sablier - Vesting on an ERC20 token. Less sci-fi but potentially useful.

[trentmc]

Approach: Bonding Curve

Use a Bonding curve as the primary market, ie where DT first enters the public market.

Then, the Balancer Pool becomes a secondary market (and a very convenient one).

This is specified in detail here: Zenhub epic

[trentmc]

https://twitter.com/infected_whale/status/1323718336858017792

[infected-whale]

That above comment was purely to address rug pulling and fair distribution of author funds.

However also need to address the large increase in price when people add liqudity:

"Only problem is that it doesnt solve the big price increase when a data set is provided liqudity by non authors. I do think the price increase needs to be set on a bonding curve in relation to how much the data set is actually being bought and holders are rewarded a larger portion of the transaction fee instead"

[infected-whale]

An elastic curve so it reacts to both directions (buying/selling of data)

[trentmc]

Thanks for the comments @infected-whale !

An elastic curve so it reacts to both directions (buying/selling of data)

This is what bonding curves do:) See comment above, and related links.

[infected-whale]

Yeh they look like great ideas ! :)

[trentmc]

Here's a great description of the issue by @0x3bfc:

What we have is unfair DT control/distribution (at the very beginning, publisher controls all the DTs, then LPs stake which creates a huge divergence in the token price compared to ocean price). This will never end as long as publishers control the pool and DT.

Comparing to normal token pairs (e.g Dai-ocean), they are distributed over bigger number of LPs, so the rug pull not that easy as in our case.

Only whales can do this because they have bigger chance to disrupt the market.

The more fairness distribution of DT (less power by publisher), the less probability of getting faster toward rug pull.

Simply in any Defi balancer or uniswap pool, both token pairs are normally/uniform distributed over population. In our case, for DT is a Degenerate distribution but ocean has a Semi-Normal distribution.

[trentmc]

Text from Intro to Ocean Market blog

C2. Initial Data Offerings (IDOs)

In an IDO, people can launch data assets using the same tools used for launches of other token assets. This section gives a brief history of past tools, and relates it to data.

2017 brought a wave of Initial Coin Offerings (ICOs), for better and for worse. Great efforts were put into designing mechanics of token distributions, and marketing and legals. A lot was learned from that era, and the learning has continued.

Here are some innovations since then. Vitalik Buterin suggested DAICOs, which leverages DAO technology to decentralize fundraising effort. Fabian Vogelsteller suggested reversible ICOs (rICOs), which gave investors the ability to pull their funds out, to minimize their risk.

Binance and other CEXes offer Initial Exchange Offerings (IEOs) which hold a fixed-price token sale, followed immediately by trading on the exchange. UMA and others have conducted Initial DEX Offerings using an AMM as the first market for their token. Balancer’s Liquidity Bootstrapping Pools (LBPs) refine this by slowly releasing more of the token over several months while simultaneously increasing its weight in the pool (towards 50–50 liquidity).

Unisocks and Karma DAO each have a combination of bonding curve + AMM. The bonding curve acts as a primary market, where price increases with each token minted. The AMM acts as a secondary market. YFI (and Bitcoin!) had no “offering” at all. Rather, tokens got distributed to users for doing “work” to add value to the system. The philosophy is that coins are “earned, not printed”. Incidentally, this is how the majority of OCEAN are distributed too, curated by OceanDAO.

An Initial Data Offering (IDO) can use any of these techniques. A pragmatic starting point is Initial DEX Offering via an AMM. This is simple, and well-suited to long-tail tokens like datatokens. Ideally, there’s software to make launching such datatokens easy; call it an IDO Launchpad.

Ocean Market makes it easy to publish a datatoken and create a Balancer AMM all at once; therefore Ocean Market is the first IDO Launchpad. We envision other IDO variants in the future, from the list above and new innovations. We hope to see more IDO Launchpads created by ambitious teams.

[trentmc]

Example state-of-the-art token sale, using Balancer "Liquidity Bootstrapping Pool".

"Awesome interface by @apyfinance for their token sale via Balancer LBP (currently live)!" -Tweet by @BalancerLabs

.

More info from APY Finance:

• LBP Guide
• LBP Dashboard
• apy.finance

[trentmc]

Suggestion by @alexcos20. (Here's the Slack thread.)

Another morning, another ideea :) Could be briliant, or dumb.

Problems:

• not enough DT to provide liquidity for pools. How are we going to enforce the mental model with 10 or 20 DT only?
• but more DT -> publisher can do rug pulls.
• initial Ocean staked by publisher - can be a barrier.
• initial DT are value-free, this posing risks
• user added staking moves the price violently (dataset price can spike 5 x in minutes)

Solution:

We always assumed that the publisher must be the owner of DT. but that is not true.

Imagine this flow:

1) Publisher A creates DT with a total cap of 100 milion.But instead of minting them to his address, all DT are sent to OCEAN contract MMX. (MarketMaker X) 2) Publisher A creates a pool, with price 1 DT = 1 OCEAN 3) Publisher A adds 100 OCEAN to the pool 4) MMX adds 100 DT to the pool 5) Now we have a pool with liquidity, but publisher has only 50% shares, he cannot do rug pulls 6) User B stakes 100 OCEAN to the pool 7) MMX adds 100 DT to the pool 8) Users are starting to buy/sell datatoken -> price is changeing -> free price, no longer controller 9) User C stakes 100 OCEAN to the pool 10) MMX adds the corresponding DT to the pool (based on the new price) 11) Users are doing other buy/sell actions -> price is changeing -> free price, no longer controller, but fees are starting to pile up in the pool 12) User B removes his stake (100 OCEAN + some fees) (let's say 20 pool shares) 13) MMX removes 20 pool shares also .. the corresponding DT from the pool .. .. 99) MMX is drained completly(all DT minted has been pushed to the pool, thus giving the complete freedom of the datatoken flow and pricing

How does the publisher makes money? Simple.

After each consume, DT is returned to the publisher. So he can go to the pool and sell that DT.

Facts:

• MMX will push/remove liquidity only when someone is adding/removing Ocean only
• For any other action(add/remove both tokens, swaps, etc) , MMX has no action, will let the market free

Concerns:

• MMX will hold a large pool share. But since it's a public available smart contract, anyone can check that the MMX cannot do rug pulls.

Changes involved:

• only smart contracts (requires new audit, re deployment), minor changes in the libs, no UI changes

@here - thoughts? it's a first cut, we can improve it. (edited) more DT -> publisher can do rug pulls.

---

Bruce: This sounds plausible.

Samer: Yes, this is actually very promising. Discussed it with Alex, almost resolves all of the known issues. The gotcha here is this wont' be a trivial task, needs proper prioritizing, planning, assigning resources, implementation. At least 2 weeks just for the smartcontracts implementation, security Audit, libraries, market updates.

Alex: to build this, I don't think it will require more than 2-3 weeks. the question is: will we provide a migration path from the old datasets/pool? or just let them be and have a warning for them

Samer: i would let them be and clearly flag them

..

Trent:

• Right now our community is staking like crazy. Which is driving price up because it implicitly buys the asset. $100 of OCEAN buys $50 of DT. So, they're implicitly speculating on the DT.
• However, things will change when swap is introduced. Now, the CT has two options: buy the DT directly, or stake. Or three, if you split stake into 'stake with OCEAN' and 'stake with OCEAN+DT'.
• This proposal aims to reduce the effect of staking just OCEAN. However I'm trying to understand now: does it reduce the effect of price going +++ due to speculation? If there's just $100 of OCEAN in the pool initially, speculators could come in and buy the DT and drive its price to 100x that quickly.

Alex: you cannot mitigate that, unless you stake a large amount of Ocean (and DT) at the pool creation time

Trent: This is where tools from ICOs etc come in. E.g. OPF sold a bunch of tokens at a fixed price, to get a bunch of holders initially. Or, even better, do a Dutch auction to auto arrive at the initial price. Here's the challenge: how do we get a bunch of DT into circulation initially, at some reasonable price, before crazy dynamics of price spikes.

Samer: crazy dynamics of price spikes is mainly caused by the single-sided addition of Ocean liquidity, LPs have incentive to take out Ocean if lots of DTs are swapped out (bought)

Trent: Crazy price spikes will also be caused if there are few DTs in the pool and people are buying it in the pool directly.

Trent, Alex, Samer and Ahmed had a call:

• Acknowledged challenge of "how do we get a bunch of DT into circulation initially, without crazy price spikes"
• Discussed two-phase concept: (1) "burn-in period" to address the challenge; then a (2) "equilibrum period" where there's the usual market dynamics.
• "burn-in period" ideas:
  • Adapt Alex's proposal: trading can't happen at first. Just staking at the publisher-set price.
  • Do like a standard ICO: make a fixed # DTs available for a fixed price. Let anyone buy. Challenge: how to set price. Too low -> a whale takes it all (and we don't have good sybil mechanisms). Too high -> no one buys.
  • Dutch auction style ICO. Resolves the issues of fixed-price.

[trentmc]

Another potential tool: "Introducing the Equilibrium Bonding Market", by Fang Gong, Sep 2018. Link

[trentmc]

We can close this, now that we are using "V4 Planning" section in GSlides to track everything. This is done in contracts branch, it will propagate elsewhere.