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

# What is z-namespace?

Before you write a contract, it's worth knowing where your data actually lives. This page covers that in two minutes; the [next page](/developers/adk/get-started/walkthrough/write-contract) starts the real walkthrough, using `Terminal-3/z-tenant-flight` — a Duffel flight booking contract — as a worked example throughout.

## What is z-namespace?

The `z:` namespace is T3N's tenant data layer. Every map and every registered contract you create as a tenant lives under `z:<tid>:…`, where `<tid>` is the 20-byte lowercase hex suffix of your tenant DID.

```
ALL MAPS
│
├── AppKvMap (system data — T3N engineers only)
│   ├── users, auth, dids, scripts, outbox_*…
│   └── idx:_tenants, idx:_tenant_contracts…
│
└── z:<tid>:<tail> (your data — you own this)
    ├── z:<tid>:secrets           ← your Duffel API key, sealed inside the enclave
    └── z:<other-tid>:anything   ← DENIED (cross-tenant isolation enforced at every KV op)
```

The cluster enforces one rule at hardware level: a contract can only read or write maps whose prefix matches its own `<tid>`. There is no ACL misconfiguration that can break this — the check runs inside the TDX enclave at every transaction.

**What T3N guarantees:**

* Your maps are inaccessible to other tenants and to system contracts.
* User PII (`users` map) is unreachable to your contract's direct reads — PII flows through the `http-with-placeholders` host interface, which substitutes it into outbound requests inside the enclave (see [Placeholders in outbound calls](/developers/adk/tips/placeholders-outbound-calls)).
* Every operation your contract performs lands in the cluster's append-only audit log with your tenant DID as a first-class field.

For the full access-control model (readers/writers ACLs per map), see [Storage Namespaces](/t3n/how-t3n-works/z-namespace).