Automating Buybacks

NuBits Automated Trading
#1

The concept is to give NuBot a simple wrapper and price feed for NSR/BTC pairs on Bter and Poloniex. Then, once a day, the bot can take a 24-hour simple moving average and apply a prefactor based on the day of the week. This should satisfy this motion:

We can proceed to talk about the proper parameters of the bot, and people can even take it and run it themselves using their own funds once they understand how it works. However, the goal of this thread is to discover a solution for automating buybacks such that we can more easily deal with this:

6 Likes
Modify NuBot to manage buybacks
Modify NuBot to manage buybacks
[Passed] Grant for NSR buyback and PPC reserve operation calculator
#2

Cool idea - using the tools we have

#3

It would already be a good step forward if the price feed is manual input.

#4

A solution in which elected representatives (FLOT like) is operating NuBots on NSR/BTC pairs could not only automate buybacks to some degree.
Funding an account of an NSR NuBot operator makes NuBot put the received funds in orders.
So this can already be automated to some degree.
Price discovery is a topic I have little knowledge in, but am aware that it’s crucial for automated buybacks.

Operating NuBots to automate buybacks could be used to hit two birds with one stone and have some market making for as well.
The NuBots would run in dual side mode and could be used to sell NSR as well as to buy NSR.
The spread would be significantly above the spread of NBT/BTC.
Nu can make money and increase the market depth of NSR.

I believe the low market depth and immense spread is limiting the adoption of NSR as tradeable asset.

Such a dual side NSR/BTC bot could close that spread while still keeping it big enough to allow Nu generating revenue from it.

The NSR funds could be spread across several people to limit the risk of technical malfunctions (NuBot crashes while orders are placed, network connection issues etc.).

If collateral is required, NSR NuBot operators will for sure request some compensation (a share of the trading volume or revenue, a monthly compensation etc.).

Just running a NuBot on behalf of Nu makes little effort.
I know that from running the two NBT gateways (entry, exit) on Poloniex.

If a tester for an NSR dual side NuBot is required, I gladly offer my support.

1 Like
#5

@desrever is this enough info to get a dev estimate so we can start the drafting process? I’d love to try getting this operational before we need a new executor.

1 Like
#6

Have a modified nubot to do it with funds injected by FLOT.

#7

We’d need a wrapper and a price feed. Wrapper, w/e, but price feed. Does the custodian enter it manually? If so, what’s the benefit to using nubot?

#8

the pricing automation. even if not automated, the bot operator and fund handler/account owner who has collateral requirements can be different persons, good for security.

#9

Cool. I’m thinking we do a 24-hour sma from both polo and bter (volume weighted average) and input the 70,80,90,100% as like hardcode or whatever. Friday can be manual. The separation of bot operator/API and withdrawals/account owner is really interesting too, though it’ll probably add to the total overall cost.

So, we would need to write wrappers for bter and polo and do that price feed stuff. How much are we willing to put up for bounty?

#10

automation also helps to make it distributed. we just need several honest account owners to run the bot in their accounts and hand back NSRs on friday.

I suspect a bot that can do buy backs bit by bit (or with other strategies unsuitable for a human) can buy back at far better prices. The bot can pay for the bounty quite possibly.

#11

then we would need some nubots like MoD’s gateways for NBT. In that way FLOT can sent BTCs and receive NSR :wink:
I guess nubot can send back NSR automatically to T4 if configured to do so?

#12

That idea is as simple as ingenious!
It should go to a separate thread not to get lost in this thread.
It would help with NSR buybacks as well as with NSR sales (e.g. to fill T4 buy side, or in general: remove NBT from circulation).

I don’t think so.
Plus it would require API credentials which are allowed to withdraw funds. I would not want to use that kind of credentials…

1 Like
#13

[Draft discussion] - A market-maker to end NSR illiquidity
Just for reference

3 Likes
#14

Right. I was thinking this bot could be a marketmaker if equipted with a feed.

Maybe this part of discussion should be moved there? Could @CoinGame do it? Starting from –

#15

It still requires the trust of one person to keep the bot running. And, a FLOT team member can determine the buyback time simply by being the last person to sign a transfer. Those are both points of weakness that exist with a sole executor, except with the added cost of development.

Automating things feels like the right thing to do, but the expense of doing so wouldn’t generate a lot of incremental benefit for shareholders. Let’s keep things simple and find one trusted executor who can use their judgement to maximize the number of shares purchased each week.

1 Like
#16

I agree that finding a execution person to do it manually is the least resistance path and we should do it now. But it’s like assigning sell-side custodians to distribute shareholders-paid liquidity in Nu’s early days. For the long term selling NSR following the NBT liquid provision scheme is still the way to go, I think.

#17

I was not only thinking of the current situation with centralized exchanges when being intrigued by that idea.
I was rather thinking of B&C Exchange as well!

I’m close to getting a headache trying to imagine it and I’m not sure whether it’s possible on a technical level, but…

If funds are sent to a BCE deposit address that is essentially a multisig address which the reputed signers control. There’s an address on BCE as well that allows initializing actions like withdrawing the funds, putting them on orders, etc.
As far as I understand, these BCE addresses can be multisig as well.
It would be awesome to support different levels of signers for different actions.
That could allow a scheme in which withdrawing funds requires 3 of 5 while putting funds into orders requires only 1 of 5.
The FLOT could have funds in addresses which any FLOT member could use to operate a NuBot with them while 3 of the members would be required to withdraw them.

#19

I was letting this thread running on its own before intervening, to make sure requirements are clear to everybody (they are not :wink: ) . I am in favour of designing and implementing a software solution for automating NSR buybacks.

So, can we start together drafting a design document? Let’s write a list of user stories … I’ll make a new post reply and make it a “wiki” so everybody can edit it

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

1 Like
#20

Feel free to edit this post, is a wiki. Make sure you add edit reason at the bottom if you change something.

Draft design of Nu-BuybackBot ( aka NBB) and Nu-BuybackPricefeed (aka NBP)

NBB+NBP is intended as a software system to automate NSR buybacks on the available markets. It requires one or more operator to configure and keep it running. It should be easy to configure and run, open source, and should use a publicly known pricing policy.

##NBP

####NBP-01
NBP is a service that requires 24/7 uptime and should have high availability and reliability since it provides a core service to the Nu network. (4)

####NBP-02
NBP should expose an entry point that accepts HTTP get request and reply with a price, expressed in BTC with 8 decimal digits precision. It should also provide a timestamp at which the value has been refreshed.

####NBP-03
NBP should implement some DoS protection mechanism.

####NBP-04
The price is calculated in weekly cycles (1) as required by current buyback strategy :

  1. an initial cycle price (ICP) is computed every Sunday, 23:59 PM UTC, using this formula based on market price : . (5)
  2. every Mondays 23:59 PM UTC the price is updated : ICP + xx%
  3. every Tuesdays 23:59 PM UTC the price is updated : ICP + yy%
  4. every Wednesday 23:59 PM UTC the price is updated : ICP + zz%
  5. The price stays the same from 4—>till next cycle

####NBP-05

The pricefeed operators should be able to configure the parameters for the cycle. (6)

##NBB
####NBB-01
An elected operator can download the source code and binary. The main scope of the bot is to place limit buy orders for NSR below market price.

####NBB-02
The bot will work on available markets with an active NSR/BTC market. At the time of this writing being Poloniex and BTER.

####NBB-03
The bot operator will manually fund his exchange account with BTC, create an API key pair, configure the bot and run it.

####NBB-04
The bot needs to connect to an external price feed that is active 24/7 . The price will be verified locally and used to determine the limit buy price (2).

####NBB-05
The bot operator needs to manually withdraw funds from his account as defined by his operational details.

####NBB-06
As soon as NBB obtained and verified a buy price the whole BTC balance will be used to enter a single limit buy order (3).

####NBB-07
If the price feed is not available or considered unreliable, the bot should stop and do nothing.

####NBB-08
The NBB operator can configure a list of IP addresses of nodes of price feeds. feed1, feed2, feedN. A minimum number of x nodes is required to work …

####NBB-09
Every two hours the bot checks active orders and … ?

###Discussion
(1) Do we want the bot to operate on weekly cycles or continuously ?
(2) This way, the operator doesn’t have any control on pricing. Ana a price feed requires a price-feed operator and maintainer.
(3) Are you sure you want a single buy order? Maybe its better to distribute it, parametric orderbooks are already built so its no brainer… Is a matter of defining which book type and the replenish-wall strategy (how often, under which conditions?)
(4)To realize this condition this service should either require an operator, some redundancy and decent infrastructure, or it can be distributed and replicated across multiple volunteer nodes, similarly to the DNS seed server.
(5) please enter some proposals for the formula used to compute ICP
(6) if we deploy the feeds across a network of volunteer nodes, how can we know the config parameters are the same for all nodes
(7) …

1 Like
#21

Thanks for the draft.

####NBP-04
The price is calculated in weekly cycles

There is no reason to run it in a weekly cycle even the buy back amount is determined once a week. The price can sweep at a faster or even randomized pace to make it harder to game.

  1. an initial cycle price (ICP) is computed every Sunday, 23:59 PM UTC, using this formula based on market price : 12-hour Moving Average . (5)

.

####NBB-03
The bot operator will create an API key pair, configure the bot and run it. The bot operator will either manually fund his exchange account with BTC, or let external bodies, such as FLOT, fund it.

.

####NBB-06
As soon as NBB obtained and verified a buy price the whole BTC balance will be used to enter a single limit buy order

It could sell a random fraction of the total amount.

So coupled with unpredictable selling cycle, if you see a good price you should buy immediately since the price won’t last and if you see the same price next time, you don’t know how much will be on sale.

We are programming a bot. We can afford to be complicated, at least after an initial simple-strategy trial period as given in the original draft.

1 Like