> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notareum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

# 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

| Primitive          | Algorithm                                 | Purpose                                    |
| ------------------ | ----------------------------------------- | ------------------------------------------ |
| Signature          | ECDSA secp256k1 (EIP-191)                 | Prove resource ownership                   |
| Hash               | keccak256                                 | Resource ID derivation, content addressing |
| Address derivation | keccak256 last 20 bytes of pubkey         | Standard Ethereum address                  |
| Packed encoding    | `abi.encodePacked(uint8, uint256, bytes)` | Resource ID input canonicalisation         |

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:

```mermaid theme={"system"}
flowchart LR
    Stake[Validator stakes NOTA] --> Attest[Attests to resources]
    Attest --> Reward{Correct?}
    Reward -->|Yes| Earn[Earn fee share]
    Reward -->|No| Slash[Stake slashed]
    Slash --> Burn[Portion burned]
    Slash --> Pay[Portion pays disputer]
```

**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](staking-and-tiers.md).

**Slashing**: malicious or negligent attestation triggers automatic stake reduction. Severe violations result in full stake burn plus exclusion from the validator set. See [Slashing](slashing.md).

**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](dispute-resolution.md).

## Resource ID security

Resource IDs are derived deterministically from `(resource_type, chain_id, identifier)`:

```
resource_id = keccak256(abi.encodePacked(uint8(type), uint256(chainId), bytes(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](../resources/security-disclosure.md).

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.

## Related pages

* [Dispute Resolution](dispute-resolution.md)
* [Slashing](slashing.md)
* [Security Disclosure](../resources/security-disclosure.md)
* [Contract Addresses](../reference/contract-addresses.md)