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.
1 Like
I guess a T3 custodian can be any FLOT member which is trusted and has been voted already 
Do you think it’s currently feasible? Given the infrastructure you already have, perhaps the most important part is having a price feed to decide the trade price automatically, and the rest seem attainable.
Nubot already has a price feed. We’d just need to make sure it reports liquidity properly. The audit software can come later, but ya we’re basically ready for this now.
2 Likes
We need to develop the feature of automatical payment, which must be done very carefully because huge lose could occur if we are attacked by hackers.
Currently, NuLagoon manually process the withdraw request.
I’m not convinced we want automatic payment. Even just manual would be a vast improvement over what we have. Basically, have a bunch of people doing the job JL was doing.
Automatic trading like this is very reminiscent of the seeded auctions. People would need to register an nbt-btc address pair.
1 Like
We’ll talk about how to do automatic payments; automatic payments is more ideal if we want a service with enough uptime that tier 1 LPs feel they can rely on it.
I have a rough idea of a semi-decentralized rubber-stamp multisig mechanism. This probably looks like a vastly dumbed-down version of what BCE might be doing, and needs polishing. It’s slow and not as convenient as clicking a few buttons, but probably good enough for tier 3.
User side
A trader needs to first register with the platform. A refundable small deposit may be needed for anti-DDOS.
For example:
To buy NBT with BTC, Alice will send about $1 dollar of BTC to a deposit address 1yyyy specified by the platform. Then she will sign an NBT address Bxxxx using a BTC address 1xxxx and send the message to the platform.
The platform will confirm the BTC deposit and register Alice’s addresses. Alice can then send BTC from 1xxxx to receive NBT at Bxxxx.
If Alice sent funds without registering by making a deposit, $1 of the funds will be treated as a deposit and the rest refunded. She can register and enjoy the platform features if she registers relevant addresses.
Server side - front end
A centralized server is used to host a website. It mainly handles registrations as a front end and broadcasts useful information such as price references. We’ll aim to sandbox the hardest security issues within the server and not directly affect transactions.
Server side - back end
There will be N independent operators controlling and approving transactions, with funds held at m-of-N multisig addresses. Each operator receives registration information from a broadcasting medium, and store their own copies. They will monitor the blockchain and do the following:
- Confirm registration states, by looking for $1 deposits
- Create, sign and broadcast transactions if deposits are received at registered addresses.
Server side - front / back end interface
There will be no exclusive channels between the front end and the backend, but the front end server should know the public keys of the operators. Front end maintenance needs to be carried out separately. The front end stores and broadcasts registration information as well as the states of multisig transactions.
As long as the public keys and addresses of the signers held on the server are correct, these cannot be spoofed or replayed; things like MITM can only prevent access to this information. The most probable risks, at first glance, are that a user may see a wrong deposit address on the website, or their registration information is lost, or multisig transactions cannot complete. On the other hand, there is a reduced risk that the operators lose their own funds.
You’re assuming participants can send from a specific address. This is an issue I was running into with the auctions, there is no “sendfromaddress” rpc command. To send from a specific address, you have to either use coin control or raw transactions, both of which are very inconvenient for Alice, who is assumed to not have a ton of technical info about forging raw txns.
Would T3 custodian not be better with different people in different time zones so you have 24/7 cover or am I reading this wrong.As a newbie if I am ignore me lol
Yah, for sure. Currently, we have to wait for JL or FLOT, which can take days never mind just over night. With many T3 custodians willing to trade NBT for BTC and vice versa off-exchange, Nu should be able to balance liquidity around the clock. The limit would be when our T3 custodians run out of funds and need a refilling from FLOT. This is a vast improvement over customers interacting with FLOT directly.
1 Like
Interesting. Coin control is something within the NuLagoon manual though, and if we mainly target tier 1 LPs it’s doable.
Not necessarily worth the effort if we want to reach more novices, hope there’s a way round that without developing a custom client.
Yah, making our own client ends up kinda complicated:
https://github.com/Nagalim/SeededNuAuction/blob/master/participant.py
It forges the raw transactions on line 106 and 107. The fee is kind of fudged (it overestimates the fee). An rpc command would be sooooo much awesomer.
At least for Nu one can implement sendfromaddress and ask devs to accept the pull request… for Bitcoin, looking around it seems that at least Electrum has a straightforward option, while Armory uses coin control.
@henry When you report tier 3, does Nubot do it? Do you feed it your buy and sell addresses? How are you reporting T3 currently, technically speaking?
We developed a tool to report tier3, as NuBot only report tier1&2.
Now we have to manually deposit into and withdraw from exchanges, when we do this, we call the RPC command of Nubits client to update tier3 info.
1 Like
Extended cross post / cross quote, but it is on topic:
1 Like
I’m going to assert some controversial stuff about T3 now:
T3 funds should be given to T3 operators by Nu. These funds are not considered T4 and so are therefore ‘Circulating NBT’ and will trigger motions accordingly. Even though they are in the hands of a trusted custodian, they are not in multisig. This is similar to the funds pools give out that are also considered in circulation. For this reason, the NSR collateral is actually fairly important: it functions as a temporary buyback during the period that the T3 custodian holds circulating NBT that they didn’t pay for. Also, Nu is giving the custodian both NBT and BTC, which hits on T4 double by both reducing the funds we have and increasing the funds we need before we hit overflow. Therefore it is somewhat costly to start up a T3 custodian, but they contribute a great deal to the depth of the network once operating.
On a different note, the mandated 0.3% offset completely prevents T3 custodians from trading with each other. As the compensation model is to pay a custodian for every NBT sold, this is ideal. T4 rebalances are the only way a T3 custodian can get back to a balanced pool. For FLOT, all that means is that they need to keep an eye on each individual T3 custodian to refill if they go out of balance. This may seem like a burden, but it’s still much simpler than FLOT dealing with either T1 providers or customers directly.
2 Likes
I wouldn’t say they should, but I agree they could…
The result would be a small step away from the decentralized liquidity model, but a step towards more reliability of liquidity operations, more agility of balancing walls, more security for the peg:
The price is increased risk for the Nu funds.
This hits the nail on the head and is valid no matter whether the T3 funds are property of Nu or property of the liquidity provider.
FLOT/T4 balancing with T3 is the way to go!
PoS-like T3 custodians (Stochastic Trust):
@mhps’s idea, my interpretation
The custodian is prevented from making many fraudulent accounts by preferentially weighting based on volume. Therefore, if a custodian has 100 NBT, they are weighted the same as 100 custodians with 1 NBT each. When a T1 custodian comes to make a bid, they are randomly given a T3 custodian as ask. If the Txn happens, Nu pays the T3 custodian based on how long that custodian has been reporting those funds.
The concern: a T3 custodian that gives a terrible price to everyone but themselves. Then, they never touch the buy or sell T1 wall with their funds. The cost for them is only the opportunity cost of keeping their funds locked up, which is necessarily less than the cost for honest T3 liquidity (what we’re paying them).
Possible Solution:
We could just pay the T3 custodian park rates for both NBT and BTC. That would counteract the opportunity cost and be very cheap liquidity for Nu. However, it is important to know that in this case T3 would be fraudulently reported and would not be reliable in any sense.
That is the “coind day” equivalent. This encourages people to set aside fund. Another way is reward based on fund. This encourages people to get fund from somewhere else quickly. The first method may attract less fund in an absolute sense.
Then people will see that a T1 wall gets low, Nu gets T3 fund for this wall, but the T1 LP doesn’t use the fund (at a price within tolerance). It’s easily identified and punishable.