Skip to main content

​
Security

This page describes the Notareum Protocol’s security model: the threats it defends against, the cryptographic guarantees it provides, and the economic mechanisms that align validator behaviour with honest verification.

​
Threat model

The protocol is designed to resist the following attacks:
  1. Resource spoofing: an attacker registers a resource under a forged owner. Defended by signature-based ownership proofs and validator attestation.
  2. Sybil attacks: a single entity creates many validator identities. Defended by stake-weighted voting and minimum tier thresholds.
  3. Validator collusion: validators coordinate to attest maliciously. Defended by slashing and dispute resolution with economic penalties.
  4. Replay attacks: old .nota files resubmitted as new. Defended by on-chain registry uniqueness and per-resource chain ID binding.
  5. Front-running: a third party watches a pending registration and races to claim it first. Defended by commit-reveal patterns (for alias registration) and deterministic resource ID derivation.
  6. Governance capture: a minority accumulates enough voting power to push hostile proposals. Defended by veNOTA time-locking, which requires sustained commitment for voting power.

​
Cryptographic primitives

All signatures use the standard personal_sign framing: keccak256("\x19Ethereum Signed Message:\n" + len + message). This makes every .nota file verifiable in any Ethereum-compatible wallet without custom tooling.

​
Economic security

The protocol’s trust model rests on three economic mechanisms: Validator staking: validators must stake NOTA to participate. Tier determines daily verification capacity. Higher tiers command more influence but also more slashable capital. See Staking and Tiers. Slashing: malicious or negligent attestation triggers automatic stake reduction. Severe violations result in full stake burn plus exclusion from the validator set. See Slashing. Dispute resolution: any user can challenge a verification decision by posting a NOTA bond. Successful disputes slash the malicious validators and reward the disputer. Failed disputes burn the bond. This creates a market for honest verification. See Dispute Resolution.

​
Resource ID security

Resource IDs are derived deterministically from (resource_type, chain_id, identifier):
Two properties follow:
  • Collision resistance: keccak256 provides 256 bits of security, making accidental collisions infeasible.
  • Chain binding: the same identifier on a different chain produces a different resource ID. Cross-chain identity requires explicit registration on each chain.
This means implementations in any language must compute identical IDs for identical inputs. The protocol’s cross-language test vectors verify this property.

​
Audits and disclosure

All smart contracts undergo third-party security audit before mainnet deployment. Audit reports are published under resources. Security vulnerabilities should be reported through the responsible disclosure process at security@notareum.com. Valid reports qualify for bounties under the protocol’s bug bounty programme.