The Register and the Ledger: A Companies House Checklist for Entity-Aware Aergo Builds

UK builders increasingly want their Aergo applications to know who they are dealing with. A common shortcut is to treat a Companies House record as an identity oracle: look up the company number, anchor a hash on-chain, and let the smart contract decide that the entity is verified. That shortcut is understandable, but it collapses several different questions into one. A company can be registered and still be insolvent. A director can be recorded at Companies House and still lack authority to sign a particular contract. A wallet can be controlled by a person who is named as a director, but that does not automatically make the wallet a corporate signer.

As of November 2026, the practical question for Aergo builders is not whether the chain can store a company number. It can. The question is what a verifier should infer from that stored claim. The answer depends on the issuer, the evidence, the validity period and the separation between entity identity and signer authority.

Entity verification is not signer verification

A Companies House record establishes that a company or limited liability partnership is on the register, subject to the accuracy and freshness of the filed data. It does not, by itself, establish that a particular cryptographic key belongs to that entity. That second step is signer verification, and it requires a mapping between the legal person and the key holder.

An Aergo-based application can prove that a transaction was signed by a private key. It can prove that a smart contract accepted a claim under defined rules. It can prove that a document hash existed in a particular state at a particular block height. It cannot prove, without an authoritative issuer and a sound key-mapping process, that the signer was authorised to act for the company.

This distinction should shape the user interface as much as the smart contract. A badge saying verified company is too broad. A better label is closer to: attestation issued by X, referring to company number Y, valid until Z, covering signer key K. That wording is less elegant, but it is more honest.

What an Aergo attestation can establish

Within a well-designed system, an Aergo attestation can establish several useful facts. It can show that a claim was issued by a known attestation key. It can show that the claim has not changed since a given block. It can show that a document hash matches the evidence referenced by the issuer. It can enforce revocation rules, expiry dates and role-based permissions in a smart contract.

What it cannot do is make the underlying register more authoritative than it is. Companies House remains the source for company registration, director appointments, confirmation statements and related filings. An Aergo contract is a record of what an issuer asserted, when it asserted it and against which evidence. If the issuer is unreliable, or the evidence is stale, the chain does not repair the defect. It only makes the defect easier to audit.

For UK builders, this suggests a claim-based model rather than a company-based model. Do not encode a permanent status such as company is active. Encode a dated attestation: company number 12345678 was recorded as active on the register on 10 November 2026, based on evidence hash H, issued by provider P, valid until 10 February 2027. The wording is longer, but it survives scrutiny.

Director changes and key rotation run on different clocks

Director changes are a familiar source of overclaiming. A company may file an appointment or resignation at Companies House, and the public register may update after a filing lag. Meanwhile, the Aergo application may still hold an old attestation saying that a named person is a director. If the application treats that attestation as permanent, it will be wrong for however long the gap lasts.

Key rotation creates a parallel problem. A director may leave, a wallet may be compromised, or a corporate signer may move from one hardware security module to another. The legal change and the cryptographic change do not necessarily happen on the same day. A robust design needs a revocation registry or a versioned credential with an effective-from and effective-until date. It also needs a rule for what happens when an old key signs during a transition window.

The safest approach is to separate three records: the entity record, the officer or role record, and the signer-key record. Each should have its own issuer, evidence and expiry. A single verified company badge hides all three and creates false confidence.

Insolvency, filing lag and the freshness problem

Insolvency events are another area where on-chain claims can mislead. A company can enter administration, liquidation or a voluntary arrangement, and the public record may take time to reflect the change. An Aergo contract should not infer solvency from the absence of an insolvency filing. Absence of evidence is not evidence of absence, especially where filing lag and update cycles are involved.

If an application needs to act on insolvency status, it should rely on a named issuer that monitors the relevant register and, where appropriate, court or insolvency practitioner notices. The chain should record the evidence hash, the issue time and the validity window. A verifier should be able to see that the claim is current, who stands behind it and what happens when it expires.

Filing lag is not a reason to abandon on-chain attestations. It is a reason to design for freshness. Short-lived credentials, explicit as-of timestamps and challenge windows are more useful than a single immutable claim that nobody dares revoke.

A practical checklist for entity-aware Aergo applications

Before anchoring Companies House data to an Aergo contract, UK builders should be able to answer the following questions.

• What exactly is being claimed: registration, officer role, signer authority, insolvency status or something else?
• Who is the issuer, and what evidence did they rely on?
• Is the evidence hashed and retrievable for audit, with a clear retention policy?
• Does the claim have an as-of date, an expiry date and a revocation path?
• Is the legal entity separated from the signer key in the data model and the user interface?
• How are director changes, resignations and key rotations handled during transition periods?
• What happens when Companies House data is stale, corrected or disputed?
• Can a verifier distinguish between a chain fact, an issuer assertion and a legal conclusion?
• Does the application avoid language that implies the chain has verified more than it has?

The Companies House test is therefore not a test of whether Aergo can store a company number. It is a test of design discipline. Aergo can provide a durable, auditable record of attestations and signer activity. It cannot replace the register, and it should not pretend to. The stronger pattern is to prove the claim, name the issuer, show the evidence and let the verifier see the limits.