I think it will be good to have open-source tools for custodians to run multi-sig pools off-exchange. This will be important along the line of heavy-duty subsidiary applications like NuBot and NuPool.
A rough idea is as follows:
Suppose Alice and Bob jointly run NuBooth, a semi-distributed market-marking off-exchange platform. It allows people to deposit NBT to get BTC and vice versa via Blockchain transactions.
In order to reduce risks, NuBooth addresses are 2-of-3 multisig addresses, where one private key is in cold storage by another trusted third party (or whatever arrangement that has both multisig security and robustness against loss of private keys).
Being multisig, they both need to sign a transaction in order to deliver funds to their customers. They should be separate entities for this to make sense, and this inevitably leads to a discrepancy in price feeds.
First I note that I want to put in a market-maker element for ALPs. We need to be able to get people to buy at non-arbitrage pricing, or Nu will risk an eventual break down by excessively subsidizing cryptocurrency speculation. So a crucial difference between this and NuLagoon Tube (apart from the availability of pool funds) is how the selling price is determined. The crux is that NuBooth will always be on the safer side of the trade, and try to avoid trades when there is a large discrepancy between price feeds.
A rough work flow is as flows:
-
I send in 1 BTC without replace-by-fee.
-
Alice and Bob each has a price feed, sees the unconfirmed transaction and starts tracking the lowest “real-time” non-arbitrage selling prices of NBT based on their feeds, Alice tracks p_1a,p_2a,…,p_Ta; Bob tracks p_1b,p_b,…,p_Tb.
-
If Alice sees that the 1 BTC is confirmed at time T,a she computes compute the highest values p_max(a) and lowest value p_min(b) among all p_i’s and sends them to Bob. When Bob sees that the 1 BTC is confirmed at time Tb, he does the same, computing values p_max(b), p_min(b) Suppose Ta < Tb, in which case Bob also sends in his prices.
-
Because Bob receives the price pairs from Alice first, once he works out his own prices he will decide whether to propose a transaction. If the range of the 4 prices exceeds say 1% he will decide to refund my 1 BTC and tell that to Alice, in which case the refund transaction is signed. Otherwise he will propose a transaction at the price point max(p_max(a),p_max(b)) and ask Alice to sign it.
Due to the pricing issues I don’t think this will be high-volume; however, as long as a service like this is live and known, we do not have to worry about the peg being at risk when liquidity is low on main exchanges - we readily provide non-arbitrage price that is slightly biased to ourselves, effectively organically applying a “spread” to adjust for the occasion.
When BCExchange comes out, the multisig-part might not survive, but the non-arbitrage element will still be needed and refined.
