Building Decentralized Gateways to Crypto

Many of the most exciting features of cryptocurrency — lack of censorship, user-controlled privacy, no limits, low fees , unstoppable — don’t actually apply to the on-ramps and off-ramps of crypto.

Bitcoin transactions may be pseudonymous, but your Coinbase account isn’t. Ethereum smart contracts don’t care about borders, but exchanges do. The ERC20 standard doesn’t give a whit who its customers are, but KYC is ubiquitous in any tool that bridges Dai to dollars. Most cryptocurrencies cannot be stopped — great! But every traditional exchange is a court order away from shutdown. Not great.

In short, conventional crypto exchanges allow movement between the old economy and the new economy, but only on the old economy’s terms: KYC and hassle, loss of privacy, and most crucially of all — only functional for as long as the local government deems it acceptable.

To get all humanitarian on you guys, Zimbabwe is slowly but surely re-entering hyper-inflation. Zimbabweans would love a way out. But last year, their government shut down Golix, the only crypto exchange in the country. If a Zimbabwean wants to enter or exit crypto but doesn’t have the right contacts — tough luck.

This is unacceptable. We’ve got to make sure this kind of thing cannot happen. To someone in a failing economy, it doesn’t matter how free and flexible crypto is, if their government can simply prevent them from entering crypto in the first place.

We believe the crypto industry can solve this problem, and reverse the above dynamic, providing a gateway into crypto, on the new economy’s terms: no limits, no borders, no KYC, uncensorable and unstoppable.

We see two bright points of progress in this journey: Bisq, which has been in development for years, and announced the 1.0 launch with their DAO last April; and DAIHard (our project) which is quite a bit younger and is built from a very different set of parts.

In this post I’ll begin by comparing these projects, highlighting the drawbacks of each. I’ll then zero in on the “hard problem” any decentralized exchange must grapple with: the inconsistent, often-irreversible nature of the fiat banking system. Finally I’ll discuss why DAIHard is uniquely positioned to address this problem effectively.

Bisq: It Gets the Job Done. Right?

Bisq is a peer-to-peer market that syncs like a Bitcoin client. Once your client syncs, you are shown a marketplace of offers to buy and sell BTC for various fiat currencies (or other cryptos). These offers come from other peers that are currently online. It’s a very robust, resilient system.

It has a decentralized method of choosing arbiters, and can reassure users that most of the time disputes don’t even happen, and if they do they’re typically resolved to the users’ satisfaction. The key here is that it’s a decentralized process — contrast this with LocalEthereum, which runs (mostly) on smart contracts but has a centralized method of arbitration. Bisq could survive regulatory pressure (there is no point to pressure) while LocalEthereum could not (the arbitration team gets threatened/sued/jailed, and suddenly the system can’t resolve disputes).

Bisq is a solid first step in the right direction, as well as impressive from a technical perspective. It’s a live project that works — that’s nothing to shake a stick at in this industry today!

But it falls short in a few ways. These flaws are for the most part both forgivable and critical.

Syncing Issues and Other Bugs

When I downloaded and ran Bisq, it froze a full three times before I could even see the marketplace, and froze a final time once I did get to the marketplace. Each time I had to force-quit the application. The process took something like 40 minutes (although this could have gone quicker if I’d been watching like a hawk to restart the thing). Once past all this, the application seemed to run just fine.

I stuck around and soldiered on, but remember that my motivation was academic, and as a crypto developer I’m used to this stuff. To a regular user (who can’t even see the order book at first, to judge whether it’s all worth it), this is a very discouraging obstacle.

(while drafting this post at a nearby cafe, which has otherwise satisfactory wifi, I found Bisq wouldn’t connect at all, despite having already synced it at home.)

I should also note that as of this writing, a significant portion of posts on the frontpage of r/Bisq are complaints about bugs or issues that sound relatively serious.

I don’t want to hate on Bisq — writing a peer-to-peer syncing client is surely a nightmare, right on the bleeding edge of development. It’s forgivable that these bugs show up. But it’s also critical.

Rigid, Opaque Payment Methods

When you do get to the list of orders, for the most part the UX is pretty well-designed:

However, note that in the Payment Method column, only two types of trades show up: Zelle and F2F (face to face, I later found out, for Brooklyn). Upon some investigation, I found that Zelle doesn’t work with either of the banks I’m able to receive payment in (Credit Union 1 and Schwab, for the record). And I’m nowhere near Brooklyn.

Maybe at a different time I would have found an offer that worked (you only see online offers, after all), but opening the app always takes a few minutes and requires you’re on your laptop. Maybe I could have opened my own offer and gotten it filled (eventually). But at this point, as a user, I’m feeling extremely discouraged.

So at least in my (admittedly anecdotal) situation, Bisq cannot facilitate entry or exit to crypto. And I’m a first-world citizen, with relatively open access to financial tools. For people in more restrictive financial contexts (like Zimbabwe), Bisq is even further away from being a real solution.

I’ll have more to say on this problem — it is a tough one to solve! — in The Hard Problem below.

DAIHard: Accessible and Flexible, but Scary and Vague

DAIHard aims at the same purpose, but is built quite differently.

First, rather than being a client on a peer to peer network, DAIHard is a dapp with a webpage front-end. The user does not need to download a client or sync and can immediately see the marketplace, although they do typically need to download a web3 wallet plugin like Metamask or Nifty Wallet if they want to take actions (like create an offer or interact with an existing offer).

Second, rather than offering Bitcoin as the main currency to trade, DAIHard offers Dai. The upside here is that Dai is stable to USD, meaning that a user can decouple the actions of getting crypto and investing in crypto. The downside is that it doesn’t have the same ubiquity of Bitcoin. But it’s entry into any crypto that’s hard; once you’re in, trading between types of crypto is relatively easy.

Third, where Bisq has a decentralized system for choosing arbitrators, DAIHard addresses dispute resolution with a cryptoeconomic primitive called a burnable payment: Both parties must deposit Dai into the contract, and the seller can burn the whole balance in the case of an attempted scam by the buyer. You can read more about that here, but the general idea is that this credible threat of burn should prevent the vast majority of scam attempts in the first place.

Because the seller is the judge, jury, and executioner here, we don’t need to limit the payment methods to things that are verifiable by a third party. In fact, we don’t need to limit the payment methods in any way: it’s just a text box the offer creator fills in, and which the offer filler will read before deciding to deposit their own Dai into the contract to start the trade.

Now, DAIHard is our baby and we love it, but it has some critical issues too.

You Can’t Buy Dai Unless You Have Dai

I mentioned above that both parties must deposit Dai into the contract to begin the trade. Specifically, the seller must deposit the full sale amount, and the buyer must put in 1/3 of that. So if a user sees an offer on the marketplace to sell 100 Dai, but they don’t already have at least 33 Dai of their own, they can’t actually participate as a buyer.

In the DAIHard contracts themselves, this “buyer deposit” can be lowered upon offer creation, even to 0 (although for the moment the interface hides this option). But if this amount is lowered, the game theory is weakened: It is only because the buyer has “skin in the game” that we can reliably predict he won’t attempt a scam.

This is why we often call DAIHard an off-ramp, or a crypto gateway, but avoid calling it an on-ramp: if you want your very first chunk of crypto, DAIHard cannot help you.

Threat of Burn is Very Scary

Where Bisq has significant technical hurdles and barriers to entry, DAIHard has a significant educational hurdle: the user must be informed that in the case of an attempted scam, the entire trade balance must be burned.

No, we don’t mean refunded. Yes, the money is destroyed. Why? Well, let me just get out this game tree diagram… Wait, come back! It almost definitely won’t happen to you!

It doesn’t really matter how sound the game theory is, when having this initial discussion — especially in this early stage where we don’t have much platform history to illustrate how low this threat must be delivered on. This is a very scary game to play, and we’re hard-pressed to find explorers for such an unexplored space.

Open-Ended Payment Methods

Bisq’s payment methods are rigid and limited, preventing whole demographics of users from participating in the platform, but at least that means they’re mapped out and vetted, and generally can be relied upon by users to go smoothly. DAIHard has the opposite problem, giving the user enough rope to hang themselves with, and kinda hoping they’re smart enough not to.

It’s often hard to tell whether a given transfer within the banking system will work before it’s actually attempted.

In an early test of DAIHard, I made an offer saying that I could pay to any TransferWise or Revolut account, thinking that I could do so with my own TransferWise account. But the user who committed had a Revolut account in GBP, and lived in Poland. Some combination of these factors foiled my every attempt to complete the transfer.

Eventually we just agreed that I would send Dai instead of the planned fiat transaction, and he’d release the trade’s Dai to me — a sort of manual trade annulment. But if I didn’t actually have that much Dai, we might have been forced to call the abort method in the trade, incurring a small burned punishment for each of us. And at the end of the day, we certainly can’t say that the trade worked as intended: it failed to facilitate a trustless fiat/crypto trade.

Every time a user opens a trade on DAIHard, they must write in human language how they can send or receive the fiat payment. What if their method just doesn’t work, as in my example? What if the seller doesn’t realize the payment method is reversible, and the buyer reverses the fiat payment well after the seller released the Dai? What if it takes far longer to resolve than either party expected, forcing them to resolve the trade (burn or release? Decide now!) before the recipient’s fiat account reflects the transaction?

The Goal Unreached

Both of these products seem unsatisfying, incomplete. What is it, specifically, that we’re missing? What more should we have in place before we can call it done?

Less Exclusive

Bisq excludes all users who can’t work with the app-specified list of payment methods. DAIHard is only accessible to people who already have crypto, which is fine for those wanting to sell, but an impassible barrier to anyone new to crypto and wanting to enter.

Easier to Use

Bisq imposes significant technical hurdles and seems to have a host of unresolved issues. DAIHard faces the monumental task of educating the user of the threat-of-burn mechanic, and why it must remain as a threat but will rarely ever come into play.

More Liquidity

At the time of writing, Bisq has a tiny amount of liquidity, and DAIHard even less. In both cases this is exacerbated by the platform’s barriers to new users: technical in nature in Bisq’s case, and educational in DAIHard’s case.

The Hard Problem

I won’t try to solve every issue above in this post, but there is a particular challenge that manifests in both products that I’d like to talk about. It’s something that any decentralized crypto gateway must somehow address, which we see DAIHard being uniquely able to solve.

Fiat Banking is Inconsistent, Unpredictable, and Often Reversible

The traditional banking system is cobbled together from a multitude of data center silos. Worse, the vast majority of the system supports reversible transactions, as a response to the unsurprisingly huge volume of fraud it sees (when you think about it, a credit card number isn’t much different from a take-as-much-money-from-me-as-you-want password. Unless you change that dynamic (as crypto has done) you better have some reversibility mechanic.)

So when you have a user in fiat banking silo A who wants to buy crypto from a user in fiat banking silo B, there are some unknowns. Is the payment possible in the first place? What are the fees going to be? How long will it take? And can the sender reverse the payment? If so, how long will be be before we can consider the payment “final”?

These questions are often extremely difficult to know before actually attempting the payment, and often remain vague even afterward. Maybe the very same payment that was irreversible today, but will be reversible in a few months when some internal banking policy changes.

Bisq solves this problem by vetting and limiting the payment methods available to users, but the side effect is that they exclude large swaths of humanity, and we’re reliant on the core developers to implement new payment methods in a rather slow, ponderous manner. For this task, we could accurately call Bisq a “democratically controlled central planner”; there is no possibility of individuals spontaneously solving the problem in local situations.

DAIHard basically just shrugs its shoulders and expects the user to figure it out, under possible threat of burn if anything goes wrong. At first this will be a liability, simply intimidating new users, but in the long term it exposes this large, unwieldy problem to the incredible force of decentralized market intelligence.

DAIHard’s Answer to the Hard Problem: “Idk, Figure it Out!”

I have TransferWise. I’m pretty sure I can send payment to any other TransferWise user in the world with low fees. With DAIHard, I could open a trade (in fact I’ve already opened several) that puts money behind this confidence. Others can commit to these trades if they dare, and the game theory should take care of the rest.

What’s happened here? Where did the hard problem go?

The problem only looks hard from the perspective of a central planner trying to solve it all at once. Thousands of payment silos with unknown characteristics — where would you even begin? But as an individual user I only need to answer a small part of that question: do I have access to any one fiat payment method that I can rely on? And the answer (for me) is: well, TransferWise seems pretty damn irreversible and pretty damn instant. Let’s give that a shot!

With Bisq, that doesn’t get me anywhere, because TransferWise is not one of the built-in payment methods. But with DAIHard I can put anything I want in the Payment Methods text box.

DAIHard pushes the problem to the edges of the network and gives its users the power to solve it for themselves. A user attempting to solve this problem will face risk, of course, but also opportunity for profit (you may have noticed all of my TW trades will net me a small bonus if someone commits!).

Remember that a DAIHard trade’s payment method is just a block of text which the offer creator fills in, and the offer filler reads and agrees to before committing, under threat of burn. This is extremely flexible. You could sell Dai for Steam credit, buy Dai by sending nudes, or hide cash bundles in some public park and sell their locations for Dai. All of this can be done without a single change to DAIHard itself.

DAIHard doesn’t solve the hard problem directly; rather, it is a platform that allows entrepreneurs to spontaneously solve bits and pieces of the problem and profit from doing so. And this is exactly the kind of problem that markets are particularly good at solving.

There is still a lot to discuss, but we see this problem as the most challenging and critical to success. We’d love to hear any thoughts on other approaches, as a comment either here or in the discussion thread in r/ethereum!