Gateway with built-in USD reserve

[mhps]

The following describes how a gateway with a build-in 90% USD reserve (and with reduced exchange risks) works.

1. Nu sends 10000 Nubits to the sell side of the gateway
2. The gateway sells Nubits to customers and accumulates bitcoin on the buy side order book
3. Once the buyside has more than 1000+B NBT worth of BTC, it converts B NBT of BTC to the USD token on the exchange. B is a settable parameter.
4. Once the buyside has less than 1000-B NBT worth of BTC, it converts B NBT of the USD tokens to BTC and puts it on the buy side.
5. In an equilibrium state there will be 1000 NBT liquidity on each side on average. The maximum volume of sustained trading in one direction is 10000 NBT.

Way to lower exchange default risk by using multiple exchanges

1. If the gateway accumulates more than 3000+R NBT of USD tokens, it converts it to BTC, sends the BTC to another exchange where the BTC is converted to USD on that exchange, with minimum delay in order to minimize volatility loss of using BTC. R is a settable parameter. Other coins can be used for transfering if risk is lower.
2. If its USD reserve is less than 3000-R Nubits, it does the reverse and have USD reserve on the other exchange sent back similarly.

Pros:

• Only T1 fund on the buy side (1000 NBT in above example) is ever exposed to BTC volatility risk for extended time. 10% of total fund in the example.
• Exchange risk is lower depending on how many backup exchanges are used.
• Except for possible technical problems, it is almost deploy-and-forget. No constant attention from FLOT is needed. Reserve only needs t be replenished after BTC volatility exposure on the buy-side has consumed most reserve, which for a 10% exposure should take years according to current data.
• multiple gateways can run on the same exchange, reducing custodian run off risk (assuming no collateral)
• USD tokens issued by exchanges don’t need to have high KYC/AML requirement to buy/sell, as long as you don’t withdraw/deposit, usually. So the redtape problem isn’t severe.

Cons:

• Needs to trust the gateway operator. We already do that with current gateways however.
• Lower BTC volatility exposure ratio means higher exchange risk, for the same liquidity provided.
• Automation needs development.

[masterOfDisaster]

Great proposal!
This combined with a threshold at which funds get put in NuSafe and alike are a good way to mitigate BTC volatility risk.
If NuSafe is used early, the exchange risk is reduced in addition to the reduction by using multiple exchanges.
This way you can have a USD stable reserve - what’s very useful with a cryptocurrency pegged to USD!

[mhps]

If NuSafe is used early, the exchange risk is reduced i

NuSafe can just replenish the on-exchange USD reserve – no exposure to btc volatility for NuSafe. (btc might still be needed as transfer media if to avoid fiat depositing)

[Cybnate]

Cons:* Needs to trust the gateway operator. We already do that with current gateways however.* Lower BTC volatility exposure ratio means higher exchange risk, for the same liquidity provided.* Automation needs development.

It will also need a number of exchanges with BTC/USD pairs. Gateway operators will need accounts on those exchanges.
Spreading the risk across exchanges is better, but not that scalable.

Not without its issues, but one of the better proposals I have seen to maintain ‘stable’ reserves.

[masterOfDisaster]

Not without its issues, but one of the better proposals I have seen to maintain ‘stable’ reserves.

We will always have issues
To get a good combinations of “pros” and “cons” is all we can try to achieve.
A clever mix of centralized and decentralized, NuPaid and NuOwned approaches can help to stabilize different situations, while offering a good cost-effectiveness.

[mhps]

It will also need a number of exchanges with BTC/USD pairs

There is no lack of those.

Gateway operators will need accounts on those exchanges.

Yes. But usually a normal crypto account is suffice. No need to submit lots of information because no fiat deposit/withdraw is needed.

[mhps]

Edited OP to add another pro.

[Cybnate]

• Automation needs development.

Automating transfer does need development, but also increases the security risks. Funds will have to be withdrawn automatically to other exchanges. This requires a sophisticated authentication mechanism, probably still with manual approval from operators to reduce the risks of people tricking the bots into inappropriate transfers.

[mhps]

Automating transfer does need development, but also increases the security risks.

Yes but balancing multi exchange reserves doesn’t have to happen often and can be done manually.

Actually the part in “Way to lower exchange default risk by using multiple exchanges” is a multi-exchange reserve manager. It can be made into an independent product not limited to USD or Nu, and does not have to be an internal part of the reserved-gateway.

[masterOfDisaster]

What about converting the proceeds of the next NSR sale to USDT and keeping them on exchange until this scheme is complete and has been voted on?
I suppose we’ll use Poloniex again - should we prepare an auction instead? I’m fine with doing another sale on Poloniex, but don’t have the capacity to conduct an auction of any kind.

I don’t like the centralization and exchange risks this approach increases.
To be safe against BTC volatility and having the funds ready on short notice, USD (equivalent) funds on T2 are the most viable approach.

[mhps]

Sounds good to me.

[masterOfDisaster]

We are facing an interesting conflict between centralized and decentralized approaches - not only in terms of liquidity provision, but in terms of governance as well.

Nu’s liquidity provision isn’t steered by shareholders at the moment.
It’s done by FLOT based on experience and discretion.
Almost all buy side is NuOwned. This is with a different risk than ALP, but remarkably reliable so far.
FLOT is more agile than any shareholder consensus could ever be.
Let’s hope that FLOT decides in the best interest of shareholders.
I say, FLOT is handling this emergency quite well so far.

@shareholders, if you don’t think so, please create corrective motions!

Otherwise be greatful for having FLOT.
You may want to show your gratitude eventually.

[zoro]

Otherwise be greatful for having FLOT.

FLOT is the CEO of NU elected by shareholders

[masterOfDisaster]

Just because some of us act like that (I’m guilty), doesn’t mean it’s wanted that way.
There needs to be a duscussion about that.

Without the speed and tight consensus of such a board, Nu isn’t agile enough in emergencies.
With the discretion of FLOT or some of its members, shareholders don’t have full control.

If you look at how much I do and did (sometimeys even without consensus amongst FLOT members), because I think and thought it’s right that way, some will want to fire me (I’ll survive that, not being paid for most of what I do), others will love me for it.

There needs to be some regulation for it.
@Cybnate and others who demand that are right: a DAO needs governance.
This might be something for the lessons learned session, though.

[Cybnate]

If you look at how much I do and did (sometimeys even without consensus amongst FLOT members), because I think and thought it’s right that way, some will want to fire me

MoD is our benevolent dictator in times of crises

some will want to fire me

Dictators usually fire back We will be careful…

a DAO needs governance.

What can I say, a DAO without one is not a DAO.

This might be something for the lessons learned session, though.

[masterOfDisaster]

Dictators usually fire back We will be careful…

I loathe violence
Which is one of the reasons why I like the Nu network.

This might be something for the lessons learned session, though.

I didn’t want to prohibit a discussion or measures, that could and should happen now, with this statement!
Let me make it clear: I encourage all to take the initiative to do it now!

I meant, that I won’t take care of that myself now.
You might not believe it, but I have a life outside the Nu network and try to focus on the things I find more important than others - in the Nu network and anywhere else

[zoro]

I have a life outside the Nu network

No! I don’t believe it

[masterOfDisaster]

No! I don’t believe it

Maybe you don’t have it in yourself to believe enough?
Maybe I’m a stronger believer than you are

[mhps]

[Voting] Dual side NuBot gateways at multiple exchanges - masterOfDisaster

@masterOfDisaster
Automating a gateway will require reworking NuBot.

i don’t think it has to.

@masterOfDisaster
I don’t know how deleting orders works.

easy.

1. shut down the nbt/btc bot and the orders get deleted.
2. start the btc/usd bot with a shift that accelerates selling btc. Use nagalim’s bot to sell only a fraction of btc into usd.
3. shut down btc/usd bot and restart nbt/btc bot.

you just need a bot, and a shell script that shuffles two config files.

[Voting] Dual side NuBot gateways at multiple exchanges - masterOfDisaster

Ideally both bots would run at the same time and an overflow of BTC gets automatically traded to USDT, while USDT get traded back to BTC once BTC funds run low.Doing it manually is of course possible and would be the first step of playing with it.

I think trade USDT every 15min would be good enough.

@Nagalim’s nubot fork can adjust how big fraction of liquidity is put on order book. The nbt/btc bot can run continuously having only a limited amount of btc on the buy side. The rest btc will be picked up by the btc/usd bot to trade with usd.

Poloniex has no BTC/USD, only BTC/USDT. I think we need an adjusted wrapper, but I don’t know how to investigate wrappers for supported trading pairs.

Can we use the BTC/USD price feed for trading on BTC/USDT?That might be risky, but I’m not aware of a feed for BTC/USDT.

I see nbt and usdt prices can differ by several percent.

[Nagalim]

@Nagalim’s nubot fork

pybot. Different software entirely, no compatability. However, yes of course it can be run in conjunction with nubot via shell script.