Payment Middleware + Session Auth

Devices that prove who they are, authenticate sessions, and pay for exactly what they use. All anchored to one Bitcoin-rooted key.

Future work (Tier 6c). Not built yet. Documented as the natural next layer on top of IronIP identity, BRC-52 attributes, and PushDrop revocation. See docs/payment-middleware-future.md for the full architecture.

The Fourth Layer

IronIP today answers who is this device? via BCA network-layer identity. The broader vision stacks four layers on top of that answer, each using the same Bitcoin-anchored key:

Layer	Question	Primitive	Tier
Identity	Who is this device?	BCA (anchored IPv6)	Current
Attributes	What properties does it have?	BRC-52 certs	6a
Revocation	Is the identity still valid?	PushDrop UTXO	6b
Session	Are both parties authenticated?	BRC-103 mutual auth	6c
Payment	How does it pay for access?	BRC-29 channels / HTTP 402	6c

The crucial property: every one of these uses the same anchored key. BCA anchors a public key. BRC-52 attests about that key. BRC-103 authenticates sessions using it. BRC-29 payment channels flow between wallets holding it. One anchor, four capabilities stacked cleanly.

What This Enables

Pay-per-API-call without accounts

No sign-up, no credit card, no OAuth. Device presents BCA + micropayment. First call gets through. No account to hack or revoke. The Bitcoin payment is the authorization.

Pay-per-minute VPN / IPsec tunnel

IronIP-authenticated IPsec tunnel gains a payment channel. Tunnel lifetime and bandwidth metered. Stop paying, tunnel torn down. No monthly plan — pay for the connectivity you actually use.

Mesh-to-mesh paid resource exchange

Device A has spare bandwidth or compute. Device B needs it. Both IronIP-identified. Both use BRC-103 for session auth. Both settle via BRC-29 channel. No centralized broker. True peer-to-peer paid service exchange.

Federated identity + payment across trust domains

Device consumes a service in another region or company. No shared PKI, no business relationship. IronIP proves identity. BRC-103 establishes session. BRC-52 proves any required compliance attributes. BRC-29 handles payment. Bitcoin is the shared trust root for all four layers.

IoT "plug-and-pay"

Device ships from factory with a BCA anchor + preloaded wallet holding a few cents of BSV. First time it connects anywhere, it pays its way in, authenticates, gets onboarded. No provisioning dance. No enrollment step. No per-vendor app.

Payment Models on the Table

Pay-per-request (HTTP 402)

Device sends request with X-IronIP-Payment header. Service verifies BCA (identity) plus payment (authorization). Returns 402 if missing, 200 if both valid. Best for ad-hoc API calls.

Streaming / pay-per-packet (BRC-29 channels)

Session established via BRC-103. Payment channel opened alongside. Service issues streaming payment requests as usage accrues; device signs, channel balance updates locally. Settle on-chain on close or periodic checkpoint. Best for continuous connectivity.

Prepaid quota

Device buys N credits up front. Service draws down on each request. Low per-request overhead once established. Best for predictable workloads.

Tiered (BRC-52 + BRC-29)

BRC-52 cert attesting "Tier Premium" gets free access up to a threshold. Over threshold, pay-per-use via BRC-29. Cert is the entitlement; payment is the burst capacity.

Why This Matters More Than "IoT Payments" Sounds

Most discussions of IoT payments imagine crypto-enthusiast niches. The actual market is operational:

Every cloud provider charges per-request or per-GB today. IronIP+BRC-29 replaces the billing backend with direct cryptographic settlement.
Every API vendor operates an accounts-and-billing system that's expensive to build and painful to use. Direct micropayments bypass this entirely.
Every IoT fleet has a provisioning story that costs money and time. BCA+BRC-29 makes fleets self-onboarding.
Every cross-border transaction today has currency conversion, fraud prevention, and settlement overhead. BSV is single-currency, single-settlement.

The compelling pitch: your API, priced in BSV, with no billing infrastructure to maintain. Your IoT fleet, paying its own connectivity. Your cross-region service federation, without treaty or trust agreement.

Integration With Existing Tiers

Tier 1 adapters: optional payment middleware per endpoint. /protected/hello could cost 1 sat; /protected/premium 100 sats.
Tier 2 NGINX/Envoy: payment verification via the same shared library used by Lambda adapters.
Tier 3 IPsec / WireGuard: tunnel establishment triggers payment channel open; tunnel teardown triggers channel close.
Tier 4 IPv6 extensions: SAVI could drop packets from devices not currently paying (interesting edge case, not always desired).
Tier 5 federation: mTLS certs and SPIFFE SVIDs carry pricing metadata.

Why Deferred

The portable showcase story (Tiers 1-5) lands first. Prove IronIP works everywhere before adding economics.
Payment adds a second wallet (service wallet) and channel state management — more moving pieces than the clean identity-only story.
Pulls in more BSV surface area. The clean "we only borrow proof-of-work" pitch for BCA gives way to "we use the BSV payment stack as well," which is a bigger ask of skeptical audiences.
Best built after at least one pilot customer expresses a need for paid connectivity — until then it's speculative.

What's Already Compatible

Nothing needs to change in the current IronIP architecture to accommodate this later:

Devices already have anchored key pairs (used for BCA identity).
Shared verifier library is designed as a pipeline — payment verification is a step 10 added later.
Adapters are thin shims; each can gain a requirePayment config option.
Frontend's existing config-driven API layer accepts additional headers (X-IronIP-Payment) with no structural change.