The PolicyBlockchain Whitepaper

01Status of this document

This paper describes the design of PolicyBlockchain and the state of the network on the date above. It describes mechanisms, not offerings. Nothing in it is an offer of any financial instrument, or a statement about the price or value of anything. Each item is marked Live, Built, Being built, Planned, Draft or Open.

02Abstract

Insurance runs on the same handful of facts: who is covered, what happened, who paid, who owes. Those facts are copied by hand into a dozen different systems, each one a little more stale and a little less trustworthy than the last. Carriers re-key what agencies already entered. Regulators wait weeks for reports that already exist somewhere. Capital prices risk on numbers nobody can independently verify.

PolicyBlockchain is the fix: report once, to one place, and everyone entitled to see a record reads it from there. It is a reporting standard the industry did not have, built so that anyone can write to it for free and nobody can read more than they are allowed to. It is not a token pitch.

Technically, PolicyBlockchain is the whole network, managed by IEC (InsurEco Ecosystem): two chains, the Tawa Reserve and the contracts, together. It is private and permissioned. PolicyBlockchain runs two chains: Settlement and InsureBio. The main genesis chain, chain ID 1117710, is the settlement chain. It runs on Hyperledger Besu with QBFT consensus on IEC's own validators, and it is live. There are two chains. The InsureBio chain, chain ID 1140615, holds identity, policies and data-access grants. It is being built, and it checkpoints into the settlement chain. Records on the chain are fingerprints and pointers. The underlying insurance records stay with the parties entitled to them, so personal data can be corrected or deleted without breaking the chain. Septor, the platform's hash-chained audit log, is the write interface and the event language. The chain is where those records are agreed and checkpointed.

03The problem

Insurance suffers from a trust problem that is really a record problem. Policy terms can be disputed. Endorsement histories get lost. Claims records are siloed. Audit trails are incomplete. Data vendors resell the same public dataset a hundred different ways, each copy a little more degraded than the source.

A shared record has to handle the following, and a design that misses any of them fails somewhere that matters:

04Design principles

Two rules, and everything else follows from them.

1. Writing is free and open. Any system of record (an agency management system, a rating engine, a claims platform, a government data source) can report to the chain at no cost, through a certified connector. Every report makes the network more valuable, and "any system can report at no cost" is the sentence that lets a regulator trust it.
2. Reading never leaves. Apps come to the data; the data never goes to the app. A plugin runs inside the network, reads only what its owner explicitly scoped it to see, and never touches the outside internet.

Two further commitments shape every section below. Fingerprints on chain, data off it. Hashes and pointers are permanent; personal data is not. Corrections are new entries. After commit, a correction is a linked event rather than a rewrite, so the hash chain stays valid.

05Architecture

Two ways to get this wrong

Renting someone else's chain means a recurring bill for infrastructure you do not control, on a roadmap you do not set. Building one chain and hoping it scales is the other failure mode, and the more dangerous one, because it fails exactly when you succeed. If the network captures real share of the market and lets third parties build on top (telematics streams, parametric triggers, high-frequency plugin reads), volume stops being thousands of events a day and becomes unbounded. A single chain that gets congested in public, after being sold as the standard, is the outcome to design against from day one.

Two volume categories, not one

• Insurance-of-record events (binds, endorsements, claims, trust movements) are bounded by the real world. This is a different kind of workload than retail payments or social platforms.
• Everything built on top (telematics and IoT streams, parametric triggers polling weather or market feeds, plugin reads, machine-to-machine microtransactions) is genuinely unbounded.

These two categories must never share the same execution layer.

A mesh, not a monolith

The design is two chains, kept apart on purpose: PolicyBlockchain runs Settlement and InsureBio. Settlement (chain 1117710) is the money book. It holds the Tawa Reserve, which is the reserve bank account plus the daily signed check, and the contracts built on it. It is live, on IEC's validators. InsureBio (chain 1140615) is the records book: identity, policies and data-access grants. It is being built, and it checkpoints into settlement. A new chain is split off only for a different trust group, volume or legal residency, never for a product line. Jurisdiction is a tag on InsureBio records, not a chain: tenant_id, program_id and jurisdiction already exist in the Septor event schema. Growth means that, if volume or residency ever calls for it, another chain is added, rather than hoping one chain gets faster.

• Each chain is a self-hosted, permissioned EVM chain (Besu-class, QBFT consensus, no mining, instant finality). EVM means standard Solidity contracts, tooling, audit firms and AI-assisted development.
• Validators run on hardware already in the plan. IEC operates them at launch and hands them to partners over time.
• High-frequency signal never touches the settlement chain directly. Raw telemetry flows through its own streaming or oracle layer; only the outcome (a trigger fired, a threshold crossed, a claim opened) becomes a Septor event on the relevant chain.
• The InsureBio chain posts a periodic Merkle root, not continuous transaction data, into the settlement chain IEC operates. That preserves "verify against a root without trusting our database", the property Septor was designed around.

The network today

Why QBFT, and why permissioned

• Immediate finality. A block is final as soon as it is committed. That is what a ledger that records deposits and policy events needs.
• Permissioned by construction. Validators are a known set of keys. No staking, no mining and no token are needed to run it.
• Byzantine fault tolerant. It keeps going with up to f faulty or malicious validators out of 3f + 1, unlike Clique-style proof of authority. It is Besu's recommended consensus for enterprise networks.
• Insurance records are never part of a public chain. They live on IEC's own permissioned chains.

Fault tolerance

QBFT stays live with f offline validators when there are at least 3f + 1. Four validators is the smallest network that survives one failure. Five or six still tolerate only one, and the next useful step is seven, which tolerates two. This was tested: with one node stopped blocks continue; with two stopped they halt; with them restarted the chain recovers by itself, with no data lost.

Node tiers

Tawa is a writer, not a validator. Tawa services read and write through a Tawa-run RPC node and a chain gateway service, never through a validator's RPC. Connectivity is a real requirement given the physical deployment (agency boxes, rural nodes). Node software at every tier needs to tolerate a node going dark and resyncing, which standard permissioned-chain software supports. That is to be validated during implementation, not invented.

06The InsureBio chain

The InsureBio chain, chain ID 1140615, is the records book. The settlement chain is the money book. The InsureBio chain is being built and is not live yet. What follows is the design.

What it holds

• Identities. Bio-ID identities and each entity's iecHash, its permanent chain address.
• Entities. Agents, agencies, MGAs and carriers.
• Policies and binds. Each recorded with a fingerprint of its terms.
• Appointments. Carrier-to-agency appointments and their history.
• Data-access grants. Who may see which record, and when that was granted or revoked.

Like the settlement chain, it holds fingerprints and pointers. The records themselves stay in the InsureBio registry, and access is granted party by party. Jurisdiction, such as Tennessee, is a tag on the records, not a separate chain.

Who runs it

How it connects to settlement

Money and records have different jobs. Money needs to be fast and controlled by the company responsible for it. Records need several independent parties vouching for them. Keeping them apart means a flood of records never slows a payment, and the partners vouch for records without holding the keys to the vault. Every so often the InsureBio chain checkpoints a Merkle root of its recent blocks into the settlement chain, so a record can be shown to have existed, unchanged, as of a given moment. Status: Planned. The checkpoint cadence is Open.

Today, the public entity lookup reads InsureBio entities and their Septor event chains, and checks each chain's hashes. The InsureBio chain is the agreed, checkpointed home for those same records.

07Identity and roles

Every participant needs a Bio ID, a keypair (hardware-backed where the role warrants it) and an address. This is the same identity primitive used everywhere else in the ecosystem (Passport, SSO, wallet identity), not a chain-specific bolt-on. Every entity also has a permanent chain address, its iecHash, which is how events attach to the entity they concern.

Key management. Hardware keys where the role's stakes justify it (validators, Cabinets, oversight offices), with rotation and revocation as first-class operations, and addresses that resolve to identities rather than raw public keys.

Device identity. Cabinets, Terminals and Viewer satellites are identities in their own right, not just endpoints authenticated as their owner. A compromised device can be revoked without touching the owner's own Bio ID, and every write carries a device-level provenance trail (which box reported this) in addition to the owner-level one (which agency authorised it).

Roles and consensus. Validators order and approve blocks. Writers submit signed records on an agency's behalf. Full nodes (regulators, developers) run their own copy for independent verification. Light clients hold a fingerprint and summary view without running infrastructure.

08Reporting and plugins

Open to report, closed to leak. Two kinds of thing plug in, and they get different rules.

Reporting connectors: free, and they write

Insurance software and vendors build connections so their systems report straight to the chain: agency management systems, policy and rating systems, claims platforms, premium finance, payments and e-signature. Reporting is free because every report makes the network more valuable. Charging vendors to report would slow the thing you most want.

• An SDK plus ready-made mappings to ACORD and AAIS formats, so vendors are not starting from scratch.
• The customer authorises the vendor to report on its behalf. The record is signed by both the vendor and the customer's Bio.
• Every report goes through a staging window: pending, validated, committed. After commit, corrections are added as linked entries, never an overwrite. This is the pattern Septor already uses for PII redaction, generalised to every reported record.
• A vendor certification test runs on a sandbox chain before going live.

Plugins: third-party apps that read, and nothing leaves

Apps built by partners run inside the ecosystem and read permissioned chain data. The app comes to the data; the data never goes to the app.

• Inside the network. Plugins run on the platform, never on the vendor's own servers.
• No way out. Plugins cannot reach the outside internet.
• Declared scopes. Each plugin lists exactly what data it needs; the customer approves it, and the permission graph enforces it.
• Results stay in the ecosystem. Answers go back to the user in the product they were using.
• Signed and reviewed. Plugin code is signed and reviewed before listing, every read is logged, and access can be revoked instantly.

Examples: loss control scoring, actuarial pricing tools, exposure maps, fraud checks, certificate tracking for lenders and contractors, regulator dashboards. Licensed third-party logic, such as a commercial catastrophe model, runs as a hosted plugin so the vendor's IP stays under its control. Whether specific vendors will accept that arrangement is Open.

09Reference data

A third category of data sits beside insurance-of-record events and plugin reads: external, shared, read-heavy reference data. A public agency publishes a dataset, and five hundred companies each pull their own copy, run their own cleanup and repackage it. Every copy degrades a little differently from the source, nobody can prove which version is right, and the same normalisation is redone five hundred times.

It behaves differently from the other two tiers: it is large, updated on a schedule rather than streamed, read far more than written, and not scoped to any one tenant or program. Weather does not have a program_id. It needs to be shared across chains, not replicated into each one.

1. Ingest once, at the source, through the Universal Write Gate, from authoritative public sources.
2. Hash and anchor the raw data before any cleanup touches it, so anyone can verify "this is what the source published, and when".
3. Clean up as a separate, versioned, linked layer, never overwriting the raw. Each cleaned version links to the exact raw commit and pipeline version that produced it.
4. Everyone reads the canonical cleaned copy through the plugin sandbox, instead of each running their own scraper.

The pitch is airtight for genuinely public data. It does not automatically extend to licensed commercial models: redistributing their outputs without a data-licensing agreement is a legal problem, not a technical one.

10Audit and Septor anchoring

Septor is the transaction language. When a service calls septor.emit() it publishes a permanent, hash-chained record. Three calls cover the model: emit to make something permanent and auditable, query to read the history, verify to prove nothing was tampered with.

verify(iecHash) walks an entity's entire chain and validates every hash link. If any event was modified, the chain breaks and verification fails. The entity lookup on this site runs it.

Standard event taxonomy

Events use {resource}.{action} names, lowercase and dot-separated, so the explorer displays them consistently and regulators can query them. The categories are entity lifecycle, token and access, policy lifecycle, appointments and licensing, claims, regulatory, and premium finance (premium, commission and trust account events).

Financial events and regulatory hold

Financial events carry tenant_id, program_id, trust_account_id and fiduciary_role, so an examiner can prove fund segregation from the chain alone rather than trusting application-layer query scoping. Insureds can revoke their data, but fiduciary law requires trust account records for years. Events marked regulatory_hold survive revocation: personal fields are redacted from the payload, the financial fields remain, and the redaction is itself a new event, so the hash chain stays valid.

Anchoring

Septor remains the write interface and event language. The settlement chain is what Septor's hash chains anchor to. The InsureBio chain posts a periodic Merkle root into the settlement chain, which makes a record verifiable against a root no single party controls. Archived segments can be validated against the anchored root without loading the full chain. Status: Planned. The exact anchoring cadence is Open.

11Custody and signing

This section states the roles that the design settles. Key custody for agencies, including hosted and device-held modes, is still being designed and is not described here as decided.

• A validator cannot forge a writer's signature. Writes are signed by the writer's own key. A validator can order and include what writers have signed. It cannot create or alter it.
• Validators see fingerprints and pointers, not the underlying insurance records.
• Writers are not validators. Signing blocks is a different job from signing an agency's records, and a validator key on an office device raises the stakes of a stolen device.
• Tampering is detectable. The InsureBio chain's state is anchored by periodic Merkle roots into the settlement chain, and writers keep their own signed copy of every write they submit.

12The Tawa Reserve

Where the network issues balances (prepaid network credit, promotional credit and points), the rule is mechanical and the evidence is on the chain. The reserve and its contracts are designed to live on the settlement chain, chain 1117710. The Tawa Reserve is the reserve bank account plus the daily signed check. Every Tawa is minted only against a Tawa Reserve deposit. This section describes the mechanism as a verifiability feature. Status: Built and tested. Not deployed. Not audited. The contracts are version 0, with no upgrade path: a fix means deploying a new contract and migrating.

The locks

1. No creation without a matching, unused settlement ID. A deposit is recorded only once the bank transfer has settled, not when it is sent, because returns can come back after a transfer clears.
2. A daily signed attestation. A checker compares the bank balance with what is owed. A round finalises when the required number of distinct checkers sign the same result (one to start, M of N later).
3. Automatic pause. Creation is allowed only if the contract is not paused, the latest attestation passed, and the last passing one is not more than 48 hours old. A later failing check closes creation again.
4. Separated roles. No account can hold both the checker role and the minting role. This is enforced when a role is granted and again at use. A pauser can pause but cannot unpause; unpausing needs the administrator, intended to be a multisig.
5. Everything is evidence. Every deposit, creation, reduction, expiry and check is recorded on the chain. Recording deposits and reducing balances still work while paused: pause stops creation only.

Before any real use: a contract security review, a key-ceremony test, and a full dry run of the deposit-to-attestation cycle. Signing keys are never read from environment files or committed to code.

13Security and operations

• Keys. Each validator generates its key on first boot, on the node. Only its address and node identifier leave the machine. No keys are in source control, and the nodes hold no unlocked accounts. Transactions arrive pre-signed.
• Network isolation. Validators sit in a dedicated private network behind a cloud firewall and a host firewall. Peer-to-peer traffic is allowed only between validators, and peers come only from a static list (discovery is off). RPC is reachable only from the private network and the platform build host. Metrics are private. SSH is limited to an explicit allow-list. From the internet, the RPC, metrics and peer ports are filtered.
• Minimal RPC surface. Only the ETH, NET, QBFT, WEB3 and TXPOOL APIs are enabled. There is no ADMIN, DEBUG or account API. QBFT is exposed so votes can be cast, but a vote takes effect only with more than half of the validators.
• Backups. Each node is backed up nightly in its own time slot, so two are never down together. A backup first checks that all other peers are connected, then stops the node, takes a consistent snapshot, restarts it and copies the archive off the machine to versioned object storage. A node's archive can restore any node, and any one healthy node is itself a copy of the chain.
• Monitoring. Block height, peers and block production are scraped continuously, with an alert if blocks stall. The public network map shows health only: validators online, block height, block time and time since the last block. It never publishes IP addresses, node identifiers or validator addresses.
• Upgrades. The client is pinned. Upgrades roll one node at a time, confirming it imports blocks before the next. EVM milestones are scheduled with a future activation time, with every node holding the same genesis file well before it.
• Failure. With one validator down, blocks continue. With the quorum lost, the chain halts and resumes on its own when a quorum returns. No data is lost.

What is fixed at genesis

14Governance

Who does what

The settlement chain is live, with IEC running its validators. The InsureBio chain is being built and is not live yet. Its validator set is planned as five: IEC, IBC (BindDesk), InsureCap, Paragon and Santee. IEC runs every node at launch. Each partner takes over its own node when it is comfortable, and that timing is the partner's decision.

Validator-set votes

A validator joins or leaves by on-chain vote. More than half of the current validators must propose the same vote, and it is put on the chain when each voter next proposes a block. Adding a validator was tested locally (three to four) as was removing one (four to three).

1. The new operator runs a node as a non-validator first, with the same genesis and its own key, generated on its own machine.
2. Once it is in sync, more than half of the current validators vote to add its address.
3. The votes are cleared so they are not re-proposed, and peer-to-peer access is opened for the new node.

Size matters. On any chain, QBFT tolerates f faults with 3f + 1 nodes, so five or six validators still tolerate only one fault and raise the quorum to four. To hand a seat to a partner, either add the partner and then remove an IEC node, or grow to seven. With four nodes IEC alone holds a quorum of three; a partner holding half the nodes could halt the chain, which is why the order of changes matters.

Takeover

When a partner is ready, it takes its node over: a machine in its own account or office, a new validator key generated on it, and a validator-set update on the chain it validates. The node's history and seat carry over. IEC then destroys the hosted key and decommissions the hosted node.

Validator agreement

A starting-draft agreement, for review by counsel, covers who operates the node (IEC at launch, the partner after takeover); uptime and maintenance windows; key custody and lost-key recovery; what a validator does (it orders and approves blocks, and sees fingerprints and pointers, not the underlying records); joining, leaving and validator-set votes; and liability.

Record-type registry

The design adds a validator-set-and-record-type-registry contract that extends the permission graph already enforcing scopes and revocation for data access. New members, new record types and rule changes then share one approval path instead of three. The arrangement for who controls it initially is Open.

15Roadmap

16Open decisions

• Whether Besu's QBFT tooling covers the light-client and summary use case for Viewer satellites at the fidelity needed, or whether a thin-client API layer is defined explicitly.
• The checkpoint cadence from the InsureBio chain into the settlement chain.
• How control of the validator-set and record-type registry is shared at the start.
• Which licensed third-party vendors will accept running inside the platform, and which external datasets are genuinely public versus licensed.
• Liability, service levels and fees in the validator agreement.

17Glossary