HREVN Engineering opinion

Engineering opinion · 4 August 2026

When a check passes and proves the wrong thing: what COLDCARD changed in HREVN

A wallet-security incident prompted us to re-examine what our own verification results establish — and to strengthen how HREVN proves integrity, authority and issuance for business records that people and AI agents rely on.

Better models do not repair weak provenance. More capable agents can act on weak data more quickly.

That is the problem we work on at HREVN, and in July 2026 an incident in an unrelated industry made it unusually easy to describe.

Coinkite disclosed a serious security problem affecting wallet seed generation in certain COLDCARD firmware. We do not build wallets, generate recovery phrases, hold bitcoin or analyse affected wallets. We also make no claim that HREVN would have detected or prevented that incident.

But one detail in Coinkite's public technical account stayed with us. A runtime guard failed hard when two consecutive outputs from the random-number generator matched. On affected seed-generation calls that completed, that check did not trigger. A deterministic software fallback can also produce changing consecutive values.

We took that as a question about ourselves rather than as an invitation to dissect someone else's product. We reviewed what each HREVN result actually established and rebuilt our evidence core around narrower claims.

The product

A horizontal core for verifiable business records

HREVN EB1 Core turns a business record and its supporting material into a deterministic, signed evidence bundle. A bundle can carry structured data, documents and images together with the cryptographic commitments needed to detect later alteration.

The core is deliberately horizontal. It is not tied to one database, one AI provider or one industry. A conforming verifier can inspect format, integrity and mathematical signature without access to the application that produced the record; signer authority uses separately published trust material.

None of this makes a statement inside a record true. It establishes narrower properties: which bytes were committed, whether they changed, whether an authorised key signed the commitment and whether the exact submitted ZIP appears in HREVN's signed issuance record.

The AI layer

Why this matters before an agent reads the record

Companies already use AI to summarise records, identify patterns and support operational decisions. As agents gain more autonomy, the provenance of the data they consume becomes part of the security boundary rather than a data-quality footnote.

An agent can reason fluently over an altered photograph, an incomplete inspection, an ambiguously identified document or a record whose origin was never established. It can do so confidently and at speed.

HREVN-compatible applications therefore improve the record before an agent reads it. They can preserve structured, portable data and expose controlled, read-only views to an AI layer. The agent does not need unrestricted access to the production database, and the organisation is not permanently tied to one model: the same records can be exported, checked and reused by whatever comes next.

The first vertical

SuperProperty applies the model to property operations

SuperProperty uses the core for inspections, incidents, handovers and supporting photographs. A record is captured when the event happens, bound to its evidence and issued as a signed EB1 v2 bundle.

If the record or an included photograph changes afterwards, the mismatch is detectable. Structured exports can feed spreadsheets, internal reporting and scoped AI queries without giving an agent permission to alter the operational database.

Our own format

The same category error, at much lower stakes

Historical HREVN v1 bundles could demonstrate content integrity and a mathematically valid signature under the public key carried inside the archive. Those were real checks.

But a key supplied by the archive was not, by itself, portable proof that HREVN had authorised it. Some identity information sat outside the signed commitment. A single positive result could therefore be read as a broader statement about origin than anything the verifier had tested.

That was not the COLDCARD vulnerability. It was the same shape of mistake in a different domain: measuring one property while a reader infers another. Once you see the pattern, it becomes difficult not to look for it in your own work.

HREVN EB1 v2

What we changed

The protocol does not collapse integrity, signature, authority and issuance into one global valid result.

01

Evidence and context are signed together

Changing record identity, product context or signing-key identity can no longer leave the original signature valid.

02

Signer authority comes from outside the archive

A verifier uses separately published and pinned trust material. A public key carried by an archive is not treated as proof of who authorised it.

03

Exact issuance is a separate question

The public ratifier checks whether the SHA-256 of a submitted ZIP matches a signed HREVN issuance entry, not merely whether the bundle is internally consistent.

Beyond property

One core, more possible verticals

Property management is the first application, not the limit of the model. The same core can support installation inspections, maintenance visits, building work, equipment checks, handovers and quality-control processes — situations where evidence is created now and examined later.

Each vertical defines its own fields, workflow and interface. The objective underneath stays the same: portable business data with a clear integrity, authority and issuance path, ready for current or future AI systems without depending permanently on one application.

Explicit boundaries

What verification does not mean

A signed bundle does not prove that an inspection was thorough, that a photograph shows the whole situation or that a human statement is true. Verification must not be collapsed into a promise of correctness — that would be the same error again, committed by us.

Current SuperProperty bundles claim neither an independent timestamp nor a blockchain anchor. The HREVN trust-root copies remain under one operator, which is operational redundancy rather than independent custody. Exact-issuance ratification currently depends on preserving the issuance ledger, the online ratifier and published signed checkpoints.

These are product boundaries, not footnotes. Infrastructure worth relying on starts by stating precisely what has, and has not, been established.

The lesson carried forward

A verification result should prove the property its reader will infer from it.

The commercial objective is broader than any single incident: helping organisations create records that retain integrity, provenance and portability as business processes become mediated by AI agents.

Verifiable evidence does not make an agent's conclusions correct. It gives people and machines a record worth reasoning from.