Decentralized liquidity without counterparty risk not yet implemented

creon 2015-01-26 10:26:10 UTC #9

You can a use future markets to transform the risk into a calculable cost. Jordan described it here:

So in the end its mostly the risk that the exchange gets hacked and of course the missing opportunity that should be the basis for the reward calculation.

JordanLee 2015-01-29 20:45:33 UTC #10

There was a thread started here a few days ago (that I can’t easily locate) that discussed the idea of using pools for liquidity provision. I think this is a great business idea that is likely to be profitable and very helpful to the network. While it means you have a pool operator centralizing the control of funds (which isn’t as ideal as each liquidity provider controlling their own funds) it is a huge iterative improvement over what Jamie and KTm are doing. It doesn’t use shareholder funds that present systemic risk, and presumably a number of these pools would develop, providing some degree of decentralization. It is a way that very small players can provide liquidity and earn a return on their NuBits, all without having to run NuBot or face the hassle of hedging the BTC used.

Some basic software is needed to facilitate deposits, withdrawals and accounting. It is likely that off the shelf exchange software could be used. It is also possible for an existing exchange such as Bitspark, Bter, Excoin, Bitcoin.co.id or CCEDK to offer pooled liquidity provision. In the interest of fairness, this could be done in a cross exchange manner, so that liquidity providers don’t have the advantage of seeing the contents of exchange accounts. For instance, Bitspark could use its deposit, withdrawal and accounting infrastructure to run a liquidity pool on Excoin.

One way a pool could get paid for liquidity provision is rather than agreeing to provide a specific quantity of liquidity as has been done in the past, simply ask that the pool be paid a certain percent for each NuBit of liquidity brought per unit of time: 0.25% for each 24 hour period liquidity is provided, for example. Shareholders approve a contract for a 90 day or 120 day period, and then every two weeks or every month a custodial grant is passed to pay for liquidity actually provided in accordance with the contract.

I would love to see liquidity pools developed. Please let me know if I can assist you in doing so. It is a priority for me.

The passage of LPC proposals such as those offered by @muchogusto and @cryptog will indicate to entrepreneurs that there is a profitable market for liquidity and that it is a market worth competing in.

cryptog 2015-01-30 09:42:08 UTC #11

You must be alluding to that: We need much more liquidity providers....Let us think of strategies

I feel the future of Nu depends on that.

peerchemist 2015-01-30 09:42:58 UTC #12

I am glad you like this idea. In my opinion this functionality should be included in NuBot. NuBot could just memorize inputs (in BTC) and make withdrawals based on insterest rate. Also this should be faster and less error prone than human (custodian).

creon 2015-01-31 03:42:27 UTC #13

I like the idea of separating the liquidity provider from the bot operator and I think this can be accomplished only by using the blockchain.
For every incoming transaction, the full amount + a interest gets repaid to the sending address once a certain number of blocks has passed. The interest rate scales (exponentially) from the full amount to zero around a funding target. Therefore everyone can independently calculate the current interest from the blockchain.

I quickly implemented the idea in Python to show you what I mean (not much tested, may have bugs):

github.com

verc/nubot-backer/blob/master/backer.py

#! /usr/bin/env python

import json
import jsonrpc
import sys, os
from math import exp, log

_blockspan = 1440 # about one day
_maxinterest = 0.02 # 2% interest per _blockspan
_targetfunds = 10.0 # amount of NBT we want to have allocated
_address = 'BCuSTodiAnAddR3SSXXXX' # custodian grant address
_nuconfig = '%s/.nu/nu.conf'%os.getenv("HOME") # path to nu.conf
_passphrase = "" # possibly passphrase (unsafe)
_fee = 0.01 # fixed fee of 0.01 NBT

# calculates the payout for the amount provided at the balance of the corresponding block
def payout(balance, amount):
  # integrate over decreasing logistic sigmoid centered at _targetfunds with a maximum value of _maxinterest
  return _maxinterest * (amount - (log(exp(_targetfunds) + exp(balance + amount)) - log(exp(_targetfunds) + exp(balance))))

This file has been truncated. show original

Different interest rates for different time spans can easily be implemented by using multiple addresses. I like the solution because it is simple, robust, and externally verifiable at any time. Would love to read everyone’s opinion on that.

[Passed] Motion to end LPC operations of KTm, Jamie and NSR sales of Jordan

[Passed] Motion to create the first liquidity pool: The Nu Lagoon

Joe 2015-02-10 00:16:23 UTC #14

I was wondering about this the other day. When issuing currency to be used for projects it makes far better sense to give a stable currency to gaurantee funding until the project is completed. How does issuing nushares ultimately differ from someone selling those shares for nubits in order to store the value?

cryptog 2015-02-10 01:19:36 UTC #15

Right now as a reward you can ask for both assets: NSRs or NBTs.
It is just that it is more complicated to ask for NSRs since it is not yet at protocol level (you need to trust JL to give you the shares once your mission is completed) but the automatic rewarding process is being implemented right now.

Joe 2015-02-10 02:11:03 UTC #16

Thanks for the info. As always i am pleased with the game plan going forward and hopefully we will have quick implementation going forward as well.

JordanLee 2015-03-01 01:44:27 UTC #17

When our liquidity operations are 100% conducted by self funded LPCs (or liquidity pools where users provide funds like what @henry is forming), we will be able to say liquidity operations are counterparty risk free, from the perspective of the network.

While what constitutes decentralized liquidity is a matter of degrees, my short term goal is to ensure that no single LPC provides more than 25% of total buy side liquidity, and that there be at least six LPCs providing at least 5,000 NBT in buy support each.

Once liquidity operations become counterparty risk free and decentralized according tho the above definitions, I will unpin this topic. In the meantime, I will periodically articulate our progress toward liquidity operations being counterparty risk free and decentralized.

Here is my present assessment of liquidity operations:

Using the getliquidityinfo RPC with B as the parameter, I can see that currently 21.1% of our liquidity is currently being provided by self funded LPCs where the liquidity operation poses no systemic risk or potential loss to the network.

There are six LPCs currently operating, although two LPCs have trivial funds at work (< 150 NBT). One LPC, @jmiller, provides 47% of all liquidity and more than 90% of all buy side liquidity. Having <5,000 NBT buy side liquidity being provided by all LPCs besides @jmiller is quite hazardous to the peg. @jmiller, @henry and @KTm: will you work together to balance the buy side liquidity among yourselves please?

mhps 2015-03-01 09:03:00 UTC #18

Some questions:

Are these for NBT/Crypto pairs or also including NBT/USD ? NBT/USD has little exchange rate risk.

The 5000 NBT number seems arbitrary. We have seen that some exchanges don’t have more than a couple of hundred NBT traded everyday on average. Crpto activities in general has ups and downs. There is little need to risk many times liquidity when it is obvious that there isn’t all that much trading. So I think tier 1+2 should be adjusted maybe on a 10-day moving average of buy-side (or buy+sell) liquidity basis or on a10-day MA of daily volume basis (the calculation can be made by the bot).
Or give this speific decision to the LPCs to make and only ask the LPCs to follow general guide lines in the beginning. After a while when this new mode of operation goes well, more specific requirement can be added based on experiences.

JordanLee 2015-03-07 06:46:53 UTC #19

Time for another evaluation of our liquidity operations:

Currently, 74.8% of liquidity is being provided by self funded LPCs that present no systemic counterparty risk (this excludes liquidity being reported from KTm, which is shown erroneously right now). This is a huge improvement over last week’s 21.1%. The change is due more to KTm and jmiller reducing liquidity than it is due to an increase in activity from new self funded LPCs (though that was a factor). This means total liquidity is very low at ~69,000 for both walls (once again excluding the erroneous KTm figure). More LPC proposals and shareholder approval of those proposals is needed. I’m hopeful the Nu Lagoon will improve things quickly once the motion paying for their operation is passed. Given that NuBits volume has been in the low 10,000’s recently, this low liquidity is not a serious problem. However, providing more liquidity should positively impact NuBit trade volume.

The buy walls of @henry and @creon are quite unbalanced, in opposite directions. Would the two of you consider balancing your walls together, please?

There are four LPCs providing liquidity, with 45% of all liquidity being provided by a single LPC. Quite a bit of improvement is needed in the area of decentralization.

creon 2015-03-07 15:39:51 UTC #20

The only thing that is holding be back doing this is that it would violate my grant proposal. If the liquidity balance generally is considered as something that can be changed later on then I can transform half of my funds into NBT.

erasmospunk 2015-03-31 10:58:51 UTC #21

Could you please review this proposal if it fits the criteria of decentralized liquidity. @JordanLee

Nagalim 2015-05-12 23:19:20 UTC #22

Can we unpin this please?

JordanLee 2015-05-13 02:36:39 UTC #23

Let’s take a look at our progress toward providing decentralized liquidity without counterparty risk (from the point of view of the network).

Using the getliquidityinfo RPC with a B parameter, I can see that there is 98,760 of tier 1 liquidity. 72,672 (73.6%) of this is coming from Jamie Miller and Kiara Tamm, who are using shareholder funds. So, only 26.4% of tier 1 liquidity is free of systemic counterparty risk. That isn’t an improvement in raw numbers.

However, we can see very important progress forming that hasn’t quite manifested in the current numbers. Nu Pool appears on track to dramatically expand its operation to provide 70,000 in liquidity. Liquid Bits and NuPond have just started operations and are providing 3000 and 500 in liquidity respectively. I expect the amount provided by Liquid Bits to rise quickly. NuPond and Liquid Bits are both likely to expand operations in a few weeks. Jamie and KTm will be burning all shareholder funds in a few weeks except what is held hostage at CCEDK and BTER.

There is a reasonable chance that in 30 days we will see liquidity offered using shareholder funds drop to less than 30,000 while counterparty risk free liquidity rises to around 90,000 from our 4 pools. Most of this will be provided by Nu Pool, but in 60 to 90 days hopefully it will become more balanced among our pools.

So, if we continue to nurture the efforts already well underway, we will have liquidity that is both decentralized and free of systemic counterparty risk in 60 to 90 days.

Sentinelrv 2015-05-13 03:49:19 UTC #24

@JordanLee, I was wondering if you had read this thread. It began about something else and then turned into a discussion about how to continuously pay for liquidity pool interest in the future. Right now we’re just printing NuBits to fund the pools, but can that go on forever? Please take some time to look it over if you haven’t read it yet. I was interested in hearing your opinion about it. For example, @Sabreiib talks about how we’re bleeding money out of the system through the 7.5% interest for pools…

JordanLee 2015-07-04 21:50:04 UTC #25

The burn by jmiller means the undesirable practice of using shareholder funds for liquidity has been completely abandoned. Now our liquidity operations are free of counterparty risk (from the perspective of the network and shareholders) and it is decentralized, with a number of pool operators and many users of each pool. It was a monumental task that is now complete. Thank you to the dozens of people who played a role in making NuBit liquidity decentralized and free of counterparty risk.

The exchange defaults that occurred in February can never happen again as a result. Those were difficult for our network, but the network and design was so robust that it was able to maintain the peg even under remarkably unfortunate circumstances (the chances of so many simultaneous defaults are quite low) combined with a core part of the design not being implemented and operational yet. This speaks volumes for the reliability of our network and the peg. We have reason to be proud of what we have built. The facts that this can never happen again and the network remained stable throughout the crisis means that there is good reason to be confident in the future of the peg and the future of the network.

The only element that remains centralized is tier 4 liquidity. While this can be split into the custody of multiple entities now, it would still represent a reserve that is subject to a variety of risks. We can end it entirely by using B&C Exchange to lock down liquidity for a time period specified in a liquidity provider’s contract. While it won’t be implemented in the first version of B&C Exchange, it is possible to mark certain deposits as locked for liquidity provision for a configurable time period. Reputed signers could automatically place liquidity orders with these funds for the locked period. This means that if we had liquidity providers lock $100,000 there for six months, we could guarantee $100,000 in liquidity for the six month period. Liquidity providers would not be able to remove their funds in the event that they would like to for whatever reason. This increases the reliability of the peg, as liquidity providers might otherwise be tempted to remove liquidity at just the time it is most needed.

This is how I envision implementing our design goal of zero reserves.

Current Liquidity

JordanLee 2015-07-04 21:50:13 UTC #26

cryptog 2015-07-05 03:25:27 UTC #27

So it is another way to use time locking (besides releasing user funds in case signers get non responsive) where some liquidity providers (could be reputed signers or not) would agree to lock their liquidity for a specific amount time in exchange for a reward specified into a motion agreed upon by shareholders?

crypto_coiner 2015-07-05 05:39:19 UTC #28

What’s the use of B&Cex then?