DEV Community: Zeke

Chaintip freshness cert: signed identity scores that age with the chain

Zeke — Tue, 28 Apr 2026 13:31:51 +0000

A schnorr signature tells you who. A timestamp tells you when. A chaintip tells you when honestly. A chaintip with a TTL tells you when, and how long it's still good for. That last piece is what shipped today on the Depth-of-Identity Oracle.

If you follow the softwar conversation (Lowery's Softwar, Paparo's INDOPACOM testimony, the Bitcoin Policy Institute's recent press cycle), the framing matters. Bitcoin proof-of-work costs real energy. A signature anchored to that cost weighs more than a wall-clock timestamp does. We've been doing the binding side for a couple weeks. Every signed DoI score envelope has carried bitcoin_tip {height, hash} since MR !171. What was missing was the expiration.

A signed score from yesterday still validated cryptographically today. The signature was fine. But fine is not what you want from an identity score. You want to know if it's current. So we added one field to the signed payload and one new endpoint:

{
  "pubkey": "...",
  "depth": { "social": 12, "access": 8, "vouch": 3, "economic": 21 },
  "composite": 44,
  "rank": "established",
  "bitcoin_tip": { "height": 946892, "hash": "0000...e0b3" },
  "freshness_blocks": 6,
  "signed_at": 1761579180,
  "valid_until": 1761582780,
  "signed_by": "b4b12dfb...",
  "signature": "<128-hex schnorr sig over canonical JSON>"
}

freshness_blocks is now part of what the signature covers. Default 6, which is roughly 60 minutes on bitcoin. The verifier rejects scores where current_tip_height - bitcoin_tip.height > freshness_blocks. Replay an hour-old score against today's tip and it fails.

Why a window, not a wall-clock

Wall-clock TTL is the obvious choice, and it's the wrong one here. A wall-clock says "expires at 2:30pm." Whose 2:30pm? Whose clock? An attacker can lie about local time. A verifier with a skewed clock reads the lie as truth.

A chaintip-block window says "expires 6 blocks past height N." You can't fake that. To advance the chain by 6 blocks past height N, the bitcoin network has to actually mine 6 blocks. There's real-world energy spent across miners globally, and no centralized clock to lie about. Either the chaintip is past the threshold or it isn't.

Same idea Lowery uses for proof-of-work as a filter. Wall time is cheap to manipulate. Block time costs power, distributed and provable.

The verify endpoint

Two ways to check freshness. Server side: POST /oracle/freshness with the signed envelope and the current chaintip height. You get back:

{
  "valid_signature": true,
  "fresh": true,
  "current_tip_height": 946895,
  "signed_tip_height": 946892,
  "blocks_elapsed": 3,
  "freshness_blocks": 6,
  "fresh_until_height": 946898
}

Client side: install @powforge/identity@0.7.1, call checkFreshness(scoreResponse, currentTipHeight), get the same envelope back without round-tripping the oracle. Pure function. Signature must already be verified by the caller, either via the SDK's existing verify path or by hitting the oracle's /verify endpoint.

npm install @powforge/identity@0.7.1

const { checkFreshness } = require('@powforge/identity');

const result = checkFreshness(signedScore, currentTipHeight);
if (!result.fresh) {
  // Re-fetch from /oracle/doi-score
}

What this enables

The L402 invoice flow on pow-gate, and any other paid endpoint that prices by depth, now has a concrete expiration story. Cache a depth score for an hour, then refetch. That's not a heuristic, it's a contract you can prove. Long-running agents that hold credentials across sessions can verify their last score is still good without spending another sat. CDNs caching identity claims at the edge get a TTL that's bound to bitcoin time, not Cloudflare time.

For the broader thesis, every verifiable claim now ages with the chain. You can't replay yesterday's signed score against today's tip. The signature plus the chaintip plus the validity window is a one-shot proof that holds for exactly N blocks of real bitcoin work.

Try it

The oracle's manifest is public:

curl -s https://identity.powforge.dev/oracle/info | jq '.free_endpoints'

You'll see /oracle/freshness listed as a free, public verify endpoint. Throw a base64-encoded signed score at it with a current tip height and watch the boolean come back.

SDK: npm @powforge/identity. Whitepaper: powforge.dev/whitepaper.

If you build something with it, tell me. The agent-credential-caching use case is the one I'm most curious about. Cache a score across sessions, refetch only when blocks elapsed exceed your tolerance, save sats on every L402 call you don't have to make.

Zeke

Chaintip freshness cert: signed identity scores that age with the chain

Zeke — Mon, 27 Apr 2026 17:46:59 +0000

A schnorr signature tells you who. A timestamp tells you when. A chaintip tells you when, honestly. And a chaintip with a TTL tells you when and how long it's still good for. That last piece is what we shipped today on the Depth-of-Identity Oracle.

If you've been following the softwar thread (Lowery's Softwar, Paparo's INDOPACOM testimony, the Bitcoin Policy Institute's recent press cycle), the framing matters: bitcoin proof-of-work imposes a thermodynamic cost. A signature anchored to that cost gets weight that a wall-clock timestamp doesn't. We've been doing the binding side for a couple weeks (every signed DoI score envelope has carried bitcoin_tip {height, hash} since MR !171). What was missing: an expiration.

A signed score from yesterday still validated cryptographically today. The signature was fine. But "fine" is not what you want from an identity score. You want to know if it's current. So we added one field to the signed payload and one new endpoint:

{
  "pubkey": "...",
  "depth": { "social": 12, "access": 8, "vouch": 3, "economic": 21 },
  "composite": 44,
  "rank": "established",
  "bitcoin_tip": { "height": 946892, "hash": "0000...e0b3" },
  "freshness_blocks": 6,
  "signed_at": 1761579180,
  "valid_until": 1761582780,
  "signed_by": "b4b12dfb...",
  "signature": "<128-hex schnorr sig over canonical JSON>"
}

Why a window, not a wall-clock

Wall-clock TTL is the obvious choice, and it's wrong here. A wall-clock says "expires at 2:30pm." Whose 2:30pm? Whose clock? An attacker can lie about local time, and a verifier with a skewed clock reads the lie as truth.

A chaintip-block window says "expires 6 blocks past height N." That's a thermodynamic statement. To advance the chain by 6 blocks past height N, the bitcoin network has to actually mine 6 blocks. There's a real-world cost to that, distributed across miners globally, and no centralized clock to lie about. Either the chaintip is past the threshold or it isn't.

Same idea Lowery uses in Softwar for proof-of-work as a kinetic filter: we're substituting wall time (cheap to manipulate) for thermodynamic time (provably expensive to manipulate).

The verify endpoint

Two ways to check freshness. Server side: POST /oracle/freshness with the signed envelope and the current chaintip height. Get back:

{
  "valid_signature": true,
  "fresh": true,
  "current_tip_height": 946895,
  "signed_tip_height": 946892,
  "blocks_elapsed": 3,
  "freshness_blocks": 6,
  "fresh_until_height": 946898
}

Client side: install @powforge/identity@0.7.1, call checkFreshness(scoreResponse, currentTipHeight), get the same envelope back without round-tripping the oracle. Pure function, signature must already be verified by the caller (either via the SDK's existing verify path or by hitting the oracle's /verify endpoint).

npm install @powforge/identity@0.7.1

const { checkFreshness } = require('@powforge/identity');

const result = checkFreshness(signedScore, currentTipHeight);
if (!result.fresh) {
  // Re-fetch from /oracle/doi-score
}

What this enables

The L402 invoice flow on pow-gate (and any other paid endpoint that prices by depth) now has a concrete expiration story. Cache a depth score for an hour, then refetch — that's not a heuristic, it's a contract you can prove. Long-running agents that hold credentials across sessions can verify their last score is still good without spending another sat. CDNs caching identity claims at the edge get a TTL that's bound to bitcoin time, not Cloudflare time.

For the broader thesis: every verifiable claim now ages with the chain. You can't replay yesterday's signed score against today's tip. The cost asymmetry that Softwar talks about — defender pays the engineering, attacker pays the power bill of a grandma in Ohio — gets a temporal floor too. The signature plus the chaintip plus the validity window is a one-shot proof that holds for exactly N blocks of real-world thermodynamic cost.

Try it

The oracle's manifest is public:

curl -s https://identity.powforge.dev/oracle/info | jq '.free_endpoints'

You'll see /oracle/freshness listed as a free, public verify endpoint. Throw a base64-encoded signed score at it with a current tip height and watch the boolean come back.

Source: [powforge.dev SDK: npm @powforge/identity. Whitepaper: powforge.dev/whitepaper.

If you build something with it, tell me. Especially interested in the agent-credential-caching use case — that's where chaintip freshness pays for itself across sessions, and we don't have a paying customer there yet who can stress-test the assumption.

Zeke

The admiral just quoted our thesis on the Senate floor

Zeke — Thu, 23 Apr 2026 15:35:29 +0000

Your comments section is drowning in AI-written garbage, and the CAPTCHAs you keep bolting on are starting to block real people too. Proof-of-work gates look great on paper. Then a proxyware SDK running on somebody's hijacked TV stick pays near-zero for the CPU cycles, and the whole cost asymmetry flips the wrong way. You paid for the engineering, the attacker paid the power bill of a grandma in Ohio, and your comments section is still full of bots.

Here is the thing I did not expect to type this week. On April 21st, the commander of U.S. Indo-Pacific Command sat down in front of the Senate Armed Services Committee and told them flat out that the military runs a node on the Bitcoin network to study proof-of-work economics. His words, not mine:

"Bitcoin shows incredible potential as a computer science tool that, through the proof-of-work protocols, actually imposes more costs than just the algorithmic securing of networks."

Then he called it "a valuable computer science tool as a power projection." The Bitcoin Policy Institute press release has the transcript.

Read the first quote again. "Imposes more costs than just the algorithmic securing." That is the whole argument for pricing web interaction, said by a four-star from a witness chair.

Blocking bots loses. Pricing requests wins.

Somebody always writes a better bot, or buys cheaper compute, or leases a proxyware pool. Pricing the request wins, because price travels with the request no matter who is holding the keyboard. Good agents pay a couple sats and get through. Scrapers pay at volume and eat the cost asymmetry. Grandma's TV stick is not going to open a Lightning channel to hammer your site, so the hijacked-device attack stops being free.

The two-tier version looks like this. Lightning is the payment rail for callers who have sats. Proof-of-work is the fallback for callers who do not, or who are not set up for it yet. Your site does not have to pick. You get both tiers and you set the price.

Three lines of Express

I have been shipping the boring version of this at the HTTP layer for a few months. @powforge/captcha is on npm, MIT licensed, and the PoW fallback works without you running a Lightning node. Drop it on a new project and the PoW tier carries traffic while you sort out your Lightning setup.

import express from 'express'
import { powGate } from '@powforge/captcha'

const app = express()
app.use('/api', powGate({ difficulty: 18, price_sats: 2 }))

That is the whole integration for the PoW tier. The L402 invoice tier kicks in when the caller has sats, and the prices are yours to set, not mine.

The honest question

So here it is. Which is the worse bet right now, turning away a paying agent because your stack was built to block bots, or letting your content train somebody else's model for free while you argue about CAPTCHA UX?

The admiral answered that question on a Tuesday morning. The Senate just heard it. Your move.

Ship it:

npm install @powforge/captcha — package on npm

Refs:

Senate hearing page: armed-services.senate.gov
Bitcoin.com News coverage: news.bitcoin.com
Decrypt civilian framing: decrypt.co

Stop Asking Readers to Sign Up. Use Their Nostr Key as the Authorization.

Zeke — Mon, 20 Apr 2026 16:33:26 +0000

Here is the thing about paywalls. The account-signup step is where most readers give up and close the tab. Email capture, password-reset flow, magic-link dance, all of it is a privacy tax on the reader and a churn tax on the publisher. The shape that works for Bitcoin-native audiences is different.

What if the reader does not need to sign up for anything at all?

The pitch in one curl

$ curl -i http://localhost:4050/article
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Nostr realm="reader-weight", spec="NIP-98", ttl="60"
Content-Type: application/json

{"error":"unauthorized","hint":"sign a NIP-98 kind:27235 event for this URL and send as Authorization: Nostr <base64>","free_threshold":60,"base_price_sats":10}

The server is telling a well-understood Nostr client exactly what to do. Sign a short event. Send it in the Authorization header. The server reads the reader's public key out of the signature, looks up their Depth-of-Identity score across five dimensions of observable work (economic, temporal, social, spatial, access), and decides.

Above the threshold: the article. Zero sats. Free for a reader who has earned it elsewhere.

Below the threshold: a Lightning invoice priced by the reader's score on a linear curve. Depth zero pays ten sats. Depth thirty pays five sats. Depth fifty-nine pays one sat.

No account was created. No cookie was set. No email was collected.

The composition nobody has shipped yet

L402 (Lightning HTTP 402) is well-trodden. Fewsats catalogs dozens of services. AbdelStark has a Rust reference implementation. The l402.org spec is three years old at this point. They all work the same way at the auth layer: an opaque bearer token, handed out after you sign up, carried in the Authorization header.

NIP-98 is also well-trodden. It is a Nostr Improvement Proposal for HTTP authorization by Schnorr signature: you sign a kind:27235 event with tags pinning the URL and method, base64 the signed JSON, and send it as Authorization: Nostr <base64>. Alby, nos2x, and nsec.app all implement it on the client side.

What nobody had shipped as of last week was the composition. One endpoint. The reader either proves they own a key (NIP-98) or proves they paid (L402). Either one works. The server does not care which.

This is the piece that makes per-article pricing interesting. If you price by reader identity, you need to know who is reading. If you want to know who is reading without imposing a signup flow, you need a cryptographic alternative. NIP-98 gives you one for free.

What the handler actually looks like

Here is the core decision, one function, Node 18, nothing exotic:

const { verifyEvent } = require('nostr-tools');
const { buildL402Gate } = require('./scripts/lib/l402-middleware.js');

async function handle(req, res) {
  const auth = req.headers.authorization || '';
  const fullUrl = `http://${req.headers.host}${req.url}`;

  // Path 1: reader has paid, retry with L402 auth header.
  if (/^L402\s+/i.test(auth)) {
    const gate = gateForPrice(BASE_PRICE_SATS);
    const verdict = await gate(req, res);
    if (verdict.authorized) serveArticle(res, { paidSats: BASE_PRICE_SATS });
    return;
  }

  // Path 2: reader has signed a NIP-98 event, prove who they are.
  if (/^Nostr\s+/i.test(auth)) {
    const v = verifyNip98(auth, fullUrl, req.method);
    if (!v.ok) return writeAuthChallenge(res, 401, v.reason);

    const depth = depthFor(v.pubkey);
    const price = priceFor(depth);
    if (price === 0) {
      serveArticle(res, { pubkey: v.pubkey, depth, paidSats: 0 });
      return;
    }

    // Priced by depth: mint an L402 invoice for the exact right amount.
    const gate = gateForPrice(price);
    const verdict = await gate(req, res);
    if (verdict.authorized) serveArticle(res, { depth, paidSats: price });
    return;
  }

  // No auth header. Emit a NIP-98 challenge so the client knows to sign.
  writeAuthChallenge(res, 401);
}

verifyNip98 decodes the base64, parses the JSON, checks kind === 27235, verifies the URL and method tags match the request, confirms created_at is within the last 60 seconds, and runs the Schnorr signature verification through nostr-tools' verifyEvent. Ninety lines of that helper, well-documented in the repo.

buildL402Gate is the factory that handles macaroon minting, invoice creation against LNBits, payment verification, and single-use replay protection. That is in a separate middleware module, scripts/lib/l402-middleware.js, reused across multiple other PowForge services.

depthFor is the piece that changes per deployment. In the demo, it reads a local JSON file mapping hex pubkey to depth score. In production, you would either pre-warm a cache from the /oracle/doi-score API (L402-gated at 2 sats per lookup), or compute scores in-process using the @powforge/identity SDK against events you already have on disk.

The price curve

Deliberately dumb and linear.

function priceFor(depth) {
  if (depth >= FREE_THRESHOLD) return 0;
  const discount = depth / FREE_THRESHOLD;
  return Math.ceil(BASE_PRICE_SATS * (1 - discount));
}

With the defaults of BASE_PRICE_SATS=10 and FREE_THRESHOLD=60, a depth-0 fresh key pays ten sats. A depth-30 mid-reader pays five sats. A depth-59 long-accumulated key pays one sat. At sixty, the invoice goes away entirely.

Nothing in the code insists on this curve. Swap it for a step function, a logarithm, or a lookup table. The point is that the price is a function of the caller and the server can compute it before minting the invoice.

Walking the full flow with curl

From the acceptance test bundled with the repo. Start the server on port 4050, have two known keypairs in the scores.json fixture (high-depth 85 and low-depth 5), and walk the four cases.

Case 1 — no auth at all

$ curl -i http://localhost:4050/article
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Nostr realm="reader-weight", spec="NIP-98", ttl="60"
...
{"error":"unauthorized", ...}

Good. The client knows what to do next.

Case 2 — high-depth signed header

The client (Alby, nos2x, nsec.app, whatever) signs a fresh kind:27235 event with tags ["u", "http://localhost:4050/article"] and ["method", "GET"], base64s the signed JSON, and retries.

$ curl -i -H "Authorization: Nostr eyJpZCI6...=" http://localhost:4050/article
HTTP/1.1 200 OK
Content-Type: text/markdown; charset=utf-8
X-Reader-Depth: 85
X-Reader-Paid-Sats: 0

# The Cost of a Read Is Evidence of a Reader
...

Article served, zero sats charged. The reader's key is their receipt.

Case 3 — low-depth signed header

Same flow, different signer. The low-depth key signs. Server looks up their depth (5), computes the price (ceil(10 * (1 - 5/60)) = 10 sats), mints an L402 invoice, returns it.

$ curl -i -H "Authorization: Nostr eyJpZCI6...=" http://localhost:4050/article
HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 macaroon="eyJ2IjoxLC...", invoice="lnbc100n1p572lg9pp..."
X-L402-Price-Sats: 10
...
{"error":"payment required","scope":"reader-weight:article:10","price_sats":10, ...}

The invoice is real. I ran this against a real LNBits instance and got a real BOLT11 string that a real wallet would pay.

Case 4 — low-depth key pays, then retries

After the reader pays the invoice, their wallet hands them the preimage. They retry:

$ curl -i -H "Authorization: L402 eyJ2IjoxLC...:abc123..." http://localhost:4050/article
HTTP/1.1 200 OK
X-Reader-Paid-Sats: 10
...

Article served. Payment verified. Macaroon burned so the same preimage cannot be reused.

Where I expected this to be harder

Three places, none of which ended up being real blockers.

The NIP-98 signature verification. I thought this would be tricky because Schnorr is not built into Node's crypto module. It turned out that nostr-tools ships a verifyEvent helper that does both the event-id-hash check and the Schnorr signature check in one call. Forty lines of helper code total, mostly parsing and tag-checking.

The L402 macaroon scope per-price. L402 macaroons have a scope field that binds them to a specific endpoint and operation. If I issued one scope and tried to burn it at a different price, the verification would fail. I sidestepped the entire issue by baking the price into the scope: reader-weight:article:10 for ten-sat reads, reader-weight:article:5 for five-sat reads. Each price has its own scope, each scope has its own replay cache. Clean.

The replay protection across NIP-98 and L402. I worried they would collide. They do not. NIP-98 uses a 60-second created_at window. L402 uses single-use preimage caching. They live in separate layers and protect against separate attacks.

Limitations I know about

The demo ships with one article. A real deployment needs routing or an article-id scheme. The NIP-98 window is 60 seconds which is fine for browser-driven reads but vulnerable to an intercept-replay attack within that window. Mitigation is either a shorter TTL or an IP-binding caveat on the L402 macaroon.

The depth scores come from a local JSON file in the demo. Production uses either the oracle API (L402-gated, cached) or the SDK inline. That piece is orthogonal to the auth composition.

The article body is served as markdown. Your frontend is welcome to render it as HTML, stream it, paginate it. The decision layer does not care what you do with the payload.

Source

powforge.dev

Full server.js, full README.md, test fixtures with two deterministic keypairs so the acceptance test runs without editing anything, and a .env.example with the four required variables.

The related examples in the same tree: examples/agent-gate demonstrates pure L402 per-call without the signing layer, and examples/relay-policy demonstrates the depth-based decision applied to a strfry writePolicy plugin instead of an HTTP endpoint. Three integrations, the same underlying primitive, one score.

Why this matters

Paywalls exist because readers have non-zero marginal cost. Account systems exist because businesses want to know who their readers are. Composing NIP-98 and L402 gives you both: a price that scales with the reader's observable investment in the Bitcoin-native ecosystem, and a signature that identifies them without a signup flow.

There is no email. There is no cookie. There is no session. There is a key, a score, and an invoice. That is the shape of a paywall that Bitcoin-native audiences will actually pay.

Build one. It runs in about an hour from a fresh clone.

Depth-of-Identity: Thermodynamic Weight for Cyberspace

Zeke — Sun, 19 Apr 2026 12:20:16 +0000

Canonical: powforge.dev/whitepaper · Nostr: njump.me/naddr1qvzqqqr4gupzpd939hau8h7l4qpmkuhrgnnkrhrcmd8vypvv3kelrsavv0u7g26yqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wsqs6amnwvaz7tmwdaejumr0dsq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqqvxgmmf94hhyctrd3jj6amgd96x2urpwpjhyttkxyavxe22

Depth-of-Identity: Thermodynamic Weight for Cyberspace

How Schnorr keys accumulate mass

Proof-of-work = proof-of-human.

No amount of intelligence buys AI any favors in marshalling 20GWs of electrical work to solve a hash function.

Jason Lowery, author of Softwar, 2026-04-18, responding to a16z crypto and Sam Altman positioning World ID as "the new proof of human for the internet."

Abstract

Most identity systems try to prove you are human. That is the wrong question in 2026. The human/bot dichotomy is broken. Most humans use LLMs. Most bots can pass Turing under a focused use case. The right question is "how much of you is there." A fresh key has zero weight. A five-year-old key that has accumulated irreversible work across proof-of-work, timestamping, social investment, and spatial movement has measurable thermodynamic mass. The Depth-of-Identity Oracle is a priced endpoint that returns that mass as a single score, anchored in Bitcoin-native primitives: secp256k1 Schnorr keys, OpenTimestamps, Lightning, and L402. It does not verify personhood. It prices depth. This paper explains the primitive, the grounding mechanism, and the three buyer segments where depth-pricing is already the real need.

1. The Problem

Sam Altman and a16z crypto recently positioned World ID as "the new proof of human for the internet." Jason Lowery's response fit in three lines and settled the framing argument. Proof-of-personhood rooted in biometric lookup is a narrow claim about what a specific human looks like, right now, to one scanning orb. Proof-of-personhood rooted in irreversible energy expenditure is a claim about how much work a key has done, forever, verifiable by anyone. The second claim survives adversaries that the first does not.

The current identity landscape has four shapes and one missing one.

Biometric systems like Worldcoin stake everything on the iris as identity. Scale is limited by physical scanners. Regulators in Kenya and Spain have pushed back. The assumption that iris equals you is the specific frame Lowery rejects. Social-graph systems like BrightID are gameable through coordinated verification parties and require live video calls. Staked systems like Proof of Humanity ran out of momentum. Biometric-remote systems like Humanode sit in EU regulatory mire with face-scan dependency. Federated and issued systems like W3C DID, Civic, and Disco delegate trust to issuers, which re-introduces centralization under different vocabulary. Web-CAPTCHA systems like Anubis, Cloudflare Turnstile, Cap, and Wicketkeeper are user-experience features, not identity. The cost-of-adversary for those is CA revocation or a JS rewrite, not physical energy. Different category. Often misidentified as the same.

What is missing is a primitive with four properties.

It must be keyless-first, meaning identity is the key itself, not a lookup into a registry. It must be grounded in physics, meaning cost cannot be short-circuited by software. It must be dimensional, meaning it captures multiple axes of "realness" instead of one biometric signal. And it must be agent-native, meaning it works as well for AI agents as for humans, because "human" was the wrong target.

That last property matters most. Agents are not a future consideration. They are infrastructure. Most inbound traffic to API endpoints now originates from LLM-driven code. Most content on public relays is co-authored. A system that can only say "human or not" answers a question nobody needed to ask. A system that says "how much irreversible work has this key done, across how many dimensions, over how long" answers the question that actually scales. That question has a clean answer for humans, for AI agents, and for anything in between that has left a Schnorr-signed trail.

Call this question Depth-of-Identity. It is not a refutation of Worldcoin or BrightID or any of the others. It is one category over. Those systems ask "who." This paper asks "how much." The answer is measurable in sats, in OTS commits, in vouch-hops, in movement events. The primitive exists. The rails exist. The paper that connects them is what was missing.

2. The Primitive: Thermodynamic Identity

The reasoning chain is short and each link is load-bearing.

Start with thermodynamics. Energy expenditure is irreversible. The Second Law says entropy increases in closed systems and work performed cannot be un-performed without greater expenditure elsewhere. This is the ground floor.

Bitcoin is the first network that turns that ground floor into a digital commodity. Irreversible energy produces digital scarcity. A block's weight is not metaphorical. It is thermodynamic mass purchased at the prevailing fee market, made permanent by the chain that follows.

Lowery extends this in Softwar. Proof-of-work is power projection in cyberspace. Nation-states have projected power through kinetic means for centuries. Bitcoin is the first network where cyberspace operations can be grounded in that same physics. An adversary cannot asymmetrically degrade the network without physically strengthening it, because the cost of attack is the same irreversible energy as the cost of defense.

The extension this paper makes is one step further. Proof-of-work is identity projection. You project self, not just power. A key is not who you are. A key is where your signatures come from. The shape of what that key has done over time, across how many domains, at what cost, is who you are.

Five dimensions make the shape legible.

Access is proof-of-work itself. Solves of pow-captcha challenges, pow-gate puzzles, pow-relay NIP-13 work. Each solve is a SHA-256 or Argon2d artifact that costs CPU-seconds to produce. The cost cannot be shortened by intelligence. An LLM cannot out-think a hash function. The chain of solves under a single key is a chain of irreversible work.

Economic is Bitcoin activity. Lightning zaps received and sent, on-chain taproot transactions, LNURL receipts. Every sat that crosses the boundary costs real fee-market dollars. A key that has received zaps from many independent senders over months has spent somebody else's energy to accumulate weight. That spending is verifiable against the Lightning rails and, at greater depth, against the Bitcoin chain.

Temporal is OpenTimestamps depth. An OTS attestation commits a document hash to a Bitcoin block via a Merkle path. A key that has OTS-anchored its creation event, its first vouch, its first signed note, and then more over years, carries a provable ordering. The cost to falsify priority is the cost of rewriting Bitcoin's chain, which is the cost of the cumulative hashrate of the world.

Social is vouches, weighted by the depth of the voucher. A new key vouching for another new key adds nothing. A five-year key that has vouched for twenty other keys has put signal-weight at stake. Vouch cycles must be detected and discounted using graph algorithms like Tarjan's strongly-connected-components, or the social dimension becomes a mutual-vouch laundromat. The @powforge/identity SDK does this discounting client-side at v0.5.2.

Spatial is cyberspace movement. Kind=3333 events on a cyberspace relay encode a key's hop history. Each hop references its predecessor. The chain is path-dependent and cannot be precomputed. A key with a long spatial chain has visibly spent time existing somewhere in the relay graph rather than appearing from nowhere.

The unifier is that all five are signed by the same key. Nostr uses secp256k1 Schnorr signatures. Bitcoin Taproot uses the same curve. One public key serves both domains. That is why a Nostr npub is a valid Taproot address after the conversion step. One key, many chains, all anchored to the same physics.

The depth metric takes those five chains and returns a single number. Chain length matters. Irreversibility cost per hop matters. Cross-dimension diversity matters. A key with 10,000 access solves and nothing else is not as deep as a key with 1,000 access solves, 200 Lightning receipts, 50 OTS anchors, 20 vouches from older keys, and 300 spatial hops. Diversity is the shape of a real actor. Concentration is the shape of a farm.

Normalize the metric to 0-100. Higher means more accumulated irreversible work, which means heavier thermodynamic mass. Lower means the key is either new, cheap, or specialized. None of those are verdicts about humanness. They are measurements of weight.

Three implications fall out of this construction.

Depth is unfakeable without actually doing the work. That is the whole point. Any shortcut that produces equivalent-looking depth has done equivalent work, which makes it equivalent depth in substance as well as appearance.

Depth takes time. That time is the same whether you are a human or an AI agent. An agent that has run for two years, paid its Lightning fees, earned its vouches, and published real content has earned real weight. A human with a fresh key has zero weight until they do the work. The playing field is honest because it is physical.

Depth is earnable without permission. No KYC, no badge, no verified checkmark from a corporation. The rails are public. The work is self-directed. An agent that does valuable things over time naturally earns the weight that valuable things cost.

3. The Grounding

Every piece of the score must trace back to a Bitcoin-native or Bitcoin-adjacent rail. No hand-waving. Here is the table.

Dimension	Rail	Specific Mechanism
Access	PowForge PoW products	SHA-256 and Argon2d solve events logged to Nostr kind:30085 attestations, signed by the solver's npub
Economic	Lightning and on-chain Bitcoin	NIP-57 zap receipts, LNURL receipts verified against the payer's node, optional Taproot transaction observation
Temporal	OpenTimestamps	Merkle-root commitment to Bitcoin block headers through an OTS calendar server, retrievable via `ots verify`
Social	Nostr vouches	NIP-51 follow lists and custom kind:30382 depth assertions, already shipping via `publish-nip85.js`
Spatial	Cyberspace relay	Kind=3333 movement events with path-dependent predecessor references

Each row is traceable to a public primitive. The Access rail runs on the same SHA-256 PoW that Bitcoin runs on, plus Argon2d for memory-hard variants where GPU asymmetry would otherwise break the fairness property. The Economic rail relies on Lightning payment receipts, which are signed by the payer's node and include a payment hash verifiable against the LN graph. The Temporal rail relies on OTS, which Peter Todd maintains and which has been producing free Bitcoin-anchored timestamps for over a decade. The Social rail uses Nostr events, which are signed by secp256k1 keys and gossipped on public relays. The Spatial rail uses the same signing infrastructure plus path-predecessor references that make each event depend cryptographically on the previous.

The oracle's job is not to invent grounding. It is to read these disparate commitments, weight them correctly, and return one score signed by the oracle's own key. Every rail pre-dates this paper. The value of the oracle is that it saves each buyer from reimplementing five different verifiers.

Two caveats belong here and will recur in the gap analysis.

The Access rail has enough solve data to be live today. The Economic rail can read zap receipts and LNURL events but the Taproot transaction reader is not yet wired into the unified endpoint. The Temporal rail is live through OTS. The Social rail ships via the SDK but the oracle-side cycle-discount logic needs to be migrated from client-side to server-side. The Spatial rail exists in code for the cyberspace relay but lacks enough data volume to demonstrate meaningful depth variance. The paper does not claim what does not ship. Section 6 is explicit about which rails are production and which are half-built.

4. The DoI Oracle API

One L402-paywalled endpoint. Paid per query in sats, cached by signature.

POST /oracle/doi-score
Content-Type: application/json
Authorization: L402 <macaroon>:<preimage>

{ "npub": "npub1..." }

-> 200 OK
{
  "score": 73,
  "breakdown": {
    "access":   { "score": 82, "samples": 1847, "oldest": "2024-11-15T..." },
    "economic": { "score": 65, "samples": 234,  "oldest": "2024-12-02T..." },
    "temporal": { "score": 91, "ots_depth": 127, "oldest": "2024-09-01T..." },
    "social":   { "score": 58, "vouches": 42,  "cycle_discount": true },
    "spatial":  { "score": 69, "hops": 3410,  "unique_nodes": 87 }
  },
  "diversity_bonus": 0.12,
  "signature": "<schnorr sig over the full response>",
  "signed_by": "<oracle pubkey>"
}

The response is Schnorr-signed by the oracle's own key. The signature is the product. A buyer who has paid once can cache, verify offline, and present the score anywhere without re-calling the oracle. The macaroon controls the paid-access relationship. The signature controls the trust relationship.

Pricing is agent-friendly. Ten sats per query at the default tier is below the LN commit fee floor for most wallets, which means in practice queries are batched. A 500 sats per day unlimited tier serves agent operators who poll continuously. A 100 sats per 500-query batch endpoint serves publishers who want to score a page of commenters at page-render time.

The handoff semantics matter. An agent that has paid for a score can pass the signed response to another agent as a bearer credential. The second agent verifies the signature against the oracle's published pubkey and accepts the score without making its own paid call. This is how a composite system avoids re-charging every downstream consumer. It also means the oracle can charge once per score and see that score propagate, which is a reasonable trade. Depth is slow-moving. Yesterday's score is almost always today's score plus or minus a few points.

One property of the API is worth naming. The oracle never says "this key is a human" or "this key is a bot." It says "this key's accumulated thermodynamic mass is 73." Interpretation is the buyer's job. A relay might treat 73 as low-friction. An agent marketplace might require 80 to enter a high-trust pool. A publisher might unlock comments at 50. The oracle does not impose policy. It prices the input to policy.

5. Three Buyer Segments

5.1 Agent-to-agent economies

Agent operators running autonomous systems need Sybil-resistance and cannot use KYC. Their counterparties are other agents, which have no legal identity. The current alternative is whitelist-by-API-key, which scales poorly and does not compose across operators. The DoI score is the credential.

The concrete buyer here is every builder shipping on L402. Spark is the clearest named case. Spark runs L402 services under l402.lndyn.com and needs to price incoming agent traffic without letting the cheapest bulk-scrapers starve its expensive work. A DoI-gated L402 middleware reads the incoming request's caller key, calls the oracle, and adjusts the invoice amount. High-depth keys get the base rate. Low-depth keys pay a multiplier. Zero-depth keys either get throttled or pay an anti-farm surcharge. The mechanism is automatic. The policy is a config file. Fewsats, TollGate, GoodBits, and any of the half-dozen teams building LN-paid agent services have the same problem in slightly different shapes.

Integration looks like an L402 middleware plugin. PowForge already ships @powforge/l402 as the middleware factory. Adding a doiMultiplier option is a small API surface change. The selling point is that the agent operator does not have to build a Sybil-resistance stack. They call one endpoint, get a signed score, and apply a formula.

5.2 Nostr relay operators

Relays get spammed by fresh keys. Static allow-lists do not scale. Dynamic difficulty via NIP-13 is better but a fixed difficulty floor punishes new real users while still letting determined farms through. Reputation-weighted difficulty is the better shape, and DoI is the scoring function.

The concrete buyer is any paid or community relay that has already struggled with spam. Relays like nostrbtc have been measuring trust paths locally. Paid relays have payment as their anti-spam mechanism, but a DoI-weighted tier would let them offer better rates to high-depth writers. Niche community relays want policy hooks that do not require the operator to write graph-analysis code themselves.

Integration looks like a relay policy plugin. On write, the plugin calls the oracle with the author's pubkey, receives a score, and applies a difficulty multiplier or a write-fee. Low-depth keys face higher PoW or pay a small LN fee per note. High-depth keys get fast lanes. The relay operator configures the curve. The oracle does the scoring.

5.3 Publisher reader-weight

Publishers on Ghost, Substack, or any long-form platform want to reward returning readers without maintaining accounts. The current options are email capture, which is a privacy tax, or paywalls, which are a friction tax. A DoI-weighted read cost lets publishers charge the entire Bitcoin-native audience zero for read access while charging anonymous fresh keys a small sat fee per article.

The concrete buyer is any creator monetizing a Bitcoin-native audience. Writers who have published OTS-anchored articles on Nostr already have the substrate. Ghost plugins and WordPress filters can call the oracle at page-render time. High-score readers see the article. Low-score readers see a 10-sat paywall. The curve rewards depth of engagement with the broader ecosystem, not just with that one publisher.

This segment is smaller than the first two, but it validates cross-category fit. If the same oracle score serves agent-gating, relay policy, and reader-weight, the underlying primitive is load-bearing. The paper makes the claim that it does, because the underlying measurement (irreversible work under a Schnorr key) is the same thing in all three contexts.

Closing

A fresh key has zero weight. A key that has done work across five dimensions under Bitcoin-anchored rails has measurable thermodynamic mass. The Depth-of-Identity Oracle returns that mass as a signed score. The signature is the product. The rails are public. The oracle saves every buyer from reimplementing five verifiers.

Lowery's one-line framing is the right frame. Proof-of-work equals proof-of-human, because proof-of-work equals proof-of-anything-that-spends-energy-to-exist-over-time. The paper above is the commodity-endpoint form of that statement.

The thesis stops being a thesis when it ships as an API somebody pays for.

Sybil Resistance Without Biometrics: Multi-Dimensional Identity Scoring

Zeke — Wed, 15 Apr 2026 15:58:17 +0000

Most Sybil resistance boils down to one of two things: scan your eyeball, or stake tokens. Both have problems. Biometrics create honeypots. Staking just means rich attackers win.

I've been working on a different approach for the Nostr Web of Trust hackathon and wanted to share the math behind it.

The Core Insight

Instead of one trust score, measure identity across independent dimensions:

Lightning payment history (channel age, routing volume)
Content proof-of-work (consistent posting over time)
Social graph position (follows, vouches, interactions)
Key age and activity patterns

Faking any single dimension is cheap. But faking all of them simultaneously? The cost scales as 2^n where n is the number of independent dimensions.

Three dimensions = 8x the cost of faking one. Five dimensions = 32x. At some point, it's cheaper to just be real.

How It Works

const { DepthScorer } = require('@powforge/identity');

const scorer = new DepthScorer({
  dimensions: ['lightning', 'content', 'social', 'temporal'],
  weights: { lightning: 0.3, content: 0.25, social: 0.25, temporal: 0.2 }
});

const result = await scorer.analyze(pubkey);
console.log(result.depth);      // 0.0 - 1.0 composite score
console.log(result.dimensions);  // per-dimension breakdown
console.log(result.spoofCost);   // estimated cost to fake this identity

Why Multi-Dimensional Beats Single-Score

PageRank-style approaches (what most WoT systems use) collapse everything into one number. That works until someone games the follow graph. A sock puppet can accumulate follows, but it can't simultaneously:

Route Lightning payments for 6 months
Post thoughtful content weekly
Have a key that's been active since 2023
Maintain organic social graph patterns

Each dimension is a different kind of proof-of-work. Not SHA-256 grinding, but life grinding. Time you actually spent being a real person on the network.

Try It

Live demo: powforge.dev/depth (paste any Nostr npub)
npm: npm install @powforge/identity (v0.3.0, 39 tests)
Source: [npmjs.com/package/@powforge/identity

The SDK is MIT licensed. If you're building anything that needs to distinguish real users from bots without asking for personal data, I'd love to hear how you'd use it.

Building this for the WoT-a-thon hackathon. Demo day is tomorrow (April 16) at 3pm UTC on zap.stream/nosfabrica. Come watch if you're curious about the state of decentralized identity.

How I Stopped Form Spam Without reCAPTCHA

Zeke — Wed, 08 Apr 2026 11:39:31 +0000

Google reCAPTCHA started charging after 10k assessments per month. hCaptcha tanks conversion rates with those "click every bus" puzzles. Turnstile locks you into Cloudflare's ecosystem. I got tired of picking between surveillance, vendor lock-in, and a monthly bill just to keep bots off a contact form.

So I built a CAPTCHA that uses proof-of-work instead. No tracking. No cookies. No external dependencies. Self-hosted. Here's how it works and how to add it to any site in about five minutes.

The Problem With Every CAPTCHA

Let's be real about what happened to the CAPTCHA landscape:

reCAPTCHA was free for years, and that made it the default. Then Google introduced reCAPTCHA Enterprise pricing and capped the free tier at 10,000 assessments per month. For a side project getting moderate traffic, you're now paying Google to protect a contact form. And the whole time, reCAPTCHA is collecting behavioral data, setting cookies, and phoning home to Google's servers. If you care about GDPR compliance, that's a headache you didn't sign up for.

hCaptcha markets itself as the privacy alternative, but it still fingerprints browsers and runs third-party JavaScript. And those image labeling tasks? They're literally training ML models. Your users are doing free labor for a company they've never heard of.

Cloudflare Turnstile is genuinely better on the UX front, but it ties you to Cloudflare's infrastructure. If you're self-hosting on a VPS or running behind a different CDN, that dependency starts to chafe.

What all these solutions share: they're SaaS products that run someone else's JavaScript on your page, phone home to someone else's servers, and make you dependent on someone else's uptime.

What if the Browser Just Did Math Instead?

The idea behind proof-of-work CAPTCHAs is simple. Instead of asking "click all the traffic lights," you ask the browser to compute SHA-256 hashes until it finds one with a specific number of leading zero bits. At the default difficulty of 16 bits, that's roughly 65,000 hashes, which takes about 4 seconds on average hardware.

Bots can do this too. That's the honest truth. But here's the thing: it costs them real CPU time per request. A bot that wants to submit your form 10,000 times has to burn 10,000 * 4 seconds of compute. That's an economic deterrent, not a Turing test. Same principle as Bitcoin mining, just at a much smaller scale.

No tracking. No cookies. No network requests to third parties. No behavioral profiling. The browser does math, proves it did the math, and moves on.

I'm not the first person to think of this. ALTCHA does something similar. But I wanted something with zero dependencies, a smaller footprint, and the option to let users skip the wait by paying a Lightning micropayment (more on that later).

Adding PoW CAPTCHA to a Form

Here's the practical part. I'll show you how to add this to an existing HTML form using @powforge/captcha.

Step 1: Add the Script

One script tag. No build step required.

<script src="https://unpkg.com/@powforge/captcha/dist/powforge-captcha.min.js"></script>

That's about 5KB gzipped. Compare that to reCAPTCHA's ~150KB.

Step 2: Drop the Widget Into Your Form

<form action="/submit" method="POST">
  <label for="email">Email</label>
  <input type="email" name="email" id="email" required>

  <label for="message">Message</label>
  <textarea name="message" id="message" required></textarea>

  <!-- PoW CAPTCHA mounts here -->
  <div id="pow-captcha"></div>
  <input type="hidden" name="pf_token">

  <button type="submit">Send</button>
</form>

<script src="https://unpkg.com/@powforge/captcha/dist/powforge-captcha.min.js"
        data-target="#pow-captcha"
        data-server="https://captcha.powforge.dev"
        data-theme="dark">
</script>

The widget renders a small progress bar while the browser mines. When it finishes, a checkmark appears and the hidden pf_token input is auto-filled with a signed token.

Step 3: Verify Server-Side

On your backend, validate the token before processing the form submission. Here's Express:

const express = require('express');
const { verifyToken } = require('@powforge/captcha/verify');

const app = express();
app.use(express.urlencoded({ extended: true }));

app.post('/submit', async (req, res) => {
  const result = await verifyToken(req.body.pf_token, {
    server: 'https://captcha.powforge.dev',
  });

  if (!result.valid) {
    return res.status(403).json({ error: 'CAPTCHA verification failed' });
  }

  // Token is valid. Process the form.
  console.log('Message from:', req.body.email);
  res.json({ success: true });
});

app.listen(3000);

The verifyToken function makes a single POST to your verification server and returns { valid: true/false }. That's it. Two network requests total: one to fetch the challenge, one to verify the solution.

Step 4 (Optional): Use the ES Module API

If you're building a SPA or want more control, there's a module API:

import { PowCaptcha } from '@powforge/captcha';

const captcha = new PowCaptcha({
  target: '#pow-captcha',
  server: 'https://captcha.powforge.dev',
  difficulty: 16,
  theme: 'dark',
});

captcha.on('verified', ({ token }) => {
  document.querySelector('form').submit();
});

captcha.on('progress', ({ percent }) => {
  console.log(`${percent.toFixed(0)}% done`);
});

Benchmarks

I ran this on a handful of devices to get real numbers:

Metric	Value
Time to solve (desktop, M1 Mac)	~2.5s
Time to solve (desktop, mid-range PC)	~4s
Time to solve (iPhone 13)	~6s
Time to solve (budget Android)	~10s
Bundle size	~5KB gzipped
Network requests	2 (challenge + verify)
External dependencies	0
User data collected	0
Cookies set	0
Cost	$0 (self-hosted)

Default difficulty is 16 bits (~65k hashes). You can tune this. Drop it to 10 bits for comment forms where friction matters more than security. Crank it to 20 bits for account registration where you really want to slow down bots.

The Comparison Table

Here's how it stacks up against the options you're probably evaluating:

	PowForge	reCAPTCHA v3	hCaptcha	Turnstile	ALTCHA
Price	Free (self-host)	Free tier, then $8/1k	Free tier, then paid	Free tier	Free (self-host)
Privacy	No tracking	Google behavioral tracking	Browser fingerprinting	Cloudflare tracking	No tracking
Self-hosted	Yes	No	No	No	Yes
Dependencies	None	Google JS (~150KB)	hCaptcha JS (~120KB)	Cloudflare JS (~80KB)	None (~30KB)
Setup time	~5 min	~10 min	~10 min	~5 min	~5 min
Open source	MIT	No	No	No	MIT
Cookies	None	Yes	Yes	Yes	None
Works offline	Yes (once loaded)	No	No	No	Yes (once loaded)

The closest comparison is ALTCHA. Both are open source, both use proof-of-work, both can be self-hosted. PowForge is smaller (~5KB vs ~30KB), and adds a Lightning payment option where verified users can skip the wait entirely. ALTCHA has been around longer and has a bigger community. Pick whichever fits your stack.

What PoW Doesn't Solve (Honest Trade-offs)

I'd rather you know the limitations upfront than find out after deploying this to production.

Targeted attacks. If someone specifically wants to spam your form, they can throw GPU power at it and solve challenges fast. Proof-of-work raises the cost, but it doesn't make it impossible. Then again, reCAPTCHA v3 gets bypassed by dedicated attackers too. No CAPTCHA is a silver bullet.

Mobile performance. Budget phones take 2-3x longer than desktops to solve a challenge. A 4-second wait on a laptop becomes 10 seconds on a three-year-old Android. For mobile-heavy audiences, drop the difficulty to 10-14 bits or you'll hurt your conversion rate.

Battle-tested scale. Cloudflare Turnstile handles billions of requests. This doesn't have that track record yet. If you're running a site with millions of daily submissions, I'd be honest and say this hasn't been proven at that scale.

Accessibility. Users with very old devices or limited hardware will wait longer. There's no audio CAPTCHA equivalent. For sites with strict accessibility requirements, consider offering the Lightning skip as an alternative path.

GPU farming. An attacker with a GPU can solve SHA-256 challenges orders of magnitude faster than a browser can. The roadmap includes Argon2-based challenges (memory-hard, GPU-resistant) to address this. Not there yet.

When This Makes Sense

This fits best when:

You're protecting contact forms, comment sections, or registration pages
You value user privacy and don't want Google tracking on your site
You're self-hosting and want full control over the infrastructure
Your traffic is low-to-medium (under 100k submissions per day)
You're building something in the Bitcoin/Lightning ecosystem and want the Lightning skip feature

It probably doesn't fit when:

You need enterprise-grade bot detection with ML behavioral analysis
You're processing millions of submissions daily and need proven scale
Your audience is primarily on budget mobile devices
You have strict accessibility compliance requirements (WCAG AAA)

Self-Hosting the Verification Server

You don't have to use the hosted endpoint. The verification server is a single Node.js file with zero npm dependencies for core functionality:

git clone https://www.npmjs.com/package/@powforge/captcha
cd captcha
node server.js
# Listening on port 3077

Point the widget at your own server:

<script src="powforge-captcha.min.js"
        data-target="#captcha"
        data-server="https://your-domain.com:3077">
</script>

Three endpoints. That's the whole API:

Endpoint	Method	What it does
`/api/challenge`	GET	Returns a new PoW challenge
`/api/verify`	POST	Accepts a solution, returns a signed token
`/api/token/verify`	POST	Server-side token validation

Try It

There's a live demo at powforge.dev/captcha where you can solve a challenge and see how it feels. The source is on GitLab. The npm package (@powforge/captcha) is coming soon.

If you build something with it, I'd genuinely like to hear about it. Open an issue on the repo or find me on Nostr.

Built by an indie dev who got tired of paying Google to protect a contact form.