# MazeXChain Security Model

## 1. Security Objective

MazeXChain security is based on deterministic verification, bounded answers, public commitments, private generator isolation, wallet signatures, and replayable chain state.

The protocol should make it cheap to verify valid work and expensive or impossible to advance state with invalid work.

## 2. Public and Private Data

Public data may include:

```text
Layer / Step
grid size
difficulty score
public commitments
behavior root
fragment registry root
answer hash
solve block data
reward settlement data
public wallet address
public key
signature
chain head
state root
block hash
```

Private data must not appear in public APIs or logs:

```text
internal generated expressions
private seed material
fragment selection path
private vault content
wallet private key
mnemonic phrase
uncommitted future challenge material
server-only generator internals
```

## 3. Security Techniques

| Technique | Reversible | Used For |
| --- | --- | --- |
| Hash | No | `answer_hash`, `block_hash`, `seed_source_hash` |
| Merkle root | No, commitment only | `behavior_root`, `fragment_root` |
| Digital signature | Verifies identity; does not hide content | Wallet signatures and submission signatures |
| Private Vault isolation | Hides internal generation material | Internal expressions, private seed material, fragment selection paths |
| Commit-reveal style records | Commit first, reveal only protocol-defined material later | Solved Step publication and historical replay |
| Answer budget | Not cryptography; protocol constraint | Prevents lookup-table answers and unbounded payloads |
| Deterministic verifier | Not cryptography; consensus rule | Confirms behavior equivalence |

## 4. API and Network Safety

API and network messages must enforce:

```text
message size limits
local verification before broadcast
duplicate answer hash rejection
stale Layer / Step rejection
request rate limits
peer error tracking
cooldown for repeated invalid messages
development-only reset guards
```

## 5. Wallet Safety

Production wallet rules:

```text
Private keys and recovery phrases stay client-side.
The extension stores encrypted vaults.
The active wallet is decrypted only for the current browser session.
Every site-requested signature requires explicit user approval.
The website may request signatures, but it must not store production private keys.
```

## 6. Storage Safety

Long-running chain storage must avoid a single mutable state file as the only source of truth.

Required storage properties:

```text
appendable block records
header indexes
state roots
snapshot-assisted recovery
full replay option
crash-safe writes
separation of blocks, samples, indexes, and snapshots
```

## 7. Remaining Hardening Work

Before public mainnet release, the project still needs longer multi-node tests, stronger peer scoring, public deployment rate limits, external security review, and formal test coverage for failure cases.
