FLOT NSR Operations (buy side)

Got it. Will reduce it to 1.2 million at once.


It will be replenished like announced.


What is the status of the sale?

The first 2.3 BTC were retrieved:

Final state of BTC proceeds from the auction:

What do we do with the next NSR that need to be sold?
We can safely assume that another round of NSR sale is required, although the buyback calculation will take place later.

1 Like

@FLOT, what do we do with the NSR, that need to be sold?
Putting them on order at Poloniex again?
How much of them? By whom? I don’t want to forge ahead, but can do it again.
$4,762 or do we need to include the PPC calculation?
Current NSR price is approximately $0.0015.

4,762 * 0.0015 = 3.175 mil nsr for sale this week.

1 Like

What about the PPC?
Not considered, because there is no PPC reserve?
How to bring the NSR to market?
If I were to sell them, I can do the same as last time: place several orders (I started wirh two and continued with three) and move the one with the biggest offset - and I recommend others to do the same. It worked quite well.

1 Like

I suppose. We could actively look for investors, or wait hoping Bitcoin’s value will fall and there to be NuBit sales replenishing our Bitcoin reserve.

If Bitcoin doesn’t fall, we have to sell more shares, right? If Bitcoin falls, we may not have to, but we better get back up as soon as possible.

How many Bitcoins do we need?

Theoretically, if nobody else sells their shares cheaply, the NuShare price would jump back up to previous levels once we’ve sold enough for liquidity restoration. :dizzy:

Assuming Nu regains liquidity and begins keeping larger reserves (or otherwise improves the issue), then NuShares at moments such as this may become seen as the investment opportunity we believe it to be.

NuShare sales in combination with buybacks should work a lot better when demand is where I believe it should be, by how I value Nu. Have we been in this bad a situation before? I imagine our current lack of liquidity doesn’t make us attractive to invest in while we also continue applying downward pressure on the shares they’d buy.

I don’t understand Park Rates, but it seems we should leverage them.

The price support mechanism of offering interest for funds taken out of circulation is extremely robust.
However, there are a handful of individuals who believe there is a 30% chance that NuBits will still have value in a year because they are NuShareholders and plan to implement a bold and daring plan to change the protocol to meet different needs than NuBits have in the past. These individuals would buy NuBits if there was 400% interest rate offered for one year. So it will be offered by NuShareholders and taken by the speculators, and the peg will stand at $1.00 US.

Perhaps we should pay for and advertise that Parking Your NuBits Rocks.

The concern that high rates signify a crisis and will turn people away must be taken care of if it’s an actual problem. It is a crisis, but the system seems built to be able to recover with the right measures, and it will continue to grow more sustainable.

Parking interest rates should be easy to understand. The percentages are currently confusing people.

Another presented way to increase NuBit utilisation (transaction fee revenue, and sales?) is NuLagoon’s BearBTC and BullBTC. It appears costly, and would be easier to approve with Nu in better standing, but should we pay for it anyway? I’m uncertain.

I support selling more shares. I think it’d be much appreciated if you’d perform the sale.

We need to trust and use the mechanisms we have at disposal. It doesn’t feel great to sell shares, but we committed to that and what else can we do? I need to learn more about Park Rates (Tier 5).


I think we need to increase rates to 50% annually up to 1.5 months.
Assuming that we have 100k of sell side liquidityz
If those 100k were all parked for 1.5m, we would only pay for 6.5k nbt in 1.5 months. That s way below the price we are paying for nsr dilution: we have lost 300k nbt from a share price decrease from 0.002 to 0.0016 …

1 Like

I really don’t know about park rates in the current situation - it’s something different, if it’s about mitigating temporary issues.

Park rates try to postpone the trouble we have (lack of NBT demand) by creating additional trouble (park interest).

Is this really a temporary issue or is it a structural problem?
If it’s the latter, NSR sale is the way to fix it.

…I think it’s a combination of both; we need both: park rates at a reasonable level and NSR sale.


I can’t load teh redeem script to initiate a transaction. cointoolkit suspects that the explorer is down but it is not.

@Dhume, @ttutdxh, @cryptog, @mhps, we soon need to start creating a new NSR multisig address to request a new grant.
It isn’t impossible that the NSR sales push the NSR rate down and we see increasing numbers of NSR that get sold each week.
The rest of the 25 million might last only a few weeks.

Do we use new pubkeys fot that new address or do we want to create a new multisig address by changing the order of the pubkeys we already have?

Do you have scripts disabled in your browser?
Can you use @backpacker’s explorer or Cointoolkit?

1 Like

It’s not as serious. PArk rate is much smaller than how much we pay LPs. They are not highly comparable but at the end of the day they are both increading of liability.

1 Like

So far tier 6 NSR sales have raised very little additional reserves. The current process of posting the shares for sale above market and slowly bringing it down is too timid for the circumstances.

For the next sale of shares I’d suggest using a different strategy, here are some options:

Option 1: Start the sale at a point where there are less than 10,000 NSR already for sale. Continue reducing the price until sold.

Option 2: Start the sale at the same price as the last one concluded (0.00000275 BTC/NSR). Continue reducing the price until sold.

Option 3: Start the sale at the same price as the last shares were bought. Continue reducing the price until sold.

Option 4: Sell half the NSR into the buy orders, but the other half for sale whatever the first half concluded at. Continue reducing the price until sold.

Option 5: Sell all the NSR into the buy orders.

Option 1 is most conservative, option 5 the most aggressive. Given the gravity of the situation, I think option 4 is the most prudent course of action.

I’ll also point out that last weeks calculation resulted in:
"Standard < -2500: Sell 4726.93 NBT (9.3535 BTC) amount of NSR next week."
But the share sales stopped after selling only:
"6.9 BTC, at $533 per BTC at the time of writing valued $3,677"
This is more than 25% fewer BTC than the authorization.

1 Like

That’s how it works.
You calculate a number of NSR, that gets sold per week, based on the NSR market rate.
Whether you can sell all at that rate is a different matter.

The way things are currently worded, it is easy for someone not familiar the intricacies of the system to expect that if 9.3535 BTC worth of NSR were authorized to be sold, when the sale concluded there would be something very close to 9.3535 BTC available. If the intention is rather to sell a certain amount of NSR, then it should be stated that way in the authorization.

“Standard < -2500: Sell XXX NSR next week (worth 9.3535 BTC at current prices)”

That way everyone is clear what the plan is.

We can certainly make it more clear. However, i greatly warn FLOT against automating the NSR spot price. The market is small enough that they should look at the recent trades and market orders directly to manually pick an estimated nsr valuation for the week.

Taking the average rate of the recent sale into consideration is no bad idea either, right?
At least unless there’s trade in the same order of magnitude in between.

But that can be gamed as well: a shareholder/speculator can dump NSR on the market just to increase the amount of NSR for the next sale, hoping to get the shares back at a cheaper rate.
How to really find the “true” rate in such an illiquid market?

NuShare transaction without NuExplorer

In Nu’s NuShare debug window or from shell, run the following.

Requires the latest transaction ID after this transaction is made. Read the guide.

getrawtransaction b24342d957bf8deb5abf7ff19ff06c38520e99ee6a09797c2ed9b3895f09ed19
decoderawtransaction 0100000039ae49570215abb65fa5ed15c36c13a950bcab36f1cfd6f1d160dd04e4e9b4ed925508c38300000000fd89010047304402204db74aae2ba58582c738e5f42f748fb5d7ac37c755bc469cf7fdf8410d3fdc2402201bd130869f18f34c828176c09976cc25c4d59df67ff7dd80d163133bb9615b81014730440220535e8d1638123ca92e9b91e97ad432d9519e14473876c9174b0d34f81aa7f2a702201da45708931b00fba0052d245191604f0692586d747ef33e505505cede99cf4b01483045022100948691e7bb9717828ee7649615fee7d3e2926ba7e648a306cbf707fa702982e402201f91af1388eb6d6ef1c7ebc9d2aa09be9789b1be28c12caf784db68f9bb61e02014cad532102e2fcdfe246e9cd4864d9119b8af465487385eccd0ea30a8cb21d44d36818189f2103661a4370dfcfbcea25d1800057220f4572b6eecab95bb0670e8676a9e34451dc2103686ee42f635c71c08f326e66139b6cb37167402cc0562584655aac03fe74049521039854d0e2abf6e4971e1350137b876da6a05132737c11ca3e37aaed2a0eb668082103d05d8fb69fcd289548140dde8e906f6fc217b02477f81842f2483d9ea1c9242555aeffffffff94c1b11ee00dc036bf5e4afed3e8650fe86ed16e4681a9f40bf9270bc75d110b00000000fd8a0100483045022100f954a529618fd5274fc6ad264782a2042940dc3340c545d3d27ffd71277ebcf8022015460ed8fd66cbfc093fd31039ae375ee0c872383aced04162d9b82f69030a0001473044022075c3dad18b0c038cb9727ddb53d63ad0872acdfa7b2643c4f3994d3cfd6794ba02206ed02137ae047df5025a0290a316228138c5b022b958f211f849d94ae11caf1801483045022100d540a0a3692af6b1975dd3207e0456d1bb2d9f43b97bcb18f6769e0fbf023d3c022017b3de38047366f17aed956ef18bef8963e87ff0d8ce4fa05bca97b7c3f96fce014cad532102e2fcdfe246e9cd4864d9119b8af465487385eccd0ea30a8cb21d44d36818189f2103661a4370dfcfbcea25d1800057220f4572b6eecab95bb0670e8676a9e34451dc2103686ee42f635c71c08f326e66139b6cb37167402cc0562584655aac03fe74049521039854d0e2abf6e4971e1350137b876da6a05132737c11ca3e37aaed2a0eb668082103d05d8fb69fcd289548140dde8e906f6fc217b02477f81842f2483d9ea1c9242555aeffffffff0200f08296050000001976a9141462d25d2568d72654320aef11732fc006d73deb88ac603ea79e3400000017a9147077487df91c0166d33ee6079b0c2229788f6ac2870000000053
"txid" : "b24342d957bf8deb5abf7ff19ff06c38520e99ee6a09797c2ed9b3895f09ed19",
"version" : 1,
"time" : 1464446521,
"locktime" : 0,
"unit" : "S",
"vin" : [
"txid" : "83c3085592edb4e9e404dd60d1f1d6cff136abbc50a9136cc315eda55fb6ab15",
"vout" : 0,
"scriptSig" : {
"asm" : "0 304402204db74aae2ba58582c738e5f42f748fb5d7ac37c755bc469cf7fdf8410d3fdc2402201bd130869f18f34c828176c09976cc25c4d59df67ff7dd80d163133bb9615b8101 30440220535e8d1638123ca92e9b91e97ad432d9519e14473876c9174b0d34f81aa7f2a702201da45708931b00fba0052d245191604f0692586d747ef33e505505cede99cf4b01 3045022100948691e7bb9717828ee7649615fee7d3e2926ba7e648a306cbf707fa702982e402201f91af1388eb6d6ef1c7ebc9d2aa09be9789b1be28c12caf784db68f9bb61e0201 532102e2fcdfe246e9cd4864d9119b8af465487385eccd0ea30a8cb21d44d36818189f2103661a4370dfcfbcea25d1800057220f4572b6eecab95bb0670e8676a9e34451dc2103686ee42f635c71c08f326e66139b6cb37167402cc0562584655aac03fe74049521039854d0e2abf6e4971e1350137b876da6a05132737c11ca3e37aaed2a0eb668082103d05d8fb69fcd289548140dde8e906f6fc217b02477f81842f2483d9ea1c9242555ae",
"hex" : "0047304402204db74aae2ba58582c738e5f42f748fb5d7ac37c755bc469cf7fdf8410d3fdc2402201bd130869f18f34c828176c09976cc25c4d59df67ff7dd80d163133bb9615b81014730440220535e8d1638123ca92e9b91e97ad432d9519e14473876c9174b0d34f81aa7f2a702201da45708931b00fba0052d245191604f0692586d747ef33e505505cede99cf4b01483045022100948691e7bb9717828ee7649615fee7d3e2926ba7e648a306cbf707fa702982e402201f91af1388eb6d6ef1c7ebc9d2aa09be9789b1be28c12caf784db68f9bb61e02014cad532102e2fcdfe246e9cd4864d9119b8af465487385eccd0ea30a8cb21d44d36818189f2103661a4370dfcfbcea25d1800057220f4572b6eecab95bb0670e8676a9e34451dc2103686ee42f635c71c08f326e66139b6cb37167402cc0562584655aac03fe74049521039854d0e2abf6e4971e1350137b876da6a05132737c11ca3e37aaed2a0eb668082103d05d8fb69fcd289548140dde8e906f6fc217b02477f81842f2483d9ea1c9242555ae"
"sequence" : 4294967295
"txid" : "0b115dc70b27f90bf4a981466ed16ee80f65e8d3fe4a5ebf36c00de01eb1c194",
"vout" : 0,
"scriptSig" : {
"asm" : "0 3045022100f954a529618fd5274fc6ad264782a2042940dc3340c545d3d27ffd71277ebcf8022015460ed8fd66cbfc093fd31039ae375ee0c872383aced04162d9b82f69030a0001 3044022075c3dad18b0c038cb9727ddb53d63ad0872acdfa7b2643c4f3994d3cfd6794ba02206ed02137ae047df5025a0290a316228138c5b022b958f211f849d94ae11caf1801 3045022100d540a0a3692af6b1975dd3207e0456d1bb2d9f43b97bcb18f6769e0fbf023d3c022017b3de38047366f17aed956ef18bef8963e87ff0d8ce4fa05bca97b7c3f96fce01 532102e2fcdfe246e9cd4864d9119b8af465487385eccd0ea30a8cb21d44d36818189f2103661a4370dfcfbcea25d1800057220f4572b6eecab95bb0670e8676a9e34451dc2103686ee42f635c71c08f326e66139b6cb37167402cc0562584655aac03fe74049521039854d0e2abf6e4971e1350137b876da6a05132737c11ca3e37aaed2a0eb668082103d05d8fb69fcd289548140dde8e906f6fc217b02477f81842f2483d9ea1c9242555ae",
"hex" : "00483045022100f954a529618fd5274fc6ad264782a2042940dc3340c545d3d27ffd71277ebcf8022015460ed8fd66cbfc093fd31039ae375ee0c872383aced04162d9b82f69030a0001473044022075c3dad18b0c038cb9727ddb53d63ad0872acdfa7b2643c4f3994d3cfd6794ba02206ed02137ae047df5025a0290a316228138c5b022b958f211f849d94ae11caf1801483045022100d540a0a3692af6b1975dd3207e0456d1bb2d9f43b97bcb18f6769e0fbf023d3c022017b3de38047366f17aed956ef18bef8963e87ff0d8ce4fa05bca97b7c3f96fce014cad532102e2fcdfe246e9cd4864d9119b8af465487385eccd0ea30a8cb21d44d36818189f2103661a4370dfcfbcea25d1800057220f4572b6eecab95bb0670e8676a9e34451dc2103686ee42f635c71c08f326e66139b6cb37167402cc0562584655aac03fe74049521039854d0e2abf6e4971e1350137b876da6a05132737c11ca3e37aaed2a0eb668082103d05d8fb69fcd289548140dde8e906f6fc217b02477f81842f2483d9ea1c9242555ae"
"sequence" : 4294967295
"vout" : [
"value" : 2400000.0,
"n" : 0,
"scriptPubKey" : {
"asm" : "OP_DUP OP_HASH160 1462d25d2568d72654320aef11732fc006d73deb OP_EQUALVERIFY OP_CHECKSIG",
"hex" : "76a9141462d25d2568d72654320aef11732fc006d73deb88ac",
"type" : "pubkeyhash",
"reqSigs" : 1,
"addresses" : [
"value" : 22600006.0,
"n" : 1,
"scriptPubKey" : {
"asm" : "OP_HASH160 7077487df91c0166d33ee6079b0c2229788f6ac2 OP_EQUAL",
"hex" : "a9147077487df91c0166d33ee6079b0c2229788f6ac287",
"type" : "scripthash",
"reqSigs" : 1,
"addresses" : [

Input #1

Transaction ID: b24342d957bf8deb5abf7ff19ff06c38520e99ee6a09797c2ed9b3895f09ed19
Amount: 22600006
N: 1
Script: a9147077487df91c0166d33ee6079b0c2229788f6ac287

Create transaction

  1. Open Cointoolkit with multisig redeem script filled in.
  2. Insert values of Input #1 under the tab Inputs.
  3. Go to the tab Outputs and continue as usual.

@masterOfDisaster: Are you willing to execute the sale? Which address?

SP9nvw4RviJKN5Nn3v15ACHQgfwjfbauha was used in your transaction for 2.4 M.
Sidhvfpo93KGVpbu9pM3LgyiPdgesnT1G6 was mentioned by you later.

1 Like

Thank you for starting the NSR tx!
I was starting to look at how to do it based on your guide but got lost.

I’m willing to execute the NSR sale.

Both NSR addresses belong to accounts at Poloniex, I use for NuOwned NuBot operations.
I’d prefer using Sidhvfpo93KGVpbu9pM3LgyiPdgesnT1G6, because that account is empty on buyside at the moment.
It’s the account, which runs at a quite tight spread trying to stimulate trades on the NBT/BTC pair:

I need to disable NuBot during the NSR sale, but @Cybnate’s PyBot operates at a similar and even tighter spread.

I wouldn’t want to use the other Poloniex account, because that one builds a $0.10 wall in case a real bank run happens:

and has some NBT for sale in case BTC nosedives.

I tried to create a tx using Cointoolkit with your help:

I put the input tx id b24342d957bf8deb5abf7ff19ff06c38520e99ee6a09797c2ed9b3895f09ed19 here:

Unfortunately the result is:

I entered N=1 and the hex key from the tx id of the value 22,600,006 (a9147077487df91c0166d33ee6079b0c2229788f6ac287) into the script field (as well as the amount):

I could create and sign a tx.

3,175,000 NSR to

Signed 1 (by masterOfDisaster) of 3/5


##Please check thoroughly! I’ve never done it this way before!

1 Like