What does the upcoming Nash MPC API mean for cryptocurrency’s automated trading?
Turkish translation: https://t.co/8XTtz2irXE
Fabio Canesin of the Nash Exchange recently tweeted about an upcoming update: the introduction of a decentralized Automated Programming Interface (API).
Let’s toss around some words and explore what is potentially implied by automated trading with decentralized API signatures on the Nash Exchange — just for entertainment purposes.
What does an API do for an algorithmic trader?
When you visit a website, you are requesting the website’s server to retrieve information from a database and display it to you on your browser. If a website has visitors that may want to make large data requests, either in volume or frequency, then a website will offer an API to accommodate and streamline those requests. It’s a more efficient way to retrieve and deliver the data to accommodate such requests.
An algorithm is a process. If you wrote down instructions on how to make a peanut butter and jelly sandwich, you have fashioned a PB&J algorithm. Algorithm trading can be thought of as creating a set of instructions for a trading strategy and automating that strategy. The computer does the trading. An API is a mechanism for a trader to interact with an online exchange to gather data through the API, and then also execute trades through the API.
Algorithmic trading step one: Gather data
Algorithmic trading strategies are based on a complex web of mathematics strung together with calculus, linear algebra, statistics and probability. It’s hard to accurately predict what a successful strategy looks like and, to make matters worse, a successful strategy is temporal. Many are only successful for a while, then the game changes, and the profitable trader must adapt.
The process is a back-and-forth between developing strategies, testing strategies and then implementing them. In order to test a trading strategy (with its complex mathematics), a trader will gather historical price data from the exchange along with whatever other data is believed to be useful in the search for correlations to price activity.
This is a large data request sent through the API. The trader then organizes (wrangles) that data and devises a strategy to test. Actually, the trader either tests his own strategy or asks a computer to look and possibly suggest a strategy for testing, but we don’t need to dive too deep into deep learning.
After traders gather a large set of data through the API, about 80% of that data is used to develop a strategy, and the other 20% is reserved to test the strategy to see if it would have worked. If it turns out that strategy would have been profitable in the past, it’s time to see if it remains profitable in the future.
Algorithmic trading step two: Execute the trade
The algorithmic trader, now ready to implement the strategy that has been developed and tested, makes the second use of the API. The benefit of automating a trading strategy is that the computer can watch more order books than a human can, and a computer can execute trades much faster, and with much higher frequency, than a human can. Algorithmic trading is even commonly referred to as “high-frequency” trading. The high-frequency element allows for finding and trading within windows of profitability that may only exist for fractions of a second. Buy low and sell high, really quickly, making little bits of profit, over and over again.
Algorithmic traders draft computer code to execute these trades for them, which typically sits on a remote server so it can operate continuously. The code has to contain a way to provide the exchange with account credentials, so it will include a configuration to connect your account to the exchange through the API — some way to sign and authorize account transactions. The orders to buy or sell are then communicated from the algorithmic program on the server to the exchange through the API. The algorithmic trader’s capital maintains a continuous presence on the exchange so that the high-frequency trades can be executed.
The institutional account and the multi-party computation API
Fabio Canesin’s recent tweet informed the world that the Nash Exchange is releasing a decentralized API using multi-party computation (MPC). This is important because of the implications it has for taking the next steps in providing a user experience on a decentralized exchange (DEX) that was previously only available on a centralized exchange (CEX).
Canesin’s tweet, published on March 13, reads as follows:
Next week we will deploy MPC API keys for public testing on https://app.sandbox.nash.io, and public BTC trading testing the following week.
More details on deploys TBA from @nashsocial.
We reward responsible disclosure at email@example.com
There happens to be a very informative discussion on the Nash Community forum between Nash Ambassador “Nick”, creator of the popular NEX Staking Calculator stakingnex.io, and Fabio Canesin. We can eavesdrop on a couple of smart guys getting on the same page about what MPC is.
Nick starts us off:
Well, the easiest way to explain is to look at the name of the beast: multi-party computation. This means that multiple parties (users) can access 1 private key/account without holding the exact same key. Their combined keys make the final private key. This enhances security because you can set it up in a way that a transaction must have approval from multiple parties (threshold signatures) before execution is allowed… This is great for institutions because they don’t rely on the security of 1 single point of failure (the single private key as we currently know).
Nick goes on to ask a few questions and Canesin offers some clarification. Two keys are not combined into a third key. Rather, “pre-signatures” from each key are combined into a final valid signature:
Nash and users collaborate in a protocol to form the final signed transaction! This means that users generate what we call a “pre-signature” using their keys, then Nash receives an encrypted message that it operates on without decryption (this property is called homomorphic) to generate the final signature… With our MPC, users collaborate in a protocol to generate a valid signature, not a final key.
If you want to look at more, the full discussion is here. I’m not going to try to add to it. Like I said, it’s already two smart guys talking about the subject. For now, we can work with this: MPC is what provides for an API on a DEX to function and perform in similar ways to an API provided by a CEX. Let’s move on to some of the implications of decentralized automated trading on a DEX.
Security from the exchange perspective
Most automated trading algorithms, by design, maintain a continuous presence on an exchange. If the trading algorithm is profitable, then the financial exposure to risk increases with time, and remains in perpetuity. If there is an above-zero chance of a single central point of security failure, then the risk/return analysis is ugly. If a security failure happens at any point in time while capital is exposed — which is always if the algorithm is profitable — then there exists a guaranteed negative impact of a security breach.
Now, consider automated trading on a DEX with state channel scaling. Nash is the first decentralized exchange to offer the trading conditions institutions are familiar with, but with extra security. The time of exposure to the risk element in the risk/return equation has disappeared! There is no exposure to a central security breach. The common crypto warning for new users to “never leave tokens on the exchange!” doesn’t apply to Nash. Noobs can go on and noob out and absolutely leave their tokens on the exchange. So can algorithmic traders. Neither has to worry about a central security breach on the exchange end.
Even in the unlikely event the Nash Exchange servers fail, the order book falls to stasis and tokens can be retrieved from the trading contract back to a user’s wallet. If MPC signatures are distributed across multiple users — for example, a setup for an institutional trading account — and a breach occurs with one of the MPC signatures, Canesin explains the scenario:
A user would “revoke” a set of keys and create a new key for the same account using his 12 words.
Custody of capital is always retained by the trader. The risk/return analysis looks completely different on the Nash Exchange. Exposure to security risk isn’t present.
How Nash extends security to the user
Up until now, an API on a DEX could only be connected with one account, via the private key. Those conditions have presented a problem for institutional accounts. If an institutional account were to consider trading under such conditions, it is looking at distributing the actual private key, with full and complete access, across several individual traders, thereby exposing the institutional account to internal security liability that many institutions may not be comfortable with.
Institutions have a common structure of allowing individual traders, or teams of individuals, to engage in the algorithmic process described above and to devise their own automated trading strategies. Because profitability is temporal and elusive, institutions will diversify their institutional strategy across several different component strategies. The collective institutional strategy contains many individual moving parts. The MPC signatures on the Nash Exchange allow the institution to distribute signatures to it’s traders and maintain certain measures of control over the amount of authority that is granted to those component signatures in managing funds.
Now that we have discussed the problem, and the solution that has been presented, we can appreciate how it extends the theme of security. On the Nash Exchange, there can now be a main institutional account that holds the private key, which can be placed in a super-top-secret James Bond vault. That institutional account can then use the private key when it needs it, generate MPC signatures and distribute them to individual traders, and put the private key back in the vault. Those MPC signatures provide a few functional utilities.
First, they insulate the institutional account from a security breach on the user end (remember, Nash is a DEX, so the security breach is solved on the exchange end). The MPC signatures extend security measures to the user end for both the institution and the individual.
The MPC signature protocol can be configured to only work in conjunction with another signature, thus preventing unilateral action (picture old 1980s movies where two different generals needed to simultaneously turn their keys to enter the nuclear launch codes). The MPC signatures can be configured with trading limits. This provides security measures to prevent an individual rogue trader from emptying the whole institutional account. Or, an MPC signature can be configured to restrict withdrawals to the institutional account addresses — again, guards against the rogue trader.
MPC signatures also open the door to future security features to be developed for the individual user in the near future. MPC signatures can provide additional safety features that guard against common horror stories that circulate through crypto. Trading limits and withdrawal limits help to insulate the individual from security breach in the same way they do for the institution. More updates on such features will be provided soon!
Testing is available now
Nash is extending an invitation to trade on their exchange and it reads as follows: Decentralized MPC API available for algorithmic trading on a state channel DEX. Oh, and BTC (the OG, not a wrapper) is going to be available for trading too. When it’s time to talk about security, Nash comes to the mic hard.
You can even go ahead and start testing things out now. Fabio Canesin authored a market-maker for the Nash Exchange’s original API, available on gitlab at https://gitlab.com/nash-io-public/nash-makerbot, which might help get you started.