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.
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
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.
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 01Threat model & invariants
Written before implementation: who can call what, what must always hold, what an attacker gains by breaking each assumption.
-
PHASE 02Implementation & unit proof
Minimal surface area, well-known libraries, no clever gas tricks in code that moves value. Full unit coverage on every branch.
-
PHASE 03Fuzzing & invariant testing
Property-based tests hammer the stated invariants across randomised state; failures are reduced to minimal reproductions.
-
PHASE 04External audit & remediation
Independent audit arranged with a reputable firm. Findings are fixed, re-reviewed, and the report published alongside the deployment.
-
PHASE 05Staged deployment & monitoring
Testnet, then mainnet with caps, then caps lifted. On-chain monitoring with alerting on anomalous flows and a documented pause procedure.
// 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.
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.
Common questions
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.