UIP 1: Optional Permissioned Liquidity Pools

[mgarciap]

Uniswap Improvement Proposal

UIP 1: Optional Permissioned Liquidity Pools

Simple Summary

A Pool Factory extension to allow creation of pools and token swapping, where participants can have a choice to be compliant with their local or international laws.

Use case 1: Every non-US corporate and institutional liquidity providers (such as crypto hedge funds, market makers, OTC desks) is mandated, by US Government to pay taxes in the US for income received from US sources. To do so, liquidity providers must know the country of residence (but almost never identity) of Uniswap users who generated that income. To do so, such liquidity providers must have a "country of origin" report for all income they receive from liquidity pools.

Use case 2 - most (but not all) corporate and institutional liquidity providers must have an attestation that Uniswap users - specifically makers and takers (payers of the income generated by liquidity providers) were AML'ed by a 3rd party KYC provider such as onFido, Wyre, Jumio, etc. Almost never liquidity providers want an actual identity of a Uniswap user, - as long as there is a name of 3rd party AML provider and an anonymized customer ID behind 100% of the income received by such liquidity provider.

Use case 3 - most (but not all) corporate and institutional Uniswap users who want to swap tokens must have an attestation that their counterparty in Uniswap - were AML'ed by a 3rd party KYC provider such as onFido, Wyre, Jumio, etc. Almost never makers or takers want an actual identity of a Uniswap user, - as long as there is a name of 3rd party KYC provider and an anonymized customer ID behind 100% of the income received by such liquidity provider.

Abstract

This proposal aims to extend Uniwap by adding a new optional feature for users: Know Your Customer (KYC), Anti-Money Laundering (AML), and Combating the Financing of Terrorism (CFT) regulations compliance. This feature will allow individuals and institutions alike to exchange and invest using Uniswap when these regulations apply.

Motivation

There is a huge opportunity for exchanges such as Uniswap to attract individuals and institutions looking for investment opportunities that require to comply with regulations (e.g.: file reports with both the Internal Revenue Service and the U.S. Treasury, pay taxes on capital gains, etc.). Also, it is needed that every potential counterparty also comply with the regulations. This opportunity is very valuable even if they must go through a thorough KYC/AML/CFT process.

Current permissionless liquidity pools do not enforce KYC/AML validations, which is ok, however they prevent certain traders and investors from using Uniswap.

Specification

Pool Factory extension supporting only KYC’ed addresses to add/remove liquidity, swap and send tokens

In the current implementation only one pool can exist for a given token. We propose adding the possibility of having parallel sets of pools. Each pool in a set can only be used by a given smart contract (meaning, a set of pools is defined by the smart contract that can use those pools). The address of this contract is specified when the pool is created, and then all the interactions with those pools must go through that contract. That is: exchanges created this way will check that msg.sender is equal to the proxy address that was used for creating the pool.

If this is supported, then a set of pools could be created so that they can only be used by addresses that went through a KYC/AML process. This can be done by checking that the account possess some KYC/AML token (see next section).

Note: Both approaches can be useful outside of this: Uniswap can use this “Sender address” for more customized pool factories, and this KYCProxy contract can be used as a proxy for any other contract that requires KYC.

In this diagram, we can see how the Registry works today, and how this new registry would work. Notice that the old Registry can continue to work, and the existing liquidity pools are still accessible. We have five different scenarios:

• A.1 A user adds liquidity to the BAT pool through the (current) registry
• A.2 Users can also interact with pools without using the registry
• B.1 If the user doesn't specify a Proxy, the call is delegated to the old registry
• B.2 If the user specifies a Proxy address, the call is delegated to that added, which then uses a pool that only that proxy can call
• B.3 Proxied pools can't be used by users directly

Wyre for KYC/AML validation

Wyre offers a service for validating KYC/AML information and it can associate this validation to an ethereum account. This is done by depositing a "KYC token" in that account's address. The KYCProxy contract could just check that this token exists for the transaction originator.

By using the Wyre widget, a full customer on-boarding with minimal coding KYC/AML widget can be integrated into Uniswap UI and flow.

Wyre is just one of the many KYC providers that can be plugged into a standard mechanism.

“KYC’ed pools” to be created from Uniswap UI

[mgarciap]

Hi @haydenadams, any thoughts?

[MicahZoltu]

Since liquidity isn't shared between pools, this seems like a better fit for a separate project rather than trying to bundle it into Uniswap directly. KYCed Uniswap could have a separate UI, separate branding, etc. which would help make it more clear what you are talking about when you say, "there is X liquidity on Uniswap" (which may be a vastly different number if you are talking about the KYCed portion vs the permissionless portion).