# Guld 2.0 Whitepaper (Draft)

**Status:** draft — for design review, not a launch commitment  
**Version:** 0.9-draft  
**Date:** 2026-09-23  
**Token:** GULD (native)  
**Based on:** [`research/modern-l1-direction.md`](../research/modern-l1-direction.md) and related research notes  
**Normative drafts:** [`../specs/README.md`](../specs/README.md)

---

## Abstract

Guld 2.0 is a **global, identity-focused DeFi layer-1**: people and groups are first-class network citizens addressed by **username**, referenced by **content hash**, and authorized by **threshold cosignature** (and other enumerated leaf-consensus proofs). The chain is a **witness**: it records that a user or group achieved consensus on a new **head** (master hash). It does not interpret why they signed, run their private scripts, or adjudicate their disputes.

The design aims at **Bitcoin / Ethereum / Solana-class** L1 security and throughput while differentiating on product shape—**names, personal and group hash trees, flexible leaf control**. The network is **not a general VM**: it validates fixed transaction schemas, checks hashes and signatures, and applies a small set of built-in state updates. Custom operations live in leaves. The reserved account **`guld`** holds protocol software and rules; full nodes must fully clone it. Validators otherwise stay lean on keys, tips, and balances. Optional git and PGP remain **leaf** tools, not the consensus bus.

Fees follow a **Bitcoin-style weight market** (GULD per virtual byte), not an EVM gas ISA. Emission and PoW (or DAG-PoW) align open membership with scarce block space. Each account is responsible for what it **witnesses** and **cowitnesses**.

---

## 1. Motivation

### 1.1 The gap

Ethereum proved programmable settlement and fee markets. Bitcoin proved open Sybil-resistant consensus. Solana proved that non-conflicting account updates can proceed in parallel. None of them treat **human-meaningful identity** and **sovereign group process** as the primary object:

- Addresses are opaque key hashes, not names.
- “Multisig” and governance are applications, not the native tip model.
- Putting social process on a general VM forces every validator to re-execute politics—or forces that politics into custodial apps.

Guld 1.0 explored identity, git, and weighted observation. Solving network consensus **inside** git and PGP proved too bloated for global scale (emails and UIDs as metadata, weak first-class cosign, mega-repo growth).

### 1.2 Thesis

**Address by name. Commit by hash. Authorize by proof. Pay a tx fee. Leave leaf law to the leaf.**

Guld 2.0 is a hard fork of the 1.0 software and ledger: preserve historical balances and rules where possible; do not preserve blockchain-in-git or FUSE as the product model.

### 1.3 Design bar

| Goal | Meaning |
|------|---------|
| Identity-first DeFi | Transfers, bonds, grants, and permissions bind to **usernames / groups** |
| Flexible leaves | Groups choose languages, rules, and dispute processes offline |
| Network as witness | L1 verifies external proofs and records heads |
| L1-competitive | Throughput and security in the ETH/BTC/SOL class—not PayPal-scale day one |
| Lean validators | No requirement to index social graphs or execute leaf interpreters |

---

## 2. Architecture overview

```
┌─────────────────────────────────────────────────────────────┐
│  Consensus plane                                            │
│  PoW / DAG-PoW headers · fork choice · coinbase · fees      │
└────────────────────────────┬────────────────────────────────┘
                             │ commits to state_root
                             ▼
┌─────────────────────────────────────────────────────────────┐
│  State plane (KV + sparse Merkle / authenticated tree)      │
│  username → account · keys · threshold · master_hash        │
│  balances · nonces · receipts                               │
└────────────────────────────┬────────────────────────────────┘
                             │ references content hashes
                             ▼
┌─────────────────────────────────────────────────────────────┐
│  Object plane (CAS + optional git remotes)                   │
│  personal / group trees · forge clones · encrypted blobs    │
│  local/optional retention · leaf hosts materialize clients  │
└─────────────────────────────────────────────────────────────┘
                             │
                             ▼
┌─────────────────────────────────────────────────────────────┐
│  Clients (unknown) + optional indexers                      │
│  Browser / game / CLI ↔ leaf host API · explorers           │
└─────────────────────────────────────────────────────────────┘
```

**Implementation sketch:** Rust validator; polyglot leaf tooling (including today’s Python/JS meta-FS packages as leaf hosts). Users may push leaf git to GitHub or any forge for free distribution. SHA-256 for commitments; AES-256 for private leaf encryption when needed; account signatures Ed25519 at genesis with a documented PQ migration path (hybrid / ML-DSA).

---

## 3. Identity model

### 3.1 Names and hashes

| Concept | Role |
|---------|------|
| **Username / group name** | Human-addressable primary handle on the network |
| **Account id** | Stable internal id (hash of registration commitment) |
| **Master hash** | Single SHA-256 committing to the account’s defined tree + meta |
| **Content hashes** | SHA-256 (or tree roots) referencing CAS objects |

People say: *pay `alice`*, *bond to `guild/traders`*, *follow tip of `bob`*. Machines settle against the registered mapping and the current master hash.

### 3.2 Account structure and network-level home

```
name
├── keys[]              # verification keys
├── threshold           # cosign policy for tip / spend / recover (roles optional)
├── nonce
├── master_hash         # SHA-256 head of the account home
├── balance (GULD)
└── optional bond / remote-hint fields   # bonds = roles/deposits only; no L1 CAS pins
```

```
master_hash = SHA256(
  home_tree_root ‖          # SHA-256 Merkle (or equivalent) of defined home objects
  account_meta_root ‖
  … schema-frozen fields …
)
```

**Primary homes are hash trees at the network layer**, not git objects. The chain stores the **identity record** (name, keys, threshold, `master_hash`, balances)—that is the network’s primary identity file. Home **bytes** live in CAS addressed by SHA-256. For ordinary accounts, validators need only the tip; **content retention is a leaf concern** (self-host, forge mirrors, leaf contracts)—not an L1 pin market. The reserved account **`guld`** is the exception: full nodes must clone its full home (§3.5).

**Leaf formats under the home** (git repos, game data, HTTP app trees, encrypted blobs, …) are optional and opaque. Git is a fine leaf encoding for free forge hosting; it is **not** the network home format. Other leaf formats—including as the bulk of a personal or group home—are first-class as long as the committed root is SHA-256.

Validators never open leaf formats; they only check that proofs authorize a new `master_hash`.

### 3.3 Registration (priced; anti-spam)

Registering a name consumes **global namespace** and creates durable validator state. It must be **painful to spam**, continuing the Guld 1.0 idea of explicit registration fees for individuals and groups.

| Kind | Who pays | Fee idea (draft) |
|------|----------|------------------|
| **Individual** | New username | Fixed **registration fee** `F_user` in GULD (high enough to deter bulk squat/spam) **plus** ordinary weight-based miner fee |
| **Group** | New group name | **Registration fee** `F_group(n) = F_group_base + F_group_per_signer × n` where `n` = number of registered signers / keys in the initial policy **plus** weight-based miner fee |

**Why scale group fees with signer count:** each additional key enlarges proofs the network must verify for the life of that account (registration now; every threshold tip later). Charging upfront for `n` aligns payment with **proof complexity** the validators will perform.

Exact `F_*` magnitudes are parameters (retune with economics); the invariant is: **registration is expensive relative to ordinary tip updates**, and **larger signer sets cost more to create**.

**Burn:** `F_user` and `F_group(n)` are **burned** (removed from supply)—not paid to the block miner. Registration creates lasting state and proof burden for *every* full node, not a service to the lucky proposer. Optional **name deposits** may lock separately (returnable/slashable under policy).

```
RegisterUsername / RegisterGroup(
  name, keys[1..n], threshold, initial_master_hash
)  requires  balance ≥ F_*(n) + miner_fee
           F_*(n) → 🔥 burn
           miner_fee → coinbase miner (weight-priced inclusion)
```

Legacy Guld 1.0 usernames and balances are imported as **claimable pre-mine accounts** (§8.6, [`../specs/15-ledger-import.md`](../specs/15-ledger-import.md)). Spend and tip authority activate only after a **key upgrade**: the holder proves control of the 1.0 identity (PGP / legacy binding) and registers Ed25519 (or hybrid) keys. Until then, balances are respected on-chain but **locked**. OpenPGP is not the hot verify path after claim.

### 3.4 Addressing vs referencing

- **Address by name** in UX and high-level txs (`Transfer { to: "alice", amount }`).
- **Reference by hash** for tips, trees, and proofs (`master_hash`, CAS oids).
- Resolvers and indexers may cache name→id; consensus stores the authoritative map.
- **Foreign chains** MAY appear as reserved names (`bitcoin`, `ethereum`, …) whose tips advance under **that chain’s consensus proofs**—cross-chain as a **namespace witness hub**, not automatically as a token bridge (see [`../specs/13-foreign-chains.md`](../specs/13-foreign-chains.md)).

### 3.5 Reserved name: `guld` (network identity)

The username / account **`guld`** is **reserved for the network itself**. It is not available for public registration.

The `guld` home’s leaves carry the **protocol software and consensus rules**—for example:

- full node / validator  
- core libraries  
- client SDKs  
- schemas, genesis params, weight tables, proof-kind definitions  
- related tooling and docs that define “what honest nodes run”

**Full-node requirement:** every full node **must keep a complete clone** of the current `guld` home (all objects under its tip)—not an optional retention choice. That tree *is* the software and rule bundle the node is supposed to execute and the state transition rules it is supposed to enforce. Advancing the network’s understanding of “valid” is advancing the `guld` tip under its own cosign / governance policy (itself an on-chain account).

```
on-chain account "guld"
  └── master_hash  (SHA-256 home tip)
        └── leaves: node, core, libs, clients, schemas, …
              └── e.g. this repository (`~/Projects/guld`) as a **sub-leaf**
                  of the guld home (git or hash-tree encoding inside the leaf)
```

Working copies such as `/home/isysd/Projects/guld` are development checkouts of that sub-leaf; consensus cares about the committed tip under `guld`, not any particular machine path.

**Implications**

| Topic | Rule |
|-------|------|
| Namespace | `guld` cannot be registered by users; genesis-created |
| DA | Full nodes **must** materialize the full `guld` tree; other account bytes are **not** consensus DA — tip ≠ availability |
| Upgrades | Protocol upgrades ship as new `guld` tips (signed under `guld`’s key policy) that nodes sync before/as they enforce new rules |
| Light clients | Need not hold the full tree; they trust headers / proofs, or fetch rule digests as needed |

---

## 4. Leaves, witnessing, and cowitnessing

### 4.1 Leaf sovereignty

A **leaf** is a personal home or group realm: its members may use any languages, scripts, and local rules. Disputes (“why we signed”) are resolved **inside** the leaf.

The network accepts a tip update only if it carries an **enumerated, externally verifiable** leaf-consensus proof under the account’s current on-chain policy—for genesis, primarily:

**`threshold_cosign_v1`:** at least `threshold` signatures over

```
SHA256( account_id ‖ prev_master_hash ‖ new_master_hash ‖ nonce ‖ chain_id )
```

Additional proof kinds require explicit protocol upgrades.

### 4.2 Witness and cowitness responsibility

| Actor | Responsibility |
|-------|----------------|
| **Account / key holder** | Whatever they sign: they **witness** that `new_master_hash` is the authorized head |
| **Cosigners** | Jointly **cowitness** the same statement; threshold failure ⇒ tip rejected |
| **Validators / miners** | Witness that the proof verifies and the fee is paid; they do **not** endorse leaf politics |
| **Leaf hosts / remotes** | Hold bytes clients need; availability is **off** the consensus path (leaf contracts, self-host, forges) |

Signing is **attributable**. Social or legal meaning of a cowitness remains a leaf concern; cryptographically, cowitnesses are jointly necessary for the tip to enter global history.

### 4.3 What the node does *not* do

- Run leaf interpreters as a consensus requirement (Python, WASM guild scripts, games, …)
- Read emails, PGP UIDs, or git commit headers as consensus input
- Decide internal group disputes
- Require a global metadata index to produce blocks

### 4.4 Clients, leaf hosts, and free git remotes (UX)

The **ultimate client is undefined**: a browser UI over HTTP, a native game binary, a CLI, a mobile app, an agent. The L1 only knows names and heads. To *use* files and code, a client must talk to something that holds **leaf material**—not merely the on-chain `master_hash`.

```
  unknown client (browser / game / CLI / …)
           │
           ▼
  leaf host  ←── full node software can provide this as a local/remote service
  (clone, serve files, run optional leaf runtime)
           │  push / fetch git or CAS
           ▼
  leaf remotes (often free): GitHub, Forgejo, self-host, …
           │  announce new tip
           ▼
  network validators  (verify proof + fee; store master_hash only)
```

**Git as empowerment, not consensus bus**

- Individuals or groups can get **free git hosting** (e.g. GitHub) for their home or group branch.
- Whatever client they use can **push** there; peers and leaf hosts **clone/fetch** to distribute updates and to recompute or verify tree hashes that become the next `master_hash`.
- The network may **read** public remotes when helping users sync, but consensus does **not** require GitHub uptime, git commit metadata, or a particular forge—only a valid proof over the new head.
- Optional: account meta may list **hint URLs** (`remotes[]`) so clients know where to fetch; hints are convenience, not consensus truth.

**Runtime is leaf-defined**

A leaf might expose an HTTP server + browser UI, load a game binary, run notebooks, or stay static files. The full node package **may** start such services for supported leaf types; it is not obligated to understand every leaf. Unsupported leaves are still valid on-chain as long as heads and proofs verify.

**“Connected to a node that supports their leaves”**

- Wallet-only clients can transfer GULD and read heads from any validator light/API path.
- **Contentful** clients need a **leaf host** (often the user’s own full node, or a hosted node they trust) that:
  - tracks network tip for their name/group  
  - materializes the matching tree (clone from remotes / CAS / pins)  
  - optionally runs the leaf’s chosen runtime  
- Full node software is the default way to get that host locally; third parties may offer “node-as-a-service” for specific leaf kinds without becoming consensus validators.

**Caveat:** relying solely on a commercial forge for availability is a **UX bootstrap**, not protocol DA. Serious leaves should mirror or self-host (or contract retention in-leaf); on-chain head can outlive a deleted GitHub repo.

### 4.5 Reference UI (web + extension)

Reference clients are **HTTP/browser-based**, not native-first: a **webapp/PWA** and especially a **browser extension** that injects `window.guld` so ordinary websites can act as Guld dapps (wallet + network ops with user confirmation). See [`../specs/14-reference-ui.md`](../specs/14-reference-ui.md).

---

## 5. Network validation (not a VM)

The L1 is intentionally **not** a programmable machine. It may:

- validate fixed **schemas** for a closed set of tx types  
- check **hashes**, **signatures**, and enumerated **leaf-consensus proofs**  
- apply **built-in** balance/tip/key updates  

It does **not** host user-defined functions, loops, or leaf languages. Those run only in leaves. That is why Bitcoin-style tx fees fit and an EVM gas ISA does not.

---

## 6. Transaction types (network surface)

Illustrative set (names TBD):

| Tx | Effect |
|----|--------|
| `RegisterUsername` | Bind individual name; pay `F_user` + miner fee |
| `RegisterGroup` | Bind group name with `n` signers; pay `F_group(n)` + miner fee |
| `RotateKeys` | Update keys/threshold with current policy proof |
| `UpdateMaster` | Advance `master_hash` with leaf-consensus proof |
| `Transfer` | Move GULD between named accounts |
| `Bond` / `Unbond` / `Slash` | Optional stake for **roles / name deposits** (policy TBD)—**not** CAS storage |

All txs pay a **weight-based fee**. Conflict sets are account ids touched; non-overlapping updates may execute in parallel within a block.

---

## 7. Consensus

### 7.1 Role of PoW

Open membership for block proposal uses **PoW or DAG-PoW** on headers that commit to:

- `prev` / DAG parents  
- `state_root`  
- `tx_root`  
- `receipt_root`  
- `difficulty` / `nonce`  
- `coinbase` (PQ-ready reward address)  
- `fee_total` / block weight used  

Useful validation (schema + proof verify + state transition) is **eligibility**. PoW elects among valid candidates and prices Sybil proposal spam. DAG-PoW variants may raise parallel block throughput without abandoning PoW’s open-entry property.

### 7.2 Finality

Probabilistic depth (Nakamoto / GHOSTDAG-class). Optional later checkpoints are out of scope for this draft.

### 7.3 Relation to stake

Bonded GULD may gate name deposits or future attestor roles. **CAS retention is not bonded on L1.** This draft does **not** require PoS tip election; weights live at the **account cosign** layer and optional bonds, not as a replacement for header PoW.

---

## 8. Tokenomics and fees

The network has a **fixed transaction vocabulary**. There is no user-defined opcode meter and no general-purpose on-chain VM. Validation is: parse schema → check hashes/sigs/proofs → apply built-in delta. That matches a **Bitcoin-style fee market** better than Ethereum gas.

### 8.1 Native asset: GULD

| Use | Description |
|-----|-------------|
| **Transaction fees** | Weight-priced inclusion fees → **miners** |
| **Registration fees** | Expensive `F_user` / `F_group(n)` → **burned** (anti-spam; burden is network-wide) |
| **Name deposits** | Optional extra lock on top of registration |
| **Transfers / DeFi** | Settlements between named identities |
| **Miner rewards** | Block subsidy (PoW issuance) + inclusion fees |

Hard fork from 1.0: import every positive `*:Assets` balance from `archives/ledger-guld` as genesis pre-mine **x**, then unlock per name via **key upgrade** (spec: [`../specs/15-ledger-import.md`](../specs/15-ledger-import.md); intent: [`../intents/ledger-migration.md`](../intents/ledger-migration.md)). See §8.6.

### 8.2 Why not an EVM-style gas ISA

| EVM gas | Guld network |
|---------|----------------|
| Meters arbitrary script steps | No custom functions on L1 |
| `gas_limit` / opcode schedule | Fixed tx kinds; cost ≈ size + sigs |
| Complex refunds / metering bugs | Simple weight policy |

Leaf runtimes may invent their own internal metering; the L1 never sees it.

### 8.3 Weight (virtual size)

Each tx has a **weight** in virtual bytes (vB), in the spirit of Bitcoin:

```
weight(tx) = size_bytes(tx)
           + W_sig × n_signatures
           + W_extra_account_write × max(0, n_writes - 1)
```

Registration also charges a separate **protocol fee** in GULD (`F_user` or `F_group(n)`), not only weight—see §3.3. Weight still grows with `n_signatures` so ongoing tips from large groups stay costly to include.

**Draft weights** (tunable at genesis / soft fork):

| Term | Draft | Rationale |
|------|-------|-----------|
| Serialized bytes | 1 weight unit / byte | Bandwidth + storage in block |
| `W_sig` | 64 vB per signature | Dominant verify cost |
| `W_extra_account_write` | 50 vB | Extra state leaves (e.g. transfer touches 2) |

**Draft registration fees** (magnitudes TBD; structure fixed):

| Fee | Formula |
|-----|---------|
| `F_user` | constant (painful vs spam) |
| `F_group(n)` | `F_group_base + F_group_per_signer × n` |

Signatures in the tx body already add `size_bytes`; `W_sig` is an **additional** CPU surcharge so large cosign sets remain expensive every tip—not only at registration.

**Examples (illustrative)**

| Tx | Approx size | Sigs | Writes | Weight | Protocol fee |
|----|-------------|------|--------|--------|--------------|
| `UpdateMaster` (1-of-1) | 200 B | 1 | 1 | ≈ **264 vB** | — |
| `UpdateMaster` (3-of-5) | 400 B | 3 | 1 | ≈ **592 vB** | — |
| `Transfer` | 150 B | 1 | 2 | ≈ **264 vB** | — |
| `RegisterUsername` | 250 B | 1 | 1 | ≈ **314 vB** | **`F_user`** |
| `RegisterGroup` (n=5) | 400 B | 5 | 1 | ≈ **720 vB** | **`F_group(5)`** |

### 8.4 Fee market (Bitcoin-style)

Users attach `fee` in GULD (or `fee_rate` × weight):

```
inclusion_fee ≥ fee_rate_min × weight(tx)     # policy / relay floor
inclusion_fee → miner who includes the tx

registration_protocol_fee F_*(n) → burned     # not to miner
```

- **Registration burns**; inclusion fees do **not** (Bitcoin-like).  
- Mempool orders by **fee rate** (GULD / vB), same intuition as sat/vB.  
- Blocks have a **weight limit** (draft **4_000_000** weight units / block—BTC-order; retune with benchmarks).  
- Miners maximize inclusion-fee total under the weight cap among valid txs (they still include registrations to earn the weight fee + advance the chain—not the burned `F_*`).

Congestion ⇒ users raise `fee_rate`. No opcode schedule to maintain.

### 8.5 Block capacity (order of magnitude)

If average tip update ≈ 300 vB and block weight limit = 4 M:

| Effective blocks/sec | Tip updates/sec (order) |
|----------------------|-------------------------|
| 0.1 | ~1 300 |
| 1 | ~13 000 |
| (DAG parallel blocks) | higher; specify in client |

Sig-heavy tips consume more weight → self-limit. Target remains **L1-class**, not Visa.

### 8.6 Supply, pre-mine, and issuance

#### Pre-existing GULD as genesis pre-mine

**Snapshot source:** `archives/ledger-guld` — per-user ledger-cli journals (`*.dat`), concatenated in timestamp order into a single journal (also archived as `guld-ledger-all.dat` alongside a flat balance dump). Period covered: **2016-06-01 → 2018-12-09**.

**Amount precision:** the 1.0 journal uses at most **10 decimal places** in any `GULD` amount. Freeze: **10** decimals (1 GULD = 10¹⁰ quanta).

Let **x** = total GULD imported at genesis = sum of positive member `name:Assets` roots:

| Quantity | GULD (working) |
|----------|----------------|
| **x** = member circulating / claimable | **≈ 959,947.19527052** |

**Not imported:** `guld:Assets:ERC20` and other protocol-side ERC20 mirror buckets (barely used in 1.0; omitted from the pre-mine).

Notes from the same pass:

- **≈ 2,217** names with positive `Assets`; ~15 names with negative `Assets` summing to ≈ **−1,028** GULD (import as **0**; list in the genesis anomaly appendix).
- Top holders (share of **x**): mizim ≈ 37%, isysd ≈ 9%, cz ≈ 4%, raadyx ≈ 3%, tigoctm ≈ 3%, then betatown, zimmi, aehaynes, torvalds, minotaur (~1% each). Top 10 ≈ **63%** of **x**.

```
circulating_supply(0) = x ≈ 959_947.20 GULD   // claimable by 1.0 names; legacy-locked until key upgrade
```

#### Respect balances; unlock via key upgrade

**Invariant:** every positive 1.0 `Assets` balance is imported 1:1. No haircut, no silent consolidation, no reassignment of names.

Import creates **legacy-locked** accounts: balance is on-chain, but `Transfer`, tip spend, and ordinary `RotateKeys` are disabled until the owner completes a **key upgrade** (`ClaimLegacy` — [`../specs/15-ledger-import.md`](../specs/15-ledger-import.md)):

1. Prove control of the 1.0 identity (PGP / published binding over `name ‖ new_keys ‖ …`).
2. Record Ed25519 (or hybrid) keys + threshold; clear the legacy lock.
3. Thereafter the account is a normal 2.0 individual; further rotations use `RotateKeys`.

Unclaimed balances remain in the owner's name; they count toward **x** but do not move without a valid claim. From genesis forward, **new** GULD enters only via the **block subsidy**.

#### Block time

**Target block interval: 10 minutes** (600 s) — Bitcoin-class. Comfortable for identity tips and weight-priced inclusion; keeps header/PoW overhead modest. Normative draft:

```
TARGET_BLOCK_INTERVAL = 600        // seconds
BLOCKS_PER_YEAR       = 52_560     // 365 × 144
```

Retarget keeps mean interval near target (**TBD** algo in [`../specs/06-blocks-and-consensus.md`](../specs/06-blocks-and-consensus.md)).

#### Inflation schedule (locked draft)

Annual inflation rate **i(y)** (fraction of supply at the start of year **y**, y = 1 at genesis) decays **geometrically** from **100%** in year 1 to **4%** in year 20, then stays at **4%** forever:

```
i(y) = 0.04 ** ((y - 1) / 19)     // y = 1..20   →  1.00 … 0.04
i(y) = 0.04                        // y >= 21
```

```
S(0) = x
annual_issuance(y) = S(y - 1) * i(y)
S(y) = S(y - 1) + annual_issuance(y)
subsidy(height) = annual_issuance(year(height)) / BLOCKS_PER_YEAR
```

`year(height) = floor((height - 1) / BLOCKS_PER_YEAR) + 1`. Within a year the per-block subsidy is **constant** (deterministic from genesis `x`). Consensus MUST embed the precomputed yearly per-block table (or an equivalent pure function of `height` and `x`).

**Why geometric ΔS/S:** a linear drop of the inflation *rate* while compounding would stay near 100% for many years and mint thousands× **x**. Geometric decay opens hot (year 1 doubles supply), reaches the 4% tail on schedule, and has **no reward cliff** at year 21.

##### Rewards schedule (working `x`; gross subsidy; burns omitted)

| Year | Inflation i(y) | Annual issuance (GULD) | Subsidy / block (GULD) | Supply end (GULD) | Supply / x |
|------|----------------|------------------------|------------------------|-------------------|------------|
| 1 | 100.00% | 959,947.20 | 18.263836 | 1,919,894.39 | 2.000× |
| 2 | 84.42% | 1,620,695.96 | 30.835159 | 3,540,590.35 | 3.688× |
| 3 | 71.26% | 2,523,039.80 | 48.003040 | 6,063,630.15 | 6.317× |
| 4 | 60.16% | 3,647,584.27 | 69.398483 | 9,711,214.42 | 10.116× |
| 5 | 50.78% | 4,931,401.74 | 93.824234 | 14,642,616.16 | 15.254× |
| 6 | 42.87% | 6,276,820.78 | 119.422009 | 20,919,436.93 | 21.792× |
| 7 | 36.19% | 7,569,989.05 | 144.025667 | 28,489,425.99 | 29.678× |
| 8 | 30.55% | 8,702,683.10 | 165.576163 | 37,192,109.09 | 38.744× |
| 9 | 25.79% | 9,590,571.50 | 182.469016 | 46,782,680.59 | 48.735× |
| 10 | 21.77% | 10,183,638.95 | 193.752644 | 56,966,319.54 | 59.343× |
| 11 | 18.38% | 10,467,916.80 | 199.161279 | 67,434,236.34 | 70.248× |
| 12 | 15.51% | 10,460,362.97 | 199.017560 | 77,894,599.31 | 81.145× |
| 13 | 13.09% | 10,199,945.90 | 194.062898 | 88,094,545.21 | 91.770× |
| 14 | 11.05% | 9,737,864.98 | 185.271404 | 97,832,410.19 | 101.914× |
| 15 | 9.33% | 9,128,968.19 | 173.686609 | 106,961,378.39 | 111.424× |
| 16 | 7.88% | 8,425,392.50 | 160.300466 | 115,386,770.89 | 120.201× |
| 17 | 6.65% | 7,672,614.55 | 145.978207 | 123,059,385.44 | 128.194× |
| 18 | 5.61% | 6,907,586.20 | 131.422873 | 129,966,971.64 | 135.390× |
| 19 | 4.74% | 6,158,412.58 | 117.169189 | 136,125,384.21 | 141.805× |
| 20 | 4.00% | 5,445,015.37 | 103.596183 | 141,570,399.58 | 147.477× |
| 21+ | 4.00% | 0.04 · S(y−1) | recomputed each year | +4%/yr | — |

Peak **per-block** subsidy is around years **11–12** (~199 GULD/block) as `S·i(y)` maximizes; thereafter block rewards decline toward the 4% tail even while supply rises.

##### Supply and inflation graphs

```mermaid
xychart-beta
    title Inflation rate i(y) — 100% to 4% over 20 years
    x-axis [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]
    y-axis "i(y) %" 0 --> 100
    line [100, 84.4, 71.3, 60.2, 50.8, 42.9, 36.2, 30.6, 25.8, 21.8, 18.4, 15.5, 13.1, 11.1, 9.3, 7.9, 6.7, 5.6, 4.7, 4.0]
```

```mermaid
xychart-beta
    title Circulating supply / x (gross subsidy; burns omitted)
    x-axis [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]
    y-axis "S/x" 0 --> 150
    line [2.0, 3.7, 6.3, 10.1, 15.3, 21.8, 29.7, 38.7, 48.7, 59.3, 70.2, 81.1, 91.8, 101.9, 111.4, 120.2, 128.2, 135.4, 141.8, 147.5]
```

```mermaid
xychart-beta
    title Block subsidy (GULD per 10-minute block)
    x-axis [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]
    y-axis "GULD/block" 0 --> 200
    line [18.3, 30.8, 48.0, 69.4, 93.8, 119.4, 144.0, 165.6, 182.5, 193.8, 199.2, 199.0, 194.1, 185.3, 173.7, 160.3, 146.0, 131.4, 117.2, 103.6]
```

Subsidy is paid in the **coinbase** to the miner. **Inclusion fees** add to miner revenue; **registration burns** remove GULD from supply (realized supply tracks below the gross table).

#### Burn vs issuance (net inflation)

```
Δsupply ≈ block_subsidy − F_burned − (optional other burns)
```

- Early years: subsidy dominates → high net inflation (by design).
- Later: 4% gross issuance, offset in part by registration burns → **effective** inflation can sit below 4% when namespace demand is strong.

#### Why not zero long-run inflation?

New humans and new named identities continually join. A pure capped supply plus burned registrations could starve miner security or make names unreachably expensive in GULD terms. Perpetual **4%** funds security and leaves room for newcomers.

| Flow | Direction | Rationale |
|------|-----------|-----------|
| 1.0 `*:Assets` → genesis | Pre-mine **x** (locked until key upgrade) | Continuity; respect every balance |
| Key upgrade (`ClaimLegacy`) | Unlock spend/tip under new keys | Port 1.0 → 2.0 without moving coins |
| Block subsidy | Mint → miner | PoW security + distribution |
| Inclusion (weight) fee | User → miner | Pay for block space |
| Registration `F_*` | User → **burn** | Pay for global state/proof burden |
| Name deposit | Lock / unlock | Optional squat policy |

**Invariant:** no hidden inflation beyond this schedule; **x** and the per-name import manifest are disclosed at genesis; registration burns are consensus-enforced; no imported balance spends until key upgrade.

### 8.7 Content retention (leaf, not L1)

**Locked:** there is **no** network-level `PinClaim` / bonded pin / slash-for-missing-data market in consensus.

- **`guld`:** full nodes **must** retain the complete current `guld` home (protocol software + rules). Membership requirement for validating—not a pin market.
- **All other accounts:** the chain stores the tip (`master_hash`) only. Bytes live in CAS / remotes / leaf hosts. **Tip ≠ data availability.**
- **Who keeps bytes:** self-host, forge mirrors, BitTorrent-class sharing, or **private leaf contracts** (cosign, escrow `Transfer`s, group policy). Parties who care arrange retention off the consensus path.
- **Why not L1 pins:** slash-for-missing-data needs a hard DA protocol; it bloats fixed-tx surface and fights leaf sovereignty. Optional storage markets MAY appear later as **apps/leaves**, not as required L1 txs.

---
## 9. Scalability analysis

### 9.1 State growth (keys + hashes)

Validators store per account roughly: 1 key (32 B) + ~10 SHA-256 fields (320 B) + meta, with LSM/SMT overhead (~2.5–4×).

| Accounts | Cold state (≈ mid overhead) |
|----------|-----------------------------|
| 10 M | ~10 GiB |
| 100 M | ~100 GiB |
| 1 B | ~1 TiB |

Retaining **10 historical tips for recently active** accounts only adds marginally. This is realistic for global identity **because file bytes are not in the consensus DB**.

### 9.2 Bandwidth and CPU

- Bottleneck: **signature verification** ∝ signatures per tip, not SHA-256.  
- 1 000 single-sig tip updates/s ≈ order **0.1** core-s/s at ~100 µs/verify (parallelizable).  
- Large thresholds (e.g. 100-of-150) raise **weight and CPU** linearly—**priced in**, self-limiting.

### 9.3 Execution parallelism

Conflict graph = accounts touched. Alice’s `UpdateMaster` ∥ Bob’s `UpdateMaster`. Contended names/accounts serialize. This matches Solana-style account parallelism without adopting the SVM.

### 9.4 Data availability

Scalability of **content** is orthogonal: tips scale with accounts; blobs scale with **leaf hosting and mirrors**. Full nodes must fully clone **`guld`**; for other accounts they fetch only when a client/leaf-host chooses. Light clients verify state proofs against headers. **No L1 pin market.**

### 9.5 Comparison

| Approach | Validator state | Per-tx work |
|----------|-----------------|-------------|
| General L1 VM re-executing group logic | Large + unbounded | High, variable |
| Guld witness L1 (fixed txs) | Keys + tips + balances | Schema + proof verify + writes |
| Git mega-repo consensus | Explodes with history | Merge/social metadata |

**Conclusion:** identity-scale state is feasible; throughput is gated by **block weight**, **proof size**, and **PoW/DAG rate**—Bitcoin-class levers—not by leaf language choice.

---

## 10. Game theory analysis

### 10.1 Players

| Player | Action | Payoff drivers |
|--------|--------|----------------|
| Users / groups | Register, tip, transfer, cosign | Utility of settlement + reputation of name |
| Cosigners | Sign or withhold | Shared control vs liability of cowitness |
| Miners | Which valid txs to include; PoW | Rewards − energy − orphan risk |
| Leaf hosts | Retain or drop bytes | Leaf contracts / reputation / fees (off L1) |
| Attackers | Spam, squat, forge, reorg | Theft / griefing vs cost |

### 10.2 Leaf cosign as a game

- **Threshold policy** is on-chain; internal preference aggregation is off-chain.  
- Rational cosigners sign when the leaf process they accept says so; the chain cannot force “honest politics,” only **attributable authorization**.  
- **Griefing:** a minority below threshold cannot advance the tip; a malicious majority *of keys* can—same as any multisig. Mitigations: key rotation, role separation (tip vs spend), social recovery schemes as leaf policy compiling to `RotateKeys`.  
- **Cowitness liability:** cryptographic responsibility is clear; expanding legal meaning is out of protocol scope but supported by auditable signed messages.

### 10.3 Fee market and burns

- Under congestion, users raise **inclusion fee rate** (GULD/vB); low-fee tips wait.  
- Miners maximize **inclusion** fees under the weight limit (Bitcoin-like).  
- **Registration burns** cannot be captured by miners—no incentive to spam-register for coinbase side-payments; the burn pays the *network* for permanent load.  
- High early **subsidy** pulls hashpower and redistributes away from pure pre-mine dominance; long-run **4%** keeps a security budget as identity demand grows.

### 10.4 PoW security

- Cost of rewrite ≈ energy × depth; same family as Bitcoin.  
- DAG-PoW changes throughput and topology, not the “work is scarce” principle.  
- **Nothing-at-stake** is primarily a PoS issue; pure PoW proposers still risk orphaned work (wasted energy).

### 10.5 Username scarcity and registration cost

- Free names ⇒ squatters and spam identities. **High `F_user` / `F_group(n)`** make bulk registration painful (Guld 1.0 continuity).  
- Scaling `F_group` with signer count prices the **proof burden** groups impose on every full node.  
- Impersonation remains a social problem; cryptographic binding is name→keys on-chain. Apps may add secondary attestations (leaf or indexer)—not consensus-critical.

### 10.6 Validator laziness (Verifier’s Dilemma)

- Verification is **cheap and fixed-shape** (schema + sigs + hash checks), so skipping verify is less tempting than for heavy smart-contract re-exec—but still possible.  
- Invalid blocks are rejected by honest majority hashpower; light clients use state proofs against headers.  
- Keep proofs small and weight-priced so honest full nodes stay common.

### 10.7 Content availability (leaf)

- L1 does **not** bond or slash for CAS retention.  
- Tips can outlive missing blobs—**users who care self-host, mirror, or contract in a leaf**.  
- Altruistic / forge / BitTorrent-class availability is acceptable for public content; private groups use leaf terms.

### 10.8 Incentive compatibility summary

| Desired behavior | Mechanism |
|------------------|-----------|
| Keep protocol rules available | Full nodes **must** clone account `guld` |
| Don’t spam tips | Weight-priced inclusion fees |
| Don’t spam identities | Expensive `F_user` / `F_group(n)` **burned** |
| Don’t forge tips | Unforgeable sigs under registered keys |
| Provide security | PoW subsidy + inclusion fees |
| Dilute pre-mine fairly | Geometric inflation 100% → 4% over 20 years, then 4% |
| Offset issuance | Registration burns (deflationary pressure) |
| Keep important bytes | Self-host / forge mirrors / **leaf** retention contracts |
| Don’t underpay large multisig | `W_sig × n` ongoing + higher group registration |
| Own your governance | Leaf process; chain only checks proofs |

---

## 11. Security notes

- **Cryptography:** SHA-256 commitments; AES-256 confidential leaves; Ed25519 (or hybrid PQ) account sigs.  
- **Quantum:** signature migration plan required; PoW hash enlargement optional.  
- **Privacy:** names are public; tree contents may be encrypted; graph metadata may leak via tip timing—threat model TBD.  
- **Upgrades:** new proof kinds and weight policy via soft/hard fork—not silent leaf reinterpretation.

---

## 12. Roadmap (indicative)

1. Freeze account schema + `threshold_cosign_v1` + weight fee policy + **10 decimals**  
2. Rust validator MVP: state DB, fixed txs, headers, single-lane PoW  
3. Pin genesis import manifest from `ledger-guld`; ship `ClaimLegacy` key upgrade  
4. Leaf SDKs (Python/JS) + leaf host in full node; optional git remotes (GitHub, …)  
5. Indexers for apps; leaf-host retention tooling (no L1 pin market)  
6. DAG-PoW / parallelism; PQ migration  

---

## 13. Conclusion

Guld 2.0 proposes an L1 where **identity is the product**: global names, hash-linked personal and group heads, and **flexible leaf control** with the network as a **witness**—not a programmable VM. DeFi settles between names under a **Bitcoin-style weight fee** market. Legacy supply **x ≈ 9.6×10⁵ GULD** is a disclosed pre-mine from the 1.0 ledger (ERC20 bucket omitted), unlocked per user by **key upgrade**; PoW issuance follows a locked **100% → 4% over 20 years** schedule at **10-minute** blocks, with **burned registration fees** as deflationary pressure. Scalability follows from keeping validators on keys and hashes; content retention stays in **leaves**; game theory follows from attributable cosign, fee-rate bidding, burns, and PoW security.

This whitepaper is a **draft**. Parameters (emission, name deposits, exact PoW flavor, PQ genesis, weight constants) remain open. The invariants intended to hold are: **name-addressable accounts**, **hash-referenced tips**, **leaf-sovereign process**, **lean witness nodes**, **fixed tx vocabulary**, **priced inclusion**, **respected 1.0 balances**, and **tip ≠ DA** (CAS retention off L1 except mandatory `guld`).

---

## References (internal)

- [`research/modern-l1-direction.md`](../research/modern-l1-direction.md)  
- [`research/block-window-consensus.md`](../research/block-window-consensus.md)  
- [`research/storage-scale-git-postgres.md`](../research/storage-scale-git-postgres.md)  
- [`research/postgres-blockchain.md`](../research/postgres-blockchain.md)  
- [`intents/ledger-migration.md`](../intents/ledger-migration.md)  
- [`specs/15-ledger-import.md`](../specs/15-ledger-import.md)  
- [`UPGRADE_FROM_1.md`](../UPGRADE_FROM_1.md)  

## Change log

| Version | Notes |
|---------|--------|
| 0.1-draft | First whitepaper draft from modern L1 research |
| 0.2-draft | Network is not a VM; Bitcoin-style weight fees replace EIP-1559 gas ISA |
| 0.3-draft | Clients / leaf hosts / free git remotes (GitHub-class) UX model |
| 0.4-draft | SHA-256 network homes; priced individual/group registration (`F_group` ∝ signers) |
| 0.5-draft | Pre-mine x; year-1 ~2× supply then 2–4% tail; registration fees burned |
| 0.6-draft | Reserved `guld` account; full nodes must clone protocol home; repo as sub-leaf |
| 0.7-draft | 1.0 ledger snapshot figures (~1.06e6 GULD **x**); 10 decimals; key-upgrade claim path |
| 0.8-draft | Drop ERC20 from **x** (~9.60e5); geometric inflation 100%→4% / 20y; 10-min blocks; supply & reward graphs |
| 0.9-draft | No L1 pin/slash market; CAS retention is leaf/self-host/forge only; `guld` clone still mandatory |