As you see on the project-bitmark github, they have pushed to master the fork dbkeys proposed (so he can easily sell his stash). Not only does it fundamentally change Bitmark from a P2P cryptocurrency to a crowdfunding campaign for investors, but it uses cheap hacks to get the thing done (forced block height not even waiting for user or miner votes), doesn't fix important bugs, and still continues to be advertised as a "decentralized cryptocurrency". If it is not 100% crystal clear to someone that this fork is about manipulating the price from the supply side, then ask me and I can try to make it more clear (except for dbkeys whom I already explained this to repeatedly).

In case someone / people want to continue with the current protocol, with a couple of minor/bug fixes that technically need a hard fork, then I created a github repo called bitmark-protocol, that has this under the software version number 0.9.7.3 (dbkeys' fork is 0.9.8.x). The core block number remains as 4, just a variant/subversion number 1 is embedded into the full version number, so the version number for blocks would be called 4.1 (dbkeys's fork has version number 5). My fork would require 950 out of the last 1000 blocks signaling for version 4.1 to activate. The code is available at https://github.com/bitmark-protocol/bitmark. You can clone the latest master for stable code. It is quite well tested, though I will test more thoroughly if I see version 4.1 blocks being mined. The dev branch is for developments before they enter master. I also launched an explorer for monitoring blocks: https://explorer.bitmark.cc and https://explorer.bitmark.cc/testnet for testnet.

The 2 fixes in this release are:
1) Use Bignum for the subsidy scaling factor to prevent an overflow that has occasionally caused block rewards to be much less than they should be.
2) Activate the resurrector even right after the surge protector kicks in. Currently, 25 blocks must pass before the resurrector (lowering of difficulty after some time of no blocks of an algo) can kick in after a surge protector event (9 in a row for an algo). This is a rare case, but still needed for correctness.

If there is not enough support for my fork, then, instead of creating a new coin, I will likely work on migrating the Bitmark protocol into a Bitcoin sidechain. Sidechain technology is still not mature and requires some layer of trust, but I think it can work and help other sidechains thrive as well. You can see my post about this here https://bitcointalk.org/index.php?topic=4919679.msg44289606#msg44289606

By the way, dbkeys' fork is not even well tested, they use the requirement block.nVersion >= 5, while it should be GetBlockVersion(block.nVersion) >= 5 in order to force version 5 blocks. The raw version number only worked for the first fork where we first introduced the notion of raw (with extra data) and core version numbers. It's not a critical bug, but still shows lack of testing.