Nexiv Labs is now operating six divisions across healthcare, veterinary, commerce and infrastructure. See the group →
Division 05 — Blockchain projects

Nexiv Chain

Production blockchain engineering for cases where a shared ledger genuinely earns its keep — provenance, credentials, tokenised assets and audit anchoring. If a database is the better answer, we will say so.

EVM & L2 Audit-first Non-custodial by default
Block production
Honest scoping

Most projects do not need a blockchain

We start every engagement by trying to talk you out of one. A ledger is justified when several parties must agree on state and none of them will accept another as the authority. Otherwise you are paying a large tax for a slower database.

A chain fits when…

  • Multiple organisations must share state without a trusted operator
  • A claim must be verifiable by someone who does not trust you
  • Ownership or entitlement must transfer without a central registry
  • Records must be provably unaltered after the fact
  • Settlement needs to be atomic across parties

A chain does not fit when…

  • One organisation controls all the data anyway
  • The data is personal and must be erasable on request
  • You need high write throughput at low cost
  • The real problem is data quality at the point of entry
  • "Blockchain" is in the requirement but not in the problem
What we build

Delivery capabilities

Smart contract engineering

Solidity on EVM chains and L2s. Upgrade patterns chosen deliberately, invariants stated explicitly, and property-based tests plus fuzzing before anything reaches an external auditor.

Tokenisation

Fungible and non-fungible asset representation with allow-listing, transfer restrictions, lock-ups and role separation — designed so compliance constraints are enforced on-chain, not in a spreadsheet.

Verifiable credentials

W3C-style credentials with selective disclosure, so a holder can prove one attribute — a licence is valid, an animal is vaccinated — without exposing the whole document.

Provenance & anchoring

Off-chain records hashed and anchored on-chain so tampering is detectable while the personal data itself stays in a system you can still erase from.

Custody & key management

Integration with qualified custodians, MPC wallet providers and hardware security modules. Multi-signature policies, spend limits and separation of duty for treasury operations.

Indexing & reconciliation

Event indexers, subgraphs and reconciliation dashboards so finance and operations can see on-chain state in the same view as everything else, with breaks flagged automatically.

Security process

Contracts are unforgiving, so the process is strict

Deployed code is public, immutable and holds value. We treat every contract as a security artefact from the first commit.

  • PHASE 01
    Threat model & invariants

    Written before implementation: who can call what, what must always hold, what an attacker gains by breaking each assumption.

  • PHASE 02
    Implementation & unit proof

    Minimal surface area, well-known libraries, no clever gas tricks in code that moves value. Full unit coverage on every branch.

  • PHASE 03
    Fuzzing & invariant testing

    Property-based tests hammer the stated invariants across randomised state; failures are reduced to minimal reproductions.

  • PHASE 04
    External audit & remediation

    Independent audit arranged with a reputable firm. Findings are fixed, re-reviewed, and the report published alongside the deployment.

  • PHASE 05
    Staged deployment & monitoring

    Testnet, then mainnet with caps, then caps lifted. On-chain monitoring with alerting on anomalous flows and a documented pause procedure.

contracts/ProvenanceAnchor.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

/// Anchors off-chain record hashes. No personal data
/// is ever written on-chain — only a commitment.
contract ProvenanceAnchor {
    event Anchored(
        bytes32 indexed subject,
        bytes32 commitment,
        uint64  at
    );

    mapping(bytes32 => bytes32) private _latest;

    function anchor(bytes32 subject, bytes32 commitment)
        external onlyIssuer
    {
        require(commitment != bytes32(0), "empty");
        _latest[subject] = commitment;
        emit Anchored(subject, commitment, uint64(block.timestamp));
    }

    function verify(bytes32 subject, bytes32 commitment)
        external view returns (bool)
    {
        return _latest[subject] == commitment;
    }
}

Personal data never goes on-chain. We anchor a commitment to a record, not the record. That preserves tamper-evidence while keeping erasure rights intact under UK and EU data protection law.

Inside the group

Where Nexiv Chain is already used

Pet provenance

Pedigree, vaccination and transfer-of-ownership commitments anchored for Nexiv Pets, so a buyer can verify seller claims independently.

Audit anchoring

Daily commitments of clinical and marketplace audit logs, so any later alteration of history becomes provable rather than arguable.

Professional credentials

Verifiable credentials for clinician and veterinary registration status, checkable by partner platforms without exposing the underlying record.

Questions

Common questions

We build systems; we do not offer, promote or give advice on investments. Nexiv Chain does not operate an exchange, run a fund, or market tokens to the public. Where a client's project has a regulatory dimension, we require them to take their own qualified legal advice and we build to that advice.
Primarily EVM-compatible networks and their layer-2 rollups, chosen on finality, cost, tooling maturity and where the counterparties already are. For enterprise consortium use cases we also evaluate permissioned networks. Chain selection is a design decision we justify in writing, not a default.
No. Our default is strictly non-custodial: keys stay with the client or with a qualified custodian they appoint. Where operational signing is required we integrate MPC or HSM-backed providers with multi-signature policies, so no single party — including us — can move value alone.
By never putting personal data on-chain. We store the record in a conventional, erasable system and anchor only a salted hash. Deleting the off-chain record makes the on-chain commitment meaningless while leaving the tamper-evidence property intact for records that remain.

Bring us the problem, not the technology

Describe what needs to be verifiable and who needs to verify it. We will tell you whether a ledger helps — including when it does not.