OK, how about a T3 custodian has to put up a bunch of nsr collateral (they can also be a trusted community member). Then, they are given an nbt and btc allowance for the week. They offer to sell nbt at $1.003 and buy at $0.997. Each week they rebalance their allowance with T4, pocketing 2% for each nbt bought or sold.
The issue is of course as @masterOfDisaster says, that auditing a T3 transaction is very difficult. We’d have to keep track of their nbt and btc addresses as well as the btc price at Txn time. This isn’t impossible, it’s just annoying.
What if the T3 custodian records the prices at txn time and shareholders can cross check the announced btc and nbt addresses with the record of the open market and the custodian’s reported prices? Maybe we could make a quick audit tool.
Sounds like a feature request for NuBot!
NuBot already is aware of BTC/USD and logs that.
A reliable block explorer with an API to retrieve UTXOs of addresses would be required, too.
Then it could be like this: an option "T3enable": true, together with "T3buySideAddress": "BTCaddress", and "T3sellSideAddress": "NBTaddress",
makes NuBot broadcast and log T3 info as well.
A parser retrieves T3 information from the NuBot log files or an additional “T3 log” gets automatically created.
Ok, so I don’t really know what you just said, but yah, it seems like this is totally doable. So, let’s assume that we can audit T3 custodians to verify their reported transaction record. That means that shareholders can be confident in the reward system of giving them a certain % of the transactions that involve them, other than their weekly allowance re-balance. If every transaction is done at $1.003 and $0.997, we can give the custodian 0.2% without fearing them taking any kind of advantage.
So that covers 1+4.
3 is still up in the air, but it’s looking like this is just a person willing to escrow trades for Nu at 0.3% offset. Maybe they have a minimum limit, like 100 NBT?
2 is the weekly allowance re-balance with NSR collateral. Clearly, this is a weak point in the system, but the statement is that these are trusted community members voted in, so it’s not much worse than electing pool operators. Perhaps pool operators should be putting up NSR collateral. Perhaps T3 custodians don’t need to put up any collateral.
It appears we would need two separate scripts, one for the custodian and one for the auditor. Features the software would need:
Custodian: ability to simply record BTC price over time using API. T3 custodians will act as auditors of each other by independently storing the BTC price.
Custodian: being fed a valid custodial address and the BTC and NBT reserve addresses, it will broadcast T3 data equal to the balance in those two addresses.
Audit: can be fed a price history a simple text log of transactions including manually entered price, volume, and time that the price was chosen. The software will tell in an easily read format if there were any transactions missing or extra, then will provide the tolerance on price (in %) required for the custodian to pass audit.
Making this a part of NuBot would run into compatibility issues I feel. A fresh script would be nice, but perhaps we can just copy and paste stuff like the price feeds. But I dunno, maybe running nubot in T3 mode is totally practical. I still have yet to actually use Nubot, so I don’t know.
I have no clue about the inner workings of NuBot, I only use it for some purposes (modPuddle, Poloniex gateways). @desrever might be able to answer the question for the capability of being a T3 tool as well.
With my limited knowledge I can imagine that it’s possible without to much effort.
re 1) NuBot already records price in the logs. It should be fairly simple to get a log that only contains time stamps and BTC exchange rates based on different sources.
re 2) that’s what NuBot is currently made for - albeit only for T1 and (if enabled) T2 at the moment. Should be possible to extend that to T3 reports/broadcasts.
re 3) if the liquidity that gets broadcast by NuBot is recorded, that’s pretty much all that’s required for audit. Broadcasting BTC or NBT liquidity of the registered addresses on T3 requires API access to block explorers that can be queried for the UTXO of certain addresses. If somebody doubts the validity of the NuBot reports, the UTXOs can be read from the blockchains directly and aligned with the data NuBot reported. Would be convenient to have the block height reported in the NuBot log.
I’m speaking of adjustments of NuBot although I don’t know whether it’s possible to do that with the current design of NuBot or how much effort it would be. I’m just trying to project the current features of NuBot into a future version that’s capable of doing T3 stuff.
I think it’s useful if T3 custodians are able to put orders on T1 even if they normally have all funds on T3. It’s way faster if they can just send the T3 funds to their exchange deposit address than to arrange a deal with somebody - their NuBot is already running (because of broadcasting the T3 liquidity information)!
You can run a single NuBot only on one exchange. So a T3 custodian would not necessarily active be on the exchange in need of T1 funds. But if there are T3 custodians for the most important exchanges that shouldn’t be much of a problem.
I think improving NuBot to support T3 custodians means using well-tested software and add features to it. And it saves the Nu landscape from creating a completely new software, that needs to be tested, maintained and that introduces additional complexity to the environment.
T3 management have been looong planned. In particular, T3<---->T2 movements should be automated to guarantee a proper fund management. NuBot can interact with multiple crypto-wallets via RPC (not with blockexplorer), and an interface is underway, but not planned for the near future.
0.7.1 - Tier3 liquidity management
What we planned when designing this roadmap, is slightly different to what you guys seem to have in mind. NuBot 0.7.1 will be for liquidity providers that want to optimize their strategy and minimize their risk by keeping on exchange the minimum amount of funds needed, yet being able to quickly and automatically refill and withdraw to keep walls as balanced as possible.
It won’t be too hard to create a multisig pool as some kind of Tier 3 ALP before B&C exchange goes live (which I guess could take more than 6 months from now)
It will hold funds either taken from tier 4 or paid for by interest like Tier 1 ALPs, then allow people to deposit NBT to get BTC and vice versa, at slightly higher spreads than from the exchanges. Then we can register Tier 4 addresses to “buy” NBT or BTC at better prices in order to balance the liquidity in Tier 3.
I can help to implement it; it won’t be wasted or completely replaced when B&C comes out.
The nubot development on the roadmap is all well and good, but it does not really help T4 get to market. What we are discussing here is more powerful than that.
Why a larger spread for T3? This is actually a very critical point. With no exchange fees or default risk, the spread should be lower. The idea being that T1 custodians can buy nbt for something like $1.003 from T3 and sell on T1 for something like $1.007.
If we are still operating under a concept of credit and T4 refills, a T3 custodian will only be rewarded for nbt bought or sold, not for just holding funds. In this way, it is unlike an ALP.
ALP granting interest is just the status quo. If that can be made unnecessary then all the better. I also don’t think it is difficult to go back to giving out interests, if such insurance is required for pool operators.
Spreads should be within what Nu can stomach, but at least comparable to tier 1 spreads so to capture the natural response to high BTC or NBT demand. It should be automatic so we can easily advertise and operate the service and ensure people will go for it. The trades have to be low frequency; either make sure there are obstacles (such as spreads / fees) or only activate the service based on need. We can register some providers so they can get discounted rates. So on so forth.
Why? These are basically escrow agents for Nu. They put up their own restrictions, most likely something like a $500 minimum or whatever. They don’t have to make a deal if they don’t want to, they get paid by the transaction volume like an exchange. 0.2% trading fee is plenty, and a $1.003 sell price is very much reflecting on our T1 spread because it only gives 0.2% profit to the T1 custodian buying from a T3 custodian (only 0.5% offset-after-fee from the spread regulation motion)
Given current incentive systems we have for Tier 1, if Tier 3 can be provided as a reliable service then it may not be necessary to give discount; liquidity providers have strong incentives to balance their exposure to BTC, which we can encourage through education.
There will also be people who are willing to buy at higher spreads when there’s insufficient support at exchanges.
If we can make cuts from each trade like exchanges do it would be nice to see that a Tier 3 pool operates at a profit after deducting liquidity expenses. In that case, Nu can tax Tier 3 for Tier 4 providing them liquidity.
@henry, what do you think about operating an off-exchange platform for people to trade directly with tier 3; any legal issues or else that one might face?
T3 is by definition off exchange. This thread is about having a custodian who is able to buy and sell nbt at a small spread (0.3%) off-exchange, acting as a private escrow for Nu.
An escrow is a third party to a transaction that must be trusted by both parties in the trade. In this case, one party is Nu (T4 multisig signers) and the person buying or selling nbt (could be a T1 custodian, or just a customer). The T3 custodian is acting as escrow because one party is slow to act (Nu multisig) and the other isn’t trusted by the network (the customer).
I’m not sure what you mean by that. The idea here would be that the T3 custodian picks their customers and the pricefeed manually. The benefit over interacting directly with T4 is that a T3 custodian can act the moment they settle on price and volume with the customer and they receive the customer’s funds. T4 on the other hand has to wait for multisig. Also, there can be several T3 custodians whereas T4 tends to have just one or two addresses.
