Safer chain writes: the new Chain Gateway, with testnet-first pickers and mainnet confirmation
Every record written to the insurance data chain is a statement that someone stands behind. If the way that write happens is hard to see, the record is harder to trust. That is why we changed how chain writes work.
As of this release, chain writes run through a gateway service instead of the old private-key setup. Alongside it, there is a new console page for managing signers, policies, chains and transactions, with guardrails built in: testnet-first options and an explicit confirmation step before anything goes to mainnet.
This post covers what changed, how it works at a high level, and why it matters if you depend on insurance data being owned, visible and shared only with consent.
What shipped
Three things, working together:
- A gateway service for chain writes. Writes no longer depend on the old private-key setup. They pass through a single service that handles the write.
- A console page for the chain side of the platform. Signers, policies, chains and transactions are now managed from one page rather than scattered across configuration.
- Guardrails on the path to mainnet. Pickers default to testnet-first options, and sending a write to mainnet requires an explicit confirmation.
The change was noted in the Tawa daily what's new feed.
Why move away from the private-key setup
A private-key setup puts the ability to write in the hands of whoever holds the key and wherever it is stored. That works, but it makes a few questions harder to answer than they should be. Who can write? To which chain? Under what rules? And what did they actually send?
Routing writes through a gateway changes the shape of those questions. Instead of many places where a write can originate, there is one service every write goes through. That gives the platform a single point where signers, policies and target chains are applied, and a single place where the resulting transactions can be seen.
For a company whose whole argument is that every access should be visible and logged, the write path itself has to meet that standard. A gateway is how we hold ourselves to it.
One page for signers, policies, chains and transactions
The new console page groups the four things an operator needs to reason about when data is written on chain:
- Signers: the identities that authorize writes.
- Policies: the rules that govern how those writes happen.
- Chains: where a write is sent.
- Transactions: what was actually written.
Having them side by side matters more than it sounds. When you are checking whether a write was correct, you usually need all four at once: who signed it, what rules applied, which chain it went to, and what the transaction contained. Putting them on one page means you can follow a write from authorization to result without stitching together separate views.
This is the same principle we apply to the data itself. Every record has an owner; every write should have a clear trail back to who authorized it and how.
Testnet first, by default
Most mistakes in chain operations are not malicious. They are someone pointing a write at the wrong network, or testing against a live environment because it was the option already selected.
The pickers in the new console lead with testnet options. The safe choice is the default choice, so trying something out does not risk touching production records. If you want to send a write to mainnet, you have to choose that deliberately.
For agencies, MGAs and carrier operations teams that build on top of the chain, this means you can test integrations and workflows against a non-production environment without first checking which network is selected.
Explicit confirmation before mainnet
Choosing mainnet is not the last step. Writes headed to mainnet require an explicit confirmation.
The point of this step is simple: a write to the production chain should never happen by accident. A record on the insurance data chain is meant to be durable and trusted by everyone who reads it, so the moment it is written deserves a pause and a clear yes.
Taken together, testnet-first pickers and mainnet confirmation make the careful path the easy one and the irreversible path a conscious decision.
What this means for the people who rely on the data
If you contribute data, this change means the writes that carry your records go through a controlled, visible path rather than a key held somewhere out of sight.
If you read or use data from the chain, it means the records you see were written through a service that applies signers, policies and chain selection in one place, with production writes requiring confirmation.
If you are a regulator or an auditor, it means there is a single place to look when you need to understand how writes are authorized and what was sent.
None of this changes the core commitments. Every record still has an owner. Every access is still visible and logged. Data is still shared only with consent. What changes is that the mechanics of writing to the chain now match those commitments more closely. It is the opposite of opaque data resale, where nobody can see who touched a record or why.
Where to go from here
If you manage chain operations in the console, the new page is where signers, policies, chains and transactions now live. Start on testnet, check the trail, and confirm deliberately when you are ready for mainnet.
We will keep tightening the write path in the same direction: fewer places a write can come from, clearer records of what happened, and guardrails that make mistakes harder to make.
Secured on InsureBio, the insurance data chain.