Independent custody for crypto hedge funds trading on multiple exchanges

 

We believe that self custody for crypto hedge funds trading on multiple exchanges is not a viable institutional solution (see this paper on self-custody we wrote earlier). Although many custodians claims to have institutional custody, in practice they lose control of the fund’s crypto assets when they send them to an exchange.

 

While we have been seeking to setup a crypto arbitrage fund for some time, we decided to only launch a fund once a solution to self-custody was available. Nickel Asset Management has been working with the London-based custodian, Copper (copper.co), who have developed a working solution to the self-custody problem.

The Walled Garden

 

This solution creates a walled garden that surrounds the fund’s custodian and the exchanges on which it trades. This walled garden is a secure area where transfers can be made frequently, rapidly and safely between custody and the intra-mural exchanges. Moving funds outside the walled garden will still require multiple signatures and is a more onerous procedure but it would only be used in the case of a redemption which only happens with a monthly or lower frequency.

In order for the exchanges to operate within the walled garden they need to have a REST API for withdrawals, permissioned API keys for withdrawal only, trading only and read only, and, for extra security, the ability to specify whitelisted addresses for withdrawal purposes. Some exchanges also allow main account and sub-accounts which makes exchange operations simpler.

 

Why do we need these exchange capabilities?

1) The REST API for withdrawals enables the investment manager to request transfers via the custodian’s website which the custodian can then initiate using the REST API.

2) Permissioned API keys enable the various parties of custodian, investment manager and fund administrator to perform their roles: The custodian’s withdrawal-only API key enables them to withdraw crypto funds from the exchange. The investment manager’s trading-only API key enables them to trade on the exchange but not to withdraw funds from the exchange. The administrator’s read-only API key enables them to view trade, position and price exchange data to enable them to produce the fund NAV and reconcile trades and positions.

 

3) Whitelisted addresses for exchange fund withdrawal ensure that once these addresses have been set up and the exchange security credentials secured, that withdrawals from exchanges are restricted to blockchain addresses within the walled garden. The only blockchain addresses that will be whitelisted are the fund’s blockchain address (controlled by the custodian) and the exchange blockchain addresses for the fund accounts.

4) Exchange sub-accounts enable the investment manager to logon to the exchange to trade without having to use an Execution Management System (EMS). However in practice most investment managers will use an EMS or trading bots to improve market access and to reduce slippage. This is a feature that only a few exchanges currently offer although as the space institutionalizes it should become widespread.

The diagram below illustrates the main points of the Walled Garden solution:

1) All funds transfer requests pass through the custodian

2) The custodian instructs the exchanges on receipt of a transfer request

3) The investment manager does not have access to the exchanges for transfers

The Walled Garden

How do we add an exchange to the Walled Garden ?

The walled garden doesn’t appear out of nowhere and it needs to be established. This is our current setup process which will no doubt be improved upon as exchanges and service providers mature.

The steps to set this up are as follows:

1) The investment manager gathers the fund KYC documents necessary to open exchange accounts.

2) The investment manager (with fund directors, if necessary ) opens the exchange accounts. No crypto funds have yet been transferred to the exchange.

3) The investment manager sets up the whitelisted blockchain addresses for the custodian’s account for each cypto used as margin on the exchange (In our case BTC and some stable coins).

4) The investment manager generates the trading and read-only API keys for the exchange. The read-only key is given to the administrator.

5) The investment manager passes the exchange security credentials (username, password ) to the custodian. No 2FA has been set up as this will be set up by the custodian.

6) The custodian checks the whitelisted blockchain addresses set up by the investment manager are the valid addresses of the fund and the fund’s exchange account addresses. The custodian adds the fund’s exchange account addresses to its own whitelist.

7) The custodian generates the exchange transfer key and incorporates it into their system for exchange to custody transfers using the custodian’s systems.

8) The custodian changes the account email and password and adds 2FA to the exchange account. This process is actually slightly more involved that this although we currently prefer to keep it secret for security purposes.

9) The custodian securely stores exchange security credentials and passes an encrypted copy to the administrator to store in case of corruption of the custodian’s systems.

10) The custodian passes the 2FA device to the administrator. In this way neither the custodian nor the administrator has access to the exchange account. Access to the exchange account can only be made by the custodian and the administrator acting together.

11) The investment manager can now ask the custodian to send crypto assets to the exchanges for trading and margin. These transfers will only be sent to exchange addresses (that have been whitelisted at the custodian).

12) Withdrawals from the exchange to the custodian or direct to other exchanges can be made by the investment manager using the custodian’s system as the exchange whitelisted addresses have been restricted to be the custodian’s and the other exchanges.

What are the drawbacks ?

There are a couple of minor drawbacks to this solution:

Direct access to exchanges

Unless the exchanges support sub-accounts the investment manager does not have direct access to the exchange to trade and would have to use the exchange API to trade on exchanges either with trading bots or EMSs such as Coinigy or Caspian (we will soon publish a review of crypto EMSs). In practice most managers would use an EMS so they can use more sophisticated orders (Iceberg, etc) that those currently offered by the exchanges.

Changes to exchange account

Occasionally the investment manager may need to make changes to the exchange account. While this is unlikely to be frequent it may be necessary. If the changes are simple the administrator and the custodian working together can make the changes. If the changes are complex the custodian and administrator can remove the 2FA and reset the exchange security credentials so the manager can assess the account to make the changes. Note that before any changes are made to the exchange account the manager would send all the crypto on the exchange account back to custody. In this way the manager would only be accessing an empty account.

Summary

The Walled Garden solution with Copper as custodian now exists for crypto hedge funds trading on multiple exchanges. This creates a secure area that surrounds the fund’s custodian and the exchanges on which it trades. This walled garden is a secure area where transfers can be made frequently, rapidly and safely between custody and the intra-mural exchanges. Individually neither the investment manager, custodian nor the administrator could be forced by a criminal party to transfer the fund’s crypto assets from the exchanges.

Institutional investors in hedge funds can now be confident that the funds they invest in crypto hedge funds are not self-custodied when held on exchange.

To learn more about the solution contact Copper at [email protected]

To learn more about crypto arbitrage contact [email protected]

Source: Crypto New Media

Close

Request For My Information

 
Close

Request For Account Deletion

Close

Request For Information Deletion

Close

General Request / Query To DPO