You are right. Sorry, this one slipped off my radar, although it’s veeeery important…
Just like you said - buybacks can’t (or rather shouldn’t - even if more and more BTC hit the T4 buy side!) last forever.
Let me digest it and provide you with my feedback.
Asking as a novice, does this look reasonable to you?
I skimmed through abstract and conclusions to understand if that is something we can use. The paper is theoretical and at least 4years old. They wrote …
We plan to experiment with our liquidity-sensitive market
maker with real traders to see how they react and how the
market performs.
Now and I am very curious to read a follow up study with a real case scenario and implementation. If by any chance you can find anything, that would be useful.
Thanks mark, will take a look, although it seems that smart-markets are directed to Stablecoins, and NSR is not one of them.
"The hedging strategy that we describe is similar to some monetary policy schemes in that a sort of “central bank” performs open market operations.[37] Possible open market operations for a stablecoin mechanism include conducting “burn auctions” or setting interest rates on deposits"
It sounds like Nu but no mention of nubits.
There is one mention of schillingcoin.
The paper was published in jul.
At that time, nubits was already the most successful stable coin.
Why don t they mention nubits?
Generally papers do not mention nubits.
Is it taboo to talk about Nu?
So the only thing stopping this project is the price feed?
What do we want the bots to do in the event of a buyback? Isn’t that a conflict of interest for Nu?
Do we want the bots to act in unison, or should bots be buying from other bots within our own network?
Nope, not at all…
We don’t have a consensus on the strategy yet.
Who provides liquidity?
What is the pricing strategy?
Who builds the software?
Should we use NBT and NSR grants?
What’s the first step?
The client and the buyback software are different because the buyback wants to push the price while the client wants to stabilize it.
Both versions have the same basic inputs:
Buy liquidity / Sell liquidity in account and in orders
24hour volume weighted nsr price in BTC from bter, polo and cryptsy.
Local order book / within 50% of most recent price.
Both bots will also have a set of tunable parameters. The client bot will have something akin to ‘spread’ or ‘bull/bear’ or other strategic trading parameters. The buyback version will have waves of orders that push the price up. I’d like to talk about that one more in depth.
We want a bot that approaches the current price quickly, hesitates there, then pushes upward against walls. I’m gonna just spitball:
Bot works in 6 hour cycles with small liquidity (can ramp up over time if desired). First hour, place buy order 5% below price feed. Each hour increase price by 1%. If the order makes it through, the ending price is now the first hour’s price for the next cycle. Otherwise, the order must have been filled. In that case, for the next cycle use whatever is less, 5% less than the fill price or 5% less than the price feed.
Thanks for replying … I like the interaction you imagined between buybacks and liquidity provider’s bot.
However, I don’t think we should plan for two bots. Buybacks will be over at some point, right? They have limited budget and limited lifetime. I strongly believe we should have a strategy of liquidity provision that works regardless of buybacks.
For a start, I must disagree with the starting assumptions
Depends on the market. In a seller’s market, placing buy orders below market price, brings the price down. For NSR, we had a seller illiquid market for months, so having a buy floor simply gave confidence to investors who started buying again. Moreover the price is trending up also because NSR are burned and supply shrinks.
So generally speaking, buybacks aim should acquire cheap NSR, not push price, at least in the current buyback schema.
mmm maybe not.
Stabilise around what? If I understand correctly you propose it tracks an arbitrary value read from a pricefeed. I expect the pricefeed to change its target, therefore moving the center price up or down.
That sounds an interesting approach … But it would inflate price without upper bounds. It’s gonna be expensive to maintain, depending on how aggressive you go.
Another note: I think you are again making a distinction between “last” price and “client” price … That is valid only for the beginning of the cycle. For marketmakers, that’s the same thing… If you are providing liquidity, it means that your orders are going to be filled very often, therefore “last” will be exactly “client” price.
Am I missing something?
This setup was indeed specifically about buybacks rather than market makers. It was intended to be aggressive as only buy funds are presumed, though it approaches the ‘price’ from the lower side, allowing for the market to push down on the buybacks, as you say finding the lowest price. The biggest distinction between price feed and client price is that price feed is a volume weighted average over multiple exchanges. It is assumed the buybacks will happen on multiple exchanges and the price feed will be the way they ‘talk’ to each other (because like you said the market maker is often the last price).
As for the ‘client’, that software can be complicated long term and I haven’t solved that problem yet. But it seems like that’s the solution you’re more interested in, so I’ll think about that some more.
1 Like
After having read all posts in this thread I came to the conclusion that this is no topic where I can really contribute. If I can think of something that is worth posting it, you’ll find it here 
1 Like
So, as far as I can tell all we need here is wrappers for nsr on bter and polo as well as price feeds for both of them. The final price feed can be a 24-hour small volume-weighted average of bter and polo. We can use nubot and program in whatever we want. Would be useful for both buybacks and individual provision.
I’d estimate the cost for wrappers and feeds around 1 kNBT, but I don’t really know anything.
I still disagree with this part: it is a self-referenced price, isn’t it? You set it the first time based on 24 hours average, and after that - since you set the walls - the price its likely to be bounded between those walls for another 24 hours (or whatever x amounts of time you set).
So this is a price fixing scheme, not a market maker. If we’d start it today, it will take yesterday’s market price and keep it forever, without taking into account any other variable.
I’m not sure I understand. Say the price today is $0.01. I set at $0.015 and $0.005. Someone buys at $0.015 and that’s the only trade all day. Now, I will set at $0.02 and $0.01. As you can see the price can move around just fine.
I’m thinking 24-hour SMA for the buyback bot and EMA for the market maker.
Oh, well a market maker with a 150% spread is pointless, doesnt give any depth . moreover in your example the price swings between sell and buy . i d consider this an illiquid market .
‘Pointless’ is extreme. Check the nsr order books, we would kill for some liquidity on there, even at giant spreads. Given the tools, people will start lowering spreads themselves and getting competitive.
Anyway, the question is more related to buyback bots. Why is this not an entirely reasonable (and cheap) way to automate buybacks?
I didn’t say this is not. Indeed this would be one of the cheapest options to automate buybacks. Still we could improve a bit more the initial idea of simply taking 24h average price as reference, and we should discuss the size of bid/ask spread.
What I am saying this doesn’t fully fall within the scope that drove me to open this thread. So maybe open a new thread “Automating buybacks” , so we can dive deep into its details, pass a motion and go for it. It will likely cost much less than 1K and I can do it in one weekend , so definitely worth it
1 Like
50% might not really be necessary. Let’s consider the following hypothetical feed.
For certain values of N and W, we look back N seconds and compute the 99th-percentile price change (in terms of %), Delta1, over W seconds. The largest 1 percent of price changes are treated as outliers; we instead compute a geometric mean for this 1 percent, which is to be Delta2. The price changes may be weighted by volume, especially for the outliers.
N can be large enough to span months or years. W should be set as the time period it takes to settle a trade or update the price (which is rather important for BCE). The spread % is then calculated as Delta1 + 0.01 * Delta 2.
Empirical data is needed to see if this results in desirable spread values, but my impression on past NSR movements is that, even for NSR/NBT and W = 60 and large N the final spread might not be much higher than 10%.
It’s hard to say whether this feed is robust to manipulation, but it’s probably conservative enough for high volume pairs like BTC/USD.