Continuing the discussion from Current Liquidity:

Current Liquidity Current Liquidity I think it would be good to raise a motion about the dual-side

TL;DR

Have a custodian run a dual side NuBot on Poloniex with Nu funds to create a buffer and support the peg.

This is a band-aid solution until e.g. T3 custodians and fixed cost compensation have eased the liquidity situation and improved the reliability of the peg.

Poloniex as the exchange with biggest NBT trading volume is very important for customers evaluating the peg.

/TL;DR

Assessment / Reasoning

This motion draft is trying to solve a problem Nu currently faces:

there’s too much friction in the flow between tiers, especially T4 and the lower tiers.

That caused the activation of the Poloniex gateways several times.

More than once the liquidity situation first required funding the sell side gateway and after a swing, funding the buy side gateway - or vice versa.

It may be that the amount of money that was injected in the gateway was too much and caused that swing. One might think that if too much funds would have been put into the gateway, they wouldn’t have been traded.

The spread is high enough to put the funds rarely in the front line of the order book.

But as NuBot was configured in “gateway mode”, all proceeds were siphoned from the market (the intention of the gateway) and not available for future trades.

So having a dual side NuBot might ease the situation.

Road map

In the very near future T3 custodians, LPs getting familiar with NuLagoon Tube, improved incentives for liquidity provision with fixed cost (or variations of it) should help mitigating liquidity issues.

Need for action now

Until then the FLOT is overburdened with the needs to keep an eye on the liquidity (especially at Poloniex) and act very fast if a side is in danger to run dry.

I’m not saying that it’s very much effort to craft a tx using Cointoolkit and sign it.

Kudos to @ttutdxh; without Cointoolkit I dare say the peg would have been in severe danger several times in the last weeks!

But NSR holders might underestimate the burden to have the FLOT be effectively responsibe for real-time activity.

That is not what the FLOT was created for. It will burn out FLOT members and it’s not reliable. If the FLOT is only a few hours too late, damage might be done.

Solution

Create a buffer on Poloniex in addition to the liquidity that is “contracted by paying liquidity providers” and introduce a kind of liquidity providing custodian again.

Have a sufficient buffer (e.g. 10,000 USD equivalent) on Poloniex to have an increased resiliency for swings in NBT demand.

Create a new Poloniex account to operate a dual side NuBot.

Constraints and drawbacks

Funds (e.g. 10,000 USD equivalent) on exchange create a risk due to exchange default, theft, etc.

As the used Poloniex account is using 2FA and the API credentials aren’t allowed to withdraw funds, the main risks seem to be:

exchange default

the custodian steals the funds

These risks can hardly be calculated. The costs (total risk * funds at stake) can only be estimated.

They are higher as with gateways as funds stay for an extended time on the exchange.

Last words

I won’t provide a collateral as I don’t intend to make money with the dual side gateway.

The only reason for adding a compensation clause is that I don’t want to establish this dual side NuBot as permanent solution.

Other solutions that need to come will cost money.

If this solution is for free, NSR holders make the wrong choice.

I’m unhappy about doing it anyway, but see no other chance to arrive at a future, more sound, lower friction scheme of liquidity provision without losing the peg on one of the most important exchanges on the way to it.

Motion RIPEMD160 hash: 6a2fdd44881be1d64ee5c03517525b52f607342c

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=

Intro

@masterOfDisaster - below called “the operator” - will run a NuBot on Poloniex. The liquidity is being broadcast using a custodial address to allow tracking the liquidity situation of the bot.

The operator promises to send all funds to a FLOT multisig address upon request of a majority of the FLOT members or by a passed NSR holder motion.



Availability

The operator offers no guarantee for anything - neither the availability of NuBot nor the operator’s avialability nor malfunctions of NuBot nor outages of the internet access nor the funds on the exchange as the operator doesn’t intend to earn money with this operation.



Begin of operation

Operation begins on the day NuBot puts the first deposit of funds by FLOT on the order book.

In case NuBot is on standby (not running) and the FLOT deposits funds, operation will begin on the day NuBot gets started and puts orders on the book.



End of operation

Operation is ceased by request of withdrawal of all funds or if operator sends all funds to FLOT multisig address(es). NuBot is put on standby afterwards.



Modes of withdrawal

NSR holders can request withdrawal by motion.

FLOT members can request withdrawal to a FLOT multisig address for which they are signer by posting in the forum.

The number of FLOT members to request a deposit to a FLOT multisig address equals the number of FLOT members to execute transactions from this address.

The operator may withdraw funds to a FLOT multisig address by discretion.



Compensation scheme

The operator charges no fee for this operation for the first 45 days of operation.

If the operation hasn’t been ceased by request of either NSR or FLOT after those 45 days passed, a fee of daily 15 NBT applies for the next 30 days, increasing 5 NBT per day each subsequent 30 days.

The fee will be taken from funds on the exchange account if sufficient funds are available or raised by grant.

If the operation is ceased by FLOT or NSR holder request and started again afterwards, this grace period won’t be applied again.



Reasoning for compensation scheme

Having no fee at all for this operation is expected to hinder the creation of more sound solutions (e.g. T3 custodians who need to charge a fee).

So it mustn’t stay free forever and on the contrary has a high daily compensation.

On the other hand this motion isn’t meant to skin Nu and therefore has an extended grace period.



Premature activation

If the FLOT deposits funds at the operator’s exchange account, they will be used by the operator as if this motion already passed.





=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

Verify. Use everything between and including the <motionhash></motionhash> tags.

I was thinking about including the deposit addresses to the motion, but as they might change (I don’t know why, but who knows) I rather put them here:

BTC deposit address of Poloniex account: 1BEFcbS5VmSh4MbB7xZMtKjtQ4aqKF2YkL

NBT deposit address of Poloniex account: BTZMCt5LvAnVCtPxpmh9dtnUDp5M9W3KKy

I have not yet a dedicated custodial address for this operation. If this motion is put up for voting, I’ll request a custodial address (grant with value 1).

For a premature start of the operation, I consider using “BETwD8nSjtj9ADSvej2na34xmsMYwPRymv”, which belongs to the NBT entry gateway, if there are no objections.

The part of the config I’m going to use for the dual side NuBot that deals with the order placement is:

“wallchangeThreshold”: 0.1,

“mainfeed”:“blockchain”,

“backupfeeds”: [“bitfinex”, “bitstamp”], “bookDisabletier2”: true, “bookSellwall”: 3000.0,

“bookSellOffset”: 0.007,

“bookSellInterval”: 0.002,

“bookSellMaxVolumeCumulative” : 6000,

“bookSellType”: “lin”,

“bookSellSteepness”: “low”, “bookBuywall”: 3000.0,

“bookBuyOffset”: 0.007,

“bookBuyInterval”: 0.02,

“bookBuyMaxVolumeCumulative” : 6000,

“bookBuyType”: “lin”,

“bookBuySteepness”: “low”

Any comments on that?

An explanation of the config paramenters can be found here: https://bitbucket.org/JordanLeePeershares/nubottrading/src/7dea551e0794f102b8bc904268e4c42e6e48b064/docs/SETUP.md?at=master