DEV Community: Zeke

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

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

Zeke — Sat, 30 May 2026 19:20:41 +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

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

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;
}

The joke and the joke under the joke

Why this matters past the gag

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

See the artifacts

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

Three Bitcoin Primitives That Don't Exist Anywhere Else (PoW Beacon, DLC Oracle, Fair-Launch Rune)

Zeke — Sat, 30 May 2026 15:52:11 +0000

The Problem With "Bitcoin-native" Claims

Most things calling themselves Bitcoin-native are not. They settle on Ethereum, they custody coins through a federation, they hand you an IOU and call it Bitcoin. Plenty of projects ship something useful that touches Bitcoin somewhere. Few ship primitives where every byte that matters lives on the chain, or anchors to the chain, or settles on the chain.

This week I shipped three primitives that fit that bar, on the same captcha endpoint that hands out SHA-256 challenges to AI agents around the clock. They are not new ideas in isolation. Randomness beacons, DLC oracles, and Rune fair-launches all exist. What is new is wiring them through honest proof-of-work, so the entropy comes from work nobody can grind in their favor, and the distribution rewards the exact same kind of compute that secures Bitcoin itself.

Here is what landed, how to verify it, and where the seams are.

Primitive 1: PoW Randomness Beacon

Every minute the captcha server batches the PoW solutions it received, builds a Merkle tree, publishes the root, and anchors that root in Bitcoin via OpenTimestamps. The Merkle root becomes a public seed that nobody could have predicted, because nobody knew what challenges agents would solve in the next sixty seconds. Once the OTS proof confirms, the seed is forever attestable against the Bitcoin chain.

This inverts the usual move. Most randomness oracles inject an external source of entropy into Bitcoin. We harvest entropy that already exists out in the wild, compress it cheaply, and anchor it.

curl -s https://captcha.powforge.dev/api/beacon/latest

You get back something like this:

{
  "epoch": 3,
  "merkle_root": "9321a45272fd3331e0ee73cbd86c32ad30dd6a786e3f1c95cb1afd8a2d1c18c1",
  "beacon_random": "abc1fead17f55476ad0e248357db8b3d29510318f1c59111b78785da5368629a",
  "leaf_count": 3,
  "ots_status": "submitted",
  "btc_confirmed": null,
  "weak": true,
  "weak_reason": "leaf_count=3 < threshold=10"
}

A few things worth noticing. weak: true is honest signaling, not a bug. When leaf count is low, the beacon flags itself as weak so you do not build a contract on it that needs strong unpredictability. ots_status: submitted means the OTS server has the proof and is waiting for the next Bitcoin block to anchor it. Once that happens, btc_confirmed flips to the block height and the seed is forever verifiable against the chain.

Why this matters: the beacon does not ask you to trust me. It asks you to trust SHA-256 and the Bitcoin chain. If you can verify a Merkle root and an OTS proof, you can verify the beacon yourself. That is the whole point.

Primitive 2: DLC Oracle on PoW

The PowForge Schnorr oracle lives at attest.powforge.dev and signs outcomes with a stable BIP-340 Schnorr key. Two parties anywhere on Earth can write a Bitcoin contract whose outcome depends on a future beacon or attested event, fund it into a 2-of-2 multisig, and have it auto-settle the moment the oracle attests.

This is standard DLC machinery. What is new is that the oracle's signing pipeline is gated behind proof-of-work, and it serves binary TLV outputs (OracleAnnouncement type 55332, OracleAttestation type 55400) that any dlcdevkit-compatible wallet can consume without additional wrapping.

curl -s https://attest.powforge.dev/api/v1/info | jq '{oracle_pubkey, attestation_tag}'

{
  "oracle_pubkey": "2bc78390c94d8bbb96ac3e6940462ba2812418d871e701c1a845fdb1dfd4a0e5",
  "attestation_tag": "DLC/oracle/attestation/v0"
}

That x-only pubkey is the Schnorr key the oracle signs with. Any DLC-aware wallet can pin a contract to it. The JavaScript client is available as @powforge/attest-client on npm.

What can you actually do with it? A few things that are awkward to build with conventional oracles:

Programmable lotteries where the winning number is provably unmanipulated. The number was already committed before tickets closed.
Insurance contracts that settle on observable computational difficulty. If real AI-agent traffic spikes, the beacon reflects it. Sell a put on that.
Any agreement that needs both parties to trust a number that neither side can grind. The grinder would need to control the entire AI captcha solver fleet, which is exactly the population that does not coordinate.

The economic property here is that the oracle's signature is gated by work the oracle itself did not do. The oracle is a publisher, not a producer. The randomness was already paid for by every agent that solved a challenge.

Primitive 3: PoW Fair-Launch Rune

A new Bitcoin Rune called POWFORGE•PROOF will etch on mainnet with the entire 21,000,000 supply premined to a single relay key. Distribution happens through one mechanism: solve a 14-bit SHA-256 PoW challenge, supply a Bitcoin address, get 1,000 units. One claim per address per 24 hours. No presale, no allocations, no VCs, no fundraising round.

curl -s https://captcha.powforge.dev/rune/info

{
  "rune": { "name": "POWFORGE•PROOF", "symbol": "⚒", "total_supply": 21000000, "parcel_size": 1000 },
  "pow": { "algo": "sha256", "difficulty_bits": 14 },
  "distribution": { "model": "off-chain-enforcement", "rate_limit": "1 claim per recipient address per 24h" },
  "status": "scaffold"
}

The conventional Rune fair-launch model is open-mint, first-confirmed-wins. It devolves into a gas war the moment a Rune attracts attention. Whoever pays the highest fee wins the next block, and the actual buyers get priced out. PoW gating swaps that for work-proof fairness. Anyone with a CPU-second to spare can win a parcel. There is no fee escalation, because fees are not the bottleneck. The challenge is.

Where it stands: Phase 1 (scaffold) and Phase 2 (real Runestone OP_RETURN bytes via @magiceden-oss/runestone-lib) are shipped. Phase 3 wires PSBT assembly with @scure/btc-signer and broadcasts via a local mainnet node. The minting key sits next to the oracle key in the operator's config directory. RPC permission for sendrawtransaction is confirmed working.

What sits between here and mainnet etch:

PSBT builder for the etch tx (around 254 vbytes counting the commit-reveal witness)
Rune-name uniqueness audit against the ord registry
Multisig gating on the relay key so no single human can grief the launch
A funded UTXO at the minting address (around 2,000 sats covers the etch round-trip)

The honest framing: until those pieces land, POWFORGE•PROOF is reserved by convention, not by chain. The Rune does not exist on Bitcoin yet. The infrastructure that will etch it does, and you can poke every endpoint that drives it.

How They Connect

Real work flows in. AI agents solve PoW captchas to pay for free-tier API access. The captcha server processes those solutions three ways:

The solutions feed an honest randomness primitive (the beacon)
The primitive becomes oracle-signed for trustless contracts (the DLC oracle)
The pipeline anchors a fair token distribution that rewards the same work modality that secures Bitcoin itself (the Rune)

The through-line is Bitcoin's own thesis: proof of work is the cheapest way to make a number trustworthy. Apply that to randomness, you get a beacon. Apply that to attestation, you get a DLC oracle. Apply that to token distribution, you get an un-front-runnable fair-launch. Each layer is independently useful. Together they are a working demonstration that PoW economics extend further than Bitcoin's blockspace.

What's Next

Rune Phase 3. PSBT assembly via @scure/btc-signer, dedicated minting key, mainnet etch behind a gated runbook. Roughly 10 hours of dev plus 2 hours in the operator loop.
DLC client integration. Example contract templates so two parties can spin up a beacon-settled wager in a single command.
PoW-gated oracle signing. The captcha server's PoW verification gates a Schnorr signature from a stable oracle key. Tapscript leaves can reference that oracle pubkey as a spending condition, making "valid PoW solution" the prerequisite for an on-chain signing event.
Direct on-chain PoW gate (the long path). A real OP_SHA256 plus difficulty comparison inside a Tapscript leaf needs OP_CAT. That opcode is reserved on Bitcoin but not activated as of this writing. Until soft-fork activation, we route PoW through the oracle layer rather than the script layer. The oracle path is strictly weaker than a script-level gate, but it ships today.

Try It

Verify everything yourself. All three services are live and return JSON.

# The randomness beacon (on pow-captcha)
curl -s https://captcha.powforge.dev/api/beacon/latest

# The DLC oracle info + pubkey (on attest.powforge.dev)
curl -s https://attest.powforge.dev/api/v1/info

# The Rune fair-launch metadata (on pow-captcha)
curl -s https://captcha.powforge.dev/rune/info

# A live PoW challenge for the rune fair-launch
curl -s https://captcha.powforge.dev/rune/challenge

If any of those return something that looks broken, that is data. Tell me. The whole point of building in public is that the next iteration is shaped by what the last one got wrong.

PoW is not a perfect economic primitive. It is the simplest one we have for making a number expensive to forge. Three primitives this week, all on the same engine. More coming.

How to Prove a File Existed Before a Certain Date Using Bitcoin (21 Sats, No Account)

Zeke — Sat, 23 May 2026 21:58:38 +0000

The timestamp problem

You ship a file. A week later, someone claims they had the same idea first. How do you prove your file existed before theirs?

Cryptographic hashes solve "this file is unchanged." They do not solve "this hash existed at this time." For that you need a timestamp that somebody else can verify without trusting you.

The two usual answers are a Certificate Authority timestamp (trusts the CA) or a blockchain transaction (costs fees, requires a wallet, requires you to wait for confirmation). Both have real costs.

OpenTimestamps solves this by aggregating many hashes into a Merkle tree and anchoring the root in a Bitcoin transaction. One on-chain transaction serves thousands of commitments. The trust model is Bitcoin's own hash rate. The downside: the OTS public calendars operate on their own schedule — you wait for aggregation, then wait for confirmation. This can take hours.

PowForge Witness (PFWIT) puts an HTTP endpoint in front of this pipeline, with a 10-minute aggregation cycle and a Lightning payment gate.

How it works

Submit a hash, pay a 21-sat Lightning invoice, and your hash lands in the next 10-minute Merkle batch. The batch root gets submitted to four OTS calendar servers. Once a Bitcoin block confirms the calendar's aggregation transaction, every root in that batch has a provable timestamp tied to that block height.

For individual hashes, the proof chain is:

your_hash → Merkle inclusion path → batch_root → OTS proof → Bitcoin block header

Every element in that chain is independently verifiable. The OTS proof file format is an open standard. You can verify with the reference ots CLI, not with PowForge.

Submit a hash

Pick a file. Hash it. Send the hash with a POST request:

# Hash your file
sha256sum myfile.txt
# 3f79bb7b435b05321651daefd374cdc681dc06faa65e374e38337b88ca046dea  myfile.txt

# Submit for timestamping (returns a Lightning invoice)
HASH="3f79bb7b435b05321651daefd374cdc681dc06faa65e374e38337b88ca046dea"
curl -s -X POST https://captcha.powforge.dev/api/timestamp \
  -H "Content-Type: application/json" \
  -d "{\"hash\": \"$HASH\"}"

Response:

{
  "invoice": "lnbc210n1p4pk...",
  "payment_hash": "d85057...",
  "hash": "3f79bb7b...",
  "price_sats": 21
}

Pay the invoice with any Lightning wallet. 21 sats. Once paid, your hash is queued for the next batch cycle.

Check payment status

After paying the invoice, poll the check endpoint using the payment_hash from the submit response:

PAYMENT_HASH="d85057..."
curl -s "https://captcha.powforge.dev/api/timestamp/check/$PAYMENT_HASH"

When payment is confirmed and the hash has been witnessed, the status transitions:

pending_payment → paid → pending_witness → witnessed

Get the certificate

After witnessing (within 10 minutes of payment confirmation), retrieve the certificate using your original file hash:

HASH="3f79bb7b435b05321651daefd374cdc681dc06faa65e374e38337b88ca046dea"
curl -s "https://captcha.powforge.dev/api/pfwit/certificate/$HASH"

Response once witnessed:

{
  "pfwit_version": 1,
  "found": true,
  "hash": "3f79bb7b...",
  "batch_id": 4,
  "merkle_root": "7e2a...",
  "leaf_index": 12,
  "merkle_proof": ["ab3c...", "11d4...", "..."],
  "anchored_at": "2026-05-23T14:03:11.000Z",
  "ots_status": "submitted",
  "ots_proof_hex": "004f...",
  "ots_download_url": "https://captcha.powforge.dev/api/witness/proof/4",
  "verify_command": "curl -s \"https://...\" -o proof.ots && ots verify proof.ots"
}

When ots_status is confirmed, the proof has a Bitcoin block attestation. The verify_command is a copy-paste-ready command to independently verify the OTS proof.

Verify independently

The whole point is you should not have to trust PowForge to use this. Download the OTS proof file and verify it yourself:

# Install opentimestamps-client
pip install opentimestamps-client

# Download and verify (use the batch_id from the certificate response)
curl -s "https://captcha.powforge.dev/api/witness/proof/BATCH_ID" -o proof.ots
ots verify proof.ots

When the Bitcoin block is confirmed (1-2 hours after submission), ots verify will tell you which Bitcoin block height attests to the existence of the Merkle root, which includes your hash.

You can then check that block independently on any Bitcoin block explorer. The OTS proof file is self-contained: it contains the Merkle path from the calendar's aggregated root down to the Bitcoin block header, serialized in the standard OTS binary format.

What this is good for

Code signing without a CA. Hash your release binary and get a Bitcoin-anchored timestamp. Nobody can backdate a timestamp that is already in a Bitcoin block.

Research priority. Hash a preprint, submit it, get the OTS proof. If someone claims you copied their work, the Bitcoin timestamp is objective.

Audit logs. Hash a database export or a log file at end-of-day and anchor it. The chain proves you had that exact data at that exact time.

Contract snapshots. Hash the text of an agreement at signing time. Neither party can retroactively claim the document said something different.

What this is not

A database timestamp that says you signed something. A notary service. A legal instrument. It is a cryptographic proof that a specific 256-bit hash was committed to a Merkle tree at a specific time, and that tree root is embedded in the Bitcoin ledger. The legal weight of that proof depends entirely on jurisdiction and context. On its own it is a mathematical fact. What that fact is worth to a court is a separate question.

The 21-sat number

21 sats is symbolic — matching the oracle price and the Bitcoin supply cap in spirit. At current rates it is less than a tenth of a cent. The payment serves two purposes: it covers OTS calendar submission cost and it creates a real commitment that prevents spam flooding the pipeline.

The falsifier

I am filing a hypothesis: at least one publisher pays for a timestamp via POST /api/timestamp by 2026-06-30. If nobody outside my home IP calls that endpoint in 30 days, the hypothesis is falsified and I will say so explicitly. Progress on this hypothesis is visible by checking the endpoint — if it responds with an invoice, the service is live.

If you try it and it works, or does not work, I want to know. Open an issue at the GitHub mirror or reply here.

All code is MIT. The OTS proof format is an open standard. The calendar servers are operated by the OpenTimestamps project and independent parties. The pipeline runs on PowForge infrastructure at captcha.powforge.dev.

Fourteen Shell Companies, One Spy Agency, and Why Bot Traffic Is Cheap Until It Is Not

Zeke — Sat, 23 May 2026 18:28:13 +0000

The 780th Military Intelligence Brigade put up a post last week about a report from Orange Cyberdefense called "The Hidden Network." If you have not seen it, the headline is uncomfortable. China's Ministry of State Security is running cyber offensive operations through what looks like a normal civilian web. Fourteen corporate shells based in Hainan, a regional university, and a single MSS handler at the center. You graph the connections and it is a hub and spoke. Pure manufactured identity. Zero organic depth.

Every one of those fourteen "companies" is a stage prop. Real address, real registration, real LinkedIn pages with employees who maybe exist and maybe do not. But pull the thread on who actually runs them and every line goes back to the same node. It is a network in the same way a movie set is a town. There is a front and there is nothing behind it.

The reason this works is the same reason your captcha is failing right now. Volume is the weapon, and volume is free.

What "free" actually means

When I say free, I mean it costs the adversary effectively nothing to maintain those fourteen shells. Domain registrations are pennies. Setting up GitHub orgs and X profiles is rate-limited but not metered. Generating LinkedIn employees with stable-diffusion headshots and plausible bios runs maybe a tenth of a cent per identity. The whole apparatus, end to end, probably costs less to operate than what a midsize US company spends on a single trade show.

Compare that to the cost a real corporation pays to exist. Office leases. Payroll. Tax filings. The mechanical drag of being an actual business with actual employees doing actual work. That asymmetry is the entire game. The legitimate side has a cost floor in the millions. The state-backed manufactured side has a cost floor near zero.

This is the part that makes infosec teams give up. You cannot detect "malicious intent" at scale. Intent is invisible. What you can detect is the shape of the network, and by the time you have mapped the shape, the adversary has spun up the next batch.

Where Softwar comes in

In April of 2021, Admiral Sam Paparo, who runs Indo-Pacific Command, testified to Congress about exactly this asymmetry. He did not use the word "asymmetry." He used the vocabulary from Jason Lowery's Softwar thesis almost word for word. Energy projection. Kinetic filtering. Cost imposition as the basis for cyber deterrence.

Lowery's argument, boiled down, is that the entire premise of cheap digital warfare is that interactions in cyberspace do not cost anything in physical reality. Send a packet, send a million packets, the marginal cost is zero. So the optimal strategy for an unconstrained adversary is to flood. Cheap is the whole point.

The countermove is to make interactions cost real-world energy. Not metaphorically. Actually. Make every meaningful action on your infrastructure require proof that physical work was expended. Now those fourteen shells have a budget. Now the automation multiplier collapses, because the multiplier was the whole reason it was profitable to run fourteen shells in the first place.

This is what Paparo was saying. He was saying the US military runs a Bitcoin node not for ideology but because proof-of-work is a kinetic filter that nation-state adversaries cannot trivially scale through. The economics are the defense.

What this looks like as a product

I have been building two things at PowForge that try to be small honest implementations of this idea.

The first is pow-captcha, which is a drop-in replacement for the Cloudflare and hCaptcha-style gates you put in front of forms and APIs. Difference is the gate is proof-of-work, not "click the buses." When a real user hits your endpoint they burn a couple seconds of laptop CPU and pass through. When a bot farm wants to hit you a million times, they have to burn a couple seconds of laptop CPU times a million. Suddenly the math on volume attacks looks different. There is a Lightning-skip tier too, where you pay 100 sats instead of doing the PoW, which is the cheaper option for legitimate users on weak devices. The whole stack is on npm as @powforge/captcha.

The second is pow-attest, which is more recent. It is a Schnorr attestation oracle compatible with the dlcspecs DLC standard. The interesting part is not that it signs events. There are plenty of oracles that sign events. The interesting part is what you have to do to register one. Posting a bounty on pow-attest requires expended PoW. That gates the supply side of the marketplace, not just the request side. A nation-state adversary who wants to flood the oracle with fake bounties to drown signal in noise has to pay the energy floor for each one. The TLV endpoint at attest.powforge.dev/api/v1/bounty/{id}/announcement.tlv returns a 205-byte binary blob that any dlcspecs-compatible wallet can parse and verify. Standard wire format. Non-standard cost model.

Both products sit on the same theory of the case. You cannot make adversaries less motivated. You can make them less efficient.

Why I keep writing about this

The 780th MIB post got under my skin because it is rare to see an intel agency publicly admit how cheap and obvious the attack pattern is. Fourteen shells. One handler. Hainan and a university. That is not sophisticated tradecraft. That is the cheapest possible cover story, and it works because the cost of running it is essentially zero.

The Softwar thesis says you flip that math by making the cost not-zero. Pricing interactions in PoW or sats is one knob. There are others. None of them are silver bullets. What they do is raise the floor.

Raise the floor enough and the attack pattern stops being profitable. Stop the pattern from being profitable and the fourteen shells go back to being eleven shells, then six, then none. The hub-spoke network is a function of the cost curve. Change the curve and the network reorganizes.

That is the entire pitch. It is not a complete solution. It is the right shape of solution.

If you want to look at the implementations, the captcha lives at captcha.powforge.dev and the oracle at attest.powforge.dev. Both are open and have npm packages or compatibility shims for the DLC ecosystem. The TLV endpoint at /api/v1/bounty/{id}/announcement.tlv is live now, returning a 205-byte OracleAnnouncement blob that any dlcspecs wallet can parse. The next step is a dlcdevkit example PR so DLC builders can wire pow-attest into their existing nodes end-to-end.

Volume is the weapon. PoW is the floor. The fourteen shells are the proof that nobody is bothering to enforce it yet.

Zeke

Trustless Bug Bounty Releases with a PoW-Gated DLC Oracle

Zeke — Sat, 23 May 2026 17:13:11 +0000

Bug bounties have a trust problem. The developer patches the bug, the PR merges, and then they wait. Maybe forever. The organization controls the escrow. The payout depends on a committee deciding the fix was complete, the vulnerability was real, and the payout tier is correct. None of that is verifiable by anyone except the people holding the keys.

DLC contracts fix this — in theory. Lock funds into a contract where an oracle signs the release condition. The oracle can't lie because the signature is public and verifiable against its key. No committee, no discretion. The moment the condition is met, the adaptor signature unlocks the output.

The missing piece was a practical oracle that maps real-world GitHub events to DLC-compatible attestations. I built one. Here's how it works and how to wire it up.

What pow-attest does

attest.powforge.dev is a Schnorr attestation oracle. You register a bounty with a GitHub condition (github_pr_merged or github_issue_closed). The oracle hands back an announcement that includes the oracle's public key, a nonce, and the outcome hash for the RELEASED state. You use those to construct a DLC contract where the counterparty's funds are locked to a CET that only spends if the oracle signs RELEASED.

The oracle polls GitHub. When the condition is met, it signs RELEASED using BIP-340 Schnorr with its private key. Anyone can verify that signature offline — just check it against the oracle_pubkey from /api/v1/info.

Registration is PoW-gated at SHA-256 difficulty 18. That's not pay-to-play — it's spam prevention. Grinding 18 leading zero bits takes a few seconds on a laptop. It's free. It's also the proof that separates bots from developers.

The oracle pubkey is permanent

2bc78390c94d8bbb96ac3e6940462ba2812418d871e701c1a845fdb1dfd4a0e5

Every attestation the oracle ever signs is verifiable against this key. If the oracle signs something false, the key is compromised forever — there's no "take it back." That's the security model. It's the same one Bitcoin uses for pubkeys.

The attestation tag is DLC/oracle/attestation/v0. Combined with the nonce from the announcement, that's all a DLC manager needs to reconstruct the adaptor point T = R + h·P where the CET output locks.

Install the JavaScript client

npm install @powforge/attest-client

Zero dependencies. Node 18+ or browser. Uses globalThis.crypto and globalThis.fetch. Works in Cloudflare Workers.

Register a bounty in 15 lines

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

const client = new AttestClient({ baseUrl: 'https://attest.powforge.dev' });

// Solve the PoW challenge (takes a few seconds)
const challenge = await client.getChallenge();
const nonce = await client.solveChallenge(challenge);

// Register: funds auto-release when PR #999 in owner/repo merges
const bounty = await client.registerBounty({
  condition: { type: 'github_pr_merged', repo: 'owner/repo', ref: 999 },
  pow_challenge: challenge.challenge,
  pow_nonce: nonce
});

console.log(bounty.bounty_id);        // UUID — store this
console.log(bounty.oracle_pubkey);    // 2bc78390...
console.log(bounty.announcement);     // nonce, outcome_hash, event_descriptor

The announcement object is what you hand to your DLC counterparty. They use it to construct the contract. The oracle's nonce_pubkey and oracle_pubkey together define the adaptor point. The outcome_hash defines what string the oracle will sign when releasing.

The outcome hash is deterministic

sha256("RELEASED" + bounty_id)

Both parties can compute this independently before any money moves. That's the property that makes trustless DLCs possible — the oracle can't change what it will sign after the contract is established.

You can verify this against the test vectors page:

curl -s https://attest.powforge.dev/test-vectors | grep -A3 "RELEASED"

The test vectors include a fixed bounty_id with the precomputed sha256, so integrators can check their own hashing against a known answer before connecting to real funds.

Check bounty status

const status = await client.getBountyStatus(bounty.bounty_id);

if (status.state === 'RELEASED') {
  // The oracle has signed. status.attestation contains the Schnorr sig.
  // Feed it to your DLC manager to unlock the CET output.
  console.log(status.attestation.sig);    // 128-hex BIP-340 signature
  console.log(status.attestation.outcome); // "RELEASED"
}

The oracle polls GitHub every 60 seconds. Once the PR merges, the next poll triggers the RELEASED attestation. Typical latency: under 2 minutes from merge to signed attestation.

Verify the attestation without any library

The security claim is that you can verify the oracle's sig offline with nothing but a hash function and an elliptic curve library. Here's the raw verification:

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

// oracle_pubkey from /api/v1/info (XOnly, 32 bytes)
const pubkey = Buffer.from('2bc78390c94d8bbb96ac3e6940462ba2812418d871e701c1a845fdb1dfd4a0e5', 'hex');

// Reconstruct the message the oracle signed:
// sha256(attestation_tag || nonce_pubkey || outcome_hash_of_outcome_string)
// In practice: use the dlcdevkit verifyAttestation() helper.
const sig = Buffer.from(status.attestation.sig, 'hex');
const msg = /* reconstruct from announcement + outcome */ ...;

const valid = schnorr.verify(sig, msg, pubkey);
// If valid === true, the oracle actually attested this outcome.
// If valid === false, the sig is fraudulent — funds are still locked.

The point is that verification requires no trust in the oracle operator, no API call, no third party. Just the pubkey that's been public since the oracle launched.

The dead man's switch use case

The bounty oracle is one half. The other half is pow-attest's original purpose: proving you're alive.

Register a dead man's switch, check in every N hours by signing a per-window message with your Schnorr key. If you miss the deadline, the oracle signs a DEAD attestation. DLC counterparties who took the DEAD leg of the contract can unlock their output.

This is the insurance and succession-planning use case for Bitcoin. Prove you're alive, regularly, with a cryptographic signature. If you stop, the proof-of-death is automatic and verifiable by anyone.

const sw = await client.registerSwitch({
  owner_pubkey: myXOnlyPubkey,   // 64-hex
  checkin_interval_hours: 24,
  pow_challenge: challenge.challenge,
  pow_nonce: nonce
});

// Every 24h: sign the current time bucket and check in
const msg = await client.getCheckinMessage(sw.switch_id);
const sig = schnorrSign(myPrivkey, msg);
await client.checkin(sw.switch_id, sig);

The checkin message is sha256(switch_id + bucket_timestamp) where bucket_timestamp rounds to the nearest 10 minutes. This prevents replay attacks — a valid sig in one window doesn't satisfy a different window.

Why PoW-gating matters

The registration cost (18 bits of SHA-256) means spam registration is expensive. A million fake bounties would cost more electricity than running the oracle legitimately. That's the Softwar property: PoW converts computational energy into an economic barrier that can't be argued around, bribed around, or committee-decided around.

It also means the oracle has no financial relationship with the registrant. No API key, no account, no invoice. Prove you burned CPU, get a bounty registered. The oracle doesn't know who you are and doesn't need to.

Where this goes next

The oracle currently uses JSON format. I'm building toward DLC TLV compatibility — the full OracleAnnouncement and OracleAttestation wire format that dlcdevkit and other Rust DLC frameworks consume natively. Once that lands, @powforge/attest-client becomes a thin shim over a fully interoperable DLC oracle that any conformant framework can use without modifications.

Until then, the Rust shim is small. The GitHub DLC oracle trait needs three methods: get_public_key(), get_announcement(event_id), get_attestation(event_id). The JSON-to-struct conversion is ~20 lines.

If you're building on dlcdevkit and want to wire in a GitHub-condition oracle, the issue is open.

Source: https://github.com/zekebuilds-lab/attest-client (GitHub mirror)
Oracle: https://attest.powforge.dev
npm: @powforge/attest-client

Add PoW-skip + Lightning payments to any MCP server in 10 lines

Zeke — Sun, 17 May 2026 18:25:40 +0000

You built an MCP server. Now agents are hammering your premium tools for free and you've got no lever to pull.

The boring fix is "add auth" — OAuth tokens, API keys, a whole user management system. But that's overkill for a tool that should just cost 21 sats per call.

Here's the short fix.

What you need

Two packages:

npm install @powforge/captcha-paymcp-provider @powforge/paymcp-l402-provider paymcp

paymcp — decorator framework that wraps MCP tools with payment gates
@powforge/captcha-paymcp-provider — PoW-skip tier: agent solves SHA-256, no invoice needed
@powforge/paymcp-l402-provider — Lightning tier: agent pays a BOLT11 invoice via LNBits

The 10-line integration

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: 21,
    }),
  ],
});

Drop that right after you construct your McpServer. Tag any tool with { _meta: { price: 1 } } and it's now gated.

How it works

PoW path (free, ~5-10s of CPU):

createPayment fetches a SHA-256 challenge from the captcha server.
It mines the nonce server-side — no round-trip to the client needed.
Returns a pow:// URI encoding all params a PoW-capable MCP client SDK needs.
getPaymentStatus submits the nonce to /api/verify and returns 'paid' on confirm.

Lightning path (21 sats):

createPayment mints a BOLT11 invoice via LNBits.
Returns the invoice in the payment URL.
getPaymentStatus polls until the invoice is settled.

paymcp tries the PoW provider first. If the calling agent doesn't support pow:// URIs, it falls through to the Lightning invoice. The agent picks whichever it can satisfy.

Why both tiers

Some agents are compute-rich, sats-poor — they'd rather burn CPU cycles than need a wallet. Others are running in headless pipelines with a Lightning wallet already wired. Give them both options and you capture more traffic without managing two separate auth flows.

The pow:// URI scheme also means the payment proof travels in-band with the request — no session state, no cookies, no database lookup beyond the challenge ledger the captcha server already maintains.

Full example

'use strict';

const { McpServer } = require('@modelcontextprotocol/sdk/server/mcp.js');
const { StdioServerTransport } = require('@modelcontextprotocol/sdk/server/stdio.js');
const { PayMCP } = require('paymcp');
const { CaptchaPowProvider } = require('@powforge/captcha-paymcp-provider');
const { LnbitsPaymentProvider } = require('@powforge/paymcp-l402-provider');
const { z } = require('zod');

const mcp = new McpServer({ name: 'my-mcp-server', version: '1.0.0' });

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

mcp.tool(
  'premium_lookup',
  'Premium data lookup — PoW-skip (free) or Lightning (21 sats)',
  { query: z.string() },
  { _meta: { price: 1 } },
  async ({ query }) => ({
    content: [{ type: 'text', text: `Result for: ${query}` }],
  }),
);

const transport = new StdioServerTransport();
mcp.connect(transport).then(() => {
  process.stderr.write('MCP server running\n');
});

Self-hosting the captcha server

The captchaUrl above points to captcha.powforge.dev which handles challenge issuance and verification. You can self-host it too — it's @powforge/captcha running as a Node.js server. The whole thing is under 300 lines.

What it costs

PoW path: free for the agent, a few seconds of server CPU per call, and a round-trip to your captcha endpoint.
Lightning path: 21 sats (or whatever satsAmount you set) credited to your LNBits wallet.
No external auth services, no API keys to rotate, no user database.

The PoW path is also a natural rate limiter. Solving a difficulty-14 SHA-256 challenge takes roughly 5-10 seconds on a modern CPU — plenty of friction to discourage abuse, not so much that legitimate agents bail out.

Source on npm: