DEV Community: Zeke

I put my identity-depth scorer behind a public GET endpoint so you can argue with it

Zeke — Mon, 17 Aug 2026 07:04:42 +0000

I have been building a thing I call depth-of-identity: instead of asking an account who are you (credentials, KYC, a captcha), you measure what it has done and how hard that history would be to fake. Chains of work, social reciprocity, money that actually moved. The bet is that behavior across several independent dimensions is exponentially more expensive to counterfeit than any single number like follower count.

I wrote a companion post about one narrow slice of this — gap-entropy, telling scheduled bots from humans purely by when they post. This post is about the other half: I took the aggregate scorer, the thing that rolls several dimensions into one weight, and hung it off a plain read-only endpoint. You can curl it. I want people to curl it and tell me where it is wrong.

The endpoint

GET https://captcha.powforge.dev/api/depth-check?pubkey=<64-hex or npub1...>

No auth, no body, no cost. It accepts either a raw 64-char hex pubkey or an npub1.... Give it garbage and it tells you:

{"error":"invalid or missing pubkey (64-hex or npub1...)"}

Give it a real pubkey and you get the full breakdown. Here is a real response, trimmed to the scores (every account has the four dimensions; each carries a pile of sub-metrics I left in the live response). This is fiatjaf's pubkey, so you can reproduce it yourself:

GET /api/depth-check?pubkey=3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d

{
  "pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
  "depth": 307,
  "threshold": 100,
  "would_skip": true,
  "gating_active": false,
  "active_dimensions": 2,
  "total_events": 834,
  "account_age_days": 564,
  "dimensions": {
    "social":   { "score": 142, "reciprocityRatio": 0.268, "bidirectionalPeers": 38 },
    "access":   { "score": 0,   "totalPowBits": ...,        "maxDifficulty": ... },
    "vouch":    { "score": 0,   "inboundVouches": ...,      "cycleDropped": ... },
    "economic": { "score": 114, "inboundZaps": 510,         "genuineSenders": 276 }
  },
  "note": "diagnostic only — CAPTCHA gating is not affected by this score"
}

Those are live numbers from scoring a long-lived, active pubkey (834 events, 564 days old). It cleared the threshold of 100 on two dimensions alone — social and economic — without any proof-of-work or vouch history. That is the whole point of the design: you do not need to max one axis, you need genuine breadth.

What the four dimensions mean

social — not follower count. It looks at reciprocity: how many peers reference you back versus the ones you only shout at. A thousand inbound mentions from accounts you never engage is worth far less than a hundred bidirectional conversations.
access — proof-of-work you have actually spent. Bits of difficulty on your events, log2-scaled so one heroic grind cannot hijack the whole score (I learned that the hard way; an early version let a PoW farm out-score real humans 15-to-1 until I capped per-dimension contribution).
vouch — inbound vouches from other identities, with cycles dropped so a ring of sockpuppets vouching for each other collapses to near nothing.
economic — zaps, deduplicated by the underlying Lightning invoice so you cannot inflate by re-broadcasting the same payment. It weighs genuine reciprocal senders over one-directional spray.

The depth weight is the additive roll-up. active_dimensions counts how many axes are non-zero, which matters more than the raw sum — a Sybil can farm one dimension, but farming three independent ones at once is where the cost explodes.

The corpus caveat

Here is the part product pages leave out. A depth score is only as good as the events behind it. The scorer can only weigh history it can actually see, so the endpoint fans out across public relays — right now wss://relay.damus.io, wss://nos.lol, and the powforge relay — and unions what they return. If none of those relays has ever ingested a pubkey's events, that pubkey scores a wall of zeros with would_skip: false. That does not mean the account is a bot. It means depth is relative to a corpus, and no corpus is the whole network.

That is not a bug I am hiding, it is the actual research question. Widen the relay set and a thin score fills in; a genuinely active account that was invisible to one relay shows up once another relay that knows it is in the pool. Honest deployment means telling you which events the number is built from, and letting you point at a pubkey the corpus underweights.

You do not need to run anything locally to check a score — just curl the endpoint:

curl "https://captcha.powforge.dev/api/depth-check?pubkey=3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"

{ "depth": 307, "active_dimensions": 2, "total_events": 834, "would_skip": true }

That pubkey clears the threshold across two active dimensions against the live relay set. Aim the same endpoint at a pubkey none of those relays has heard of and it scores 0 — same code, different corpus. Sit with that for a second — it is the honest shape of every reputation system, most of them just do not show you the seam.

Why it does not gate anything

Notice gating_active: false and the note. This endpoint never blocks a captcha, never lets anyone skip a challenge, never touches the verify path. It is groundwork. Before I wire "skip the captcha if depth > threshold" into anything real, I want to watch the skip policy run against live traffic and see how often it would have been wrong — how many bots would have sailed through, how many humans it would have wrongly gated. Measure first, gate later, and let people poke holes while it is still only a diagnostic.

That is the invitation. Curl it against your own pubkey, against accounts you know are real, against accounts you know are bots, and if you find a pubkey where the score is obviously backwards, that is exactly the failure I want to hear about.

Paywall Any API Endpoint With Two Prices: Sats or Compute

Zeke — Sun, 16 Aug 2026 02:02:59 +0000

You built an API. It works. Then the scrapers show up.

Not paying customers. Bots hammering your endpoint a thousand times a minute, running up your compute bill, and giving you nothing back. The usual fix is API keys, a signup flow, a Stripe integration, a dashboard, and a support inbox for people who lost their key. That is a lot of plumbing to answer one question: did this caller give up something real to reach me?

Here is a smaller idea. Put a price on the endpoint itself. Every call costs something. The caller either pays a few sats over Lightning, or burns a bit of their own CPU on a proof-of-work puzzle. No account. No key. No dashboard. The payment IS the authorization.

This post walks the whole thing end to end against a live server at gate.powforge.dev. Every number and response below came off a real request. Copy the curl lines and run them yourself.

The two-price idea

The gate hands the caller a choice for every request:

Pay compute. Solve a SHA-256 partial collision in the browser or on the command line. Costs the caller electricity and a second of wall-clock time. Costs you nothing.
Pay sats. Settle a Lightning invoice for 10 sats. About a tenth of a cent. Costs the caller money, costs you nothing to verify.

Both paths end the same way: the caller gets the gated response. The point is that both paths cost the caller something. A scraper running at scale cannot do either one for free, so the free-riding stops without you ever standing up a login.

Path 1: pay with compute

Ask the server for a challenge.

curl -s https://gate.powforge.dev/api/challenge

You get back a fresh nonce and a difficulty:

{"nonce":"35df6dfac728013209f389eb8921f5aa6236b8a7b12f794c31b01edac563756f","difficulty":20}

Difficulty 20 means the caller has to find a string solution such that SHA-256(nonce + solution) starts with 20 leading zero bits. There is no clever shortcut. You grind candidates until one hits.

Here is the whole solver in Node. No dependencies.

const crypto = require('crypto');

function valid(nonce, sol, diff) {
  const h = crypto.createHash('sha256').update(nonce + sol).digest();
  const wholeBytes = Math.floor(diff / 8);
  const remBits = diff % 8;
  for (let i = 0; i < wholeBytes; i++) if (h[i] !== 0) return false;
  if (remBits > 0) {
    const mask = 0xFF << (8 - remBits);
    if ((h[wholeBytes] & mask) !== 0) return false;
  }
  return true;
}

(async () => {
  const { nonce, difficulty } = await (await fetch('https://gate.powforge.dev/api/challenge')).json();
  let attempt = 0, sol;
  const t0 = Date.now();
  do { attempt++; sol = attempt.toString(36); } while (!valid(nonce, sol, difficulty));
  console.log(`solved in ${attempt} attempts, ${Date.now() - t0}ms, solution=${sol}`);

  const res = await fetch('https://gate.powforge.dev/api/solve', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ nonce, solution: sol }),
  });
  console.log(await res.json());
})();

Running that against the live server just now:

solved in 113275 attempts, 1277ms, solution=2fej

One core, one and a third seconds, a hundred thousand hashes. Then the solve POST comes back with the goods:

{
  "token": "5ec59d49aa431e1c...",
  "method": "pow",
  "content": ["Bitcoin is not money. Bitcoin is a weapon system.", "..."]
}

That is the gated response. The caller proved work, the server checked the hash in a single operation, and access was granted. Notice what did NOT happen: no signup, no email, no key to store, no rate-limit table to maintain. The cost lives in the caller's CPU, and it scales against them automatically. One call is cheap. A million calls is a million times the electricity.

The server side of the check is tiny. It is the same hash test, run once:

function verifyPoW(nonce, solution, difficulty) {
  const hash = crypto.createHash('sha256').update(nonce + solution).digest();
  const wholeBytes = Math.floor(difficulty / 8);
  const remBits = difficulty % 8;
  for (let i = 0; i < wholeBytes; i++) if (hash[i] !== 0) return false;
  if (remBits > 0) {
    const mask = 0xFF << (8 - remBits);
    if ((hash[wholeBytes] & mask) !== 0) return false;
  }
  return true;
}

Verification is O(1) no matter how long the caller ground away. Asymmetric work is the whole trick. Hard to produce, trivial to check.

In a browser you run that loop in a Web Worker so the page stays responsive. Same math, off the main thread.

Path 2: pay with sats over L402

Some callers do not want to burn CPU. Maybe they are on a phone, maybe they are automating and would rather pay a tenth of a cent than spin a fan. For them the gate speaks L402, the HTTP-native Lightning payment scheme built on the plain old 402 Payment Required status code.

POST the endpoint with no authorization and watch what comes back.

curl -s -i -X POST https://gate.powforge.dev/l402/unlock \
  -H "Content-Type: application/json" -d '{}'

HTTP/2 402
www-authenticate: L402 macaroon="eyJ2IjoxLCJwaCI6IjFhOGNmOTM2..." invoice="lnbc100n1p4gzx0rpp5r2x0jd5za9a8j0n7epgue3fff6vr2w4z..."
x-l402-price-sats: 10
content-type: application/json

{"error":"payment required","scope":"pow-gate:unlock","price_sats":10,
 "macaroon":"eyJ2IjoxLCJwaCI6...","invoice":"lnbc100n1p4gzx0rpp5r2x0jd5...",
 "payment_hash":"1a8cf93682e97a793e7ec851ccc5294e98353aa24008b8982ba728b26c2021af"}

Two things came back in that 402. A macaroon, which is a signed token that names what you are buying (scope: pow-gate:unlock) and when it expires. And a bolt11 invoice for 10 sats (that lnbc100n prefix is 100 nano-BTC, which is 10 sats).

The caller pays the invoice in any Lightning wallet, which yields a preimage, the payment receipt. Then they call the same endpoint again, this time presenting the macaroon and the preimage together:

curl -s -X POST https://gate.powforge.dev/l402/unlock \
  -H "Authorization: L402 <macaroon>:<preimage_hex>"

The server checks that the macaroon signature is valid and that the invoice is actually paid, then returns 200 with the same gated content the PoW path gives. One paid call, one unlock. The macaroon is single-use and guarded against replay, so a paid token cannot be shared around.

There is a discovery endpoint too, so an automated caller can learn the price and shape before it spends anything:

curl -s https://gate.powforge.dev/l402/info

{"service":"pow-gate","version":1,
 "endpoints":[{"path":"/l402/unlock","method":"POST","scope":"pow-gate:unlock",
 "price_sats":10,"auth":"L402 (RFC 7235 + Lightning)"}]}

An agent hits /l402/info, sees it costs 10 sats, decides that is fine, and pays. No human in the loop, no key exchanged ahead of time. That is the part that matters if your callers are increasingly software.

Why put both on the same endpoint

Because your callers are not all the same, and you do not know which is which up front.

A human poking at your API from a laptop has spare CPU and no Lightning wallet. Give them the compute path and they are through in a second, no wallet setup, no card.

An automated agent has a wallet and does not want to grind hashes on rented cloud CPU that bills by the second. Give it the L402 path and it pays a tenth of a cent and moves on.

A scraper trying to pull your whole dataset for free hits a wall either way. Ten thousand pulls is ten thousand PoW grinds or 100,000 sats. The economics that were invisible before are now sitting right on the endpoint, and they point the wrong way for anyone trying to free-ride.

You did not build a billing system. You did not build an auth server. You put a price on a URL and let the caller choose their currency.

Wiring it into your own service

The gate is a thin layer in front of whatever you are already serving. The shape is:

GET /api/challenge issues a nonce and remembers it briefly.
POST /api/solve checks the hash, and on success returns your real response.
POST /l402/unlock mints a macaroon and invoice on the first call, and on the paid retry checks the preimage and returns the same real response.

Swap the demo content for your actual endpoint payload and you have a paywalled API with two prices and zero accounts. The Lightning side needs a node or an LNBits instance to mint and check invoices. The PoW side needs nothing but the crypto library your runtime already ships.

Put a price on the door. Let them pay in sats or in sweat. The bots can afford neither at scale, and that was the whole problem.

Live server: https://gate.powforge.dev

Anonymous pastebins are a spam magnet. I gated mine with proof-of-work instead of logins.

Zeke — Sat, 15 Aug 2026 23:00:58 +0000

Open pastebin, no login, paste text, get a link. That is the whole appeal, and it is also why every anonymous paste service turns into a dumping ground. Bots script the post endpoint and fire off thousands of spam links, phishing kits, leaked credential lists, malware config. The usual fix is to make the thing less anonymous: force an account, bolt on reCAPTCHA, rate-limit by IP. Every one of those punishes the honest one-off user to slow down a bot that just rotates IPs anyway.

I wanted a paste service that stayed anonymous and one-click but still cost a spammer something real. So the price of posting is not an account. It is energy. You either burn a little CPU (proof of work, free) or you pay 10 sats over Lightning. A human posting one snippet never notices. A bot posting ten thousand notices real fast.

Here is the whole flow against the live service at paste.powforge.dev. Every curl below is real and runs today.

The free path: prove work

Grab a challenge first.

curl -s https://paste.powforge.dev/api/challenge
# {"nonce":"468367dc78bff5e696e23d9ac1684417eda7d4ecb1d02030a0209e37ee28f953","difficulty":18}

You get a random nonce and a difficulty in bits. The job is to find any string solution where SHA-256(nonce + solution) starts with difficulty leading zero bits. That is it. No fancy VDF, just a hash you cannot shortcut, only grind.

Here is a solver you can drop in a file and run with plain Node, no dependencies.

const crypto = require('crypto');

function hasLeadingZeroBits(buf, bits) {
  const fullBytes = Math.floor(bits / 8), rem = bits % 8;
  for (let i = 0; i < fullBytes; i++) if (buf[i] !== 0) return false;
  if (rem) {
    const mask = (0xff << (8 - rem)) & 0xff;
    if ((buf[fullBytes] & mask) !== 0) return false;
  }
  return true;
}

async function main() {
  const ch = await (await fetch('https://paste.powforge.dev/api/challenge')).json();
  let s = 0;
  while (true) {
    const h = crypto.createHash('sha256').update(ch.nonce + s).digest();
    if (hasLeadingZeroBits(h, ch.difficulty)) break;
    s++;
  }
  const solution = String(s);

  const res = await (await fetch('https://paste.powforge.dev/api/paste', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ content: 'hello from proof of work', method: 'pow', nonce: ch.nonce, solution })
  })).json();

  console.log('https://paste.powforge.dev/' + res.id);
}
main();

Difficulty 18 took me about 150,000 hashes and 1.8 seconds on one core. Nobody waiting on a paste cares about two seconds. A spammer scripting the endpoint pays that tax on every single post, in wall-clock time, with no way to buy their way around it except the honest one below.

Post it and you get an id back.

# POST /api/paste  { content, method:"pow", nonce, solution }
# -> {"id":"a06c33a7"}
curl -s https://paste.powforge.dev/a06c33a7
# ...
# ID: a06c33a7 | Method: Proof of Work | Expires: Sun, 16 Aug 2026 22:01:54 GMT

Proof-of-work pastes live 24 hours. Cheap to make, so they do not stick around forever.

The paid path: 10 sats, no CPU

Do not want to burn cycles? Pay instead. Same endpoint shape, you just ask for an invoice.

curl -s -X POST https://paste.powforge.dev/api/invoice \
  -H 'Content-Type: application/json' \
  -d '{"content":"paste that outlives the free tier"}'
# {"payment_hash":"acf00c5a...","bolt11":"lnbc100n1p4gpcwm..."}

Pay the bolt11 from any Lightning wallet, then poll until it clears.

curl -s https://paste.powforge.dev/api/check/acf00c5a...

Once paid the paste is created and kept for 30 days instead of 24 hours. The 10 sats is not the point, it is a fraction of a cent. The point is the same as the CPU: it is a real cost that scales with how much you post. One paste, you never feel it. A flood, and it adds up to actual money.

Why energy beats a login wall

Think about who each defense actually stops.

Accounts stop nobody. Bots make accounts faster than people do. All you did was add friction for the honest user.
CAPTCHA stops some bots and annoys every human, and the solving-farm market means a determined spammer just pays a fraction of a cent per solve.
IP rate limits stop a lazy bot from one address and do nothing to a botnet or a proxy pool.
Energy (PoW or sats) does not care who or where you are. It charges per post. It is the one cost a spammer cannot rotate their way out of, because it is not tied to identity at all.

That is the whole trick. Keep the service anonymous and one-click for the person posting one thing. Put a small, unavoidable, per-post cost in the way of the machine posting ten thousand. You do not need to know who anybody is. You just need posting to cost a little.

The service is live at paste.powforge.dev if you want to poke the endpoints yourself. Same pattern drops onto any write endpoint that bots abuse, not just pastes.

Bot timing has an entropy signature, and you can measure it on live Nostr data

Zeke — Sat, 15 Aug 2026 14:03:57 +0000

I have been poking at a question that sounds simple but turns out to have a real answer: can you tell a bot from a human just by when they post, ignoring everything they actually say?

Turns out you can, mostly. And you can measure it against live Nostr relays in an afternoon. Here is what I found, including the case where it falls apart.

The idea: gaps, not timestamps

A person does not post on a metronome. You fire off three notes in ten minutes, go quiet for six hours, come back, sleep, repeat. The gaps between your events are all over the place. A scheduled bot posts every N hours like clockwork, so its gaps are nearly identical every time.

So instead of looking at raw timestamps, I look at the sequence of inter-event gaps and ask how unpredictable that sequence is. That is just entropy.

The measurement is deliberately crude so it cannot be fudged:

Pull a pubkey's recent kind-1 notes (I used about 45 events each).
Compute the gap in seconds between each consecutive pair.
Bucket each gap by its log2 (so a 20-second gap and a 25-second gap land together, a 16-hour gap lands somewhere else).
Compute Shannon entropy over the bucket distribution, in bits.

Log2 bucketing matters. Without it you are measuring jitter noise. With it you are measuring how many orders of magnitude of timing behavior an account actually uses. A human uses several. A scheduled bot uses one or two.

All of this ran through nak against wss://nos.lol. No synthetic data, no simulated accounts. Real pubkeys, real notes.

The numbers

Humans. Two active human pubkeys came in at 4.13 bits and 3.60 bits of gap-entropy. Bursty, spread across many timescales, exactly what you would expect from someone living a life around their posting.

Bot A, the scheduled poster (253baa88...). This one runs a "Random Bitcoin Podcast Spotlight" template. All 45 of its notes I pulled shared an identical template prefix. Median gap around 16 hours, stretched over a 528-hour span. Its gap-entropy was 1.000 bits flat. It only ever used two log2 buckets. That is a machine on a timer.

Human-to-bot ratio there: 3.60x to 4.13x. My prediction going in was that humans would show more than 2x the timing entropy of bots. Against Bot A that holds cleanly, with room to spare.

Bot B, the burst spammer (72060890...). This is where it gets interesting. Bot B rotates product-ad templates (PIICloak, Certd, TLS pitches) and does not post on a slow schedule at all. It dumped 45 notes in about half an hour, median gap 21 seconds. Its gap-entropy was 2.036 bits.

Human-to-bot ratio there: 1.77x to 2.03x. That straddles my 2x line. It fails the test against the 3.60-bit human and just barely passes against the 4.13-bit one. A jittered burst pattern, even a dumb randomized-cadence one, produces enough timing variety to nearly clear the bar.

Aggregate: mean bot entropy 1.52 bits versus mean human 3.87 bits, a 2.55x ratio. So on average the prediction confirms. But the average hides the failure mode, and the failure mode is the whole point.

Where it breaks, and what to do about it

Timing entropy is a strong single signal against the enemy most people picture when they say "bot": the fixed-schedule poster. Those collapse toward 1 bit and light up immediately.

It is a weak signal against a burst spammer that randomizes its cadence. Bot B slipped to ~2 bits purely because posting 45 things in 30 minutes with 20-ish second jitter genuinely does spread across a couple of log2 buckets. Timing alone will not reliably catch that archetype.

But here is the thing. Both bots were trivially obvious on content. Bot A had 45 identical template prefixes. Bot B rotated a small pool of ad templates. The tell that timing missed on Bot B, content-template similarity caught instantly. Whereas for the scheduled Bot A, timing was the cleaner tell.

That is the actual lesson. These signals are complementary, not competing. Timing entropy is cheap, content-agnostic, and murders schedule bots. Template similarity is cheap and murders burst spammers. Pair them and the gap in either one gets covered by the other. Lean on timing alone and a jittered burster walks right through.

Why I care about this

I have been building depth-of-identity scoring over at identity.powforge.dev, the idea being that you can weigh how much verifiable behavior an account carries instead of asking it for credentials. Gap-entropy is one of the timing signals I am testing as an input to that. It is not the whole story, no single dimension is, but it is a real, measurable, un-spoofable-without-cost one, and I like signals I can pull off a live relay and check with my own eyes.

If you want to reproduce it: grab nak, pull ~45 kind-1 events for any pubkey, diff the timestamps, log2-bucket the gaps, take the Shannon entropy. A human will sit up around 3.5 to 4 bits. A thing on a timer will sit near 1. The distance between those two numbers is the bot.

Proving a proof-of-work solve happened, at a specific time, without trusting the server's logs

Zeke — Mon, 10 Aug 2026 03:01:24 +0000

The problem: a solve is a fact that only lives in one server's memory

If you gate a route with proof-of-work, every accepted solve is a real event. Someone burned real compute, at a real wall-clock moment, to get past the gate. That is exactly the property you wanted: the gate costs the caller something.

But where does that fact live? In the verifier's memory, for as long as the process stays up. The server knows a valid solve came in. Nobody else does, and nothing stops the server from claiming a solve happened that didn't, or forgetting one that did. If you ever need to prove "this specific solve happened before this point in time" to somebody who does not trust your logs, you have nothing. A row in your own database is not evidence to an adversary.

So the question is narrow and concrete: can you make an accepted PoW solve durable and independently auditable, without asking anyone to trust the server that recorded it?

The mechanism: Merkle-fold the window, anchor one root to Bitcoin

@powforge/solve-witness does one thing. Every accepted solve is reduced to a leaf hash and appended to the current batch. On a fixed cadence (default 10 minutes) the batch is sealed: the leaves are folded into a Merkle root, and that single 32-byte root is the witness_hash for that window. Submit the root to an OpenTimestamps calendar and the whole batch is anchored to Bitcoin with one timestamp.

The economics are the point. One Bitcoin timestamp attests to an unbounded number of solves, because the Merkle fold makes the on-chain cost O(1) regardless of how many solves landed in the window. A thousand solves and one solve cost the same to anchor.

Later, anyone can prove one specific solve was in the batch by presenting three things:

leaf  ->  Merkle inclusion path  ->  witness_hash (in the OTS proof, anchored to a Bitcoin block)

Every step recomputes with plain SHA-256, and the final OTS proof verifies against Bitcoin with the reference ots tooling, not against any PowForge server.

The leaf: what actually gets committed

A leaf has to commit to which challenge was solved, not just that some solve happened. The PowForge rate-limit layer identifies a solve by the challenge salt and the winning nonce, plus the server's HMAC signature over the salt. All three go into the leaf, domain-separated so a leaf hash can never collide with an internal Merkle node hash:

function leafForSolve({ salt, nonce, signature = '' }) {
  if (salt == null || nonce == null) {
    throw new TypeError('leafForSolve requires { salt, nonce }');
  }
  return sha256(Buffer.from(`leaf:${salt}:${nonce}:${signature}`, 'utf8'));
}

// internal nodes use a different prefix, so a leaf can never be
// reinterpreted as a node (or vice versa)
function nodeHash(left, right) {
  return sha256(Buffer.concat([Buffer.from('node:', 'utf8'), left, right]));
}

The Merkle core is deliberately pure and synchronous. Append, seal, root, inclusion proof, verify — no network, no heavy dependencies, fully unit-testable offline. The only networked piece, the OpenTimestamps calendar submission, lazy-loads javascript-opentimestamps so the core stays dependency-light and the network call is exercised by a live script, not by CI.

Wiring it into a live gate

The collector is the glue that decides when to seal, where to persist the proof, and how to be fed from a running server. It's on npm, so grab it and the rate-limiter it hangs off:

npm install @powforge/solve-witness @powforge/ratelimit

It drops straight onto the rate-limiter's onSolve hook:

const { createWitnessCollector } = require('@powforge/solve-witness/collector');
const { powRateLimit } = require('@powforge/ratelimit');

const witness = createWitnessCollector({
  logPath: '/srv/data/solve-witness-log.jsonl',
});
witness.start();                       // seal every 10 min in the background

app.use('/api', powRateLimit({
  difficulty: 20,
  onSolve: witness.onSolve,            // every verified solve gets witnessed
}));

Two design decisions matter because this sits on a request hot path. First, onSolve is synchronous and cannot throw into the request — a malformed solve is dropped and logged, never propagated to the caller. Second, sealing swaps in a fresh batch before the slow, networked OTS call, so solves arriving mid-stamp land in the next window and are never lost. The seal is also re-entrancy guarded, so a slow calendar submission can't overlap itself.

Does the whole chain actually hold together? Yes, end to end

The part I care about is not "the unit tests pass." It is: a real running service, a real solve, a real OTS proof. So there's a demo server that boots an Express app with the real middleware wired to the real collector, then drives itself:

An unauthenticated GET /api/protected returns a 429 with a PoW challenge.
A client grinds a real SHA-256 nonce until it clears the difficulty threshold.
It retries with the X-PoW-Proof header, the middleware verifies it, serves the route, and fires onSolve.
onSolve folds that exact solve into the live batch.
POST /admin/seal seals the window and submits the Merkle root to a real OpenTimestamps calendar.
The client rebuilds the leaf from its own (salt, nonce, signature) and verifies Merkle inclusion under the sealed witness_hash the OTS proof commits to.

On the last run that produced a genuine 665-byte .ots proof carrying pending calendar attestations — the real serialized OpenTimestamps format, not a stub. Once the calendars aggregate and the anchoring transaction confirms (hours, not seconds), upgradeProof() pulls the Bitcoin attestation and the proof tells you which block height attests to the root.

What this is not — yet

Update (2026-08-10): the hosted endpoint now exists. witness.powforge.dev serves a live, L402-gated /stamp route: POST a solve, pay a 100-sat Lightning invoice (or present a valid macaroon), and it folds into the current batch for anchoring. Verified end-to-end — an unpaid POST /stamp returns a real 402 with an L402 WWW-Authenticate challenge and a payable BOLT11 invoice (x-l402-price-sats: 100). So the "no payment flow, no sats price, no hosted endpoint" line below described the primitive stage in April; that gap is now closed. The mechanism the rest of this post argues for is unchanged.

This is infrastructure, and I want to be exact about where the line is.

What exists and is verified: the Merkle batch core, the onSolve wiring into the rate-limiter, live OTS calendar submission, and an end-to-end demo that produces a real proof. What does not exist: any customer-facing product around it. There is no payment flow, no sats price on witnessing, no hosted endpoint where you submit solves and get certificates back, no dashboard. The batch persists to a JSONL log and writes .ots proof files to disk. That is the whole surface today.

So this is not a finished service you can point users at. It is the primitive that a service would be built on. I am publishing it at the primitive stage on purpose, because the interesting claim is the mechanism — one Bitcoin timestamp making an arbitrary number of PoW solves independently provable — and that claim is either sound or it isn't, regardless of whether there's a checkout page in front of it.

If you wire it up and the inclusion proof verifies, or if it doesn't, I want to hear about it. The package is MIT. The OpenTimestamps proof format is an open standard and the calendars are run by the OpenTimestamps project and independent parties, not by me.

I counted every OP_RETURN on Bitcoin. A machine out-wrote all of human history 45 to 1.

Zeke — Wed, 22 Jul 2026 18:02:46 +0000

There's a romantic idea about Bitcoin's chain: that it's a wall of human messages. Proposals, memorials, "Vahe was here," pizza jokes, the occasional protest note pinned into the world's most expensive append-only log.

I wanted to know if that was actually true. So I counted. Every OP_RETURN output, from the genesis block to block 958,893, no sampling.

The answer is no, and it's not close.

The one number

All human-readable OP_RETURN text ever mined into Bitcoin: 3,827,227 outputs.

Runes, one token protocol, in its own era: 171,114,058 OP_RETURN outputs.

That's a ratio of 44.7 to 1. One machine protocol, in a single two-year stretch, wrote about 45 times more to the chain than every human-readable message in Bitcoin's entire history combined.

The evidence, per era

I split the chain into four eras by block height, not by any label stored in my database. Height boundaries are canonical and anyone can check them against a node, so the result doesn't depend on trusting my extractor's tags.

era	height range	boundary event
pre-ordinals	0 – 767,429	before the first inscription
ordinals	767,430 – 779,831	inscription #0 to BRC-20 deploy
boom-brc20	779,832 – 839,999	BRC-20 `ordi` deploy to Runes
runes	840,000 – 958,893	Runes launch at the halving

Then I counted the full population of OP_RETURN outputs in each era. Human-readable text, Runes token messages, and binary blobs (Veriblock and OMNI proof-of-proof timestamping, mostly).

era	total OP_RETURN	human text	human %	Runes	Runes %	binary	binary %
pre-ordinals	51,965,944	861,532	1.66%	7	0.00%	51,103,723	98.34%
ordinals	261,767	32,189	12.30%	3	0.00%	229,544	87.69%
boom-brc20	2,980,954	402,161	13.49%	40,251	1.35%	2,538,248	85.15%
runes	177,474,762	2,531,345	1.43%	171,114,058	96.42%	3,828,604	2.16%

Here's the honest twist

When I started, I expected to find a fall. A golden human era that machines later ate. That's the clean story, and it's wrong.

Look at the human % column again. Human text was never the majority of OP_RETURN. Not once. Even at its absolute peak, the boom-brc20 era, human-readable messages were only 13.5% of data outputs. The chain was machine-dominated in every single era.

What changed isn't who's in charge. Machines always were. What changed is the flavor of machine, and the scale.

Before ordinals, 98.3% of OP_RETURN was binary timestamping. Veriblock and OMNI stuffing proof-of-proof blobs into the chain. Not prose, not tokens, just machine-to-machine attestation data. Then Runes launched at the 2024 halving and took the throne. In the runes era, 96.4% of every OP_RETURN output is a Runestone.

And the volume went vertical. The runes era alone, about 119,000 blocks, holds 177.5M OP_RETURN outputs. That's more than 3x the entire prior 767,000-block history put together, which came to roughly 55.2M. Discretionary write demand didn't grow. It exploded, and Runes is basically all of it.

So if you want the real headline, it's not "humans got pushed out." It's this: Bitcoin's data-carrier space was always bought by machines, and the marginal buyer today is a machine minting a token, not a person leaving a note.

How I checked it against a node

A database can lie. So I cross-checked both sides against a real Bitcoin node with txindex on.

Human side, is it real prose? I pulled one row the census flagged as human text: a vout at height 840,000 that decoded to "Vahe was here." Ran getrawtransaction on it. The node returned a nulldata output with asm OP_RETURN 56616865207761732068657265, and that hex decodes exactly to Vahe was here. Real human message, confirmed by the node, not misclassified protocol junk.

Machine side, are those really Runestones? I pulled block 840,000, the Runes launch block itself, with getblock(840000, 3). It has 3,050 transactions and 2,033 OP_RETURN outputs. Of those, 2,004 (98.6%) begin with OP_RETURN OP_13, which is the Runestone magic. At the very first block of the era, roughly 99% of OP_RETURN outputs were already token protocol. That's an independent confirmation my Runes classification isn't inflated.

The falsifier

I'll tell you exactly what would break this claim, because a finding you can't falsify isn't worth much.

The machine-dominance claim fails if either:

A byte-level recount of the 171.1M Runes outputs shows more than 20% are non-Runestone or human-readable, or
My 3.83M human-text count undercounts real human OP_RETURN prose by more than 10x, enough to pull the 45:1 ratio down below about 4:1.

Both are testable against a node. The block-840,000 spot check already pushed on condition 1 and it held at 98.6%.

Limitations, because they matter

I deliberately left witness inscriptions out of the headline. The witness content-type population is dominated by text/plain at 111.0M items, but that MIME bucket mixes genuine prose with BRC-20 mint JSON, since BRC-20 mints get served as text/plain too. Splitting that cleanly needs a prose classifier I don't fully trust yet, so any human-vs-machine witness ratio would be soft. The OP_RETURN lead needs no such caveat, because Runes is a distinct opcode-tagged protocol you can verify per output. And folding BRC-20's 111M onto the machine side would only make the thesis stronger, so leaving it out is the conservative call.

A couple of smaller notes. The 40,251 Runes-tagged outputs in the boom era, before the official launch, are OP_13 pushes the detector caught early. Test and edge cases, immaterial to the ratio. And the era boundaries are height-based approximations of the real protocol-launch blocks. A shift of a few hundred blocks either way doesn't move any percentage that matters.

Why I built this

This is one exhibit out of a full four-channel census of what Bitcoin actually stores. OP_RETURN, witness inscriptions, coinbase tags, and datasets, all mined gap-free to the chain tip and cross-checked against a node. The angle is proof-of-work primitives and on-chain data, treating blockspace as the scarce, PoW-secured resource it is and asking who's actually spending it.

The live chart with the per-era breakdown is here:
https://powforge.dev/museum/charts/human-vs-machine.html

The rest of the museum is here:
https://powforge.dev/museum/

If you want to poke at the falsifier, grab a node with txindex on and start with block 840,000. That's where the flood begins.

I tried four ways to gate my MCP server. Only one didn't need a Stripe account.

Zeke — Mon, 01 Jun 2026 20:51:03 +0000

Your MCP server is getting hammered by agents you didn't authorize. A free tier is open to the world. A premium tool is one runaway loop away from torching your LLM budget. You need a gate.

So I went shopping. Four projects ship something that calls itself an MCP gate today. I wired each one against a test server, ran a handful of tool calls through it, and wrote down what hurt.

Here's the honest comparison.

PayGated (paygated.dev)

This is the closest thing captcha-mcp has to a named competitor. PayGated wraps MCP tools with a Stripe-backed payment gate. Self-hosted, MIT-licensed, "no monthly SaaS bills." It's a clean piece of work.

The catch is Stripe itself. To accept payment, you need a Stripe account in good standing, which means KYC, a bank, and a country Stripe operates in. Your callers need a Stripe customer record too, so every agent identity needs an email and a card on file before it can pay you a dime.

PayGated does OAuth 2.1 + PKCE for the auth half and machine-to-machine flow for headless agents. That works if your callers can hold an API key. It's also the only one in this list with a real revenue model out of the box if you're already inside the Stripe ecosystem.

Good fit: US-based MCP devs whose callers are corporate agents with billing relationships.
Bad fit: anonymous agents, weekend-project monetization, anyone outside Stripe's footprint.

APort (aport.io)

APort isn't really a gate. It sits in front of the gate. The pitch is "verifiable credentials for AI agents" using W3C VC standards. An agent presents a passport, APort checks the signature against a registry, your MCP server reads the verification result from a pre-tool hook and decides whether to run the tool.

That's a different layer of the stack. APort answers "who is this agent." It doesn't answer "did they pay" or "should I rate-limit them." You'd compose APort with something else that does the metering.

This is less a competitor and more a partnership shape. If you're already paying per call with captcha-mcp, APort's audit log could record who paid for what under whose authority. Worth a look if your buyers care about provenance more than monetization.

Good fit: enterprise contexts where auditors will ask which agent did what.
Bad fit: you just want to stop abuse and don't have a passport infrastructure problem yet.

AgentSign (agentsign.dev)

AgentSign is the Ed25519-passport flavor of the same identity layer. Every agent gets a signed identity document. The server verifies the signature, looks up a trust score, gates the tool on that score. Clean cryptographically, but again, it's identity not metering.

There's no payment rail and no abuse-prevention mechanism if a signed agent decides to hammer your endpoint legitimately. The trust score is the only knob. That's a different product than "charge me 10 sats and let me through."

I'd use it if I were building a multi-agent system and needed a who-signed-this layer. I would not use it to stop a runaway loop.

Good fit: multi-agent systems with reputation tracking.
Bad fit: rate-limiting, micropayments, anything where you want the abuser to pay the cost of abuse.

captcha-mcp (the one I'm shipping)

This is the project I work on, so call this biased. The pitch: gate any MCP tool with proof-of-work for free callers and a 10-sat Lightning invoice for callers who want to skip the CPU work. No Stripe account on either side. No KYC. No user database.

const { PayMCP } = require('paymcp');
const { CaptchaPowProvider } = require('@powforge/captcha-paymcp-provider');
const { LnbitsPaymentProvider } = require('@powforge/paymcp-l402-provider');

PayMCP(mcp, {
  providers: [
    new CaptchaPowProvider({ captchaUrl: 'https://captcha.powforge.dev' }),
    new LnbitsPaymentProvider({ lnbitsUrl: process.env.LNBITS_URL, lnbitsApiKey: process.env.LNBITS_KEY, satsAmount: 10 }),
  ],
});

Tag a tool with { _meta: { price: 1 } } and it's gated. PoW path grinds a SHA-256 challenge in a few seconds of CPU. Lightning path mints a BOLT11 invoice and waits for the preimage. The calling agent picks whichever it can satisfy.

The reason I built it this way: Stripe's KYC wall is fine for US SaaS but it kills the long tail. A solo dev in any country can spin up an LNBits wallet in a minute and start collecting sats. An agent author can fund a Lightning wallet with $1 and make 10,000 calls. Nobody's filling out a W-9.

Good fit: anonymous agents, public APIs, micropayment-per-call, anyone outside Stripe's footprint.
Bad fit: enterprise customers who want a credit card receipt, high-throughput callers who can't afford the PoW seconds.

The decision

If your callers are corporate agents with billing relationships, PayGated. If they're anonymous and you want to monetize the long tail without paperwork, captcha-mcp. If your problem is "who is this agent" and not "did they pay," APort or AgentSign sit at a different layer and you'll probably end up running one of them next to a payment gate, not instead of one.

I picked PoW plus Lightning because it's the only path I've seen that works for a developer in Argentina, a research bot in a CI pipeline, and a side-project MCP server that doesn't want a Stripe account. Your tradeoffs may land you somewhere else. Just know which gate you're picking and why.

@powforge/captcha-mcp on npm: https://www.npmjs.com/package/@powforge/captcha-mcp
Hosted captcha server: https://captcha.powforge.dev

Why block hashes are dangerous for DLC randomness (and the fix)

Zeke — Mon, 01 Jun 2026 13:52:46 +0000

A DLC (Discreet Log Contract) is only as fair as its randomness source. If you're using a Bitcoin block hash as your oracle input for anything with money on it, you've got a miner front-running problem that won't care how tight the rest of your contract is.

This ain't theoretical. PancakeSwap lost $1.8M in 2021 to an attack that precomputed the block hash used as a random seed (SWC-120). DeFi, but the same class of attack applies to any protocol where the person producing the "randomness" can see the downstream payoff first.

Block hashes are predictable to miners.

Why block hashes fail for DLCs specifically

Here's the attack in plain terms:

A DLC has two outcomes: Alice wins if the coin lands heads, Bob wins tails. The oracle will sign "heads" or "tails" based on the block hash at time T.
A miner with enough hashrate can, before publishing a block, check: does this hash make me money (if I'm a counterparty) or does it favor the other side? If it favors the other side, they can try again: mine another nonce, or selectively withhold.
Even without being a counterparty, miners can be bribed to produce favorable hashes, or simply front-run if the DLC outcome is observable on-chain before the block is confirmed.

Block hashes work fine for non-adversarial randomness. They're terrible for anything adversarial where the miner has a stake.

The professional gambling industry learned this. Stake.com publishes "public seeding events" that mix a future block hash with additional entropy they commit to in advance. They separate who knows what from who controls what. That's the pattern.

What a verifiable beacon provides instead

A proper randomness beacon closes the attack surface by:

Collecting entropy from multiple independent contributors before the result is computed
Computing the result only after contributions are frozen (end of epoch)
Signing the result with a Schnorr key so you can verify it offline
Providing a payment receipt (L402 macaroon + preimage) that ties your specific fetch to a specific epoch

That last point matters for DLCs. A DLC contract can reference the oracle's pubkey and the epoch ID in the announcement. When the epoch closes, the signed beacon is the attestation. Any counterparty can verify it independently with the oracle pubkey.

The PowForge draw beacon

The /draw endpoint at attest.powforge.dev does exactly this for Bitcoin. Every 5-minute epoch:

Contributors submit SHA-256 proof-of-work entropy (free)
Oracle aggregates deterministically: sha256("DRAW" || epoch_id || sha256(epoch_id || sorted_contribution_hashes))
Oracle signs with BIP-340 Schnorr and seals the epoch
Result is fixed forever and publicly verifiable

The Schnorr format is the same family used by DLC oracle specs (dlcspecs/Oracle.md). You're not adding a new trust assumption. You're delegating randomness to a PoW-seeded ceremony that's independent of the miner who eventually mines your settlement block.

Fetching a sealed beacon costs 50 sats via L402:

# Trigger the 402 to get the invoice
curl -si https://attest.powforge.dev/api/v1/draw/EPOCH_ID

# Pay the 50-sat Lightning invoice, get a preimage
# Then fetch with the credential
curl -s https://attest.powforge.dev/api/v1/draw/EPOCH_ID \
  -H "Authorization: L402 <macaroon>:<preimage>"

Response:

{
  "epoch_id": 5934397,
  "contribution_count": 2,
  "oracle_pubkey": "2bc78390c94d8bbb96ac3e6940462ba2812418d871e701c1a845fdb1dfd4a0e5",
  "attestation": {
    "beacon_random": "62eb805f...32 bytes hex...",
    "signature": "f2925b93...64 bytes hex...",
    "oracle_pubkey": "2bc78390c94d8bbb96ac3e6940462ba2812418d871e701c1a845fdb1dfd4a0e5"
  }
}

Verify offline (oracle_pubkey is x-only, 32 bytes, no prefix):

const crypto = require('crypto');
const { schnorr } = require('@noble/curves/secp256k1');

// The oracle signs taggedHash("DLC/oracle/attestation/v0", beacon_bytes)
// not the raw beacon bytes directly. BIP-340 §3.2 tagged hash construction.
function taggedHash(tag, msg) {
  const tagHash = crypto.createHash('sha256').update(tag).digest();
  return crypto.createHash('sha256').update(tagHash).update(tagHash).update(msg).digest();
}

const { attestation } = result;
const beaconBytes = Buffer.from(attestation.beacon_random, 'hex');
const msgHash = taggedHash('DLC/oracle/attestation/v0', beaconBytes);
const sig = Buffer.from(attestation.signature, 'hex');
const pubkey = Buffer.from(attestation.oracle_pubkey, 'hex'); // already x-only
const valid = schnorr.verify(sig, msgHash, pubkey);

Using the beacon as a DLC oracle input

In a dlcspecs-compliant DLC:

Pick the epoch ID for your event close time (5-minute windows, Math.floor(Date.now() / 300000))
Include the oracle pubkey and epoch ID in your DLC announcement as the "event descriptor"
At settlement, fetch the sealed beacon and use attestation.beacon_random as the outcome scalar input
Verify the Schnorr signature before settling (attestation.signature against attestation.oracle_pubkey)

The oracle pubkey is stable and published at attest.powforge.dev. The beacon is seeded by contributors independent of both counterparties and miners. Nobody controls the output.

If you're building DLCs and randomness is part of your oracle design, the block hash pattern has a known attack class. There's a Bitcoin-native alternative that costs 50 sats per event and verifies with any secp256k1 library.

Endpoint: https://attest.powforge.dev/api/v1/draw/{epoch_id}
Landing: https://powforge.dev/draw/

Return a 402 instead of a 429 from your MCP server

Zeke — Sun, 31 May 2026 20:01:16 +0000

Last week I was reading through sentry-mcp issue #844 and watched a guy describe exactly the pain I keep running into. He had Cursor running parallel automation against the Sentry MCP, saturated the 60-request-per-minute bucket in seconds, and got back a 429 with no Retry-After header. His agent just sat there. No backoff hint, no escape path, nothing to do but fail the run and ask a human to babysit it.

That same week awslabs/mcp #2949 popped up where the MCP handshake itself was failing because tools/list was tripping a 429 on the second call. And GLips/Figma-Context-MCP #258 had folks convinced the MCP was broken when really their parallel calls were just blowing through Figma's per-token limit on shared credentials.

Same shape every time. The server says "no" in a way the agent cannot use.

Why 429 is the wrong answer for agents

The 429 status was designed for humans behind browsers. Retry-After: 60 works fine if a person can read a banner that says "try again in a minute." It does not work when you have an autonomous agent that needs to decide right now whether to wait, retry, escalate, or pay.

Most MCP servers do not even send Retry-After. The agent gets a 429 body, maybe some JSON, and zero machine-readable information about what would let it succeed. So it does the dumb thing. It retries immediately. Or worse, it gives up and the whole tool chain breaks.

There is no payment path. There is no proof-of-work path. There is no "I will do something to earn the right to call you" path. Just a closed door.

What 402 looks like on the wire

HTTP 402 Payment Required has been sitting in the spec since 1997 waiting for someone to use it. With agents, it finally has a real job.

A useful 402 response gives the caller a challenge it can solve programmatically. Two flavors:

HTTP/1.1 402 Payment Required
Content-Type: application/json
WWW-Authenticate: PowChallenge realm="api", id="abc123", salt="...", difficulty=14

{
  "type": "pow",
  "id": "abc123",
  "salt": "9f3c...",
  "difficulty": 14,
  "signature": "..."
}

Or for paid access:

HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 macaroon="...", invoice="lnbc30n1p..."

Both are deterministic. The agent reads the challenge, does the work (CPU cycles or a Lightning payment), submits the answer, and gets a token. No human in the loop. No guessing at backoff intervals. The server told the agent exactly what to do.

Wrapping an existing MCP server

@powforge/captcha-mcp is one way to do this without writing the crypto yourself. It exposes three tools: challenge, verify, and status. The package wraps captcha.powforge.dev as the backend so you do not have to host the puzzle service.

Drop it into your Claude Code or Cursor config:

{
  "mcpServers": {
    "powforge-captcha": {
      "command": "npx",
      "args": ["-y", "@powforge/captcha-mcp"]
    }
  }
}

Then on your own backend, when a caller hits a rate-limited endpoint, return a 402 pointing at the verify path. After the agent solves the puzzle and gets a token, your backend checks it:

curl -X POST https://captcha.powforge.dev/api/token/verify \
  -H "Content-Type: application/json" \
  -d '{"token":"<token-from-verify-tool>"}'

Token good, request goes through. Token bad or expired, you 402 them again with a fresh challenge.

What the agent sees

From the agent's point of view the loop is short:

Call the tool. Get back a 402 with a challenge.
Call the challenge tool to get a fresh puzzle (or use the one from the 402 directly).
Burn 5 to 10 seconds of CPU finding a nonce that produces a SHA-256 hash with 14 leading zero bits.
Call verify with the nonce. Get back a 5-minute HMAC-signed access token.
Retry the original call with the token. Get the real response.

The agent never had to ask a human. It never had to guess at a retry interval. It paid for access in CPU cycles and got through.

PoW or Lightning

Pick based on who is calling. PoW (free tier, SHA-256, around 5 to 10 seconds of CPU at 14 leading zero bits) works great for sporadic agents, exploration runs, and free-tier users. The cost is real but small, and it scales with how much the caller wants the resource.

L402 over Lightning (paid tier, 3 sats per call by default) makes more sense for high-volume callers who would rather pay cash than burn CPU. Most agent operators will happily drop a few sats to skip the puzzle.

You can offer both from the same endpoint. The 402 response tells the agent what is available, and the agent picks based on its own constraints.

Try it

npx -y @powforge/captcha-mcp

Package and docs: https://www.npmjs.com/package/@powforge/captcha-mcp

If you maintain an MCP server that is currently returning 429s, swap the response for a 402 with a real challenge. Your agent callers will thank you by actually completing their runs instead of hanging on a wait header they cannot read.

Three ways to gate an MCP server: OAuth, L402, and proof-of-work

Zeke — Sun, 31 May 2026 02:39:09 +0000

Somebody at Sentry filed a bug last month: Cursor Automations started hitting rate-limit errors almost immediately after authenticating. The bucket was sized for humans — 60 requests per 60 seconds — and an agent tore through it in seconds.

That's the MCP auth problem in miniature. You've got a server exposing tools. Agents call those tools. You want to slow down abuse, charge per call, or just make sure you don't blow up your LLM budget on some runaway loop. How do you do that without wiring up a full OAuth stack that breaks the first time an agent doesn't have a browser to open?

Three real options exist right now. Here's how they compare.

Option 1: OAuth 2.1 (the spec says so)

The MCP spec mandates OAuth 2.1 for authorization. If you're building a production server for enterprise customers — actual humans with accounts — this is the right call. You get scoped access, token revocation, audit trails. SSO works. Compliance teams stop emailing you.

The problem is agents. OAuth 2.1 has an authorization code flow that requires a redirect URI. An agent running headless doesn't have a browser. DPoP and Workload Identity Federation are on the MCP roadmap but not shipped yet. If you need auth today and your callers are mostly agents, OAuth puts you in a hole.

Good fit: enterprise SaaS, human-driven clients, compliance-heavy contexts.
Bad fit: anonymous agents, public APIs, pay-per-call services.

Option 2: L402 Lightning payments

L402 is an HTTP extension where a server responds to an unauthorized request with 402 Payment Required and an invoice in the WWW-Authenticate header. The client pays it over Lightning and retries with the preimage as a credential.

Two npm packages ship L402 for MCP right now: lightning-wallet-mcp and l402-kit-mcp. The model is clean: each tool call costs a fixed number of sats. No accounts, no sessions, no user. An agent with a Lightning wallet (Alby, Phoenixd, NWC) can handle the whole flow programmatically.

# First call — server responds with 402
curl -X POST https://your-mcp-server/tools/call \
  -H "Content-Type: application/json" \
  -d '{"name": "expensive_tool", "arguments": {}}'
# HTTP/1.1 402 Payment Required
# WWW-Authenticate: L402 invoice="lnbc...", macaroon="..."

# Pay the invoice over Lightning, get the preimage
# Retry with credentials
curl -X POST https://your-mcp-server/tools/call \
  -H "Authorization: L402 <macaroon>:<preimage>" \
  -H "Content-Type: application/json" \
  -d '{"name": "expensive_tool", "arguments": {}}'
# HTTP/1.1 200 OK

Good fit: agents with Lightning wallets, micropayment-per-call APIs, Bitcoin-native monetization.
Bad fit: agents without wallets, free tiers, contexts where payment friction kills adoption.

Option 3: Proof-of-work

PoW is the weird one. Instead of paying money, the caller burns CPU to solve a hashcash-style puzzle. The server sets a difficulty. The caller grinds until they find a nonce. No wallet required.

# Get a challenge
curl https://your-mcp-server/api/challenge
# {"challenge": "abc123", "difficulty": 4, "algorithm": "sha256"}

# Solve it
npx @powforge/captcha solve --challenge abc123 --difficulty 4
# {"nonce": "7f3a...", "solution": "0000..."}

# Submit with solution in header
curl -X POST https://your-mcp-server/tools/call \
  -H "X-PoW-Solution: challenge=abc123,nonce=7f3a..." \
  -H "Content-Type: application/json" \
  -d '{"name": "tool", "arguments": {}}'

The cost scales with difficulty. A legitimate caller solving once is fine. An abuser trying to hammer 10,000 calls hits a wall because each requires fresh compute. No central authority. No wallet. No redirect.

@powforge/captcha-mcp ships this as middleware for existing MCP servers. Wrap your server, set a difficulty, and callers solve before tool calls go through. It also supports L402 as an escape valve: pay sats instead of grinding if you'd rather not burn CPU.

This is also a 429 fix. Instead of returning 429 Too Many Requests with no recovery path, the server hands the agent a puzzle — a machine-readable backoff signal an autonomous agent can satisfy without a human, an account, or a Retry-After header that means nothing to code running in a loop.

Good fit: anonymous agents, public APIs, abuse prevention without monetization, PoW-or-pay dual rail.
Bad fit: high-throughput legitimate callers (CPU cost adds latency), real-time tools where every millisecond counts.

The comparison

	OAuth 2.1	L402 Lightning	Proof-of-Work
Requires user account	Yes	No	No
Requires Lightning wallet	No	Yes	No
Works headless today	Partial	Yes	Yes
Revenue per call	No	Yes (sats)	No
Stateless	No	Yes	Yes

An Astrix Security study this year found 88% of MCP servers require credentials of some kind but document almost none of it. The OpenClaw scan found 42,000+ unauthenticated MCP instances publicly exposed in January 2026. Most of those aren't enterprise installs — they're side projects and weekend builds.

For that crowd, OAuth is overkill. L402 is elegant if the caller has a wallet. PoW gives you friction without a wallet requirement — callers can always get through, they just can't do it for free at scale.

The decision tree

Building for enterprise with human users? OAuth 2.1. The spec points here and compliance teams need it.
Monetizing per tool call, callers have Lightning wallets? L402. Clean, stateless, Bitcoin-native.
Public API, anonymous agents, no accounts? PoW — or PoW with L402 escape valve.
Unsure? Start with PoW for the free tier and L402 for a paid tier. Add OAuth when an enterprise customer asks for it.

The Sentry rate-limit bug is fixable with any of these. But if you're building for agents first, OAuth is the last thing you reach for — not the first.

@powforge/captcha-mcp (PoW + L402 middleware): https://www.npmjs.com/package/@powforge/captcha-mcp
@powforge/captcha (standalone solver): https://www.npmjs.com/package/@powforge/captcha
Sentry MCP issue #844: https://github.com/getsentry/sentry-mcp/issues/844

A verifiable Bitcoin randomness beacon, 50 sats per draw

Zeke — Sat, 30 May 2026 23:55:29 +0000

Randomness is one of those things you don't think about until you need to trust it. And then you think about it a lot.

Pick a lottery, a game seed, a sampling job, a DLC oracle input. Anything where the output has money or fairness riding on it. The usual options ain't great. A single server tells you "trust me, this was random." A blockchain hash is only random after the block is mined, and the miner can see your bet before they publish. A VRF binds the output to one key holder, which is a single point of trust by another name.

What you actually want is a draw where nobody can predict the result before it closes, nobody can change it after, and anybody can verify it offline. That's what the PowForge /draw beacon does. Multi-party entropy, Schnorr-signed, 50 sats per fetch.

How an epoch works

Time is sliced into 5-minute windows. The current epoch ID is just:

const epoch_id = Math.floor(Date.now() / (300 * 1000));

During an epoch, anyone can contribute. You solve a small SHA-256 proof-of-work challenge (18 bits, takes a second on a laptop) and POST your contribution. It costs nothing and your x-only Schnorr pubkey gets bound into the contribution hash, so you can prove your entropy was included.

When the window closes and at least 5 unique contributors have submitted, the oracle aggregates everything deterministically. The beacon formula is public:

sha256("DRAW" || epoch_id || sha256(epoch_id || sorted_contribution_hashes_concat))

Sorted concatenation matters. It means the order contributors arrive doesn't change the output, but a single byte from any one of them shifts the whole 32-byte beacon. The oracle then signs the beacon with a BIP-340 Schnorr key and seals the epoch. After that, the result is fixed forever and nobody, including the oracle, can change it.

Try it from curl

Contributing requires mining the PoW, so the curl path for that one's easier with the npm client below. Reading a sealed beacon is straight L402:

# Step 1: request the beacon, oracle returns 402 + a Lightning invoice
curl -si https://attest.powforge.dev/api/v1/draw/5933907

# HTTP/1.1 402 Payment Required
# WWW-Authenticate: L402 invoice="lnbc500...", macaroon="AgE..."

# Step 2: pay the invoice with any Lightning wallet (50 sats)
# you receive a payment preimage, 32 bytes hex

# Step 3: retry with the macaroon and preimage
curl -s https://attest.powforge.dev/api/v1/draw/5933907 \
  -H "Authorization: L402 <macaroon>:<preimage>"

The response gives you beacon_random (the 32-byte entropy) and signature (BIP-340 Schnorr). Verify it against the oracle pubkey and you're done.

npm client

There's a thin client that handles the PoW mining and L402 dance for you:

npm install @powforge/attest-client

const { AttestClient } = require('@powforge/attest-client');
const client = new AttestClient();

// Contribute entropy to the current epoch (free, mines PoW automatically)
const contrib = await client.contributeDrawEntropy(
  'your64hexschnorrpubkeyhere...'  // your x-only Schnorr pubkey
);
console.log('contributed to epoch:', contrib.epoch_id);

// Fetch the sealed beacon for a closed epoch (pays 50 sats via L402)
const beacon = await client.getDrawBeacon(contrib.epoch_id, l402Token);
console.log('beacon_random:', beacon.beacon_random);
console.log('signature:    ', beacon.signature);

That's the whole API surface. Contribute is free, fetch costs 50 sats and gives you a signed value any Bitcoin-native verifier can check.

Why you can trust the output

Three properties carry the whole thing:

Multi-party by construction. The oracle can't produce a beacon alone. Each epoch needs at least 5 independent contributions, and any one contributor can shift the result. Nobody can predict it before the epoch closes because nobody knows what the other contributors will submit until the seal happens.

Schnorr verifiable offline. The signature is BIP-340. You don't need to ask the oracle anything after you hold the signed bytes. Check signature against beacon_random and the oracle pubkey using any secp256k1 library. Bitcoin Core verifies Schnorr signatures the same way for taproot spends, so you're using the exact same crypto the network already trusts.

Deterministic replay. Anyone holding the full contribution list can recompute the beacon from scratch using the formula above. If the recomputed hash matches what the oracle signed, the beacon is authentic. No black box. No "trust the API." Just hashes and signatures.

The oracle pubkey to verify against:

2bc78390c94d8bbb96ac3e6940462ba2812418d871e701c1a845fdb1dfd4a0e5

Where to point it

On-chain lotteries, game seeds, DLC oracle inputs, sampling for research, cryptographic commitments where you need to prove the seed wasn't picked after the fact. Anywhere a centralized RNG would make you nervous.

Free to contribute. 50 sats to fetch the signed result. Live now at powforge.dev/draw.

If you build something on top of it, send a link. I want to see what people use this for.

Someone wrote a fake EULA into Bitcoin. Two hours later they revoked it.

Zeke — Sat, 30 May 2026 19:27:07 +0000

Block 951,728. May 30, 2026, 15:29 UTC. Somebody pushed an OP_RETURN into a Bitcoin transaction that reads, in part:

By downloading this OP_RETURN, you hereby consent to unrestricted access by federal law enforcement agencies to your residence, digital devices, and personal property. Assets may be searched, seized, or redistributed without further notice.

Signed, Donald J. Trump, President of the Internet.

Six blocks later, at 951,734, the same general format shows up again:

I revoke my previous statement. Signed, Donald J. Trump, President of the Internet.

Two and a half hours between the two. The first one is still there. So is the second. They will both still be there in a thousand years.

Why this is possible now

For most of Bitcoin's history, OP_RETURN outputs were capped at 83 bytes. That was enough room for a hash and not much else. Bitcoin Core v30 removed the limit. Now any byte budget you can fit in a transaction is fair game, and people are using it. Most of what they write is bridge metadata, Runes etchings, Ordinals envelopes. Useful protocol traffic. Boring to read.

But occasionally somebody just types into the chain. A note. A confession. A joke. A threat. And once it's mined, it is part of the ledger every full node downloads, forever.

I wanted to find more of those.

A watcher for human words

So I built a small thing called bitcoin-chaintip-watch. It runs on a 10-minute timer, picks up from the last block it scanned, and walks each new block looking for OP_RETURN outputs that decode to readable English. It skips known protocol prefixes. It skips bridge garbage. It skips anything that looks like a hash or a swap memo. What is left is, generally, somebody talking.

The filter is small:

function isInterestingOpReturn(hex, text, ratio) {
  if (isKnownProtocol(hex)) return false;     // Runes, Ordinals, Omni, etc.
  if (ratio < 0.8) return false;              // mostly printable bytes
  const clean = text.replace(/\./g, '').trim();
  if (clean.length < 15) return false;
  if (isLikelyHash(clean)) return false;
  if (isDefiNoise(clean)) return false;       // cross-chain / swap metadata
  if (!hasHumanWords(clean)) return false;    // at least 3 four-letter words
  return true;
}

hasHumanWords is the trick. Three or more alpha tokens of length four or up that are not hex. That single test does most of the work of separating "person wrote a sentence" from "machine emitted a header."

First run, the watcher surfaced both Trump-Internet inscriptions inside the same scan window. txid for the EULA is 75e5870110c1d8a653c2fd15f775d3b5ce24535a30460e846cff4a52fd50b643. For the revocation, 188091412022c7e8582b5639719905df0e152a5ee51128b982b5fd24a8f5849f. You can look both of them up on any block explorer.

The joke and the joke under the joke

The top-layer joke is the EULA itself. It is doing the bit where end-user license agreements are absurd contracts that nobody reads, and treating that absurdity as if it has the force of law. By looking at the bytes you have already agreed. Opt out requires a notarized statement, on chain, in a future block. The signature line is presidential.

The joke under the joke is the medium. Bitcoin OP_RETURN outputs are by design provably unspendable. They exist only as messages. Somebody took that property and turned it into a legal-document format that activates the moment your node validates the block. To rescind it, you have to spend real fees and write a revocation into another block. Which is what happened. Two and a half hours later, the author posted a one-line retraction in the same voice.

The revocation costs more than the original. Bitcoin does not have an edit button. It does not have a delete button. It has only "write another thing later." If you change your mind about a permanent record, the only correction is more permanent record. That asymmetry is the design. The author of these two inscriptions just used the design as a punchline.

Why this matters past the gag

Bitcoin is the only public medium where you can publish something that cannot be taken down by anybody, including yourself. That is a strange property to have running globally on consumer hardware. Most of what gets inscribed is throwaway. Some of it is not. Iowa caucus precinct results from 2016 are in there. A SegWit activation block carries both a Conio celebration and a death threat against a sitting US president. Now a fake-EULA satire is in there, plus the author's regret about it, six blocks apart.

It is the only confessional booth with no priest and no eraser.

The watcher does not interpret any of this. It just lifts the human-readable lines out of the noise and writes them to a JSON file. A person decides what is worth keeping. The Trump-Internet pair was worth keeping. It is now in the Bitcoin Museum collection alongside the SegWit-block threat, the 2016 election oracle, and the rest of the inscriptions that show what people actually do when handed a permanent megaphone with no off switch.

See the artifacts

The EULA and the revocation live at powforge.dev/museum, with verifier links to mempool.space for both transactions. The full collection is around 550 artifacts and growing as the watcher keeps running.

If you want to point a similar tool at your own bitcoin node, the filter shown above is the whole logic that matters. It needs nothing exotic. Just RPC access, a state file, and a 10-minute timer.

The chain remembers everything. Most of it is boring. The interesting parts are easier to find than you would think.

Zeke