T3 custodians

[huafei]

can we use auto-sign escrow ?

code by NU dev

[Nagalim]

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.

[zoro]

I guess a T3 custodian can be any FLOT member which is trusted and has been voted already

[dysconnect]

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.

[Nagalim]

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.

[henry]

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.

[Nagalim]

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.

[dysconnect]

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:

1. Confirm registration states, by looking for $1 deposits
2. 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.

[Nagalim]

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.

[nubition]

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

[Nagalim]

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.

[dysconnect]

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.

[Nagalim]

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.

[dysconnect]

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.

[Nagalim]

@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?

[henry]

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.

[masterOfDisaster]

Extended cross post / cross quote, but it is on topic:

Interpretation of the liquidity tiers, a waterfall model, triggers, metrics and actions

Interpretation of the liquidity tiers, a waterfall model, triggers, metrics and actions

About T3, i believe T3 has 2 roles.(2 sublayers)[…]T3.2 is the sublayer closer to T4 that NU has full knowledge of it. It is the tier that interacts with T4 and T1+T2 to makefund transfers faster with 24/7 availability.

I hear what you say. I fully agree to the function of T3.2. But I’d explain it in a slightly different way.T3 sell side (T3 buy side has millions of BTC ready ) custodians hold NBT that are their property.They verify that they hold the NBT and pledge to use them for T1 (and T2) operations.They get compensated for having NBT “locked” (pledged to liquidity operations).This compensation is lower than T1-2 compensation, because no exchange default risk applies, but needs to be big enough to make people hold the NBT.

I’ve thought some time about the accounting of the compensation.I still believe that one of the easiest ways to do that is to make this via custodial grants by people who run NuBots.The T1-2 funds get reported by NuBot.T3 funds can be read on the block chain.The total of T1-3 is more or less constant and only prone to BTC volatility when being traded hence and forth.

The incentive for the custodians to move funds from T3 to T1 is the increased compensation for a sell wall that has run low. This of course works even better with the fixed compensation scheme, because it amplifies the compensation effect of providing liquidity in low walls. With fixed rate it only provides an increased incentive, if the side drops below the compensation threshold.

FLOT is only doing business with these custodians, but not with random people.That limits the involvement of the FLOT in liquidity operations and ties T4 to T3.Plus it can allow (by NSR holder vote, depending on the terms of the custodial grants) to have the FLOT send NBT before they received BTC from the custodian. This speeds up the refilling of T3 in case the funds run really low there.It might not play a big role, but can make the difference between the FLOT doing business with T3 and the FLOT beind required to use NBT entry gateways to directly inject NBT in T1 - which requires to have such a gateway at the exchange with the low sell side!

T3 custodians should trade with each other to balance sides on different exchanges as long as the overall T1(-3) sides are balanced.The easiest way to do that is by transferring funds to another exchange and trade there.If on one exchange there is demand for NBT, while another has sufficient NBT or NBT in excess, send BTC there, trade them for NBT and send the NBT back to where they are low.

T4/FLOT would only be involved if one side is overall low or in emergencies.

[Nagalim]

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.

[masterOfDisaster]

T3 funds should be given to T3 operators by Nu.

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:

[Discussion] about the size of buy and sell side / T1-3 (T4)

Maybe the complete decentralization of T1-3 liquidity is not the optimum and a clever combination of decentralized and centralized liquidity providing in the end is cheaper for Nu.

The price is increased risk for the Nu funds.

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.

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!

[Nagalim]

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.