Finalized evolution of liquidity operations

I am looking forward for the upcoming technical clarifications.

But before that, personally, I would also like to receive a clarification of what I wrote in post#46 . It basically boils down to :

Do we really want NuBits to be an intermediary coin? Why?

And can be expanded to several subquestions : Is being an intermediary coin part of our strategy to become widely adopted as a stable currency? Is there any sign that being used as an intermediary will drive adoption of NuBits in other contexts?
What are the benefits for shareholders?
Do we have clear signs from the market?
Should we update our whitepaper? Our marketing targets, slogans, and campaigns?
“The world first stable intermediary currency”

Should we change our description of “What can you do with nubits?” ?

I believe that this change - forgetting technical challenges - deserves more attention, and a proper discussion followed by a motion.

I will chip in what I think.

I have been concerned that Nubits is running on fractional reserve and there doesn’t seem to be an obvious or quick solution to it. I do realize that fractional reserve is an effcient way to use capital. The crux is where to draw the line between being so conservative that Nu economy is choked off and being so adventurous that we ended up having a catastrophic loss of the peg.

I don’t know where to draw the line yet but I think I see how to increase the safety margine, to broaden the line into a buffer zone. The trick is to create a demand for nubits such that its users don’t really care whether there is localized or short term doubt of the peg. Such use already exists. Bitcoin fluctuates greatly but people still consider it safe as a medium of exchange because it is often “good enough”. This utility of bitcoin creates a constant demand of it. People don’t rush to the exchanges to cash out bitcoin just because there is a couple of percent drop of BTC/USD. This fraction of bitcoin that is effectively permanently in users hand is what I consider safety margin.

Nubits could have this safety margin, just miles broader. The period of bitcoin’s being considered “good enough”, as mentioned above, is inversely proportional to how stable bitcoin is. If nubits is widely used as a intermediary currency in commerce, then I expect many users will hold onto it regardless where short term price might drift. I will go as far claiming people will use it even the peg will slowly drift away from at strict 1:1. This part of “nubits with velocity” is the coushion of fractional reserve. (I will post an brief review of a paper that discussed money with velocity)

Therefore I see pushing nubits to be an intermediary coin on cryptocurrecny exchanges to be of great strategic importance for Nu’s security.

3 Likes

I agree if it is being under control. The beauty with cryptos is that we are compelled to make everything transparent in order to keep the integrity and the trust into the trustless decentralized system.
So I think having a real time tool that lets shareholders and users know about the quantity of nubits in circulation, the quantity of nubits parked, the reserves and the buy liquidity on every NBT/* pair is very important so that we know to which extent Nu is “leveraged”.

I agree on that. I mean it is just a matter of trust. And the trust can absolutely exist under a fractional regime as long as the degree of the fractional aspect is “reasonable”, I believe.
Look at FIAT money. It is probably highly leveraged but still most people use it all the time.
We need to define and measure what is “reasonable” though.

2 Likes

FYI : we are building it and it’s high priority. Front end is mostly complete

2 Likes

Yes @Ben was mentioning about that the other day.

To say that we want NuBits to be an intermediary currency is probably a redundant statement. The word “currency” is misused quite a bit in our industry so I felt additional clarification was helpful. In reality, all currencies are intermediary currencies. Specifically, currencies are never bought to be used directly. Rather, they are instruments used to solve the coincidence of wants problem. For example, I’m a software developer that would like to sell my labor for food at the grocery. They can’t use my labor so I’m out of luck, unless I use an intermediary currency. I sell my labor for currency and the grocery is happy to take the currency. This is exactly what I am proposing when I say NuBits ought to be the thing people buy when they want to trade Dogecoin for Peercoin. It is an instrument that allows them to solve the problem that most people selling Peercoin don’t want to receive Dogecoin. We aren’t in a position to become a currency to the average grocer at this time. We must gain that position in the cryptoasset trading markets first. So, suggesting that NuBits become an intermediary currency is really just saying it should be a proper currency.

Yes. We have to create that role for NuBits in cryptoasset trading markets first, then we will have the liquidity and credibility we need to drive acceptance in other contexts.

Yes. Bitcoin is an example. Liquidity, infrastructure, services and trust must all be built to see wider adoption. Becoming the currency used in cryptoasset trading is the most practical way to do these things at this stage.

If we achieved the goal of becoming the currency used for cryptoasset trading, it would be difficult to imagine a scenario where the market cap of NuShares would be less than a billion NuBits.

US dollars and BTC are currently being used for this purpose, and it is a big market. It is clear there is a real chance NuBits can penetrate and dominate this market. The reason is that it is a much better currency than the US dollar or BTC. Ever try transferring 50,000 USD from Bitfinex to BTC-e? It takes a long time, funds are subject to freezing and it is expensive. Compared with BTC, we can provide deeper liquidity and stable value, which are valuable attributes in this scenario.

I don’t think so. It isn’t a shift in the vision of what NuBits will become, it is just additional details regarding how it will get there.

12 Likes

Thank you for taking the time to answering my questions. I will welcome the 2015 liquidity challenge with open arms.

4 Likes

As will I. Thank you Jordan for answering these questions. You have a grand vision for NuBits and taking the time to understand the path that lies ahead of us and setting clear achievable goals will only aid in giving us the motivation to carry out this vision.

Here is broad outline of how we can implement the proposed changes to NuBot:

First of all, if the motion passes desrever and I should hire an additional developer for NuBot. Woolly_Sammoth has little time available due to another full time job and other obligations, so I would like to have him continue to implement exchange APIs as he has been doing. Then we will have two other developers. One should work on implementing the transfer of funds between tier 1 and tier 2. The other can be begin working on order book matching code. After the funds flow between tier 1 and tier 2, the flow between tier 2 and tier 3 can be implemented, probably by the same developer that worked on tier 1 and 2.

I will say a little about how order book matching will work. Take the example of the Bter BTC/NBT market, which you will see will be far superior in liquidity to the Bter BTC/USD market. We will make the order books of as many exchanges as possible available on the BTC/NBT Bter market. For instance, Bitfinex, Bitstamp and BTC-e. The Bter BTC/NBT market mirrors the combined order books of Bitfinex, Bitstamp and BTC-e. The entire depth of the order books is not replicated, only the top portion. How big that portion is depends on how much of a risk the double fill exploit proves to be, where orders are simultaneously filled by a bot at Bter and say Bitstamp by someone who is not an LPC.Even if this is employed extensively, the cost can be kept quite small by using a small amount of tier 1 liquidity. Losses could be made up with custodial grants or widened spreads. The merged order book on Bter will have slightly worse pricing in one sense than Bitstamp, Bitfinex and BTC-e. This is because two transaction fees must be included in the spread, one for Bter and one for, say, Bitfinex. I expect we can negotiate fee discounts to minimize the adverse effect of this. There is even a real chance we can be transaction fee free because what we are doing will bring so much volume to exchanges we support. In another sense, our pricing will be better because you will get the best price offered at the three exchanges for the full depth of your order. Let’s look at an example. Say I want to buy 10 BTC. Here are the buy BTC order books, presuming a special, negotiated transaction fee of 0.1% on all exchanges for our LPCs:

Bitstamp
Price, USD, BTC
310, 620, 2
311, 933, 3
313, 1252, 4
315, 630, 2

Bitfinex
Price, USD, BTC
314, 942, 3
316, 632, 2
317, 317, 1
319, 1595, 5

BTC-e
Price, USD, BTC
308, 924, 3
310, 620, 2
312, 624, 2
313, 1252, 4

Bter
Price, NBT, BTC, Mirrored Exchange
308.62, 925.85, 3, BTC-e
310.62, 621.24, 2, Bitstamp
310.62, 621.24, 2, BTC-e
311.62, 934.87, 3, Bitstamp
312.62, 625.25, 2, BTC-e
313.63, 1254.50, 4, Bitstamp
313.63, 1254.50, 4, BTC-e
314.63, 943.88, 3, Bitfinex
315.63, 631.26, 2, Bitstamp
316.63, 633.26, 2, Bitfinex
317.63, 317.63, 1, Bitfinex
319.64, 1598.19, 5, Bitfinex

The cost to purchase 10 BTC at each exchange, including a 0.2% transaction fee the buyer pays is:

Bitstamp: 3126.24 USD
Bitfinex: 3173.33 USD
BTC-e: 3113.21 USD
Bter: 3109.41 NBT

So, you pay less for your cryptoassets if you buy them with NBT instead of USD. And, you don’t have to use Bter. Bitstamp, Bitfinex and BTC-e would each have their own blended BTC/NBT order books as well that offer similar pricing as Bter, if the exchange supports NBT and we support the exchange.

Let’s examine how this works from the liquidity provider custodian perspective. Dan is an LPC mirroring the BTC-e order book. He opens accounts at BTC-e and ideally, all other supported exchanges, which we will say are CCEDK and Bter. Dan deposits an equal amount of funds in BTC-e, Bter and CCEDK. In each case half the deposit is BTC with the other half being USD for BTC-e and NBT for CCEDK and Bter. NuBot places buy and sell walls on CCEDK and Bter to mirror the BTC-e walls on the BTC/USD pair. It updates the CCEDK and Bter walls as the BTC-e wall changes. When one of his orders on either CCEDK or Bter is filled, NuBot executes a comparable market order on BTC-e immediately. Just as is the case now, from time to time these accounts may need to be rebalanced. The question of whether that can be done without losing funds other than transaction fees is complex with many variables. The question should be answered empirically, by tracking the actual costs of rebalancing. Similar issues exist with rebalancing costs now, although some of the variables are different. It is possible that an offset value will need to be used (for example, perhaps the BTC-e account will be repeatedly drained of BTC and it cannot be replenished at cost, on average, so BTC-e liquidity is offered at other exchanges at a 1% higher price than normal). This means NuBot will need to track losses and gains, including for rebalancing. This type of tracking is needed regardless of whether order book mirroring is implemented.

Another LPC mirrors Bitfinex at CCEDK and Bter. He does not need to concern himself with Dan’s orders placed on CCEDK and Bter. Limited, or small, collisions will occur when the BTC sell price at Bitfinex is at or below the BTC-e buy BTC price. Only the top price in combined order book will collide. This is not a problem, and it is self correcting when mirrored orders are placed at BTC-e and Bitfinex. With this design, collisions are actually profitable trades in the sense that custodians get to trade at a price more favourable than the price of the market they are mirroring. This design does not require coordination of LPC walls to prevent collisions, offering significant simplification over the way NuBot currently operates.

Edit: While the above example uses BTC, I expect similar mirroring would be done with other coins, such as Litecoin, Dogecoin, Ripples, etc. While in the example above the goal is to compete against USD, an LTC/NBT market would compete against LTC/USD and LTC/BTC pairs simultaneously by mirroring both types of trading pairs.

4 Likes

Sounds like a kind of automated arbitrage without moving the coins. Given the amounts which are likely involved it requires very well tested and hardened bots. Mistakes or failures will be expensive. But I probably state the obvious. Can I assume we invest in a proper simulation/test environment or will it be small scale testing in production to mitigate these risks?

1 Like

Probably the most practical way to finalize testing will be on a small scale in production, as you suggest. The LPCs will be independent enough of one another that it will be practical to have them on different versions of NuBot.

If you run such bots on NBT/BTC and you see an arbitrage opportunity of BTC/USD between two of the exchanges where you have bots, do you do arbitrage between the two exchanges and level the prices in BTC/USD, or not?

If you don’t, and since you actively maintain the same order book of NBT/BTC on the two exchanges, will you attract arbitrageurs on each of the exchanges to run arbitrage between your NBT/BTC bot and BTC/USD locally, which is cheaper and low risk to do? Aren’t your bots used by these arbitrageurs to move funds between the exchanges for their profits? Won’t your multi-exchange bots end up becoming a multi-exchange price equalizer to all pairs among these exchanges? Since it costs to move funds around, aren’t you footing the bill for such non-trivial trades? Since you are paying for it anyway, won’t you run bots to do arbitrage between exchanges on pairs, such as BTC/USD above, that have a close “affinity” to your NBT/BTC, as well?

2 Likes

Thanks for your reply. Had the time to think a bit more about this and I like to share some concerns.

Having had exposure to high availability software and hardware environments in the distant past, I suggest that we ensure that developers and QA are aware of at least the strategies mentioned here: http://www.embedded.com/design/prototyping-and-development/4024434/Design-Patterns-for-High-Availability

Fault injection, tolerance scenarios, checkpoints and forward error recovery should be standard in their vocabulary.

I emphasize this as I like your proposal to move forward, but also see increased risks removing our software development focus from the blockchain to more classic areas (the bots) without these assurances. The assurances and protections the blockchain offers about logging and transactions are most likely not envisaged in the proposed development. We have already seen that a lot of effort is required to provide transparency and clarity on the current bots workings, reporting and logging. Blockchain technology would provide this natively. This potential weakness of the bots technology, if not addressed properly, might concern shareholders especially when the inevitable faults occur and cannot be played back to learn from.

I would like to see that the design of your proposal would support transparency in logging from day one, ideally based on blockchain technology. Transparency might not need to be real-time publication of transactions but the ability to access secure and irrefutable logs should be available with or without blockchain technology.

Please consider this post as positive feedback and engagement and possibly this has been already thought off and my concerns can be taken away. I see the hiring of another developer in this area as a potential recognition that these risks needs to be mitigated and require additional effort.

4 Likes

I recommend that we build the NuBot equivalent of a Simian Army.

2 Likes

Thanks @JordanLee for taking the time to expand on the enhanced liquidity operation with some figures. It has cleared up most of the concerns I had around the reasons for doing so when such a large change to the technical workings of NuBot is required to achieve it.
My remaining concerns are less to do with NuBot itself although they do echo @Cybnate s concerns above.
When working with NuBot, and previously with personal trading bots, the weakest point has always been the APIs of the Exchanges. While they perform admirably 99% of the time, the 1% when they fail (or communication with them fails) is when the market has most movement, which is just when you need them most. I’m less concerned about NuBot instances not being highly available, more the APIs, which are, unfortunately, out of our hands.
Although knowing this to be the case puts us on a good footing, a lot of thought needs to be paid to the best ways of reacting to such an API failure when it could impact the mirroring and overall liquidity provision so badly.
The actual implementation of reading orders, doing a calculation and placing a similar order somewhere else should be fairly straight forward. It’ll take time but the code to interact with the exchanges in that way is already there in NuBot, it’s just the controlling logic that needs a tweak. I’d agree that an extra developer for NuBot would be a good thing. As mentioned, I don’t always have the spare time to devote as I would like due to other commitments.
I do think though that before that, there should be a wider discussion among shareholders around the controlling logic of NuBot and how to react to the various scenarios that have historically played out in the real world. I’m constantly astounded by the level of trading knowledge displayed on this forum and feel that it’s a hugely valuable resource that needs to be tapped for the Nu trading bot.

My other concern is around the number of Custodians we have versus the number of markets we will potentially have to mirror. I’m comfortable with the idea of a single custodian potentially handling the mirroring of an entire exchange on a second, with all the pairs that entails. I’m also comfortable with the idea of a single custodian potentially running multiple instances of NuBot to cope with that. There comes a point though where we hit a natural limit both in terms of what a single custodian should be expected to handle for the return they get and in what a single NuBot instance can handle with mirroring.
I’m not really expecting an answer to this as we will only find out what those limits are by trying out various combinations in the real world and seeing what happens. I write it here as a concern merely because that’s what I started thinking about when I read Jordan’s example. At least it’s now a known unknown!

In conclusion - I’m sold on this idea now. I think this is a logical evolution for liquidity provision to take and, now that my concerns around it have been allayed, I’m excited by the technical challenges it presents. I’m going to crack on with implementing as many APIs as I can find.

6 Likes

Could someone explain how we end up with “using NBT cheaper than using USD”?
I fail to understand the calculations.

In any case, it seems that in the overall vision of @JordanLee, besides monetary policies, developing and maintaining NuBot than can deal with multiple pairs over different exchanges is a crucial element for maintaining the peg, therefore for NuBit.
At the same time, it seems that NuBot would get more and more complex as well over time.

So I agree with @cybnate on the fact that providing max transparency of how NuBot works is of utter importance not only for shareholders but also for users.

It is easy to be tempted by the dark side of greed and try to take advantage of a centralized system that you have control over. Have a look at what has been found out with MtGox. It looks that Mark created fake trades all along, to build up more than 600k bitcoins in his own pocket.

The best way to make NuBot transparent is to put it somewhat on a blockckain-technology, I believe but is it realistically easy to implement? If the answer is yes, what would be the cost to shareholders?

Besides, if this motion passes, by when mirroring is intended to be implemented?

EDIT: I have understood now how the computations are made.

1 Like

I am analysing the proposed approach and taking some time to thinking this through.

We can definitely use an additional developer time for implementing the “move funds across tiers” part while I work on the mirroring part.

It is very interesting reading about all the different point of views and expertise in the community to form a more holistic vision.
This is why I am also interested in reading more about the concerns expressed by @mhps, and also listening to the opinions of more experienced traders ( including @Chronos and @pennybreaker :wink: ) .

While we will do our best to incorporate collective wisdom into the bot, I have a strong feeling that one of the best way to achieve good results in this domain is empirically.

Once again I want to express a wish : while 3-4 persons, including myself, are working on this experiment, I would like to see the rest of the community trying to explore other domains where a digital 1$ currency comes to hand. In case our experiment fails, we should have many other open branches to work on. I invite everybody to read Jordan’s last post about vision and mentally replace “intermediate liquid currency” with some of the many spaces we could attack : crowdfunding, remittance, merchants, crypto-equity, betting … Sorry for sounding redundant .

1 Like

This motion passed 1 day ago.
@JordanLee Hope you will address some of the concerns though.

1 Like

It is definitively one of the huge application domains of NBT, I guess once we have established a deep liquidity across exchanges.

I submitted some proposals to improve NuBot to the developers. I believe there is a lot of room for improvement it will be interesting to see how it evolves.

3 Likes