Find someone who can read a PPC codebase (anyone will suffice, since it is better than nobody), pay these persons in NSR and only in NSR, no single NuBit must be printed for that
Use the gained centralized development capacity to implement a plugin system into the client, including libraries and wrappers that allow it so easily and independently develop interfaces for centralized custodian services
Develop a motion with payment processor interfaces or other plugins as suggested by you in your post. Assign a minimal and maximal value of NBT to each of these interface proposals and vote for it to pass. When the motion passes everyone can submit a code solution to the plugin at any time by applying for the corresponding NBT grant, where the promised compensation rises weekly from the minimal up to the maximal value to increase the incentive.
This would have been one possible transition to a decentralized development effort that is Nu focused. But all this will not happen, since shareholders would neither be willing to create more NSR, nor to find a suitable developer who can do the first step. It furthermore requires continuous attention from the shareholders on this specific project and not to another project.
But this is what I would suggest as development road map for a stable unit. And no, I am certainly not done with the concept, too much efforts have I put into this. Many ideas are floating around, from which several are inspired by Nu and which totally focus on the stable currency / money transmitter aspect.
Practically we should pay them with NBT (in its function as a stable currency) I think, but we should burn an equal amount of NSR at the same time or soon afterwards. I think with the new burning functionality soon to be released this is not an issue. Custodians can take care of that as part of the motion/grant.
Just an off-topic side note on an interesting suggestion.
Contractors of the main code repository should have never been paid in money, but only in shares, so its in their own interest that the project succeeds. I see this different with the plugins where people from outside who donât want to have anything to do with Nu but getting their bounty are still very welcome.
Of course these NBT have to be burned at some point, to make a zero sum. This wonât change until people stay with their money within the Nu ecosystem. You will (in my opinion) see soon that Nu started too early to make use of sell side LPCs when many long hold NBT will be used in the auction.
No more such liabilities! A strict money management on the cost of the shareholders directly (through NSR), not on the pegged unit, and an active participation to realize all this without getting totally ignored will be required. If the current shareholders are willing to suffer, then I think that Nu has all ingredients to provide non-existing tools that are useful today, and not in some potential future.
Nearly all contributors have had equity in the project. However, the problem with paying only in NuShares is that contributors need to pay bills, so they would be forced to sell NSR. Given the current thin trading volume, this would cause the NuShare price to decline considerably. It is better to have investors who intend to hold NuShares provide funds to pay contributors in NuBits.
If they need to pay bills, then they also need to sell their NuBits. If they sell their Nubits, then they sell into a custodian. The custodian then at some point needs to pay bills and sells to the next custodian.
Without any natural growth, as right now, this has to end in an NSR grant to burn these NBT again, so there is absolutely no difference. We just shift the same liability into the future.
EDIT: In fact, and I wanted to suggest this for some longer time, I think it could be a useful design property if shares are non-spendable. Shares can only be created through grants or burned for NBT if shareholders offer this possibility. But somehow I think that exchanges would vote against this motion
Peercoin community members such as mably and kac- have certainly read PPC code. Mably even are trying to re-write the wallet in Go.
This has been suggested to Peercoin but has gained no traction. Currently anyone who wants to do peripheral development has to read the code. This is great obstacle to Peercoin/Peershares/Nu growth.
We do have Peercoinj and Nubitsj library thanks to Matthew which allows for maintaining a wallet and send/transfer actions. https://github.com/Cybnate/NuBitsj
I think more can be done, but I for one wouldnât have a clue what is needed in the plugin system besides the already existing libraries and RPC calls in the current wallet.
Really well done mhps, this list is absolutely fantastic. People will soon realized how much money there is in this business, no matter if you implement this with NBT, BitUSD or whatever stable currency approach you are using. Those services give you a stable BTC, and this is something people want to have.
Of course you can also buy all this code, but it surely will be more expensive, so shareholders would need to decide to either put more personal effort in it or to print more NSR to compensate for this.
There is an important difference between selling NuShares to investors who are likely to hold them versus contributors who need to sell them to pay living costs. While the total NuShare supply will be the same, the market price will be higher if sold to investors, especially when exchange volume is low as it currently is.
Iâm probably derailing this thread with the post above, so to bring the focus back to the trust-less liquidity pool, I would like to make the community aware of some recent developments:
@woolly_sammoth will be taking a primary role in maintaining TLLP code going forward. He is working on the CCEDK API wrapper now.
When the CCEDK API wrapper is ready (likely hours or a couple days away), @Cybnate will be moving forward with her own TLLP operation.
@Nagalim is also moving toward setting up a separate TLLP operation.
Many thanks to @creon for taking the initiative to create this important piece of software. It has been instrumental in our efforts to end shareholder funding of liquidity operations in about a month. Iâm confident everyone would be happy to have @creon work on it in the future if his understanding of the situation changes.
When order match=false causes no orders to be placed we should enter a broken peg state where we start leveraging the nsr market to regain the peg.
I guess this (as well as arbitrage to even the walls off using other exchange custodians) will be somewhat accomplished by the cooperative pay model for the tllp, but only if people realize whatâs happening.
Sure, you can also just let two trading bots run on two different exchanges, from which one has LPC support and the other doesnât. Then you apply a large spread on the non LPC exchange and trigger the other trading bot on the LPC exchange every time an order got filled on the non LPC exchange, such that it buys back the funds from the custodian. The spread difference is your profit. This isnât hard to realize with the TLLP software.
I am willing to set it to true but what are the pros and cons of doing so?
PS: @creon , it is sad that you decided not to work on ttlp any more but I would like to thank you sincerely for your hard work on it. It was an intellectual pleasure to follow its development.
It will immediately trade into any wall that is breaking the peg. So if the price were .0045 and someone was selling at .004 and you had btc with ordermatch=true, the bot would buy nbt at .004 immediately.
Iâm having problems getting the server to credit orders. People are gonna help me out with it when they get the ccedk wrapper under control.
Ordermatch=true doesnât break the peg, it recovers a broken peg. So if it were on nbt/USD and someone was selling nbt for $0.5, the NuPool wouldnât put up any liquidity on buy side because itâs outside the 0.5% range. However, if you have ordermatch=true then the not will autobuy at $0.5, as well as any other order <$0.995, until it either runs out of liquidity on accounts where ordermatch=true or regains the pegs. Once it regains the peg it will put up all the liquidity on accounts with ordermatch=false or true.
