IronIP in 5 Minutes

What IronIP is, how it works, and when to use it. Written to be skimmable and shareable.

The problem

Every IPv6 device needs a cryptographic identity to prove it is who it claims to be on the network. The existing standard — CGA (RFC 3972) — requires each device to perform its own proof-of-work. At meaningful security levels this takes ~696 seconds per address. For resource-constrained IoT devices that's impractical. For fleets of millions of devices it's impossible.

The alternative — PKI with per-device certificates — works at small scale but breaks down operationally at IoT scale. Certificate distribution, revocation, renewal, and CA trust assumptions all become liabilities when you have 10 million devices.

The idea

Bitcoin miners already perform massive proof-of-work. Every block header represents trillions of hash computations. What if devices could borrow that work instead of doing their own?

That is IronIP. A device's public key is anchored to a Bitcoin transaction via OP_RETURN. The block header that mines that transaction carries the proof-of-work. The device's IPv6 address is then derived from a hash of the block header, the transaction, and a random modifier. Verification is pure hash operations: check the Merkle proofs, check the block header's PoW, recompute the address. No certificates. No PKI. No online verification service.

The result: 89-bit security in under a millisecond, at a cost of $0.00004 per anchor. Each anchor supports 32 addresses. The security comes from the entire Bitcoin mining network — not the device's own CPU.

How it works (30-second version)

A device registers: its public key hash plus a Merkle root of 32 random modifiers goes into a Bitcoin OP_RETURN transaction. One-time cost: ~$0.00004.
The transaction confirms in a block. The block header carries the proof-of-work.
To generate an IPv6 address, the device computes one SHA-256 over (modifier, block header, subnet prefix, collision count, transaction). The leftmost 64 bits become the interface identifier.
Any peer can verify the address by running the 8-step verification using the BCA parameters (modifier, public key, transaction, block header, Merkle proofs). All hash operations. <1ms.

Where it fits

IronIP is a network-layer identity primitive. It complements rather than replaces application-layer auth.

Cloud auth (OAuth, JWT, etc.) answers "is this device authorized to DO this thing?"
IronIP answers "IS this device who it claims to be?" — at the IPv6 address level, verifiable by any peer, offline.

Both are needed. IronIP makes the hardware root of trust more valuable, not less, because it becomes the root of a permanent, provider-independent identity.

Where it works

Reverse proxies: API Gateway, ALB, CloudFront / Lambda@Edge, NGINX, Envoy — see Adapters
Transport: IPsec (IKEv2 identity), WireGuard peers — see IPsec Integration
IoT Core: BCA IPv6 as the auth credential via Custom Authorizer
mTLS / SPIFFE: BCA-anchored X.509 certificates and SVIDs
On-prem: fully AWS-independent via params-in-header; standalone verifier has zero dependencies

What it doesn't solve

Be honest about scope. See Known Limitations.

Public-network source-IP spoofing — BCA proves the identity was registered, not this packet came from that device. For public networks, pair with IPsec or application-layer signing.
Revocation — not built yet. The PushDrop revocation mechanism is on the roadmap.
Paid access / metered connectivity — not built yet. Payment middleware with BRC-103 sessions and BRC-29 micropayment channels is on the roadmap.
Application-layer authorization — IronIP is network-layer only. You still need RBAC, scopes, lifecycle management, etc.

The Bitcoin question

"Isn't Bitcoin a liability?" Short answer: IronIP uses Bitcoin as infrastructure, not as currency. No one buys, sells, or holds Bitcoin for investment. See Bitcoin as Infrastructure for the full framing.

Chain-agnostic by design — works on BSV, BTC, or BCH with a config change. The word "Bitcoin" doesn't need to appear in customer-facing material; it can be described as "distributed proof-of-work anchoring."