One of BitMEX’s claims to fame is the ability for clients to use 100x leverage while trading the Bitcoin / USD price. We often get asked to what extent traders use the maximum leverage offered. I asked our data science team to pull up historical data on leverage usage for the XBTUSD perpetual swap from May 2018 to April 2019.
The first chart and table combo shows the weighted effective leverage at month end for XBTUSD longs and shorts.
It appears traders are quite “responsible” in that they do not on average use the maximum amount of leverage.
Definitions aggregation grouped by month, side, and symbol
Methodology for Calculating Percentiles
Pick the last available timestamp for each of the prior 12 months (i.e. ‘month-end snapshot’), and calculate the effective leverage for every position across all accounts rounded to the nearest integer
Create a sorted list from the resulting values, flattened by expanding each position’s resulting effective leverage by the number of contracts held (e.g. if an effective leverage of 3 was used by an account with a position quantity of 4, it’s a contribution to the list is '3 3 3 3')
Any given percentile of this list can be found by taking the value at the index given by: (Count of the list) * (Desired percentile)
Using the mean is crude because traders who hold large positions must use less leverage than smaller traders. This is due to the risk limit feature of BitMEX. Traders may use 100x leverage up to a position size of 200 XBT. After that, the initial and maintenance margin requirements step up 0.5% per 50 XBT.
To understand the distribution of leverage respective to the number of contracts, we looked at a histogram of XBTUSD long and shorts averaged over the 12 month-end snapshots from May 2018 to April 2019. The above two charts display this data. As we expected, the largest traders use the least amount of leverage.
While the maximum leverage allowable for opening a position in XBTUSD is 100x, the effective leverage can then increase to 200x (i.e. the reciprocal of the 0.50% maintenance margin requirement), at which point liquidation occurs.
Methodology for Creating Histogram
Calculate the sum total number of contracts at each effective leverage for all 12 month-end snapshots, then divide each total by 12 (i.e. average month-end snapshot)
I hope this data allows traders to better understand the BitMEX market microstructure. I will continue to periodically post backward looking statistics in the near future.
We are pleased to introduce updates to the BitMEX visual identity. Starting today, you will see the replacement marks applied to all BitMEX properties. For some background on the history of our logo, as well as the construction of the update, please read on.
Our History
The BitMEX logo was created in early 2014 before the launch of the initial trading platform and is a representation of the ‘put-call parity’. The put-call parity defines that a futures contract (or more simply, a forward) can be replicated by a portfolio consisting of a long call option and a short put option.
The original logo design was a literal interpretation of the put-call parity formula, which, while effective, proved unwieldy when applied to a myriad of real-world scenarios. Over time, we have made the icon and logo less representational, and more flexible, to allow for easier use in social media, contracts, and everything in between that comes with running a modern trading platform.
What’s Next
As we continue to improve the BitMEX trading experience, we will also be improving the look and feel of the platform so as to give you all the information you need to make intelligent, decisive trades on a clean, easy-to-read, and professional platform.
We value all the support and feedback we have received over the past few years, please continue to let us know how we can continue to improve, on Twitter, and through our support page.
Abstract: In this piece we present data on a relatively new phenomenon, Initial Exchange Offerings (IEOs). The ICO market is down around 97% in Q1 2019 (YoY), based on the amount of capital raised. In this relatively challenging climate to raise funds, some projects have changed the “C” in ICO to an “E”, perhaps in an attempt to assist with raising capital. At least for now, to some extent, this appears to be working, with almost $40m having been raised so far this year. However, we remain sceptical about the prospects for long term investors.
Overview
We consider an Initial Exchange Offering (IEO) as the issuance and sale of a token based on public-private key cryptography, where participation in the issuance occurs exclusively through one trading platform or exchange. This piece provides a basic overview of the largest IEOs and tracks various IEO token metrics, including investment performance.
ICO market
First we briefly look at the ICO market. As the following chart indicates, the market has dried up following a massive boom in 2017 & 2018.
Funds raised by ICOs – US$M
Source: BitMEX Research, icodata.io Notes: Data as at 25 April 2019
As the below chart illustrates, the investment returns of the 2018 ICOs has been poor, many of the projects are down around 80% from the ICO price, if the coin even trades at all. Peak to trough, project token prices typically declined much further than this.
Top ten ICOs by funds raised in 2018 – Investment performance data
ICO Name
Funds raised – US$m
Return based on average ICO price
EOS
4,234
(4%)
Telegram
1,700
Coin not listed
Dfinity
195
Coin not listed
Bankera
150
(87%)
t0
134
Coin not listed
Basis
125
Returned capital to investors
Orbs
118
(64%)
PumaPay
117
(93%)
Jet8
33
(99%)
Unikoin Gold
32
(88%)
Source: BitMEX Research, tokendata.io Notes: Data as at 25 April 2019
Changing a “C” into an “E” – The IEO market
Perhaps in an attempt to address some of the concerns about the poor investment returns and the lower levels of enthusiasm for ICOs, IEOs appear to have gained in popularity. Below is a list of the major IEOs and the main exchange platforms involved.
List of IEO token sales
Coin
IEO Date
IEO issue amount vs total coin supply
Return vs first exchange trade price
Return vs IEO price
US$m raised in IEO
Binance
Gifto
21/12/2017
3.0%
(90.5%)
142.2%
0.4
Bread
26/12/2017
7.9%
(84.2%)
164.6%
0.8
Fetch.AI
02/03/2019
6.0%
(55.0%)
203.6%
4.1
BitTorrent
03/02/2019
6.0%
54.8%
433.9%
7.5
Celer
24/03/2019
6.0%
(29.4%)
82.0%
4.5
Matic
24/04/2019
19.0%
Ongoing
Binance Total
17.3
Huobi
TOP
26/03/2019
7.5%
10.2%
357.0%
3.3
Newton
16/04/2019
2.0%
(23.0%)
197.0%
4.8
Huobi Total
8.1
Bittrex
VeriBlock
02/04/2019
3.3%
(30.9%)
(33.0%)
7.0
RAID
Canceled
OKEX
Blockcloud
10/04/2019
5.0%
(43.1%)
599.7%
2.5
BitMax
Dos Network
11/04/2019
14.2%
(55.1%)
74.2%
1.7
Kucoin
MultiVAC
03/04/2019
6.0%
(30.5%)
20.0%
3.6
Source: BitMEX Research, IEO Launchpad websites, Coinmarketcap Notes: Data as at 25 April 2019
The number of IEOs taking place has intensified in recent months, as the model is proving somewhat successful. Smaller exchange platforms are attempting to replicate the model, as the long list of IEOs below illustrates.
Other IEOs with limited data available
Coin
IEO Date
Platform
Coin Analyst
07/07/2018
Exmarkets
SID Token
15/11/2018
Exmarkets
Rebglo
01/12/2018
Coineal
Aerum
01/01/2019
Exmarkets
TerraGreen
21/01/2019
Exmarkets
Verasity
01/03/2019
Probit
Percival
05/03/2019
Coineal
Decimated
06/03/2019
Exmarkets
Menapay
15/03/2019
Exmarkets
Linix
16/03/2019
Probit
Levolution
18/03/2019
Coineal
WeGen
18/03/2019
Probit
Spin Protocol
19/03/2019
Probit
CharS
20/03/2019
Probit
Windhan Energy
21/03/2019
Exmarkets
HUNT
23/03/2019
Probit
KIZUNA GLOBAL TOKEN
25/03/2019
Coineal
PUBLISH
26/03/2019
Probit
ZeroBank
31/03/2019
Coineal
REDi
03/04/2019
Probit
VenusEnergy
04/04/2019
Exmarkets
Bit Agro
05/04/2019
Exmarkets
XCon
06/04/2019
Coineal
YellowBetter
08/04/2019
Bitker
Link by BlockMason
09/04/2019
BW
GTEX Gaming Platform
12/04/2019
Coineal
AlienCloud
16/04/2019
IDAX
Evedo
16/04/2019
Bitforex
PantheonX
18/04/2019
BW
NUVO
19/04/2019
Probit
Grabity
19/04/2019
BW
Farm2Kitchen
22/04/2019
Exmarkets
Cryptobuyer
23/04/2019
Coineal
Airsave Travel
01/05/2019
Exmarkets
Source: BitMEX Research, IEO Launchpad websites
With respect to all but one of the tokens, investors have earned strong positive returns based on the IEO price. However, after the tokens begin trading, the investment returns have typically been poor. This is illustrated by the below chart, which rebases the token price to the IEO issuance price.
IEO Investment performance since launch (IEOs in 2019)
Source: BitMEX Research, IEO Launchpad websites, Coinmarketcap Notes: Data as at 25 April 2019
US$38.9m has been raised so far by IEOs in 2019 (up to 25th April). Binance has been the most prolific IEO platform by a considerable margin.
Top exchange platforms by IEO funds raised – US$m
Source: BitMEX Research, IEO Launchpad websites, Coinmarketcap Notes: Data as at 25 April 2019
The proceeds from IEOs can be relatively small, however on average only 4.4% of the total token supply is made available in the sale. Therefore, there are opportunities for project teams to make considerable profits from selling coins they granted to themselves. The 2019 IEOs were priced at a level which implies a total market capitalisation of US$907.7m, based on the disclosed total token supply.
Top exchange platforms by IEO token market capitalisation at IEO price – US$m
Source: BitMEX Research, IEO Launchpad websites, Coinmarketcap Notes: Data as at 25 April 2019
Conclusion
While exchanges, traders & subscribers may have done very well from IEOs thus far, we are less confident on the outlook for long term investors. However, this is simply a high level analysis – we have not looked into any of the individual projects in detail.
Disclaimer
Any views expressed on BitMEX Research reports are the personal views of the authors. BitMEX (or any affiliated entity) has not been involved in producing this report and the views contained in the report may differ from the views or opinions of BitMEX.
The information and data herein have been obtained from sources we believe to be reliable. Such information has not been verified and we make no representation or warranty as to its accuracy, completeness or correctness. Any opinions or estimates herein reflect the judgment of the authors of the report at the date of this communication and are subject to change at any time without notice. BitMEX will not be liable whatsoever for any direct or consequential loss arising from the use of this publication/communication or its contents.
If we have made any errors in relation to particular projects, we apologise and are happy to correct the data as soon as possible.
Abstract: We summarise and provide context for a recent Bitcoin softfork upgrade proposal, which includes a new digital signature scheme (Schnorr), as well as a complementary upgrade called Taproot, which adds new capabilities that extend Bitcoin’s smart contracting capability. The upgrades are structured to ensure that they simultaneously improve both scalability and privacy. Other than increased complexity, there are no significant downsides to the proposal, and the most controversial aspect of it is likely to be the lack of other anticipated features. We conclude that although many will be enthusiastic about the upgrade and keen to see it rolled out, patience will be important.
On 6th May 2019, Bitcoin protocol developer Pieter Wuille posted a softfork upgrade proposal to the Bitcoin developer mailing list, called “Taproot”. If this proposal is accepted, it is likely to complement the Schnorr signature softfork upgrade, which Pieter posted in July 2018. The benefits of these proposals are related to both scalability (efficiency) and privacy. Scalability and privacy enhancements now appear somewhat interrelated and inseparable. Removing details about transactions, ensures both that transactions are smaller (improving scalability) and that they reveal less information and are therefore potentially indistinguishable from transactions of different types, thereby improving privacy.
Schnorr Signatures
The Schnorr signature scheme was patented in 1991 by Claus Schnorr and the patent expired in 2008. Although the Schnorr scheme is said to be stronger, a variant of it, the Digital Signature Algorithm (DSA) scheme was more widely adopted, as the patent for this scheme was made available worldwide royalty free. However, Dr Schnorr himself always maintained that DSA should be covered under his patent.
When Bitcoin was launched, in 2009, it therefore used a variant of DSA, Elliptic Curve Digital Signature Algorithm (ECDSA) for its digital signature scheme, due to its widespread adoption. However, the original Schnorr signature scheme was always more simple and efficient than DSA, with less burdensome security assumptions. After 10 years of experience of Bitcoin usage, it is becoming more apparent that these efficiency advantages could be important. Therefore it seems sensible that Bitcoin should migrate over to the Schnorr signature scheme.
The main benefit with Schnorr signatures, is that multi-signature transactions appear onchain as a normal single signature transaction. Using Schnorr signatures, multiple signers can produce a joint public key and then jointly sign with one signature, rather than publishing each public key and each signature separately on the blockchain. This is a significant scalability and privacy enhancement. This implies that Schnorr signatures result in significant space savings and savings to verification times, with the comparative benefits getting larger as the number of signatories on a traditional multi-signature transaction increase.
Schnorr signature space saving estimates
We have tried to calculate the potential Bitcoin network capacity increase this aggregation feature of Schnorr multisig can provide. However, due to the large number of assumptions involved, our 13.1% capacity increase figure below should be considered as a very approximate estimate.
Savings estimates based on UTXO count
Estimated current multi-signature usage by UTXO count
(Source: BitMEX Research calculations and estimates, p2sh.info)
(Notes: The estimates ignore the impact of Schnorr’s smaller signature size and only include the benefits of joining the public keys and signatures. The capacity increase was estimated by using p2sh.info related to multi-signature usage and applying a savings multiple to each multi-signature type (ranging from 50% to 85%). A network wide capacity increase was estimated by assuming the UTXO usage proportion was typical of blockchain usage and applying a higher weight to larger multi-signature transactions. Unspent P2SH outputs were allocated to multi-signature types in proportion to the spent outputs. This figure should only be considered as a very approximate estimate. Data as at 07 May 2019 )
The above estimated capacity increase can be considered as small, however one should consider the following:
Economic usage of multi-signature technology is far more prevalent than by merely looking at the UTXO count. Around 21.5% of all Bitcoin is stored in multi-signature wallets, a far higher figure than the 5.9% adoption by UTXO count
Multi-signature adoption is growing rapidly, as the below chart indicates. While at the same time new systems like the lightning network require multi-signature adoption and with Schnorr signature making multi-signature systems more powerful, adoption is likely to increase
Bitcoin stored by P2SH address type – chart shows strong growth of multi-signature technology
Therefore, although based on the current usage of the network, according to our basic calculation, even 100% Schnorr adoption only results in a 13.1% network capacity increase, in the long term the potential space savings and network capacity gains are likely to be far higher than this.
Merkelized Abstract Syntax Tree (MAST)
MAST was an idea worked on by Bitcoin protocol developer Dr Johnson Lau in 2016. Dr Lau has written for BitMEX Research in the past, in his February 2018 piece entitled The art of making softforks: Protection by policy rule. The MAST idea is that transactions can contain multiple spending conditions, for example a 2 of 2 multi-signature condition, in addition to a time lock condition. In order to avoid putting all these conditions and scripts into the blockchain, the spending scripts can be structured inside a Merkle tree, such that they only need to be revealed if they are used, along with the necessary Merkle branch hashes.
Graphical illustration of MAST spending conditions
(Source: BitMEX Research) (Notes: The diagram is trying to illustrate a transaction structure assuming MAST was used in conjunction with Schnorr. In the above construction funds can be redeemed the cooperative way if both Bob and Alice sign, or in an uncooperative way after a timelock. The above is supposed to illustrate the type of structure which could be required when opening and closing lightning network channels)
Based on the above design, it can be assumed that only one spending condition will need to be revealed. For example, to spend the output, all the signers need to do is provide one Schnorr multi-signature and the hash at the top of the right hand side of the Merkle tree (Hash (1 & 2)). Therefore despite the existence of a Merkle tree, in the majority of cases, where everything goes as planned, only a single signature and 32-byte hash is required. More concisely, in order to verify a script, you need to prove that it is part of the Merkle tree by revealing other branch hashes.
However, the disadvantage of this structure is that even in normal optimal circumstances, when the single key and script on the top left of the Merkle tree is provided, one still needs to publish another hash to the blockchain (Hash (1 & 2) in the above diagram), using up 32 bytes of data. This weakness also reduces privacy, since third parties can always determine if more complex spending conditions exist, as the top branch of the Merkle tree is always visible.
Taproot
As far as we can tell, the origins of the Taproot idea are from an email from Bitcoin developer Gregory Maxwell in January 2018. Taproot is similar in construction to MAST, except at the top of the Merkle tree. In the case of Taproot, in the cooperative or normal scenario, there is an option for only a single public key and single signature to be published, without the need to publish evidence of the existence of a Merkle tree. An illustration of the Taproot transaction structure is provided below.
Graphical illustration of Taproot spending conditions
(Source: BitMEX Research)
(Notes: The diagram attempts to illustrate the same spending criteria as the MAST diagram above)
The tweaked public key on the left (or address) can be calculated from the original public key and the Merkel root hash. In the event of a normal or cooperative payment, on redemption, the original public key is not required to be onchain and the existence of the Merkle tree is not revealed, all that needs to be published is a single signature. In the event of a lack of cooperation or abnormal redemption, the original public key is revealed along with information about the Merkle tree.
The benefits of Taproot compared to the original MAST structure are clear, in the cooperative case, one is no longer required to include an extra 32-byte hash in the blockchain or the script itself, improving efficiency. In addition to this, the transactions looks “normal”, just a payment with a public key and signature, the existence of the other spending conditions do not need to be revealed. This is a large privacy benefit, for example when opening a lightning channel or even doing a cooperative lightning channel closure, to an external third party observer, the transaction would look exactly like a regular spend of Bitcoin. The transaction could be structured such that only in an uncooperative lightning channel closure would the existence of the Merkle tree need to be revealed. The more different types of transactions look the same, the better it is for privacy, as third parties may be less able to determine which types of transactions are occurring and establish the flow of funds. A long term objective from some of the Bitcoin developers may be to ensure that, no matter what type of transaction is occurring, at least in the so-called cooperative cases, all transactions look the same.
The confusion over Signature aggregation
The potential scalability benefits of reducing the number of signatures needed on the blockchain are large and therefore the concept tends to generate a lot of excitement. Schnorr signatures do provide the capability to aggregate signatures in multi-signature transactions, which should be a significant benefit to Bitcoin. However, the inclusion of this and the existence of other signature aggregation related ideas, has lead to some unrealistic expectations about the potential benefits, at least with respect to this upgrade proposal. As far as we can tell, for this particular upgrade proposal, the only aggregation benefits are in the form of joining signatures in multi-signature schemes, not for multiple inputs or multiple transactions.
Summary table of signature aggregation ideas
Included in softfork proposal
Combined public key and signatures in multi-signature transactions – Included as part of Schnorr
Yes
Joint signature for multiple inputs in a transaction
No
Joint signature for multiple inputs in multiple transactions (Grin coin has some capabilities in this area, using Mimblewimble)
No
(Source: BitMEX Research)
Conclusion
In our view, the benefits associated with this softfork are not likely to be controversial. This softfork appears to be a win-win-win for capability, scalability and privacy. The largest area of contention is likely to be the absence of the inclusion of other ideas or arguments over why to do it this particular way.
That being said, many are likely to be excited about the potential benefits of these upgrades and keen to see these activated on the network as fast as possible. However, when it comes to Bitcoin, and in particular changes to consensus rules, the need for patience cannot be overstated.
To better serve customer support requests, we have created a new support page to manage customer inquiries at https://bitmex.com/app/support/contact. We will continue to improve this page with future updates, such as multi-language forms.
Please note that while support@bitmex.com will continue to function until further notice, we recommend customers use this new form to contact the Support team.
Abstract: On 18th April 2019, the BitMEX Research Bitcoin Cash SV node experienced 2 block re-organisations. First a 3 block re-organisation, followed by a 6 block re-organisation. In this brief piece, we provide data and graphics related to the temporary chainsplit. The chainsplit appears to be caused by large blocks which took too long to propagate, rather than consensus related issues. Our analysis shows there were no double spends related to the split.
Chainsplit diagram – 18 April 2019
Source: BitMEX Research Notes: The above image indicates there were two valid competing chains and a non-consensus split occurred at block 578,639. Our node followed the chain on the left until block 578,642, then it jumped over to the right. About an hour later, it jumped back over to the left hand side. The chain on the left continued, while the chain on the right was eventually abandoned.
Chainsplit transaction data
Number of transactions
Main chain (within 6 blocks)
754,008
Fork chain
1,050,743
Overlap (within 6 blocks)
753,945
Eventual double spends
0
Source: BitMEX Research
Based on our analysis of the transactions, all the TXIDs from the forked chain (on the right), eventually made it back into the main chain, with the obvious exception of the coinbase transactions. Therefore, it is our belief that no double spends occurred in relation to this incident.
Timestamps of the blocks related to the split – 18 April 2019
If one is interested, we have provided the above table which discloses all the relevant details of the blocks related to the chainsplit, including:
The block timestamps
The local clock timestamps
The block hashes
The block sizes
The total accumulated PoW up to each block
With the above details one can follow what occurred in relation to the chainsplit and create a timeline.
Conclusion Our primary motivation for providing this information and analysis is not driven by an interest in Bitcoin Cash SV, but instead a desire to develop systems to analyse and detect these type of events on the Bitcoin network. Systems are being developed on our website, https://forkmonitor.info, to help detect chainsplits, caused either by poor block propagation or consensus related issues. This event on Bitcoin Cash SV is good practice for us.
As for Bitcoin Cash SV, the block sizes were particularly large during the period of the re-organisations. On the forked chain, the last two blocks were 128MB and 107MB respectively. On the main chain many of the blocks were over 50MB. Therefore, in our view, it is likely the large sizes of the blocks were the root cause of the re-organisations, as miners couldn’t propagate and verify these large blocks fast enough, before other blocks on different chains were found.
As for the implications this has on Bitcoin Cash SV, we have no comment. We will leave that to others.
HDR Global Trading, the owner of BitMEX, has partnered with Trading Technologies International, Inc. (TT), a global provider of high-performance professional trading software. Through the partnership, traders eligible to trade at BitMEX now have access to market-leading trading tools via TT on all BitMEX products, including the flagship XBTUSD Perpetual Swap.
Arthur Hayes, CEO of BitMEX, said: “Like Trading Technologies, BitMEX is committed to providing innovative financial products and a seamless experience for sophisticated traders. By combining our robust technologies, this partnership will not only extend BitMEX’s unique services to Trading Technologies’ discerning clients, but advance our mutual vision to unlock access to cutting-edge cryptocurrency products.”
“This collaboration with BitMEX brings our award-winning trading software to a much broader cryptocurrency market. We expect this partnership will grow trading volume on BitMEX, not only through our existing clients, who want access to cryptocurrencies, but also through new users keen to leverage professional trading software and enjoy better trading experiences,” said Rick Lane, CEO of Trading Technologies.
The TT platform provides professional traders with direct global market access and trade execution through TT’s privately managed infrastructure spanning five continents. Designed specifically for professional traders, brokers, and market-access providers, TT incorporates a broad array of customizable tools to accommodate trading styles that range from manual point-and-click trading to automated order entry.
About Trading Technologies
Trading Technologies (www.tradingtechnologies.com, @Trading_Tech) creates professional trading software, infrastructure and data solutions for a wide variety of users, including proprietary traders, brokers, money managers, CTAs, hedge funds, commercial hedgers and risk managers. In addition to providing access to the world’s major international exchanges and liquidity venues, TT offers domain-specific technology for cryptocurrency trading and machine-learning tools for real-time trade surveillance.
On 2 April 2019 between 04:44:34 UTC and 05:22:08 UTC, less than 200 positions were auto-deleveraged due to the sharp price movements of the underlying mark price on XBTU19 and ETHM19.
At the time of these auto-deleveraging events, the Insurance Fund allocated to these contracts was minimal. The Insurance Fund is allocated individually to each contract according to how many liquidations contribute to that specific contract (System Gains and Losses). In the case of expired contracts, BitMEX has a process in place to roll over the Insurance Fund allocated to these contracts into the next front month contract. With the recent expiry on the 29th March 2019, this process failed and front month contracts did not receive their reallocation, and the funds remained unallocated. As a result, a handful of users were auto-deleveraged upon large liquidations within these affected contracts.
BitMEX receives auto-deleveraging reports and was made aware of the unusually high rate of auto-deleveraging events, at which point we investigated the matter. We identified the root cause, corrected the allocation and put further controls in place to ensure that reallocation failures are automatically flagged internally.
For users that were affected, BitMEX will be reaching out to you personally to explain the situation and document your compensation. We compensated users based on the maximum potential profit that they would have made over the timeframe of these auto-deleveraging events. We exited these users at the best price of each contract: longs at 5,079.5 on XBTU19 and shorts at 0.03103 on ETHM19. BitMEX did not profit from these auto-deleveraged positions.
We apologise for any inconvenience this caused. Should you have any questions, please contact customer support.
On 29 March at 12:00 UTC, BitMEX experienced a minor outage for approximately 15 seconds whereby all requests would have been load shed as the engine was blocked during settlement operations. The platform was back to normal after the 15 second outage.
At 20:13 UTC, the BitMEX website experienced a limited interruption in service to a small group of users. The issue was immediately identified and fixed. The API was not affected.
We apologise for the inconvenience. Should you have any questions, please contact customer support.
