Bootstrapping an Immutable Ledger

How we turn WebAuthn signatures into a chain of blocks: a genesis block starts each ledger, every new block links back to the one before it, and independent ledgers can cross-propagate each other's hashes for extra tamper-evidence.

Bootstrapping the chain

Genesis Block seed signers + bootstrap rules hash: G0 Block 1 prev_hash: G0 transactions hash: H1 Block 2 prev_hash: H1 transactions hash: H2 Block 3 prev_hash: H2 transactions hash: H3 ... created once, never repeated each block signed by WebAuthn credentials, then locked

1. Bootstrap

Every ledger starts with a one-time genesis block: it registers the first set of WebAuthn signers and the rules that will govern the chain (sign thresholds, modes, entitlements).

A Register founder / seed signers
B Fix ledger mode + strength rules
C Publish genesis hash

2. Build & Sign Blocks

Requests (transfers, content, entitlements) queue up, get bundled into a block, and the block hash is signed with the same WebAuthn credential used for login — proving who authorized this exact state.

A Collect pending requests
B Hash block = f(prev_hash, txns)
C Signers attest with passkey

3. Immutability

Because every block embeds the previous block's hash, changing any past block would break every hash after it — the same tamper-evidence idea as a public block chain, without needing a public token network.

A prev_hash links blocks together
B Any edit invalidates later hashes
C Signers can independently verify

Two ledger modes, same chain mechanics

Token incentive mode

Ledger issues its own unit of value (credits / tokens) that signers and contributors earn for building and signing blocks. Useful for community or public-facing ledgers that need an incentive to keep participants active.

  • Balances tracked per account inside the ledger
  • Rewards paid out per signed block / content submission
  • Good fit: public utility ledgers, community networks

Corporate mode

No token or balance layer at all — the ledger only records and signs the organization's own data (contracts, approvals, audit events). Signing is a compliance/audit action, not an economic one.

  • No balances, no incentive accounting
  • Signers are employees / officers with entitlements
  • Good fit: internal audit trails, regulated record keeping

The block-building and WebAuthn-signing engine underneath is identical — only the request types and reward logic differ per mode.

Cross-propagation across many ledgers

The platform can run 100+ independent ledgers side by side. Each ledger can anchor another ledger's latest block hash into its own next block — so tampering with one ledger becomes visible to every ledger that anchored it.

Ledger A hash H_a Ledger B hash H_b Ledger C hash H_c Ledger D hash H_d Ledger E hash H_e Ledger F hash H_f + 100 more ledgers each arrow = "next block includes peer's latest hash as anchor"

Why cross-propagation matters

Single ledger

Tamper-evident on its own — a rewritten block breaks every hash after it, but only within that one ledger.

Cross-anchored ledgers

Every anchoring ledger holds an independent, signed copy of a peer's hash — rewriting history would also require rewriting every ledger that anchored it.

Block hash formula
block.hash  = SHA512(prev_hash + txns + block_number)
block.anchor = { ledger_id: peer_latest_hash, ... }
signature    = webauthn_sign(block.hash)

Animated flow

Genesis
→
Build Block
→
Sign Block
→
Cross-anchor