Technical abstract. An ordinary database audit row is an assertion made inside the same administrative system that stores it. Access control can make that assertion difficult to modify during normal operation, but it does not automatically give an external verifier a cryptographic basis for distinguishing the genuine history from a history rewritten by a sufficiently privileged administrator. PostgreSQL documents table and ownership privileges and superuser authority. This historical paper examines what an exported artifact and a separately established trust anchor can add, and what they cannot establish.
The offline verification test
Given only an exported artifact and pre-established trust material, can a third party determine, without logging into the originating database, calling the vendor, or trusting a screenshot, that the evidence has not been silently modified since an authorized cryptographic commitment was created?
A conventional query returns what the currently trusted database says. Separation of duties, append-only application controls, replication, and archived storage remain useful, but they are not independently verifiable cryptographic commitments.
A hash chain needs an authenticated anchor
Changing event E_k changes its hash and every descendant hash under the assumed properties of SHA-256. A privileged actor who can replace every event, however, can also recompute every descendant hash. The terminal commitment must therefore be signed by a key that the attacker cannot simply substitute.
The NXC1 evidence bundle
This historical NXC1 concept separates a signed manifest from its byte-addressed attachments so each component can be recomputed. The layout, manifest and algorithm below illustrate a construction; they are not an interchange specification for Runtime v1 or the financial v3 bundles accepted by the current payment evidence reviewer.
NXC1
|
|-- certificate-manifest.json
|-- ledger-events.jsonl
|-- execution-manifest.json
|-- proposer-manifest.json
|-- policy.json
|-- approvals/
| |-- approval-001.json
| -- approval-002.json
|-- authorization.jws
|-- receipts/
| -- provider-receipt.raw
|-- identity/
| -- verification-material...
|-- trust/
| -- signing-key-chain...
-- certificate.jwsThe signed content manifest
{
"type": "NXC1",
"format_version": 1,
"certificate_id": "nxc1:...",
"intent_id": "018f...uuid",
"execution_manifest": { "sha256": "..." },
"proposer_manifest": { "sha256": "..." },
"policy": { "sha256": "..." },
"approval_set": { "sha256": "..." },
"authorization": { "sha256": "..." },
"ledger": { "event_count": 11, "terminal_hash": "..." },
"provider_receipt": { "sha256": "..." },
"signing": { "alg": "ES256", "kid": "..." }
}The mathematical shorthand expresses the authenticated payload. An actual JWS implementation signs the protected-header representation and payload representation joined into the JWS signing input.
A conceptual verification algorithm
verify_NXC1(bundle, trusted_roots):
require exact supported NXC1 version
reject duplicate component names and ambiguous JSON keys
reject unknown critical fields
enforce component size and count bounds
cert := parse(certificate.jws)
require cert.alg == ES256
key := resolve_only_through_trusted_root(cert.kid, bundle)
require verify_JWS(cert, key)
manifest := JCS(cert.payload)
for component in manifest.components:
require SHA256(bundle[component.name]) == component.sha256
execution := strict_parse(execution-manifest.json)
effect_digest := SHA256(JCS(execution))
prev := NXC1_GENESIS(...)
expected_seq := 0
for event in ledger:
require event.sequence == expected_seq
require event.previous_hash == prev
require transition_allowed(previous_state, event.state)
prev := SHA256(DOMAIN || encode(event.sequence) || prev || SHA256(JCS(event.body)))
expected_seq += 1
require prev == certificate.ledger_terminal_hash
for approval in approvals:
require approval.effect_digest == effect_digest
validate_approval_evidence(approval)
require quorum_satisfied(approvals, certificate.policy_digest)
auth := verify_ES256(authorization.jws)
require auth.effect_digest == effect_digest
require auth.policy_digest == certificate.policy_digest
require auth.approval_set_digest == SHA256(canonical_approval_set)
require execution.idempotency_key == auth.idempotency_key
require SHA256(provider_receipt.raw) == certificate.provider_receipt_sha256
return VALID_WITHIN_DECLARED_TRUST_MODELThe output should decompose assurance. A valid certificate signature does not automatically mean the IdP token was independently revalidated, and an integrity-bound provider receipt is not necessarily provider-signed.
Trust anchors and receipt authorship
A public key carried only inside the untrusted bundle is not a trust anchor because an attacker can replace both key and signature. The verifier needs a pre-established root, a customer-pinned fingerprint, or an operational key chain authenticated to that root.
Offline verification means network-independent cryptographic validation against supplied or pre-established trust material. It cannot know that a key was revoked after the trust snapshot was created unless current revocation information is supplied.
If a provider receipt is unsigned JSON, a valid signature and matching digest establish that the displayed bytes match the signer’s commitment under the admitted key. They do not independently establish who captured or authored those bytes, that the provider supplied them, or that the payment reached final settlement.
The required parts and their limits
A complete implementation of this construction can bind declared policy, approval evidence, execution intent, state transitions, authorization and receipt bytes into a signed artifact. Offline verification checks supported commitments under the supplied trust model. It does not establish source truth, complete event capture, current revocation status, sound human judgment or payment settlement. The conceptual examples here are not a claim that every Nikxius format implements every illustrated check.
Primary references
This is Nikxius’s technical synthesis of the original provider documentation, standards and official materials cited below. They support the specific mechanisms attributed to them; they do not endorse Nikxius or validate this conceptual construction. Living documentation may change after the stated review date.