init

Esau · Esau · commit 766e1ac7597b · 2026-01-30T22:16:00.000+08:00
diff --git a/docs/docs-network/concepts/economics/_category_.json b/docs/docs-network/concepts/economics/_category_.json
@@ -0,0 +1,6 @@
+{
+    "position": 3,
+    "collapsible": true,
+    "collapsed": true,
+    "label": "Economics & Rewards"
+}
diff --git a/docs/docs-network/concepts/economics/index.md b/docs/docs-network/concepts/economics/index.md
@@ -0,0 +1,79 @@
+---
+title: Economics & Rewards
+description: Learn about Aztec network economics including reward distribution, sequencer and prover incentives, and the activity score system.
+displayed_sidebar: conceptsSidebar
+---
+
+# Economics & Rewards
+
+The Aztec network uses economic incentives to encourage honest participation and consistent operation. This page explains how rewards are distributed and what factors influence earnings.
+
+## Reward Sources
+
+Network participants earn rewards from two sources:
+
+1. **Slot Rewards**: Protocol-funded rewards distributed each slot (inflationary)
+2. **Transaction Fees**: Fees paid by users for transaction processing
+
+## Slot Rewards
+
+The protocol mints new tokens each slot as rewards. The current slot reward is **400 $AZTEC**, split between sequencers and provers:
+
+| Recipient | Share | Amount Per Slot |
+|-----------|-------|-----------------|
+| **Sequencers** | 70% | 280 $AZTEC |
+| **Provers** | 30% | 120 $AZTEC |
+
+This value can be adjusted through governance.
+
+### How Slot Rewards Flow
+
+```mermaid
+flowchart TD
+    Issuer[Issuer Contract] -->|Mints tokens| Dist[Reward Distribution]
+    Dist -->|Claims per slot| Rollup[Rollup Contract]
+    Rollup -->|70% · 280 $AZTEC| Seq[Block Proposer]
+    Rollup -->|30% · 120 $AZTEC| ProverPool[Prover Reward Pool]
+```
+
+## Sequencer Rewards
+
+Sequencers earn rewards for successfully proposing and finalizing blocks:
+
+- **Slot share**: 70% of each slot reward (280 $AZTEC) goes to the block proposer, paid when the block is finalized on L1
+- **Transaction fees**: Sequencers collect fees from users; a portion is burned via the base fee mechanism, and the remainder is split between sequencer and prover
+
+## Prover Rewards
+
+Provers earn rewards for generating validity proofs that finalize blocks:
+
+- **Slot share**: 30% of each slot reward (120 $AZTEC), distributed among provers who participated in the epoch
+- **Transaction prover fees**: Provers receive a portion of transaction fees, with the rate set by protocol parameters
+
+### Activity Score and Reward Distribution
+
+Prover slot rewards are not split equally. They are distributed based on each prover's **activity score**, which measures consistency of participation. The score:
+
+- **Increases** by 125,000 per epoch of active proving
+- **Decreases** by 100,000 per epoch of inactivity
+- **Maximum**: 15,000,000 points
+
+A prover's share of the reward pool is determined by a quadratic penalty formula:
+
+```
+shares = k - (a × (maxScore - score)²) / 1e10
+```
+
+Where `k = 1,000,000`, `a = 1,000`, and the minimum share is `100,000`.
+
+At maximum activity score, a prover receives the full `k` shares. As the score drops, the quadratic term reduces shares increasingly aggressively, meaning small drops have minimal impact but extended inactivity significantly reduces earnings.
+
+This design rewards long-term, consistent provers and discourages sporadic participation.
+
+---
+
+:::tip Learn More
+- [Proof of Stake](../proof-of-stake/index.md) - How staking and validation work
+- [Governance](../governance/index.md) - How protocol parameters (including rewards) can change
+- [Running a Prover](../../operators/setup/running-a-prover.md) - Technical setup for provers
+:::
diff --git a/docs/docs-network/concepts/governance/index.md b/docs/docs-network/concepts/governance/index.md
@@ -10,6 +10,18 @@ import Image from "@theme/IdealImage";
 
 The Aztec network is governed by its community through an onchain governance system. This system allows the network to upgrade rollup contracts, adjust parameters, and evolve over time while maintaining security and decentralization.
 
+## Quick Summary for Token Holders
+
+If you're a token holder looking to participate in governance, here's what you need to know:
+
+| Your Situation | How to Participate | What Happens |
+|----------------|-------------------|--------------|
+| **I have staked tokens** (as sequencer or delegator) | Nothing required - you're already participating | Your voting power is automatically delegated to the rollup, which votes "yea" on proposals that passed sequencer signaling |
+| **I want to vote differently than the default** | Delegate your voting power to yourself | You can cast your own votes on proposals |
+| **I have tokens but haven't staked** | Lock tokens in the Governance contract | You gain voting power without staking rewards or slashing risk |
+
+For step-by-step instructions, see [Voting on Proposals](../../users/voting.md).
+
 ## Design Goals
 
 The governance system is designed around two core requirements:
diff --git a/docs/docs-network/concepts/proof-of-stake/index.md b/docs/docs-network/concepts/proof-of-stake/index.md
@@ -29,7 +29,7 @@ Validators must stake tokens on L1 to join the sequencer set. The staked tokens
 
 **Activation Delay**: After staking, a sequencer needs to wait for an activation period before they can start proposing new blocks. This delay provides time for the network to recognize the new validator.
 
-**Unstaking Delay**: Unstaking requires a delay to allow for slashing of dishonest behavior that may have occurred while the validator was active.
+**Unstaking Delay**: Unstaking requires a delay to allow for slashing of dishonest behavior that may have occurred while the validator was active. See [Unstaking](#unstaking) for details on the specific delay periods.
 
 ### Stake Delegation
 
@@ -104,6 +104,83 @@ Because transaction data and attestations are not posted onchain, automatic slas
 
 A sequencer must aggregate BLS signatures on slashing proposals and post them to L1 for slash execution. When a sequencer's balance is slashed below `MINIMUM_STAKING_BALANCE` (e.g., 50%), they are removed from the sequencer set.
 
+## Unstaking
+
+Unstaking is the process of withdrawing your staked tokens from the network. When you initiate a withdrawal, two delays start **in parallel**:
+
+1. **Staking exit delay** — enforced by the Rollup contract
+2. **Governance withdrawal delay** — enforced by the Governance contract (since staked tokens also carry voting power)
+
+You must wait for **both** to pass before finalizing your withdrawal. The effective exit delay is whichever is longer.
+
+### Staking Exit Delay
+
+The Rollup contract enforces an exit delay to allow time for pending slashing conditions to be detected, and to prevent validators from quickly exiting after misbehaving.
+
+#if(testnet)
+**Testnet staking exit delay:** 172,800 seconds = **2 days**
+#else
+**Mainnet staking exit delay:** 345,600 seconds = **4 days**
+#endif
+
+### Governance Withdrawal Delay
+
+Because staked tokens carry voting power via the GSE (Governance Staking Escrow), the Governance contract also enforces a withdrawal delay. This prevents governance attacks where someone could vote on a malicious proposal and immediately exit before it executes.
+
+The governance withdrawal delay is calculated as:
+
+```
+withdrawalDelay = (votingDelay / 5) + votingDuration + executionDelay
+```
+
+#if(testnet)
+**Testnet governance values:**
+
+| Component | Value |
+|-----------|-------|
+| Voting Delay | 43,200s (12 hours) |
+| Voting Duration | 86,400s (1 day) |
+| Execution Delay | 43,200s (12 hours) |
+| **Calculation** | **(43,200 / 5) + 86,400 + 43,200 = 138,240s** |
+| **Governance Withdrawal Delay** | **~1.6 days** |
+#else
+**Mainnet governance values:**
+
+| Component | Value |
+|-----------|-------|
+| Voting Delay | 259,200s (3 days) |
+| Voting Duration | 604,800s (7 days) |
+| Execution Delay | 604,800s (7 days) |
+| **Calculation** | **(259,200 / 5) + 604,800 + 604,800 = 1,261,440s** |
+| **Governance Withdrawal Delay** | **~14.6 days** |
+#endif
+
+### Effective Exit Delay
+
+Since both delays start at the same time, the effective wait is whichever is longer:
+
+#if(testnet)
+| Delay | Duration |
+|-------|----------|
+| Staking exit delay | 2 days |
+| Governance withdrawal delay | ~1.6 days |
+| **Effective exit delay** | **2 days** |
+#else
+| Delay | Duration |
+|-------|----------|
+| Staking exit delay | 4 days |
+| Governance withdrawal delay | ~14.6 days |
+| **Effective exit delay** | **14.6 days** |
+#endif
+
+### Unstaking Process
+
+1. **Initiate withdrawal**: Begin the exit process via the [Staking Dashboard](https://stake.aztec.network/)
+2. **Wait for the exit delay**: Your tokens remain locked during this period
+3. **Finalize withdrawal**: After the delay, complete the withdrawal to receive your tokens
+
+For step-by-step instructions, see the [Unstaking Guide](../../users/staking.md#unstaking).
+
 ---
 
 :::tip Ready to participate?
diff --git a/docs/docs-network/operators/operator-faq.md b/docs/docs-network/operators/operator-faq.md
@@ -170,6 +170,27 @@ Error: Unable to get blob sidecar, Gateway Time-out (504)
    - Running your own provides better reliability and eliminates timeouts
    - See the [prerequisites guide](./prerequisites.md) for L1 infrastructure setup
 
+## L1 Node Requirements
+
+### Do I Need an L1 Archive Node?
+
+No. You do not need an L1 archive node to run an Aztec node. Snapshot sync is the recommended approach and works with standard L1 full nodes.
+
+To use snapshot sync, set `SYNC_MODE=snapshot` in your configuration.
+
+#if(testnet)
+### Consensus RPC and Blob Availability (Testnet)
+
+On testnet, your L1 consensus (beacon) RPC endpoint must be able to serve **all blob data**. Standard beacon nodes only retain blobs for approximately 18 days (4096 epochs), which may not be sufficient.
+
+To meet this requirement, you need a consensus node configured as either a:
+
+- **Supernode**: Stores all 128/128 data columns regardless of validator staking weight. This provides full blob availability.
+- **Semi-supernode**: Stores enough data columns (typically 64/128) to reconstruct blobs. This is sufficient for testnet participation.
+
+This requirement is specific to testnet. On mainnet, standard beacon nodes with default blob retention are expected to be sufficient.
+#endif
+
 ## Funding and Resources
 
 ### Insufficient L1 Funds
@@ -192,6 +213,8 @@ Error: insufficient funds for gas * price + value
    - [Alchemy Sepolia Faucet](https://www.alchemy.com/faucets/ethereum-sepolia)
    - [Infura Sepolia Faucet](https://www.infura.io/faucet/sepolia)
 
+   For Aztec testnet tokens (TST), use the **[Aztec Testnet Faucet](https://testnet.aztec.network/)**.
+
 2. **Maintain sufficient balance**:
 #else
 **Cause**: Your publisher address doesn't have enough ETH to pay for L1 gas fees.
diff --git a/docs/docs-network/users/index.md b/docs/docs-network/users/index.md
@@ -21,6 +21,28 @@ Use your staked tokens to vote on governance proposals that shape the future of
 
 ---
 
+#if(testnet)
+## Getting Testnet Tokens
+
+To participate in the Aztec testnet, you'll need testnet tokens. Visit the **[Aztec Testnet Faucet](https://testnet.aztec.network/)** to get started.
+
+The faucet provides:
+- Testnet TST tokens for staking and governance participation
+- Instructions for connecting your wallet
+
+You'll also need Sepolia ETH for L1 transaction fees. See the [Sepolia Faucets](#sepolia-eth-faucets) section below.
+
+### Sepolia ETH Faucets
+
+For L1 operations (staking, governance transactions), you need Sepolia ETH:
+
+- [Sepolia Faucet](https://sepoliafaucet.com/)
+- [Alchemy Sepolia Faucet](https://www.alchemy.com/faucets/ethereum-sepolia)
+- [Infura Sepolia Faucet](https://www.infura.io/faucet/sepolia)
+#endif
+
+---
+
 ## Before You Start
 
 Understanding these concepts will help you make informed decisions:
diff --git a/docs/docs-network/users/staking.md b/docs/docs-network/users/staking.md
@@ -56,6 +56,31 @@ Before staking, understand that your stake can be partially slashed if:
 
 See [Slashing Concepts](../concepts/proof-of-stake/#slashing) for detailed information.
 
+## Unstaking
+
+When you want to withdraw your staked tokens, you must go through an unstaking process with a mandatory exit delay.
+
+#if(testnet)
+The exit delay for testnet is **2 days**. For a breakdown of how this is calculated, see [Unstaking Concepts](../concepts/proof-of-stake/#unstaking).
+#else
+The exit delay for mainnet is **14.6 days**. For a breakdown of how this is calculated, see [Unstaking Concepts](../concepts/proof-of-stake/#unstaking).
+#endif
+
+### How to Unstake
+
+To unstake your tokens, use the [Aztec Staking Dashboard](https://stake.aztec.network/). The dashboard guides you through the unstaking process:
+
+1. **Initiate withdrawal**: Select your validator and begin the exit process
+2. **Wait for the exit delay**: Your tokens remain locked during this period
+3. **Finalize withdrawal**: After the delay, complete the withdrawal to receive your tokens
+
+If you've delegated stake, contact your operator or use the delegation interface to request unstaking.
+
+### Important Considerations
+
+- **Slashing Risk**: You can still be slashed during the exit delay if misbehavior is detected from when you were active
+- **No Rewards During Exit**: You do not earn staking rewards during the exit delay period
+
 ## Next Steps
 
 - [Delegate your stake](./delegation) if you prefer not to run infrastructure
diff --git a/docs/docs-network/users/voting.md b/docs/docs-network/users/voting.md
diff --git a/docs/sidebars-network.js b/docs/sidebars-network.js
