[Passed] Bonus for multisig liquidity pool

The introduction of trustless liquidity pools has been a very important development in our liquidity operations. However, this method of providing liquidity should not be used as our only form of liquidity. The reason for this is that pools based on @Creon’s software can only provide tier 1 liquidity, which is high risk and high cost. To lower the overall cost of liquidity, we need most of it to be in tier 3 multisig addresses and below, where it will be safe from exchange defaults that have been so devastating. There has been money waiting for this service to be offered and muchogusto has in the past pledged to place 25,000 NBT in such a pool.

What I would like to see in the coming months is the TLLP pools providing most of the tier 1 liquidity, with multisig pools similar in design to NuLagoon providing tier 3 liquidity. Long term a concentration of liquidity will be placed on B&C Exchange. The escrow potential of B&C Exchange can be utilized to reward liquidity providers for locking their funds to ensure they will provide liquidity for a specific period of time. So, long term, I expect TLLP to provide tier 1 liquidity with a concentration of that on B&C Exchange, while the pools that meet the conditions below and resemble NuLagoon will also have a large presence on B&C but will also be able to commit to locking some of their pool funds on B&C for tier 1 liquidity for an extended period. Note that on B&C Exchange the difference in the safety of funds in tier 1 versus tier 3 is minimized. This will permit Nu to make statements such as “we can guarantee at least 250,000 NBT in liquidity will be provided over the next 90 days.” This will be possible because B&C Exchange signers will not release the funds used for liquidity during the contract period.

So, these NuLagoon style pools have an important role to play in present and future liquidity operations. They will allow for individuals who don’t want to be involved in daily liquidity operations such as @muchogusto to contribute and benefit and will also permit liquidity to be guaranteed for a certain period of time in the future.

I would like to point out that @henry at NuLagoon has pioneered a pool architecture that provides buy side support while completely eliminating BTC volatility in the form of pool C. Additionally, he has created pool D which permits leveraged speculation on Bitcoin with an added 13% return per month. The pool architectures pioneered by @henry have tremendous potential to provide cheap and user friendly liquidity, but need to employ multisig addresses to reach their full potential, in my opinion. Providing incentive to use multisig addresses for these types of pools is the primary purpose of this motion.

Motion RIPEMD160 hash: 806780895db71afc8302e59cd65765a35e598fc8

=##=##=##=##=##=## Motion hash starts with this line ##=##=##=##=##=##=

A reward of 500 NBT via custodial grant will be given to the operator of liquidity pool that meets the following conditions:

  1. Uses at least 2 of 3 multisignature Bitcoin and NuBit addresses for managing off exchange user funds.
  2. At least 75% of funds are held off exchange in the multisig addresses as tier 3 liquidity.
  3. Does not require pool users to run any software regularly to provide liquidity.
  4. Rebalances tier 1 and tier 3 liquidity at least 3 times per week. For instance, if a pool keeps 15% to 25% of all funds in tier 1 on an exchange, then three times a week the ratio would be examined and funds moved to adjust the percentage if it fell outside the 15% to 25% zone.
  5. Reports tier 3 liquidity (buy and sell side) at least once a week.
  6. Meets above conditions for 30 days with the intent of continuing to do so indefinitely.

=##=##=##=##=##=## Motion hash ends with this line ##=##=##=##=##=##=

Verify. Use everything between and including the <motionhash></motionhash> tags.

I welcome comments and suggestions for changes to the draft version of the motion.


Would be great to see something like this. And I like to see something added to ensure the Tier 3 liquidity is reported each time a rebalance takes place or funds are being withdrawn or added to Tier 3. Even just a weekly report would help the Shareholders to enable to vote appropriately for interest or burn rates.

1 Like

Just a quick question. I’m a little outdated with the latest info, but as far as I know TLLP uses its own bot to place trades called Pybot correct? If we were able to connect NuBot to the TLLP software (instead of Pybot), would that enable funds to be moved between tiers 1, 2 and 3? Or is it impossible for TLLP to work with tier 3? I’m not sure if it’s just a matter of software coding or if it’s just not possible because of the design of the system.

Tllp uses api calls to verify market orders. It is currently incompatible with any tier other than tier 1. We may be able to get more sophisticated in the future, but for now NuLagoon and such ‘trusted’ liquidity pools are our best bet.

I will vote for this motion, though I think it’s dangerous not to spell out targets, rates, and spread. Still I can hardly see an operator taking the time to set up such a pool and not making those variables relevant to previous operations.

Edit: I was wrong about Nubot:

So basically this is a draft for a motion that would add a 500 NBT bonus to the reward specified by a centralized liquidity pool a la NuLagon provided that the pool keeps 75% of the funds in tier 3 under a multi-sig regime.
I think it is a reasonable reward and such a pool would be useful.

PS: typo

Bump, no more views on this?

Maybe NSR holders just wait for the draft to be finalized in order to start voting.
The motion provides a huge benefit for the security of user funds (which should have a big benefit for the attractiveness of such a pool) for a comparably little investment of 500 NBT.
There might be just not much to discuss about…


hashed: 806780895db71afc8302e59cd65765a35e598fc8

The reward is applicable only to the first 30-day period, right?

A minimum of amount of liquidity provided should be required even 500 NBT isn’t a large reward.

“Create it and they will come”.
Although I would have preferred to see a minimum amount provided, I don’t think it is necessary.
When an operator meets the conditions it is also likely that they will make an effort to advertise it.

And I think there is demand for such an offer especially with condition 3 anyway and in the unlikely event there is not, the damage is just 500 NBT. Worth trying, will add this to my datafeed.

1 Like

I agree. It would be better.
500 NBT could represent 10% commission. So a min of 5000 NBT total liquidity provided could be appropriate.

Someone running a TLLP server with 10 NBT and manually collecting users’ fund could meet all the requirements. How much fund will be collected depends on compensation and many other factors. Even no other user comes (there is no way to prove) this motion will have shareholders give out reward. Intention to go on indefinitely is just intention.

Sorry to notice this late. Too many things are going on.

We would still need to vote for someone running a TLLP server with a maximum of 10 NBT, which is unlikely to happen.
The existing operators don’t have such low restrictions for their pools. Low risk, I believe.

No there is nothing against self-funded pools running by strangers in the motion. Shareholder approval is not needed. TLLP is just there to set the walls. If it’s a NBT/USD pool, even TLLP is not needed – just manual place the orders then you have the walls up.

You have a point there. Maybe it needs an amendment…

This is open end so abuse or modification/nullification is a matter of time.

I actually disagree that it will be taken advantage of, though I whole heartedly agree with the balking at the precident we’re setting. As this is a one time bounty for the creation of a program, I think it highly unlikely that someone will go through all that effort not to run a pool and also get liquidity compensation out of it.

But yah, I’ve always been keen on this motion having minimum targets.

Actually this isn’t how the motion is worded.
That’s what caught @mhps’ attention and made him write

Based on the wording of the motion each liquidity pool that meets the conditions can claim the reward.
I recommend including exactly that limit into the motion - the first x liquidity pools that meet the conditions, shall be allowed to claim the bounty.

You can try to prohibit pool operators from claiming the bounty asserting they violate point 6. of the conditions and don’t intend to continue and do so indefinitely, but it’s easier to limit the number of bounties right now.

From a contractual point of view it would be bad to allow unlimited bounties to be claimed.

I didn’t recognize that when I read the motion. Nice catch, @mhps!

1 Like

It’s almost impossible to prove. Even the person ends up not continuing after claiming the reward, he/she can claim there was an intention but things didn’t work out. Then you shouldn’t complain because you only asked for intention.

It doesn’t take an abuser to have problem. The motion rewards anyone who tries, which Nu now needs. But it doesn’t reward more to someone who does a better job, which isn’t good in the long run.

1 Like

There have been objections based on the perception that the reward may be given multiple times to different pool operators. That certainly wasn’t the intent, which I think was generally understood. The following phrase uses the singular form for “A reward” and “the operator of liquidity pool”. It does contain a grammatical error which is probably not helpful. It could be more clear, but I’m not sure it is worth editing, rehashing and starting voting over. I would like some more input on whether there is really enough ambiguity to require modification. If all agree the intent was to provide a single reward, that is sufficient.

There is also concern about the level of liquidity provided and other types of gaming. Condition 6 requires that the pool operator “Meets above conditions for 30 days with the intent of continuing to do so indefinitely.” I think this gives shareholders the leeway they need to to exclude to exclude pools that don’t really meet the intent of the motion, which is to provide incentive for the creation of a sustainable multisig pool where pool participants simply hand their funds over to the multisig operators. Even if little liquidity is provided in the first 30 days, that isn’t important to me as long as there is reason to believe the pool will persist and grow.

Basically, is there anyone who refuses to vote for the motion because of these ambiguities that would vote for a clarified version? If yes, I will change it. If no, I think it is sufficient as is.