Midstate
State of Play
Before a coin is real, three things have to be true: the chain has to run, people have to mine it, and it has to trade. Midstate does all three. The chain is live, people mine it (including on a Raspberry Pi), and it’s listed on SafeTrade, so it trades against real money.
I did not arrange that listing or apply for it. SafeTrade reached out. They said they liked what Midstate was doing and listed it themselves, describing it publicly as an innovative post-quantum blockchain.
They expected it to be hard. Post-quantum signatures and the two-phase transaction model made it, on paper, one of the more difficult integrations they had taken on, so they started with some precautions; no mining straight to the exchange, no high-frequency deposits or withdrawals. Then they built it, and it went smoother than they thought. Their words, once it was live: it wasn’t as hard as they initially expected, and it has run smoothly since.
Most projects never get any of the three, let alone all of them.
With the basics working, this seems like a good time to write down where the project stands and what comes next, including the parts that aren’t finished, since that’s where most of the remaining work is.
The Pi axe
That is a Raspberry Pi 5 mining Midstate. Not a rack. Not a rented GPU. A single board computer in one hand.
It matters because of the hardware gap. On Midstate the fastest miner is a GPU. A Pi running the 8-way NEON SIMD path does roughly 100 nonces per second. An RTX 4090 farm does tens of thousands. The gap between the hobbyist and the industrial rig is about 1 to 5,000.
That sounds bad until you compare it to Bitcoin. A hobbyist on a Bitaxe hashes at 500 Gigahashes per second against a 600 Exahash network. That gap is 1 to 1.2 billion. Midstate traps the hardware advantage in the commodity silicon band. A cheap, low-power machine you already own is genuinely in the game. Almost no coin with real hashrate can say that.
I looked at pushing it further, past GPUs, down to the Pi specifically. I had a design. I built it and I tested it. The honest answer is you cannot make a Pi beat a desktop at hashing. There is no resource a Pi has more of. You can make GPUs less dominant, but every version of that ends up favouring cheap cloud ARM and botnets, which is worse. A botnet of compromised phones is not decentralisation.
So the proof-of-work stays. It is simple, it verifies against one scalar implementation, and it works. GPUs dominate on purpose: they cost capital, space, and power, which prices out the IoT-refrigerator swarms a CPU coin invites. The Pi axe mines it. 1 to 5,000 is a gap a hobbyist can live with.
There is also a pool, so a small miner is not stuck mining solo against 1-to-5,000 odds and waiting months for a block. Point a Pi at the pool and it earns steadily, in proportion to the shares it submits.
The pool is provably fair. Normally a pool miner has to trust the operator to count their shares honestly. This one does not require that. It commits a Merkle tree of every miner’s score into the coinbase of each block, and a miner can pull a proof from the pool’s audit API that their exact score was included before they start hashing. If the operator lies or leaves someone out, the miner’s client sees the mismatch and disconnects. Payouts are proportional and every past split can be re-checked against the commitment it was paid from.
If you want a Midstate Pi5 Axe, I will sell it to you all set up to mine for 1000gMDS. Ready to run and fully synced.
Next: Layer 2
The next real work is Q-Bolt, the Layer 2 system. It exists and it works. But there is an honest gap between what it is now and what it needs to be, and this is the section where I say exactly what that gap is.
What Q-Bolt is today
Q-Bolt is Spilman channels. Two parties fund a 2-of-2 multisig UTXO. One side is the sender, one is the receiver. The sender signs balance states and hands them over; the receiver stores them and signs nothing until the channel closes. Only two transactions ever touch the chain: the open and the close.
This design is deliberately simple, and it buys a strong safety property for free. The sender never holds the receiver’s signature, so the sender cannot broadcast any balance state at all. Their only unilateral exit is a time-locked refund after the channel expires. The receiver’s balance can only ratchet up: an old state pays them less, and they just reject it. So there is no need for revocation, no penalty transactions, no “punish the cheater” machinery. The attack those mechanisms defend against is structurally impossible here, because the money only flows one way.
The routing, HTLCs, and swaps are already built on top of this. Payments cross multiple channels locked by a single preimage. Hubs forward for a flat 50 sats, which is what their two one-time keys cost them. Covenant HTLCs claim with no signature at all — the script forces the coin to the right place, so the redeemer only reveals the preimage. On a chain where every signature is a 576-byte one-time key, a claim path that spends zero keys is worth having. There is even just-in-time channel opening, so a hub can pay a destination it has no channel to yet.
A worked example: the cross-chain DEX
The clearest way to see why Layer 2 matters is the cross-chain DEX, which is live and works today, on-chain, both directions but is currently hidden in the wallet.
Say you are selling MDS for ETH on Base. Under the hood it is a hash-time-locked swap:
You lock your MDS in a covenant on Midstate. The lock has a hashlock — H = BLAKE3(secret) — and an absolute refund height. Only someone with the secret can claim it before that height; after it, you get it back.
The buyer sees your lock, verifies it, and locks their ETH in the swap contract on Base with the same H and a shorter refund delay.
You claim the ETH by revealing the secret on Base. The contract publishes it.
The buyer reads the secret from Base and uses it to claim your MDS on Midstate.
Nobody can be cheated. Either both legs complete or both refund. The whole thing is trustless and needs no intermediary.
It is worth heading off the obvious worry: doesn't publishing the secret let anyone steal the coins? No, and the reason is the whole trick of the design. The secret is not a key to the money — it is one of two conditions on each lock. The other condition is a fixed recipient, baked in when the lock was made: the MDS lock pays the buyer, the ETH lock pays you, and that is true no matter who reveals the secret. So the secret only lets someone trigger a payment that was already addressed to someone else. If a bot reads the secret off Base and races to claim first, all it does is pay gas to send you your own ETH. Revealing the secret is not a leak; it is how the swap settles.
But look at where the time goes. Every leg is an on-chain Midstate transaction, and a Midstate transaction is two phases — commit then reveal — separated by block confirmations, at roughly one block a minute. Locking the covenant confirms on-chain. Claiming it confirms on-chain. A single swap can take many minutes end to end, and every partial fill is another round of the same. It is correct, but it is slow, and slow kills a DEX.
This is exactly the problem Layer 2 solves, and here is the part worth being precise about: the fix is already partly built. The hashlock in that swap is the same primitive Q-Bolt uses for routing. A submarine swap is the bridge — it links the on-chain HTLC to an off-chain channel payment under one preimage, so the Midstate leg settles instantly in a channel while the ETH leg settles on Base, and the same secret unlocks both. Flip the MDS side from an on-chain covenant to a channel HTLC and the lock-and-claim — minutes of block confirmations — collapses into an instant channel update.
That submarine path exists in Q-Bolt today. When a taker locks their ETH, the maker’s node can intercept and add the matching HTLC to a
n open channel instead of going on-chain. Both sides of that plumbing are written. Two things stop it being the everyday experience. First, it is currently disabled in the interface — the DEX defaults to the slower on-chain settlement while the fast path is finished and tested. Second, and more fundamentally, it only works when a channel already happens to exist in the right direction with enough balance. Because today’s channels are one-directional and disposable, that channel often is not there, and the swap falls back on-chain.
So the DEX is not blocked on inventing Layer 2. It is blocked on finishing it: turning the submarine path on, making it the default, and making channels persistent and routable enough that the fast path is available every time instead of only when liquidity was pre-positioned. That is the shape of the whole plan. Anything slow because it waits for Midstate blocks — DEX fills, token trades, ordinary payments — gets fast the moment it settles in a channel, and the machinery to do it is already partly in the code.
What it needs to become
The end goal is the only thing that matters here: instant transactions, high throughput, low fees. A real Layer 2. Whether the channels end up one-directional, bidirectional, or something else is an implementation detail I will solve in code. The target is fixed; the shape is not.
Q-Bolt has the hard parts already — funded channels, HTLCs, routing across hubs, swaps — and they work. What is left is turning that from a set of working parts into a network that moves payments instantly and cheaply at scale. That is engineering, not research: it needs no new cryptographic assumption and no script feature the chain does not already have. The primitives are in the VM. The work is making them into a payment network.
Alongside the channel work, three supporting pieces:
Watchtowers, so your channels are safe while you are offline. Midstate already has a gossip layer and peer reputation to build them on.
Refill and splicing, so a drained channel is topped up instead of closed and reopened on-chain.
Pathfinding and invoices, so payments route across many hubs with liquidity awareness.
The measure of success is simple. A payment confirms instantly, costs almost nothing, and the network can carry a lot of them at once. Everything in this section is in service of that and nothing else.
Then, on top of it
Once the channel layer is a real network, the rest follows:
Submarine swaps. Move value between Layer 2 and the main chain trustlessly, in either direction, unlocked by one preimage on both sides so there is no cross-chain theft.
The DEX, brought back on top of those swaps.
A token on-chain. Not because the world needs another memecoin, but because it proves the chain carries tokens other than MDS.
A Uniswap-style AMM, so those tokens trade against MDS.
All of it works on the main chain today. It is slow. On Layer 2 it is instant. That is the whole reason for doing it there. But the instant part is real only once the channels are bidirectional and the network can route. That is the work.
A GUI wallet
Right now there are two ways to hold Midstate: the command-line wallet, and the browser wallet. The CLI is for people who live in a terminal. The browser wallet is genuinely a light node — it scans the chain with compact block filters over WebRTC, verifies what it finds, and never trusts a server to tell it its own balance. But it is a browser tab.
What is missing is a desktop application. A GUI full-node wallet for Windows and macOS that a normal person can download, run, and understand. Send, receive, channels, history, backup — without a command line and without a browser.
The harder, better version has mining built in. The node already has an 8-way NEON SIMD miner and a GPU miner that treats the graphics card as an untrusted oracle and re-verifies every chain on the CPU before broadcasting. Wrapping that in a desktop wallet means one download that syncs, holds your coins, and mines them. That is the thing that makes a Pi axe or a desktop a first-class citizen instead of a config file.
It is not a small job. It is a large amount of non-core code to write and, worse, to support. Support is the part people underestimate. It needs more hands than mine.
So there is a bounty: 1000 gMDS (1,073,741,824,000 MDS or 1000 block rewards) for a working GUI full-node wallet, Windows and macOS. Wallet first; mining can follow. If that is a thing you would build, say so. Judged by me and the community. I’m working something up in the meantime to be part of the Core codebase - as moving to layer2 natively is one of the next challenges that would be more user friendly in a GUI vs the CLI.
The actual problem
Here is the honest part.
People use Midstate. They mine it, swap it, trade it. Almost nobody builds on it.
That is what holds the project back. Not the protocol. The protocol is further along than the community realises. What is missing is other people making things: contracts, tokens, tools, apps. Right now that is mostly one socially awkward person, and one person is not a development community.
I want to fix that directly, and the first piece is already live.
There is an IDE at https://midstate.cash/ide. You do not hand-write stack opcodes. It has a real language built for Midstate — let and var, if, repeat, switch, user-defined macros, named struct and state field layouts so you address a coin’s committed state by name instead of slicing bytes, and the usual infix operators. It ships with a standard library of the primitives covenants actually need: require_signed_by, require_timelock, require_funds_transferred, Merkle-proof verification.
That compiles down to the low-level script the VM runs, you can still drop to raw opcodes anywhere you want, and the debugger steps through the compiled bytecode against a live stack so you watch exactly what your code does. There are HTLC and covenant templates to start from, an emulator where you set the block height and inputs, and wallet connect, so you can go from a blank editor to a deployed script without leaving the page. A novel script language is hard to start cold. This removes most of that.
On top of the IDE:
The 1000 gMDS GUI wallet bounty above.
Competitions, ideally run on-chain themselves. The prize money does not need to sit in my wallet on trust. For a bounty with an objective test — a contract that has to satisfy a given spec, pass a given input, or unlock a test coin — a covenant can escrow the prize and release it automatically to whoever first meets the condition. No judge, no trust. For a judged competition, where "best" is a human call, the same escrow releases on a governance vote instead. Either way the funds are locked on-chain and the rules are visible, which is itself the kind of contract the competition is asking people to write.
A foundation — possibly a DAO written in Midstate script. Midstate covenants are stateful: a script reads the state committed on the coin it spends and the state on the coin it creates, and enforces the relation between them, so state threads forward from one transaction to the next. That is enough for a real on-chain state machine — a running vote tally, a staking pool, a treasury — not just a one-shot check. It is not hypothetical: the IDE ships a staking-and-governance contract that compiles to bytecode today and enforces exactly this state continuity, with named state fields, stake-weighted voting, thresholds, and enforced treasury payments. It stays within a deliberately non-Turing-complete VM — a stateful treasury with token-weighted rules, not arbitrary contract logic — and it would be the project governing itself on its own chain, which is the strongest demonstration there is that Midstate carries real applications, not just MDS.
There is a JavaScript SDK on npm, but it is behind the protocol: it does not handle reorgs, misses consolidate outputs, and its Layer 2 support is a stub. Updating it is exactly the kind of contribution the project needs.
The chain works, it trades, and it is cheap to experiment on. If Midstate grows, it grows because more people build on it than just me. That is not a complaint. It is the one thing I cannot do alone.
Near term
Over the next few days I will write something longer and put a proper roadmap on the site.
Short version: finish Layer 2, bring back the DEX on submarine swaps, add tokens and an AMM, a GUI wallet probably by bounty, and push hard on getting people building instead of only using.
The hard parts are done. The rest is a question of hands.