[Passed] Grant to provide liquidity using NuBot on hitBTC - the begin of modPuddle

As some of the readers here are aware, I’ve been playing with NuBot.
The intention was to get familiar with it, because I intend to provide liquidity on hitBTC, but don’t want to rely on ALPs or existing MLPs to do the job.

I’m not ready to start with the LP, the wrapper for hitBTC is still missing, some trouble with hitBTC’s API seems to slow down cancelling order, but I feel it’s about time to discuss the details for the operation.
I have two people trusting me with money for the operation, because they find the expected reward (they know about the risks in detail!) interesting and neither want to do that on their own via ALP nor by NuLagoon.
HitBTC’s past (late 2014, early 2015) shows some problems, but it seems to be fine at the moment.

The formatting of the motion draft leans on examples here: [Draft] Periodic 90 Day ALP Grant Competition, but as it’s about something different, I thought it’d be ok to differ in some areas.

I have some trouble figuring out the compensation. As I’m going to run this on my RaspberryPi at a private internet access, I’m not sure about the reliability until I’ve tried it over some time.

I don’t know how to track the provided liquidity in a verifiable way as it’s not recorded in the blockchain.

getliquiditydetails B

is able to show the current liquidity, but it’s not possible to check that for a given time frame.
An ongoing recording of the liquidityinfo would be required for that.
So I’m a bit lost.

How can I prove that I provided the liquidity that I promised to provide?
If I can only provide the liquidity 90% of the time (because of RaspberryPi or internet access issues), only 90% of the compensation would be earned.
You could even think about a contractual penalty for providing less than x% of the time the promised liquidity, but truth be told: I’d refrain from following this idea in that case…
Still I’d like to have a fair calculation of the compensation.

Anyway, I think we can start discussing about the parameters of the LP.
I’m going to move it to the “Custodial Grant Proposal” section once it’s ready for voting.
Would be glad to have your input.

following a recommendation from @mhps

made me think twice about the compensation.

I intend to follow the recommendation in big parts. I’m not going to raise the former 9% per 30 days compensation to 16%, but to 15% instead.
This rate will likely fall if other LPs offer service for cheaper conditions or hitBTC proves reliable.

Trying to provide extra service for the extra money I offer to keep the liquidity up even if the price of BTC changes to rollercoaster mode as this is something Nu is in desperate need of.
I think the fairest approach is to provide liquidity first and get the compensation afterwards (similar to how NuLagoon is handled).

I don’t know how to treat service outages due to hassle with my RaspberryPi, NuBot, the internet access, or hitBTC itself.
Plus I’m not sure about the restoration time in case my RaspberryPi kills another SD card while I’m not near it.
Which leads me to the question: can two NuBots be run with identical configuration in a kind of failover mode?

I want to guarantee a stable wall, but don’t intend to take the risk caused by trouble with necessary resources alone - especially if not being able to influence it (like hitBTC down).
I hope anybody has some idea how to reflect that in the motion.

One remark about hitBTC: if hitBTC defaults, loses the funds during the 30 days or simply stops the service for whatever reason the compensation until that point of time will need to be paid by Nu - a small price compared to the February exchange defaults…

The operation contract changed from “motion” to “grant”.
To be able to start the liquidity providing soon and broadcast liquidity information, I need a custodial address.
The compensation for the operation will be a matter of a later grant.

Important note
For those who don’t want to look in the previous versions: the total compensation I request for the 30 days of liquidity providing is 225 NBT - which is due after I have provided the service.
I could have entered that at “Total Grant:”, but didn’t want to confuse voters with two different amounts requested.

Proposal RIPEMD160 hash: 42a734a54664547d04f4cb5c292f30730451a55d

=##=##=##=##=##=## Custodian Hash starts with this line ##=##=##=##=##=##=

Custodial Address: BBZ4h88BwYCyE9q268LoArps6eodq9PDGH
Amount Requested: 1 NBT

Operator: @masterOfDisaster
Type: NuBot
Exchange: hitbtc.com
Pair: BTC/NBT (at least I hope they flip it until the LP operation begins)
Strategy: Moderate Peg
Spread After Fees: 1%
Liquidity volume: 1,500 NBT
Bid target volume: 50%
Ask target volume: 50%
Balancing bid/ask: at least each Wednesday
Balancing goal: each side between 45% and 55% of volume (preferred balancing method: seeded auctions)
Bid Reward Rate: 0.5%/day (not paid in advance)
Ask Reward Rate: 0.5%/day (not paid in advance)
Duration: 30 days
Operator Fee: 0 NBT
Total Grant: 1 NBT
Present Term Requested Funds: 1 NBT

=##=##=##=##=##=## Custodian Hash ends with this line ##=##=##=##=##=##=

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

modPuddle Term1 - 2015-10-12 to 2015-11-11
modPuddle Term2 - 2015-11-11 to 2015-12-11
modPuddle Term3 - 2015-12-12 to 2016-01-11


As discussions go on about fixing pool compensation to force pool providers to cut costs, we can consider to bring it one step further. For example, you’re going to be the only one paid by Nu to provide liquidity on the exchange, then you have exactly one job: to make sure there are buy/sell walls of sufficient depth within the right spreads.

You can do whatever you want to provide that liquidity; you can advertise, put enough tier 2 liquidity, make sure there’s enough funds, do some trading, encourage NBT users to put ask/bid walls themselves, contract out the work etc. You can be a facilitator or put up the stake yourself. Then the only metrics would be the size of the walls, the spread, and the historical persistence. These are likely the only metrics we use to judge a pool at the moment, apart from some vague albeit important component of “potential risks yet to be known”.

So we can consider to just observe the walls and decide the payment, and think about what are the feasible compensation schemes etc… I believe at some point liquidity provision will evolve to this level, so it might be worth considering now.

I caution liquidity providing on new exchanges here

How do you balance? You don’t control the fund and the interest rates are fixed.

I think I’m doing that albeit in a different way.
For me running NuBot there and having an independent solution is what I’m striving for first.

Your warning has been heard. It will be considered.

I do control the funds. This is not another ALP, but a NuBot being run at hitBTC.
The funds are in an exchange account I control.
In need of balancing funds (BTC or NBT) are withdrawn to other exchanges (with sufficient tier 1 bid walls) traded there and put back to bring NBT/BTC on an even level.
I don’t know how to treat situations in which BTC price plummets, because it will make it hard to balance and affects the liquidity volume as well, but this shouldn’t stop us here.

Oh. It was not obvious until it was obvious :wink:

1 Like

That’s why I often struggle when choosing a proper forum name.
I’m torn between “masterOfDisaster” and “CaptainNotSoObvious”.
Most times I pick the first, but I think both suit me well :wink:

What concerns me with forced rebalancing is possible aggrevated losses in a bear market (which had probably caused the imbalance in the first place) as discussed here and a few posts that followed -

On the contrary - in a bear market people will try to get rid of BTC (assuming they’ll drop even further).
So the LPs end up with lots of BTC and little NBT.
Rebalancing mitigates the effects of falling BTC prices, because after the rebalancing more NBT will be in the pockets of the LPs.
This is for sure only true if the LPs can trade the BTC for NSR (at an exchange) and the NSR for NBT (at Nu).
Without being able to sell NSR (the former BTC) to Nu and buy NBT there, it will leave another LP holding the baby…

There is for sure some arbitrage loss when rebalancing. However, it is assumed that Nu is paying plenty to LPs to cover such losses. As far as volatility is concerned, I would argue that instituting random buys and sells at random times should be statistically equivalent to making no buys or sells other than the txn fee, assuming liquidity, no potential gaming vectors, and a longterm stable bitcoin price. A long term bear trend is a risk for operation on the btc pool in general, it is not exacerbated by rebalancing.

Rebalancing in a bear market means selling the btc at current low prices. If the price action reverses there is no chance to ride on an appreciating btc price for those sold btcs.

I decided to write my thoughts about your last post in another thread as I want to focus on the motion draft for hitBTC.

And I want to note that I thought about your warning about providing liquidity at new exchanges which lead to adjusting the compensation.
This makes the liquidity operation look expensive, but on the other hand I don’t ask for an operator fee and include a part about continuity of liquidity.

edit: I’ve made a rework of the draft in some important parts and recommend to inspect it closely. It’s very different from the last draft - I hope for the better.
Your feedback is highly appreciated.

1 Like

No interest in having a liquidity operation on hitBTC (independent from ALP operations)?
Or are there just no more questions to be answered and I can turn from [Draft] to [Voting]?

to be ohnest, i prefer the ALP so that i can participate my self :wink:

Yet NSR holders might be interested in buying liquidity at a new exchange :wink:

1 Like

I am in favour. Would you mind expanding the

Amount Requested: 225 NBT

How does it compare to other grants? How did you come up with such number?

I’m not saying that is either too much or insufficient, just would like to know what’s the reasoning being it.

The amount is considering that hitBTC is a new exchange and I follow @mhps’ recommendation to put a premium for that on top.
The 225 NBT per month for a liquidity of 1,500 NBT are rather expensive (15%), but I charge no operator fee.
I expect future terms to be cheaper, because

  • fixed cost models will allow no to determine the compensation rate required by the market
  • good experience with hitBTC will lower the premium

I also suggest you to contact @HitBTC to get a premium txfee

We offer 0% trade commission for new currencies. Of course it works for NuBots :wink:


I think you should charge an operator’s fee. The higher premium is the cost of Nushare holders’ determination to expand pegging operations to a relatively young exchange, if the grant motion passes. The total cost is not a big sum, which is a result of a modest target appropriate for a starter pool on a new exchange.

I would like to see a point to point comparison with the other MLP, Nulagoon.