Security
Every attack has a named mitigation.
The protocol is small on purpose. Below is what someone could try against it, and the specific mechanism that defeats each attempt — taken from the threat model in the whitepaper.
Status. The protocol is in development. The mitigations below describe how TENUP is designed; external audits and a public bug bounty are planned before mainnet, and neither has taken place yet. This page will carry audit reports and contract addresses once they exist.
Attack
Hindsight editing
Changing a claim after the outcome is known.
Mitigation
Commit–reveal with a secret nonce
The fingerprint is written before the outcome exists. Any change to the content produces a different hash, and the stored one cannot be rewritten.
Attack
Content guessing before reveal
Brute-forcing the sealed content from its hash.
Mitigation
32 bytes of nonce entropy per artifact
A random nonce is concatenated before hashing, so dictionary attacks and guessing the payload are infeasible while the claim is still sealed.
Attack
Withholding unfavourable claims
Quietly never revealing the ones that went badly.
Mitigation
Reveal deadlines and public Expired flags
Every commitment carries a maximum reveal time. Miss it and the anchor is publicly marked Expired and counted against the publisher, so silence is visible.
Attack
Front-running a commit
Watching the mempool to act on a claim early.
Mitigation
Harmless by construction
A commitment is a hash and compact metadata. It discloses nothing about the content, so there is nothing to front-run.
Attack
Publisher spoofing
Anchoring claims while posing as someone else.
Mitigation
Signature bound to a registered key
An optional secp256k1 signature over the canonical bytes binds the artifact to a recognised signing key, and the publisher in the metadata must match.
Attack
Chain reorganisation
A block being reorganised after an anchor lands.
Mitigation
Pending state until k confirmations
Anchors are shown as pending until enough confirmations have passed, and the Explorer tracks finality rather than assuming it.
Attack
Key compromise
A publisher's signing key being stolen.
Mitigation
HSM custody, on-chain registry, rotation
Publisher keys are held in hardware, listed in an on-chain registry and rotatable. Contract changes sit behind a multisig and a timelock.
Attack
Contract bugs
A flaw in the verification contracts themselves.
Mitigation
Minimal surface, external audit, bug bounty
The verification core is deliberately small — no payload storage, write-once commits. External audits before mainnet and a public bug bounty are planned.
Standing controls
No payload ever stored on-chain
The chain holds fingerprints and compact metadata. Raw documents, patient data and personal records are never written to a public ledger, in any mode.
Write-once commitments
Records are keyed by publisher and sequence number, and cannot be overwritten once set.
Upgrade discipline
Multisig plus timelock on any contract change, with the verification core kept small enough to review in full.
Nothing of ours in the trust path
Verification needs the payload, the nonce and any public RPC endpoint. It does not call a TENUP service, so our uptime and our honesty are irrelevant to the result.
The full threat model and contract architecture are in the whitepaper.Read the whitepaper