P2P Markets -- Escrow Functions

P2P Markets -- Escrow Functions

Report on Research, Testing and Lessons Learned Building Blocks Hackathon at Consensus 2016

Background: I am building P2P Markets, an online, peer-to-peer two-way auction market. Initially this will be a secondary market for small business loans. There has never been a secondary auction market for loans, quite simply because the profits to be made in the 'spread' between what the borrower pays and the lender gets have an irresistible appeal to the greed of loan dealers and brokers. Dealers pay low and sell high because in the existing markets they can force themselves between the borrower and the lender and take a significant percentage of the spread. If however the borrower and lender could deal directly with each other as peer-to-peer principal parties there would be no spread and consequently no obscene profits for dealers.

If borrowers and lenders are to deal directly with each other they require sophisticated tools, first to find each other and then to analyze credit and risk; to engage in sophisticated negotiations of the terms of a loan contract; to produce legally-compliant documents which state that contract; and then to monitor the performance of the loan going forward and to service the collections and payments required--and all of this without intermediating a dealer or even an exchange between them.

P2P Markets' solution is to provide those tools as Software-as-a-Service to the principal parties. Our business model is to charge $0.25 for each invocation of our APIs--and that's all. There is no spread between the principal parties to the deal. There is also no data about the contracts or the principal parties themselves which might be owned or controlled by dealers or by an exchange. All of the data which constitutes a deal, and all of the detail of negotiating that deal, is committed to one or more blockchains, from which P2P Markets' software allows potential principal parties to recover it and engage in deal negotiations based upon it.

The fundamental abstraction which governs access to this data is the common law concept of privity. As principal parties to a deal, a borrower and a lender each have full access to and authority over the data because they have full privity to the data they have created and, within the scope of that data, full privity to each other.

The problem which I came to this Hackathon to solve is how to implement the escrow functions which such deals will often require in a manner which fully respects the concepts of privity, software-as-a-service, and peer-to-peer principal dealing which are the fundamental premises of this system.

I examined and played with the IBM 'Marbles' code and the Block Apps 'Pizza' demo code which were provided to the hackathon participants, because those claimed to addressed some portion of the escrow problem which must be solved in implementing peer-to-peer dealing. In short, all of the code which I examined had fundamental conceptual and design flaws which made it unsuitable for implementing escrow functions in P2P Markets, as designed. The exercise of researching that question, however, has made it possible for me to design the appropriate escrow functions which P2P Markets will require,and I expect to have those functions implemented as microservices within P2P Markets before the end of May.

In brief, the conclusions of this research are that:

1) Escrow functions, by their nature, cannot be performed by either of the principal parties. Implementing escrow requires creating a new class of participant in these deals and defining appropriate privity--and appropriate access to data, consequent on that privity--for escrow agents.

2) There are three distinct classes of escrow functions, which I have labeled Receiving, Appraisal and Custody. Each of these 'real world' functions requires a software implementation, as well as implementation of software to effect its reversal. Each of those six function groups requires a different class of privity as well as a different definition of the scope of data to which it has access. reliminary research (this morning!) indicates that the ether.camp project may have the best tools and underlying abstractions for implenting those functional artifacts.

In conclusion, a work still very much in progress, but helped along significantly by the resources assembled for this hackathon. Thanks to the sponsors and organizers.