XKOVA Docs
Provenance and Transparency
Real-world-asset metadata is immutable by system design: you can append new facts, but you cannot quietly rewrite old ones. Three mechanisms enforce that claim. Every change is appended to a hash chain, external parties sign their own facts, and a public transparency log lets any holder verify the history without trusting XKOVA's database.
An append-only history
Each metadata change earns a provenance version and a leaf in a per-token hash chain. Nothing is edited in place; a correction is a new appended version, not a rewrite of an old one. That makes the history tamper-evident: if a past version were altered, the chain would no longer recompute.
You verify a token's provenance chain on demand. The verify check recomputes the metadata hash chain, confirms the latest signed checkpoint still matches (catching a rewritten version), and recovers the checkpoint's EIP-712 signature against the live isolated-signer address (catching a forged checkpoint; the row's stored signer address is not trusted). The verdict is one of:
| Verdict | Meaning |
|---|---|
| ok, no reason | The chain is intact and covered by a checkpoint. |
| ok, unanchored | Intact, but no checkpoint exists yet. |
| chain_broken | A version's leaf does not recompute. |
| head_mismatch | A covered version was rewritten. |
| signature_invalid | The checkpoint signature does not recover to the live signer. |
| signer_unreachable | Transient; retry. |
Multi-attester facts
Some facts come from outside the issuer: an auditor's opinion, an appraiser's valuation, a custodian's confirmation. Rather than the issuer typing those in, the external party signs them with their own key.
- The issuer registers a trusted external attester against the token, pinned to that token, with a role label such as auditor, appraiser, or custodian. The attester's address is validated and stored.
- The attester signs an EIP-712 fact over the token reference, the field path, and a digest of the payload, then submits it to an append-log field.
- XKOVA recomputes the digest, recovers the signer, and rejects the fact if the recovered address is not the named attester's registered address. No row is written on a mismatch.
An accepted attested fact commits through the same single ingestion path as any other change, earning a provenance version and chain leaf, with its provenance source recorded as attested. An attester can be soft-revoked, after which their key can no longer sign accepted facts. Only append-log fields can be attested.
The public transparency log
Each token's metadata history is also committed to an RFC-6962 transparency log, the same Merkle-tree structure used by certificate transparency. The log read routes are public, with no api key, because the log carries only hashes, never gated content. That lets a holder or auditor confirm two things without trusting XKOVA's database:
- Inclusion: a specific metadata version was logged. Fetch a signed tree head, fetch an inclusion proof for the version, and verify the proof against the tree head's root offline.
- Consistency: the log was only ever appended to, never rewritten between two points in time. Fetch a consistency proof between two tree sizes and verify that the earlier tree is a prefix of the later one.
The XKOVA TypeScript SDK ships verifiers for these proofs, so a holder can check them in their own code. A signed tree head, once published, is append-only and always served.
Third-party witnesses
For stronger assurance, an issuer can register a trusted witness (an auditor, custodian, or oracle) whose key co-signs the published tree heads. Only a co-signature that recovers to a registered, active witness is accepted and recorded on the tree head. A witness that independently co-signs the log makes it harder for any single party to rewrite history unnoticed.
Verified against the chain
XKOVA re-verifies the stored record against ground truth on a nightly schedule: stored documents against their content hashes, and projected positions and token supply against on-chain state. Most detected drift is logged and alerted for an operator to reconcile against the chain, for example by re-indexing a token; the on-chain supply mirror is additionally re-replayed from chain state automatically, while tampered document bytes can only be flagged, never silently restored. The transparency log above lets you prove the history was never rewritten.
Related
- Real-World Assets: the schema and metadata model these facts attach to.
- Holder Eligibility and Transfers: how attested attributes feed transfer decisions.
- Corporate Actions: lifecycle changes that also append history.
- Security Model: the isolated signer behind the checkpoints.