The last few weeks have been a rollercoaster for DeFi, specifically around what the expectations are for providing compliant DeFi services.

The good news is we have seen a resurgence in interest in Digital Assets and along with it, a surge of interest in the growth of DeFi protocols to support them.

The more challenging news has been on the regulatory front, specifically:

FinCen’s Notice of Proposed Rulemaking (NPRM) on mixers, which was in fact an NPRM on all DeFi services; the announcement of the Binance settlement.

There is a clear need for DeFi protocols to start to take AML and other compliance requirements seriously. In the FinCen NPRM, nearly all DeFi services were lumped in with mixers, which will require all centralized exchanges or other regulated entities to treat any wallets which interact with them as high risk and subject to additional scrutiny, data collection, and reporting requirements. In some cases regulated entities will be required to report all customers who interact with these services to regulators via Suspicious Activity Reports <SAR’s>.

Even more concerning for DeFi developers and operators was the announcement of the $4.3B Binance settlement, a part of which was the CEO pleading guilty to felony anti money laundering laws. When the settlement was announced, the government specifically mentioned that DeFi operators should expect the same scrutiny and results if they do not comply with the AML rules that banks, securities exchanges, and other traditional financial institutions follow.

In addition to the regulatory risk, the lack of implementation of proper AML controls in DeFi protocols has kept many institutions and regulated entities sitting on the sidelines, unable to interact with DeFi services without putting their own licenses at risk. This means that there are less traders, less liquidity and less transaction volume on DeFi protocols today than there could be if regulations were being fully followed.

When DeFi protocols are able to properly meet expected requirements it will:

• unlock institutional capital
• grow customer bases
• grow the number of active wallets
• increase the number of transactions per wallet
• dramatically increase the amount of liquidity available in DeFi protocols.

There have been a number of potential solutions in the marketplace to help DeFi developers meet these new requirements, unfortunately, many of these solutions fall far short of what is actually expected of DeFi Services by regulators and institutions. Implementing these kinds of solutions will only delay institutional adoption, as well as continue to put protocol developers and operators at risk of regulatory and even criminal sanctions.

Why whitelists won’t save DeFi

Most DeFi compliance solutions proposed in the marketplace are based around “whitelists”. Essentially a user goes through a one time KYC process, and then their wallet is added to a white list that is allowed to trade with a given protocol or smart contract.

One-time KYC is certainly an important part of any compliance schema, but it is only one piece of the puzzle. It is not a complete solution in and of itself.

Regulators and institutions expect compliance to be applied during every transaction, based on the unique data and characteristics that are available at the time of the transaction, which were not necessarily available at the time of customer onboarding. Some examples of things that are missing at the time of onboarding are as follows:

One-time compliance can not do real time wallet screening at the time of the transaction to ensure the wallet interacting with your protocol is not on a sanctions list, or otherwise affiliated with high risk transactions such as transactions with dark markets, sanctioned mixers, sanctioned wallets, or other indicators of criminal activities or connections.

• One-time compliance cannot apply traditional financial transaction monitoring for suspicious behaviors such as structuring, transaction velocity, massively increased transaction sizes, or other indicators of illegal behavior.
• One-time compliance cannot ensure that the wallet was not shared with or stolen by a bad actor after the original compliance check was done.
• One-time compliance cannot easily do re-screening of names if a user is added to a sanctions or other watchlist.
• One-time compliance cannot do ongoing wallet screening to ensure the wallet has not been involved in criminal or other high risk activity, or added to a sanctions list.

For these reasons it is critical that any DeFi compliance solution needs to be real time — not just one-time — in nature, and able to be run for each transaction, ideally, or at a minimum at regular, daily intervals.

[Editors note: This is the first of a 4 part series on Travel Rule solutions for the cryptocurrency ecosystems. Joe Ciccolo of BitAML’s post can be found here: https://medium.com/@joeciccolo/crypto-cant-ignore-the-fatf-travel-rule-6da43667436d ]

The new requirements from global regulatory body Financial Action Task Force (FATF) around Travel Rule present a serious challenge to the digital currency ecosystem today. Exchanges and service providers alike are scrambling to come up with adequate solutions to these emerging and expanding requirements. The tl;dr on the Travel Rule is that for transactions over a certain value <think along the lines of $1000 in many cases, but it can vary by jurisdiction>, if both ends of the transaction are an exchange or other regulated service, they are required to exchange and store identity information about the transacting parties. The easy way to solve for this problem is to simply re-create the SWIFT network, or something like it, but that isn’t the right way to solve this problem, not now, and definitely not for the future.At Netki we were first alerted to this problem in 2015, when Ripple had a consent decree with FinCEN. In it FinCEN cited and Ripple agreed, that as an MSB they needed to comply with Travel Rule and would need to do so going forward. With no available solutions in the marketplace, Ripple had to vastly limit the number of companies they directly interacted with, and built a very manual solution to address the requirement. Netki viewed this as an existential threat to the cryptocurrency ecosystem as a whole and immediately started working on a solution that would keep the community’s ethos in place and still meet regulatory requirements. We launched our first implementation of the solution in 2016. We were maybe a little ahead of things, having a solution long before the regulatory requirements showed up in force.

We used that time to collect feedback from both the industry and regulators, and have arrived at what we believe should be the guiding principles for any solution the industry adopts. These principles will ensure that solutions will satisfy the interests of both regulators and digital currency proponents.

In this article I am going to primarily focus on two of those areas:

1. the importance of any solution to support both custodial <regulated> and non-custodial platforms <where users control their own keys>.
2. How this regulation has already negatively impacted privacy coins and how we can fix that.

Custodial and Non Custodial Wallets

What differentiates networks like bitcoin and ethereum from the existing global financial systems is that they are:

• Open and permissionless to use and
• Open and permissionless to innovate on

The existing financial systems, like SWIFT and ACH, are still very closed and permissioned. Taking away the open and permissionless aspect of digital currency networks, or breaking the smooth flow of transactions between regulated entities and Dapps or DeFi projects takes away the reason that many of us joined the ecosystem to begin with.

There are two groups within the cryptocurrency ecosystem that enjoy a symbiotic relationship. The first group is the regulated Virtual Asset Service Providers (VASPs). Effectively, these are the exchanges, custodial wallets, OTC desks, payment processors, and others who hold or manage digital currency or assets on behalf of others. The other group consists of the unregulated Dapps, wallets where users control their keys, and defi apps that run on the chain itself. Each of the groups needs the other. The unregulated side needs the regulated side to provide the on and off ramps, as well as to provide custodial and other services that mass market and mainstream adoption needs to transition to this new environment more smoothly.

Similarly, the Dapps and other non custodial services are essential to the ecosystem as a whole because, for lack of a better way to put it, this is where the magic happens. The primary reason that digital currency is an exciting new platform and asset is because it is both the same, as well as different, than traditional financial networks. The main difference between older networks and newer decentralized ones is that anyone can build or use an application on top of the network, without getting anyone else’s permission first.

Unless these two parts of the ecosystem can continue to transact, we don’t have an adequate solution. Any solution that is dependant on a company being registered or listed on a centrally controlled list of “approved” participants not only risks breaking that connection, but irreversibly shattering it.

Why This Will Matter Later, and Why It Already Matters Now

Today, regulators are focused on Travel Rule. Next, it is clear, they are going to be focused on sanctions. Iran, Venezuela, Russia, and North Korea have all been publicly connected to using cryptocurrency as a way to make an end run around sanctions regimes, and they are planning to expand those operations. Regulators are watching this and are certain to respond. This is important because sanctions requirements apply to ALL TRANSACTIONS, not just those where both parties in the transaction are VASPs/regulated entities.

So, hypothetically, if you wanted to send digital assets from your Coinbase account to your friend’s BRD wallet, Coinbase would need to know the validated identity of your friend in order to complete the transaction. Any solution that tries to re-create a SWIFT style network of trusted entities, or otherwise relies on both ends of the transaction being a regulated entity will instantly cause a schism, breaking the network in two. Exchanges won’t be able to send to apps, and apps won’t be able to send to exchanges <or, more specifically, the exchanges will have to quarantine the funds that come from apps>. This is nearly the worst thing that can happen.

We don’t have to wait for the future to see this happening. Switzerland’s FINMA has issued very strict guidance in this area already:

“FINMA-supervised institutions are thus not permitted to receive tokens from customers of other institutions or to send tokens to such customers. This practice applies as long as information about the sender and recipient cannot be transmitted reliably in the respective payment system. Unlike the FATF standard, this established practice applies in Switzerland without the exception for unregulated wallets and is therefore one of the most stringent in the world.”

They, today, require all transactions involving a regulated entity on either end to exchange identity as a part of the transaction flow and protocol, exactly the same outcome that the implementations of sanctions for digital currency will require globally. “Our protocol doesn’t support this,” only leads to the response “Well then you can’t do the transaction.” Game over. We need to do better than that.

The incredible disappearing privacy coins

One of Netki’s key tenets when designing our solution for Travel Rule was that it had to support “any coin or token on any public or private chain”. Yes, that even includes privacy coins. Today, privacy coins such as Zcash, Dash, and Monero, are being delisted at exchanges in Asia and Europe, reportedly because of the new guidance around Travel Rule.

Privacy coins are a particularly tricky case to handle because the blockchain itself may hide information about the sender, receiver and amounts being transacted. All of these things are mandatory parts of Travel Rule reporting and record keeping, along with the identity information discussed above. Solutions based primarily on only blockchain analytics or monitoring the blockchain will have challenges tracking transactions in the same way they do with bitcoin or other blockchains that today leave all transactions more public.

In response, exchanges in Korea, Europe and other jurisdictions have begun de-listing of privacy coins in an attempt to keep themselves safely within the law, as regulators are starting to ramp up their Travel Rule guidance and enforcement. On the other side, Bitcoin and other major cryptocurrency networks are looking at ways to enhance their privacy-related features for the benefit of their end users.

The current trajectories put compliance and the right to privacy on a collision course, and we can’t afford to compromise in either area if our industry is going to be successful long term. Any solution to Travel Rule needs to acknowledge this and take it into account.

Avoiding reverse alchemy

It’s clear that our industry is at a crossroads, one where the decisions that we make today will reverberate long into the future. These decisions will not only impact the platforms on which we build, but whether we can actually realize the incredible potential blockchain has to make lasting, positive change in the world.

There is magic in what we all have created here. Our community created digital gold out of thin air by creating something that is open and permissionless, invites all kinds of innovation, and respects the privacy of the users of the platform. Let us take this moment to ensure that the decisions we are making now, in response to the new regulatory reality, support and enhance that magic.

If we respond to regulation by recreating the traditional banking world — a locked down system where only “trusted providers” can interact then we have broken the magic, destroyed the alchemy, and turned digital gold into digital lead.

Keeping Digital Gold was originally published in Netki on Medium, where people are continuing the conversation by highlighting and responding to this story.

SUED BY SCIENTOLOGY

Another similarity between then and now is the importance of doing the right thing for the ecosystem and our users. In August of 1995, I was running technology for an ISP called Digital Gateway Systems, based outside of Washington D.C. During a typical day at the office, I answered the phone fully expecting a normal customer call. It was not. The person on the other end of the line was Helena Kobrin, then legal counsel for the Religious Technology Center. For those of you who are not familiar, they are responsible for managing all the super secret documents of the Church of Scientology. Apparently, one of our users, Arne Lerma, had posted some materials on USENET for which the Church claimed they held a copyright. I informed Ms. Kobrin that I would be more than happy to take the materials down, if they sent me proof of the copyright. They refused. In that moment, I knew that we were at a critical point, and understood how important it was to set the right precedent in terms of preserving the rights of Internet users moving forward. The entire DGS team knew that the Church of Scientology was on a lawsuit rampage, and that this was going to get very costly, very fast. Rather than backing down to their demands we (myself, the engineering team, and the exec team) chose to forgo our salaries in order to fight back for the rights of our users, future users, and for the ecosystem as a whole. DGS was named in the lawsuit and we got served a few days later.

CONGRESS ATTEMPTS TO IDENTIFY ALL INTERNET USERS

Shortly after the case was over, I saw the need for a group that could represent and protect the industry and our users, and I co-founded what became the largest trade association for ISP’s, the ISP/C. Working as a core engineer by day, and as our Public Policy Director by night, I focused my efforts on ensuring that any new laws or regulations supported the open, permissionless nature of the Internet, as well as protected the rights of individuals on the Internet.

The first issue we tackled was spam legislation, which was becoming a rapidly growing problem that stood to adversely impact both ISPs and end users alike. As Congress was drafting one of the early anti-spam bills, the Netizens Protection Act of 1997, Representative Chris Smith’s office reached out to me to see if ISP/C would endorse the bill. After waiting for them to fax it over (yeah I know, crazy), I finally got the draft, and was shocked to find a line in the bill which would have made it ILLEGAL to send ANY email without attaching your real name to it. Online anonymity was a right that needed to be protected, and this legislation would set a dangerous precedent that the ISP/C could not endorse. More than just not endorsing the bill, it was important for us to get Chris Smith and his team to understand why this was such a critical issue, as soon as possible. I was able to get in touch with the legislative analyst for the bill, and had several in-depth conversations with him about the right to privacy, user protections, and the goals we were working towards at ISP/C. Eventually, we were able to get that language removed, and replaced with language that instead only required a valid return email address, for users sending out unsolicited commercial emails: a solution that, I think, everyone is probably thankful for, well, except the spammers. ;)

I wanted to share these stories to demonstrate a long and ongoing commitment to protecting the rights of individuals online, and also to show how strategic, collaborative engagement works to produce better outcomes.

WHY WE STARTED NETKI

When we started Netki in 2014, we wanted to find ways to make bitcoin (and all blockchains) easier for normal individuals to use. Our first step was to build out our Wallet Name Service. Wallet Name service, (based on DNSSEC and optionally the Namecoin blockchain) gave people the ability to share an easy to use name, such as “justin.bi.tt” in place of their complicated wallet address. When we designed this, we thought not just about ease of use, but also security and privacy, both of which we wanted to improve, compared to current processes.

First, we required the use of DNSSEC so that the address transfer was cryptographically signed (in a manner similar to bitcoin transactions), and that the sender’s wallet could validate that the chain of trust was complete, and therefore ensure that the address hadn’t been tampered with in transit. This was a major improvement over then current practices of sending wallet addresses over unencrypted email, or via social media.

HOW NETKI HAS ALWAYS BEEN PRIVACY FIRST

From a privacy perspective, we implemented BIP32 (HD Wallet) into our product before it even launched, allowing users to share their Wallet Name with as many people as they want, and still know that each person will only be able to tie the Wallet Name and the wallet address used for the transaction to their OWN transactions. The fact that the use of a unique wallet address for each transaction hasn’t already been made automated for end users has led to CoinLab to announce they have successfully ‘de-anonymized bitcoin’ https://coinlab.com/blog/post/exploring/ . We saw this risk coming and wanted to make it brain dead simple for end users to use HD wallets, and therefore improve on-chain privacy. We hope that most major wallets and exchanges will support this, or some other mechanism to protect their users’ privacy, by making HD address generation automatic in their users’ wallets, without making the users themselves have to do any extra work.

We also included support for the Payment Protocol, BIP70 so that the sender could know who they were sending to, before confirming a transaction. The user experience for this would be: type in an easy to remember Wallet Name, and get back the “little green lock” that people are used to when browsing the web, and the ‘identity’ (self signed, e.g. their email address; or 3rd party validated) of the party they are sending to. We saw this as a major step forward in terms of both improving the current user experience, making bitcoin feel more comfortable for the users we all, as a community are trying to get onto the network.

Sometime in mid-2015, we read an article proposing Store & Forward servers as a way to allow for offline message passing between bitcoin wallets. We loved the idea so much, that we decided to start building an open-source service that acted as a Store & Forward server, called Addressimo. During the development phase we uncovered a hole in the security model of the proposed idea. All messages stored on the service were almost completely open for anyone to view. In the event of a compromise, an attacker would most certainly have access to all of the messages being passed between wallets, and along with that, all of the wallet addresses included in the PaymentRequest messages.

So we started to think amongst ourselves and eventually spoke to the folks at Breadwallet about a solution to this problem. Eventually we decided that all messages should be end-to-end encrypted using shared, ephemeral keys such as the scheme employed by TLS. To that end we began to write and refine what would eventually become BIP75, an extension to the already existing BIP70 Payment Protocol. The primary focus of BIP75 was, and is, to enhance user privacy and security in an open-standards way for an open-standards network.

We liked the option, present in BIP70, that allowed the user sending funds to see and verify with their own eyes that the receiver was, in fact, who they purported to be. A natural extension of this, we concluded, was that it would be helpful if this existing facility in BIP70 could be included in an ‘Invoice Request” message, so that both parties to a transaction could share information, that would allow them (and ONLY those parties) to know something more about ‘who’ (this information can be something as basic as an email address) they are transacting with.

The culmination of months of ideation, design, and implementation work brought together many things that we at Netki believed were missing from current bitcoin applications that would be hugely helpful towards continued mainstream adoption, including improved ease of use, and increased security and privacy. The major features of BIP75 are:

• Allows for end-to-end, fully encrypted two-way communication of payment information between the parties to a transaction (and ONLY those parties)
• Makes Store & Forward services usable and secure for mobile wallet applications
• Optional information sharing between users who choose to share (about ‘who’ they are), via an encrypted, private channel
• Application-level protocol that does not in any way interfere with or change the core Bitcoin protocol
• Permissioned wallet address release
• Allows for an address book feature on wallet applications without static wallet addresses

Finally by using BIP75 we encourage the use of a unique address per transaction, which improves user privacy, by protecting against potential leakages that can be acquired using analytics tools, and other forms of ‘prying eyes’. In summary, we designed a protocol that makes it easy to share information with who you want, while at the same time making it harder for outside eyes to spy on what you are doing.

WHY A BIP?

Originally, we at Netki were unsure if BIP75 should actually be proposed as a BIP. When we starting digging in and looked at things, however, it became apparent that this was really the only proper route to take. First, the work we are doing here is an extension of the work that was already done on BIP70. If we are to use history as our guide, the core development community (at the time) that authored and contributed to BIP70, must have believed that the BIP process was appropriate for this kind of proposed extension. Next, we took a closer look at the details themselves. This kind of communication between wallets can clearly benefit from a standard, and the method for creating such a standard can clearly benefit from the peer review generated by an open, standards based process. In the bitcoin ecosystem, that place is in BIPs. We have already seen the benefits of engaging in this process, and improved the proposal multiple times based on the feedback we have received from other developers.

We also believe that we as a community will end up with a better mechanism for the handling and sharing of identity, if we work together in an open manner rather than allowing things to transpire behind closed doors without proper community input or oversight.

KYC

Currently, there are many bitcoin companies that must comply with existing AML/KYC reporting requirements (e.g. exchanges and custodial wallets in the U.S. that are classified as MSBs), and as a result, have to employ certain ‘Know Your Customer’ measures as part of their ‘risk-based approach’ to compliance. There are also many bitcoin applications that do not have to comply with these regulations (e.g. non-custodial wallets with no exchange feature), and therefore do not have stringent requirements surrounding the collection of identity information about their customers. The bitcoin ecosystem is a diverse and growing community of users that clearly finds utility in both kinds of applications. In terms of the regulated service providers, a problem with some of the approaches to these measures, today, is that they can work to isolate transactions within ‘walled gardens’, where a user on one service can’t send funds to a user on a different provider. We see the potential for these walled gardens to reduce user choice, and constrain the overall ‘openness’ of the ecosystem, by boxing users into certain institutions, if they want to exchange funds with certain parties. With BIP75, via the encrypted two-way data exchange, we saw the opportunity to allow transactions to take place in a truly open network while maintaining the ‘on-chain’ privacy of the transacting parties. With the existing challenges surrounding compliance with regulatory reporting requirements, we ultimately see the development of standardized means to meet these requirements in a way that fundamentally protects and improves user privacy as a critical step in the development of real world solutions that utilize and/or interact with Bitcoin and other blockchains.