> For the complete documentation index, see [llms.txt](https://docs.zecblocks.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zecblocks.xyz/validation-security.md).

# Validation security

## Consensus vs protocol validity

Zcash consensus and ZB-1 validation are separate layers.

A transaction may be:

```
Valid Zcash transaction
but
Invalid ZB-1 event
```

In that case, Zcash includes the transaction normally while ZB-1 clients ignore its protocol payload.

## Client requirements

A compliant implementation should independently verify:

* Genesis identity
* Source heights and source block hashes
* Proof-of-work
* Token uniqueness
* Global valid-claim count
* Required protocol fees
* Ownership authorization
* Event ordering
* Replay protection
* Marketplace payment conditions

## Do not trust UI state

Website labels such as “owned”, “listed”, or “sold” are convenience views.

Canonical ZB-1 state must be obtained by validating protocol events, not by trusting a website response.

## Key safety

{% hint style="danger" %}
Never publish:

* Wallet seed phrases
* Private spending keys
* Private ZB-1 ownership keys
  {% endhint %}

The protocol specification, public keys, commitments, source code, manifests, and deterministic validation logic can be public.

## Experimental software

{% hint style="warning" %}
ZB-1 is experimental software. Users should independently verify software before committing funds or valuable assets.
{% endhint %}