dusk-network · HDauven · Feb 16, 2026 · Feb 15, 2026 · Feb 15, 2026 · Feb 15, 2026
diff --git a/.gitignore b/.gitignore
@@ -19,3 +19,6 @@ pnpm-debug.log*
 
 # macOS-specific files
 .DS_Store
+
+# Local analytics exports (do not commit)
+Pages_and_screens_*.csv
diff --git a/src/content/docs/developer/overview.mdx b/src/content/docs/developer/overview.mdx
@@ -77,6 +77,6 @@ If that’s you, start with:
 
 You can explore existing contracts and examples in the Dusk repos:
 
-- Protocol contracts in [`rusk/contracts`](https://github.com/dusk-network/rusk/tree/master/contracts)
+- Protocol genesis contracts in [`contracts/genesis`](https://github.com/dusk-network/contracts/tree/main/genesis)
 - The DuskDS example [`my-first-contract`](https://github.com/dusk-network/my-first-contract)
 - DuskEVM examples in the [DuskEVM docs](/developer/smart-contracts-dusk-evm/deploy-on-evm)
diff --git a/src/content/docs/developer/smart-contract/hyperstaking_tech.md b/src/content/docs/developer/smart-contract/hyperstaking_tech.md
@@ -28,7 +28,7 @@ The stake is considered active after a maturity period of 4320 blocks (~12 hours
 :::
 
 ### Interacting with the Stake Contract
-Stake Abstraction requires contracts to interact with the <a href="https://raw.githubusercontent.com/dusk-network/rusk/rusk-1.0.0/contracts/stake/src/state.rs" target="_blank">Stake Contract</a>.
+Stake Abstraction requires contracts to interact with the <a href="https://raw.githubusercontent.com/dusk-network/contracts/main/genesis/stake/src/state.rs" target="_blank" rel="noreferrer">Stake Contract</a>.
 
 
 #### Required contract calls
@@ -72,7 +72,7 @@ To implement Stake Abstraction, you can refer to <a href="https://raw.githubuser
 
 Differently from normal users, that stake directly by calling `stake(stake: Stake)`, smart contracts must use `stake_from_contract(recv: ReceiveFromContract)`.
 
-This is because the <a href="https://raw.githubusercontent.com/dusk-network/rusk/rusk-1.0.0/contracts/stake/src/state.rs" target="_blank">Stake Contract</a> defines `stake_from_contract(recv: ReceiveFromContract)`, which requires a `ReceiveFromContract` object. By doing so, it ensures that the calling contract is verified as the stake owner and that the function is only triggered as part of a fund transfer.
+This is because the <a href="https://raw.githubusercontent.com/dusk-network/contracts/main/genesis/stake/src/state.rs" target="_blank" rel="noreferrer">Stake Contract</a> defines `stake_from_contract(recv: ReceiveFromContract)`, which requires a `ReceiveFromContract` object. By doing so, it ensures that the calling contract is verified as the stake owner and that the function is only triggered as part of a fund transfer.
 
 In the <a href="https://raw.githubusercontent.com/dusk-network/rusk/refs/heads/master/contracts/charlie/src/state.rs" target="_blank">example</a> implementation, `stake()` does not call `stake_from_contract` directly. Instead, it first transfers the funds and then invokes `stake_from_contract` via a `contract-to-contract` call.
 
@@ -215,4 +215,4 @@ pub fn receive_reward(&mut self, receive: ReceiveFromContract) {
     let _: () = abi::call(TRANSFER_CONTRACT, "withdraw", &withdraw)
         .expect("Withdrawing rewards should succeed");
 }
-```
+```
diff --git a/src/content/docs/learn/core-components.md b/src/content/docs/learn/core-components.md
@@ -3,93 +3,86 @@ title: Core Components
 description: Introduction to the core components that power Dusk.
 ---
 
-Dusk is built with a modular architecture, leveraging tools and components specifically designed to meet [institutional standards](/learn/tokenization-comparison#meeting-institutional-standards) for privacy, regulatory compliance, and secure interactions with regulated assets. These components enable Dusk to support not only the tokenization of real-world assets (RWAs) but also [native issuance](/learn/tokenization-comparison#native-issuance).
+Dusk is a modular blockchain architecture built for regulated finance: privacy where it’s needed, transparency where it’s required.
 
-What sets Dusk apart from other blockchains is its tailor-made architecture, driven by continuous cryptographic research to ensure compliance, privacy, and robust network security, providing a reliable foundation to be a **Decentralized Market Infrastructure** (DeMI).
+At a high level:
+
+| Component | Role | Where to go next |
+|---|---|---|
+| **DuskDS** | Settlement, consensus, and data availability | [Transaction Models](/learn/deep-dive/duskds-tx-models), [Run a node](/operator/overview) |
+| **Rusk** | The Rust node implementation that runs DuskDS and exposes APIs | [HTTP API](/developer/integrations/http-api/), <a href="https://github.com/dusk-network/rusk/" target="_blank" rel="noreferrer">GitHub</a> |
+| **DuskVM** | WASM execution environment for native smart contracts | [DuskVM deep dive](/learn/deep-dive/dusk-vm/), [Smart Contracts on DuskDS](/developer/smart-contracts-duskds/) |
+| **DuskEVM** | OP Stack-based EVM execution environment | [DuskEVM deep dive](/learn/deep-dive/dusk-evm/), [Deploy on DuskEVM](/developer/smart-contracts-dusk-evm/deploy-on-evm/) |
+| **Citadel** | Identity and access primitives (selective disclosure) | [Digital Identity protocol](/developer/digital-identity/protocol/) |
 
 ## DuskDS
 
-DuskDS is the settlement, consensus, and data availability layer at the foundation of the Dusk architecture. It provides finality, security, and native bridging for all execution environments built on top, including DuskEVM and DuskVM. By modularizing the protocol stack, DuskDS is built to meet institutional demands for compliance, privacy, and performance.
+DuskDS is the settlement, consensus, and data availability layer at the foundation of the Dusk architecture. It provides finality, security, and native bridging for execution environments built on top (including DuskEVM and DuskVM).
 
-DuskDS includes Rusk (the node implementation) which is powered by Succinct Attestation (PoS-based consensus), Kadcast (P2P networking layer), and the Transfer and Stake Genesis contracts. Together, these elements form a secure, compliant, and composable environment for regulated financial applications
+DuskDS includes Rusk (the node implementation), Succinct Attestation (PoS consensus), Kadcast (P2P networking), and the genesis contracts (stake + transfer).
 
-Through its dual transaction models (Phoenix and Moonlight), it provides a secure settlement and data availability layer for compliant execution environments (such as DuskEVM and DuskVM). For seamless, trustless transfers between execution layers,  DuskDS exposes a native bridge.
+DuskDS supports two transaction models: **Moonlight** (public) and **Phoenix** (shielded). See: [Transaction Models on Dusk](/learn/deep-dive/duskds-tx-models/).
 
 ### Rusk
 
-<a href="https://github.com/dusk-network/rusk/" target="_blank">Rusk</a> can be thought of as the technological heart of the Dusk protocol, similar to the motherboard of a computer. It is the reference implementation of the Dusk protocol in Rust. Rusk serves multiple critical functions. It includes foundational elements like the genesis contracts, such as the transfer and stake contract. It integrates key components such as Plonk, Kadcast and Dusk VM, and supplies host functions to smart contract developers through Dusk Core. Beyond that, Rusk houses the consensus mechanism and node software, maintaining the chain state, database and network. It also provides crucial external APIs through the Rusk Universal Event System (RUES).
-
-<a href="https://github.com/dusk-network/rusk/" target="_blank">Deep dive into Rusk implementation</a>
+<a href="https://github.com/dusk-network/rusk/" target="_blank" rel="noreferrer">Rusk</a> is the Rust implementation of DuskDS. It runs consensus, maintains chain state, and exposes external APIs (including the HTTP API and RUES event system used by wallets, indexers, and integrators).
 
 ### Succinct Attestation
 
 Succinct Attestation (SA) is DuskDS’s permissionless, committee-based proof-of-stake consensus protocol. It uses randomly selected provisioners to propose, validate, and ratify blocks, providing fast, deterministic finality suitable for financial markets.
 
 At a high level, each round goes through three steps:
 
-1. **Proposal** – a provisioner creates and broadcasts a candidate block.
-2. **Validation** – a committee checks the block’s validity.
-3. **Ratification** – another committee confirms the validation outcome and finalizes the block.
+- **Proposal** – a provisioner creates and broadcasts a candidate block.
+- **Validation** – a committee checks the block’s validity.
+- **Ratification** – another committee confirms the validation outcome and finalizes the block.
 
 For the full protocol specification and security analysis (including committee selection, finality, and slashing), see Section 3 “Consensus mechanism” of the [Dusk Whitepaper (2024)](https://dusk-cms.ams3.digitaloceanspaces.com/Dusk_Whitepaper_2024_4db72f92a1.pdf).
 
 ### Transactions in DuskDS
 
-Transactions in DuskDS are managed by the Transfer Contract. The Transfer Contract oversees the handling of both transparent and obfuscated transactions within the network.
-
-The Transfer Contract supports both a UTXO and account-based model through [Phoenix](/learn/deep-dive/duskds-tx-models) and [Moonlight](/learn/deep-dive/duskds-tx-models) to handle transfers of the native currency, gas payments, and serve as a contract execution entry point.
+Transactions in DuskDS are managed by the **Transfer** contract, which supports both public and shielded transfers.
 
-Moonlight provides public transactions, while Phoenix enables shielded transactions. The flexibility of this dual-model allows users to take the best from both privacy and compliance features.
+Moonlight is account-based and public. Phoenix is UTXO-based and shielded. Both are used to transfer `DUSK`, pay gas, and act as the entry point for contract execution.
 
 ## Execution environments
 
-Dusk is designed to support multiple specialized execution environments, each optimized for distinct use cases (including FHE for confidential transactions to full EVM equivalency). These environments sit atop DuskDS and inherit its secure, compliant settlement guarantees. By separating execution from settlement, Dusk enables high-performance computation without compromising on regulatory alignment or composability.
+Dusk supports multiple execution environments on top of DuskDS. Each environment can focus on a specific developer experience (WASM vs EVM) while inheriting settlement and data availability from DuskDS.
 
 ### Dusk VM
-[Dusk VM](/learn/deep-dive/dusk-vm) is a highly optimized <a href="https://en.wikipedia.org/wiki/Virtual_machine#Process_virtual_machines" target="_blank">virtual machine</a> built around Wasmtime, a WASM runtime. It is a ZK-friendly virtual machine, enabling the development and execution of privacy-focused smart contracts and applications. 
-
-Dusk VM is fundamentally different from many blockchain VMs in that it not only executes WASM and is able to natively support ZK operations like SNARK verifications, but it also has a completely different way in which it handles memory.
-
-[Deep dive into Dusk VM](/learn/deep-dive/dusk-vm)
+[Dusk VM](/learn/deep-dive/dusk-vm) is a WASM execution environment built around Wasmtime. It’s optimized for Dusk-native smart contracts and privacy-focused applications.
 
 ### Dusk EVM
-[Dusk EVM](/learn/deep-dive/dusk-evm) is a fully EVM-equivalent execution environment. Built on the <a href="https://docs.optimism.io/stack/getting-started" target="_blank">OP Stack</a> with support for <a href="https://www.eip4844.com/" target="_blank">EIP-4844</a> (Proto-Danksharding), it enables developers to deploy smart contracts using standard EVM tooling while benefiting from DuskDS's regulatory compliant infrastructure.
-
-[Deep dive into Dusk EVM](/learn/deep-dive/dusk-evm)
+[Dusk EVM](/learn/deep-dive/dusk-evm) is an OP Stack-based EVM-equivalent execution environment. It lets you deploy Solidity contracts using standard EVM tooling while using DuskDS for settlement and data availability.
 
 ## Network Layer: Kadcast
 
-<a href="https://github.com/dusk-network/kadcast/blob/main/README.md" target="_blank">Kadcast</a> is an innovative peer-to-peer protocol used by Dusk to optimize message exchanges between nodes. Unlike the traditional Gossip protocols used by many blockchain protocols, which broadcasts messages to a random set of nodes, Kadcast uses a structured overlay to direct message flow. This drastically reduces network bandwidth and makes latency much more predictable, and at the same time lower compared to Gossip protocols.
-
-Kadcast is highly resilient to network changes and failures. It dynamically updates routing tables to handle node churn, making it suitable for decentralized environments where network conditions can be unpredictable. Even when nodes fail to forward messages, Kadcast’s built-in fault tolerance ensures alternative paths are used, maintaining reliable message delivery.
-
-<a href="https://github.com/dusk-network/kadcast/blob/main/README.md" target="_blank">Deep dive into Kadcast implementation</a> 
+<a href="https://github.com/dusk-network/kadcast/blob/main/README.md" target="_blank" rel="noreferrer">Kadcast</a> is Dusk’s P2P networking layer. It uses a structured overlay (instead of random gossip) to reduce bandwidth and improve latency predictability.
 
 ## Genesis Contracts
 
-Dusk contains two fundamental Genesis contracts, which are contracts that are available when the network starts, known as the **stake** and **transfer** contracts. 
+Dusk ships with two genesis contracts:
 
-The <a href="https://raw.githubusercontent.com/dusk-network/rusk/rusk-1.0.0/contracts/stake/src/state.rs" target="_blank">Stake Contract</a> manages the stakes of node [provisioners](/operator/provisioner) (stakers). It tracks active provisioners, records their rewards, and provides functions to stake, unstake, and withdraw rewards.
+- **Stake**: tracks provisioners, stakes, rewards, and validator set management. (<a href="https://github.com/dusk-network/contracts/tree/main/genesis/stake" target="_blank" rel="noreferrer">source</a>)
+- **Transfer**: transfers `DUSK` and is the entry point for transaction execution and gas payment. (<a href="https://github.com/dusk-network/contracts/tree/main/genesis/transfer" target="_blank" rel="noreferrer">source</a>)
 
-The Transfer Contract is responsible for the transferring of `DUSK`, regardless of the transaction model used.
+For node operators: [Run a provisioner node](/operator/provisioner/).
 
 ## Applications
 
-Applications powered by Dusk provide decentralized market infrastructure (DeMI) for regulated finance. While Zedger and Hedger facilitate secure asset lifecycle management, Citadel enables self-sovereign identity (SSI) with selective disclosure. These applications are designed to meet regulatory standards without compromising on decentralization, privacy, or usability.
-
+On top of the base protocol, Dusk supports application-layer protocols for regulated markets.
 
 ### Zedger / Hedger
 
-Zedger is an asset protocol that incorporates a unique hybrid transaction model combining the benefits of both UTXO and account-based transaction models. This model provides the Confidential Security Contract (XSC) functionality necessary for Dusk’s securities-related use-cases among them the full lifecycle management of securities and supporting full regulatory compliance.
-
-Zedger allows for the digital representation, native issuance and management of securities in a privacy-preserving manner. Issuers of securities are able to issue, manage, and let investors trade securities as XSC tokens It offers built-in support for compliant settlement, redemption of securities, preventing pre-approved users from having more than one account, supports dividend distribution and voting, and can handle capped transfers. Zedger aims to support a range of security types, like stocks, bonds and ETFs. The emphasis on regulatory compliance and privacy ensures that all operations meet the highest standards required by financial authorities and stakeholders.
+Zedger and Hedger are protocols for issuing and managing regulated assets with built-in compliance and privacy constraints.
 
-Differently from Zedger, which operated directly on Rusk, Hedger runs on DuskEVM leveraging the EVM equivalency of Dusk’s new execution layer. ZK operations in Hedger are handled via precompiled contracts provided by DuskEVM, mirroring the functionality once exposed through host functions in Rusk. This shift enables significantly easier developer access to privacy-preserving logic, while preserving the regulatory guarantees and auditability required for compliant finance.
+- **Zedger** runs natively on DuskDS.
+- **Hedger** runs on DuskEVM to offer an EVM-first developer experience.
 
 ### Citadel
 
 ![Citadel](../../../assets/citadel.gif)
 
-Citadel is a Self-Sovereign Identity (SSI)/Digital Identity (DI) protocol designed for authenticating with third party services while upholding user privacy. With Citadel it’s possible to anonymously prove identity information, like meeting a certain age threshold or living in a certain jurisdiction, without revealing the exact information or revealing more information than is necessary. Given that Citadel is part of the network, it has wide ranging applications for on-chain activity and realizing compliance in regulated financial markets.
+Citadel is Dusk’s identity and access layer. It supports selective disclosure so users can prove attributes (e.g. residency, age bracket, accreditation) without revealing more than necessary.
 
 [Deep dive into Citadel](/developer/digital-identity/protocol)