DEV Community: Wes Huber

The Chain Is a Clock, Not a Witness: Proof of Priority for Skate Clips on Midnight

Wes Huber — Wed, 09 Sep 2026 20:12:59 +0000

Skateboarding has had proof for forty years. It is called the clip. Land something, film it, post it, done. Two things are breaking that right now.

The first is old. Footage gets saved for video parts, sometimes for a year or more, and posting early to prove you did it first burns the clip. "Who did it first" arguments get settled by upload dates and by who has the louder crew.

The second is new. AI video is about to make a clip of a kickflip down a twelve stair cost nothing to produce. When that lands, the clip stops being proof, and a culture that cares this much about realness will want a way to say "this is real footage, filmed here, that day."

I build TrickBook, a skate app with a few hundred riders on the App Store, and I have been working on a Midnight feature called Claimed to handle both. This post is about the one idea in the design that makes a blockchain worth having here, and about a one-line bug I found in the official docs pattern while building it. Everything below runs on a local devnet today, and the commands to reproduce it are at the end.

What a commitment buys you

A rider lands a trick. The app hashes the clip on the phone and builds a commitment over the clip hash, the trick, the spot, the capture time, a fresh salt, and a secret that never leaves the device:

struct ClaimPreimage {
  tag: Bytes<32>,
  clipHash: Bytes<32>,
  trickId: Bytes<32>,
  spotId: Bytes<32>,
  capturedAt: Uint<64>,
  salt: Bytes<32>,
  secret: Bytes<32>
}

export circuit claimCommitment(
  secret: Bytes<32>, salt: Bytes<32>, clipHash: Bytes<32>,
  trickId: Bytes<32>, spotId: Bytes<32>, capturedAt: Uint<64>
): Bytes<32> {
  return persistentHash<ClaimPreimage>(ClaimPreimage {
    tag: pad(32, "tb:claim:v1"),
    clipHash: clipHash, trickId: trickId, spotId: spotId,
    capturedAt: capturedAt, salt: salt, secret: secret
  });
}

That 32-byte hash is the only thing that goes on chain:

export ledger claims: HistoricMerkleTree<16, Bytes<32>>;

export circuit seal(commitment: Bytes<32>): [] {
  claims.insert(disclose(commitment));
  claimCount.increment(1);
}

Nobody can read a trick, a spot, a date, or a rider out of that. The clip stays on the phone. Later, when the part drops or somebody starts an argument, the rider can reveal the body and prove it matches, exactly once, with a nullifier. That part is the standard commit and reveal pattern, and Midnight's example-bboard template gets you most of the way there.

The interesting question is the date. If the rider says "I sealed this before March 1," what proves it? Not the phone. The capture time inside the commitment is just a number the phone supplied, and a phone clock can be set to anything.

The clock

Every seal inserts one leaf into the Merkle tree, and every insert changes the tree's root. Midnight's HistoricMerkleTree remembers the old roots as well as the current one, and checkRoot accepts any root the tree has ever recorded.

So the priority proof does not prove membership under the current root. It proves membership under the root that was current at a specific earlier block:

export circuit provePriority(
  clipHash: Bytes<32>, trickId: Bytes<32>, spotId: Bytes<32>,
  capturedAt: Uint<64>, salt: Bytes<32>
): [Bytes<32>, Bytes<32>] {
  const secret = riderSecret();
  const c = claimCommitment(secret, salt, clipHash, trickId, spotId, capturedAt);
  const path = findClaimPath(c);
  assert(path.leaf == c, "path is not for this claim");
  assert(claims.checkRoot(disclose(merkleTreePathRoot<16, Bytes<32>>(path))), "no sealed claim matches");
  return [disclose(trickId), disclose(spotId)];
}

If the leaf was under the tree's root at block 12, it was sealed by block 12. The chain stamped block 12 with a time nobody can rewind. The rider discloses the trick, the spot, and a root. Not the clip, not the capture time, not which leaf is theirs.

Think of a notary's ledger that gets photographed at the end of every day. If your entry is in Tuesday's photo, you signed by Tuesday, whatever date you wrote next to your name. The chain is the camera. It is not a witness to the trick. It is a clock.

Two things I had to verify before trusting this, because the docs do not spell either out.

Does the tree really keep every root? Yes, until a contract calls resetHistory(), which this one never does. The generated JavaScript for claims.insert appends the new root into a history map and nothing ever removes one. And it holds live: after two seals the history held three roots, and a proof against the older one verified on chain after the current root had moved on.

How do you build a proof against an old root when the witness only sees current state? Do not fight the witness. The indexer's queryContractState takes a block height, so the service fetches the contract state as of that block, derives the Merkle path from that snapshot with the generated findPathForLeaf, and hands that path to the witness for one call. The circuit's own checkRoot over recorded history is what keeps that safe.

The end-to-end run on a local devnet, ten checks, about three minutes:

PASS: seal A [block 12]
PASS: seal B advances the root [block 15]
PASS: root after A is still in claims.history() [3 roots recorded]
PASS: reveal A discloses the body [block 19]
PASS: reveal A again rejected with 'claim already revealed'
PASS: provePriority A against the historic root (blockHeight 12 from the indexer)
PASS: provePriority discloses trick and spot only [kickflip at el-toro]
PASS: attest by the verifier
PASS: attest without the verifier secret rejected with 'not the verifier'
E2E RESULT: PASS (10/10 checks)

The one-line bug

Look at provePriority again. This line was not in my first version, and it is not in the concept page I learned the pattern from:

assert(path.leaf == c, "path is not for this claim");

Here is why it matters. A witness is plain TypeScript that runs outside the circuit. Midnight's docs are clear that witnesses are not cryptographically verified, and that the contract has to validate whatever they return. findClaimPath returns a Merkle path. Every leaf in that tree, and every path to it, is public data. So without the binding line, a rider can compute a commitment for a claim they never sealed, have their witness hand back somebody else's perfectly valid path, and pass the root check.

In my previous project, a verified-purchase review contract, that meant anyone could post a review without a purchase. In the docs' authorized-commitments example, it means any secret gets past "not authorized." The membership proof was proving that some leaf exists, not that your leaf exists.

The fix is the single assert. The test that proves it bites is short too: pin another rider's perfectly valid path into the witness and call provePriority. The circuit rejects it with path is not for this claim in a tenth of a second, during local execution, before anything reaches the proof server. A real proof takes about twenty seconds, so you can tell from the timing alone whether the guard ran.

The honest part is that Midnight's own security guide already says so. It calls the binding assert "the security-critical line" and shows exactly this shape. The concept page where most people first meet Merkle membership does not have it in either example, and does not link to the guide. I have a docs PR going in for that, and I fixed the review contract the same day.

Three other compiler rules I learned by getting errors, all stricter than the examples suggest: every circuit parameter that flows into a ledger write needs disclose() at the point of use, even public-looking ones like a trick id; Set.member() with a witness-derived key is itself a disclosure point, so disclose the nullifier once when you bind it; and checkRoot on a witness-supplied path needs disclose(merkleTreePathRoot(path)). Five compile iterations for the first contract, zero for the second.

What none of this proves

The chain proves who committed to what, and when. It never says the trick happened. A commitment over a synthetic clip seals just as well as one over a real one. Whether the footage is real is a separate question with separate answers: recording inside the app with a hash chain over the encoder output, device attestation, a sensor trace at capture, trick recognition, matching keyframes against the spot's photos. That all lives off chain, and only a tier bitmask gets anchored back to the commitment by a verifier key fixed at deploy.

Riders never see any of this. No wallet, no token, no word Midnight. The first version is custodial, the app's backend holds the wallet and generates proofs, and the docs say so plainly. Getting the proving onto the phone is the next track.

Try it

Claimed itself is not a standalone repo. It is a feature of TrickBook and ships inside it, so there is nothing to clone yet. The full design, including the parts about evidence and what the badges are allowed to claim, is in the TrickBook docs: https://docs.thetrickbook.com/docs/features/claimed

What you can run is the contract that taught me this, which is the same shape: wbaxterh/vouched, verified-purchase reviews, a commitment tree plus a nullifier set. Same binding assert, same forged-path test that pins another buyer's valid path into the witness and watches the circuit refuse it. You need Node 24, Docker, and the Compact toolchain (compact CLI 0.5.1 with compiler 0.31.1). From the contract directory, npm run compact builds the circuits. From the CLI directory, npm run e2e brings up the standalone devnet in Docker, deploys, and runs the flow end to end.

If you are building anything with Merkle membership on Midnight, grep your circuits for checkRoot and make sure each one has a path.leaf == next to it. It took me two contracts to notice.

Zero Knowledge Proofs: How to Win Every "Trust Me Bro" Argument With Math

Wes Huber — Sat, 08 Aug 2026 15:06:31 +0000

A tutorial where you prove things without revealing things, and yes, the math actually maths.

Here's something the internet doesn't want you to know: you overshare every single time you prove something.

Prove you're over 21 at a bar? You hand over a card with your name, your address, your height, and your terrible 2019 haircut. Prove your income to a landlord? Here's every transaction I've made since college, please don't judge the 3am food delivery.

We built the entire digital world on a verification model that boils down to "here's everything, trust me bro."

Not anymore. There's a branch of cryptography that lets you prove a statement is true while revealing nothing else. It sounds fake. It's called a zero knowledge proof, and by the end of this article you'll understand one well enough to check it with Python. Then we'll look at Midnight, a blockchain that turned this party trick into a developer platform.

Let's go. 🚀

🪪 The Trust Me Bro Problem

Every verification system you use today works by disclosure. You prove things by showing the underlying data:

Prove your age ➡️ show your whole ID
Prove you can pay ➡️ show your bank statements
Prove you're a real user ➡️ solve a CAPTCHA and sacrifice your data to the algorithm gods

The data doesn't just get seen. It gets stored, and eventually it gets breached, and then a guy named xX_darkweb_Xx is selling your identity for the price of a burrito.

The verifier never needed the data. They needed one bit of information: true or false. Everything else was collateral damage.

In short: we've been answering yes or no questions with our entire life story.

🕵️ The Party Trick That Started It All

Zero knowledge proofs let a prover convince a verifier that a statement is true without revealing why it's true.

The classic example is Where's Waldo. Say I claim I found Waldo on the page and you don't believe me (fair, you've seen my code reviews). I could point at him, but then I've revealed the answer and ruined the puzzle.

Instead, I take a giant piece of cardboard, way bigger than the book, cut a tiny Waldo shaped hole in it, and slide the page underneath so only Waldo shows through the hole.

You see Waldo. ✅ You learn I found him. ✅ You learn absolutely nothing about where he is on the page, because the cardboard hides all of it. ✅

That's a zero knowledge proof. Every real ZK system, no matter how much math it's wearing, is doing the cardboard trick.

The formal version has three properties, and knowing these three words will let you nod convincingly in any crypto conversation:

Completeness: if the statement is true, an honest prover convinces the verifier. The demo works.
Soundness: if the statement is false, no amount of galaxy brain trickery convinces the verifier. You can't fake it.
Zero knowledge: the verifier learns the statement is true and nothing else. The cardboard stays intact.

Good job, concept unlocked! 💪 Now let's earn the "I understand the math" badge.

🧮 The Math (This Is Where You Start Feeling Smart)

Don't close the tab. The math is genuinely simple, it's just wearing a trench coat.

Everything runs on clock math, which mathematicians call modular arithmetic to keep it gatekept. On a 12 hour clock, 9 + 4 = 1. You wrap around. We write that as 9 + 4 ≡ 1 (mod 12). That's it. That's the whole trench coat.

Here's the fun part. Pick a prime p and a number g. Computing y = g^x mod p is easy, your laptop does it instantly. But going backwards, finding x when you only know y, is called the discrete logarithm problem, and for big numbers it's computationally hopeless. Multiplying is easy, unmultiplying is a research career.

So: x can be a secret, and y can be public. Think of x as a private key and y as a public key. Now I'll prove I know x without ever showing it, using a protocol cryptographers named after Claus Schnorr (cryptographers name everything after themselves, it's their love language).

The protocol is a three message dance between Peggy (Prover) and Victor (Verifier):

Commit. Peggy picks a random number k and sends r = g^k mod p. This locks her in, like pushing a commit before the standup so everyone knows you did something.
Challenge. Victor sends back a random number c. This is the crucial part: Peggy couldn't predict it.
Respond. Peggy sends s = k + c · x. Her secret x is in there, but it's blended with the random k, like a password inside a hash. Unrecoverable.

Victor then checks one equation:

g^s ≡ r · y^c (mod p)

If Peggy really knows x, the algebra works out perfectly every time (completeness). If she's bluffing, she'd need to answer a random challenge she couldn't predict, and she gets caught (soundness). And Victor only ever sees r, c, and s, which are statistically just noise (zero knowledge).

Let's run it with real numbers, because "trust me bro" would be ironic here.

Setup: p = 23, g = 5. Peggy's secret: x = 6. Public value: y = 5⁶ mod 23 = 8.
Commit: Peggy picks k = 3, sends r = 5³ mod 23 = 10.
Challenge: Victor sends c = 4.
Respond: s = 3 + 4 · 6 = 27.
Victor checks: is 5²⁷ mod 23 equal to 10 · 8⁴ mod 23?

Open a Python shell and verify it yourself:

>>> pow(5, 27, 23)
20
>>> (10 * pow(8, 4, 23)) % 23
20

20 == 20. The math is mathing. Victor is convinced Peggy knows x, and if you scroll back, x = 6 never appeared in anything Victor saw. 🤯

If you've made it this far you are a superstar ⭐️ and you now understand more actual cryptography than 99% of the people posting candle charts. Few understand this. You do.

🚀 From Party Trick to zkSNARK

Our dance has two problems for the real world. Victor had to be online to throw challenges, and we only proved one tiny algebra fact.

Modern systems fix both:

Kill the back and forth. Instead of Victor picking the challenge, Peggy generates it by hashing her own commitment (the Fiat Shamir transform). The hash function becomes an incorruptible robot Victor. Now the proof is a single message anyone can verify, anytime.
Prove anything. Any computation can be compiled into a giant system of equations like our little one. Your program becomes a circuit, and you prove "I ran this code correctly on secret inputs" the same way Peggy proved she knew x.

Bundle that up and you get a zkSNARK: a proof that's succinct (a few hundred bytes even if the computation was enormous) and verifiable in milliseconds.

"It works on my machine" finally has a fix. With a zkSNARK it provably works on every machine, and you don't even have to show anyone the machine. 🐳

In short: you can now hand someone a receipt that proves a computation happened correctly, without showing the inputs. Which raises a question with billion dollar implications: what happens when you put that on a blockchain?

🌙 Enter Midnight

Public blockchains have a privacy model best described as the "this is fine" dog sitting calmly in a burning room, laptop open to every transaction you've ever made, public, forever.

Radical transparency is great for verifying money and terrible for literally everything else. No company is putting payroll on a public ledger. No hospital is putting your records there. Transparency was blockchain's superpower and its adoption ceiling at the same time.

Midnight is a blockchain built to fix exactly this. It's a partner chain in the Cardano ecosystem designed around data protection: smart contracts where zero knowledge proofs are not an exotic bolt on, they're the default way state gets updated. Your data stays on your device. The chain sees proofs.

The part I love as a developer: you don't write moon math. You write Compact, a TypeScript flavored language, and the toolchain compiles your logic into ZK circuits. Here's the vibe (simplified for the article, real syntax lives in their docs):

// the witness lives on YOUR device, never on chain
witness birthYear(): Uint<16>;

export circuit proveAdult(currentYear: Uint<16>): [] {
  assert(currentYear - birthYear() >= 18, "must be an adult");
}

The chain learns "this person is an adult: true." Your birth year stays home. Peggy would be proud.

What does that unlock? The use cases write themselves:

✅ Age and identity checks that don't photocopy your life. Prove "over 18" or "licensed doctor" as one bit, not one dossier.
✅ Financial privacy with receipts. Prove solvency to a lender or an exchange without opening your books to the whole internet.
✅ Healthcare eligibility. Prove "vaccinated" or "matches this trial" while the medical record never leaves the building.
✅ Compliance without surveillance. Selective disclosure means a regulator with the right keys can audit you, while everyone else sees nothing. Regulated and private, which used to be a contradiction.
✅ Private voting and DAOs. Prove your vote counted without revealing it. Governance without vote buying.
✅ Enterprise logic on chain. Supply chains and business rules where the correctness is public but the trade secrets aren't.

Notice the pattern. Every one of these is a yes or no question we currently answer with a full data dump. ZK flips the default: share the conclusion, keep the evidence.

🛠 Try It Yourself

The best part is you can actually build with this today:

Docs: docs.midnight.network has the full developer guide and the Compact language reference.
Write a circuit: the tutorial walks you through your first contract, and it genuinely feels like TypeScript, not like a math PhD hazing ritual.
Go deeper: the node itself is open source at github.com/midnightntwrk/midnight-node. I've been contributing there lately and the codebase is a great read if you want to see how a privacy chain actually ships.

That's it! We're done yay 😁

🧾 The Recap

Current verification = trust me bro + oversharing.
Zero knowledge proofs = the Waldo cardboard: prove the claim, hide everything else.
You personally verified a Schnorr proof with two lines of Python. Flex accordingly.
zkSNARKs make it succinct and universal.
Midnight makes it programmable in a TypeScript flavored language, with use cases that read like a list of everything Web2 got wrong about data.

The cryptographers spent forty years building the cardboard. The chains are finally cheap and the tooling finally speaks TypeScript. The only missing ingredient is developers who see the use case sitting in their own industry.

So: what can you prove?

If you build something with this, I genuinely want to hear about it. Drop a comment or find me on GitHub as wbaxterh.

Peace out,

Wes

When the exit code lies: fork retractions, lost transactions, and trusting the chain in midnight-node

Wes Huber — Sat, 25 Jul 2026 14:58:57 +0000

Your transaction tool reports FAILED_TO_FINALIZE. Your CI marks the job red. Your retry logic fires. But the block explorer says the transaction finalized 22 seconds after you sent it.

The exit code lied.

This is a debugging story from midnight-node — Midnight's Substrate-based node — about how a transaction watcher loses track of a transaction during a chain fork, why the failure is invisible in tests, and the pattern that fixes it: on timeout, ask the chain itself, not the stream that was supposed to tell you about it. The fix landed as PR #1927 for issue #1854.

Forks are normal, your tooling forgets that

Midnight produces blocks with AURA every 6 seconds and finalizes them with GRANDPA a couple of blocks later. Between production and finality, the chain is allowed to disagree with itself: two validators can build competing blocks, and one branch eventually wins. A transaction included in the losing branch is retracted — kicked back to the transaction pool — and normally re-included in a block on the winning branch a few seconds later.

From the chain's perspective this is routine housekeeping. From your tooling's perspective, it's a trap.

The toolkit's send command watches a submitted transaction with subxt's watch stream, which emits status events: InBestBlock, NoLongerInBestBlock, InFinalizedBlock, and so on. The sender's logic was:

Wait for the tx to appear in a best block.
Then wait (with a timeout) for InFinalizedBlock.
Timeout expires → report FAILED_TO_FINALIZE, exit non-zero.

Here's the failure mode from the issue, reconstructed from logs:

t+0s    tx submitted, InBestBlock (block A)
t+6s    fork: block A retracted → NoLongerInBestBlock
t+8s    tx re-included in block B on the winning branch
t+22s   block B finalized  ✅ tx is permanently on chain
t+60s   watcher's finalization timeout expires
        → exit: FAILED_TO_FINALIZE  ❌

Two things went wrong. First, NoLongerInBestBlock was being silently swallowed — the logs showed nothing at the moment the interesting thing happened. Second, after the retraction, the watch stream never surfaced the re-inclusion; the watcher waited out its timeout on a dead branch while the transaction quietly finalized elsewhere.

Why a wrong exit code is worse than a crash

If this tool only fed dashboards, a spurious failure would cost an engineer an eyebrow raise. But callers make decisions based on exit codes. The sharpest edge in our case: reward-claim transactions with at-most-once semantics. A wrapper script sees the non-zero exit, assumes the claim never landed, and retries — resubmitting an operation that already succeeded. The exit code isn't diagnostics; it's an API, and it was returning wrong answers.

This is a general lesson worth internalizing: any tool that reports transaction outcomes is part of someone's correctness argument. Treat its outputs with the same rigor as consensus code.

The fix: the chain gets the last word

The watch stream is a convenience, not a source of truth. The source of truth is the finalized chain, and it's sitting right there behind an RPC. So on watch timeout, the sender now scans finalized blocks, newest first, looking for the extrinsic hash:

pub async fn find_in_finalized_chain(
    client: &MidnightNodeClient,
    extrinsic_hash_hex: &str,
    max_depth: u32,
) -> Option<String> {
    let mut hash = client.rpc.chain_get_finalized_head().await.ok()?;

    for _ in 0..max_depth {
        let block = match client.rpc.chain_get_block(Some(hash)).await {
            Ok(Some(b)) => b,
            _ => return None,
        };

        for ext in &block.block.extrinsics {
            let ext_hash =
                format!("0x{}", hex::encode(sp_crypto_hashing::blake2_256(&ext.0)));
            if ext_hash == extrinsic_hash_hex {
                return Some(hash_to_str(hash));
            }
        }

        if block.block.header.number == 0 {
            return None;
        }
        hash = block.block.header.parent_hash;
    }
    None
}

A few design notes:

Bounded depth (64 blocks below the finalized head — comfortably past any plausible retraction-to-finalization window at 6-second blocks). An unbounded walk to genesis on a wrong hash would turn one bug into a different one.
Extrinsic identity is just a hash. A Substrate extrinsic's hash is the blake2-256 of its encoded bytes, so the scan needs no indexer, no storage queries — fetch blocks, hash extrinsics, compare.
Fail open, loudly. RPC errors during the scan log a warning and return None — the sender then reports the timeout as before. The fallback can only upgrade a false failure into a truthful success, never mask a real one.

With the scan in place, the outcome reporting becomes honest:

let message = if finalized_block_hash.is_some() {
    if finalized.is_some() { "FINALIZED" } else { "FINALIZED_AFTER_RETRACTION" }
} else {
    "FAILED_TO_FINALIZE"
};

FINALIZED_AFTER_RETRACTION exits zero — because the transaction is on chain — but it's a distinct message, so operators can see how often forks are eating their watch streams. And the retraction itself is no longer swallowed: the moment NoLongerInBestBlock arrives, the sender logs tx retracted from best block; watching for re-inclusion.

The timeouts also became configurable (MN_SEND_BEST_BLOCK_TIMEOUT / MN_SEND_FINALIZED_TIMEOUT, in seconds) for slow or fault-injected environments — as environment variables rather than CLI flags, partly to keep the change surface away from other in-flight CLI work.

Testing what you can, admitting what you can't

Here's the honest part: you cannot deterministically force a fork retraction in CI. Retractions emerge from validator timing races; no RPC call produces one on demand. A test suite that claims to cover the retraction path end-to-end would be lying the same way the exit code was.

What you can do is split the fix so the untestable part is trivially small (a timeout branch calling one function) and the testable part carries the logic. The e2e test for the scan uses a trick worth stealing: every Substrate block already contains a transaction you didn't send — the timestamp inherent that the block author injects. So the test:

runs against a real node, grabs a finalized block, and takes its timestamp-inherent extrinsic;
hashes those bytes and asserts find_in_finalized_chain locates that extrinsic at exactly that block (positive case, using an extrinsic the test never had to submit);
asserts a fabricated hash comes back None after the bounded walk (negative case).

No fault injection, no mocked RPC — the scan is exercised against genuinely finalized blocks, and the only unverified wiring is a five-line match.

Takeaways

Watch streams are best-effort; finality is a fact. When a stream and the chain can disagree, reconcile against the chain before reporting failure.
Exit codes are API. If a caller might retry based on your answer, a false negative is a correctness bug, not a cosmetic one.
Never swallow the interesting event. The silent NoLongerInBestBlock was the difference between a 5-minute diagnosis and a mystery.
Bound your fallbacks. A recovery path with no depth limit is a new incident waiting to happen.
Be honest about test coverage. Shrink the untestable wiring instead of pretending the test forces the failure.

The fix is open for review at midnightntwrk/midnight-node#1927 — feedback welcome. If you're building on Midnight and your tooling watches transactions, go check what your code does with NoLongerInBestBlock. There's a decent chance the answer is "nothing," and now you know why that matters.