KarmaCoverage

I think it was on twitter. but there has been some educational email threads on the ILP W3 email recently. Adrian and a few others discussing ILP development.

I have been reading about SPSP today and wanted to create a thread for discussion on the various aspects of the ILP stack, (like used to be on this forum when RCL was being developed). If I am understanding correctly, by using PSK "Pre Shared Key", the two end points of a TX are able to share a fulfillment/receipt. I think this works by the sender requesting from the receiver the PSK, that way when the receiver gets the value transferred, the receiver can return a signed receipt to the sender, informing the sender that the TX was completed properly. Would it be correct/wrong to assume this same schema is used between direct peers in each hop within a multi hop ILP TX? Just trying to play some catch up, as I have not been able to stay on top of ILP's development and thinking.

@tulo Very true that the MM's risk will end up being reflected in the spread. That said, if there are derivatives available for risk management, one would expect a reduced spread in the open market. There will always be risk, MMs accept this as a reality of doing business. I believe you have done a bit of bot MMing? and expect/hope that your efforts have paid off handsomely and will continue to for a bit of time. Will check out links, looks interesting, thanks.

@tulo Volatility is not all that bad if you have the means to hedge / or do risk management. There is no way for a Market Maker to not hold some of the asset in inventory, true. This is why derivatives markets and and risk management strategist exist.

R3 met with Accord, which is the maker of the insurance industry's standardized "accord forms". They also did a meeting with the mortgage industry, mortgage registery/owenrship was a bit of a mess during the crisis, especially after they were securtized.

Regarding this idea for these digital asset tokens being, "a cryptographic unit of account attesting to your purchase of a perpetual license to access the network’s utility" I did a little research on this idea, and I think this is a possibly fitting pre-existing license type. An RTU license, Right-to-use license http://thesamblog.com/perpetual-vs-rtu-license/ from that site... "RTUs have one flat fees that include license charge, support and upgrade fees all lumped into one." Holders of XRP do not have to pay extra for Rippled code management, support, or upgrades, etc Then I found Cisco's worksheet for "configuring Right-To-Use licenses" that breaks down some of the ways an RTU can be set up. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/system_management/configuration_guide/b_sm_3se_3850_cg/b_sm_3se_3850_cg_chapter_0100.pdf I wonder how Ripple Inc has legally defined what they are selling when they have done private sales, presumably with a contract?

That might be it! but I dont look at Lets Talk Bitcoin often Yes it is, this is one of the key reasons I have not even entertained the idea of trying to get KarmaCoverage going via ICO/ITO. I think the argument can be made for any ledger where the token plays some part in the utility value creation of the network, or acts as a fee for access to the network's utility value, and gives no rights to any cash flow (like dividends) then there is some ground to stand on and make the argument that the token sale is the sale of a perpetual license to use the network. So IMHO these ITO/ICOs should be re-marketed as, "a cryptographic unit of account attesting to your purchase of a perpetual license to use the network" and then we are back to selling software licenses and this all makes sense again. sec definition of a security

Token as a perpetual license to use the network I cant find the source, but I saw a lawyer lady a few weeks back who was engaged in a conversation about all these ICO/ITOs being issued. The real legal concern is defining what the hell these token/coins represent legally. Some say they are property, others currency. FinCen & the IRS and other govts have pointed to both of those definitions, and then changed their mind. Anyway, this lady made the most coherent argument I have heard. Saying, "for tokens that have utility value in the ledger/network, those tokens represent a license to use the utility of the network". This is much like my old analogy for XRP within Ripple's network/ledger. The analogy was that XRP is like a postage stamp. A postal stamp gives you the right/ability to access and use the utility of the postal network to deliver a package from one address to another address. It is a token used to pay a transaction fee, just like XRP is on the Ripple ledger. I saw Corda using the postage stamp analogy. The disconnect remains in that most issuers of Stamps (evidence postage revenue has been paid) are governments, and not private companies. To the best of my knowledge, FedEx & UPS don't issue stamps, they collect Postage, which is revenue for postal/letter carrying services. With XRP, Ripple Inc / OpenCoin as a private company issued every stamp that will ever be "printed". This along with all distributed ledger stuff is new, and I think we just need to give the SEC, FinCEN, IRS, FED, and other government's version of these organizations some time to finally make a decision. If they wanted to slap Ripple into non-existence they would have fined them a lot more, and could have just shut them down. It appears the regulators in general are now taking this stuff seriously, and the US is falling behind on the regulatory front, but they are focusing attention. Hopefully one of these bs ICOs gets sued and we get some case law soon. If anyone knows of or can find the source on this, I would be very appreciative. I cant re-find it. Edit: https://www.sec.gov/news/press-release/2017-131

I think various RCL networks along with ILP can get pretty close to a solution, but that may leave some holes in the full scope requirements of the Fed.

https://github.com/Azure/azure-blockchain-projects/blob/master/bletchley/bletchley-whitepaper.md At the very bottom...

In all likelihood this is just in the provisional stage waiting for review. I think I filed my patent app in late 2012 and waited late 2014 for them to even take the first look. It would have to actually issue before you could pursue enforcement. They will probably not get anything issued till 2019. It would be great if Ripple Inc could put a patent in the bag, but the Supreme Court basically dropped a nuke on the intersection of Software and Finance with the Alice decision. I got my patent all the way to the end, and we were had defended, with only minor edits, all our claims. Then came the 101 rejection, which basically says you cant patent anything to do with finance and software is not a patentable subject matter. From wikipedia... The idea is that if you could do a process/method without a computer, no matter how unfeasible, just if you can theoretically do a process/method without a computer... then just because you do it on a computer does not make it patentable.

Ahh ok, now I understand. This is the key! This is what is different about KarmaCoverage than Insurance. Insurance is all 1st degree connections to a single hub. I call this the "Trust Graph", and the leverage created by the 2nd degree friends is what enables Risk to be spread out laterally across the network of trust lines. 50 1st degree connections is enough, and people dont in real life trust 500 facebook friends. Although there are super users, who are hubs of trust line connections. These would be Agents or Community leaders, they can have up to 500 inbound trust lines max. Here is one of Ripple's early investors, I dare say I gave him the term "Trust Graph".

There is a bit of a 'pay it forward' feel, but if you renew every year at some point your will be the one needing to tap the network for some liquidity. The profits (like in uber/airbnb/etc) are in operating the platform, not in supplying the escrowed value (car/home). I agree, and this could be in part from an ICO (although I am not wanting to get caught up in the speculative craze), charitable giving, or investment. On the investment part, I had to think about this for a long time, crossing off revenue models because they came with incentives which would under bad leadership open the door for the leadership to work the network for more profit. I have settled on Demurrage as the revenue model. The key here, like Ripple Inc, KarmaCoverage has a business model and is not dependent on ICO funding. There are also ILS (insurance linked securities) think of MBS but where insurance/risk is the underlying asset being securitized. I have spoken to these guys https://ledgerinvesting.com/blog/ and they look like they just got some funding. https://youtu.be/1upTUjeiPiU ..The problem with their methods is that the underlying indemnity contract insurance product is still highly inefficient on the higher frequency smaller losses. KarmaCoverage could also act as a source of data flow to improve the capital market side of the ILS pricing. I may reach back out to them because there is some benefit from adding in the KarmaCoverage social review layer for fraud prevention and to push up deductibles. Data flow is a big one. Each coverage request must be documented and there is a conversation curated around the loss event, and the solution showing just how much it cost, and that the funds from the network were used for the purpose intended. There is also lead generation revenue opportunity here to connect people needing a repair service, with a company offering that repair service. The service repair users can help price the loss event by placing a bid to fix the issue. Lead generation revenue again alleviates the need to depend on ICO funding. KarmaCoverage can be run with almost all user funds going back to users. Once it gets to scale, I'd prefer it run at 100%, but the demurrage income may be needed in the beginning. What do you mean by weighted trust lines? The problem with GoFundMe, is exactly what you said. People only show up with their hand out. KarmaCoverage in intended to be an annual service that users renew on monthly/annually. This is where the whole section on "Post Pay" via GoFundMe, vs "Pre Pay" by escrowing value on ledger and networking with 50 others you trust and are willing to help. Then it is not a big deal, just like nobody gets mad when someone else gets an insurance claims check. That is why the money was escrowed at the insurance company anyway. This is a big deal from a financial product design perspective.

You put XRP into Escrow to fund a Payment Channel, then you can do x1000 TPS off ledger, but the receiver can 'cash in' with the XRP in escrow via the PayChan when ever they want to. This enables off ledger transactions, and improves TPS scaling. Escrow & PayChan do not work with IOUs only XRP, because of the counter party issue of IOUs.

There would have to be an initial sign up period where the network would be in limbo waiting for enough users and trustlines to be connected. As those users came on network, and connected with their max of 50 trustlines, that would lead to inviting new trusted users onto the network. As the users connect their ability to create coverage increases. If you had funding to 'prime the pump' that would go into the central KarmaFund, and could be used to make users believe it will work, because, "look the money is there". It is this KarmaFund where charitable contributions would be allocated. Then each user also has their wallet (with 50 trustlines), and when they vote to help someone they said they would be willing to help, the money moves from their individual wallet first. After all votes are counted, and if the loss event has not been fully covered, then based upon the sum opinion of all the voter/reviewers matching funds will be paid out of the KarmaFund. I thought I had all this fancy stuff figured out, but then when I found Pure Takaful, I didn't actually come up with anything. Takaful has a central account and individual user accounts. I guess if I added anything it would be the 2nd degree connections (friends of friends), this is more like Hawala which is what RCL was originally built for by Fugger. So KarmaCoverage is Takaful coverage methods + Hawala flow of funds. Each risk type, or market, will have a different Loss Frequency. The amount of leverage KarmaCoverage can create depends on the Loss Frequency. This is the tricky part with a Life Events coverage... what the hell is a "Life Event"? It could be anything, if the Loss Frequency gets above 20% (meaning 1 in 5 will have a loss) then... you could still use KarmaCoverage the amount of leverage it would create is just reduced. With a 10% Loss Frequency, users can get 10x coverage on average, and a max of 25x coverage. Each of these risk markets, would have it's own RCL where the true real world Loss Frequency can be determined and change over time. But all of them contribute to the central KarmaFund, and this is where the business opportunity for KarmaCoverage is, in connecting and making markets (think ILP) between the RCL risk ledgers. As far as "the unknown providers". I think of it like any P2P service, the service must be provided by a peer to another peer. The service here is Liquidity, "Liquidity as a Service" or LaaS is the term I am going to stick with for now. I use this LaaS term because it is the individual peer who are escrowing value on ledger, and because it is on ledger it can be liquid and flow to any other peer in need liquidity to fill a financial hole. Just like it is car owner, not Uber, who provides the service. With LaaS it is the giving users who provide the Liquidity as a Service directly peer to peer. In a sense this is close to the idea of a Market for Float, but different use case/ market. Your idea of "the users pay the money back", makes sense in a LaaS mindset because Liquidity Risk is related to a time frame. Once that time frame has passed the need for the liquidity will have passes. You see this in businesses getting a line of credit. They use it to buy inventory, sell the inventory, and pay off the line of credit. I will have to think on this some more, very interesting.