Manfred,
(Sorry for the delayed response.) Iāll try to address your questions as briefly as possible:
Q: How high is the collateral (credit + interest?)
A: Credit + interest + margin
Q: Is there collateral for both?
A: No. Collateral is only put up by the borrower. The arbiter software agent validates that the lender sent the funds to the borrower. This is determined by inspecting the flow of funds on the appropriate blockchain explorer. The software arbiter agent is a decentralized consensus mechanism.
Q: As collateral currency is not the same as credit currency, how to deal with price volatility (can render collateral as too low
A: The margin component of the collateral protects against deflation of the collateral currency vs the borrowed currency. If the borrowed currency drops in value relative to the collateral currency, there is an incentive for the borrower to repay in that the collateral has a higher value and it is to the benefit of the borrower to repay the loan to get back the higher valued collateral. On the other hand, if the borrowed currency increases in value relative to the collateral currency, an adjustment needs to be made (additional collateral deposited) to account for this and re-establish the balance in value. So an initial margin component is added to the collateral to attempt to account for this. It is not 100-percent as no one can predict the value of currency units once the loan has been made. The amount of volatility in cryptocurrency prices is a challenge to manage via a decentralized consensus mechanism due to response times ( canāt be done synchronously.) Iām looking at a number of approaches to mitigate this risk but in concept, it is the same type of problem that centralized exchanges handle in their margin facilities. Bitcoin multi-signature addresses can accommodate multiple collateral deposits. It complicates transaction handling but could be utilized to provide incremental collateral deposits for decentralized margin calls. Decentralized margin calls will need more experimentation.
Bottom line is that volatility is always a risk that will need to be managed in the terms and conditions of the lending contract.
Q: If there are several arbiters, who has the right to issue the contract if there are timing issues (2 parties take the same offer at near same time)?
A: The arbiter is automated software code that performs arbitration through a Merkle DAG structure with digitally signed evidence of workflow and a decentralized consensus algorithm (in principle, similar to Bitcoin mining.) There is never a single arbiter processing the lending workflow. It is always a community effort when it comes to performing the work and distributing rewards.
Q: I assume the peers have to wait for at least 1 confirmation after the deposit, otherwise there is double spend risk
A: Correct. The collateral deposit is a Bitcoin (other collateral currencies will be added if they can support 2-of-3 multi-sig) 2-of-3 multi-signature transaction. Confirmations are handled just like other Bitcoin transactions. The borrowed currency (loan principal) transfer should follow confirmation procedures according to that currencies protocol recommendations.
Q:What if the lender never sends the money?
A: The collateral is returned to the borrower. And transaction fees are distributed in a way similar to the Bitsquare trading protocol to properly incent the involved parties (borrower + lender). Arbiter fees are distributed through the decentralized consensus algorithm.
Q: If a peer is not online at the matching time, the deal will fail I assume.
A: Short answer, no. The loan is modeled as a smart contract. There are defined response times that are specified in the contract and if those time limits are exceeded, then breach of contract terms are enforced. There is a bot interface that can always be running to provide for needed levels of automation to respond to defined events. So if the automated bot interface is not online or available, then yes the deal is at risk. The counter party must be present for the contract to be agreed to. I have focused on having the bot interface as a rule-based approach that will allow the contract to proceed without a human presence (manual acceptance). The contract terms and conditions are specified (no ambiguity) so that acceptance and execution can be automated to the greatest extent.
Q:I think there might be tricky cases where the collateral is already paid but then the peer is not available.
A: There are a lot of tricky cases. Iām still working on continuous improvement in the prototype.
Q: What if the arbiter is not online or does not fulfill his role?
What if the arbiter colludes with one peer?
A: Again the arbiter is an automated, p2p decentralized consensus algorithm. Arbitration functionality is distributed across many peers. So colluding would require something like the Bitcoin mining >50% attack. Given that arbiter functionality is available on each and every node (even though it is on an opt-in basis) the expectation is an acceptable number of arbiters would always be online.
Q: Any more concrete ideas how the DAO would work?
A: At this point, it would be similar to Bitcoin mining rewards with the reward being the pool of fees paid on lending transactions. (There is no token or coin issued to users of the system. No new altcoin here.)
Q: How do the software agent resolve software bugs and usability problems (90% of all disputes in Bitsquare are in that area)?
A: This code will be open-source. So a development community would be responsible for handling software bugs. Very similar to how Bitsquare and others address these types of issues.
Iāll provide additional details in the documentation that accompanies the prototype code. Once I have the code ready for others to inspect and stress test, I plan to create a project on github and start forming a community to extend the experiment.
regards,
Doug