
Show HN: Dharma – Programmable Peer-To-Peer Loans Using Ethereum Smart Contracts - nahollander
Hey HN!<p>My name&#x27;s Nadav Hollander, and I&#x27;m the Founder of Dharma.<p>Dharma is building an open-source library that makes it really easy to programatically borrow and lend cryptocurrencies using smart contracts on the Ethereum blockchain.<p>Today we&#x27;re launching our Alpha Testnet release -- a command line tool that allows you to<p>1. Access a line of cryptocurrency credit from the command line in under 5 minutes
2. Easily build a bot that auto-invests in loans under hyper-customizable, programmable criteria<p>Check it out: <a href="https:&#x2F;&#x2F;github.com&#x2F;dharmaprotocol&#x2F;dharma-cli" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dharmaprotocol&#x2F;dharma-cli</a><p>Why I Think This Is Cool:<p>1. Loans in the Dharma Protocol are basically miniature ICOs issued by borrowers -- an investor&#x27;s stake in a loan is held in a digital token that entitles them to future cash flows.  That means loans are just as tradeable and moddable as Bitcoin or Ether, and packaging loan tokens into tranched debt instruments of all shapes and sizes is relatively trivial to implement in an Ethereum smart contract.<p>2. Dharma is an open protocol.  This opens the door for any client application, including existing online lending platforms, to tap into a non-proprietary army of lending bots as a source of lending capital.  This has the potential to dramatically lower the cost of capital for online lenders -- and, in turn, borrowers.<p>How This Can Be Better:<p>1. Loans in the Dharma Protocol are slow and expensive.  Ether gas costs are fairly steep for writing the requisite loan data onto the Ethereum blockchain, and an on-chain auctioning mechanism places a bottleneck on how fast a loan can be funded.  We plan to address these issues by migrating towards an off-chain auctioning mechanism layered on top of a Kademlia-style P2P network.<p>2. The identity verification mechanisms we use to assess baseline creditworthiness are very weak -- any mainnet release of the protocol would necessitate much more robust KYC flows.<p>Please play around with the CLI -- would love to hear feedback!
======
nicpottier
Forgive what might be an obvious question, but though I see there is a concept
of trying to determine the risk of a loan, it isn't clear to me how that is
actually done.

What is used as a source of identity of the borrower? IE, how do you punish
bad borrowers on future loans? Or does that fall outside of this?

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

~~~
weego
Risk assessment is literally the entire product is it not? Loans are not a
technical problem to solve, and there's no inherent usefulness in it being a
smart contract. A guy in a office is not a risk assessment strategy.

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

~~~
MichaelGG
So Dharma should just offer loans in tranches and let them be tradeable on
Ethereum?

Also if you're loaning in ETH, but presumably people need the loan for USD-
based operations, what do they do when the price of ETH spikes?

~~~
jstanley
Presumably people doing USD-based operations would take out USD loans, and
people doing ETH-based operations would take out ETH loans.

------
tyingq
Slightly off topic, but the recent Ethereum hacks have created interest in how
to write secure contracts with Solidity. That is, despite some of the built in
barriers, like functions defaulting to public, awkward guard code limitations,
etc.

I would imagine if you have some expertise in that area, it would be of
interest here. Might also help put some confidence in your specific use case.

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

~~~
buckie
This project is simultaneously a great example of the democratizing effect of
Ethereum while also being truly terrifying. A Stanford '17 grad with a few
internships worth of industry experience is able to create and deploy a peer-
to-peer loan infrastructure. This isn't meant to be demeaning in any way, I'm
just remarking on how incredible of an accomplishment it is for both you and
Ethereum that the previous sentence isn't fantasy.

Now, I'm someone with ~10yrs experience in finance/production
engineering/regulation. That doesn't mean I'm right, just that I've been in
the trenches for far longer and seen this type of domain from a number of
sides over the course of many years. I need to at least mention that, well,
__this project is probably a bomb and you should be really careful with it __.
I, at least, wouldn 't want to be the next DAO dev (e.g. project takes off
quickly, unseen exploit exists, I lose some 10's of millions of other people's
money) at mostly a personal (I'd feel guilty) and career trajectory level.

The Parity multi-sig bug occurred in a solidity shop that was founded by the
father of the language itself. It got past a serious audit and had the best
eng process known (for solidity) enforced. The odds that your code --
currently unaudited correct? -- doesn't have an exploit are, while impossible
to accurately calculate, quite remote. Even an audit, as shown by Parity, is
no guarantee. And while yes, we're all human so there is always the chance for
a bug, your system could be the next ITO market and thus could gain a huge
amount of attention (from both regular folks, regulators, and hackers).

I'm not saying you shouldn't do it (I wouldn't but you do you) or that you
must have more exp to do it. I'm just recommending to be careful. Have fun and
good luck!

~~~
nahollander
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é :)

~~~
buckie
No need to forgive. You're not wrong nor naive. I'd pin the difference as one
of personal risk tolerances. I have much less than you, that's all. Right now
Solidity is the only choice of public smart contracts. All I meant before was
that this is an impressive project and to be careful.

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

This is a really common trope in finance -- the trader/quant/manager/pm who
thinks that he's god's gift to earth because he made so much money (and a
system that made even more). I'm not saying that's what's going on in
Ethereum, far from it, just that people who make a lot of money tend to think
they are worth that amount of money (usually they are just fortunate) and that
using monetary value as the sole justification for one's actions is
(generally) wrong.

While I disagree that Eth is actually valued at $20B -- if you can't get even
a fraction of the $20B out of the market then it's not worth $20B in value...
I bet the buy side of the Eth market supports around $100M-$300M max -- that's
neither here nor there.

The Ethereum ecosystem is, invariant on the value it represents, truly
impressive and Vitalik's work is amazing especially given his experience level
prior to it. I wouldn't say that the EVM is well designed in the slightest but
the rest of the system is. It's closer to a 80's era CPU than a modern VM. I
get why it looks like it does -- taking the bitcoin bytecode and extending it
as little as needed -- but I disagree with the approach at a technical level.
VM's are supposed to do more (e.g. handle dispatch and library loading) and to
not support that means one must implement it in the language (like an ASM
compiler does) which in a blockchain context consumes the limited gas you
have.

> I hold an optimistic view that, as formal verification techniques for smart
> contracts get fleshed out and easier to use

100% Agreed, though I don't think Solidity will have it anytime soon (3-5 year
min for whole program verification that experts can use, I know some of the
people working on it). The path the solidity FV people are following is a
long, hard research path (close to what they did for the seL4 microkernel).
Moreover, I know a ton about this because I built the first whole program
formal verification system (compiler + DSL) for any smart contract
language[1].

I built it for Pact, the language we[2] built to address the problems we saw
with Ethereum's approach in enterprise contexts, that's FOSS but currently
only available for on-chain use on our private platform. It wholly fixes the
"immutable code" problem[3] via cryptocharters -- think of them as a module
(smart contract) that have native support for both decentralized and
centralized governance mechanisms for updating contracts and migrating the
data they store. There's a bunch more stuff that Pact gets right, but that's
what the papers are for describing.

Keep in mind that formal verification isn't the "end all be all" for program
safety. While it massively advances the state of the art in that regard you
need more than just FV because FV still requires human effort (just vastly
less/safer than regular/auditing testing). It's just that FV is SO damn rare
that most people, including myself until last year, (a) have no idea what it
looks like and (b) have no idea what to use it for. People seem to think that
an FV-capable language will solve all of their problems. No, it won't.

How many people going to become experts in SMT/Coq/Isabell just to write a
safe smart contract? They, but Coq especially, make Haskell (which already
scares people off) look like a cuddly puppy. What we'll need is a smart
contract language that was designed to empower people to write safe code from
the start + an FV system + a FV DSL that regular devs can use to leverage FV's
power without having to become an expert in it. This is, unsurprisingly,
exactly the feature set we have built for Pact. If you think I missed/should
add a feature for empowering safe contracts I'm all ears (seriously,
criticism/ideas are always welcome).

Wait a couple weeks and we'll have the public chain whitepaper(s) out (we're
still refining the wording).

[1]:
[https://youtu.be/Nw1glriQYP8?t=1072](https://youtu.be/Nw1glriQYP8?t=1072) \--
my co-founder is presenting it

[2]: [http://kadena.io](http://kadena.io)

[3]: "immutable code" gets you laughed out of the room in industry

Edit: this came out when I was writing the response... are you planning to
sell tokens in the system? If so, again, be careful.

"SEC Issues Investigative Report Concluding DAO Tokens, a Digital Asset, Were
Securities" [https://www.sec.gov/news/press-
release/2017-131](https://www.sec.gov/news/press-release/2017-131)

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

~~~
buckie
### FV Resources

These are few and far between. My paper on it is soup to nuts for how we do it
in Pact which, while technical, should be somewhat approachable for most devs
to grasp (I tried at least -- representing a program as equations is just an
abstract concept).

Until it comes out, the best one I've found as an entry point was the approach
they use in Cryptol: [https://youtu.be/ruNFcH-
KibY?t=897](https://youtu.be/ruNFcH-KibY?t=897) . Cryptol, generally is a
great project to look to for guidance. We're not going with the interactive
approach. An EDSL in the docstrings is our approach so that you can pull a
contract from the chain (pact is interpreted so the code on chain is the code
that executes... well after it gets inlined and validated) and do the
verification for yourself. Pact inlines at module creation/update time as a
safety feature -- this way if a dep upgrades the code your contract runs
doesn't change though the dep can revoke your code's right to access its
tables/data until you update your contract. The "no leftpad" approach to deps.

All the imported code that's pure, however, still works. This way, when you
are building a module, you know that the code you formally verified/tested
against is the only code that will ever run (until you update it).

### Whitepapers

Thanks for the offer but I've already got enough people looking at them
currently and we're keeping them confidential for now... a glaring stupid
mistake would be embarrassing. Subscribe to the mailing list on kadena.io and
you'll get updated with them the second they get released publically.

### SEC

FYI I used to work at the SEC and I was their tech lead when they formed the
Cryptocurrency Steering Committee, which has been renamed to the Distributed
Ledger Technology Working Group (DLTWG). I worked with Valarie (then the head
of it, still is probably) on a few actions. This is the group did the
investigation and put out the release.

Yep, no one is surprised by the take on the DAO and you're 100% right about
the grayer-area of app coins. The key distinguisher will be, IMO, if the app-
coin has real world use when it's sold + isn't supposed to return a profit as
part of the app itself.

IMO, expecting to resell the app-coins for a profit will be fine in the same
way that art can be bought/sold for a profit, and a profit can be expected
when one purchases it, but also art can be hung (or rented out and shown for a
profit). Everything else is strictly a security.

------
alistproducer2
I would love to see the loan be able to (or better yet, enforced that it is)
used as a funding source in a smart contract. Provide an API for funneling
revenue in the client contract to the loan object thus ensuring repayment.
Making the release of the funds contingent on an audit ensuring the repayment
is handled autonomously. Sort of interesting though.

~~~
joosters
Isn't that impossible? If the money is locked up so it can't be lost, then by
definition you can't do anything with it.

------
jmagoon
I know this is off topic, but why the heck is it called Dharma? Just a cool
sounding eastern word? It's like calling something 'The Gospel' or 'The New
Testament' or the 'Quran Protocol'. I get that it's hip for westerners to yank
Buddhist words, but this one really pushes my East Asian buttons. It doesn't
even semantically make sense--in fact, it's a total antonym in many ways.

~~~
marsrover
> It's like calling something 'The Gospel' or 'The New Testament' or the
> 'Quran Protocol'.

Yeah, I don't think that is true, at all. Dharma is a concept and you've
listed books (or close enough to books).

According to Wikipedia,

> In certain contexts, dharma designates human behaviours considered necessary
> for order of things in the universe, principles that prevent chaos,
> behaviours and action necessary to all life in nature, society, family as
> well as at the individual level.

With this definition, I think the author has given the project a fine name.

Beyond that, I really think you're getting bent out of shape about something
very insignificant and don't think this has anything to do with "westerners
[yanking] Buddhist words". It's no different than naming something Apache,
Vista, Yahoo, or Google. It's just a name.

And just to add, also according to Wikipedia,

> The antonym of dharma is adharma (Sanskrit: अधर्म), meaning that which is
> “not dharma”. As with dharma, the word adharma includes and implies many
> ideas; in common parlance, adharma means that which is against nature,
> immoral, unethical, wrong or unlawful.

So, either you don't know what Dharma or Adharma is yourself or you just don't
know what's an antonym.

~~~
djtriptych
This is an oversimplified answer. Dharma certainly has religious significance
to many millions of people. So, it's not "like any other name". It's
evocative, and if you are unaware of just which feelings you are evoking, your
product is at risk.

Consider the case of the javascript test runner, Karma. It was originally
named testacular. Possibly a play on spectacular, but also close enough to
testicular to make female consumers of the library a bit uncomfortable.
Ultimately, products have to be sold to someone, and this is a problem that
makes that job harder.

Dharma does carry a secular sanskrit definition, but sanskrit is not a precise
written language like English. The meanings of words are often only
discoverable in context, and approachable only with a prior familiarity of
common illustrations and allegories depicting the concept. Westerners,
unfamiliar with such depictions as the Bhagavad Gita, which MOST Indians are
familiar with, are severely disadvantaged in discussing the true concept
behind the word. Relying on a particular English transliteration is risky.

~~~
dragonwriter
> Dharma does carry a secular sanskrit definition, but sanskrit is not a
> precise written language like English. The meanings of words are often only
> discoverable in context, and approachable only with a prior familiarity of
> common illustrations and allegories depicting the concept.

But for the part about it being different in this regard from English, this is
probably true of Sanskrit.

But that's not a different from English; lots of things in English require
similar (local and cultural) contextual information to understand.

------
sharemywin
I know it's off the subject but is there a marketplace for freelancing for
altcoins?

~~~
Jabanga
There's [https://ethlance.com](https://ethlance.com). I don't know how much
activity it has, but I do know it will be part of a family of marketplaces
called District0x [1], which should help it with adoption.

[1] [https://blog.district0x.io/introducing-the-
district0x-networ...](https://blog.district0x.io/introducing-the-
district0x-network-5d45a72d364a)

~~~
sharemywin
I was thinking any coin. With all the ICOs there seems like a lot work that
needs done and a lot of coins to burn.

~~~
Jabanga
Almost all the token sales are being done on Ethereum so they'll probably be
paying in ETH. I imagine Ethlance is working on integrating ERC20 payments, so
you can get paid in tokens as well.

------
mcjiggerlog
I'm struggling to understand what the use-case of this is, both from a
borrower and a lender viewpoint? Who would use this and for what?

~~~
atomicUpdate
As a borrower, this is a perfect way to attempt to get free money, since
there's no penalty for defaulting on the loan.

~~~
mcjiggerlog
That's what it seems like. I'm happy to be convinced otherwise, but the
homepage doesn't really explain anything.

~~~
sm4sp
The white-paper has more detail than the homepage and I recommend reading it
for a better understanding of the project

From what I understand, third party entities responsible for vetting
borrowers. These entities referred to as "Risk-Assessment Attestor"(RAA) are
incentivized to do quality risk assessment as they get a piece of the loans
they vet.

Here's a section from the white paper, discussing the importance of RAAs and
how they might deter habitual defaulters

"Moreover, RAAs are capable of reporting borrower defaults to relevant credit
bureaus on the behalf of lenders. Thus, borrowers are disincentivized from
defaulting on loans insofar as their future creditworthiness, both within the
Dharma network and in traditional loan markets, will be adversely affected."

[https://dharma.io/whitepaper](https://dharma.io/whitepaper)

~~~
joosters
What happens when the borrower and the RAA turn out to be the same entity?

~~~
KomradeKeeks
A series of defaults where the RAA shrugs after questions about their
legitimacy surface, I bet.

------
Terretta
If you would enjoy playing with this[1], with getting paid to play as a bonus,
email me. I want to pay you to do what you enjoy.

\---

1\. And/or things like this.

------
primeblue
With all the DAO hacks and criticism of Solidity, why would one use Ethereum?

------
xtracto
Hey man Omar from Kueski, good to see you are progressing on this. I will
definitely download the CLI program and start playing with it!

------
luizb
How does a RAA ( so far Dharma INC) grants initial credit worthiness to new
borrowers ?

------
sm4sp
Very nice work.

Is there an estimated release date for the Dharma Loan Browser?

