nahollander

The collateral can be any other asset that is represented by a cryptographic token. Right now, few crypto-assets map to real world assets in some capacity, but we're willing to make a bet that this will change faster than most expect.

Already, though, there are many interesting assets in the world of crypto that are particularly well suited to being put up for collateral -- namely, the emerging class of crypto-collectibles such as CryptoKitties.

The collateral is held in a smart contract -- if the borrower disappears and fails to make a repayment, his collateral becomes eligible for seizure.

This happens quite regularly in the world of margin trading.

Imagine the following:

1. I own ETH, and want to hold my ETH position so I can enjoy price increases, but I need liquidity to live my day to day life and, well, it's hard to pay for things with ETH. 2. Instead of selling ETH and exiting my position, I put ETH up for collateral and borrow a stable-coin (like DAI) against it. That way, I maintain my price exposure to ETH, but have liquid cash to use for my day-to-day needs.

In the current implementation / use cases we're focused on, your collateral, which is held in a smart contract, would become eligible for seizure by the lender.

Thank you! :)

We've pretty deliberately opted out of baking jurisdiction-specific protections (be they KYC / AML, accreditation, etc.) into the protocol insofar as we really want this to be a universal standard that's jurisdiction-agnostic -- to give a somewhat crass analogy, most developers would agree that it does not make sense for content-protection against, say, child pornography, to sit at the level of TCP / IP. Jurisdictions vary widely in how they treat lending law, and so we've opted to be as flexible as possible on a technical level.

With that being said, we're actively working on making sure that, at layers above the protocol, developers have an easy time plugging in / restricting functionality on the basis of regulatory parameters. There are several interesting projects in the decentralized identity space that are tackling ways of natively attesting to KYC / AML screening on blockchains like Ethereum, and we're actively in conversations with them to make sure we maintain compatibility.

Beat me to the reply :)

Indeed, even with a fixed supply token, a borrower would simply have to come across the necessary amount of principal + interest in the loan term.

Yes -- two parties are permitted to lend money to one another in a mutually agreed environment. It's important to note, though, that developers who build end-user applications on top of Dharma ought to be cognizant of lending regulations / securities law in the jurisdictions they are active in. However, we've opted to build Dharma in a non-jurisdictionally-biased manner -- we think that jurisdiction-specific regulatory restrictions are better implemented at the application layer rather than the protocol piping.

Thank you for pointing this out -- I've flagged our team and we're looking into it.

Yup -- there are several. The most mature relayer project on Dharma we're aware of is Bloqboard (bloqboard.com), though I believe they are not ready to launch on mainnet quite yet.

Thanks for the kind words!

In the short-term, as you correctly alluded to, we're focused on loans that are fully-collateralized on-chain. In the future, however, we hope to integrate trusted third-party underwriters into the network in order to open the door for unsecured loans. There are many technical / game theoretic challenges to be solved on this front, though, so we've included unsecured loans as an "experimental" feature set in this initial release.

Thank you! Glad to hear that you enjoyed the tutorial.

There are numerous ways in which Dharma debt agreements can interface with insurance contracts:

1. We've already seen some members of our developer community working on trustless credit default swaps -- which are functionally insurance contracts that use the programmatic endpoints of Dharma debt agreements to assess claims on defaults. 2. For non-fully-collateralized insurance contracts, Dharma debt agreements can serve as the mechanism for tracking and administering the tokenized bonds that capitalize the insurance contract.

Debt agreements aren't required to be underwritten in every instance -- it's an entirely optional addition. If you want to see an example of a debt agreement in which there is no underwriter or middleman and collateral is trustlessly secured -- well, it's linked as OP :)

For points 1 and 2, it's no secret :) See for yourself: https://whitepaper.dharma.io

For point ,: you're correct in that we (as in the crypto community in general) have yet to come up with good on-chain governance mechanisms, so its likely that robust decentralized governance systems are at least a few years away.

@kang -- while I don't disagree that there's no shortage of snake oil and hand-waving in the blockchain industry ("Blockchain for X! Huzzah!"), I do disagree with your point about whether there is an efficiency gain to be had from representing debt agreements on a blockchain. The primary benefits are:

1. An ability to trustlessly hold and release digital collateral on an entirely peer-to-peer basis. This entirely removes the necessity for a whole class of middlemen that seek rent for existing lending agreements. 2. An ability to trade one's ownership in a loan as a cryptographic token -- again, something that necessitates various paying agents / clearing houses / intermediaries in the traditional capital markets ecosystem.

Re: decentralization -- that's a fair point. Right now, Dharma is functionally a centralized code base controlled by a centralized set of contributors. In the future, however, we hope to transition to a decentralized governance model so that the protocol can serve as a piece of common, shared public infrastructure -- unfortunately, we don't have robust enough decentralized governance models quite yet in the crypto community.

In all seriousness, this isn't a _totally_ unreasonable proposition -- Vitalik proposed an interesting route for creating stable tokens using baskets of debt obligations in a CDO format: https://ethresear.ch/t/collateralized-debt-obligations-for-i...

Perhaps unfeasible to appraise given that CryptoKitties haven't coalesced around any sort of stable value, but it'd be interesting to see what the volatility of NFTs like CryptoKitties is in comparison to normal tokens.

Hey HN! We're the team behind Dharma protocol, building the infrastructure for the tokenized debt agreements on the Ethereum blockchain. In this code school, we teach you how to build a loan collateralized by a CryptoKitty. We hope you enjoy! If you're interested in learning more visit us at dharma.io or join our chat.

Re: FV -- I admittedly have a surface level understanding of the entire subject matter. If you have any good primers and / or resources, I'd love to hear them.

re: Pact -- sounds super cool. I look forward to reading the white paper. Would be happy to scan the drafts if you'd be interested in sharing too

re: SEC -- just saw that too. I wouldn't say I totally disagree with the decision -- by Howie test standards, a governance token like DAO is functionally a security. Whether that jurisprudence will extend to grayer-area app coins and such is the real question.

At the moment, not planning on a token sale. Largely because of the concerns you've alluded to.

Not necessarily. I think a great example of something that smart contracts enable in a lending scheme is built-in secondary market functionality. A lot of marketplace lending platforms have built in proprietary secondary markets, but none of them are anywhere near as liquid as crypto markets are in general, and the vast majority are not interoperable, to my knowledge.

Your ownership in a loan on Dharma is denominated by a cryptographic token like Bitcoin, Ether, or any other, meaning its just as easy to trade your stake in a loan as it is to trade a cryptocurrency.

Assets built on open protocols are fundamentally easier to build products and technologies around -- insofar as they lower the barrier to entry for developing financial applications, their openness is extremely valuable.

Exactly. Tala's a great analogy insofar as developing world microfinance faces a lot of same challenges Dharma will likely encounter -- namely the lack the of legal recourse for defaults.

Not as of yet, but I'd definitely be interested in exploring the possibility. If you know of any good resources or primers on those, please do send them my way.

I think the problems you're alluding to are problems with the blockchain ecosystem in general, and I don't purport to have a silver bullet to solve the inherent issues with immutable software deployments, particularly in financial applications.

But, after all, a dark horse 20 year old college dropout spearheaded the development of Ethereum, and the technology now secures nearly 20B worth of value.

Maybe it's impossible to truly build processes for secure software deployment auditing in this space -- in which case, it's unlikely blockchain tech will succeed as a technology in general -- but I hold an optimistic view that, as formal verification techniques for smart contracts get fleshed out and easier to use, best practices will emerge and it will become easier to build secure contracts on blockchains.

Hopefully, until that point in time, Dharma won't get caught on the wrong side of history.

Forgive my youth and naïveté :)

Credit-risk assessment is indeed the most brittle aspect of what I'm building.

In short -- borrowers have to get a cryptographically signed attestation from what's called a Risk Assessment Attestor in order to request a loan in Dharma. RAAs use whatever means they have to assess a borrower's identity and creditworthiness -- be that through social media logins, uploaded identification documents, authenticated phone numbers, their loan history both on and off chain, etc. They are compensated for this by a fee that is allotted to them in the loan contract. Ostensibly, borrowers are deterred from defaulting on their loans insofar as their future creditworthiness on the platform will be marred.

For the time being, Dharma Labs is the sole RAA of the protocol, but, as time goes on, we hope to build mechanisms for allowing other trusted third parties to enter the ecosystem as RAAs.

Not off topic in the slightest! In fact, all too topical, given the past few weeks.

For what it's worth -- I'm a former engineer at Coinbase / Google and recently graduated from Stanford. Though I didn't touch Solidity as part of my work at Coinbase, I've been following Ethereum extremely closely since its beginnings, and any mainnet release I'd push forward would certainly undergo rigorous third-party auditing at the smart contract level. I've also been iterating on this protocol for the better part of the past 9 months, so this is by no means a weekend project.