Email Privacy Issue: What Is Happening And How Can We Help

We understand many of you are concerned about the email disclosure which happened over this weekend and no doubt have many questions.

Our teams across the world have been working around the clock to protect your account security and make sure we are back on course. Our support team has already assisted many of our users and we are continuing to establish contact with everyone. This is a staggered process, to ensure that the proper processes are all followed, the delivery is logistically smooth and that all underlying security concerns are appropriately covered. If you have not yet heard from us already, you will do very soon.

We would like to apologise unreservedly for the concern this has caused. Below contains further information about what happened, how we can assist you and some steps that you can take to improve your protection.

What happened?

On Friday, November 1 at 06:00 UTC, many of our users received an email which contained the email addresses of other users in the “To:” field. This was a general email update to our users about upcoming changes to the weighting of our indices. As a result, many BitMEX user email addresses, including a large number of inactive addresses, were disclosed to other users in small batches. No other information was disclosed.

BitMEX is a global business that sends emails to many different email providers. Email deliverability itself is a multi-layered problem, involving decades of work in building sender reputation systems and automatic spam filters. Unfortunately, this makes the job of large services such as BitMEX difficult at times: we only send mass emails to all users on rare occasions. We intend to keep a high signal-to-noise ratio, and only send emails when absolutely necessary.

The index change we published on 1 Nov was of sufficient importance – it will impact pricing of all of our products – that we felt it necessary to inform all our users about it. However, bulk mail sends such as this are a difficult and complex undertaking when it’s on a global scale, to all recipients. Some mail servers, especially the global arms of large brands like Yahoo and 163, have very tight controls that are often triggered when we send large amounts of mail. For system notifications such as withdrawals, password resets, and liquidations, it is imperative that the customer receives mail dependably.

To remedy this, we built an in-house system to handle the necessary rendering, translation, staging, and piecemeal (as not to trigger rate limits) sending of important email. BitMEX has not sent an email to every customer at once since 2017, and much has changed since then. When we initiated the send, it became clear that it would take upwards of 10 hours to complete, and there was a desire on the team to ensure users received the same material information on a more reasonable timescale.

To handle this, the tool was quickly rewritten to send single SendGrid API calls in batches of 1,000 addresses. Unfortunately, due to the time constraints, this was not put through our normal QA process. It was not immediately understood that the API call would create a literal concatenated “To:” field, leaking customer email addresses. As soon as we became aware, we immediately prevented further emails from being sent and have addressed the root cause. Since then we have been aiding all who have been affected as best we can and mitigating the damage to contain the leak.

BitMEX is a company that takes engineering seriously, and we are disappointed that this lapse in care has resulted in unwanted disclosure for our customers. We believe that processes, not engineers, are to blame for these failures. Our processes failed here. We are working around-the-clock to revamp them and to ensure that even the simplest-looking code changes are put under strict review.

Additionally, and unrelated to this action, the BitMEX Twitter account was accessed by an external individual. The account was back under BitMEX control within 6 minutes and re-secured, and the event is under security review.

Beyond email addresses, no personal or account information has been disclosed. At no point were any of our core systems at risk.

Who was affected?

Most BitMEX users were affected by this action. You can self-diagnose your exposure with the following steps:

  • If you received an email about the index change, and your email was the only one listed in the “To:” field, you were not affected.
  • If you received the index change email, and you saw multiple addresses in the To: field, you were affected.
  • If you did not receive an index change email, you may have been affected and we still recommend that you follow steps below to improve your protection online. While the system was cut-off before it completed entirely, many recipients began marking BitMEX emails as spam, understandably out of hope that it would stop further emails. This caused deliverability issues at some hosts, causing mail not to be delivered. Unfortunately, someone else in your batch may have received the email, exposing your email address.
    • The deliverability issues caused by the spam reporting caused some follow-up password resets to be delayed for several hours. Our operation teams remedied this by 06:00 UTC on Nov 2.

What are we doing to help?

After the discovery of the disclosure, BitMEX employees have since worked through the nights and days to reduce risk for users. We are aware that many users reuse email addresses across services. This, combined with a very human tendency to reuse passwords, meant that many of our users may have been at risk due to password hash dumps on other platforms, even ones unrelated to crypto.

For this reason, we took the following steps after we notified our users of the disclosure:

  • Our Security and Support teams began enhanced monitoring of access patterns to flag accounts with suspicious activity after the disclosure. This led to several account password resets and human review with Support.
  • At 13:00 UTC on the day of the email, we conducted additional checks during our usual human review of withdrawals. We identified criteria that could be indicative of a compromise given the circumstances. We cancelled requests from accounts that (i) did not have two-factor authentication, (ii) were withdrawing to a previously unseen Bitcoin address, (iii) were submitted with previously unseen new IP address, and (iv) were made after the email address disclosure had occurred. All other withdrawal requests were unaffected. These actions were taken in the interest of protecting our users and those affected have already been contacted.
  • As it became clear that several groups were working to collate BitMEX email addresses in order to attempt to compromise them, BitMEX engineers forced a password reset for all users with balances and without Two-Factor devices. Affected users were notified via email (after a thorough QA review and retrospective on the original bug).
  • BitMEX Support (contact here) is working shifts with extra agents, continuing to handle customer requests to change email addresses, answer questions, and provide security assessment and advice.

If you are concerned about your personal exposure, on BitMEX or on any other platform, the best thing you can do is to enable Two-Factor Authentication on all critical services. Start with your email address first. We have  published advice on this topic, as have others, including this very helpful guide by Paul Stamatiou.

BitMEX engineering teams are working on new features to increase the number of security keys supported by the platform, to improve the signal of account notifications, and to give users more tools to avoid and contain account takeovers.

Do I need to do anything?

Although no-one’s personal information or account details beyond their email address were disclosed, as best practice, we recommend that you:

  • Please be vigilant against phishing attempts. Emails from BitMEX are sent from “” and “”. We recommend adding these addresses to your contacts list. We will never ask for your password.
  • Note that BitMEX will never ask you to transfer any funds. The only way to fund your BitMEX account is to send Bitcoin to your unique BitMEX deposit address. Your unique BitMEX deposit address will begin with “3BMEX” or “3BitMEX” and can be found on the deposit page of your BitMEX account.
  • Please take note of our official BitMEX communications channels. Only instructions provided via these avenues should be observed.
  • Protect your account by using strong and unique passwords; enabling Two-Factor Authentication (2FA) for all of your accounts (both BitMEX and personal); and to use a password manager.

We want to reassure you that beyond email addresses, no personal or account information has been disclosed. At no point during this issue were any of our systems at risk, and they remain secure, as we continue to take measures to enhance our security. Your privacy and security remain our top priority.

In the meantime, if you need any immediate assistance, please contact Support via our contact form.

Vivien Khoo,
Deputy Chief Operating Officer

Updated: Statement on the Email Privacy Issue Impacting Our Users

Earlier today, some of our users received an email which contained the email addresses of other users in the ‘to’ field. We apologise for the concern this communication may have caused. This was the result of a software error which has now been addressed.

BitMEX takes the privacy and security of our users very seriously. Rest assured that in this instance, beyond email addresses, no other personal data or account information have been disclosed and no further emails have been sent. The error which has caused this has been identified and fixed, ensuring our usual high standards of privacy are upheld.

We are continuing work to ensure this will not occur again in future, and will be introducing additional features to further protect our users. Further communications on this matter will be issued in due course.

In the meantime, please find below some immediate guidance which should be observed in order to ensure the continued safety of your account:

  1. Please be aware of phishing attempts. Emails from BitMEX are sent from “” and “”. Please add these email addresses to your contacts list to ensure that these emails do not land in your spam folder. BitMEX will never ask for your password.

  2. BitMEX will never ask you to transfer funds. The only way to fund your BitMEX account is to send bitcoin to your unique BitMEX deposit address. Your unique BitMEX deposit address will begin with “3BMEX” or “3BitMEX” and can be found on the deposit page of your BitMEX account.

  3. Please take note our official BitMEX communications channels. These are our primary, official social media communications channels and only instructions provided via these avenues should be observed.

  4. We would like to remind all of our users to please protect their accounts by using strong and unique passwords; enabling Two-Factor Authentication (2FA) for all of your accounts (both BitMEX and personal); and to use a password manager. Further advice can be found here.

We will continue to communicate updates on our blog. We take the security and privacy of our users very seriously and will take steps to ensure this does not occur again in future.

Statement on Email Privacy Issue Impacting Our Users

We are aware that some of our users have received a general user update email earlier today, which contained the email addresses of other users.

Our team have acted immediately to contain the issue and we are taking steps to understand the extent of the impact. Rest assured that we are doing everything we can to identify the root cause of the fault and we will be in touch with any users affected by the issue.

The privacy of our users is a top priority and we are very sorry for the concern this has caused to our users.

BitMEX Indices Update

On 22 November 2019 at 12:00:05 UTC, BitMEX will update its indices across all products to ensure that the reference prices our users trade against more closely reflect the market consensus price of underlying assets. This will allow you to trade against data which is better optimised for fairness, robustness and accuracy.    

We will achieve this by calculating index weights based on observed trading volumes across a broader set of index constituent exchanges. Volume data is obtained directly from each such exchange via API connection. This change could reduce the impact that movements on a single exchange that are contrary to the market consensus might have on your trading positions. Index calculations will continue to be transparent and easy to replicate.   


When the constituent of an index is updated, the related index price may change. This is why over the coming days we will be publishing BitMEX “NEXT”, a new family of indices that will run in parallel and reflect anticipated changes. BitMEX “NEXT” indices will not be used for valuation or settlement but by publishing them in advance, we hope to help our users better understand any differences before changes are applied to our indices during the 22 November 2019 switchover.

Please see below some Q&As on the upcoming changes.

How will the updated indices be more representative?

  • More exchanges: BitMEX is adding three new exchanges to its constituent universe to make a total of nine exchanges. This expanded set of exchanges will be reviewed periodically and updated in line with market developments. Through these additions, more data will be available to assist HDR Global Trading Limited (“HDR”), as the operator of BitMEX trading platform, in its determination of the true price of each relevant underlying asset, creating a more accurate and robust reference price for our users.
  • More constituents per index: Every constituent exchange is considered for inclusion in every index. This may lead to data from more constituent exchanges being used in an index resulting in increased price accuracy in relation to its underlying asset.
  • Weights based on observed trading volumes: Updated indices will reflect higher weights for exchanges with higher volumes. This approach will ensure that BitMEX index prices are more representative of the trade price per trade than per exchange.

How are the index prices calculated?

Each BitMEX index price is calculated as a weighted average of the Last Price for each constituent exchange. Index prices are calculated and published every 5 seconds.

How are the weights calculated? 

For each index, BitMEX observes the traded volumes of the underlying asset, obtained directly via API connection, across each exchange in the constituent universe. Proprietary mechanisms are used to identify malformed and anomalous data, which is discarded. The BitMEX index weights are computed using this volume data with the calculation removing constituents with insufficient trade volume.   

For the avoidance of doubt, and in accordance with BitMEX Terms of Service, HDR accepts no responsibility for the accuracy of any volume (or other) data received from any exchange and used to calculate the price of any BitMEX index and excludes all liability for any claimed losses arising in connection with its calculation and publication of any such index.

When are the weights updated?

Index weights will be updated on a quarterly basis. The initial index weights are shown in the table below. After this initial update, future index weights will be updated immediately after quarterly future expiries at 12:00:05 UTC. The updates to the weights will be announced three weeks in advance.

As of 22 November 2019 at 12:00:05 UTC, assuming no constituent exchanges have been excluded due to Index Protection Rules, BitMEX index weights will be:





























































How can I track the prices of the new indices?

BitMEX will introduce a new family of indices, the BitMEX “NEXT” indices. The purpose of BitMEX “NEXT” indices is to display, in advance, the hypothetical prices of BitMEX indices which include any new weights, allowing our traders to experience and better understand the potential impact of forthcoming index changes. BitMEX “NEXT” indices will be published on the BitMEX website and API.

The weights for BitMEX “NEXT” indices will be updated as soon as new BitMEX index weights are announced. On 22 November, once the weights are updated for BitMEX indices, the BitMEX indices prices will be the same as the BitMEX “NEXT” indices.

Please note that BitMEX “NEXT” indices are not used for valuation or settlement.

What can I expect when the index updates are switched on?

When the index weights are updated, index prices may experience small shifts. Experienced users will know that BitMEX is well equipped to handle large shifts thanks to our exchange protection mechanisms. We encourage you to monitor the differences between the current and future index prices using the BitMEX “NEXT” indices and factor possible shifts into your risk assessment.

Where can I find out more?

The BitMEX “NEXT” indices are available for your reference and include the index weights calculations. You can also read BitMEX “NEXT” specific documentation to further understand BitMEX indices.

If you have any further questions, please contact Support via our contact form.


Bitcoin Cash’s October 2019 Hashrate Volatility Increase

Abstract: We look at the recent elevated level of hashrate volatility on the Bitcoin Cash network. We note that the apparent cyclical nature of the oscillations may indicate a form of manipulation, although we found no direct evidence of such behavior. We conclude that there are no easy solutions to Bitcoin Cash’s hashrate volatility issue, on the other hand the negative impact on the usability of the coin has been marginal so far. The best course of action in the short term may be to be patient and research possible solutions, unless a particular cause becomes more apparent. 

Bitcoin Cash Hashrate Estimate- (8 hour rolling average) – PH/s

(Source: BitMEX Research)
(Notes: Eight hour periods were chosen to maximise the visual impact of the apparent hashrate oscillations. Hashrate data calculated by using the difficulty and block timestamps)

Bitcoin Cash Hashrate Volatility Concerns

Recently some have expressed concerns about the apparent unusually high level of volatility in the Bitcoin Cash hashrate, causing larger than expected variances in block times. As the above chart indicates, the volatility in hashrate appears to have picked up at around the start of October 2019. It is important to consider that we calculated the hashrate based on block times, which is a random and volatile process anyway, therefore determining if short term changes in the hashrate are random or caused by actual changes can be challenging. However, in our view the data is reasonably compelling. This volatility may have made the network marginally less reliable for payments in some periods, although its not a major issue, in our view.

For the month of October 2019 we conducted a basic analysis of Bitcoin Cash’s difficulty, block timestamps and the times in which our node received the Bitcoin Cash blocks.

As the below chart illustrates, Bitcoin Cash does indeed appear to have more volatile time gaps between blocks when compared to Bitcoin. 

Time interval between blocks – 50 block rolling average (Minutes) – October 2019

(Source: BitMEX Research)
(Notes: The x-axis is block heights for Bitcoin Cash, while Bitcoin is added for the same 29 days ending 29th October 2019

Not only does the Bitcoin Cash time gap between blocks appear more volatile than Bitcoin, with higher peaks and lower troughs, but it also appears to be slightly less random, with more regular peaks and troughs. There may be some form of cyclicality in the data, which might imply manipulation, although we found no direct evidence of this. On the other hand, the random nature of the data means that the chart may look cyclical, but it could be an illusion. Please note, the Bitcoin Cash difficulty is adjusted on a per block basis and therefore the adjustment algorithm should not cause such cyclicality. Please also note that a 50 block rolling period was chosen to maximize the size of the peaks and troughs, therefore the chart may exaggerate the issue slightly.

The Inconclusive Hunt For Evidence Of Causation

In the table below, we analysed the average difficulty of each block for each mining pool, by calculating the difficulty at each block height. We were trying to determine if one mining pool had been successful in some strategy aimed at achieving a lower average difficulty than its peers. The analysis was inconclusive and the unknown miner(s) achieved an average difficulty reasonably close to the total average. However, it is possible a more detailed analysis of the data could find something more interesting.

Bitcoin Cash – October 2019 Mining Pool Statistics

Mining pool

Number of Blocks Mined

Mining Share

Average Difficulty When Each Block Was Mined

Average Time Gap Between Timestamp & Our Local Clock (Minutes)













































(Source: BitMEX Research)

We also analysed the time gaps between the block timestamps and the time our local system clock says it received the block, again looking for discrepancies between pools for evidence of manipulation. Perhaps exploiting the potential 8.3% vulnerability we mentioned in yesterday’s piece. Again, no such direct evidence was found, with the unknown pool bang on the average, with the timestamp 0.48 minutes before our system clock.

The following charts continue to look at the timestamp gap to our local clock, and compare Bitcoin and Bitcoin Cash, in an attempt to visually identify any irregularities. What they appear to indicate is that Bitcoin timestamps are on average more consistent with our local clock and the time gaps are less volatile. This may merely suggest that Bitcoin has a stronger peer-to-peer network than Bitcoin Cash, with faster block propagation, rather than any nefarious manipulation of the timestamps.

Bitcoin Cash – Average Time Gap Between Timestamp & Our Local Node Clock (Minutes) – October 2019 – (Y-axis cut to compare with Bitcoin)

(Source: BitMEX Research)

(Notes: Orange line is 50 block moving average)

Bitcoin – Average Time Gap Between Timestamp & Our Local Node Clock (Minutes) – October 2019

(Source: BitMEX Research)

(Notes: Orange line is 50 block moving average. The x-axis is the month of October 2019)

We were unable to find any evidence of timestamp manipulation or other nefarious mining strategies. Bitcoin Cash is a minority hashrate coin and therefore this is likely to make the hashrate more volatile to some extent. Perhaps the apparent cyclicality is caused by lags in automated systems designed to mine the most profitable coins or some other more benign factor.


Fixing the potential problems with Bitcoin Cash’s hashrate volatility may require a hardfork and the coin is already scheduled to have a hardfork upgrade in a few days time, which does not include a fix for the above issue. Any fix is likely to require considerable development work and analysis/discussion before it is rolled out. Therefore a fix is unlikely in the short term. However, the issue may not be urgent.

As for how Bitcoin Cash may consider fixing the problem, we suggest consideration of the following proposals:

  1. Merged Mining – Enabling merge mining with Bitcoin, as we explained back in November 2017, could add stability to Bitcoin Cash mining, however some in the Bitcoin Cash the community may still be unwilling to adopt this due to the somewhat unfriendly attitude towards Bitcoin. In our view, this anger will dissipate over time.
  2. Adopt Bitcoin’s Two Week Adjustment Period – Bitcoin Cash could return to Bitcoin’s fixed two week window difficulty adjustment system. This is perhaps one of the more simple solutions, although it will not completely solve the problem.
  3. Reduce block times – Bitcoin Cash could re-enable the 1MB blocksize limit and reduce the block time to around 1 minute instead, although this may not fix hashrate volatility, due to the lower block time gaps, blocks would appear reasonably regularly anyway. This strategy more directly aligns with the Bitcoin Cash community’s objective of higher onchain throughput and improved usability without waiting so long for confirmations, than blocksize limit increases would, in our view.

As of now, the elevated hashrate volatility issue does not appear urgent and has only persisted for one month. The apparent sudden increase in volatility in October 2019 remains a mystery, at least to us. However, if this continues or a particular cause becomes apparent, in our view, a fix may be necessary. 

Bitcoin’s Block Timestamp Protection Rules

Abstract: We examine two of Bitcoin’s little-known rules, designed to stop nefarious miners from manipulating the block timestamps and achieving unfairly high mining rewards. We discuss why constants such as the two-hour MAX_FUTURE_BLOCK_TIME value may have been chosen and how this value may have particular implications for Bitcoin Cash. We conclude that Bitcoin’s time protection rules appear reasonably effective, an impressive feat, considering the lack of a functioning network when the rules were implemented. 

(Source: Pexels)

Bitcoin’s Time Problem

One might think that time is not an important consideration for the Bitcoin network, since the blocks already have a sequential order, as each block references the hash of the previous block. Bitcoin blocks also contain transactions (inputs, outputs and values), a Merkle tree leading to the block header and the block hash itself, used for proof of work. On the surface this may seem sufficient for a transaction and consensus system. However, there is the matter of the difficulty adjustment – if too many miners join the network, the block times could become too fast, or if too many miners leave, the block times could become too slow, making the network unreliable. To resolve this problem, every two weeks the mining difficulty adjusts to aim for a target time between blocks of ten minutes. Unfortunately, in order to calculate the two-week period, the concept of time needs to be introduced to the blockchain and be part of the consensus system. Therefore blocks are required to contain a timestamp, and one can think of Bitcoin as the world’s first distributed electronic clock.

Block Timestamp Security Rules

When a Bitcoin block is produced there are essentially two times involved:

  1. The timestamp in the block header, put there by the miner
  2. The actual time the block was produced.

Of course, these two times should be pretty much the same. After all, surely the miners have reasonably accurate clocks and why would they lie about the time?

As it happens, there are some incentives for miners to lie about the time. For instance, nefarious miners could add a timestamp which is in the future. For example, if a block took 10 minutes to produce, miners could claim it took them 15 minutes, by adding a timestamp 5 minutes into the future. If this pattern of adding 5 minutes is continued throughout a two week difficulty adjustment period, it would look like the average block time was 15 minutes, when in reality it was shorter than this. The difficulty could then adjust downwards in the next period, increasing mining revenue due to faster block times. Of course, the problem with this approach is that the Bitcoin clock continues to move further and further out of line with the real time.

To resolve or mitigate the above issue, Bitcoin has two mechanisms to protect against miners manipulating the timestamp:

  1. Median Past Time (MPT) Rule – The timestamp must be further forwards than the median of the last eleven blocks. The median of eleven blocks implies six blocks could be re-organised and time would still not move backwards, which one can argue is reasonably consistent with the example, provided in Meni Rosenfeld’s 2012 paper, that six confirmations are necessary to decrease the probability of success below 0.1%, for an attacker with 10% of the network hashrate.
  2. Future Block Time Rule – The timestamp cannot be more than 2 hours in the future based on the MAX_FUTURE_BLOCK_TIME constant, relative to the median time from the node’s peers. The maximum allowed gap between the time provided by the nodes and the local system clock is 90 minutes, another safeguard. It should be noted that unlike the MPT rule above, this is not a full consensus rule. Blocks with a timestamp too far in the future are not invalid, they can become valid as time moves forwards.

Rule number one ensures that the blockchain continues to move forwards in time and rule number two ensures that the chain does not move too far forwards. These time protection rules are not perfect, for example miners could still move the timestamps forward by producing timestamps in the future, within a two week period, however the impact of this would be limited.

As the above ratio illustrates, since two hours is only a small fraction of two weeks, the impact this manipulation has on network reliability and mining profitability may be limited. This is the equivalent of a reduction in the time between blocks from 10 minutes to 9 minutes and 54 seconds, in the two weeks after the difficulty adjustment. In addition to this, it is only a one-off change, as once the two-hour time shift has occurred, it cannot occur again, without first going backwards. At the same time, the miner may want to include a margin of safety before shifting forwards two hours, to reduce the risk of the block being rejected by the network.

These rules have proven reasonably effective in preventing miners from manipulating Bitcoin’s timestamps in nefarious ways, as far as we can tell.

Bitcoin Cash’s Theoretical Block Time Problems

As we first mentioned back in September 2017, Bitcoin Cash is an alternative coin which split off from Bitcoin in August 2017, the primary objective of the coin was to increase the blocksize limit. One of the concerns the Bitcoin Cash developers had at the time was that not many miners would mine Bitcoin Cash, and therefore the time gap between blocks could be too large. As a result something called the Emergency Difficulty Adjustment (EDA) was implemented to alleviate this concern. We will not go into the details here, but suffice to say this mechanism was highly complex and turned out to be fundamentally flawed. This algorithm meant that if a certain number of blocks were not found within a certain time period, the difficulty would reduce. The policy was particularly aggressive, as it meant that the longer the time gaps between blocks, the larger the downward difficulty adjustment. Miners manipulated the network by leaving large time gaps on purpose, resulting in large difficulty changes, followed by low-difficulty periods with blocks being produced at a very high frequency. The network then became unreliable.

As a result of this flaw, more Bitcoin Cash blocks were produced than expected and miner revenue increased during this period. Bitcoin Cash built a c.5,000 block lead over Bitcoin, a lead it still maintains to this day. A couple of months later, in November 2017, a fix was eventually rolled out. The EDA was removed and replaced with a new difficulty adjustment system, a more simple rolling 24-hour system. However, this is still different to Bitcoin’s two-week window system. Bitcoin Cash’s system is more dynamic and faster to adjust. While this means Bitcoin Cash may have a more volatile difficulty in the short term, the coin is faster to adjust to any changes, while any block time discrepancies in Bitcoin may take longer to correct.

Overview of Bitcoin and Bitcoin Cash’s Difficulty Adjustment Systems


Calculation period

Difficulty Adjustment



2 weeks

Every 2 weeks

  • Less likely to suffer from block time discrepancies
  • Any discrepancies take longer to resolve

Bitcoin Cash

1 day

Each block

  • More likely to suffer from block time discrepancies
  • Any discrepancies are resolved faster

(Source: BitMEX Research)

One thing that many may have overlooked in Bitcoin Cash’s new difficulty adjustment algorithm is its interrelationship with the two-hour time protection rule. As far as we are aware, Bitcoin Cash has retained the 2 hour constant.

A two-hour period is now 8.3% of the calculation period. This is the equivalent of a reduction in the time between blocks from 10 minutes to 9 minutes and 10 seconds. This does appear to be potentially significant and could result in changes to miner profitability, if exploited. Bitcoin Cash may therefore be somewhat vulnerable to miners manipulating timestamps, or at least more vulnerable than Bitcoin.

On the other hand, although Bitcoin Cash may be more vulnerable to miner timestamp manipulation attacks than Bitcoin, any issues will be resolved faster. 


The apparent vulnerability with Bitcoin Cash’s time protection rule, perhaps unexploited, illustrates how well thought out Bitcoin’s time protection rules were. As far as we know, these time protection rules existed since Bitcoin launched in 2009. When designing the system, Satoshi had to innovate at least three layers deep:

Proof of work system → Difficulty adjustment system → Robust time protection rules

While this may not seem especially ingenious to us now, we have had almost 11 years’ experience with such systems. That Satoshi had thought all this through before any such network existed is quite remarkable, in our view.

ForkMonitor: Unexpected Inflation Detection and Warning System

Abstract: ForkMonitor has now implemented unexpected inflation detection and warning systems for Bitcoin. The block reward is currently 12.5 bitcoin, which means that no more than 12.5 new bitcoin should be created each block. Some of the ForkMonitor nodes now calculate the total coin supply each block, using the gettxoutsetinfo RPC call. If the total coin supply increases by more than 12.5 bitcoin, warnings systems are initiated. This service potentially provides additional assurances to network participants about the supply of Bitcoin at any given time.



ForkMonitor has recently added a new feature, unexpected inflation detection. This feature has been added for Bitcoin and Testnet Bitcoin. The system periodically checks the total coin supply by summing up all the UTXO values. If the value is unexpectedly large, warnings are activated. Bitcoin nodes are already supposed to check the coin supply, however this occurs by only checking that no unauthorised coins are created in each individual transaction and there is no macro total supply check. Therefore the ForkMonitor service could provide an additional layer of security and assurance for Bitcoin users, as well as an early warning system which could encourage people to run these checks on their own nodes if an issue is detected.

If the inflation is in line with expectations, a green tick is displayed on the website. However, if unexpected inflation occurs, a red cross is displayed alongside other warnings.

Illustration of unexpected inflation detected by Bitcoin Core 0.18.1


Please subscribe to the feeds, to be altered in the event of unexpected Bitcoin inflation.

Coin Supply Checking Mechanisms

The systems plan to check the inflation using the following methods:

  • Coin supply change from the previous block –  After each Bitcoin block is produced, the system checks the total coin supply and stores the figure in a database. As each new block is produced, the summation is repeated and the total coin supply is subtracted from the previous figure. If the change is higher than the allowed block reward (12.5 bitcoins today, 6.25 bitcoins from around May 2020, etc.), then the warnings are initiated.
  • Consistency across multiple node versions In addition, the system will also check that the total bitcoin supply is consistent at each block height for all the nodes participating in the inflation check (which is illustrated on the ForkMonitor website).

Gettxoutsetinfo Issues

One of the main challenges we faced when implementing this inflation check feature was that it took considerable time for Bitcoin Core to run the gettxoutsetinfo call, typically around 2 minutes. This created several implementation challenges for ForkMonitor, such as what to display in this two minute period or what happens when a block is found while the calculation is occurring. For example, the maximum rate at which the inflation check can move forwards is one block every two minutes; if many blocks are found in a row, with smaller than two minute intervals between them, our check can be ineffective for a while.

Gettxoutsetinfo RPC call – Bitcoin’s supply of approximately 18 million is illustrated

 (Source: Output from Bitcoin Core 0.18.0 “Gettxoutsetinfo” call)

Others are aware of these issues, as Bitcoin developer Fabian Jahr recently put it:

[The gettxoutsetinfo call] does not have a sufficient user experience, you call it and it actually takes several minutes to respond and there is no feedback

 (Source: Fabian Jahr (Youtube))

In 2017 Bitcoin developer Pieter Wuille posted to the Bitcoin development mailing list, a potential improvement, which he says could make this Remote Procedure Call (RPC) call faster.

Replacement for Bitcoin Core’s gettxoutsetinfo RPC’s hash computation. This currently requires minutes of I/O and CPU, as it serializes and hashes the entire UTXO set. A rolling set hash would make this instant, making the whole RPC much more usable for sanity checking

 (Source: Pieter Wuille’s 2017 Rolling UTXO set hash email)

Based on the above idea, Fabian recently indicated he may work on implementing this potential fix, in an attempt to improve this RPC call. If this improvement is implemented, it would certainly be helpful for ForkMonitor.

Bitcoin’s 2018 Inflation Bug (CVE-2018-17144)

ForkMonitor was very much inspired by the events of September 2018, when it emerged that Bitcoin Core had a bug which would enable miners to create coins out of nowhere in addition to the normal block reward. This bug affected versions of Bitcoin Core spanning from 0.14.0 to 0.16.2, before the fixes were released. (0.14.X nodes merely crashed while later nodes would have accepted the blocks with the unexpected inflation).

A successful exploitation of this bug could have had catastrophic consequences for the network, for example Bitcoin’s supply could have inflated above 21 million or a large rollback may have occurred, undermining the security many users and businesses depend on.

ForkMonitor was launched to mitigate these risks. If such a bug existed today, our systems should be able to detect it in three ways:

  • ForkMonitor runs multiple versions of Bitcoin Core, spanning many years of development. If a newly-introduced bug results in unexpected inflation or an unauthorized spend, the older nodes should detect this and mark the block as invalid, triggering the warning systems.
  • The website also runs independent implementations of Bitcoin, such as bcoin, btcd and Libbitcoin. If Bitcoin Core has a bug which allows unexpected inflation or an unauthorized spend, as long as the same bug wasn’t independently implemented, these other clients should mark the block as invalid, triggering the warning systems.
  • As of October 2019, ForkMonitor also directly checks the total coin supply of each block. In the event of unexpected inflation, even in the unlikely scenario that all our nodes mark the block as valid, the warning systems will still be triggered. The inflation checking system is also helpful even if nodes do mark the block as invalid, as it can help users determine why this was the case in a timely manner.

Independent Implementations

As we explained in our October 2018 piece, Competing with Bitcoin Core, there are advantages and disadvantages of competing implementations and in particular independent implementations. One key advantage of independent implementations that we mentioned is that there could be a bug in Bitcoin Core or the reference implementation which is not present in the independent implementations.

For the above reason, we are keen to add one of the three independent implementations (bcoin, btcd and Libbitcoin) into the total coin supply inflation checking system as soon as possible. The method of calculating total coin supply used by these implementations may be independent from that used by Bitcoin Core, which should provide extra reassurance that the number is correct.


This new service may not solve all potential problems with regards to detecting unexpected inflation. For example there could be a bug in the gettxoutsetinfo check. In addition to this, the various mechanisms to check for unexpected inflation and block validity may not be truly independent from each other. Even the independent Bitcoin implementations may have inadvertently copied a bug or erroneous concept from Bitcoin Core. However, we believe this macro inflation checking service is potentially a useful addition to network security.

As a reminder, the ForkMonitor website is open source, therefore please feel free to contribute, fork the project or reproduce the website.

HDR Global Trading Limited Hires Derek Gobel as General Counsel

As a growing company we are always looking to bring on exciting new talent. It is our mission to be as successful and relevant in decades to come, as we are today. To do this, we recognise we need the right people, resources and capabilities to help us stay ahead of the market and continue to provide the best experience for our traders.  

This is why we are thrilled to announce that HDR Global Trading Limited has appointed Derek Gobel as our group’s General Counsel. He will oversee the group’s legal function and help us move forward in today’s continually evolving regulatory environment.

Derek brings with him 28 years of experience working on a wide range of legal matters, including his most recent role as BNP Paribas’ General Counsel for APAC. Recognised in the 2017 Legal 500’s GC Powerlist in China and Hong Kong, we look forward to having him on board.

Q4 2019 Quarterly Futures Listings & TRX Index Rename

On 13 September 2019 at 08:30 UTC, BitMEX will list new quarterly futures.

Please see the following tables for listings and settlements for current and upcoming futures contracts for Q4 2019. Bolded rows are the new contracts.

The .TRXXBT index will retire on 27 September 2019. It will be replaced by the .BTRXXBT Index. TRXU19 will reference .TRXXBT until its Settlement Date, TRXZ19 will reference .BTRXXBT from its Listing Date. 

Code Pair Listing Settlement
ADAU19 Cardano / Bitcoin 14 June 2019 27 Sept 2019
ADAZ19 Cardano / Bitcoin 13 Sept 2019 27 Dec 2019
BCHU19 Bitcoin Cash / Bitcoin 14 June 2019 27 Sept 2019
BCHZ19 Bitcoin Cash / Bitcoin 13 Sept 2019 27 Dec 2019
EOSU19 EOS Token / Bitcoin 14 June 2019 27 Sept 2019
EOSZ19 EOS Token / Bitcoin 13 Sept 2019 27 Dec 2019
ETHU19 Ether / Bitcoin 14 June 2019 27 Sept 2019
ETHZ19 Ether / Bitcoin 13 Sept 2019 27 Dec 2019
LTCU19 Litecoin / Bitcoin 14 June 2019 27 Sept 2019
LTCZ19 Litecoin / Bitcoin 13 Sept 2019 27 Dec 2019
TRXU19 Tron / Bitcoin 14 June 2019 27 Sept 2019
TRXZ19 Tron / Bitcoin 13 Sept 2019 27 Dec 2019
XRPU19 Ripple Token (XRP) / Bitcoin 14 June 2019 27 Sept 2019
XRPZ19 Ripple Token (XRP) / Bitcoin 13 Sept 2019 27 Dec 2019
XBTU19 Bitcoin / USD 15 Mar 2019 27 Sept  2019
XBTZ19 Bitcoin / USD 14 June 2019 27 Dec  2019
XBTH20 Bitcoin / USD 13 Sept 2019 27 Mar 2020

The Bitcoin Foundation

Abstract: In this piece we look back at the history of Bitcoin, focusing in on “The Bitcoin Foundation”, once one of the most prominent organisations in the ecosystem. We look at Foundation’s origins and then examine its failings with respect to its governance, transparency and finances, which ultimately led to a total loss of legitimacy within the Bitcoin community. We conclude that an all-encompassing Foundation was never likely to have been a good idea given the high governance and transparency standards of some in the community, and that a constant stream of scandals damaged the Foundation’s brand to such an extent that its duties had to be carried out by other organisations.

(Screenshot of the Bitcoin Foundation’s website and logo in 2013)

The Foundation’s Origins

Following on from our July 2018 piece, which took us back to shenanigans and incompetence at MtGox in 2011, this second look at Bitcoin’s scandal-rich history takes us back to July 2012, when The Bitcoin Foundation was founded. The Foundation had seven founding members, or six if you exclude Satoshi, who was oddly included as a founding member.

Bitcoin Foundation Founding Members

  • Gavin Andresen, Bitcoin Developer
  • Peter Vessenes, CEO of CoinLab
  • Charles Shrem, CEO of BitInstant
  • Roger Ver, CEO of MemoryDealers
  • Patrick Murck, Principal at Engage Legal
  • Mark Karpeles, CEO of
  • Satoshi Nakamoto, author of the white paper “Bitcoin: A Peer-to-Peer Electronic Cash System”

(Source: GitHub) 

The objective of the Foundation was never completely clear, with the original bylaws stating the following:

The Corporation shall promote and protect both the decentralized, distributed and private nature of the Bitcoin distributed-digital currency and transaction system as well as individual choice, participation and financial privacy when using such systems. The Corporation shall further require that any distributed-digital currency falling within the ambit of the Corporation’s purpose be decentralized, distributed and private and that it support individual choice, participation and financial privacy.

(Source: GitHub) 

The Foundation’s Mission – June 2013

(Source: The Bitcoin Foundation)

In practise the role of the Foundation appeared to be as follows:

  • To pay the salary of Bitcoin developer Gavin Andresen
  • To arrange Bitcoin conferences
  • To promote Bitcoin to regulators

During 2012 and 2013 the Foundation gained in popularity, attracting members from across the Bitcoin community, including prominent developers, businesses and community members.

Public list of individual lifetime members

(Source: Bitcoin Foundation

Corporate members as at September 2013

(Source: Bitcoin Foundation

The Foundation was funded by membership fees – the initial membership fee schedule is provided below. However, the Bitcoin-denominated prices did start to decline in 2013 as the Bitcoin price appreciated.

Initial Membership Fee Schedule

(Source: GitHub)

It was believed by many that due to the membership subscription fees, the Foundation had considerable financial resources to spend on its mission.

Approximate lower bound of member contributions in April 2013 (Assuming initial fee rates)

  • 2 Platinum Industry Members * 10,000 BTC = 20,000 BTC
  • 7 Silver Industry Members * 500BTC = 3,500 BTC
  • 175 Lifetime Members * 25BTC = 4,375 BTC
  • Total Resources = 27,873 BTC

(Source: BitMEX Research)

As we see later on in this report, the Foundation only had around 8,000 BTC at the end of 2012, still a nice warchest, but a lower balance than many had expected. It is possible our estimate above could be an overestimate, as the timing of member subscriptions is unclear.

The Foundation Board

The governance structure of the Foundation was quite complex and arcane. There were three classes of members: 

  1. Founders
  2. Individuals
  3. Corporates 

The board initially consisted of five members, one nominated by the founders, two nominated by individuals and two nominated by corporate members. The term of each appointee was expected to be 3 years. At the start of the Foundation, all five board members were appointed by the founders and all board members were founders, with the exception of Jon Matonis.

Bitcoin Foundation Board Members (2012 to 2019)

(Source: Bitcoin Foundation Website, BitMEX Research)

Critics can point to the fact that the governance structure gave too much power to the initial founders and that new members of the organisation should have been able to join as equals to the founders.

Board Elections

The first board elections took place in 2013, with Meyer Malka winning the Industry seat and Elizabeth Ploshay winning the vote amongst individual members.

Board Election – Industry Seat (2013) – Winners: Meyer Malka

(Source: Bitcoin Foundation)

Board Election – Individual Seat (2013) – Winner: Elizabeth Ploshay

(Source: Bitcoin Foundation)

At the start of 2014, the holders of the two founding industry seats resigned. Charles Shrem resigned on 28 January 2014, two days after his arrest at JFK airport for money laundering and unlicensed money transmitter related offences. Charlie was eventually convicted and sentenced to two years in prison in December 2014. The main substance of Mr Shrem’s felony appears to be that he continued to provide customer support to a user of his BitInstant Bitcoin purchasing service, despite him allegedly knowing the customer wanted Bitcoin for the purposes of purchasing illegal drugs on the Silk Road e-commerce platform (Or that the customer wanted to supply the Bitcoin to somebody else, who wanted to purchase illegal drugs, one extra layer removed). Mark Karpeles, the holder of the other industry seat, resigned on 24 February 2014, following the failure and insolvency of the MtGox Bitcoin exchange, where Mark was CEO.

Brock Pierce and Bobby Lee were then elected as the two replacement industry appointed board members.

Board Election – Industry Seats (2014) – Winners: Bobby Lee & Brock Pierce

(Source: Bitcoin Foundation)

The appointment of Brock Pierce to the board proved controversial, with some claiming the Foundation should have done more vetting before allowing Mr Pierce to stand. The allegation against the former child actor, who featured in the “Mighty Ducks” and Disney’s “First Kid” was related to his alleged involvement in the sexual exploitation of children in the late 1990s. Although only a teenager at the time, Mr Pierce was an executive and co-founder at the internet video startup, Digital Entertainment Network (DEN), which was accused of hosting several parties where sexual abuse may have taken place. The allegations resulted in co-founder and CEO Marc Collins-Rector, along with Mr Pierce, resigning from DEN and supposedly fleeing to Spain.  Mr Collins-Rector eventually plead guilty to child abuse related offences and according to Reuters, court record show that Mr Pierce paid US$21,000 to settle a related civil suit, while other claims were dropped, the article also states that Mr Pierce denies the allegations.

Towards the end of 2014, in the face of considerable pressure, the Foundation made the following improvements to its governance:

  • Board member terms were reduced to 2 from 3 years
  • The founder board seat was eliminated
  • The founder member class was removed

The Foundation’s Finances

The below table provides a basic analysis of the Foundation’s finances, in the period where most of the member dues were depleted (2012 to 2014). The data is based on the organisation’s IRS990 forms. With respect to the pay of the board, the disclosure seems reasonably strong. Most board members received no remuneration other than those acting as executives. Paying Gavin was one of the main aims of the organisation and Gavin’s pay appears to be disclosed in a reasonably clear and appropriate manner.

  2012 2013 2014
Directors pay      
Gavin Andresen $15,000 $209,648 $147,917
Patrick Murck   $57,592 $115,001
Lindsay Holland   $160,652  
Jodie Brady     $141,667
Jon Matonis (Contractor)   $31,250 $137,500
Other pay costs $14,013 $118,047 $582,782
Total pay costs $29,013 $577,189 $1,124,867
Conference costs   $418,413 $825,525
Other costs $32,608 $472,302 $1,335,210
Total costs $61,621 $1,467,904 $3,285,602
Foundation Revenue      
Membership fees   $358,007 $335,723
Conference revenue   $377,883 $584,308
Other   $64,803 $35,728
Total revenue $159,359 $800,693 $955,759
Surplus/(Deficit) $97,738 ($667,211) ($2,329,843)
Disclosed Bitcoin figures      
Bitcoin (US$ value at year end) $107,549 $4,512,316 $703,843
BTC sales proceeds   $749,157 $569,728
Realised Bitcoin gains/(losses)   $77,148 ($40,316)
Unrealised Bitcoin gains/(losses)   $5,195,589 ($1,966,768)

(Source: IRS 990 Forms, BitMEX Research)

The main criticisms related to the Foundation’s finances at the time appear twofold:

  1. There was a sharp increase in spend in 2014, depleting the organisation’s reserves to near zero
  2. There was a lack of transparency with regards to the Foundation’s Bitcoin balance

As for the first criticism, concerns did seem somewhat justified. In 2014 pay costs increased by 81%, the 2014 conference made a significant net loss and other costs increased significantly. As for the $1.3m in other costs, we have provided a breakdown below, therefore readers can judge the extent of the excesses. Compared to the excesses of the ICO bubble in 2017/18, where the total sum of the costs below perhaps represent a fraction of just one marketing party for the most egregious ICOs, the spend is moderate. However, some Foundation members clearly expected their funds to be spent more prudently. The main issue appears to be that expectations were not clearly set out in advance. Whatever your view, the fact is that by the start of 2015, the Foundation had almost run out of financial reserves and to that extent, its finances were mismanaged.

2014 breakdown of other spend

Other professional services $307,767
Legal fees $200,003
Travel $159,166
Information technology $158,021
Professional event expenses $115,401
Public relations $93,241
Exchange loss $73,362
Accounting $50,556
Office costs $39,071
Grants (Foreign) $37,314
Bad debts $18,500
Payments to affiliates $18,002
Occupancy $17,949
Grants $14,000
Advertising $9,218
Insurance $3,639
Other $20,000
Total other spend $1,335,210

(Source: Bitcoin Foundation IRS 990 form)

The lack of transparency with respect to the Foundation’s Bitcoin balance is another area of concern. At the end of each year the IRS990 form disclosed the USD value of the Bitcoin holding, the realised Bitcoin gains and the unrealised Bitcoin gains. Based on this information we calculated the following:

BitMEX Research BTC calculations 2012 2013 2014
Bitcoin price at year end $13 $754 $320
Implied BTC balance at year end 8,216 5,985 1,381
Change in BTC balance   (2,232) (4,604)
Implied sales price   $336 $124
Realised Bitcoin gains/(losses)   $719,945 ($2,901,314)
Unrealised BTC gains/(losses)   $4,433,979 ($599,354)
Lowest Bitcoin price figures      
Lowest Bitcoin price in the year $4 $13 $268
Implied BTC sales proceeds   $29,011 $1,233,739
Realised Bitcoin gains/(losses)   ($201) ($2,237,303)

(Source: IRS 990 Forms, BitMEX Research)

The disclosures in the IRS990 forms lead us to the following apparent Bitcoin related discrepancies:

  • The Foundations closing bitcoin balance in 2012 seems reasonably low given the volume of Bitcoin donations (See the c.28,000 BTC figure earlier in this report)
  • The Foundation disclosed an unrealised Bitcoin gain in 2013 of $5.2m, however based on the annual price movement and the calculated year end balance, we calculated an unrealised gain of only $4.4m
  • The Foundation disclosed an unrealised Bitcoin loss in 2014 of $2.0m, however based on the annual price movement and the calculated year end balance, we calculated an unrealised loss of only $0.6m
  • The Foundation disclosed Bitcoin sales proceeds of $569,728 in 2014, while even assuming all Bitcoin were sold at the lowest traded price in the year, given the large reduction in the Bitcoin balance of 4,600 coins, sales proceeds should have been $1.2m

Although there were accusations of embezzlement, we do not consider these disclosures to indicate any such crime. The Foundation was probably receiving Bitcoin and spending Bitcoin throughout the period, therefore clear financial record of Bitcoin sales are not likely to be available. At the same time, rules related to the reporting of realised and unrealised gains with respect to financial assets are not strict for this type of organisation and the Foundation does have a degree of discretion with respect to the calculation methodology. Therefore, the filings themselves do not indicate wrongdoing in our view. However, what we can say is that filings do not clearly explain what happened to the Bitcoin balance and an explanation from the board could be helpful.

Some members clearly expected greater transparency and wanted to question the board about the funds, but they were never given such an opportunity. The following quote from Bitcoin commentator Andreas Antonpoulous (who at the time was a Foundation committee chairman), reflected the views of many in the community at the time.

You say they are funded. Where are those funds? Who controls those funds? When were the last audited? Are they actually solvent? Or have all of those funds disappeared into a big black hole? Just remember who was in the leadership until recently, who is in the leadership today and what their track record of ethics has been and I would suggest that I would not be surprised at all if the Foundation implodes in a giant embezzlement problem sometime down the line or funds get stolen, within quotes or without quotes, or something like that. It’s bound to happen because these things don’t happen due to technical failures of bad actors, they happen due to failures of leadership The Foundation is the very definition of a failure of leadership.

(Source: Andreas Antonopoulos – March 2014 – Let’s Talk Bitcoin Episode 95)

Entanglement in the MtGox Scandal

To make matters worse, there were also accusations of the Foundation’s entanglement in the MtGox insolvency:

  • The MtGoX CEO, Mark Karpeles, was a founder and founding board member of the Foundation, while the company itself was a platinum member of the Foundation
  • Founding member, Roger Ver, famously assured MtGox customers of the solvency of the platform shortly before the exchange failed
  • The Foundation’s founding chairman, Peter Vessenes (who may have believed he was entitled to some MtGox equity), has been involved in various legal disputes with MtGox dating back to 2013 as a result of a failed business partnership. Peter’s company Coinlab sued MtGox for US$75m in 2013. As of August 2019, Peter now claims a remarkable total of US$16bn (Y1.6 trillion) from MtGox, an amount large enough to effectively block distributions to MtGox clients, and a large source of frustration to creditors to this day.

Andreas compared the Foundation’s situation to MtGox as follows:

Its problems go directly back to a complete failure of leadership. A completely closed, insular, arrogant, sheltered, uncommunicative leadership. Part of which was Karpeles himself, but there are another couple of relics left on that board, who pursue the exact same approach with their leadership. The Foundation is the Gox of Foundations. I am surprised it didn’t blow up in the wake of the Gox scandal, because there were a lot of significant conflicts within that environment.

However, perhaps it is unfair to make much of the association between MtGox and the Foundation, afterall, the ecosystem was small and MtGox was the dominant exchange, therefore a degree of association was inevitable to some extent.

The Amsterdam Conference (May 2014)

In May 2014 the Bitcoin Foundation arranged what was, up until this point, the largest conference in the space. It was the first conference (at least one which we attended), with characteristics familiar to many in the 2017/18 era. Unabated enthusiasm, unrealistic expectations about the underlying technology, expensive catering and countless booths representing new businesses with plans that appeared to make little commercial sense. As the figures above indicate, despite the expensive ticket prices of up to $800, the conference appears to have generated a net loss of around US$250,000.

The conference was split into two sections, a commercial section in the main exhibition hall, and the Bitcoin Foundation annual meeting (or technical track), which was down the hallway in a hotel conference room, entry to which was free for Foundation members. The technical discussions were followed by the Foundation members’ meeting

(Source: Eventbrite

Journalist Ryan Selkis (now founder & CEO of Messari), was one of the key lifetime members at the event trying to hold the Foundation to account. At the annual meeting he asked several challenging questions to the Foundation board members, asking for greater transparency. Up until this point much of the debate and complaints had taken place on online web forums and this real world interaction marked a significant and novel change. In response to his challenges, one board member said the following:

We can spend a lot of our time trying to be transparent as much as we can and higher resources can be transparent or we can spend a lot of time in the board level making sure that we [have the] resources to make bitcoin bigger. It’s possible but right now, honestly, we’re in an environment where bitcoin is not well perceived. You asked for priorities at least from my side as a board member, it’s more about [making bitcoin bigger]

(Source: Bitcoin Foundation 2014 Annual Meeting)

It was clear from this response that, for whatever reason, some board members had chosen not to tackle the transparency and governance concerns, leaving some members feeling frustrated and more convinced of wrongdoing on the part of the board. 

The Blockchain Election (February 2015)

Given the issues that the Foundation had faced and the concerns in the community about transparency, governance and the purpose of the Foundation, this was a relatively important set of elections. There was a large number of candidates and a reasonably good quality debate among the candidates, for example a dedicated Let’s Talk Bitcoin podcast on the election. 

The Foundation decided to conduct the 2015 individual board seat elections on the blockchain. As the chair of the election committee, Brain Goss said: 

I believe in the concept of using the block chain for storage of compact proofs/hashes (as the market dictates), and I’m a big believer in transparent voting that any one can verify

(Source: Bitcoin Foundation Forum)

However, the blockchain voting process did not run smoothly and the following issues arose:

  • The first round of voting took place using the Helios voting system. However, no candidate achieved more than 50% of the vote, as required by the by-laws, therefore a second round was required. The Foundation then made the odd decision to switch the voting platform to Swarm between the voting rounds, a decision met with widespread opposition. Despite initially starting the final round voting process on Swarm, during voting the Foundation then decided to switch back to Helios, invalidating the Swarm votes
  • The decision to reduce the number of candidates to four after the first round of voting appeared arbitrary 
  • Registering to vote was widely regarded as a cumbersome and complex process and some candidates complained

(Source: Email received as part of the Swarm voting process)

Board Election – Individual Seats First Round (2015)

(Source: Helios voting system records)

Board Election – Individual Seats Final Round (2015) – Winners: Oliver Janssens & Jim Harper

(Source: Bitcoin Foundation)

After the voting controversy, Patrick Murk told Bitcoin Magazine:

This clearly struck a nerve with folks that think blockchain technology should only be used for transferring Bitcoin and not other [applications] like voting. [It] sparked a debate on how people use the blockchain

(Source: Bitcoin Magazine)

Removal of Directors & The End Of Board Elections (December 2015)

In December 2015, the two newly elected board members, Oliver and Jim, were removed by the other board members, due to a disagreement over the best way forward for the Foundation. Oliver and Jim had recently succeeded in competitive elections from individual members, giving them a considerable democratic mandate. At the same time the two year election terms of Elizabeth and Meyer had already expired, while Brock and Bobby had been elected by the industry and not individuals. Therefore, from the point of view of the individual members, Oliver and Jim were the only two board members with a significant mandate and they had been removed. In a violation of the by-laws, the Foundation then decided not to conduct any further board elections. As the executive director Bruce Fenton put it:

I used to believe that public, open elections were a great thing.  I’m not as convinced now…. We unfortunately don’t have the time or resources for more process. 

(Source: Bitcoin Foundation forum)

In our view, this logic seemed difficult to justify, given many of the problems were caused by the boards apparent lack of accountability to individual members, with Elizabeth Ploshey being the only board member elected by individual members who served on the board for any meaningful amount of time. If the Foundation did want to revive itself, it could have reinstated Oliver and Jim and allowed further elections to replace the other board members who could have left. Instead, the Foundation decided to distance itself even further from members, avoiding the challenges this accountability would have imposed, and consequently the Foundation appeared to lose any remaining legitimacy it had left.

After this point, between 2015 and 2019, four new board members were appointed from the pool of candidates that were defeated in the previous elections, except this time appointments were made by the board rather than members.


The Foundation still exists today, with Brock as Chairman and Bobby as Vice chairman, although their elected terms have long since expired and no more elections are in sight. The Foundation has no significant financial resources and is largely irrelevant. The activities the Foundation used to conduct are now carried out by others, for example Coin Centre does some regulator lobbying, and Bitcoin development is funded by other organisations such as Chaincode Labs, Blockstream, MIT’s DCI and other industry players. In many ways the conclusion to this piece writes itself. Bitcoin never needed a Foundation, it is stronger without one, and any all-encompassing Foundation like this was always doomed to fail.

The outrage at the lack of transparency at the Foundation exposes some of the key divergences in expectations and culture between members of the Bitcoin (now cryptocurrency) community. Some Bitcoiners, especially those involved since the early days of the Foundation, were often highly conspiratorial, paranoid and expected radically high levels of transparency, accountability and financial prudence. The Foundation seems to have misjudged these expectations, lost the backing of the community and ultimately failed. However, compared to the excesses of the coin offering era, which picked up from around 2014 onwards, peaking at the start of 2018, the financial accountability and transparency of the Bitcoin Foundation was almost impeccable, relatively speaking. Some members of the cryptocurrency community (not all newer ones), had radically different expectations, focusing more on what they perceived as game-changing technology, changing the world and getting super rich, rather than governance. Even in this new climate, irreparable damage to the Foundation’s brand had been done and it never again found its place.

UPDATE – 23 September 2019

After the publication of this piece, several prominent Bitcoin developers, whose names were displayed on the Foundation’s website, indicated to us (in some cases with proof) that they were given membership status for free (rather than by paying 25BTC). This may indicate that:

  1. Support for the foundation may not have been as widespread as we initially thought
  2. The Foundation’s bitcoin balance in 2012 may never have been as large as we initially thought

Efficient Liquidity Pools, 20 August 2019

To encourage efficient trading strategies and incentivise behaviours that improve the executable liquidity of the market, BitMEX will be gradually introducing a number of trading rules for the platform. These rules are specifically designed to improve the quality of the exchange offering for users and are the result of a large amount of research over the past few months. This concept is nothing new and indeed most traditional venues employ similar rules.

You can read more about the first Trading Rule to be introduced in our API Announcement on the Quote Fill Ratio Threshold. This rule aims to discourage the use of strategies that submit quotes to the market without the intent to trade and therefore further strengthen the quality of liquidity on the platform in addition to freeing resources for other market participants.

We believe the introduction of these rules to be a positive step forward for the industry and we are committed to continuing innovation in the space.


For many years now, BitMEX has been the most liquid market offering cryptocurrency derivatives. A key indicator of the quality of a market is the depth and size of the quotes in the order book: liquidity is often measured by price slippage for a given volume to execute. offers a visual comparison of the price slippage across various cryptocurrency markets. In the sample below, the implied bid-offer spread for executing 1000 XBT worth of contracts on BitMEX’s XBTUSD market fluctuates around 0.5%. Compare this with other venues, where price slippage is roughly 10x higher, ranging from 3% to over 15%.




Since day 1, BitMEX has provided unprecedented access to the platform through our industry-leading API. Every action that can be performed on the website, can also be performed via our API. In fact, the web interface is just a client of our public API. This open approach has been a key contributor to BitMEX becoming the most liquid market in the industry.

Liquidity is only useful however if it is genuinely executable liquidity. In the month of June, fewer than 2% of active users on BitMEX accounted for over 60% of the order management requests processed, and less than 2% of the volume traded. Users fitting this behaviour profile are incredibly inefficient with their use of the API, submitting a disproportionately high number of orders per contracts traded.

There are a number of explanations for this kind of API usage. We often discover accounts that have signed up to an online automated trading service (or “bot”), entered their API keys, and then forgotten entirely about the account whilst it continues to place/amend/cancel thousands of orders every day. Other times, it could be a misconfigured trading system or client algo, which is quoting too wide and very rarely trades.

This kind of behaviour, whilst not currently against the rules, takes resources away from participants genuinely looking to trade on the platform. We believe that discouraging this kind of behaviour will further strengthen the liquidity of the market and provide a better overall experience for users.

If you have any further questions please contact Support via our contact form:

Ensuring the Continued Compliance of the BitMEX Platform, 19 August 2019

In 2014, HDR Global Trading Limited (HDR) was founded in Mahé, Seychelles as a small, dedicated team of young entrepreneurs focused on a simple mission: to build a crypto trading platform geared toward experienced traders first. We focused on building the most responsive interface, featuring groundbreaking products, controlled by a complete and seamless API, with the tightest security. From those ideals, BitMEX was built.

The market has spoken: BitMEX has succeeded. We are proud to have built the most innovative, reliable, and secure cryptocurrency platform in the world.

As BitMEX grows, so the world grows with it. In 2013, only months before we began, Bitcoin had just crashed from its second major bull-run. The dreams and wallet balances of the greater crypto community crashed with it. A new set of priorities emerged, focusing on safety, security, and stability. Financial regulators started to pay more attention to Bitcoin, and rightly so. It was clear to all of us that new standards were needed for this new industry.

Since then, the cryptocurrency landscape has changed dramatically, and leaders such as BitMEX have been working with regulators to help shape the industry, creating the standards that will help it go mainstream. 

The increased involvement of regulators with all the major players in the industry is not only to be expected, it is to be welcomed. It is the mission of good regulators to ensure that honest citizens are not being cheated. Regulators bear the burden of ensuring that risks are clearly communicated, products are fair, and taxes are collected. Through this process, we will see a new era of legitimacy for cryptocurrency exchanges: a future where market operation standards are clearly stated and maintained, where security is paramount, and where financial reserves are independently and frequently audited.

We believe fervently in these goals. And we understand that nothing is more sacred than the safety of your funds and the stability of the platform.

For this reason, we have decided to restrict access to BitMEX for users in the jurisdictions in which HDR-affiliated employees and offices are located. Seychelles, Hong Kong and Bermuda will be added to the list of jurisdictions already restricted from access to BitMEX. This change will have no financial impact on the business and will affect very few people. The BitMEX team will be reaching out to those who are affected. 

The BitMEX platform is entering a new and exciting era. This conservative action is not taken reactively, but proactively. We want to ensure we lead the industry not just in innovation but also in standards. 

  • We are extending the transparency of our systems so that our customers and stakeholders can better understand how BitMEX operates. 

  • We are showing third-parties why we believe BitMEX is a safe place to trade; how our innovative contracts are structured; why we keep an Insurance Fund; how auto-deleveraging is orderly and fair; how we know all accounts are 100% backed; and why we believe BitMEX has one of the safest custody solutions in the world. 

  • We are working on independent audits of our Insurance Fund, market making activities, and tradeable contract structure and we hope to share the results of these processes in the near future.

We believe success in the cryptocurrency space lies in the ability to think long-term, not short-term. And in that long-term view, we believe this course of action affords us the best opportunity to engage regulators in deep, thoughtful, and productive explorations of the risks and opportunities present in the cryptocurrency market.

BitMEX will not just be the most liquid, innovative place to trade. It will also be one where customers may rest assured – with independent affirmation – that accounts are solvent, settlements are honest, and all participants enjoy the same access and opportunity to Trade More.