What is a custodian?

[Nagalim]

I will attempt to capture what exists so far as well as I understand it:

There are two types of custodian, NBT and NSR. Custodians are addresses that are awarded a Unit (NSR or NBT) because NSR holders pass a motion which includes it. Giving a custodian funds actually takes a separate vote, but a motion vote without the subsequent custodial vote would only hurt the share holders. The motion specifies the purpose of these units and their intention.

There is also a burn custodian, OP_Return, which makes the coins unspendable and effectively burns them.

Custodial humans, owners of custodial addresses, are fundamentally people paid by Nu to accomplish some goal. Of course, the main purpose is to maintain the peg, but really any job can be contracted through this system. A marketing custodian, for example, is a possibility. However, given the business model of Nu, there is a clear overarching rule:

A custodian provides some mechanism whereby the peg can be fixed and in this way pays for the units it is given.

With recent votes, decentralized custodianship is clearly a preferred route. What’s more, being shown with the Nupool, we can clearly automate the process such that the process can be completely anonymous and unassociated; a user can prove to Nu that it held a wall up for just 1 minute and they will be credited.

My question comes down to this: what are custodians when Nu makes the market? A custodian gets paid for keeping a peg, such as btc/nbt, by announcing its buy or sell order to be within a number determined by other exchanges. If most traders start acting as Nu custodians because it’s easy, decentralized, and profitable then we need some mechanism to let volume push the custodians. Otherwise we are pegging btc along with nbt.

[Nagalim]

The real reason I bring this up is not actually about the btc/nbt market. It stems from a quote from Jordan Lee:

1. When NuBit demand is low, NuShares will be created and sold while NuBits will be purchased with the proceeds and burned. NuShare supply increases as NuBit supply decreases. This depresses the NuShare price as it supports the NuBit price to the pegged level.

2. When NuBit demand is high, NuBits will be created and sold while NuShares will be purchased with the proceeds and burned. NuBit supply increases as NuShare supply decreases. This inflates the NuShare price as it suppresses the NuBit price to the pegged level.

My issue with this is that there is an intrinsic number here which is the NSR/NBT price. This is an effort to peg the NSR/NBT price in a decentralized manner. The reason I say this is that you plan to sell NSR onto imaginary buyers at the will of a motion. If I were going to buy NSR and I knew someone was being forced to sell I would set my buy orders low. The better way to do this is clearly to just create full on NSR/NBT custodians with decentralized liquidity to provide a clear channel on-exchange between the two markets.
This generates a need for a continuously defined exchange rate for NSR based on market needs. I believe this can be done if we think about it. Perhaps some use of market cap in addition to liquidity and recent trade volumes? Make some kind of a proportional-integral-derivative controller? Isn’t this just the bitshares mechanism?

[GreatScott]

My issue with this is that there is an intrinsic number here which is the NSR/NBT price. This is an effort to peg the NSR/NBT price in a decentralized manner. The reason I say this is that you plan to sell NSR onto imaginary buyers at the will of a motion. If I were going to buy NSR and I knew someone was being forced to sell I would set my buy orders low.

This is a large concern of mine, and I hope @Nagalim’s approach seeking these answers will spark a conversation that helps me better understand it. Thank you.

[Nagalim]

I’m going to go out on a limb and super naively design a system. Disclaimer: I have read next to nothing about bitshares; I feel someone with more knowledge should speak to that.

As a basic beginning assumption, let’s assume that 1 NSR is bought and sold every second on whatever orders are there on an NSR/NBT pair, we can correct this later. Next, assume there is NBT/BTC and NBT/USD volume. We wish to take control of the market such that we reach a target price, defined later. If we take the difference between the target price and most recent price, we receive a number that will correspond to a volume for the resultant custodian order (positive is a buy wall, negative is a sell wall). If we continue to assume that 1 nsr hits both buy and sell walls every second, by having the custodial wall on just one side of the market we can push the price up and down. In reality, the buy and sell volumes are more sporadic but an integral and a differential portion of the algorithm should help to settle the market down, as well as tuning the gains on the feedback loops.

Anyway, the really interesting part is the target price. It should be something like:
P = ($1/P_NBT_BTC) * (P_NSR [V_30min/V_24hr] + P_NSR_24hrAvg*[1-V_30min/V_24hr])

The relevent price of NSR and NBT should be determined using a daily volume weighted average of the most recent trading prices across exchanges, excluding the NSR/NBT markets because the NSR price must be treated as an unknown. If the price deviates more than 1% from the target price, a paid request for decentralized liquidity (like in the Nupool) would be put on auction for only one side of the NSR/NBT market. This would create custodians who risk selling/buying their NSR for/with NBT.

Let me use an example: Everybody loves NBT and the motions just can’t print em fast enough to keep up with demand. The price according to BTC/NBT markets starts trending upward, near $1.1. Janet, a custodian, holds 10 NSR in the Nupool while Billy, a trader, has 5 NBT and wants to sell it for NSR, but at the BTC/NBT and NSR/BTC price points without incurring double fees. The price will slowly be lowered until he snatches it up just above the proper price points. Janet now has a little less than 5 NBT with nothing to do, so she puts it up on the BTC/NBT pair as NBT liquidity, helping to push the price back down to $1.

As an additional mechanism, I would allow automated and semi-instantaneous unit burning at the target price, so NBT can be burned for NSR and NSR can be burned for NBT (paying the network fee each time for each unit, of course). I’ll explain why with another example:

Ray holds 100 NBT and just wants to buy NSR without a care. The price of NBT has been fixed at $1 for a long time now, and he feels confident about the investment. He spikes the price of NSR/NBT, giving a bunch of custodians NBT. Those custodians can then burn their NBT for NSR and return the price to normal after a few confirmations on the network.

I fantasize about adding a term to the price that compares the current price to the fraction of the # of NBT / # of NSR with maybe some stuff about volumes and some square roots sprinkled in, but I think the simpler concept of just leaning on BTC as an outside asset works well. If possible, we should try to lean more on PPC instead of BTC, but practically the structure is already there for BTC.

[Nagalim]

This has been bothering me for a long time, so I’m going to continue ranting, if y’all don’t mind.
For the following discussion I will assume there are 3 types of markets:
NBT/USD, NBT/NSR, NSR/other
as well as 2 types of pegs:
NBT/USD (a fixed peg), NBT/NSR (a floating peg)
And that at any time a custodian may burn across the NSR/NBT pair at the floating peg price at the cost of transaction fees and confirmation times.

If the shareholders decide to give a false custodian nbt and it gets dumped on the market, that nbt will end up in the hands of true custodians and burnt for nsr which will dilute the market and push down the price of nsr, as it should be.

If shareholders give a contractor NSR and that is dumped on the system, it’s more complicated. First, let’s assume he gets his NBT and deposits to his bank account as USD. This pushes down on both pegs (NBT/USD and NSR/NBT). The NSR peg will sink in response to the NBT/USD price and since the contractor was already pushing down it will attain the new level quickly. Now, the NSR/NBT peg pushes down on NSR/other markets in order to try to return the peg. Once NBT/USD has achieved $1, NSR/other has established a new level such that the NSR/NBT peg does not need to move.

In the event of a rapid NBT decline less than $1, the NSR/NBT peg will push down on the NSR/other markets to reestablish the peg.
In the event of rapid NBT increase to more than $1, the NSR/NBT peg will push up on NSR/other markets to reestablish the peg. (Note that this event and its inverse recursively affect the NSR/NBT peg until the NBT/USD peg is restabilized.)

In the event of rapid NSR decline, the NSR/NBT peg will push up against the decline, pushing NSR/other up and NBT/USD down. This, in turn, lowers the NSR/NBT peg so the system does not crash. I think this event is the trickiest, but with proper burning mechanisms in place we can slow down the fall by providing perhaps higher rates for NSR/NBT sale than the broken NSR/NBT peg at the cost of a few network transaction times. The concept here is to turn a black swan event into a slower decline so a new equilibrium can be found. The burning will reduce the supply of NSR (countering the black swan effect) and increase the supply of NBT. The increased NBT supply will push the peg down some, allowing custodians to buy them back cheaper and burn them back for NSR at a lower rate, thereby regaining the equilibrium (albiet at a potentially lower NSR/other price level, but again, expected).

If NSR is bought up like crazy we can simply toss more NBT on the network via motions and custodial votes. The NBT/USD peg will break upwards and new custodians will be born. Eventually, those additional NBT will either find their way onto the market (huzzah) or be burnt for additional NSR to increase the NSR market cap either way.

[Nagalim]

Burn limiting and first floating peg motion.

As burning is done outside the market, we will need to limit the volume. What’s more, we want modification of network quantities to be decentralized but not publicly accessible. For those reasons, I would like to see the following:

Automated burning requires 3 pieces of info: how much is being burnt (use an amount with a lot of decimals as a signature), a reward address, and a custodial address. The custodial address must have received funds for providing liquidity recently (say within 90 days) and can burn a volume proportional to the custodial award they have earned within that time period.

I also think the automated burning volume should be proportional to the 24hr NBT volume, but I’m still thinking about that one.

So what do I mean by “automated burning”? I am reaching the limits of my knowledge, but I think it would look like a pair of addresses which send out appropriate funds when provided with proof of burning (I.e. the exact amount to be burnt time-stamped before the actual burning occurs). Ideally Nu would just generate rewards in response to proofs of burn without the need for the extra pair of addresses, but again I’ve reached the limit of NY technical knowledge.

The first motion I would pass would allow burning NSR at 0.5 times the floating peg and burning NBT at 2 times the floating peg. This almost guarantees that any burn will profit Nu and begins the process of switching from NBT/BTC operations to NBT/NSR operations, even before true pegging is established. Besides, we have no business pegging NBT/BTC anyway, why let BTC profit from our stabilization model? NSR is plenty volatile enough that it sorely needs our liquidity operations. Let’s get the hell out of NBT/BTC already.