Pre-Confirmed Anchor Pool

How the demo keeps instant UX without weakening the strict verification principle.

The problem it solves

Bitcoin block confirmation takes about 10 minutes on average. A naive demo has two bad choices:

IronIP rejects both. Instead, it maintains a pool of anchors that have already gone through the full register → confirm cycle and are ready to use immediately.

How the pool works

  1. A scheduled Lambda (pool-refresher) runs every 30 minutes.
  2. It checks the depth of available anchors in the ironip-anchor-pool DynamoDB table.
  3. If the depth is below target (default: 50 available anchors), it triggers a bulk-register batch of 32 new anchors in a single Bitcoin transaction.
  4. Newly anchored devices enter the pool as status: pending.
  5. On subsequent refresher runs, any pending entries that are now mined get their block header + Merkle proof fetched, and are promoted to status: available.
  6. Each bulk-register batch costs approximately $0.00004 — effectively free for ongoing maintenance.

How demo sessions use the pool

  1. User lands on the demo page.
  2. UI calls POST /pool/claim which atomically marks one available anchor as claimed.
  3. The demo proceeds using that confirmed anchor — all verifications pass all 8 steps, strict mode.
  4. When the user clicks "register", a real Bitcoin transaction broadcasts (real txid visible on WhatsOnChain).
  5. The UI transparently explains: "Your anchor is pending (~10 min). Demo continuing with pre-confirmed device HWT-XYZ. Your new anchor will join the pool for the next visitor."
  6. ~10 minutes later, the user's anchor confirms and enters the pool.
Every verification in the demo is strictly correct. The pool preserves the honest "all 8 steps pass against real confirmed Bitcoin PoW" guarantee. There is no policy exception, no "pending allowed" bypass.

Why this is the honest architecture

This isn't a shortcut — it mirrors how IronIP would actually work in production:

Pool sizing

Target pool depthBulk refill batch sizeTypical refill frequencyMonthly cost
50 anchors32 anchors / 1 Bitcoin txDaily to weekly depending on demo volume< $0.01

Each anchor supports 32 modifiers × 3 collision counts = 96 unique IPv6 addresses, so 50 anchors provide up to 4,800 demo addresses at any moment. Plenty for any realistic demo load.

Pool table schema

{
  "tokenId":       "HWT-POOL-ABC123",        // primary key
  "status":        "available" | "claimed" | "pending",
  "confirmedAt":   "2026-04-18T09:30:00Z",
  "blockHeight":   940511,
  "txid":          "...",
  "params": {
    "modifiers": [ ... 32 hex strings ... ],
    "publicKey": "...",
    "blockHeader": "...",
    "merkleProofTx": [ ... ],
    "modifierProofs": [ ... 32 proofs ... ]
  },
  "claimedBy":     "session-uuid" | null,    // if claimed
  "claimedAt":     "..." | null
}

Monitoring

A CloudWatch alarm watches pool depth:

The refresher Lambda emits the ironip/pool/available_count metric on every run. Burst demo traffic that depletes the pool faster than the 30-minute schedule can refill triggers an immediate refill before users experience empty-pool errors.

Failure modes

See also