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.
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.
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.
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.
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.
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 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.
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.
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.