In response to unforeseen issues with the rollout of RC3, the Dash development team created a mechanism by which updated code is released to the network, but not immediately made active (or “enforced”).

Communication is sent out to users informing them of the change and the need for them to update their clients. Those who update their clients run the new code, but in the event of errors occurring with that new code, the client’s blocks are not rejected by the network and unintended forks are avoided. Data about the error can then be collected and forwarded to the development team. Once the development team is satisfied with the new code’s stability in the mainnet environment – and once acceptable network consensus is attained – enforcement of the updated code can be activated remotely. Should problems arise, the code can be deactivated in the same manner, without the need for a network-wide rollback or client update.

This innovation allows for far smoother transitions than in the traditional hard fork paradigm, as well as the collection of test data in the live network environment. We set out with the intention of calling this method of updating the “Soft Fork”, but the Dash community quickly dubbed it the “Spork” and the name seems to have stuck.