The thirteen algorithms
In the exact order they're applied:
| # | Algorithm | Author / origin | Digest |
|---|---|---|---|
| 1 | Blake | Aumasson, Henzen, Meier, Phan (SHA-3 finalist) | 512-bit |
| 2 | BMW (Blue Midnight Wish) | Gligoroski et al. | 512-bit |
| 3 | Grøstl | Gauravaram et al. (SHA-3 finalist) | 512-bit |
| 4 | JH | Hongjun Wu (SHA-3 finalist) | 512-bit |
| 5 | Keccak | Bertoni, Daemen, Peeters, Van Assche (SHA-3 winner) | 512-bit |
| 6 | Skein | Ferguson, Lucks, Schneier et al. (SHA-3 finalist) | 512-bit |
| 7 | Luffa | De Cannière, Sato, Watanabe | 512-bit |
| 8 | CubeHash | Daniel J. Bernstein | 512-bit |
| 9 | SHAvite-3 | Biham, Dunkelman | 512-bit |
| 10 | SIMD | Leurent, Bouillaguet, Fouque | 512-bit |
| 11 | Echo | Benadjila, Billet et al. | 512-bit |
| 12 | Hamsi | Özgül Küçük | 512-bit |
| 13 | Fugue | Halevi, Hall, Jutla (IBM Research) | 512-bit |
The output of each algorithm is fed as input to the next. Only the final Fugue output's low 256 bits is compared against the difficulty target.
Pseudocode
function x13(block_header):
h = blake512(block_header)
h = bmw512(h)
h = groestl512(h)
h = jh512(h)
h = keccak512(h)
h = skein512(h)
h = luffa512(h)
h = cubehash512(h)
h = shavite512(h)
h = simd512(h)
h = echo512(h)
h = hamsi512(h)
h = fugue512(h)
return h[0:32] # low 256 bits
Why thirteen?
ASIC resistance by construction
A single-algorithm ASIC (e.g. a Bitcoin SHA-256 miner) is relatively cheap to design: one core layout, replicated thousands of times, optimized for one hash. An X13 ASIC has to integrate thirteen completely different circuits. Not just more silicon — different memory access patterns, different parallelism, different bit widths. The per-hash cost on dedicated hardware comes much closer to commodity GPU economics.
The result: X13 chains stayed GPU-mineable for years after SHA-256 went fully ASIC. When X13 eventually saw dedicated ASICs (the Baikal X13 in 2017, Bitmain E9 in 2018), the efficiency gap over GPUs was significantly smaller than for single-algorithm chains.
Cryptographic diversity
If a catastrophic flaw were discovered in one algorithm — say, a preimage attack on CubeHash — an X13 chain's security only degrades partially, because the other twelve algorithms are still protecting the header. A single-algorithm chain would be game-over.
This is belt-and-suspenders cryptography. Expensive in CPU cycles, but you're buying defense-in-depth.
It was a specific 2014–2015 era design choice
X13 was popularized by DigitalCoin (2014) and quickly adopted by a wave of altcoins including MotaCoin's ancestors. It's less used today than X11 (simpler, Dash's choice) or Equihash (memory-hard, Zcash's choice), but it runs quickly on any modern CPU and is perfectly adequate for a PoS chain where the hash isn't the bottleneck.
X13 in MotaCoin's current (pure-PoS) era
MotaCoin transitioned from PoW to pure PoS at the PoW cutoff block. In the PoS era, the X13 hash is still part of the block header format — every block's header is X13-hashed and compared against the stake kernel target (not a PoW difficulty target). The stake kernel hash determines whether a staker's UTXO is eligible to produce a block at a given timestamp.
Preserving X13 through the PoS transition means:
- The block header format is unchanged — genesis-era blocks still validate with modern nodes
- The kernel difficulty math is the same equation as PoW, just with a different target derivation
- Chain reorganization logic uses the same cumulative work formula
Stake kernel formula
kernel_hash = x13(
prev_stake_modifier ||
stake_utxo_tx_time ||
stake_utxo_tx_hash ||
stake_utxo_out_index ||
block_timestamp
)
valid_stake := kernel_hash < (target * coin_age)
where coin_age is how long the staking UTXO has been unspent, capped at 90 days. Old, unmoved UTXOs have a higher effective target and therefore a higher chance of producing a valid stake — but only once per UTXO; as soon as it stakes, its coin age resets.
Verifying a block hash yourself
If you want to prove to yourself that mainchain blocks really are X13 hashes, grab any block header from the explorer and hash it:
$ motacoin-cli getblockheader "<blockhash>" false
# returns the 80-byte serialized header as hex
# Compute X13 of that header with a reference library:
$ python3 -c "
import x13_hash, binascii
header = bytes.fromhex('<the hex above>')
h = x13_hash.getPoWHash(header)
print(binascii.hexlify(h[::-1]).decode()) # reversed to match little-endian display
"
The result should exactly equal the block hash reported by getblockhash(height). This is how any node validates every block on the chain — nothing magical, just thirteen hashes in sequence.
Why not just SHA-256?
Because MotaCoin is not trying to outcompete Bitcoin on raw security per dollar. The design philosophy is diverse, verifiable, GPU-friendly — a chain where a single ASIC vendor can't dominate block production, where multiple independent cryptographic primitives protect the header, and where no one algorithm's flaw is existential.
For a cannabis-community payment chain with 4:20 block times and an inverted-escrow Solana bridge, X13 is exactly the right fit: fast enough on commodity hardware, cryptographically overdetermined, and historically consistent since 2019.
src/crypto/ — Blake, BMW, Grøstl, JH, Keccak, Skein, Luffa, CubeHash, SHAvite-3, SIMD, Echo, Hamsi, and Fugue each live in their own compilation unit.