Hacker News new | comments | show | ask | jobs | submit login
Show HN: Dharma – Programmable Peer-To-Peer Loans Using Ethereum Smart Contracts
156 points by nahollander 117 days ago | hide | past | web | 61 comments | favorite
Hey HN!

My name's Nadav Hollander, and I'm the Founder of Dharma.

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.

Today we're launching our Alpha Testnet release -- a command line tool that allows you to

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

Check it out: https://github.com/dharmaprotocol/dharma-cli

Why I Think This Is Cool:

1. Loans in the Dharma Protocol are basically miniature ICOs issued by borrowers -- an investor'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.

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.

How This Can Be Better:

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.

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.

Please play around with the CLI -- would love to hear feedback!




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?


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.


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.


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.


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?


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


> They are compensated for this by a fee that is allotted to them in the loan contract.

Do the RAAs also lose money if they approve a loan that turns out bad? The creditors do.

What is the relationship is between an RAA and creditors? I assume they are separate entities.


Could something like Civic.com be used for this?


> whatever means they have to assess a borrower's identity [...] uploaded identification documents

Whee, racial profiling!

> deterred from defaulting on their loans insofar as their future creditworthiness on the platform will be marred

Oooh, scary :-) You're not even threatening to half-assedly try to involve authorities if someone just runs with the money?

I think this is a very interesting engineering feat, but it does seem to suffer from the basic problem that there is no real connection between the real world and this fantasy world called "the blockchain".

Also, a small comment on the README:

> submitting to the contract any subset of the investors' bids whose total cash amount is equal to the desired principal

If you really mean "equal" here, you are looking at the NP-complete subset sum problem in general. Also, there might just not be solutions at all. Maybe you don't actually mean "equal", it should become more practical if you allowed some deviations from the borrower's initially specified amount.


I think the idea is that RAAs can bridge the reality divide by tying the pseudo-anonymous contract identity to a real life identity. You can, for example, require the user upload a video showing them, any government IDs, their house number, their last utility bills, pay stubs, etc. You might require a mobile app that could look at ongoing phone telemetry/contact info to see someone has a network and is regularly going to a job. The goal isn't mathematical certainty, just to make the effort/cost of theft < the value of the loan.

Some startups do similar things to this (Tala) to lend in countries without credit bureaus and IIRC they can achieve loan repayment rates >= 'prime' US borrowers.


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.


I heard a guy talking on Bloomberg radio this morning about this in regards to emerging markets bond investing. The interviewer was commenting that the legal system didn't provide good recourse in the event of default. The guy said like you that the credit analyst would need to focus more on the likelihood of default than the recoverability of the collateral.

It reminded me of my time working on credit models for subprime mortgages. We forecasted 2 variables: frequency and severity of default. The total loss prediction was the product of the two. If your severity is always 100% at least it makes your model simpler.


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.


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.


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!


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


Cool project, congrats! As you speak of the "20B worth of value" I have a question:

I always ask myself what the total monetary value stored in ETH actually is, as the 20B $ is the market capitalization (as far as I understand), which in my opinion is NOT the value. Drawing on my Economics classes (from a long time ago), my thinking goes like this:

Let's assume I create 100 million items of a new cryptocurrency. At first, my coins have no value whatsoever. Now, you offer to buy 1 cryptocoin for 200 $ from me. This would instantly give my currency a market capitalization of 200 $ * 100 MN = 20 BN $! But is my currency now worth 20 BN $? I would say no, as there is probably no way for me to sell the remaining 99.999.999 coins for the same price for which I sold the first coin. And even after distributing a large amount of coins (say 50 % of the total), I would probably not be able to sell my remaining coins for their market value, as my offer volume would rapidly drive down the price of the coins by creating an oversupply (depending on the transaction volume of the currency of course).

Following this logic I always thought that speaking of 20 BN $ of value stored in ETH as misleading, as the real monetary value of the currency (as determined by how much value you could actually extract when liquidating it entirely) is probably much less than that. And given that most people invest in ETH purely for speculation, I would even wager that a single seller who puts a large number of ETH on the market (as compared to the average daily volume) could cause a massive price drop, since there is no "fundamental" value in ETH (contrary to an asset-backed currency or a company stock).


How is this different than securities sold on public stock markets? If you hold a large position in a nasdaq 100 stock and drop a large sell order on the ECN's, you are surely going to see a similar (albeit not as dramatic) phenomenon. Does that mean the market cap of stocks shouldn't be used to assess value?


The public stock market is highly regulated, which makes price manipulation and insider trading more difficult as it is illegal and suspicious trades will be investigated. The ETH market is completely unregulated, hence the risk of manipulation is much higher.

Also, NASDAQ stocks represent the underlying value (as well as future revenue expectations) of a real-world company, hence short-selling your stock to manipulate the price (usually) doesn't make much sense if the fundamentals of the underlying company are good, as investors that are optimistic about the future of the company will happily buy the stock that you sell. Of course there are situations where large funds speculate against companies or even governments, but this is (usually) only possible if there is a fundamental issue in the underlying asset such as a nation in a deep recession or debt crisis.

For ETH there is currently no underlying asset that would have a value in the real world and which could serve as an "anchor of trust" for an investor. It should therefore be much easier to manipulate and speculate against ETH as there is little external information beyond the exchange rate that other investors have as a basis for their valuation. Also, as of now there is no large economic process that depends on the existence and functioning of ETH, hence there would be very little external pressure to keep the currency alive if people started speculating against it.

For most cryptocurrencies, the initial developers / creators are similar to the founders of a publicly traded company in the sense that they possess a large fraction of the shares of the company / number of coins. What's different is that there is little for the "crypto-shareholders" to hold on to their coins in case of a sharp price drop, as there is no underlying asset that their coins represent. Economically, they are highly incentivized to "cash out" as soon as they think that the price has reached its maximum value (and this is what I expect will happen with many crypto-currencies as soon as the market cools down). With shares this is different as ownership of the share allows you to continuously extract value from the underlying company in the form of dividends, hence the incentive for selling your shares is much smaller even if you think that the share price has reached its maximum.

I would therefore be very cautious about long-term investments in ETH, as there is no safety net and no guarantor behind the value. And while this is great for gambling, it does not provide a viable platform to build real world applications on top of (in my opinion).


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 -- my co-founder is presenting it

[2]: 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


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.


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


Buckie, I'm in the process of reading your white paper on Kadena smart contracts, so it may answer this question. What is the purpose of a private block chain? Doesn't it become vulnerable due to available resource to out pace the block chain? Are there companies looking to secure intercompany transactions?


First, the pact paper needs to get updated to reflect the changes we made for the shift to public. For example, modules used to only be guarded by keysets (Pact doesn't have a notion of single-sig only constructs, anything using a sig supports multisig natively) and thus only support centralized upgrade governance mechanisms -- you don't need a decentralized vote in a private context -- so we generalized it to being a pass/fail (continue/error out) function that can do whatever it wants. e.g. you could have other contract functions record a weighted vote and have the governance function tally the vote (and run the upgrade only if it passes whatever threshold you set).

> What is the purpose of a private block chain?

Great question -- I get this all the time. First off, public and private blockchains are despite their names different beasts serving different needs. Private blockchains are more a meeting of the best that public blockchains have to offer with the best of what databases have to offer, dropping the inefficient/not so great parts from each.

The tl;dr is that a private blockchain is really the realization of a multi-administrative DB. They serve the specific need -- that no other system can -- of allowing two companies that don't fully trust each other to share a multual store of information of value. This gets extended to include logic, and thus workflows, which is where it gets really useful.

There's a ton more to the business reasons for why they make sense (or will, the B2B sale cycle is slow and this tech is still quite new) but I'll leave that for later. Instead, let's walk through what you would have to do to make a similar, non-blockchain distributed DB like consul and try to adapt it to meet the aforementioned requirement: be able to share some of the nodes with people you don't trust. NB: I'm not talking about ScalabeBFT here; the logic is similar but does a lot to more to get high performance @ scale.

## The consensus layer

Consul uses raft, so we have multi-node quorums with strong consistency + an append only ledger parts covered already. However, you have two problems when you share it: #1 a bad node can take down/halt the cluster and #2 the leader can mutate the transactions it sees before replication. #2 is a problem because trustless, which we fix by having signed transactions so the leader can't touch them pre-replication. Moreover, we don't want the leader to replicate an out of date node with bad info, so we make the append only ledger a blockchain (either blocks or inc. hashes work the same.)

#1 is a bigger problem -- it's a problem of the consensus mechanism itself. Raft isn't BFT which is what you need to protect the cluster from a subset of bad nodes... so we make the consensus layer BFT, which is quite hard. The main practical reason we NEED to do this is because in a multi-admin context I can't ssh into your part of the cluster and kill a bad node... so BFT also protects me from your crap IT dept. There are other reasons for BFT too that are probably more important theoretically, but this is the most straightforward and practically important one because it will happen in production.

## Logic/DB/SQL layer (i.e. smart contracts)

To solve #2 above, we needed to sign messages. Now how do we interpret/check that the key used is one that we allow to be used? There needs to be some layer that is checking the sigs and applying the logic to the DB. Here too, we have a problem: there are multiple entity-level users on the DB that don't trust each other so how do we make a system that acts like a DB but also enforces fine grained auth schemes.

There's more to the story of how that question ends at "you need a smart contract language" but I don't want to detail every step. Instead we'll just assume it's right (ask if you want more details but tedious) and justify it with 2 practical reason: (1) you need to protect the data/flows that you put into the system behind some auth mechanism and (2) if you don't have a generalized way of capturing inputs, reading the current state, representing business logic/workflows, writing to storage, and enforcing authorization generally+finely then the private blockchain just isn't that useful. It'd be easier to just make a standardized API to get/push data to and a network of users. It's the safe, on-chain code exec that makes it different + really useful.

## private blockchain feature swaps (public vs db features)

Adding smart contracts + an append only crypto log are the main DB features that get dropped when making a private blockchain (vs procedural SQL and mutable tables).

Merkle trees/proofs are out: you don't need to support light clients as (a) this system isn't open to the public and (b) when you query the system you hit your local nodes which are by definition trusted oracles.

Native Traditional DB integration is in: one of the big issues for enterprise EVM users is getting the damn data out of the system (to pipe to their downstream systems) without having to run a query on the EVM. As you don't need Merkle/Patricia trees, you just have the smart contract exec layer incr hash it's tx log (tracks reads, writes, updates per tx deterministically) and use those to compare for data corruption event for a given node. This allows you to directly integrate the contract language's backend with a traditional DB (we just integrate with ODBC).

PoW/PoS are out, deterministic BFT is in: Both invalid in private contexts for different reasons. Both rely on incentivization via an on-chain coin, and break down without it. As there isn't a market to sell the coin, there's no value. Instead, you just need a fully auditable and deterministic BFT consensus. The good news is that they are WAY faster. Bad news is that they have scaling problems (though ScalableBFT should be able to have ~5k nodes before it starts to slow down).

NB: a prod system of 5k nodes can't just be thrown together and hit ScalableBFT's top numbers of 8k/s... we'd need so serious messaging solutions like those used in HF trading because there isn't a good open source UDP-like broadcast messaging system and bandwidth will be a problem. Scalable was designed with broadcast being needed as scale in mind (though it works fine up to 500 nodes so long as you have fat enough pipes). Also, we measure performance inclusive of the smart contract code itself. Pact is fast (~10-100x faster than EVM and getting faster for similar workloads) but if you have heavy logic on chain, it will impede performance. There's no magic bullet, besides dep-graph drawing for parallel exec which only helps non-sequential workloads, to this problem.

## Business reasons besides just a multi-admin use case

1. On-click real-time reg oversite: just put a node (read only probably) in their data center and give them the right keys. They now have full oversite into the entire chain.

2. Servicing semi standardized markets: there are a bunch of use cases where a unified market/settlement tech stack hasn't been built because the assets in that market, unlike say equities, are all just a little bit different. Think exotic OTC derivatives contracts -- the deal you did today is pretty close to the deal you did yesterday, but not close enough (some new parameters or something) that you don't bother to build a unified stack for them. Instead, each party does their own thing. Not the best example because the best ones are ones we're working on actively.

3. Lower-bound for how bad a system can ever be: This is the longest-term possible market strategy where the tl;dr is that a private blockchain gives you SO MUCH by default that it makes sense to use one internally (like consul) from the start. It fully upfronts a massive amount (disaster recovery, high availability, distributed, perfect replication, etc. are all commoditized) that if we make the part the user sees simple and safe enough (Pact is really easy to write + is formally verifiable) + useful enough (the contract is your REST API + DB integration) that it becomes an attractive substrate to write apps on from day one. The market, and tech, will need to mature a lot before this happens though. See the most over powered todoMVC here: https://github.com/kadena-io/pact-todomvc

> Doesn't it become vulnerable due to available resource to out pace the block chain?

If you mean w.r.t. mining it would, but mining abjectly fails in private contexts http://kadena.io/blog/MiningInPrivate.html ; if you mean that it can't handle the throughput, then I'd say it's deterministic so you can shard out as needed (like we do in trading systems/everywhere today).

> Are there companies looking to secure intercompany transactions?

Yes, but you can do that with an API already. It's more about the added utility of having something so robust that you can also represent workflows directly on (vs having to make a new endpoint and a new service behind it every time).


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

OP should also definitely consult a lawyer before making this public. Eth advocates love to parrot the 'code is the contract' slogan, but the actual law could very well disagree.


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

I think this is very inaccurate. There have been devastating bugs in Ethereum, namely the bug in the DAO and the one in the Parity multisig contract. But there are numerous smart contracts that have not been found to be vulnerable. You cannot extrapolate what happened to two contracts to the entire ecosystem. It's inaccurate to claim that the probability that the loan contract he's working on will not have critical bugs once it's live is "remote", and a red herring to point out that it is unlikely to be bug free now, when it is still in development.


I had a long discussion about this topic here: https://news.ycombinator.com/item?id=14807779

> I think this is very inaccurate.

Perhaps, though keep in mind I did say that it is "[the odds that this code has a serious bug are] impossible to calculate accurately" and there's a reason for that. I'd argue that it wasn't an imprecise statement. Gavin was the father of solidity, put in the process at Parity, had an audit team, and the $200M multi-sig bug still got through. If the top-tier team and process failed, it's not imprecise to say that a more complex code base that didn't follow the best approach available likely has a bug. This is invariant on the phase of development.

Moreover, I was cautioning OP to be careful. One valid response to that is what he's already going to do (get an audit). This makes a bug less likely. The next phase would be a Bankor-style pilot+bounty. After that... well we just don't know.

> But there are numerous smart contracts that have not been found to be vulnerable.

Sorry, but unexploited is not unexploitable. Many/most of these contracts are probably unexploitable, but the problem is that we can't be sure. To me, smart contract construction on the EVM/Solidity is closer to a "rolling your own crypto" grade problem, which is something that after years of massive exploits we've all agreed that you do not ever do it, vs building a webapp. Long term as tooling + approaches + standards + the language itself mature, it'll come closer to "backend programming at a hedge fund/bank" where it's doable but you need to be responsible.


>it's not imprecise to say that a more complex code base that didn't follow the best approach available likely has a bug.

It is imprecise because the Parity multisig bug is an outlier. There are numerous contracts both by 'crack' teams like Parity, and by teams with a less established reputation, that have not been found to have a critical bug in production.

Therefore, the evidence that most contracts have serious bugs is simply absent, and one can't accurately state that the odds of a contract being launched without a serious bug is "remote".

>Moreover, I was cautioning OP to be careful. One valid response to that is what he's already going to do (get an audit). This makes a bug less likely. The next phase would be a Bankor-style pilot+bounty. After that... well we just don't know.

Yes and I agree with your advice.

>Sorry, but unexploited is not unexploitable.

And the possibility that it is exploitable does not mean it is exploitable. I'm not saying that it's out of the question that there are numerous contracts out there with exploits. I'm saying that we can't assign a probability to that being the situation.


have you attempted to apply any formal methods (coq, isabelle, tla, whatever) to your code? or will you be content with mere auditing?


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.


shrug, the reference books for all those things are the standard resources. i think they've shown up on hacker news a couple times each.

if i were aware of any material on formalizing solidity or the EVM, honestly i'd keep it to myself and use it to identity vulnerabilities in your contracts. in that hypothetical world, my question was a means to check and see if you were a good target.

good luck. :)


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.


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.


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.


I completely understand the feeling, but you're asking this on a site that uses the word 'karma' for internet points. That ship has sailed, the battle is lost, language just morphs in ways we don't like. Probably it always has.


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


Different cultures have different definitions of the loanword. For East Asian Buddhists, Dharma generally means the teachings of the Buddha. As in the phrase, 'Turning the wheel of Dharma'. I guess if you pick that one section of wikipedia and say that's what it means, then sure.

Dharma is also used by Hindus--I'm not Hindu, so I won't comment on what the word means for them.

Saying "it's just a name" is a valueless claim. Of course it's just a name. Names have meaning, and in this case, the word has four thousand years of history in Asia. I just don't understand why this particular name was chosen, and why borrowing something fundamental to two major world religions is the logical choice for a protocol.

"The Gospel", in my understanding of the Christian term, is also a concept, and not a book.


Although I agree with what you're saying, I personally find it a little irksome beacuse we're calling some kind of lending/contract/whatever system 'dharma', not that it's adharmic, but it's like when you see someone wearing a Che Guevara t-shirt, or buying soap embossed with "Fight Cub". Instead of focusing on the impermanence of phenomena, dispassion and the attainment of peace, we're... making contracts or borrowing or something?

Yes, I'm being facetious, but I think GP has a point. It seems as though a cool sounding word was chosen and used for the fun of it. And this is what words become, it just feels somewhat irresponsible to start a potential change in culture to favour your hot new tech over sage advice to better the human condition. So while the original word isn't gone, it is always at risk, and with the loss of words comes blunted ability to explain concepts. So while I would not describe it as 'yanking', I would more describe it as 'eroding', which doesn't have to be a good thing or a bad thing, but it's happening.

I'm hardly one to talk about "cultural appropriation", as nobody in particular really has claim to ownership of culture, but the naming does sit somewhat off with me, though it's just a personal preference of course.

Adorno wrote about the commodification of art in The Culture Industry. Can the same be said about our ideas? Gramsci wrote about cultural hegemony, can the same be observed in our replacement of the meaning of words in this way?


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.


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


This is kind of ironic since Karma is also a sanskrit word with religious significance. But at this point it has been fully accepted into english.


I can see all of your points, and they're valid, but...

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

When someone labels something as cultural appropriation is not a matter of whether it is a true label or not, what matters is that some number of people from that culture consider it to be cultural appropriation. If they do, then it's a problem and the project owners need to decide if they'll change the name or not.

At the beginning of the project, there's no large cost to changing the name, so I'd change it if it was my project.

That said, coming up with names is hard. I've been told I'm good at it. Not sure if that's true, but here are three alternatives: Lifeline, EthereaL, Enablr, Xtension. The Dharma project owners may use any of these names to rename their project for free in perpetuity, if they wish. Post here if you do though, because otherwise I have ideas for several of them (not ethereum loans, or even loans).


I got reminded for Dharma initiative from Lost. It has quite a fan following off screen.

https://en.m.wikipedia.org/wiki/Dharma_Initiative


Originally, "dharma" just meant "thing/object". More abstract (and derived therefrom) is a bifurcation into "true thing, real thing, truth, etc.." and on the other end of the spectrum "object, mental object, thought". Think of Carolus Linnaeus and not so much religion.


I understand the historical origin (though claiming it has a single original meaning is an extremely strong position), but the common understanding for Buddhists refers to the teachings of the Buddha and the eightfold path, which is very much a religious term. I generally don't mind people taking things from religion in the punk rock sense, but I guess I just don't get this one.


The word seems to be used in both contexts in the Buddhist Pali canon, at least from what I can tell.


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


There's 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...


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.


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.


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?


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


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


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


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


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


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.


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


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!


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


Very nice work.

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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: