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

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.

推荐订阅源

DEV Community