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.
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.
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
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