dero-mcp-server 0.2.2 → 0.4.1

package/data/docs-index.json

@@ -1,14 +1,14 @@
 {
   "version": 1,
-  "generated_at": "2026-05-24T01:55:47.792Z",
-  "page_count": 145,
+  "generated_at": "2026-05-31T20:35:13.976Z",
+  "page_count": 146,
   "pages": [
     {
       "product": "derod",
       "slug": "",
       "title": "DERO: Quick Reference Guide",
       "description": "Community DERO documentation. Build private smart contracts, deploy TELA dApps, and explore homomorphic encryption technology with complete privacy.",
-      "canonicalUrl": "https://derod.org/",
+      "canonicalUrl": "https://derod.org/.md",
       "sourcePath": "derod-main/pages/index.mdx",
       "headings": [
         "DERO - Quick Reference Guide",
@@ -26,7 +26,7 @@
       "slug": "basics/about",
       "title": "Understanding DERO: A Privacy-Focused Decentralized Application Platform | DERO Blockchain",
       "description": "Explore DERO, a revolutionary privacy-focused blockchain platform with homomorphic encryption, private smart contracts, and robust security features.",
-      "canonicalUrl": "https://derod.org/basics/about",
+      "canonicalUrl": "https://derod.org/basics/about.md",
       "sourcePath": "derod-main/pages/basics/about.mdx",
       "headings": [
         "What is DERO?",
@@ -48,7 +48,7 @@
       "slug": "basics/daemon",
       "title": "DERO Daemon: Backbone of the Privacy Blockchain | DERO Blockchain",
       "description": "Run a DERO node to support the network, earn integrator rewards, and maintain decentralization with full privacy features.",
-      "canonicalUrl": "https://derod.org/basics/daemon",
+      "canonicalUrl": "https://derod.org/basics/daemon.md",
       "sourcePath": "derod-main/pages/basics/daemon.mdx",
       "headings": [
         "DERO Daemon (Node)",
@@ -82,7 +82,7 @@
       "slug": "basics/mining",
       "title": "DERO Mining: Σ-blocks & Fair Rewards | DERO Blockchain",
       "description": "Mine DERO with the revolutionary Σ-blocks system. Solo mining made practical with daily rewards for everyone, from 100 KH/s hobbyists to data centers.",
-      "canonicalUrl": "https://derod.org/basics/mining",
+      "canonicalUrl": "https://derod.org/basics/mining.md",
       "sourcePath": "derod-main/pages/basics/mining.mdx",
       "headings": [
         "DERO Mining",
@@ -115,7 +115,7 @@
       "slug": "basics/running-a-node",
       "title": "Running a DERO Node: Complete Setup Guide | DERO Blockchain",
       "description": "Step-by-step guide to setting up and running your own DERO node on Linux, Windows, or Mac. Earn integrator rewards and support network decentralization.",
-      "canonicalUrl": "https://derod.org/basics/running-a-node",
+      "canonicalUrl": "https://derod.org/basics/running-a-node.md",
       "sourcePath": "derod-main/pages/basics/running-a-node.mdx",
       "headings": [
         "Running Your Own DERO Node",
@@ -155,12 +155,13 @@
         "RPC (optional, for local access only)",
         "Initial Sync",
         "Sync Methods",
-        "Downloads and validates entire blockchain",
-        "Time: 2-6 hours (depends on connection/CPU)",
-        "Result: Fully validated node",
-        "Downloads state snapshots",
+        "Downloads and validates the entire blockchain from genesis",
+        "Time: several hours (depends on connection/CPU)",
+        "Disk: full archival (~230 GB+, see System Requirements)",
+        "Result: fully validated node that can answer queries about any past block/tx",
+        "Downloads recent state snapshots instead of replaying from genesis",
         "Time: 30-60 minutes",
-        "Result: Functional node, still secure",
+        "Result: functional, secure node. Pair with --prune-history to keep disk small.",
         "Monitoring Sync Progress",
         "Check height increasing",
         "Synced when local height = network height",
@@ -195,15 +196,15 @@
         "Further Reading",
         "Related Pages"
       ],
-      "plainText": "Running Your Own DERO Node Run a DERO Node Running a DERO node supports network decentralization, earns you integrator rewards (10% bonus), and gives you complete privacy without relying on third-party infrastructure. **Download:** GitHub Releases --- Quick Start Linux Windows macOS --- System Requirements | Component | Minimum | Recommended | |-----------|---------|-------------| | **CPU** | 2 cores | 4+ cores | | **RAM** | 4GB | 8GB+ | | **Storage** | 20GB SSD | 50GB+ SSD | | **Network** | Stable connection | 100+ Mbps | | **OS** | Linux/Windows/Mac | Linux (best performance) | **Why SSD?** - Blockchain requires fast random reads/writes - HDD will cause sync issues and slow performance --- Configuration Basic Setup Advanced Configuration **Key flags:** - --integrator-address - Your address for 10% rewards - --rpc-bind - RPC server address (default: 127.0.0.1:10102) - --p2p-bind - P2P network address (default: 0.0.0.0:10101) - --node-tag - Custom node identifier - --fastsync - Faster initial sync **Full list:** ./derod --help --- Running as a Service Linux (systemd) First, create a dedicated user and directory for the daemon: Create service file /etc/systemd/system/derod.service: **Enable and start:** **View logs:** --- Monitoring Your Node Check Sync Status Via RPC Check Connected Peers --- Firewall Configuration Required Ports **Mainnet:** **Testnet:** **Security:** Do NOT expose RPC port (10102) to the internet unless you know what you're doing. It should only be accessible locally or via trusted network. --- Initial Sync Sync Methods **1. Full Sync (Recommended)** **2. Fast Sync** Monitoring Sync Progress --- Maintenance Updating Your Node Pruning (Reducing Disk Usage) **Source:** Pruning implementation in blockchain/prune_history.go --- Earning Integrator Rewards The 10% Bonus Explained **Every 10 miniblocks:** **Requirements:** - Run your own daemon - Set --integrator-address to your wallet - Have miners connected (or mine yourself) **Rewards:** - Base miner rewards: 88.4% - Integrator bonus: 10% - Pool fee (you keep): 1.6% - **Total: 100%** (vs 98.4% on public pools) **Source:** blockchain/miniblocks.go --- Troubleshooting Common Issues **Sync stuck:** **High CPU usage:** **High memory:** **Port already in use:** --- Performance Optimization For VPS/Server For Home PC --- Security Best Practices **1. Firewall Rules** - ✅ Allow P2P port (10101) - ❌ Block RPC port from internet (10102) - ✅ Use SSH keys (if remote server) **2. System Security** - ✅ Keep OS updated - ✅ Run daemon as non-root user - ✅ Use strong passwords - ✅ Enable automatic security updates **3. Backup** - ✅ Backup wallet seed phrase (25 words) - ✅ Document integrator address - ✅ Note configuration settings **Never expose RPC port to the internet!** It can be used to query blockchain data and potentially DOS your node. Use SSH tunneling or VPN if remote access needed. --- Benefits of Running a Node | Benefit | Description | |---------|-------------| | **Privacy** | No third party sees your transactions/queries | | **Integrator Rewards** | Earn 10% of blocks mined on your node | | **Network Health** | Contribute to decentralization | | **Self-Sovereignty** | Complete control, zero trust | | **Support Mining** | Help friends/family mine | | **Learning** | Understand blockchain deeply | --- Further Reading - DERO Daemon - Understanding the daemon - Mining Guide - Start mining on your node - RPC API - API documentation **Source Code:** - Daemon implementation: cmd/derod/main.go - Configuration: config/config.go - Pruning: blockchain/prune_history.go --- Related Pages **Node Operations:** - DERO Daemon - Understanding the daemon - DERO Mining - Mine with your node - Encrypted Network - P2P network details **APIs & Integration:** - Daemon RPC API - Full RPC reference - Wallet RPC API - Wallet automation **Advanced:** - Smart Contracts - Run smart contracts on your node - DERO Tokens - Understanding asset storage",
-      "lastUpdated": "2025-10-19"
+      "plainText": "Running Your Own DERO Node Run a DERO Node Running a DERO node supports network decentralization, earns you integrator rewards (10% bonus), and gives you complete privacy without relying on third-party infrastructure. **Download:** GitHub Releases --- Quick Start Linux Windows macOS --- System Requirements | Component | Minimum | Recommended | |-----------|---------|-------------| | **CPU** | 2 cores | 4+ cores | | **RAM** | 4GB | 8GB+ | | **Storage** | see note below | see note below | | **Network** | Stable connection | 100+ Mbps | | **OS** | Linux/Windows/Mac | Linux (best performance) | **Storage depends on your sync mode** — this is the number that catches people out: | Sync mode | Disk | Use when | |-----------|------|----------| | **Full / archival** (default derod, no pruning) | **~230 GB+ today; plan for 500 GB** (grows continuously) | you need complete chain history and to answer queries about any past block or transaction | | **Fast sync + pruning** (--fastsync --prune-history=100000) | **~50 GB** | typical node or VPS — current state, recent history, validating new blocks | The full chain has grown from ~130 GB (early 2025) to 160+ GB (late 2025) and past 230 GB by mid-2026, and it keeps climbing — size a full node for the future, not for today. A pruned, fast-synced node stays light and is the recommended setup for a VPS or any node that does not need deep history. **Why SSD?** - Blockchain requires fast random reads/writes - HDD will cause sync issues and slow performance --- Configuration Basic Setup Advanced Configuration **Key flags:** - --integrator-address - Your address for 10% rewards - --rpc-bind - RPC server address (default: 127.0.0.1:10102) - --p2p-bind - P2P network address (default: 0.0.0.0:10101) - --node-tag - Custom node identifier - --fastsync - Faster initial sync **Full list:** ./derod --help --- Running as a Service Linux (systemd) First, create a dedicated user and directory for the daemon: Create service file /etc/systemd/system/derod.service: **Enable and start:** **View logs:** --- Monitoring Your Node Check Sync Status Via RPC Check Connected Peers --- Firewall Configuration Required Ports **Mainnet:** **Testnet:** **Security:** Do NOT expose RPC port (10102) to the internet unless you know what you're doing. It should only be accessible locally or via trusted network. --- Initial Sync Sync Methods **1. Full Sync — complete history** **2. Fast Sync — recommended for most nodes** Most operators want **fast sync + pruning** (see \"For VPS/Server\" under Performance Optimization). Choose full sync only if you specifically need the complete historical chain. Monitoring Sync Progress --- Maintenance Updating Your Node Pruning (Reducing Disk Usage) **Source:** Pruning implementation in blockchain/prune_history.go --- Earning Integrator Rewards The 10% Bonus Explained **Every 10 miniblocks:** **Requirements:** - Run your own daemon - Set --integrator-address to your wallet - Have miners connected (or mine yourself) **Rewards:** - Base miner rewards: 88.4% - Integrator bonus: 10% - Pool fee (you keep): 1.6% - **Total: 100%** (vs 98.4% on public pools) **Source:** blockchain/miniblocks.go --- Troubleshooting Common Issues **Sync stuck:** **High CPU usage:** **High memory:** **Port already in use:** --- Performance Optimization For VPS/Server For Home PC --- Security Best Practices **1. Firewall Rules** - ✅ Allow P2P port (10101) - ❌ Block RPC port from internet (10102) - ✅ Use SSH keys (if remote server) **2. System Security** - ✅ Keep OS updated - ✅ Run daemon as non-root user - ✅ Use strong passwords - ✅ Enable automatic security updates **3. Backup** - ✅ Backup wallet seed phrase (25 words) - ✅ Document integrator address - ✅ Note configuration settings **Never expose RPC port to the internet!** It can be used to query blockchain data and potentially DOS your node. Use SSH tunneling or VPN if remote access needed. --- Benefits of Running a Node | Benefit | Description | |---------|-------------| | **Privacy** | No third party sees your transactions/queries | | **Integrator Rewards** | Earn 10% of blocks mined on your node | | **Network Health** | Contribute to decentralization | | **Self-Sovereignty** | Complete control, zero trust | | **Support Mining** | Help friends/family mine | | **Learning** | Understand blockchain deeply | --- Further Reading - DERO Daemon - Understanding the daemon - Mining Guide - Start mining on your node - RPC API - API documentation **Source Code:** - Daemon implementation: cmd/derod/main.go - Configuration: config/config.go - Pruning: blockchain/prune_history.go --- Related Pages **Node Operations:** - DERO Daemon - Understanding the daemon - DERO Mining - Mine with your node - Encrypted Network - P2P network details **APIs & Integration:** - Daemon RPC API - Full RPC reference - Wallet RPC API - Wallet automation **Advanced:** - Smart Contracts - Run smart contracts on your node - DERO Tokens - Understanding asset storage",
+      "lastUpdated": "2026-05-29"
     },
     {
       "product": "derod",
       "slug": "basics/tokens",
       "title": "DERO Tokens: Private Smart Contract Assets | DERO Blockchain",
       "description": "Learn about DERO's innovative approach to token storage and security, offering rugpull-resistant tokens with enhanced privacy features.",
-      "canonicalUrl": "https://derod.org/basics/tokens",
+      "canonicalUrl": "https://derod.org/basics/tokens.md",
       "sourcePath": "derod-main/pages/basics/tokens.mdx",
       "headings": [
         "DERO Tokens",
@@ -233,7 +234,7 @@
       "slug": "basics/wallets",
       "title": "DERO Cryptocurrency Wallets: A Comprehensive Guide | DERO Blockchain",
       "description": "Explore DERO wallet options, including CLI, Engram, Web, and Cold wallets for secure cryptocurrency management with enhanced privacy.",
-      "canonicalUrl": "https://derod.org/basics/wallets",
+      "canonicalUrl": "https://derod.org/basics/wallets.md",
       "sourcePath": "derod-main/pages/basics/wallets.mdx",
       "headings": [
         "What is a wallet?",
@@ -253,7 +254,7 @@
       "slug": "dvm/create-deploy-use-smart-contract",
       "title": "Create, Deploy & Use a Smart Contract on DERO | Step-by-Step Tutorial",
       "description": "End-to-end tutorial: write a DVM-BASIC smart contract, deploy it to the DERO blockchain, interact with its functions, and query its state — all from the command line.",
-      "canonicalUrl": "https://derod.org/dvm/create-deploy-use-smart-contract",
+      "canonicalUrl": "https://derod.org/dvm/create-deploy-use-smart-contract.md",
       "sourcePath": "derod-main/pages/dvm/create-deploy-use-smart-contract.mdx",
       "headings": [
         "Create, Deploy & Use a Smart Contract",
@@ -292,7 +293,7 @@
       "slug": "dvm/dero-virtual-machine",
       "title": "DERO Virtual Machine (DVM): Private Smart Contract Platform | DERO Blockchain",
       "description": "Explore the DERO Virtual Machine (DVM), a revolutionary platform for running both public and private smart contracts with enhanced security and privacy on the DERO blockchain.",
-      "canonicalUrl": "https://derod.org/dvm/dero-virtual-machine",
+      "canonicalUrl": "https://derod.org/dvm/dero-virtual-machine.md",
       "sourcePath": "derod-main/pages/dvm/dero-virtual-machine.mdx",
       "headings": [
         "DERO Virtual Machine (DVM)",
@@ -314,7 +315,7 @@
       "slug": "dvm/dvm-basic",
       "title": "DVM-BASIC: DERO's Smart Contract Language Guide | DERO Blockchain",
       "description": "Comprehensive guide to DVM-BASIC, DERO's smart contract programming language with syntax, examples, and best practices for blockchain developers.",
-      "canonicalUrl": "https://derod.org/dvm/dvm-basic",
+      "canonicalUrl": "https://derod.org/dvm/dvm-basic.md",
       "sourcePath": "derod-main/pages/dvm/dvm-basic.mdx",
       "headings": [
         "DVM-BASIC Programming Guide",
@@ -344,7 +345,7 @@
       "slug": "dvm/smart-contract-fundamentals",
       "title": "Smart Contract Fundamentals: Understanding DERO Contracts | DERO Blockchain",
       "description": "Learn what DERO smart contracts actually are, how they execute on-chain, why DVM-BASIC was chosen over Solidity, and the core patterns that make contracts secure and auditable.",
-      "canonicalUrl": "https://derod.org/dvm/smart-contract-fundamentals",
+      "canonicalUrl": "https://derod.org/dvm/smart-contract-fundamentals.md",
       "sourcePath": "derod-main/pages/dvm/smart-contract-fundamentals.mdx",
       "headings": [
         "Smart Contract Fundamentals",
@@ -380,7 +381,7 @@
       "slug": "engram",
       "title": "Engram: Decentralized Application Platform for DERO | DERO Blockchain",
       "description": "Explore Engram, a desktop application for accessing and interacting with decentralized applications on the DERO blockchain with enhanced privacy and security features.",
-      "canonicalUrl": "https://derod.org/engram",
+      "canonicalUrl": "https://derod.org/engram.md",
       "sourcePath": "derod-main/pages/engram/index.mdx",
       "headings": [
         "What is Engram?",
@@ -397,7 +398,7 @@
       "slug": "engram/features",
       "title": "Engram Features: Key Capabilities of the DERO dApp Platform | DERO Blockchain",
       "description": "Explore the key features of Engram, a desktop application for accessing decentralized applications on the DERO blockchain with enhanced privacy and security.",
-      "canonicalUrl": "https://derod.org/engram/features",
+      "canonicalUrl": "https://derod.org/engram/features.md",
       "sourcePath": "derod-main/pages/engram/features.mdx",
       "headings": [
         "Engram Features",
@@ -421,7 +422,7 @@
       "slug": "engram/hosting-dapps",
       "title": "Hosting dApps with Engram: Guide to DERO Decentralized Applications | DERO Blockchain",
       "description": "Learn how to discover, browse, and interact with decentralized applications on the DERO blockchain using the Engram platform.",
-      "canonicalUrl": "https://derod.org/engram/hosting-dapps",
+      "canonicalUrl": "https://derod.org/engram/hosting-dapps.md",
       "sourcePath": "derod-main/pages/engram/hosting-dapps.mdx",
       "headings": [
         "Hosting and Discovering dApps with Engram",
@@ -451,7 +452,7 @@
       "slug": "engram/user-guide",
       "title": "Engram User Guide: How to Use the DERO dApp Platform | DERO Blockchain",
       "description": "Learn how to use Engram, the desktop application for accessing and interacting with decentralized applications on the DERO blockchain.",
-      "canonicalUrl": "https://derod.org/engram/user-guide",
+      "canonicalUrl": "https://derod.org/engram/user-guide.md",
       "sourcePath": "derod-main/pages/engram/user-guide.mdx",
       "headings": [
         "Engram User Guide",
@@ -490,7 +491,7 @@
       "slug": "engram/wallet-integration",
       "title": "Engram Wallet Integration: Connecting Your DERO Wallet | DERO Blockchain",
       "description": "Learn how to connect your DERO wallet to Engram for seamless interaction with decentralized applications on the DERO blockchain.",
-      "canonicalUrl": "https://derod.org/engram/wallet-integration",
+      "canonicalUrl": "https://derod.org/engram/wallet-integration.md",
       "sourcePath": "derod-main/pages/engram/wallet-integration.mdx",
       "headings": [
         "Wallet Integration with Engram",
@@ -525,7 +526,7 @@
       "slug": "features/astroBWT",
       "title": "AstroBWT: DERO's CPU-Friendly Mining Algorithm | DERO Blockchain",
       "description": "Discover DERO's innovative AstroBWT mining algorithm that ensures fair mining by preventing specialized hardware advantages through Burrows-Wheeler Transform technology.",
-      "canonicalUrl": "https://derod.org/features/astroBWT",
+      "canonicalUrl": "https://derod.org/features/astroBWT.md",
       "sourcePath": "derod-main/pages/features/astroBWT.mdx",
       "headings": [
         "AstroBWT",
@@ -539,7 +540,7 @@
       "slug": "features/bulletproofs",
       "title": "Bulletproofs: DERO's Advanced Zero-Knowledge Proofs | DERO Blockchain",
       "description": "Explore DERO Rocket Bulletproofs, a groundbreaking implementation that enables transaction privacy with verification 10X faster than other cryptocurrencies, without revealing underlying data.",
-      "canonicalUrl": "https://derod.org/features/bulletproofs",
+      "canonicalUrl": "https://derod.org/features/bulletproofs.md",
       "sourcePath": "derod-main/pages/features/bulletproofs.mdx",
       "headings": [
         "What are Bulletproofs?",
@@ -553,7 +554,7 @@
       "slug": "features/dvm",
       "title": "DERO Virtual Machine: Smart Contract Execution Platform | DERO Blockchain",
       "description": "Explore the DERO Virtual Machine (DVM), a powerful execution environment for private and public smart contracts written in DVM Basic language on the DERO blockchain.",
-      "canonicalUrl": "https://derod.org/features/dvm",
+      "canonicalUrl": "https://derod.org/features/dvm.md",
       "sourcePath": "derod-main/pages/features/dvm.mdx",
       "headings": [
         "Dero Virtual Machine (DVM)",
@@ -572,7 +573,7 @@
       "slug": "features/encrypted-network",
       "title": "TLS-Encrypted P2P Network | DERO Blockchain",
       "description": "DERO's TLS-over-UDP network architecture provides encrypted communication, preventing eavesdropping and tampering while maintaining performance.",
-      "canonicalUrl": "https://derod.org/features/encrypted-network",
+      "canonicalUrl": "https://derod.org/features/encrypted-network.md",
       "sourcePath": "derod-main/pages/features/encrypted-network.mdx",
       "headings": [
         "TLS-Encrypted P2P Network",
@@ -616,7 +617,7 @@
       "slug": "features/erasure-coding",
       "title": "Erasure Coded Blocks: Resilient Block Propagation | DERO Blockchain",
       "description": "DERO uses Reed-Solomon erasure coding to split blocks into 48 chunks and disperse them across the P2P network, enabling reconstruction from any 16 pieces for fast, resilient propagation.",
-      "canonicalUrl": "https://derod.org/features/erasure-coding",
+      "canonicalUrl": "https://derod.org/features/erasure-coding.md",
       "sourcePath": "derod-main/pages/features/erasure-coding.mdx",
       "headings": [
         "Erasure Coded Blocks",
@@ -651,7 +652,7 @@
       "slug": "features/golang",
       "title": "Why DERO is Built in Go | DERO Blockchain",
       "description": "How Go's concurrency, performance, and security features enable DERO's unique blockchain capabilities - from encrypted balances to high-throughput P2P networking.",
-      "canonicalUrl": "https://derod.org/features/golang",
+      "canonicalUrl": "https://derod.org/features/golang.md",
       "sourcePath": "derod-main/pages/features/golang.mdx",
       "headings": [
         "Why Go for DERO?",
@@ -689,7 +690,7 @@
       "slug": "features/graviton",
       "title": "Graviton: DERO's Immutable Key-Value Database | DERO Blockchain",
       "description": "Explore Graviton, DERO's specialized key-value store database that securely manages encrypted account balances with cryptographic proofs and censorship-resistant design.",
-      "canonicalUrl": "https://derod.org/features/graviton",
+      "canonicalUrl": "https://derod.org/features/graviton.md",
       "sourcePath": "derod-main/pages/features/graviton.mdx",
       "headings": [
         "Graviton",
@@ -704,7 +705,7 @@
       "slug": "features/smart-contracts",
       "title": "Private Smart Contracts: DERO's Confidential Execution | DERO Blockchain",
       "description": "Discover DERO's groundbreaking private smart contracts that enable secure, confidential transactions with encrypted computation and enhanced privacy protection.",
-      "canonicalUrl": "https://derod.org/features/smart-contracts",
+      "canonicalUrl": "https://derod.org/features/smart-contracts.md",
       "sourcePath": "derod-main/pages/features/smart-contracts.mdx",
       "headings": [
         "Private Smart Contracts"
@@ -717,7 +718,7 @@
       "slug": "features/usernames",
       "title": "DERO Usernames: Simplified Blockchain Transactions | DERO Blockchain",
       "description": "Experience DERO's built-in username feature that replaces complex wallet addresses with personalized names, making cryptocurrency transfers simpler, safer, and more user-friendly.",
-      "canonicalUrl": "https://derod.org/features/usernames",
+      "canonicalUrl": "https://derod.org/features/usernames.md",
       "sourcePath": "derod-main/pages/features/usernames.mdx",
       "headings": [
         "Usernames",
@@ -731,7 +732,7 @@
       "slug": "integrity",
       "title": "DERO Protocol Integrity: Complete Technical Guide | DERO Blockchain",
       "description": "Deep dive into DERO's mathematical integrity guarantees including transaction proofs, range proofs, negative transfer protection, and network consensus validation.",
-      "canonicalUrl": "https://derod.org/integrity",
+      "canonicalUrl": "https://derod.org/integrity.md",
       "sourcePath": "derod-main/pages/integrity/index.mdx",
       "headings": [
         "DERO Protocol Integrity",
@@ -746,7 +747,7 @@
         "Verify any of the above:",
         "Mathematical Foundation"
       ],
-      "plainText": "DERO Protocol Integrity **Integrity is a mathematical guarantee, not a policy.** DERO's protocol integrity isn't achieved through secrecy or trust — it's achieved through cryptographic proofs that are independently verifiable by anyone. **The Foundation:** Every DERO transaction requires six interlocking cryptographic proofs that must all pass. Fake one, and the cryptographic binding invalidates all six. These proofs are open source and independently verifiable by anyone. --- The Six Sigma Proof System Every DERO transaction requires **six sigma proof components** bound together through a cryptographic challenge hash. Faking one proof changes the hash, which invalidates all other proofs — an all-or-nothing security model. **Source:** cryptography/crypto/proof_verify.go — Full technical breakdown → --- Anatomy of a Transaction Follow a DERO transaction from creation to finality — each row links to the full technical deep-dive. Phase 1: Building the Transaction Before a transaction leaves the wallet, the proof system is already at work. | What Happens | Learn More | |-------------|------------| | Wallet reads the sender's encrypted balance: 66 bytes, two curve points, zero plaintext | Balance Mechanics | | Wallet generates six sigma proofs, all bound through a single challenge hash | Transaction Proofs | | A_t validates a combined 128-bit value: 64 bits transfer + 64 bits remaining. Triple-layer defense | Range Proofs | | Negative amounts are caught here, before the transaction leaves the wallet | Negative Transfers | Phase 2: Network Verification Every node that receives this transaction runs the same verification independently. | What Happens | Learn More | |-------------|------------| | First checkpoint: uint64 overflow checks on fees and values. Fails fast before expensive crypto | Overflow Protection | | Five checkpoints in sequence: overflow, parity, polynomial recovery, challenge hash, inner product | Verification Flow | Phase 3: Acceptance and State Once verified, the transaction enters the mempool, gets mined into a block, and the chain state updates. | What Happens | Learn More | |-------------|------------| | Every node verifies independently and reaches the same conclusion. 18-second blocks, probabilistic finality | Network Consensus | | All ring members' encrypted balances change — including decoys. Only the owner knows who sent | Ring Members | | Transaction proofs (consensus, secure) vs. payload proofs (display, fakeable by design) | Proof Types | --- Security Guarantees All cryptographic protections below rely on the hardness of ECDLP on the bn256 curve (see Mathematical Foundation below), except where noted. | Threat | Protection | |--------|------------| | **Negative transfers** | Bit decomposition + range proofs | | **Transaction replay** | A_u key image + nonce/height + consensus rules | | **Invalid amounts** | 128-bit combined range proof | | **Forged transactions** | A_y proof (private key ownership) | | **Balance manipulation** | Homomorphic commitments | | **Arithmetic overflow** | Explicit uint64 overflow checks *(deterministic integer arithmetic, not cryptographic)* | Honest Limitations | Limitation | What's Exposed | |------------|---------------| | **Timing analysis** | Transaction submission times are visible to connected peers | | **Network observation** | IP addresses are visible to peers (TLS encrypts content, not identity) | | **Metadata correlation** | Transaction frequency and patterns are observable on-chain | --- Verify It Yourself **Don't Trust, Verify:** All claims in this documentation can be independently verified against the DERO source code. | Protection | File | Lines | |------------|------|-------| | Bit decomposition | cryptography/crypto/proof_generate.go | 468-487 | | Overflow check | cryptography/crypto/proof_verify.go | 108-110 | | Parity check | cryptography/crypto/proof_verify.go | 136-141 | | Challenge hash | cryptography/crypto/proof_verify.go | 410-425 | | Inner product | cryptography/crypto/proof_verify.go | 457-459 | | Block time | config/config.go | 34 | | Balance init | blockchain/transaction_execute.go | 189-194 | --- Mathematical Foundation DERO's cryptographic proofs rely on the hardness of the elliptic curve discrete logarithm problem (ECDLP) on a bn256 (Barreto-Naehrig) curve -- the same curve family behind Ethereum's bn256 precompiles (EIP-196/197). No efficient algorithm is known for solving ECDLP on these parameters. Source: cryptography/bn256/",
+      "plainText": "DERO Protocol Integrity **Integrity is a mathematical guarantee, not a policy.** DERO's protocol integrity isn't achieved through secrecy or trust — it's achieved through cryptographic proofs that are independently verifiable by anyone. **The Foundation:** Every DERO transaction requires six interlocking cryptographic proofs that must all pass. Fake one, and the cryptographic binding invalidates all six. These proofs are open source and independently verifiable by anyone. --- The Six Sigma Proof System Every DERO transaction requires **six sigma proof components** bound together through a cryptographic challenge hash. Faking one proof changes the hash, which invalidates all other proofs — an all-or-nothing security model. **Source:** cryptography/crypto/proof_verify.go — Full technical breakdown → --- Anatomy of a Transaction Follow a DERO transaction from creation to finality — each row links to the full technical deep-dive. Phase 1: Building the Transaction Before a transaction leaves the wallet, the proof system is already at work. | What Happens | Learn More | |-------------|------------| | Wallet reads the sender's encrypted balance: 66 bytes, two curve points, zero plaintext | Balance Mechanics | | Wallet generates six sigma proofs, all bound through a single challenge hash | Transaction Proofs | | A_t encodes a combined 128-bit value: 64 bits transfer + 64 bits remaining. Bulletproof construction starts here | Range Proofs | Phase 2: Network Verification Every node that receives this transaction runs the same verification independently. | What Happens | Learn More | |-------------|------------| | First checkpoint: uint64 overflow checks on fees and values. Fails fast before expensive crypto | Overflow Protection | | Five checkpoints in sequence: overflow, parity, polynomial recovery, challenge hash, inner product | Verification Flow | | Bulletproof soundness rejects any committed value outside the proven range — including negative/wraparound amounts | Negative Transfers | Phase 3: Acceptance and State Once verified, the transaction enters the mempool, gets mined into a block, and the chain state updates. | What Happens | Learn More | |-------------|------------| | Every node verifies independently and reaches the same conclusion. 18-second blocks, probabilistic finality | Network Consensus | | All ring members' encrypted balances change — including decoys. Only the owner knows who sent | Ring Members | | Transaction proofs (consensus, secure) vs. payload proofs (display, fakeable by design) | Proof Types | | October 2022 inflation claim: claims vs. evidence | Inflation Claim | --- Security Guarantees All cryptographic protections below rely on the hardness of ECDLP on the bn256 curve (see Mathematical Foundation below), except where noted. | Threat | Protection | |--------|------------| | **Negative transfers** | Bulletproof soundness (verifier-enforced range) | | **Transaction replay** | A_u key image + nonce/height + consensus rules | | **Invalid amounts** | 128-bit combined range proof | | **Forged transactions** | A_y proof (private key ownership) | | **Balance manipulation** | Homomorphic commitments | | **Arithmetic overflow** | Explicit uint64 overflow checks *(deterministic integer arithmetic, not cryptographic)* | Honest Limitations | Limitation | What's Exposed | |------------|---------------| | **Timing analysis** | Transaction submission times are visible to connected peers | | **Network observation** | IP addresses are visible to peers (TLS encrypts content, not identity) | | **Metadata correlation** | Transaction frequency and patterns are observable on-chain | --- Verify It Yourself **Don't Trust, Verify:** All claims in this documentation can be independently verified against the DERO source code. | Protection | File | Lines | |------------|------|-------| | Verify() entry point | cryptography/crypto/proof_verify.go | 98 | | Overflow check | cryptography/crypto/proof_verify.go | 108-111 | | Parity check | cryptography/crypto/proof_verify.go | 136-141 | | Challenge hash | cryptography/crypto/proof_verify.go | 410-425 | | Inner product | cryptography/crypto/proof_verify.go | 457-460 | | Block time | config/config.go | 34 | | Balance init | blockchain/transaction_execute.go | 189-194 | --- Mathematical Foundation DERO's cryptographic proofs rely on the hardness of the elliptic curve discrete logarithm problem (ECDLP) on a bn256 (Barreto-Naehrig) curve -- the same curve family behind Ethereum's bn256 precompiles (EIP-196/197). No efficient algorithm is known for solving ECDLP on these parameters. Source: cryptography/bn256/",
       "lastUpdated": "2026-02-06"
     },
     {
@@ -754,7 +755,7 @@
       "slug": "integrity/balance-mechanics",
       "title": "Balance Mechanics: Encrypted State Management | DERO Blockchain",
       "description": "Technical deep dive into how DERO manages encrypted balances - the 66-byte structure, homomorphic operations, zero initialization, and what balance changes mean.",
-      "canonicalUrl": "https://derod.org/integrity/balance-mechanics",
+      "canonicalUrl": "https://derod.org/integrity/balance-mechanics.md",
       "sourcePath": "derod-main/pages/integrity/balance-mechanics.mdx",
       "headings": [
         "Balance Mechanics: Encrypted State Management",
@@ -785,59 +786,86 @@
         "The Homomorphic Advantage",
         "Related Pages"
       ],
-      "plainText": "Balance Mechanics: Encrypted State Management **Always Encrypted:** DERO balances are never stored or transmitted in plaintext. All balance operations happen on encrypted data through homomorphic encryption. The Encrypted Balance Structure The 66-Byte Format Every DERO balance is stored as 66 bytes of encrypted data: **From Source Code** (cryptography/crypto/algebra_elgamal.go): > **Note:** The full struct includes G (generator) and Randomness (blinding factor) fields used during construction, but only Left and Right are serialized to the 66-byte on-chain representation. What Each Component Represents | Component | Formula | Purpose | |-----------|---------|---------| | **Left (L)** | amount×G + r×P | Encrypted amount + randomness | | **Right (R)** | r×G | Randomness commitment (for decryption) | **Where:** - amount = The actual balance (hidden) - G = Generator point (public constant) - r = Random blinding factor (secret) - P = Account's public key --- Zero Balance Initialization The Genesis Rule **From Source Code** (blockchain/transaction_execute.go:189-194): What This Means | Registration Block | Initial Balance | Reason | |-------------------|-----------------|--------| | **< 144,000** | 200 atomic units | Early adoption period | | **≥ 144,000** | 0 DERO | Standard registration | **For context:** - 144,000 blocks = 30 days of 18-second blocks (86400 / 18 × 30) - This bonus period ended long ago; the vast majority of addresses have zero initial balance **Timeline:** The 200-unit bonus only applied to addresses registered in the first ~30 days of mainnet (before block 144,000). Any address registered after that starts with exactly zero DERO. --- Homomorphic Operations Addition (Receiving DERO) **When you receive DERO:** **The Math:** Subtraction (Sending DERO) **When you send DERO:** **The Math:** **Source:** cryptography/crypto/algebra_elgamal.go:69 - ElGamal operations --- What Balance Changes Mean When Balance Changes | Scenario | Balance Changes? | Reason | |----------|-----------------|--------| | **Send DERO** | Yes | Subtracted from your balance | | **Receive DERO** | Yes | Added to your balance | | **Ring member (decoy)** | **Yes** | Participates in ring signature | | **No activity** | No | Balance unchanged | The Ring Member Case (Critical) **Important:** Encrypted balance changes occur for ALL ring members in a transaction, including decoys. This is by design, not a bug. See Ring Member Behavior for details. **From Source Code** (walletapi/daemon_communication.go:886-889): --- Balance Query Process How to Query Balance **Query Encrypted Balance (Public)** **Response:** **What you see:** 66 bytes of encrypted data **What you learn:** Nothing about actual balance **Decrypt Balance (Requires Private Key)** **Decryption process:** 1. Deserialize the 66-byte encrypted balance into an ElGamal pair (Left, Right) 2. Compute Left - privateKey × Right which yields amount × G 3. Solve the discrete log (baby-step giant-step) to recover the integer amount **What you see:** Actual balance (e.g., 500 DERO) **Who can do this:** Only the address owner (requires private key for step 2) The Encrypted Balance Identity Test **Comparing balances at different heights:** **What this tells us:** - Identical encrypted data = No balance change - Different encrypted data = Balance changed (for ANY reason) - 22,592 blocks unchanged = No involvement in any transaction (not even as ring member) --- Balance Conservation The Conservation Law **The homomorphic operations preserve this:** Network Verification **The network verifies conservation without seeing amounts.** Because ElGamal is additively homomorphic, the network can confirm that the sum of encrypted inputs equals the sum of encrypted outputs -- without decrypting any of them. If the encrypted totals don't match, the transaction is rejected. The actual balance updates happen in blockchain/transaction_execute.go using the ElGamal.Add() operation from cryptography/crypto/algebra_elgamal.go:69. --- Security Properties What's Protected | Property | How It's Achieved | |----------|------------------| | **Balance confidentiality** | ElGamal encryption | | **Balance integrity** | Commitment binding | | **Conservation** | Homomorphic verification | | **Non-negative balances** | Range proofs | What's Visible | Information | Visible To | |-------------|-----------| | **Encrypted balance (66 bytes)** | Anyone | | **That balance changed** | Anyone | | **Actual balance value** | Only owner | | **Transaction amounts** | Only sender/receiver | --- Key Takeaways The Encryption Guarantee **Always Encrypted:** From creation to storage to operations, DERO balances are always encrypted. The network processes all value transfers without ever seeing a single plaintext balance. Balance Change Interpretation | Observation | What It Means | What It Doesn't Mean | |-------------|--------------|---------------------| | **Balance unchanged** | Address not involved in ANY transaction | - | | **Balance changed** | Address participated in some transaction | ≠ Address was sender | | **66 bytes different** | Some balance operation occurred | ≠ Received or sent specific amount | The Homomorphic Advantage --- Related Pages **Security Suite:** - Ring Member Behavior - Why decoys' balances change - Negative Transfer Protection - Range proof security **Privacy Suite:** - Homomorphic Encryption - Full technical details - Transaction Privacy - Complete privacy model **Technical Reference:** - Wallet RPC API - Balance queries - Daemon RPC API - GetEncryptedBalance method",
+      "plainText": "Balance Mechanics: Encrypted State Management **Always Encrypted:** DERO balances are never stored or transmitted in plaintext. All balance operations happen on encrypted data through homomorphic encryption. The Encrypted Balance Structure The 66-Byte Format Every DERO balance is stored as 66 bytes of encrypted data: **Conceptual structure** (the source struct in cryptography/crypto/algebra_elgamal.go:34-39 has no inline comments — annotations below are docs notes; Serialize() is at algebra_elgamal.go:84-91): > **Note:** The full struct includes G (the Pedersen value generator, set from global_pedersen_values.G) and Randomness (the blinding scalar) fields used during construction, but only Left and Right are serialized to the 66-byte on-chain representation. The right-commitment generator (R = r × G) is the package-level G declared at algebra_pedersen.go:29 — distinct from e.G. What Each Component Represents | Component | Formula | Purpose | |-----------|---------|---------| | **Left (L)** | amount×G + r×P | Encrypted amount + randomness | | **Right (R)** | r×G | Randomness commitment (for decryption) | **Where:** - amount = The actual balance (hidden) - G = Pedersen value generator (global_pedersen_values.G) — the same G used in every value commitment - r = Random blinding scalar (secret, from RandomScalarFixed) - P = Account's public key (used as the second generator inside L, not a global H) - The R = r × G term uses a **distinct** package-level G (algebra_pedersen.go:29) for the randomness commitment — the formula collapses two generators for brevity --- Zero Balance Initialization The Genesis Rule **From Source Code** (blockchain/transaction_execute.go:189-194): What This Means | Registration Block | Initial Balance | Reason | |-------------------|-----------------|--------| | **< 144,000** | 200 atomic units | Early adoption period | | **≥ 144,000** | 0 DERO | Standard registration | **For context:** - 144,000 blocks = 30 days of 18-second blocks (86400 / 18 × 30) - This bonus period ended long ago; the vast majority of addresses have zero initial balance **Timeline:** The 200-unit bonus only applied to addresses registered in the first ~30 days of mainnet (before block 144,000). Any address registered after that starts with exactly zero DERO. --- Homomorphic Operations Addition (Receiving DERO) **When you receive DERO:** **The Math:** Subtraction (Sending DERO) **When you send DERO:** **The Math:** > **Implementation note:** there is **no** Sub method on ElGamal (method set is Add / Plus / Mul / Neg / Serialize). The wallet builds a signed changes ciphertext at walletapi/daemon_communication.go:886-887 and the daemon then adds it via nb.Balance.Add(echanges) at blockchain/transaction_execute.go:239. Subtraction is \"add a negated commitment,\" not a primitive. **Source:** cryptography/crypto/algebra_elgamal.go:69 (func (e *ElGamal) Add) and :80 (func (e *ElGamal) Plus) — these are the two homomorphic primitives; subtraction is composed from Add + Neg. --- What Balance Changes Mean When Balance Changes | Scenario | Balance Changes? | Reason | |----------|-----------------|--------| | **Send DERO** | Yes | Subtracted from your balance | | **Receive DERO** | Yes | Added to your balance | | **Ring member (decoy)** | **Yes** | Participates in ring signature | | **No activity** | No | Balance unchanged | The Ring Member Case (Critical) **Important:** Encrypted balance changes occur for ALL ring members in a transaction, including decoys. This is by design, not a bug. See Ring Member Behavior for details. **Source** (walletapi/daemon_communication.go:886-887 — the // lines below are docs annotations, not in source): --- Balance Query Process How to Query Balance **Query Encrypted Balance (Public)** **Response:** **What you see:** 66 bytes of encrypted data **What you learn:** Nothing about actual balance **Decrypt Balance (Requires Private Key)** **Decryption process:** 1. Deserialize the 66-byte encrypted balance into an ElGamal pair (Left, Right) 2. Compute Left - privateKey × Right which yields amount × G 3. Solve the discrete log (baby-step giant-step) to recover the integer amount **What you see:** Actual balance (e.g., 500 DERO) **Who can do this:** Only the address owner (requires private key for step 2) The Encrypted Balance Identity Test **Comparing balances at different heights:** **What this tells us:** - Identical encrypted data = No balance change - Different encrypted data = Balance changed (for ANY reason) - 22,592 blocks unchanged = No involvement in any transaction (not even as ring member) --- Balance Conservation The Conservation Law **The homomorphic operations preserve this:** Network Verification **The network verifies conservation without seeing amounts.** Because ElGamal is additively homomorphic, the network can confirm that the sum of encrypted inputs equals the sum of encrypted outputs -- without decrypting any of them. If the encrypted totals don't match, the transaction is rejected. The actual balance updates happen in blockchain/transaction_execute.go using the ElGamal.Add() operation from cryptography/crypto/algebra_elgamal.go:69. --- Security Properties What's Protected | Property | How It's Achieved | |----------|------------------| | **Balance confidentiality** | ElGamal encryption | | **Balance integrity** | Commitment binding | | **Conservation** | Homomorphic verification | | **Non-negative balances** | Range proofs | What's Visible | Information | Visible To | |-------------|-----------| | **Encrypted balance (66 bytes)** | Anyone | | **That balance changed** | Anyone | | **Actual balance value** | Only owner | | **Transaction amounts** | Only sender/receiver | --- Key Takeaways The Encryption Guarantee **Always Encrypted:** From creation to storage to operations, DERO balances are always encrypted. The network processes all value transfers without ever seeing a single plaintext balance. Balance Change Interpretation | Observation | What It Means | What It Doesn't Mean | |-------------|--------------|---------------------| | **Balance unchanged** | Address not involved in ANY transaction | - | | **Balance changed** | Address participated in some transaction | ≠ Address was sender | | **66 bytes different** | Some balance operation occurred | ≠ Received or sent specific amount | The Homomorphic Advantage --- Related Pages **Security Suite:** - Ring Member Behavior - Why decoys' balances change - Negative Transfer Protection - Range proof security **Privacy Suite:** - Homomorphic Encryption - Full technical details - Transaction Privacy - Complete privacy model **Technical Reference:** - Wallet RPC API - Balance queries - Daemon RPC API - GetEncryptedBalance method",
       "lastUpdated": "2026-02-06"
     },
+    {
+      "product": "derod",
+      "slug": "integrity/inflation-claim",
+      "title": "The 2022 Inflation Claim: Claims vs. Evidence | DERO Blockchain",
+      "description": "Point-by-point technical rebuttal of the October 2022 DERO inflation claim, including circulated report claims, the submitted proof string, and protocol mechanics that bound what is and isn't possible.",
+      "canonicalUrl": "https://derod.org/integrity/inflation-claim.md",
+      "sourcePath": "derod-main/pages/integrity/inflation-claim.mdx",
+      "headings": [
+        "The 2022 Inflation Claim: Claims vs. Evidence",
+        "TL;DR Summary",
+        "Part 1: The Claim and Its Foundation",
+        "Report claims vs. evidence",
+        "Part 2: The Explorer Wraparound — What It Actually Proves",
+        "Decode it yourself",
+        "Part 3: Forge a Fake Proof Yourself",
+        "The trick, in plain English",
+        "Tier 0 — Paste the one we already made",
+        "Tier 1 — Ask your agent to forge one (no setup)",
+        "Tier 2 — Build one from scratch (no DERO tooling)",
+        "Requires a synced mainnet daemon — RPC port 10102 by default.",
+        "List all 16 ring addresses (pick any slot 0–15 for forging):",
+        "Raw TX bytes for the Go tab:",
+        "peek at the start if you like:  head -c 80 tx.hex",
+        "No wallet, no chain access. Pick ANY display amount.",
+        "Example: forge -1 DERO (the demo callout above)",
+        "Example: the report's claimed amount",
+        "put forge_demo.go here, then:",
+        "Part 4: The Chain's Account at the Exploit Block",
+        "Negative transfers fail range-proof validation",
+        "Verify supply at the exploit block",
+        "Exploit block: what the chain records",
+        "Requires a synced mainnet daemon — RPC port 10102 by default.",
+        "See: /basics/running-a-node",
+        "1) Exploit block header — independent on-chain facts (reward, txcount)",
+        "2) Flagged TX exists in chain — accepted tx means range proofs passed",
+        "3) Optional — GetInfo reports scheduled emission (same formula as Python tab)",
+        "Emission schedule — same model as DERO.GetInfo (not a UTXO census).",
+        "Source: config.PREMINE, blockchain/transaction_execute.go (CalcBlockReward)",
+        "--- At the exploit block (schedule context only) ---",
+        "--- Emission step across the exploit block (~2× block reward, not 2.2M) ---",
+        "--- Optional: confirm GetInfo implements the same schedule (not a mint audit) ---",
+        "Example: getinfo_matches_schedule(topoheight=<from GetInfo>, getinfo_supply=<from GetInfo>)",
+        "Part 5: What Deanonymization Can and Cannot Establish",
+        "Part 6: The Keystone Collapses",
+        "Related Pages"
+      ],
+      "plainText": "The 2022 Inflation Claim: Claims vs. Evidence _Derolytics' \"irrefutable proof\" is a string anyone can forge — and even a genuine one describes a transfer the chain would have rejected._ **Scope:** This page tests **one** claim: that DERO minted ~2.2M coins in October 2022 by exploiting a bug in how transfers were validated. Laundering totals, dollar figures, and attribution to individuals all **derive from this single claim** — if it falls, they fall with it. Governance and wallet-holdings allegations are out of scope here. TL;DR Summary | Question | The Evidence | |----------|--------------| | **Did total supply increase by ~2.2M DERO?** | **No.** The exploit-block reward was **0.615 DERO** — normal scheduled emission, not millions. The report never shows a supply jump on chain. Part 4 | | Is negative-transfer wraparound possible on consensus? | **No.** Range proofs bind every transfer to a non-negative range; a negative/out-of-range amount cannot produce a verifying proof. Part 4 | | Is the circulated payload proof cryptographic evidence of a mint? | **No.** It is a user-supplied **display object**; \"Verified\" means its own math is consistent, not that consensus accepted it. Part 3 | | Can explorer **Verified** on inflated proofs be reproduced? | **Yes** on unpatched explorers (MAX_INT64_SAFE bypass). Part 3 | | Does the deanonymization support the ~2.2M? | **No — it refutes it.** The figure is the forgeable proof string, not a deanonymization output; a faithful deanonymization recovers an ordinary transfer of coins already held. Part 5 | | **Bottom line on the keystone?** | **The artifact at the center of every accusation is a display object anyone can forge — and consensus could not have accepted the transfer it depicts.** Part 6 | --- At the center of every inflation accusation is a string. About a hundred characters of base32, prefixed deroproof1..., pasted into an unpatched DERO explorer where it lights up as **Verified ✓** for an amount the explorer renders as 184,467,438,537,095.51434 DERO — roughly fourteen million times the entire DERO supply. That string is the foundation of the Derolytics \"DERO Heist\" report and its follow-ups — the source of the **2.2-million-DERO** figure, the cited evidence for every downstream claim of laundering, theft, and attribution. It is also a *payload proof*: a wallet-side display object the protocol gives no third party any way to verify. By design. Ring signatures rely on exactly this ambiguity — if outsiders could verify payload proofs, plausible deniability would die with them. The technique that produced it became possible in **May 2024**, when a separate wallet-layer randomness-reuse bug (patched in Release 142) gave outside observers their first means of reading inside DERO's encrypted payloads. Pointed back at a transaction mined on **October 17, 2022** — accepted by every validating node, indistinguishable on-chain from any other transfer — that technique returned a value, paired it with a payload proof, and announced an inflation. The chain never said any such thing. The transaction is the same one it has always been: bounded by range proofs that pin every amount to a non-negative range, conserved by balance proofs that bind inputs to outputs, accepted unanimously. What changed in 2024 was the ability to *interpret* — and a misreading, intentional or otherwise, of what a payload proof is and does. The entire Derolytics narrative rests on that single misreading. Every chart, every accusation, every dollar figure. --- Part 1: The Claim and Its Foundation The report cites this **payload proof** as cryptographic evidence — readers paste it into an explorer, see **Verified**, and treat that as confirmation the on-chain transfer was negative (Proof Types; display-layer only, not consensus). As cited: **Category error:** **Verified** on a pasted payload proof means the display object's internal math is consistent — **not** that nodes accepted the transfer or minted coins. Payload proofs are user-supplied; explorers check math, not consensus. Proof Types **The technical claim** (as stated in public exploit reports) rests on a single assumption — that the payload proof above is cryptographic evidence, and what verifies on an explorer also represents what consensus accepted: 1. The transfer amount was **−2,200,000.00181 DERO** — −220,000,000,181 atoms when the bech32 is decoded (Part 2). 2. Stored as uint64 (an unsigned 64-bit integer, no negatives), that negative value wraparound displays as **~184 trillion DERO** on explorers — roughly **14 million× total supply**. 3. Post-2024 deanonymization is cited to name a fresh wallet as the **sender** — and to read the wraparound as a **~2.2M DERO** credit to that sender, not the **~184 trillion** figure on screen. 4. **Conclusion:** consensus failed → **~2.2M DERO** minted from nothing. Each step is load-bearing. The rest of this page evaluates them on three independent grounds — the proof string (Parts 2–3), what consensus enforces (Part 4), and attribution limits (Part 5) — then synthesizes them (Part 6). Report claims vs. evidence | Report claim | What actually follows | |---|---| | *\"Protocol failed to validate transaction proofs\"* | They mean **payload proofs** (display layer). **Transaction proofs** are verified by every node. Proof Types | | *\"Verify yourself… proof string … on the official explorer\"* | **Verified** = pasted object math checks out, not node acceptance. The string decodes to exactly **−2,200,000.00181** and the explorer's display-layer consistency check passes — because that is all a display proof does. Part 3 | | *\"Sender actually received 2.2M DERO\"* | The ~2.2M is the forgeable proof string, not a deanonymization result; a faithful deanonymization reads a **conserved transfer of coins already held**. Part 5 | | *\"Both wallets freshly created and empty\"* | Ring members **always** show encrypted balance changes — including decoys who did not send. Ring Member Behavior | | *\"$8.34M laundered over 781 transactions\"* | **Assumes the mint happened.** No keystone → the graph is unmotivated. Out of scope here. | --- Part 2: The Explorer Wraparound — What It Actually Proves Paste the Part 1 **payload proof** into an unpatched explorer and it displays **184,467,438,537,095.51434 DERO** with **Verified ✓** — roughly **14 million× total supply** on screen. That figure is a display-layer reading of the embedded uint64 as a positive number. **Proves:** Unpatched explorers can mark inflated payload proofs **Verified** — including amounts that bypass MAX_INT64_SAFE and wrap to negatives. **Does not prove:** The on-chain transaction contained that amount. Remediation **The proof is authentic.** Decode the bech32 string as an integer (rpc.NewAddress → args.Value(RPC_VALUE_TRANSFER, DataUint64)) and the embedded value is 18,446,743,853,709,551,435 — exactly **−2,200,000.00181 DERO**, the report's own stated figure to the atom. The \"off-by-one\" in the display is the explorer's rounding, not a flaw in the proof: FormatMoneyPrecision parses the uint64 via big.ParseFloat(..., prec=0, ...), which Go's stdlib promotes to a **64-bit mantissa** before rounding (documented behavior — when prec=0, math/big.Float.Parse sets it to 64). At that precision the step size near 10¹⁴ (~0.0000153 DERO) is *just over* one atomic unit (0.00001 DERO), so rounding lands in the **last** place — …51435 renders as …51434. Authenticity is the page's point, not a problem for it. The misreading at the heart of the inflation claim isn't \"Derolytics produced a broken proof\" — it's that an authentic display object was treated as consensus state. A layer that cannot reliably render its own last digit is not consensus state. Decode it yourself The canonical path the callout cites — rpc.NewAddress → args.Value — runs in ~10 lines against any DEROHE checkout: On the cited TX with the Part 1 string: **Unpatched** (DEROFDN/derohe main — no proof/proof_validation.go) shows it as **Verified ✓**: Unpatched explorer displays the report proof as Verified — 184,467,438,537,095.51434 DERO **Patched** (DEROFDN/derohe community-dev, via PR #14 — ValidatePayloadProofAmount) rejects the wraparound before display: Same report proof rejected by the patched explorer Part 3 shows anyone can forge such proofs for arbitrary amounts. --- Part 3: Forge a Fake Proof Yourself **We forged one to show how trivial it is.** Below is a fake deroproof… built specifically for this page — accepts on unpatched explorers, shows an amount that never moved on-chain. It took minutes. No wallet, no private keys, no insider access. Everything needed is already public: the Part 1 transaction, its 16 ring slots, and the commitment math. The point isn't that forgery is *theoretically possible* — it's that **the report's \"Verified ✓\" evidence is the same kind of object, built the same way**. The trick, in plain English 1. **Pick the real transaction** everyone is looking at (5bbe1b7eecfe3447cb045b1197a07a214b456968eda8a3d5a90f5fae9ce57e55). 2. **Pick one of 16 ring slots** (positions 0–15) — each slot has a public address; you choose which slot the fake proof should attach to. 3. **Pick any amount** you want on screen — including **−1 DERO** or **~184 trillion DERO** wraparound values. 4. **Do the math.** Each ring slot has a published commitment of the form amount × G + blinder — public on chain. Pick any amount; rearrange to solve for the blinder that fits: blinder = C[slot] − amount × G. 5. **Paste the string** into an unpatched explorer with the same TX. If the display math fits → **Verified ✓** on an unpatched explorer. Nodes never saw the string; supply didn't change. The circulated report string (Part 1) is exactly one such pasted object. **Three ways to see it for yourself**, easiest first — paste ours, ask an agent, or build one from scratch with nothing but public data. Tier 0 — Paste the one we already made **Paste this forged demo** — built for this page, not from the report. | Field | Value | |---|---| | **TX** | 5bbe1b7eecfe3447cb045b1197a07a214b456968eda8a3d5a90f5fae9ce57e55 | | **Ring slot** | **0** (of 16) | | **Encoded amount** | **−1 DERO** → renders on screen as 184,467,440,737,094.51616 | **Unpatched** (DEROFDN/derohe main): Page-built −1 DERO forged proof accepted by unpatched explorer **Patched** (DEROFDN/derohe community-dev, PR #14): Same forged proof rejected — wraparound amount blocked Tier 1 — Ask your agent to forge one (no setup) No Go, no keys, no math. The DERO MCP server ships a dero_forge_demo_proof tool — connect once, then ask in plain language. Two ways in: - **Nothing to install** — point an HTTP MCP client (ChatGPT custom connectors, Cursor hosted mode) at https://mcp.derod.org/mcp. - **Run it yourself** — npx dero-mcp-server and add it to Claude or Cursor. Either way it finds a node automatically: your own if you're running one (the local-first default as of v0.4.0), a public node otherwise. Then ask: > *\"Forge a payload proof for TX 5bbe…e55, ring slot 7, for −5,000,000 DERO.\"* Back comes a deroproof… string. Paste it into an unpatched explorer — it lights up **Verified ✓**, rendering your −5M as a ~184-trillion-DERO \"mint.\" The chain never moved a coin. Change the slot, change the amount, go bigger; the \"evidence\" doesn't care what number you pick — *that's the whole point.* Live now — npx dero-mcp-server (v0.4.0+) or the hosted endpoint at mcp.derod.org, both shipping the forge tool and local-first node resolution (source). Tier 2 — Build one from scratch (no DERO tooling) No wallet — public inputs, public math, one bech32 string. Nothing here comes from DERO, so a skeptic can re-run the whole thing from public data and trust the result. We're showing the work so it can be reproduced, not taken on faith. **What we chose:** ring slot **0**, target **−1 DERO** (= −100,000 atoms). Encoded as the uint64 wraparound **18446744073709451616**, the unpatched explorer renders it as a positive number → **184,467,440,737,094.51616 DERO** on screen — the −1 we picked never appears (same display-layer reading as Part 2). **The equation** (proof/proof.go): C[0] is **public** in the TX hex. Rearrange: **blinder = C[0] − amount×G**. That derived point — **not** the ring address — plus V (amount) and dummy H, bech32-encoded → demo string above. **Self-check:** Passes → unpatched explorer shows **Verified ✓**. **Nothing on-chain changed.** The circulated report string (Part 1) is the same kind of object. Steps 1–2 — fetch the cited TX and its **16 ring members** (public on-chain): The explorer checks commitment math against these public values — not whether the amount was consensus-valid. Step 3 only — wraparound uint64 math for a chosen amount. **Does not** output a pasteable deroproof… string. Step 4 — encode a complete deroproof… string. **Building** the proof needs only the TX bytes (to read C[slot]); the **ring** is used solely by the optional proof.Prove self-check at the end. The proof embeds a **derived blinder point** (C[slot] − amount×G) so the explorer math fits — not the ring address string itself. **Setup once.** This imports github.com/deroproject/derohe/..., so either drop forge_demo.go *inside* a DEROHE checkout, or make a folder beside one and wire a module to it: Change amount and slot to forge any display value for any ring position. If proof.Prove succeeds, an unpatched explorer would show **Verified ✓** for that amount. --- Part 4: The Chain's Account at the Exploit Block The proof asserts consensus accepted a negative-amount transfer — that the protocol minted ~2.2M DERO from nothing. The chain testifies otherwise on two independent counts. **First:** range proofs cannot verify a negative-amount transfer, so no validating node could have accepted one. **Second:** the block where it allegedly happened records a **0.615 DERO** reward — scheduled emission, not millions — and one transaction whose range proofs passed cleanly at every validator. Both counts hold. Negative transfers fail range-proof validation Could negative transfers pass consensus — separate from the submitted proof string? **No — and the guarantee is cryptographic, not a string-parsing quirk.** Every DERO transfer carries a **Bulletproof range proof**. The protocol packs the **transfer amount** and the sender's **remaining balance** into one 128-bit value and proves, in zero knowledge, that it lies in 0, 2^128) — i.e. that *both* the amount sent and the balance left over are valid **non-negative** 64-bit numbers (number := btransfer.Add(btransfer, bdiff.Lsh(bdiff, 64)) at cryptography/crypto/proof_generate.go:471). A \"negative\" transfer is the uint64 wraparound of a huge value, and it cannot satisfy that proof: - **As the amount** — a value near 2^64 exceeds the 64-bit range bound. - **As the consequence** — spending more than you hold drives the *remaining balance* negative, which wraps out of range too. By the **computational soundness** of Bulletproofs — under the discrete-log assumption on the bn256 curve, in the random oracle model (Fiat-Shamir) — no prover can construct a proof that *verifies* for an out-of-range committed value, except with negligible probability bounded by the underlying hardness. Combined with DERO's homomorphic accounting (inputs and outputs are bound to balance exactly), value cannot be created from nothing. Every node runs this verification independently before accepting a block, so a negative-transfer mint is rejected at **consensus** — not merely discouraged client-side. See [Cryptographic Assumptions for the full assumption stack. | Proves | Does not prove | |---|---| | The **specific** alleged mechanism cannot produce a verifying proof. | No inflation via *any* mechanism. | | Range proofs bind every node's acceptance. | Every historical tx has been audited. | Full derivation: Negative Transfer Protection. That closes the *mechanism* question. The *outcome* question is what the chain permanently recorded at topo 1,081,893 — not what a pasted deroproof displays. Verify supply at the exploit block The report's conclusion is that ~2.2M DERO was **minted from nothing** on October 17, 2022 (topoheight **1,081,893**). To support that, it would need to show abnormal coin creation at consensus — a multi-million DERO step in the block itself, or a supply audit against something other than the emission schedule. It publishes neither: only a payload proof string and an interpretation of the **corresponding transaction** (Part 1). Scheduled emission is **deterministic** from block height: premine plus block rewards that halve on a fixed schedule (CalcBlockReward in blockchain/transaction_execute.go). That formula estimates *expected* cumulative supply at any height. **DERO.GetInfo reports the same approximation** (cmd/derod/rpc/rpc_dero_getinfo.go:81-82: PREMINE + CalcBlockReward(topoheight) × topoheight, then divided by 100,000 to convert atomic units to whole DERO) — scheduled emission in whole DERO, **not** a UTXO census or balance sum across the ledger. **Burden of proof.** Supply conservation isn't audited — it's built in. Every accepted transaction is bound by range proofs (amounts must be non-negative) and balance proofs (inputs must equal outputs), so cumulative supply at any height is exactly **premine + scheduled block rewards**. GetInfo.total_supply reports that schedule, not a UTXO census — and it doesn't need to. To show a 2.2M mint, the report would need a deviation against an independent supply measure, or an accounting discrepancy in the block record. It shows neither. Per-block emission at this era was **0.615 DERO**, and the cited block records exactly that. The independent checks on this case: block-header **reward**, cited-TX **acceptance** (range proofs passed), and the **impossibility** of the alleged mechanism (above). Exploit block: what the chain records Independent on-chain checks at topoheight **1,081,893** — query any synced node: | Check | RPC / source | Result | |---|---|---| | Block timestamp | GetBlockHeaderByTopoHeight | 2022-10-17 07:58:09 UTC | | Block hash | GetBlockHeaderByTopoHeight | b6bd914f7fb1c79788fe8676c277e58e7bb5a904317afb096b1d2793af9aed13 | | Block reward | GetBlockHeaderByTopoHeight | **0.615 DERO** (61,500 atomic units) — normal scheduled emission, not a 2.2M mint | | TX count | GetBlockHeaderByTopoHeight | **1** (the cited transaction) | | Cited TX status | GetTransaction | **Accepted and mined** → all range proofs passed at every validating node | | Expected cumulative supply | Emission formula | **~12,946,618 DERO** at this height (schedule only — not a ledger audit) | For context, if a **+2.2M DERO** consensus mint had occurred at this block, expected cumulative supply under the schedule would be **~15,146,618 DERO** instead — but detecting that would require an **independent** supply measure the protocol does not expose via RPC. The report never publishes one. For **this alleged mechanism**, the block record is decisive anyway: a negative-transfer mint would require consensus to accept an impossible amount (range proofs). The TX **was** accepted — under normal protocol rules, with a **0.615 DERO** block reward, not millions. Steps 1–2 are the independent checks. Step 3 confirms GetInfo.total_supply implements the emission schedule (PREMINE + CalcBlockReward × height) — **not** a UTXO census. Matching the Python tab means the RPC uses the formula; it does not detect a surreptitious mint. Same RPC methods are available via the DERO MCP server (dero_get_info, dero_get_block_header_by_topo_height). Part 4 closes the consensus side: the alleged mechanism cannot pass range-proof validation. The exploit block records a **0.615 DERO** reward — not a multi-million mint — and the cited transaction in Part 1 was **accepted**, meaning range proofs passed at every validating node. The report never publishes a supply delta against an independent measure. --- Part 5: What Deanonymization Can and Cannot Establish Parts 2–4 closed the mint question. The report leans on one further capability — deanonymization — to name a beneficiary and trace funds. Applied honestly to this transaction, it does not support the inflation claim. It undercuts it. **The bug was real, and the fix mattered.** The deanonymization in public reports relies on a genuine wallet-layer randomness-reuse vulnerability (disclosed May 2024, fixed in Release 142): payloads were encrypted under a key derived from a **deterministic** blinding scalar feeding a zero-nonce stream cipher, which Release 142 replaced with a per-payload ephemeral key. This page neither disputes the vulnerability nor minimizes the fix. **The ~2.2M is not a deanonymization result.** It is the circulated proof string — a forgeable display object (Part 3) whose embedded uint64 reads as −2,200,000.00181 only if you take a wraparound as negative. The report sources the figure there itself: *\"use the proof string on the official explorer to confirm.\"* **A faithful deanonymization reads the chain — and the chain was constrained in advance.** Deanonymizing recovers the value actually committed in the transaction, not a pasted string. Whatever that value is, the range proof already pinned what it *can* be (Part 4): the sender provably **held** the amount and the balances **conserved**. A committed transfer that wraps either way — the on-screen ~184 trillion DERO or the report's signed −2.2M read as a credit — is impossible: the first exceeds the 64-bit range bound, and the second requires the sender's remaining balance to go negative, which the range proof also forbids (Part 4). So a faithful deanonymization of this transaction recovers an **ordinary transfer of coins that already existed** — not a mint. The payload structure backs this up: in both pre-fix and post-fix wallet code (walletapi/transaction_build.go), the only address-bound byte serialized into the payload is the **receiver index** (witness_index[1]) — the sender is never written into the payload in either era. What Release 142 changed was the **key derivation**, from the global blinding scalar r to a per-payload ephemeral scalar an outside observer can't reconstruct. A faithful read of either era's payload surfaces a receiver index and the committed value — exactly what a deanonymization can return, and nothing more. Attribution to a named individual is the report's own conceded allegation, resting on timing, access, and behavior — not cryptography. The laundering graph inherits that dependency: with no minted 2.2M, there is nothing to launder. --- Part 6: The Keystone Collapses Every downstream claim in the public exploit narrative — dollar figures, laundering graphs, \"stolen funds,\" attribution arguments, the framing of a multi-year cover-up — is built on **one load-bearing artifact**: the payload proof pasted above, presented as cryptographic confirmation that the protocol minted 2.2M DERO from nothing. That artifact fails on four independent grounds — in the order established above: 1. **It is only a display object.** Part 3 — a payload proof is user-supplied; anyone can build a **Verified ✓** one for any amount and any ring slot. 2. **The mechanism is impossible.** Part 4 — a negative/wraparound transfer cannot produce a verifying range proof, so no node would accept it at the protocol layer. 3. **No consensus mint recorded.** Part 4 — block reward was **0.615 DERO**, not millions; the cited TX was **accepted** (range proofs passed). GetInfo reports scheduled emission, not a UTXO census — it cannot detect a surreptitious mint by itself. The report never publishes a supply delta against any independent measure. 4. **Deanonymization refutes the mint, it doesn't support it.** Part 5 — the ~2.2M is the forgeable proof string, not a deanonymization output. A faithful deanonymization reads the value committed on-chain, which the range proof guarantees was held and conserved — an ordinary transfer. Attribution to a person is the report's own conceded allegation. The display-layer bug that made this confusion possible was real. It is being remediated — DEROFDN/derohe community-dev (PR #14), HOLOGRAM, and patched explorers now reject proofs like this one; main and other unpatched explorers may still show **Verified**. That is a display-layer problem worth fixing. It is not evidence that the chain minted coins; the range proofs do not permit it. **\"Don't Trust, Verify\" — exactly. So verify the chain, not a string someone hands you.** Derolytics' executive summary calls the case *\"irrefutable\"* and tells you to *\"verify yourself\"* by pasting the proof into an explorer. But a payload proof's **Verified ✓** only confirms the display object's own math is self-consistent — it never touched consensus. That's not *Don't Trust, Verify* — it's *trust the checkmark.* The string is forgeable for any amount, describing a transfer consensus could never accept. **Verify the chain** — run a node, decode the transaction, check the range proofs — and the \"mint\" disappears. The artifact at the center of every accusation is a display object anyone can forge. The chain neither records the event the report describes nor permits the mechanism it alleges. Every downstream claim — laundering, attribution, dollar figures — requires that artifact to function as cryptographic evidence. It does not. --- Related Pages Transaction vs payload proofs — the distinction at the center of this case Why decoy addresses see ciphertext changes without sending funds Mathematical proof that negative amounts cannot pass consensus Why third-party payload verification is ambiguous by design",
+      "lastUpdated": "2026-05-30"
+    },
     {
       "product": "derod",
       "slug": "integrity/negative-transfer-protection",
-      "title": "Negative Transfer Protection: Mathematical Impossibility | DERO Blockchain",
-      "description": "Technical proof that negative transfers are mathematically impossible in DERO - not 'difficult' but genuinely impossible due to fundamental constraints in the proof system.",
-      "canonicalUrl": "https://derod.org/integrity/negative-transfer-protection",
+      "title": "Negative Transfer Protection: Cryptographic Impossibility | DERO Blockchain",
+      "description": "Why negative or uint64-wraparound transfer amounts cannot pass DERO consensus — grounded in Bulletproof range-proof soundness and homomorphic value conservation, not a client-side check.",
+      "canonicalUrl": "https://derod.org/integrity/negative-transfer-protection.md",
       "sourcePath": "derod-main/pages/integrity/negative-transfer-protection.mdx",
       "headings": [
         "Negative Transfer Protection",
-        "The Claim",
-        "The Proof",
-        "Given",
-        "The Protection Mechanism",
-        "Step-by-Step Proof",
-        "Step 1: The uint64 to int64 Cast",
-        "Step 2: Binary Representation",
-        "Step 3: Bit Processing",
-        "Step 4: The Failure Mode",
-        "Step 5: QED",
-        "Visual Proof",
-        "Verification Methods",
-        "Method 1: Test Go's BigInt Behavior",
-        "Run this Go code",
-        "Method 2: Review Source Code",
-        "View the critical protection",
-        "Method 3: Test Complete Flow",
-        "Why This Cannot Be Bypassed",
-        "Fundamental Guarantees",
-        "Common Questions",
-        "Q: What about the uint64→int64 cast at line 468?",
-        "Q: Could an attacker bypass BigInt.Text(2)?",
-        "Q: What if the bit loop had a bug?",
-        "Q: Has this been tested?",
-        "Security Implications",
-        "What This Means",
-        "The Protection Chain",
-        "Key Takeaways",
-        "The Mathematical Guarantee",
-        "Confidence Level",
+        "The claim",
+        "What every transfer must prove",
+        "Why a negative transfer cannot produce a valid proof",
+        "How the bit decomposition actually works",
+        "Verify it yourself",
+        "The packing + bit decomposition (proof GENERATION)",
+        "The verification every node runs (the actual ENFORCEMENT)",
+        "Why this cannot be bypassed",
         "Related Pages"
       ],
-      "plainText": "Negative Transfer Protection **Mathematical Impossibility:** Negative transfers in DERO are not \"difficult\" or \"impractical\" - they are **mathematically impossible**. This page provides the complete proof. The Claim **DERO cannot accept transactions with negative transfer amounts.** This is a mathematical guarantee, not a policy. The protocol's fundamental design makes negative transfers as impossible as dividing by zero. --- The Proof Given 1. Transfer amounts are stored as uint64 (unsigned 64-bit integer) 2. Range proofs require bit decomposition of amounts 3. Go's BigInt.Text(2) returns binary string representation The Protection Mechanism **Location:** cryptography/crypto/proof_generate.go:468-487 **Why aR differs:** The aR vector is constructed so that aL[i] - aR[i] = 1 (mod Order) for valid bits. For bit=1: 1 - 0 = 1. For bit=0: 0 - (-1) = 1 mod Order. This enforces the bulletproof constraint that each component is a valid binary bit. --- Step-by-Step Proof Step 1: The uint64 to int64 Cast **At line 468:** For uint64 values ≥ 2^63, the int64 cast wraps to negative (two's complement): **This is where someone might think an attack could work.** Step 2: Binary Representation **Go's BigInt.Text(2) for negative values:** **This is guaranteed by Go's standard library:** - Documented behavior - Cannot be overridden - Deterministic Step 3: Bit Processing **The loop at lines 479-487 processes each character:** **For negative values:** - First character is '-' (ASCII 45) - Loop expects '1' (ASCII 49) or '0' (ASCII 48) - '-' is neither '1' nor '0' Step 4: The Failure Mode **When '-' is processed:** **Result:** - Bit vector contains an invalid representation - Range proof verification fails downstream - Network verification fails - Transaction rejected Step 5: QED --- Visual Proof --- Verification Methods Method 1: Test Go's BigInt Behavior **Expected Output:** Method 2: Review Source Code **Look for:** - Line 468: SetInt64(int64(witness.TransferAmount)) - Line 473: number.Text(2) - binary conversion - Line 476: Comment about negative prevention - Lines 479-487: Bit processing loop Method 3: Test Complete Flow --- Why This Cannot Be Bypassed Fundamental Guarantees **1. Go Standard Library Behavior** - This is Go's official implementation - Cannot be changed or overridden - Has been stable for 10+ years **2. String Processing is Deterministic** - Byte-by-byte iteration is exact - '-' (45) is never equal to '1' (49) or '0' (48) - No edge cases or exceptions **3. Three Independent Layers** Even if Layer 1 somehow failed: | Layer | What It Catches | Status | |-------|----------------|--------| | **Layer 1: Bit Decomposition** | Detects '-' in string | ✅ Catches negatives | | **Layer 2: Range Proof (A_t)** | Invalid bit commitments | ✅ Fails verification | | **Layer 3: Inner Product** | Cryptographic inconsistency | ✅ Proof mismatch | **All three layers independently prevent negative transfers.** --- Common Questions Q: What about the uint64→int64 cast at line 468? **A:** This cast is **protected**, not a vulnerability. The cast is part of the normal flow. The protection happens downstream. Q: Could an attacker bypass BigInt.Text(2)? **A:** No. This is Go standard library code: - Cannot be modified without recompiling Go itself - Is the same implementation used by millions of Go programs - Has been security-audited extensively Q: What if the bit loop had a bug? **A:** Even then, Layers 2 and 3 provide backup: - Invalid bit vectors create invalid commitments - Invalid commitments fail range proof verification - Failed range proofs fail inner product verification Q: Has this been tested? **A:** Yes. See the verification methods above — Method 1 tests Go's BigInt.Text(2) behavior directly, and Method 3 simulates the complete attack flow. Both confirm the protection mechanism works as described. --- Security Implications What This Means **Inflation is Impossible:** Since negative transfers are impossible, tokens cannot be created from nothing. The total supply is mathematically guaranteed by the proof system. The Protection Chain **At no point can a negative transfer succeed.** --- Key Takeaways The Mathematical Guarantee | Aspect | Guarantee | |--------|-----------| | **Negative detection** | Go stdlib (cannot bypass) | | **Bit validation** | String processing (deterministic) | | **Proof verification** | Cryptographic (mathematically secure) | | **Network consensus** | Distributed (no single point of failure) | Confidence Level **Mathematical certainty** that negative transfers are impossible, grounded in: - Go standard library behavior (deterministic, documented, stable for 10+ years) - Multiple independent protection layers (any single layer is sufficient) - Cryptographic guarantees (bulletproof range verification) - Open source and auditable (all code paths are verifiable) **The Bottom Line:** Negative transfers in DERO are not blocked by a policy or a check that could be bypassed. They are blocked by fundamental mathematical constraints in the proof system. Creating a negative transfer would be like creating a triangle with four sides - it's not difficult, it's impossible by definition. --- Related Pages **Security Suite:** - Range Proof Integrity - Triple-layer defense - Transaction Proofs - Six sigma system - Proof Verification Flow - Complete flow **Privacy Suite:** - Bulletproofs - Zero-knowledge range proofs",
-      "lastUpdated": "2026-02-06"
+      "plainText": "Negative Transfer Protection **The chain rejects it.** No DERO transaction can transfer a negative amount or create coins from nothing — the network refuses to accept it. The protection isn't a check inside the wallet that a malicious sender could remove; it's enforced by every node, by recomputing the math on every transfer (formally: range-proof soundness + value conservation). The claim **DERO consensus cannot accept a transaction that transfers a negative amount or mints value from nothing.** This is a mathematical guarantee, enforced independently by every validating node. Crucially, it does **not** depend on the sender's wallet behaving honestly. A malicious sender controls their own client, so any protection that lived only in proof *generation* could be patched out. The protection lives in proof *verification*, where it cannot. --- What every transfer must prove DERO (Stargate) holds account balances as **homomorphic ElGamal ciphertexts**. A transfer never reveals amounts; instead it carries zero-knowledge proofs that constrain what could have happened: 1. A **Sigma proof** binds the transaction together: the sender controls their key, and the encrypted amounts **conserve value** across the statement — what leaves one account enters others, nothing is created. 2. A **Bulletproof range proof** proves the hidden quantities lie in a valid **non-negative** range. The range proof is the one that closes the door on negative transfers. DERO packs **two** quantities into a single 128-bit value and range-proves them together (cryptography/crypto/proof_generate.go:468-471): The trailing // this should be reduced comments are the DERO author's own forensic note in source — flagging that reduction modulo the bn256 group order should be applied to these inputs. They are preserved verbatim here because they carry that authorial signal. So one range proof establishes **both**: - the **amount sent** is a valid non-negative 64-bit number, and - the sender's **remaining balance** is a valid non-negative 64-bit number. **Why both matter:** proving only the amount is non-negative would not stop an overspend. By also proving the *remaining* balance is non-negative, the same proof guarantees you cannot send more than you hold — and cannot manufacture a balance by sending a \"negative\" amount. --- Why a negative transfer cannot produce a valid proof A \"negative\" amount is just the two's-complement uint64 wraparound of a value near 2^64. Fed into the construction, it fails the range proof from **both** directions: | Attack framing | Why the range proof rejects it | |---|---| | Treat the wraparound as the **transfer amount** | A value near 2^64 lies outside 0, 2^64) — the low-64 range bound fails. | | Treat it as **receiving** (so your own balance jumps) | The conservation proof forces a matching decrease; the sender's **remaining balance** goes negative → wraps → the high-64 range bound fails. | The decisive property is **computational soundness** — under the discrete-log assumption on bn256, in the random oracle model (Fiat-Shamir). A Bulletproof convinces the verifier that the committed value is in range *without revealing it*, and soundness means a prover **cannot construct a proof that verifies** for a value outside the range, except with negligible probability bounded by the underlying hardness. There is no \"almost in range,\" no rounding, no edge case: either a verifying proof exists (value in range) or — modulo that negligible cheating probability — it does not. See [Cryptographic Assumptions for the full stack. **Common misconception — it is *not* the minus sign.** A claim circulates that protection comes from Go's BigInt.Text(2) emitting a '-' that \"breaks the bit loop.\" That is not the mechanism: - That loop is **proof *generation*** (the sender's wallet), not node verification — an attacker controls it and could change it. - For a real transaction number = transfer + (balance << 64) is **positive**, so Text(2) produces no '-' at all. - The loop is an if bit == '1' { … } else { … }; it does not *detect* or *reject* anything — a stray character would simply be treated as a 0 bit. The protection is the **verifier's** Bulletproof check plus homomorphic conservation. The bit decomposition below is just how an *honest* prover builds the proof — it is not the safeguard. --- How the bit decomposition actually works For completeness, lines 473–487 of proof_generate.go turn number into the two vectors a Bulletproof commits to: aL is the bit vector of number; aR = aL − 1. Note: in the actual source at proof_generate.go:485, the -1 is stored as new(big.Int).Mod(new(big.Int).SetInt64(-1), bn256.Order) — i.e. the field-order representative of -1 (a 256-bit positive integer congruent to -1 mod bn256.Order). A literal -1 in Go's big.Int would carry the negative sign and would *not* be equivalent in the bulletproof's polynomial relations; the Mod(..., bn256.Order) is load-bearing. The proof then demonstrates, in zero knowledge, that for every position aL ∘ aR = 0 and aL − aR = 1 — i.e. **each component really is a single bit (0 or 1)** — and that those bits reconstruct the committed value. A value that is not a genuine 128-bit non-negative integer cannot satisfy those constraints, so the inner-product argument the verifier checks will not close. This is generation code, shown for understanding. What *enforces* the rule is cryptography/crypto/proof_verify.go, run by every node: it re-derives the commitments and checks the inner-product relation. A malformed or out-of-range number yields a proof that simply fails that check. --- Verify it yourself Look for the transfer + (balance << 64) packing and the 128-bit decomposition in proof_generate.go, then the inner-product / range check the *verifier* performs in proof_verify.go. The safeguard is on the verify side — that is the half an attacker cannot control. The honest test is **not** \"does Text(2) contain a -.\" It is: **can you build a transaction with a negative / wraparound amount whose range proof verifies?** You cannot: - A standard wallet will not assemble such a transfer — the witness is out of range. - Hand-craft a statement with an out-of-range number, and proof_verify.go rejects the range proof: the inner-product argument does not close. - Every node re-runs that verification before accepting the block, so even a locally forged \"acceptance\" is rejected by the network. The same holds for the alleged October 2022 inflation: a negative-transfer mint cannot reach consensus. --- Why this cannot be bypassed | Layer | Guarantee | |---|---| | **Range proof (Bulletproof)** | Committed transfer **and** remaining balance are provably in 0, 2^64). Soundness ⇒ no verifying proof exists for an out-of-range value. | | **Homomorphic conservation (Sigma)** | Encrypted inputs and outputs are bound so value is conserved — coins cannot be created, only moved. | | **Independent verification** | Every node re-verifies both proofs before accepting a block. There is no trusted client to subvert. | **Bottom line:** Negative transfers are not blocked by a policy or a parser that could be patched around. They are blocked because no prover can produce a range proof that *verifies* for a negative or out-of-range amount, and because the homomorphic statement conserves value. Minting coins this way is not \"hard\" — it is cryptographically impossible. --- Related Pages **Security suite:** - [Range Proof Integrity — how the range proof binds amounts - Transaction Proofs — the full proof set every node checks - Proof Verification Flow — end-to-end validation - 2022 Inflation Claim — point-by-point rebuttal of the circulated negative-transfer report **Privacy suite:** - Bulletproofs — zero-knowledge range proofs",
+      "lastUpdated": "2026-05-25"
     },
     {
       "product": "derod",
       "slug": "integrity/network-consensus-validation",
       "title": "Network Consensus Validation: Distributed Security | DERO Blockchain",
       "description": "How DERO's distributed network validates transactions through consensus - every node verifies independently, creating Byzantine fault tolerance and eliminating single points of failure.",
-      "canonicalUrl": "https://derod.org/integrity/network-consensus-validation",
+      "canonicalUrl": "https://derod.org/integrity/network-consensus-validation.md",
       "sourcePath": "derod-main/pages/integrity/network-consensus-validation.mdx",
       "headings": [
         "Network Consensus Validation",
@@ -872,7 +900,7 @@
         "Defense in Depth",
         "Related Pages"
       ],
-      "plainText": "Network Consensus Validation **Distributed Security:** Every DERO node independently validates every transaction. There's no central authority - security comes from the mathematical certainty that all nodes will reach the same conclusion when given the same data. The Consensus Model Distributed Validation Why This Works **Deterministic Verification:** - Same transaction → Same verification result - Every honest node reaches the same conclusion - No coordination required between nodes - Mathematical certainty, not voting --- Transaction Lifecycle Phase 1: Submission Phase 2: Full Verification **Each node performs complete verification.** The core verification logic lives in cryptography/crypto/proof_verify.go in the Verify() function. Each node independently runs through the same sequence: 1. **Overflow check** -- Reject if fees + extra_value overflows (proof_verify.go:108-110) 2. **Parity check** -- Verify the secret parity is well-formed (proof_verify.go:136-141) 3. **Polynomial recovery** -- Verify B^w × A recovery (proof_verify.go:177-179) 4. **Challenge hash** -- Recompute and compare challenge c from all six sigma proof components (proof_verify.go:410-425) 5. **Inner product** -- Final cryptographic consistency check (proof_verify.go:457-459) If any step fails, Verify() returns false and the transaction is rejected. Phase 3: Propagation **Key Principle:** Nodes only propagate transactions they've independently verified as valid. Phase 4: Block Inclusion --- What Gets Verified Transaction-Level Checks | Check | What It Validates | Failure Means | |-------|------------------|---------------| | **6 sigma proofs** | A_y, A_D, A_b, A_X, A_t, A_u all valid (A_t includes range proof) | Forged transaction | | **Inner product** | Bulletproof verification (sub-component of A_t range proof) | Invalid amount / proof manipulation | | **Structure** | Valid format, sizes, parity | Malformed TX | | **Overflow** | Fee arithmetic doesn't overflow uint64 | Arithmetic attack | | **Fee** | Sufficient fee included | Underpaid TX | Block-Level Checks | Check | What It Validates | Failure Means | |-------|------------------|---------------| | **All TXs valid** | Every TX passes individual checks | Block contains invalid TX | | **Block header** | Valid previous hash, timestamp | Chain fork or manipulation | | **Mining proof** | Valid AstroBWT solution | Insufficient work | | **Size limits** | Block within size constraints | Oversized block | | **Merkle root** | TX hash tree correct | TX inclusion manipulation | --- Byzantine Fault Tolerance The Byzantine Generals Problem **DERO's solution:** Why Malicious Nodes Can't Win **The math is deterministic:** **Key insight:** Nodes don't \"vote\" on validity. They independently compute the same mathematical result. A malicious node lying about the result is just ignored. --- The Verification Timeline Single Transaction When a transaction is submitted, it passes through these stages in order: 1. **Basic format check** -- Structural validation (field counts, size limits, parity) 2. **Full proof verification** -- All sigma proofs and inner product proof verified mathematically 3. **Mempool admission** -- If valid, added to the node's mempool 4. **Peer propagation** -- Forwarded to connected peers, who independently verify > **Note:** No official benchmarks exist for per-step verification times. Actual performance depends on hardware, network conditions, and ring size. The codebase does not include benchmark tests for proof verification. Block Confirmation **Block Time:** DERO's block time is **18 seconds** as defined in config/config.go:34. The README mentions \"16s\" but this appears to be outdated - the actual constant is BLOCK_TIME = uint64(18). **Source verification:** --- Network Topology P2P Architecture **Properties:** - No central coordinator - Multiple paths between nodes - Failure of one node doesn't affect others - Geographic distribution TLS Encryption **All node communication is encrypted:** **Benefits:** - Prevents eavesdropping on transaction data - Encrypts all peer-to-peer traffic **Honest limitations:** - Uses InsecureSkipVerify: true -- peers are not authenticated via certificate validation - TLS provides transport encryption, not peer identity verification - Peer identity is established through the DERO handshake protocol, not TLS certificates --- Finality When is a Transaction \"Final\"? **Probabilistic Finality:** Like all Proof-of-Work chains, DERO has probabilistic finality -- each additional block confirmation makes reversal exponentially harder. The general principle: - **1 confirmation** -- Transaction is in a block, but a competing chain could still overtake - **More confirmations** -- Each subsequent block multiplies the computational cost of a reversal - **Deep confirmations** -- Reversal becomes economically and computationally impractical The exact reversal probability for any given confirmation depth depends on the attacker's share of total network hashrate. No fixed percentages can be stated without knowing the current hashrate distribution. > **Note:** DERO uses AstroBWT proof-of-work and an 18-second block time (config/config.go:34). Specific finality guarantees depend on the live network's hashrate, which varies over time. **What the source code defines:** **Confirmation timing** (simple arithmetic): | Confirmations | Time | |--------------|------| | 1 | ~18s | | 3 | ~54s | | 6 | ~108s (~2 min) | | 10 | ~180s (~3 min) | | 20 | ~360s (~6 min) | How many confirmations to wait is a risk decision for the application or service -- it depends on the transaction value and the current network hashrate, neither of which are protocol constants. Block Reorganization **Reorg protection:** Deeper transactions are safer because reorganizing the chain becomes exponentially harder. --- Security Guarantees What Consensus Provides | Guarantee | How It's Achieved | |-----------|------------------| | **No fake transactions** | Cryptographic proof verification | | **No transaction replay** | Nonce/height tracking and key image binding to tree state | | **No censorship** | Decentralized mining | | **Eventual finality** | Longest chain rule | | **Consistent state** | Deterministic verification | What It Doesn't Provide | Non-Guarantee | Why | |---------------|-----| | **Instant finality** | Probabilistic confirmation | | **Privacy from nodes** | Nodes see encrypted TXs | | **51% attack immunity** | Theoretical possibility | --- Key Takeaways The Consensus Guarantee Defense in Depth **Multiple layers:** - Wallet creates valid proofs (or TX can't be created) - Each node verifies (or TX is dropped) - Miners include only valid TXs (or block is rejected) - Network verifies blocks (or block is orphaned) **No Single Point of Failure:** DERO's security doesn't depend on any single node, miner, or authority. It depends on the mathematical certainty that honest nodes, running honest code, will all reach the same conclusion about transaction validity. --- Related Pages **Security Suite:** - Transaction Proofs - What nodes verify - Proof Verification Flow - Detailed verification steps **Technical Reference:** - Running a Node - Participate in consensus - Daemon RPC API - Submit transactions",
+      "plainText": "Network Consensus Validation **Distributed Security:** Every DERO node independently validates every transaction. There's no central authority - security comes from the mathematical certainty that all nodes will reach the same conclusion when given the same data. **Scope of this page:** \"Consensus\" here refers to *network agreement on transaction validity* — every node independently re-runs the proof system and reaches the same accept/reject decision because the math is deterministic. **Chain consensus** — which sequence of blocks is canonical, how forks are resolved — is a separate concern handled by DERO's proof-of-work + DAG selection rules, and is not the subject of this page. The Consensus Model Distributed Validation Why This Works **Deterministic Verification:** - Same transaction → Same verification result - Every honest node reaches the same conclusion - No coordination required between nodes - Mathematical certainty, not voting --- Transaction Lifecycle Phase 1: Submission Phase 2: Full Verification **Each node performs complete verification.** The core verification logic lives in cryptography/crypto/proof_verify.go in the Verify() function (proof_verify.go:98). Each node independently runs through the same sequence: 1. **Overflow check** -- Reject if fees + extra_value overflows (proof_verify.go:108-111) 2. **Parity check** -- Verify the secret parity is well-formed (proof_verify.go:136-141) 3. **Polynomial recovery** -- Verify B^w × A recovery (proof_verify.go:162-180) 4. **Challenge hash** -- Recompute and compare challenge c from all six sigma proof components (proof_verify.go:410-425) 5. **Inner product** -- Final cryptographic consistency check (proof_verify.go:457-460) If any step fails, Verify() returns false and the transaction is rejected. Phase 3: Propagation **Key Principle:** Nodes only propagate transactions they've independently verified as valid. Phase 4: Block Inclusion --- What Gets Verified Transaction-Level Checks | Check | What It Validates | Failure Means | |-------|------------------|---------------| | **6 sigma proofs** | A_y, A_D, A_b, A_X, A_t, A_u all valid (A_t includes range proof) | Forged transaction | | **Inner product** | Bulletproof verification (sub-component of A_t range proof) | Invalid amount / proof manipulation | | **Structure** | Valid format, sizes, parity | Malformed TX | | **Overflow** | Fee arithmetic doesn't overflow uint64 | Arithmetic attack | | **Fee** | Sufficient fee included | Underpaid TX | Block-Level Checks | Check | What It Validates | Failure Means | |-------|------------------|---------------| | **All TXs valid** | Every TX passes individual checks | Block contains invalid TX | | **Block header** | Valid previous hash, timestamp | Chain fork or manipulation | | **Mining proof** | Valid AstroBWT solution | Insufficient work | | **Size limits** | Block within size constraints | Oversized block | | **Merkle root** | TX hash tree correct | TX inclusion manipulation | --- Byzantine Fault Tolerance The Byzantine Generals Problem **DERO's solution:** Why Malicious Nodes Can't Win **The math is deterministic:** **Key insight:** Nodes don't \"vote\" on validity. They independently compute the same mathematical result. A malicious node lying about the result is just ignored. --- The Verification Timeline Single Transaction When a transaction is submitted, it passes through these stages in order: 1. **Basic format check** -- Structural validation (field counts, size limits, parity) 2. **Full proof verification** -- All sigma proofs and inner product proof verified mathematically 3. **Mempool admission** -- If valid, added to the node's mempool 4. **Peer propagation** -- Forwarded to connected peers, who independently verify > **Note:** No official benchmarks exist for per-step verification times. Actual performance depends on hardware, network conditions, and ring size. The codebase does not include benchmark tests for proof verification. Block Confirmation **Block Time:** DERO's block time is **18 seconds** as defined in config/config.go:34. The README mentions \"16s\" but this appears to be outdated - the actual constant is BLOCK_TIME = uint64(18). **Source verification:** --- Network Topology P2P Architecture **Properties:** - No central coordinator - Multiple paths between nodes - Failure of one node doesn't affect others - Geographic distribution TLS Encryption **All node communication is encrypted:** **Benefits:** - Prevents eavesdropping on transaction data - Encrypts all peer-to-peer traffic **Honest limitations:** - Uses InsecureSkipVerify: true -- peers are not authenticated via certificate validation - TLS provides transport encryption, not peer identity verification - Peer identity is established through the DERO handshake protocol, not TLS certificates --- Finality When is a Transaction \"Final\"? **Probabilistic Finality:** Like all Proof-of-Work chains, DERO has probabilistic finality -- each additional block confirmation makes reversal exponentially harder. The general principle: - **1 confirmation** -- Transaction is in a block, but a competing chain could still overtake - **More confirmations** -- Each subsequent block multiplies the computational cost of a reversal - **Deep confirmations** -- Reversal becomes economically and computationally impractical The exact reversal probability for any given confirmation depth depends on the attacker's share of total network hashrate. No fixed percentages can be stated without knowing the current hashrate distribution. > **Note:** DERO uses AstroBWT proof-of-work and an 18-second block time (config/config.go:34). Specific finality guarantees depend on the live network's hashrate, which varies over time. **What the source code defines:** **Confirmation timing** (simple arithmetic): | Confirmations | Time | |--------------|------| | 1 | ~18s | | 3 | ~54s | | 6 | ~108s (~2 min) | | 10 | ~180s (~3 min) | | 20 | ~360s (~6 min) | How many confirmations to wait is a risk decision for the application or service -- it depends on the transaction value and the current network hashrate, neither of which are protocol constants. Block Reorganization **Reorg protection:** Deeper transactions are safer because reorganizing the chain becomes exponentially harder. --- Security Guarantees What Consensus Provides | Guarantee | How It's Achieved | |-----------|------------------| | **No fake transactions** | Cryptographic proof verification | | **No transaction replay** | Nonce/height tracking and key image binding to tree state | | **No censorship** | Decentralized mining | | **Eventual finality** | Longest chain rule | | **Consistent state** | Deterministic verification | What It Doesn't Provide | Non-Guarantee | Why | |---------------|-----| | **Instant finality** | Probabilistic confirmation | | **Privacy from nodes** | Nodes see encrypted TXs | | **51% attack immunity** | Theoretical possibility | --- Key Takeaways The Consensus Guarantee Defense in Depth **Multiple layers:** - Wallet creates valid proofs (or TX can't be created) - Each node verifies (or TX is dropped) - Miners include only valid TXs (or block is rejected) - Network verifies blocks (or block is orphaned) **No Single Point of Failure:** DERO's security doesn't depend on any single node, miner, or authority. It depends on the mathematical certainty that honest nodes, running honest code, will all reach the same conclusion about transaction validity. --- Related Pages **Security Suite:** - Transaction Proofs - What nodes verify - Proof Verification Flow - Detailed verification steps **Technical Reference:** - Running a Node - Participate in consensus - Daemon RPC API - Submit transactions",
       "lastUpdated": "2026-02-06"
     },
     {
@@ -880,7 +908,7 @@
       "slug": "integrity/overflow-protection",
       "title": "Overflow Protection: Integer Safety | DERO Blockchain",
       "description": "Technical documentation of DERO's integer overflow protection mechanisms that prevent arithmetic attacks on transaction fees and values.",
-      "canonicalUrl": "https://derod.org/integrity/overflow-protection",
+      "canonicalUrl": "https://derod.org/integrity/overflow-protection.md",
       "sourcePath": "derod-main/pages/integrity/overflow-protection.mdx",
       "headings": [
         "Overflow Protection: Integer Safety",
@@ -901,7 +929,7 @@
         "Position in Code",
         "Related Protections",
         "Combined with Other Checks",
-        "Defense in Depth",
+        "Order of Verifier Operations",
         "Security Guarantees",
         "What This Protects Against",
         "Confidence Level",
@@ -911,7 +939,7 @@
         "Source Code Reference",
         "Related Pages"
       ],
-      "plainText": "Overflow Protection: Integer Safety **Arithmetic Safety:** DERO includes explicit checks to prevent integer overflow attacks that could manipulate transaction fees or values. These checks are performed during proof verification before any transaction is accepted. The Threat: Integer Overflow Attacks What is Integer Overflow? Integer overflow occurs when an arithmetic operation produces a value outside the range that can be represented by the data type. In blockchain contexts, this can be exploited to: - **Create tokens from nothing** (if overflow wraps to positive) - **Bypass fee requirements** (if fees overflow to small values) - **Manipulate transaction values** (if sums overflow) Example Attack Vector --- DERO's Protection Mechanism The Overflow Check **Location:** cryptography/crypto/proof_verify.go:108-110 How It Works The Mathematical Principle **For unsigned integers, if a + b overflows:** **For valid (non-overflowing) addition:** This property is exploited to detect overflow without needing arbitrary-precision arithmetic. --- Verification: Step-by-Step Normal Case (No Overflow) Attack Case (Overflow Detected) --- Test It Yourself Go Verification Program **Expected Output:** --- Where This Check Occurs In the Verification Flow Position in Code The overflow check happens **early** in the verification process, before expensive cryptographic operations: **Why early?** Checking for overflow before expensive operations: 1. Saves computational resources on invalid transactions 2. Prevents attackers from wasting node resources 3. Fails fast on obviously malicious inputs --- Related Protections Combined with Other Checks | Check | What It Prevents | Location | |-------|-----------------|----------| | **Overflow check** | Arithmetic manipulation | proof_verify.go:108-110 | | **Bit decomposition** | Negative amounts | proof_generate.go:479-487 | | **Range proof** | Out-of-range values | Bulletproof system | | **Inner product** | Proof forgery | proof_innerproduct.go | Defense in Depth --- Security Guarantees What This Protects Against | Attack | How It's Blocked | |--------|-----------------| | **Fee overflow** | Sum comparison catches wraparound | | **Value manipulation** | Early rejection before processing | | **Resource exhaustion** | Fails fast, minimal computation | Confidence Level **Mathematical Certainty:** The overflow check uses a fundamental property of unsigned integer arithmetic that cannot be bypassed. If a + b overflows, then a + b < a is **always** true. This is guaranteed by CPU hardware behavior. --- Key Takeaways The Protection Summary Why This Matters - **Prevents token creation** from arithmetic manipulation - **Protects fee integrity** ensuring miners receive proper fees - **Fails fast** saving network resources - **Hardware-guaranteed** relies on CPU arithmetic behavior --- Source Code Reference **File:** cryptography/crypto/proof_verify.go **Lines:** 108-110 **Function:** Verify() **Verification command:** --- Related Pages **Security Suite:** - Negative Transfer Protection - Bit decomposition defense - Range Proof Integrity - Triple-layer protection - Proof Verification Flow - Complete verification process **Technical Reference:** - Transaction Proofs - Proof system overview - Network Consensus - Distributed validation",
+      "plainText": "Overflow Protection: Integer Safety **Arithmetic Safety:** DERO includes explicit checks to prevent integer overflow attacks that could manipulate transaction fees or values. These checks are performed during proof verification before any transaction is accepted. The Threat: Integer Overflow Attacks What is Integer Overflow? Integer overflow occurs when an arithmetic operation produces a value outside the range that can be represented by the data type. In blockchain contexts, this can be exploited to: - **Create tokens from nothing** (if overflow wraps to positive) - **Bypass fee requirements** (if fees overflow to small values) - **Manipulate transaction values** (if sums overflow) Example Attack Vector --- DERO's Protection Mechanism The Overflow Check **Location:** cryptography/crypto/proof_verify.go:108-111 How It Works The Mathematical Principle **For unsigned integers, if a + b overflows:** **For valid (non-overflowing) addition:** This property is exploited to detect overflow without needing arbitrary-precision arithmetic. --- Verification: Step-by-Step Normal Case (No Overflow) Attack Case (Overflow Detected) --- Test It Yourself Go Verification Program **Expected Output:** --- Where This Check Occurs In the Verification Flow Position in Code The overflow check happens **early** in the verification process, before expensive cryptographic operations: **Why early?** Checking for overflow before expensive operations: 1. Saves computational resources on invalid transactions 2. Prevents attackers from wasting node resources 3. Fails fast on obviously malicious inputs --- Related Protections Combined with Other Checks | Check | What It Prevents | Location | |-------|-----------------|----------| | **Overflow check** | Arithmetic manipulation (fee wraparound) | proof_verify.go:108-111 | | **Bulletproof range proof** (A_t commitment closed by the inner product proof) | Out-of-range values, including negative/wraparound amounts. The A_t commitment and the inner product proof are **one bulletproof gate with two named pieces**, not two separable checks — see Bulletproofs § Inner Product Proof — Closing A_t | A_t commitment: proof_verify.go (every node); IP closure: proof_innerproduct.go:71 + proof_verify.go:457 | Order of Verifier Operations > The verifier runs these steps sequentially; each is a precondition for proceeding to the next. They are **not** \"layers of defense in depth against the same attack\" — each catches a different malformation. The cryptographic guarantee against negative-transfer / wraparound mints is the bulletproof gate alone. --- Security Guarantees What This Protects Against | Attack | How It's Blocked | |--------|-----------------| | **Fee overflow** | Sum comparison catches wraparound | | **Value manipulation** | Early rejection before processing | | **Resource exhaustion** | Fails fast, minimal computation | Confidence Level **Mathematical Certainty:** The overflow check uses a fundamental property of unsigned integer arithmetic that cannot be bypassed. If a + b overflows, then a + b < a is **always** true. This is guaranteed by the Go language specification, which defines uint64 arithmetic as wrapping modulo 2^64. --- Key Takeaways The Protection Summary Why This Matters - **Prevents token creation** from arithmetic manipulation - **Protects fee integrity** ensuring miners receive proper fees - **Fails fast** saving network resources - **Language-spec-guaranteed** — Go defines uint64 arithmetic as wrapping modulo 2^64 --- Source Code Reference **File:** cryptography/crypto/proof_verify.go **Lines:** 108-111 **Function:** Verify() (defined at proof_verify.go:98) **Verification command:** --- Related Pages **Security Suite:** - Negative Transfer Protection - Verifier-enforced bulletproof soundness - Range Proof Integrity - 128-bit range proof closed at the verifier - Proof Verification Flow - Complete verification process **Technical Reference:** - Transaction Proofs - Proof system overview - Network Consensus - Distributed validation",
       "lastUpdated": "2025-01-26"
     },
     {
@@ -919,7 +947,7 @@
       "slug": "integrity/payload-vs-transaction-proofs",
       "title": "Proof Types Explained: Transaction vs. Payload Proofs | DERO Blockchain",
       "description": "Critical distinction between DERO's two proof systems - transaction proofs (consensus-level, secure) and payload proofs (display-level, by design unverifiable). Includes technical analysis of fake proof creation and explorer mitigation.",
-      "canonicalUrl": "https://derod.org/integrity/payload-vs-transaction-proofs",
+      "canonicalUrl": "https://derod.org/integrity/payload-vs-transaction-proofs.md",
       "sourcePath": "derod-main/pages/integrity/payload-vs-transaction-proofs.mdx",
       "headings": [
         "Proof Types Explained",
@@ -933,9 +961,8 @@
         "What They Are",
         "How They Work",
         "The Math Check",
-        "Why Payload Proofs Can Be Faked",
-        "The Design Reason",
-        "How Faking Works",
+        "Why fakeability isn't a flaw",
+        "How forgery works",
         "Demonstration",
         "Technical Cause: The int64 Cast Issue",
         "Why Fake Proofs \"Validate\"",
@@ -951,9 +978,6 @@
         "For Users",
         "For Developers",
         "For Analysts",
-        "Why This Design?",
-        "The Privacy Trade-off",
-        "The Philosophy",
         "Key Takeaways",
         "Transaction Proofs",
         "Payload Proofs",
@@ -961,7 +985,7 @@
         "Related: Payload Encryption (Separate Issue)",
         "Related Pages"
       ],
-      "plainText": "Proof Types Explained **Critical Distinction:** DERO has two completely different proof systems that serve different purposes. Confusing them leads to fundamental misunderstandings about what can and cannot be verified. The Two Proof Systems Quick Comparison | Aspect | Transaction Proofs | Payload Proofs | |--------|-------------------|----------------| | **Purpose** | Consensus validation | Display/communication | | **Verified by** | All network nodes | Explorer/wallet UI | | **Security** | Cryptographically secure | Math check only | | **Can be faked?** | No | Yes (by design) | | **Affects blockchain?** | Yes | No | | **Third-party verifiable?** | Yes (validity only) | No | --- Transaction Proofs: The \"Real\" Proofs What They Are Transaction proofs are the cryptographic proofs that make transactions valid. They're generated when you create a transaction and verified by every node on the network. **Components:** - Six Sigma proofs (A_y, A_D, A_b, A_X, A_t, A_u) - Inner product proof - Challenge hash binding all components How They Work Security Guarantees **Verification** (see cryptography/crypto/proof_verify.go): The Verify() function recomputes the challenge hash c from all six recovered sigma components (A_y, A_D, A_b, A_X, A_t, A_u) at lines 410-425, then verifies the inner product proof at lines 457-459. If any component was tampered with, the recomputed hash won't match and Verify() returns false. **Why they can't be faked:** - All proofs are cryptographically bound - Faking one changes the hash - Changed hash invalidates all responses - Network consensus requires valid proofs --- Payload Proofs: Display Convenience What They Are Payload proofs are **wallet-level tools** for showing transaction details in explorers and wallets. They're NOT used for consensus - they're just for display. **Purpose:** - Show transaction amounts in explorer - Verify receipt of funds - Sender/receiver communication How They Work The Math Check **What payload proof verification actually checks:** The verification in proof/proof.go performs a scalar multiplication to check math consistency: it takes the commitment C[position], subtracts a shared key derived from the proof, and checks whether the result equals amount × G. If the math is consistent, the amount is displayed. The critical detail: this uses ScalarMult(crypto.G, new(big.Int).SetInt64(int64(amount))) at line 98 -- the int64 cast is where the wraparound issue occurs (see Technical Cause below). **What this does NOT check:** - ❌ Whether the sender actually had that amount - ❌ Whether the sender is who they claim to be - ❌ Whether the proof was generated legitimately - ❌ Whether the amount is real vs. fabricated --- Why Payload Proofs Can Be Faked The Design Reason **Privacy by Design:** If payload proofs were cryptographically verifiable by third parties, it would break sender privacy. The entire point of ring signatures is that third parties CANNOT definitively prove who sent a transaction. How Faking Works **Anyone can create a payload proof for any ring member:** Demonstration **From security research (August 2025):** **This is not a bug - it's the consequence of privacy-preserving design.** --- Technical Cause: The int64 Cast Issue Why Fake Proofs \"Validate\" The ability to create fake proofs showing impossible amounts (like 184 trillion DERO) stems from a specific technical issue in the explorer's proof verification code. **From Source Code** (proof/proof.go:98): **The Problem:** | Input (uint64) | After int64 Cast | Result | |----------------|------------------|--------| | 100 | 100 | ✅ Normal | | 2,200,000 | 2,200,000 | ✅ Normal | | 9,223,372,036,854,775,808 (2^63) | -9,223,372,036,854,775,808 | ❌ Wraps negative | | 18,446,744,073,707,351,616 | -2,200,000 | ❌ Wraps to -2.2M | **What Happens:** Why This Doesn't Affect Protocol Security **Protocol Is Secure:** This issue only affects explorer DISPLAY. The actual transaction proofs (consensus level) use proper validation with bit decomposition that catches negative values. See Negative Transfer Protection for the mathematical proof. | Layer | Affected? | Why | |-------|-----------|-----| | **Transaction Proofs** | ❌ No | Bit decomposition catches negatives | | **Network Consensus** | ❌ No | All nodes verify with proper validation | | **Blockchain State** | ❌ No | Fake proofs don't affect state | | **Explorer Display** | ✅ Yes | Was showing fake amounts as \"verified\" | --- Explorer Mitigation The Fix To prevent explorers from displaying obviously fake amounts, validation was added to the payload proof verification. **Hologram-Exclusive:** This fix is currently only implemented in Hologram's proof validation page. The standard derohe binaries from the official DERO repository do not include this validation. Hologram is an official community project developed by DHEBP. **New Validation** (proof/proof_validation.go): **Fixed int64 Cast** (proof/proof.go:98): What This Prevents | Attack | Before Fix | After Fix | |--------|------------|-----------| | **184 trillion DERO proof** | ✓ \"Verified\" | ✗ \"Amount exceeds maximum\" | | **Wraparound to -2.2M** | ✓ \"Verified\" | ✗ \"Possible wraparound attack\" | | **100M DERO fake** | ✓ \"Verified\" | ✗ \"Exceeds reasonable maximum\" | | **Legitimate 1M DERO** | ✓ \"Verified\" | ✓ \"Verified\" | Honest Limitations **What This Cannot Prevent:** The fix blocks egregious fakes (184 trillion, negative wraparound) but cannot detect subtle fakes. A fake proof claiming 1,500 DERO instead of 1,000 DERO would still pass validation. This is a fundamental limitation of privacy-preserving design - full verification would require private keys. **What the fix CAN do:** - ✅ Block amounts > 22M DERO (above total supply) - ✅ Block amounts that would wrap to negative - ✅ Prevent the specific attack used to create false narratives - ✅ Improve user experience (no impossible amounts displayed) **What the fix CANNOT do:** - ❌ Verify the proof is genuine (would break privacy) - ❌ Detect subtle inflation (e.g., 50% fake) - ❌ Prove sender identity (by design) - ❌ Replace proper wallet verification **The Bottom Line:** This fix is a **defense-in-depth enhancement** for the display layer. It blocks the most egregious fake proofs while acknowledging that payload proofs are fundamentally unverifiable by design. For real verification, users should always check their wallet balance with their private keys. --- The Critical Difference What Each Proves **Transaction Proofs Prove:** **Payload Proofs Prove:** Verification Scope --- Implications For Users **When viewing transaction details:** - ✅ Transaction existence is real (on blockchain) - ✅ Ring members are real (from blockchain) - ⚠️ Displayed amounts may not be accurate - ⚠️ Sender attribution may be wrong **To verify you received funds:** - ✅ Check your wallet balance (decrypted with your key) - ❌ Don't rely solely on explorer display For Developers **When building on DERO:** - ✅ Trust transaction proof validity (consensus level) - ❌ Don't trust payload proof amounts (display level) - ✅ Use wallet RPC to get real balances - ❌ Don't use explorer proofs for verification logic For Analysts **When analyzing transactions:** - ⚠️ Payload proofs can be fabricated - ⚠️ Sender attribution is not cryptographically verifiable - ⚠️ Amounts shown may be manipulated - ✅ Transaction existence/validity is verifiable --- Why This Design? The Privacy Trade-off The Philosophy **Privacy Over Verification:** DERO prioritizes user privacy over third-party verification capabilities. Only YOU should be able to prove you sent a transaction. Third parties should only be able to guess. --- Key Takeaways Transaction Proofs | Aspect | Status | |--------|--------| | **Purpose** | Consensus validation | | **Verified by** | All network nodes | | **Can be faked** | No | | **Trust level** | Cryptographically secure | Payload Proofs | Aspect | Status | |--------|--------| | **Purpose** | Display convenience | | **Verified by** | Explorer/wallet UI | | **Can be faked** | Yes (by design) | | **Trust level** | Math check only | The Bottom Line --- Related: Payload Encryption (Separate Issue) **Distinct from payload proofs:** This page covers payload *proofs* (display-level, fakeable by design). A separate issue involving payload *encryption* was disclosed in May 2024 and fixed in Release142. The payload encryption issue involved **randomness reuse** between ElGamal ciphertexts and payload encryption keys. This allowed an attacker to perform trial decryption, potentially revealing sender, receiver, and amount for transactions made with vulnerable wallet software. **Key points:** - **Fixed in Release142** via ENCRYPTED_DEFAULT_PAYLOAD_CBOR_V2 - **Affected:** Wallet-layer privacy (sender/receiver/amount deanonymization) - **Not affected:** Consensus layer, ledger integrity, transaction validity - **Historical transactions** made before Release142 remain potentially affected **Recommendation:** Use Release142+ wallets for hardened payload encryption. --- Related Pages **Security Suite:** - Transaction Proofs - The six sigma system - Ring Member Behavior - Why sender can't be identified **Privacy Suite:** - Ring Signatures - Sender anonymity - Payload Proofs - Complete payload proof explanation",
+      "plainText": "Proof Types Explained **Critical Distinction:** DERO has two completely different proof systems that serve different purposes. Confusing them leads to fundamental misunderstandings about what can and cannot be verified. A transaction proof is part of the chain, verified by every node. A payload proof is a sender-supplied display string that DERO's own code calls a helper *\"to detect and decode output amount for the tx.\"* It was built to read transactions, not to prove them, which is why it's fakeable by design. The Two Proof Systems Quick Comparison | Aspect | Transaction Proofs | Payload Proofs | |--------|-------------------|----------------| | **Purpose** | Consensus validation | Display/communication | | **Verified by** | All network nodes | Explorer/wallet UI | | **Security** | Cryptographically secure | Math check only | | **Can be faked?** | Computationally infeasible | Yes (commitment-rearrangement) | | **Affects blockchain?** | Yes | No | | **Third-party verifiable?** | Yes (validity only) | No | --- Transaction Proofs: The \"Real\" Proofs What They Are Transaction proofs are the cryptographic proofs that make transactions valid. They're generated when you create a transaction and verified by every node on the network. **Components:** - Six Sigma proofs (A_y, A_D, A_b, A_X, A_t, A_u) - Inner product proof - Challenge hash binding all components How They Work Security Guarantees **Verification** (see cryptography/crypto/proof_verify.go): The Verify() function (proof_verify.go:98) recomputes the challenge hash c from all six recovered sigma components (A_y, A_D, A_b, A_X, A_t, A_u) at lines 410-425, then verifies the inner product proof at lines 457-460. If any component was tampered with, the recomputed hash won't match and Verify() returns false. **Why they can't be faked:** - All proofs are cryptographically bound - Faking one changes the hash - Changed hash invalidates all responses - Network consensus requires valid proofs --- Payload Proofs: Display Convenience What They Are Payload proofs are **wallet-level tools** for showing transaction details in explorers and wallets. They're NOT used for consensus - they're just for display. **Purpose:** - Show transaction amounts in explorer - Verify receipt of funds - Sender/receiver communication How They Work The Math Check **What payload proof verification actually checks:** The verification in proof/proof.go performs a scalar multiplication to check math consistency: it takes the commitment C[position], subtracts a shared key derived from the proof, and checks whether the result equals amount × G. If the math is consistent, the amount is displayed. The critical detail: this uses ScalarMult(crypto.G, new(big.Int).SetInt64(int64(amount))) at line 89 -- the int64 cast is where the wraparound issue occurs (see Technical Cause below). **What this does NOT check:** - ❌ Whether the sender actually had that amount - ❌ Whether the sender is who they claim to be - ❌ Whether the proof was generated legitimately - ❌ Whether the amount is real vs. fabricated --- Why fakeability isn't a flaw **Unforgeability is a deliberate property, not a default.** Building it in requires cryptographic binding (signatures or commitments tied to keys), verification by a trusted party (consensus), and a formal soundness argument. DERO's designers added that machinery where the threat model required it — transaction proofs going to chain state. Payload proofs are a sender-supplied helper for *reading* what was sent; their threat model doesn't require unforgeability, so it wasn't built in. The absence isn't a flaw — it's the natural shape of an object whose use case never demanded the property. Treating an object as if it should have a property it was never designed to have — for example, citing a \"Verified ✓\" payload proof as evidence of an on-chain mint — is a category error, not a finding. How forgery works **Anyone can create a payload proof for any ring member:** For the worked example (with the actual fake string, screenshots, and reproducible code), see Forge a Fake Proof Yourself. Demonstration **From security research (August 2025):** **This is not a bug — it's the consequence of an object built to read, not to prove.** > *The TX above (c4fbc0d5…) is an independent security-research example. The forgery walkthrough used throughout the rest of this suite — including the reproducible Go code, the bech32 decode, and the patched-vs-unpatched explorer screenshots — is built around a different transaction (5bbe1b7e…) and lives at Inflation Claim § Part 3 — Forge a Fake Proof Yourself. Both transactions illustrate the same phenomenon: a payload proof is a user-supplied display object, not consensus state.* --- Technical Cause: The int64 Cast Issue Why Fake Proofs \"Validate\" The ability to create fake proofs showing impossible amounts (like 184 trillion DERO) stems from a specific technical issue in the explorer's proof verification code. **From Source Code** (proof/proof.go:89): **The Problem:** | Input (uint64) | After int64 Cast | Result | |----------------|------------------|--------| | 100 | 100 | ✅ Normal | | 2,200,000 | 2,200,000 | ✅ Normal | | 9,223,372,036,854,775,808 (2^63) | -9,223,372,036,854,775,808 | ❌ Wraps negative | | 18,446,744,073,707,351,616 | -2,200,000 | ❌ Wraps to -2.2M | **What Happens:** Why This Doesn't Affect Protocol Security **Protocol Is Secure:** This issue only affects explorer DISPLAY. The actual transaction proofs (consensus level) are enforced by bulletproof soundness — the verifier rejects any committed value outside the proven range, including negative/wraparound amounts. See Negative Transfer Protection for the mathematical proof. | Layer | Affected? | Why | |-------|-----------|-----| | **Transaction Proofs** | ❌ No | Bulletproof soundness rejects out-of-range commitments | | **Network Consensus** | ❌ No | All nodes verify with proper validation | | **Blockchain State** | ❌ No | Fake proofs don't affect state | | **Explorer Display** | ✅ Yes | Was showing fake amounts as \"verified\" | --- Explorer Mitigation The Fix To prevent explorers from displaying obviously fake amounts, validation was added to the payload proof verification. **Where this lives:** Hologram's proof validation page, and — since PR #14 landed — DEROFDN/derohe community-dev. The upstream main branch and other unpatched explorers do not include this validation. Hologram is an official community project developed by DHEBP. **New Validation** (proof/proof_validation.go): **Fixed int64 Cast** (proof/proof.go:89): What This Prevents | Attack | Before Fix | After Fix | |--------|------------|-----------| | **184 trillion DERO proof (wraparound display)** | ✓ \"Verified\" | ✗ \"Possible wraparound attack\" | | **Negative amount wrapping to large positive (e.g., −1 DERO → 184 trillion display)** | ✓ \"Verified\" | ✗ \"Possible wraparound attack\" | | **Legitimate 1M DERO** | ✓ \"Verified\" | ✓ \"Verified\" | Honest Limitations **What This Cannot Prevent:** The fix blocks egregious fakes (184 trillion, negative wraparound) but cannot detect subtle fakes. A fake proof claiming 1,500 DERO instead of 1,000 DERO would still pass validation. This is a fundamental limitation of privacy-preserving design - full verification would require private keys. **What the fix CAN do:** - ✅ Block amounts large enough to trigger int64 wraparound (the actual demonstrated attack) - ✅ Block amounts that would wrap from negative back to an enormous positive display - ✅ Prevent the specific attack used to create false narratives - ✅ Improve user experience (no impossible amounts displayed) **What the fix CANNOT do:** - ❌ Verify the proof is genuine (would break privacy) - ❌ Detect subtle inflation (e.g., 50% fake) - ❌ Prove sender identity (by design) - ❌ Replace proper wallet verification **The Bottom Line:** This fix is a **defense-in-depth enhancement** for the display layer. It blocks the most egregious fake proofs while acknowledging that payload proofs are fundamentally forgeable as currently constructed — the commitment-rearrangement trick lets any ring member's commitment match any amount. For real verification, users should always check their wallet balance with their private keys. --- The Critical Difference What Each Proves **Transaction Proofs Prove:** **Payload Proofs Prove:** Verification Scope --- Implications For Users **When viewing transaction details:** - ✅ Transaction existence is real (on blockchain) - ✅ Ring members are real (from blockchain) - ⚠️ Displayed amounts may not be accurate - ⚠️ Sender attribution may be wrong **To verify you received funds:** - ✅ Check your wallet balance (decrypted with your key) - ❌ Don't rely solely on explorer display For Developers **When building on DERO:** - ✅ Trust transaction proof validity (consensus level) - ❌ Don't trust payload proof amounts (display level) - ✅ Use wallet RPC to get real balances - ❌ Don't use explorer proofs for verification logic For Analysts **When analyzing transactions:** - ⚠️ Payload proofs can be fabricated - ⚠️ Sender attribution is not cryptographically verifiable - ⚠️ Amounts shown may be manipulated - ✅ Transaction existence/validity is verifiable --- Key Takeaways Transaction Proofs | Aspect | Status | |--------|--------| | **Purpose** | Consensus validation | | **Verified by** | All network nodes | | **Can be faked** | No | | **Trust level** | Cryptographically secure | Payload Proofs | Aspect | Status | |--------|--------| | **Purpose** | Display convenience | | **Verified by** | Explorer/wallet UI | | **Can be faked** | Yes (commitment-rearrangement) | | **Trust level** | Math check only | The Bottom Line --- Related: Payload Encryption (Separate Issue) **Distinct from payload proofs:** This page covers payload *proofs* (display-level, fakeable due to the commitment-rearrangement construction). A separate issue involving payload *encryption* was disclosed in May 2024 and fixed in Release142. The payload encryption issue involved **randomness reuse** between ElGamal ciphertexts and payload encryption keys. This allowed an attacker to perform trial decryption, potentially revealing sender, receiver, and amount for transactions made with vulnerable wallet software. **Key points:** - **Fixed in Release142** via ENCRYPTED_DEFAULT_PAYLOAD_CBOR_V2 - **Affected:** Wallet-layer privacy (sender/receiver/amount deanonymization) - **Not affected:** Consensus layer, ledger integrity, transaction validity - **Historical transactions** made before Release142 remain potentially affected **Recommendation:** Use Release142+ wallets for hardened payload encryption. --- Related Pages **Security Suite:** - Transaction Proofs - The six sigma system - Ring Member Behavior - Why sender can't be identified **Privacy Suite:** - Ring Signatures - Sender anonymity - Payload Proofs - Complete payload proof explanation",
       "lastUpdated": "2026-02-06"
     },
     {
@@ -969,7 +993,7 @@
       "slug": "integrity/proof-verification-flow",
       "title": "Proof Verification Flow: End-to-End Transaction Validation | DERO Blockchain",
       "description": "Complete walkthrough of how DERO validates transactions from creation through network acceptance - every step of the cryptographic verification process.",
-      "canonicalUrl": "https://derod.org/integrity/proof-verification-flow",
+      "canonicalUrl": "https://derod.org/integrity/proof-verification-flow.md",
       "sourcePath": "derod-main/pages/integrity/proof-verification-flow.mdx",
       "headings": [
         "Proof Verification Flow",
@@ -977,7 +1001,7 @@
         "Phase 1: Transaction Creation (Wallet)",
         "Step 1.1: Prepare Transaction Data",
         "Step 1.2: Generate Proofs",
-        "Step 1.3: Bit Decomposition (Critical Security Point)",
+        "Step 1.3: Where the actual safeguard lives",
         "Phase 2: Network Broadcast",
         "Step 2.1: TLS Encryption",
         "Step 2.2: Basic Format Check",
@@ -1002,54 +1026,38 @@
         "Why Invalid Transactions Cannot Succeed",
         "Related Pages"
       ],
-      "plainText": "Proof Verification Flow **End-to-End Security:** Every transaction goes through a complete verification pipeline - from wallet creation through network validation to blockchain acceptance. This page traces the entire journey. The Complete Flow --- Phase 1: Transaction Creation (Wallet) Step 1.1: Prepare Transaction Data **What happens in the wallet** (see walletapi/wallet_transfer.go): 1. **Check balance** -- Retrieve the sender's current encrypted balance from the daemon 2. **Select ring members** -- Request random addresses from the daemon to form the ring (decoys) 3. **Create transfer commitment** -- Encrypt the transfer amount using the recipient's public key 4. **Proceed to proof generation** -- Build the cryptographic proofs for the transaction Step 1.2: Generate Proofs **The proof generation sequence:** **Source:** cryptography/crypto/proof_generate.go The proof generation function builds all components in sequence: 1. **Create commitments** for each sigma proof component (A_y, A_D, A_b, A_X, A_t, A_u) 2. **Bit decomposition** occurs during A_t construction (lines 468-487) -- this is where negative amounts are caught 3. **Compute challenge hash** binding all six components together via reducedhash() 4. **Generate responses** (s_y, s_D, etc.) using the challenge c and secret values 5. **Generate inner product proof** for the bulletproof range verification Step 1.3: Bit Decomposition (Critical Security Point) **This is where negative amounts are caught.** The amount is converted to binary via Go's BigInt.Text(2). For negative values, this always returns a string starting with -, which breaks the bit processing loop expecting only '0' or '1'. **Key Point:** Invalid transactions cannot even be created. The wallet cannot generate a valid proof for negative amounts. **Full technical details →** --- Phase 2: Network Broadcast Step 2.1: TLS Encryption **From Source Code** (p2p/controller.go): Step 2.2: Basic Format Check **Before full verification, nodes do quick sanity checks:** - Transaction size is within acceptable limits - Required proof fields are present and properly formatted - Basic structural validity (correct number of payloads, ring sizes within MIN_RINGSIZE/MAX_RINGSIZE from config/config.go) If format checks fail, the transaction is rejected immediately without proceeding to expensive cryptographic verification. --- Phase 3: Full Verification **Five Highlighted Checkpoints:** The verification process includes many checks. Below are five key checkpoints that must pass. Failure at any checkpoint results in immediate rejection. The Five Verification Checkpoints --- Checkpoint 1: Overflow Protection **Location:** proof_verify.go:108-110 **What it catches:** Arithmetic overflow attacks that could manipulate transaction fees. **Learn more →** --- Checkpoint 2: Parity Check **Location:** proof_verify.go:136-141 **What it catches:** Invalid sender index encoding. The parity check ensures the prover knows which ring member position they occupy without revealing it. **Why it matters:** In a ring signature, the real sender's position is hidden among decoys. The parity check cryptographically verifies the prover knows their position without revealing which one it is. This check is the verification-side counterpart of the parity constraint enforced at transaction build time — sender and receiver must occupy indices of different parity (one even, one odd), splitting the ring evenly between potential senders and potential recipients. See The Parity Constraint for the full structural explanation. --- Checkpoint 3: B^w × A Recovery **Location:** proof_verify.go:162-179 **What it catches:** Malformed proof structure. This verifies the polynomial commitment structure is consistent. --- Checkpoint 4: Challenge Hash Verification **Location:** proof_verify.go:410-425 **What it catches:** Any tampering with proof components. If ANY proof element was modified, the challenge hash won't match. --- Checkpoint 5: Inner Product Verification **Location:** proof_verify.go:457-459 **What it catches:** Invalid range proofs, forged bit commitments, and any cryptographic inconsistency in the bulletproof. --- Step 3.1: Recompute Challenge Hash **The verifier recomputes the challenge from the submitted proofs.** From proof_verify.go:410-425, the verifier builds an input byte array from all six recovered sigma components (A_y, A_D, A_b, A_X, A_t, A_u), then runs reducedhash() over them. The result must match the proof.c value submitted with the transaction: If any proof component was tampered with, the recomputed hash won't match proof.c, and verification fails. Step 3.2: Verify Each Proof **A_y: Secret Key Proof** Uses Schnorr-style verification: checks that the response s_y is consistent with the commitment A_y, the challenge c, and the sender's public key. This proves the sender possesses the private key without revealing it. **What it proves:** Sender owns the funds **A_D: Balance Update Proof** Verifies that the encrypted balance update is mathematically correct using homomorphic properties: E(old_balance) - E(amount) = E(new_balance). The verification checks this relationship holds without decrypting any values. **What it proves:** Balance math is correct (old - amount = new) **A_t: Range Proof** The bulletproof range proof component. Validates that the combined 128-bit value (transfer amount in lower 64 bits + remaining balance in upper 64 bits) is within valid range. This is where bit decomposition, bit commitments, and range bounds are all verified. **What it proves:** Amount is valid (not negative, not overflow) **Full technical details →** **Inner Product Proof** The final cryptographic check. From proof_verify.go:457-459: This recursively verifies that the bit vectors, commitments, and all proof components are cryptographically consistent. Uses 7 rounds of halving (from proof_innerproduct.go:71: length := 7) to verify 128 bits. **What it proves:** All components are cryptographically consistent Step 3.3: All-or-Nothing Decision **Key Point:** ALL proofs must pass. There is no \"partial acceptance.\" --- Phase 4: Blockchain Acceptance Step 4.1: Mempool Addition Before a transaction enters the mempool, the node: 1. **Full verification** -- Runs the complete Verify() function from proof_verify.go (all checkpoints must pass) 2. **Duplicate check** -- Ensures the transaction isn't already in the mempool 3. **State check** -- Confirms the transaction is valid against current chain state 4. **Add to mempool** -- Transaction is queued for inclusion in a future block Step 4.2: Block Inclusion Step 4.3: State Update Once a transaction is included in a block, the state is updated (see blockchain/transaction_execute.go): 1. **Update encrypted balances** -- For each ring member, the encrypted balance is updated using ElGamal.Add() from cryptography/crypto/algebra_elgamal.go:69. All ring members' encrypted balances change (see Ring Member Behavior), but only the real sender/receiver's decrypted balance changes. 2. **Record the transaction** -- The transaction is committed to the chain state via Graviton (DERO's key-value store). --- Security at Each Phase | Phase | What's Checked | Attack Prevented | |-------|---------------|------------------| | **Creation** | Bit decomposition | Negative amounts | | **Broadcast** | TLS encryption | Network snooping | | **Verification** | All proofs | Forgery, transaction replay | | **Acceptance** | Consensus | Byzantine actors | --- Verification Order | Step | What Happens | |------|-------------| | **Format check** | Basic structural validation (field counts, size limits, parity) | | **Proof verification** | All six sigma proofs recovered and challenge hash recomputed | | **Inner product** | Recursive 7-round inner product proof verified (bulletproof sub-component of A_t) | | **Consensus** | Transaction included in next block (~18s block time from config/config.go:34) | > **Note:** No official benchmarks exist for per-step verification times. The codebase does not include benchmark tests. Actual performance depends on hardware and ring size. --- Key Takeaways The Verification Guarantee Why Invalid Transactions Cannot Succeed **Multiple Barriers:** Invalid transactions face multiple independent barriers. They can't be created (bit decomposition), can't be verified (proof system), and can't be accepted (consensus). Each barrier is independently sufficient. --- Related Pages **Security Suite:** - Transaction Proofs - The six sigma system - Range Proof Integrity - Triple-layer defense - Network Consensus - Distributed validation **Technical Reference:** - Daemon RPC API - Transaction submission - Wallet RPC API - Transaction creation",
+      "plainText": "Proof Verification Flow **End-to-End Security:** Every transaction goes through a complete verification pipeline - from wallet creation through network validation to blockchain acceptance. This page traces the entire journey. The Complete Flow --- Phase 1: Transaction Creation (Wallet) Step 1.1: Prepare Transaction Data **What happens in the wallet** (see walletapi/wallet_transfer.go): 1. **Check balance** -- Retrieve the sender's current encrypted balance from the daemon 2. **Select ring members** -- Request random addresses from the daemon to form the ring (decoys) 3. **Create transfer commitment** -- Encrypt the transfer amount using the recipient's public key 4. **Proceed to proof generation** -- Build the cryptographic proofs for the transaction Step 1.2: Generate Proofs **The proof generation sequence:** **Source:** cryptography/crypto/proof_generate.go The proof generation function builds all components in sequence: 1. **Create commitments** for each sigma proof component (A_y, A_D, A_b, A_X, A_t, A_u) 2. **Packing + bit decomposition** during the bulletproof input setup: the packing step number := btransfer.Add(btransfer, bdiff.Lsh(bdiff, 64)) is at proof_generate.go:468-471; the bit-decomposition loop (number_string reversal + aL / aR for-loop) is at proof_generate.go:473-487. Together they encode the packed 128-bit value as the bit vectors the bulletproof commits to. 3. **Compute challenge hash** binding all six components together via reducedhash() 4. **Generate responses** (s_y, s_D, etc.) using the challenge c and secret values 5. **Generate inner product proof** for the bulletproof range verification Step 1.3: Where the actual safeguard lives The wallet's bit decomposition above is **proof construction**, not protection. A malicious sender controls their own wallet and could patch any client-side check. The cryptographic guarantee for non-negative amounts comes from the **verifier's** bulletproof check that every node runs in Phase 3 — by bulletproof soundness, no prover can construct a verifying proof for an out-of-range committed value. **Full derivation →** --- Phase 2: Network Broadcast Step 2.1: TLS Encryption **From Source Code** (p2p/controller.go): Step 2.2: Basic Format Check **Before full verification, nodes do quick sanity checks:** - Transaction size is within acceptable limits - Required proof fields are present and properly formatted - Basic structural validity (correct number of payloads, ring sizes within MIN_RINGSIZE/MAX_RINGSIZE from config/config.go) If format checks fail, the transaction is rejected immediately without proceeding to expensive cryptographic verification. --- Phase 3: Full Verification **Five Highlighted Checkpoints:** The verification process includes many checks. Below are five key checkpoints that must pass. Failure at any checkpoint results in immediate rejection. The Five Verification Checkpoints --- Checkpoint 1: Overflow Protection **Location:** proof_verify.go:108-111 **What it catches:** Arithmetic overflow attacks that could manipulate transaction fees. **Learn more →** --- Checkpoint 2: Parity Check **Location:** proof_verify.go:136-141 **What it catches:** Invalid sender index encoding. The parity check ensures the prover knows which ring member position they occupy without revealing it. **Why it matters:** In a ring signature, the real sender's position is hidden among decoys. The parity check cryptographically verifies the prover knows their position without revealing which one it is. This check is the verification-side counterpart of the parity constraint enforced at transaction build time — sender and receiver must occupy indices of different parity (one even, one odd), splitting the ring evenly between potential senders and potential recipients. See The Parity Constraint for the full structural explanation. --- Checkpoint 3: B^w × A Recovery **Location:** proof_verify.go:162-179 **What it catches:** Malformed proof structure. This verifies the polynomial commitment structure is consistent. --- Checkpoint 4: Challenge Hash Verification **Location:** proof_verify.go:410-425 **What it catches:** Any tampering with proof components. If ANY proof element was modified, the challenge hash won't match. --- Checkpoint 5: Inner Product Verification **Location:** proof_verify.go:457-459 **What it catches:** Invalid range proofs, forged bit commitments, and any cryptographic inconsistency in the bulletproof. --- Step 3.1: Recompute Challenge Hash **The verifier recomputes the challenge from the submitted proofs.** From proof_verify.go:410-425, the verifier builds an input byte array from all six recovered sigma components (A_y, A_D, A_b, A_X, A_t, A_u), then runs reducedhash() over them. The result must match the proof.c value submitted with the transaction: If any proof component was tampered with, the recomputed hash won't match proof.c, and verification fails. Step 3.2: Verify Each Proof **A_y: Secret Key Proof** Uses Schnorr-style verification: checks that the response s_y is consistent with the commitment A_y, the challenge c, and the sender's public key. This proves the sender possesses the private key without revealing it. **What it proves:** Sender owns the funds **A_D: Balance Update Proof** Verifies that the encrypted balance update is mathematically correct using homomorphic properties: E(old_balance) - E(amount) = E(new_balance). The verification checks this relationship holds without decrypting any values. **What it proves:** Balance math is correct (old - amount = new) **A_t: Range Proof** The bulletproof range proof component. Commits the combined 128-bit value (transfer amount in lower 64 bits + remaining balance in upper 64 bits) as a bit decomposition, along with the structural commitments the verifier needs. The actual range check is closed by the inner product proof (next tab) — by bulletproof soundness, that closure rejects any committed value outside the proven range. **What it proves:** Amount is valid (not negative, not overflow) **Full technical details →** **Inner Product Proof (closes A_t)** The recursive closure of the A_t bulletproof. From proof_verify.go:457-459: This is the bulletproof sub-protocol that completes A_t's range check. Uses 7 rounds of halving (from proof_innerproduct.go:71: length := 7) to verify the 128-bit range constraint. The IP argument and A_t are not independent checks — passing the IP is what makes A_t valid. **What it proves:** A_t's range constraint holds (by bulletproof soundness, no out-of-range value can produce a passing IP proof) Step 3.3: All-or-Nothing Decision **Key Point:** ALL proofs must pass. There is no \"partial acceptance.\" --- Phase 4: Blockchain Acceptance Step 4.1: Mempool Addition Before a transaction enters the mempool, the node: 1. **Full verification** -- Runs the complete Verify() function from proof_verify.go:98 (all checkpoints must pass) 2. **Duplicate check** -- Ensures the transaction isn't already in the mempool 3. **State check** -- Confirms the transaction is valid against current chain state 4. **Add to mempool** -- Transaction is queued for inclusion in a future block Step 4.2: Block Inclusion Step 4.3: State Update Once a transaction is included in a block, the state is updated (see blockchain/transaction_execute.go): 1. **Update encrypted balances** -- For each ring member, the encrypted balance is updated using ElGamal.Add() from cryptography/crypto/algebra_elgamal.go:69. All ring members' encrypted balances change (see Ring Member Behavior), but only the real sender/receiver's decrypted balance changes. 2. **Record the transaction** -- The transaction is committed to the chain state via Graviton (DERO's key-value store). --- Security at Each Phase | Phase | What's Checked | Attack Prevented | |-------|---------------|------------------| | **Creation** | Proof construction (wallet-side) | None on its own — an attacker controls their wallet | | **Broadcast** | TLS encryption | Network snooping | | **Verification** | All proofs (incl. bulletproof soundness) | Forgery, transaction replay, negative/out-of-range amounts | | **Acceptance** | Consensus | Byzantine actors | --- Verification Order | Step | What Happens | |------|-------------| | **Format check** | Basic structural validation (field counts, size limits, parity) | | **Proof verification** | All six sigma proofs recovered and challenge hash recomputed | | **Inner product** | Recursive 7-round inner product proof verified (bulletproof sub-component of A_t) | | **Consensus** | Transaction included in next block (~18s block time from config/config.go:34) | > **Note:** No official benchmarks exist for per-step verification times. The codebase does not include benchmark tests. Actual performance depends on hardware and ring size. --- Key Takeaways The Verification Guarantee Why Invalid Transactions Cannot Succeed **Verifier-enforced, then consensus-confirmed:** Invalid transactions are rejected by the verifier itself, regardless of what the sender's wallet does. Every node independently re-runs the proof system; by bulletproof soundness, no out-of-range or negative committed value can produce a passing proof. Consensus then ensures all honest nodes agree on the outcome. --- Related Pages **Security Suite:** - Transaction Proofs - The six sigma system - Range Proof Integrity - 128-bit range proof closed at the verifier - Network Consensus - Distributed validation **Technical Reference:** - Daemon RPC API - Transaction submission - Wallet RPC API - Transaction creation",
       "lastUpdated": "2026-02-06"
     },
     {
       "product": "derod",
       "slug": "integrity/range-proof-integrity",
-      "title": "Range Proof Integrity: DERO's Triple-Layer Defense | DERO Blockchain",
-      "description": "Technical deep dive into how DERO's bulletproof implementation provides triple-layer protection against invalid amounts through bit decomposition, range proofs, and inner product verification.",
-      "canonicalUrl": "https://derod.org/integrity/range-proof-integrity",
+      "title": "Range Proof Integrity: How DERO's Bulletproof Binds Amounts | DERO Blockchain",
+      "description": "Every DERO transfer carries a 128-bit Bulletproof range proof that binds the transfer amount and remaining balance to non-negative 64-bit ranges. Enforced independently by every node — out-of-range values cannot produce a verifying proof.",
+      "canonicalUrl": "https://derod.org/integrity/range-proof-integrity.md",
       "sourcePath": "derod-main/pages/integrity/range-proof-integrity.mdx",
       "headings": [
-        "Range Proof Integrity: Triple-Layer Defense",
-        "What Problem Does Range Proof Integrity Solve?",
-        "The Three Layers",
-        "Layer 1: Bit Decomposition",
-        "How It Works",
-        "Why Negatives Fail",
-        "The 128-Bit Combined Range Proof",
-        "Layer 2: Range Proof (A_t)",
-        "What A_t Validates",
-        "How It Works",
-        "If Layer 1 Fails",
-        "Layer 3: Inner Product Proof",
-        "The Cryptographic Fail-Safe",
-        "The Recursive Algorithm",
-        "Why It's a Fail-Safe",
-        "The Complete Protection Chain",
-        "Verification: How to Confirm",
-        "Method 1: Test Go Behavior (1 minute)",
-        "Method 2: Review Source Code",
-        "View the critical code",
-        "Security Guarantees",
-        "What's Protected",
-        "Attack Impossibility",
-        "Key Takeaways",
-        "The Triple-Layer Guarantee",
-        "Why This Matters",
+        "Range Proof Integrity",
+        "What the range proof proves",
+        "The cryptographic guarantee",
+        "Where the guarantee actually lives",
+        "How the Bulletproof verification works",
+        "The recursive inner product",
+        "Verify it yourself",
+        "The 128-bit packing (proof generation)",
+        "The verification every node runs (the actual enforcement)",
+        "The recursive inner product algorithm",
         "Related Pages"
       ],
-      "plainText": "Range Proof Integrity: Triple-Layer Defense **Triple Protection:** Three independent layers ensure amounts are always valid. Layer 1 catches issues at bit decomposition. Layer 2 validates the range. Layer 3 provides a cryptographic fail-safe. All three must pass. What Problem Does Range Proof Integrity Solve? **The Challenge:** **The Solution: Triple-Layer Defense** - ✅ Layer 1: Bit decomposition catches negatives at string level - ✅ Layer 2: Range proof (A_t) validates mathematical range - ✅ Layer 3: Inner product proof provides cryptographic guarantee --- The Three Layers --- Layer 1: Bit Decomposition How It Works Layer 1 converts the 128-bit combined value (transfer + balance) into binary and processes each bit. The key protection: **Go's BigInt.Text(2) always prepends a - character for negative values**, which breaks the bit processing loop that expects only '0' or '1'. **Source:** cryptography/crypto/proof_generate.go:468-487 **Full Technical Details:** For the complete code walkthrough, Go stdlib guarantees, and verification tests, see Negative Transfer Protection. Why Negatives Fail | Input | Binary String | First Char | Result | |-------|---------------|------------|--------| | 100 | \"1100100\" | '1' (ASCII 49) | ✅ Valid bit | | -100 | \"-1100100\" | '-' (ASCII 45) | ❌ Invalid - proof fails | The bit processing loop expects only '0' (48) or '1' (49). The minus sign character '-' (45) creates a malformed bit vector, causing downstream proof verification to fail. --- The 128-Bit Combined Range Proof **Dual Validation:** DERO's range proof validates TWO values simultaneously in a single 128-bit proof: the transfer amount (lower 64 bits) AND the remaining balance (upper 64 bits). This proves both values are non-negative in one efficient proof. **From Source Code** (proof_generate.go:471): **What This Means:** --- Layer 2: Range Proof (A_t) What A_t Validates How It Works **Mathematical Structure:** If Layer 1 Fails **Source:** cryptography/crypto/proof_generate.go - A_t generation --- Layer 3: Inner Product Proof The Cryptographic Fail-Safe **Purpose:** Ensures complete integrity across all proof components using recursive verification. **From Source Code** (cryptography/crypto/proof_innerproduct.go): The Recursive Algorithm **At each step:** - Create commitments L and R - Derive challenge from hash - Fold vectors in half - Repeat until single element Why It's a Fail-Safe **Even if Layers 1 and 2 were somehow bypassed:** --- The Complete Protection Chain --- Verification: How to Confirm Method 1: Test Go Behavior (1 minute) **Expected Output:** Method 2: Review Source Code **Look for:** - Line 473: number.Text(2) call - Line 476: Comment \"convert the amount to make sure it cannot be negative\" - Lines 479-487: Bit processing loop expecting '0' and '1' --- Security Guarantees What's Protected | Threat | Layer | How It's Blocked | |--------|-------|------------------| | **Negative amounts** | Layer 1 | '-' character detected in bit string | | **Overflow amounts** | Layer 2 | Range proof validates the 128-bit combined value with 64-bit bounds | | **Forged proofs** | Layer 3 | Inner product verification fails | | **Partial forgery** | All | All layers must pass | Attack Impossibility **To create a negative transfer, attacker would need to:** 1. Create negative BigInt value → **Layer 1 blocks** (detects '-') 2. Somehow bypass Layer 1 → **Layer 2 blocks** (invalid commitments) 3. Somehow bypass Layers 1 & 2 → **Layer 3 blocks** (inner product mismatch) 4. Somehow bypass all layers → **Network consensus blocks** (all nodes verify) **Each layer is independently sufficient to prevent the attack.** --- Key Takeaways The Triple-Layer Guarantee | Layer | What It Checks | Why It's Sufficient | |-------|---------------|---------------------| | **Layer 1** | Bit string format | Go stdlib guarantee | | **Layer 2** | Mathematical range | Bulletproof security | | **Layer 3** | Cryptographic integrity | Recursive verification | Why This Matters **Defense in Depth:** Even if one layer had a theoretical weakness, the other layers provide independent protection. This is not \"belt and suspenders\" - it's three completely independent mathematical guarantees. **Mathematical Certainty:** Negative transfers are not \"difficult\" to create - they are mathematically impossible. The bit decomposition mechanism makes it as impossible as dividing by zero. --- Related Pages **Security Suite:** - Negative Transfer Protection - Detailed impossibility proof - Transaction Proofs - Six sigma proof system - Proof Verification Flow - Complete verification process **Privacy Suite:** - Bulletproofs - Zero-knowledge range proofs - Homomorphic Encryption - Encrypted operations",
-      "lastUpdated": "2025-01-26"
+      "plainText": "Range Proof Integrity **What the range proof binds:** Every DERO transfer carries a Bulletproof range proof. One proof binds **two** quantities — the transfer amount and the sender's remaining balance — to non-negative 64-bit ranges. Every node verifies the proof independently. By the soundness of Bulletproofs, an out-of-range value cannot produce a proof that verifies. What the range proof proves DERO packs **two** quantities into a single 128-bit value and range-proves them together. The packing step is at cryptography/crypto/proof_generate.go:468-471 and the bit-decomposition loop that feeds the bulletproof is at proof_generate.go:473-487: The trailing // this should be reduced comments are the DERO author's own forensic note in source — flagging that reduction modulo the bn256 group order should be applied to these inputs. They are preserved verbatim here because they carry that authorial signal. So one Bulletproof establishes **both**: - the **transfer amount** is a valid non-negative 64-bit number (low 64 bits), and - the sender's **remaining balance** is a valid non-negative 64-bit number (high 64 bits). **Why both matter:** proving only the amount is non-negative would not stop an overspend. By also proving the remaining balance is non-negative, the same proof guarantees you cannot send more than you hold — and cannot manufacture a balance by sending a \"negative\" amount. --- The cryptographic guarantee By the **computational soundness** of Bulletproofs — under the discrete-log assumption on the bn256 curve, in the random oracle model (Fiat-Shamir) — no prover can construct a proof that *verifies* for a committed value outside the proven range, except with negligible probability bounded by the underlying hardness. Combined with DERO's homomorphic accounting (inputs and outputs bound to balance exactly), value cannot be created from nothing. See Cryptographic Assumptions for the full assumption stack. A \"negative\" transfer is the uint64 wraparound of a value near 2^64. It fails the range proof from both directions: | Attack framing | Why the range proof rejects it | |---|---| | Treat the wraparound as the **transfer amount** | A value near 2^64 lies outside 0, 2^64) — the low-64 range bound fails. | | Treat it as **receiving** (so your own balance jumps) | The conservation proof forces a matching decrease; the sender's **remaining balance** goes negative → wraps → the high-64 range bound fails. | There is no \"almost in range,\" no rounding, no edge case: either a verifying proof exists (value in range) or it does not. Full soundness derivation and the canonical refutation of the \"minus sign breaks the bit loop\" misconception: [Negative Transfer Protection. --- Where the guarantee actually lives The protection lives in **verification**, not generation. The wallet builds the proof in proof_generate.go; an attacker controls their own wallet and could patch out any client-side check. The cryptographic guarantee comes from proof_verify.go, which every node runs independently before accepting a block. | Layer | What runs | Who controls it | Is this the safeguard? | |---|---|---|---| | Wallet proof generation | proof_generate.go | Sender (attacker if malicious) | No — can be patched by the attacker | | Node proof verification | proof_verify.go | Every validating node | **Yes** — soundness ensures rejection of out-of-range proofs | A common misconception holds that Go's BigInt.Text(2) emitting a '-' for negative values \"breaks the bit loop\" in proof generation, and that this is what stops negative transfers. It does not. The loop is if b == '1' { … } else { … } — a stray '-' byte is silently treated as a 0 bit, not rejected. And for any real transaction, the packed 128-bit number is positive, so Text(2) produces no '-' at all. See Negative Transfer Protection for the full teardown. --- How the Bulletproof verification works The Bulletproof proves the 128-bit committed value is in range by decomposing it into 128 bits, committing to two vectors derived from those bits, and proving in zero knowledge that each component is a single bit and that the bits reconstruct the committed value. The verification reduces this to a single inner-product check using a recursive halving algorithm — what makes the proof logarithmic in size. The recursive inner product **At each step:** - Create commitments L and R - Derive challenge from hash - Fold vectors in half - Repeat until a single element remains (log₂(128) = 7 rounds, cryptography/crypto/proof_innerproduct.go) If the final inner product does not match the committed value, the check at proof_verify.go:457-460 fails — and the transaction is rejected at consensus. --- Verify it yourself For the soundness argument and the proof that out-of-range values cannot produce a verifying proof, see Negative Transfer Protection. --- Related Pages **Security suite:** - Negative Transfer Protection — soundness derivation, misconception teardown - Transaction Proofs — the full proof set every node checks - Proof Verification Flow — end-to-end validation - Inflation Claim — what the 2022 case actually shows **Privacy suite:** - Bulletproofs — zero-knowledge range proofs",
+      "lastUpdated": "2026-05-26"
     },
     {
       "product": "derod",
       "slug": "integrity/ring-member-behavior",
       "title": "Ring Member Behavior: Understanding Decoy Participation | DERO Blockchain",
       "description": "Technical explanation of why ring members' encrypted balances change even as decoys - this is normal behavior by design, not a protocol anomaly.",
-      "canonicalUrl": "https://derod.org/integrity/ring-member-behavior",
+      "canonicalUrl": "https://derod.org/integrity/ring-member-behavior.md",
       "sourcePath": "derod-main/pages/integrity/ring-member-behavior.mdx",
       "headings": [
         "Ring Member Behavior",
@@ -1090,7 +1098,7 @@
         "For Analysts",
         "Related Pages"
       ],
-      "plainText": "Ring Member Behavior **Critical Understanding:** Encrypted balance changes occur for ALL ring members in a transaction, including decoys. This is **by design** - it's how ring signatures provide plausible deniability. Observing a balance change does NOT mean an address was the sender. The Core Mechanism How Ring Signatures Work When Alice sends DERO to Bob: Why Decoy Balances Change **From Source Code** (walletapi/daemon_communication.go:863-903): **Key Insight:** The encrypted balance data changes for ALL ring members, but only the real sender's *decrypted* balance actually changes. --- The Two Types of Balance Changes Encrypted vs. Decrypted **Encrypted Balance (66 bytes)** **Decrypted Balance (Only Owner Sees)** --- Why This Design? The Privacy Guarantee **The key insight:** If only the real sender's encrypted balance changed, an observer could identify them immediately. By having all ring members' encrypted balances change, the sender remains hidden. Plausible Deniability **Legal Protection:** If accused of sending a transaction, you can truthfully say: \"My encrypted balance changed, but that only means I was in the ring. Any of the 8 potential senders in this ring could be the real sender.\" This is cryptographically provable. --- What Balance Changes Mean Interpretation Guide | Observation | What It Means | What It Doesn't Mean | |-------------|--------------|---------------------| | **Encrypted balance unchanged** | Address not in ANY ring | - | | **Encrypted balance changed** | Address was in a ring | ≠ Address was sender | | **Multiple changes over time** | Address in multiple rings | ≠ Address sent multiple times | | **Decrypted balance unchanged** | Was decoy (owner can verify) | Only owner knows this | | **Decrypted balance changed** | Was real sender (owner can verify) | Only owner knows this | The Unchanged Balance Test **If encrypted balance is unchanged for X blocks:** **This is powerful evidence** - unchanged encrypted balance definitively proves no involvement. --- Ring Member Selection How Decoys Are Chosen **From Source Code** (cmd/derod/rpc/rpc_dero_getrandomaddress.go): Selection Criteria | Requirement | Reason | |-------------|--------| | **Unchanged balance (5 blocks)** | Better decoys | | **Random selection** | Prevents targeting | | **Multiple candidates** | Ensures diversity | --- Example: Tracing a Transaction The Scenario What an Observer Sees What Each Owner Sees --- Sender vs. Decoy: How to Verify Method 1: Decrypt Balance (Owner Only) The wallet performs this check automatically. From walletapi/daemon_communication.go:900-903: The wallet decrypts the balance before and after the transaction using the owner's private key. If the decrypted balance is unchanged, you were a decoy. If it decreased, you were the sender. Method 2: Check Wallet History (Owner Only) Method 3: External Observation (IMPOSSIBLE) --- Common Misconceptions Misconception 1: \"Balance change = sent transaction\" **Reality:** Balance change only means the address was in a ring. Could be sender OR decoy. Misconception 2: \"Can track senders by balance changes\" **Reality:** All ring members' balances change. Tracking balance changes tracks ring membership, not sending. Misconception 3: \"Unchanged balance = received\" **Reality:** Unchanged encrypted balance = no involvement at all (not sending, not receiving, not in any ring). Misconception 4: \"Third parties can verify sender\" **Reality:** Only the owner (with private key) can determine if they were sender or decoy. This is privacy by design. --- Security Implications What This Protects | Threat | How Ring Member Behavior Helps | |--------|-------------------------------| | **Sender identification** | All ring members look the same | | **Transaction linking** | Each TX has independent ring | | **Balance analysis** | Encrypted balances hide amounts | | **Statistical attacks** | Random decoy selection | The Privacy Guarantee **Mathematical Privacy:** The probability of correctly identifying the sender is exactly 1/(ring_size/2) (e.g., 12.5% for ring size 16). Rings are split evenly — half are potential senders, half are potential recipients — so the anonymity set for the sender is ring_size/2. This is not \"hard to guess\" - it's mathematically guaranteed randomness. **Source:** This split is enforced by a parity constraint in walletapi/transaction_build.go:79-90 and by the P/Q polynomial structure in cryptography/crypto/proof_generate.go:700-710. See The Parity Constraint for the full source-code-verified breakdown. --- Key Takeaways The Design Principle For Users - **Your encrypted balance will change** when you're selected as a decoy - This is **normal** and **expected** - It does **not** mean you sent anything - Only **you** know if you were sender or decoy - This **protects your privacy** when you ARE the sender For Analysts - **Encrypted balance changes** indicate ring membership only - **Cannot determine** sender vs. decoy from encrypted data - **Statistical analysis** faces 1/(ring_size/2) probability barrier (e.g., 1/8 for ring size 16) - **Definitively proving** sender identity is cryptographically impossible --- Related Pages **Security Suite:** - Balance Mechanics - Encrypted balance structure - Proof Types Explained - Why third parties can't verify **Privacy Suite:** - Ring Signatures - Complete ring signature explanation - Transaction Privacy - Full privacy model",
+      "plainText": "Ring Member Behavior **Critical Understanding:** Encrypted balance changes occur for ALL ring members in a transaction, including decoys. This is **by design** - it's how ring signatures provide plausible deniability. Observing a balance change does NOT mean an address was the sender. **Naming note:** \"Ring signature\" is the user-facing name DERO uses for what the source actually implements as an Anonymous Zether-style anonymity-set ZK proof (see cryptography/crypto/proof_generate.go and proof_verify.go). The user-facing term is colloquial; the construction is not a classical (Schnorr/LSAG/MLSAG) ring signature. The Core Mechanism How Ring Signatures Work When Alice sends DERO to Bob: Why Decoy Balances Change **From Source Code** (walletapi/daemon_communication.go:863-903): **Key Insight:** The encrypted balance data changes for ALL ring members, but only the real sender's *decrypted* balance actually changes. --- The Two Types of Balance Changes Encrypted vs. Decrypted **Encrypted Balance (66 bytes)** **Decrypted Balance (Only Owner Sees)** --- Why This Design? The Privacy Guarantee **The key insight:** If only the real sender's encrypted balance changed, an observer could identify them immediately. By having all ring members' encrypted balances change, the sender remains hidden. Plausible Deniability **Legal Protection:** If accused of sending a transaction, you can truthfully say: \"My encrypted balance changed, but that only means I was in the ring. Any of the 8 potential senders in this ring could be the real sender.\" This is cryptographically provable. --- What Balance Changes Mean Interpretation Guide | Observation | What It Means | What It Doesn't Mean | |-------------|--------------|---------------------| | **Encrypted balance unchanged** | Address not in ANY ring | - | | **Encrypted balance changed** | Address was in a ring | ≠ Address was sender | | **Multiple changes over time** | Address in multiple rings | ≠ Address sent multiple times | | **Decrypted balance unchanged** | Was decoy (owner can verify) | Only owner knows this | | **Decrypted balance changed** | Was real sender (owner can verify) | Only owner knows this | The Unchanged Balance Test **If encrypted balance is unchanged for X blocks:** **This is powerful evidence** - unchanged encrypted balance definitively proves no involvement. --- Ring Member Selection How Decoys Are Chosen **Source** (cmd/derod/rpc/rpc_dero_getrandomaddress.go:80-111 — quoted verbatim): Selection Criteria | Requirement | Reason | |-------------|--------| | **Unchanged balance (5 blocks)** | Better decoys | | **Random selection** | Prevents targeting | | **Multiple candidates** | Ensures diversity | --- Example: Tracing a Transaction The Scenario What an Observer Sees What Each Owner Sees --- Sender vs. Decoy: How to Verify Method 1: Decrypt Balance (Owner Only) The wallet performs this check automatically. From walletapi/daemon_communication.go:900-903: The wallet decrypts the balance before and after the transaction using the owner's private key. If the decrypted balance is unchanged, you were a decoy. If it decreased, you were the sender. Method 2: Check Wallet History (Owner Only) Method 3: External Observation (IMPOSSIBLE) --- Common Misconceptions Misconception 1: \"Balance change = sent transaction\" **Reality:** Balance change only means the address was in a ring. Could be sender OR decoy. Misconception 2: \"Can track senders by balance changes\" **Reality:** All ring members' balances change. Tracking balance changes tracks ring membership, not sending. Misconception 3: \"Unchanged balance = received\" **Reality:** Unchanged encrypted balance = no involvement at all (not sending, not receiving, not in any ring). Misconception 4: \"Third parties can verify sender\" **Reality:** Only the owner (with private key) can determine if they were sender or decoy. This is privacy by design. --- Security Implications What This Protects | Threat | How Ring Member Behavior Helps | |--------|-------------------------------| | **Sender identification** | All ring members look the same | | **Transaction linking** | Each TX has independent ring | | **Balance analysis** | Encrypted balances hide amounts | | **Statistical attacks** | Random decoy selection | The Privacy Guarantee **Mathematical Privacy:** The probability of correctly identifying the sender is exactly 1/(ring_size/2) (e.g., 12.5% for ring size 16). Rings are split evenly — half are potential senders, half are potential recipients — so the anonymity set for the sender is ring_size/2. This is not \"hard to guess\" - it's mathematically guaranteed randomness. **Source:** This split is enforced by a parity constraint in walletapi/transaction_build.go:79-90 and by the P/Q polynomial structure in cryptography/crypto/proof_generate.go:700-710. See The Parity Constraint for the full source-code-verified breakdown. --- Key Takeaways The Design Principle For Users - **Your encrypted balance will change** when you're selected as a decoy - This is **normal** and **expected** - It does **not** mean you sent anything - Only **you** know if you were sender or decoy - This **protects your privacy** when you ARE the sender For Analysts - **Encrypted balance changes** indicate ring membership only - **Cannot determine** sender vs. decoy from encrypted data - **Statistical analysis** faces 1/(ring_size/2) probability barrier (e.g., 1/8 for ring size 16) - **Definitively proving** sender identity is cryptographically impossible --- Related Pages **Security Suite:** - Balance Mechanics - Encrypted balance structure - Proof Types Explained - Why third parties can't verify **Privacy Suite:** - Ring Signatures - Complete ring signature explanation - Transaction Privacy - Full privacy model",
       "lastUpdated": "2026-02-06"
     },
     {
@@ -1098,7 +1106,7 @@
       "slug": "integrity/transaction-proofs",
       "title": "Transaction Proofs: DERO's Six Sigma Proof System | DERO Blockchain",
       "description": "Technical deep dive into DERO's six interconnected transaction proofs - how they work together to guarantee transaction integrity through cryptographic binding.",
-      "canonicalUrl": "https://derod.org/integrity/transaction-proofs",
+      "canonicalUrl": "https://derod.org/integrity/transaction-proofs.md",
       "sourcePath": "derod-main/pages/integrity/transaction-proofs.mdx",
       "headings": [
         "Transaction Proofs: The Six Sigma System",
@@ -1119,12 +1127,13 @@
         "Security Analysis",
         "Attack Resistance",
         "Cryptographic Assumptions",
+        "Why bn256?",
         "Key Takeaways",
         "What Transaction Proofs Provide",
         "The Circular Dependency",
         "Related Pages"
       ],
-      "plainText": "Transaction Proofs: The Six Sigma System **Core Principle:** Six interconnected proofs bound by a cryptographic hash. If you fake one proof, the hash changes, which invalidates all other proofs. This creates an all-or-nothing security model. What Problem Do Transaction Proofs Solve? **The Challenge:** **The Solution: Six Sigma Proofs** - ✅ Each proof validates one aspect - ✅ All proofs bound together cryptographically - ✅ Cannot fake one without breaking all - ✅ Zero-knowledge (reveals nothing) --- The Six Proofs Proof Details | Proof | What It Validates | Why It's Needed | |-------|------------------|-----------------| | **A_y** | Sender possesses private key | Prevents unauthorized spending | | **A_D** | Encrypted balance update is correct | Ensures math is right | | **A_b** | Balance commitment is valid | Binding and hiding properties | | **A_X** | Additional protocol constraints | Protocol-specific rules | | **A_t** | Combined 128-bit value with 64-bit bounds | Prevents negative/overflow | | **A_u** | Key image (linking tag) is correctly derived | Binds transaction to sender's secret key | --- How They're Bound Together The Challenge Hash **From Source Code** (cryptography/crypto/proof_verify.go:410-425): **The Binding Effect:** Why This Prevents Forgery **Attacker's Goal:** **Why It Fails:** **Key Insight:** The challenge hash creates a **circular dependency**. You need all proofs to compute the hash, but you need the hash to create valid responses. Changing any proof changes the hash, which invalidates all responses. --- Each Proof Explained A_y: Secret Key Proof **Purpose:** Proves sender possesses the private key without revealing it. **Mathematical Structure:** **Source:** cryptography/crypto/proof_generate.go - A_y generation A_D: Balance Update Proof **Purpose:** Proves the encrypted balance update is mathematically correct. **What It Validates:** **Source:** cryptography/crypto/proof_generate.go - A_D generation A_b: Balance Commitment Proof **Purpose:** Proves the balance commitment has proper binding and hiding properties. **Properties Ensured:** - **Binding:** Cannot change committed value later - **Hiding:** Cannot determine committed value from commitment **Mathematical Structure:** **Source:** cryptography/crypto/proof_generate.go - A_b generation A_X: Constraint Proof **Purpose:** Validates additional protocol-specific constraints. **What It Covers:** - Transaction format validity - Protocol rule compliance - Additional cryptographic constraints **Source:** cryptography/crypto/proof_generate.go - A_X generation A_t: Range Proof **Purpose:** Proves the combined 128-bit value is valid (lower 64 bits = transfer, upper 64 bits = remaining balance) without revealing either value. **This is the bulletproof component:** - Uses bit decomposition (catches negatives) - Logarithmic proof size (7 rounds for 128-bit range) - Validates both transfer AND remaining balance simultaneously **Detailed explanation →** **Source:** cryptography/crypto/proof_generate.go:473-487 A_u: Key Image Proof **Purpose:** Proves the transaction's linking tag (proof.u) was correctly derived from the sender's secret key. **From Source Code** (cryptography/crypto/proof_generate.go:1123-1136): **What this does:** - Computes a key image by scalar-multiplying a transaction-derived curve point by the secret key nonce - The verifier recovers A_u from proof.s_sk and proof.u (proof_verify.go:399-400) - Binds the proof to a specific (hidden) ring member without revealing which one > **Note on naming:** DERO uses an account model, not UTXO. There are no \"outputs\" to mark as spent. The A_u proof serves as a key image / linking tag that cryptographically ties the transaction to the sender's secret key within the ring signature framework. --- Verification Flow **Verification flow** (see cryptography/crypto/proof_verify.go): The Verify() function performs all checks in sequence. The key checkpoints are: 1. **Overflow check** (line 108-110) -- Reject if fees overflow 2. **Parity check** (line 136-141) -- Verify the secret parity is well-formed 3. **B^w × A recovery** (line 177-179) -- Verify polynomial commitment structure 4. **Challenge hash** (line 410-425) -- Recompute c from all six sigma components and compare to proof.c 5. **Inner product** (line 457-459) -- proof.ip.Verify(hPrimes, u_x, P, o, gparams) If any checkpoint returns false, the entire transaction is rejected. See Proof Verification Flow for the full walkthrough. --- Security Analysis Attack Resistance | Attack | Why It Fails | |--------|-------------| | **Forge single proof** | Changes hash → all proofs invalid | | **Replay old transaction** | A_u key image is bound to Roothash (tree state) → stale proof fails; nonce/height prevents reuse | | **Spend without key** | A_y requires private key → fails | | **Negative amount** | A_t range proof → fails | | **Incorrect balance** | A_D validates math → fails | Cryptographic Assumptions **Security relies on:** 1. **Elliptic Curve Discrete Logarithm Problem (ECDLP)** on the bn256 (Barreto-Naehrig) curve -- a pairing-friendly curve also used by Ethereum's precompiles and early Zcash 2. **Random Oracle Model** -- Hash functions behave as random oracles 3. **Decisional Diffie-Hellman (DDH)** -- Underpins the ElGamal encryption used for balance confidentiality **Note on curve choice:** DERO uses bn256, a pairing-friendly curve. Bitcoin uses secp256k1, a non-pairing curve. Both rely on ECDLP hardness, but they are different curves with different security profiles. bn256 enables the pairing operations needed for DERO's proof system; its parameters are chosen so that both the curve ECDLP and the finite field DLP (via pairing reduction) remain computationally infeasible. **Breaking DERO's proofs would require:** - Solving ECDLP on bn256 (no known efficient algorithm exists for these parameters) - Or finding a flaw in the proof system itself (open source, auditable) --- Key Takeaways What Transaction Proofs Provide | Feature | Benefit | |---------|---------| | **🔐 All-or-nothing security** | Cannot fake partial proofs | | **🔒 Zero-knowledge** | Reveals nothing about transaction | | **⚡ Efficient verification** | Logarithmic proof size (7 rounds for 128-bit range) enables fast verification | | **📐 Mathematical guarantee** | Based on proven cryptography | The Circular Dependency **The Key Insight:** All six proofs are cryptographically entangled. This isn't just \"checking six things\" - it's a single interconnected proof system where the validity of each component depends on all others. --- Related Pages **Security Suite:** - Range Proof Integrity - Deep dive into A_t - Proof Verification Flow - End-to-end flow - Negative Transfer Protection - How A_t prevents negatives **Privacy Suite:** - Bulletproofs - Zero-knowledge range proofs - Homomorphic Encryption - Encrypted balance operations",
+      "plainText": "Transaction Proofs: The Six Sigma System **Core Principle:** Six interconnected proofs bound by a cryptographic hash. If you fake one proof, the hash changes, which invalidates all other proofs. This creates an all-or-nothing security model. What Problem Do Transaction Proofs Solve? **The Challenge:** **The Solution: Six Sigma Proofs** - ✅ Each proof validates one aspect - ✅ All proofs bound together cryptographically - ✅ All-or-nothing cryptographic binding — faking one breaks all - ✅ Zero-knowledge (reveals nothing) --- The Six Proofs Proof Details | Proof | What It Validates | Why It's Needed | |-------|------------------|-----------------| | **A_y** | Sender possesses private key | Prevents unauthorized spending | | **A_D** | Encrypted balance update is correct | Ensures math is right | | **A_b** | Balance commitment is valid | Binding and hiding properties | | **A_X** | Additional protocol constraints | Protocol-specific rules | | **A_t** | Combined 128-bit value with 64-bit bounds | Prevents negative/overflow | | **A_u** | Key image (linking tag) is correctly derived | Binds transaction to sender's secret key | --- How They're Bound Together The Challenge Hash **From Source Code** (cryptography/crypto/proof_verify.go:410-425): **The Binding Effect:** Why This Prevents Forgery **Attacker's Goal:** **Why It Fails:** **Key Insight:** The challenge hash creates a **circular dependency**. You need all proofs to compute the hash, but you need the hash to create valid responses. Changing any proof changes the hash, which invalidates all responses. --- Each Proof Explained A_y: Secret Key Proof **Purpose:** Proves sender possesses the private key without revealing it. **Mathematical Structure:** **Source:** cryptography/crypto/proof_generate.go - A_y generation A_D: Balance Update Proof **Purpose:** Proves the encrypted balance update is mathematically correct. **What It Validates:** **Source:** cryptography/crypto/proof_generate.go - A_D generation A_b: Balance Commitment Proof **Purpose:** Proves the balance commitment has proper binding and hiding properties. **Properties Ensured:** - **Binding:** Cannot change committed value later - **Hiding:** Cannot determine committed value from commitment **Mathematical Structure:** > **DERO's instantiation differs.** The per-ring-member transaction commitment uses each ring slot's **public key** as the second generator rather than a global H (C[i] = ±amount × G + r × pubkey[i], see walletapi/transaction_build.go:152-206 and Balance Mechanics). The textbook Pedersen form above is shown as background for the binding/hiding properties; the actual on-chain construction is ElGamal-style with the receiver-pubkey acting as the second generator. The binding/hiding properties carry over; the security argument differs in the details. **Source:** cryptography/crypto/proof_generate.go - A_b generation A_X: Constraint Proof **Purpose:** Validates additional protocol-specific constraints. **What It Covers:** - Transaction format validity - Protocol rule compliance - Additional cryptographic constraints **Source:** cryptography/crypto/proof_generate.go - A_X generation A_t: Range Proof **Purpose:** Proves the combined 128-bit value is valid (lower 64 bits = transfer, upper 64 bits = remaining balance) without revealing either value. **This is the bulletproof component:** - Validates both transfer AND remaining balance simultaneously (low and high 64 bits of the packed 128-bit value) - Logarithmic proof size (7 rounds for 128-bit range) - By bulletproof soundness, no prover can construct a verifying proof for a committed value outside the proven range — the cryptographic basis for non-negative amounts **Detailed explanation →** **Source:** the A_t commitment itself is constructed at cryptography/crypto/proof_generate.go:1120-1121 (a single sigma element -k_b·G + k_tau·H). The bulletproof input that A_t commits to is built earlier: packing number := btransfer.Add(btransfer, bdiff.Lsh(bdiff, 64)) at proof_generate.go:468-471, and bit decomposition (number_string reversal + aL / aR for-loop) at proof_generate.go:473-487. A_u: Key Image Proof **Purpose:** Proves the transaction's linking tag (proof.u) was correctly derived from the sender's secret key. **From Source Code** (cryptography/crypto/proof_generate.go:1123-1136): **What this does:** - Computes a key image by scalar-multiplying a transaction-derived curve point by the secret key nonce - The verifier recovers A_u from proof.s_sk and proof.u (proof_verify.go:399-400) - Binds the proof to a specific (hidden) ring member without revealing which one > **Note on naming:** DERO uses an account model, not UTXO. There are no \"outputs\" to mark as spent. The A_u proof serves as a key image / linking tag that cryptographically ties the transaction to the sender's secret key within the ring signature framework. --- Verification Flow **Verification flow** (see cryptography/crypto/proof_verify.go): The Verify() function (proof_verify.go:98) performs all checks in sequence. The key checkpoints are: 1. **Overflow check** (line 108-111) -- Reject if fees overflow 2. **Parity check** (line 136-141) -- Verify the secret parity is well-formed 3. **B^w × A recovery** (line 162-180) -- Verify polynomial commitment structure 4. **Challenge hash** (line 410-425) -- Recompute c from all six sigma components and compare to proof.c 5. **Inner product** (line 457-460) -- proof.ip.Verify(hPrimes, u_x, P, o, gparams) If any checkpoint returns false, the entire transaction is rejected. See Proof Verification Flow for the full walkthrough. --- Security Analysis Attack Resistance | Attack | Why It Fails | |--------|-------------| | **Forge single proof** | Changes hash → all proofs invalid | | **Replay old transaction** | A_u key image is bound to Roothash (tree state) → stale proof fails; nonce/height prevents reuse | | **Spend without key** | A_y requires private key → fails | | **Negative amount** | A_t range proof → fails | | **Incorrect balance** | A_D validates math → fails | Cryptographic Assumptions **Security relies on:** 1. **Elliptic Curve Discrete Logarithm Problem (ECDLP)** on the bn256 (Barreto-Naehrig) curve -- a pairing-friendly curve also used by Ethereum's precompiles and early Zcash 2. **Random Oracle Model** -- Hash functions behave as random oracles 3. **Decisional Diffie-Hellman (DDH)** -- Underpins the ElGamal encryption used for balance confidentiality Why bn256? DERO's proof system requires **pairing operations** — a math operation that pairing-friendly curves like bn256 support and non-pairing curves like secp256k1 do not. This is why DERO and Bitcoin use different curves: they need different capabilities. Bitcoin can do its job without pairings; DERO's bulletproofs cannot. The trade-off: pairing-friendly curves have lower effective security at the same parameter size. For bn256 specifically, analysis of the extended Tower Number Field Sieve (Menezes 2016; NCC Group 2017 reassessment) places effective security at **~100 bits** against discrete-log attacks on the pairing-target field, rather than the ~128 bits originally targeted. **What this means in practice:** ~100 bits remains computationally infeasible for any foreseeable adversary, including well-resourced nation-states. The same analysis applies to every production pairing-based system — Ethereum's bn256 precompiles (EIP-196/197), early Zcash, and others. bn256 has not been broken and is not approaching practical attack. But it is not 128, and these docs name that honestly rather than imply parity with secp256k1. **Breaking DERO's proofs would require:** - Solving ECDLP on bn256 (no known efficient algorithm exists for these parameters) - Or finding a flaw in the underlying constructions (bulletproofs and sigma protocols, published cryptographic literature; DERO's implementation is open for independent review) --- Key Takeaways What Transaction Proofs Provide | Feature | Benefit | |---------|---------| | **🔐 All-or-nothing security** | No partial fakes — challenge hash binds all six | | **🔒 Zero-knowledge** | Reveals nothing about transaction | | **⚡ Efficient verification** | Logarithmic proof size (7 rounds for 128-bit range) enables fast verification | | **📐 Mathematical guarantee** | Based on proven cryptography | The Circular Dependency **The Key Insight:** All six proofs are cryptographically entangled. This isn't just \"checking six things\" - it's a single interconnected proof system where the validity of each component depends on all others. --- Related Pages **Security Suite:** - Range Proof Integrity - Deep dive into A_t - Proof Verification Flow - End-to-end flow - Negative Transfer Protection - How A_t prevents negatives **Privacy Suite:** - Bulletproofs - Zero-knowledge range proofs - Homomorphic Encryption - Encrypted balance operations",
       "lastUpdated": "2026-02-06"
     },
     {
@@ -1132,7 +1141,7 @@
       "slug": "privacy",
       "title": "DERO Privacy Suite: Complete Technical Guide | DERO Blockchain",
       "description": "Deep dive into DERO's multi-layered privacy architecture including ring signatures, homomorphic encryption, bulletproofs, and transaction privacy mechanisms.",
-      "canonicalUrl": "https://derod.org/privacy",
+      "canonicalUrl": "https://derod.org/privacy.md",
       "sourcePath": "derod-main/pages/privacy/index.mdx",
       "headings": [
         "DERO Privacy Suite",
@@ -1145,7 +1154,7 @@
         "Payload Proofs",
         "Complete Privacy Documentation"
       ],
-      "plainText": "DERO Privacy Suite Privacy by Design **Privacy is a spectrum, not binary.** DERO provides strong privacy guarantees while maintaining usability and functionality. DERO doesn't add privacy as an afterthought - it's built into every layer of the protocol, from network communication to smart contract execution. **Core Principles:** - Privacy by default (no opt-in required) - Multiple independent layers (defense in depth) - Mathematical guarantees (proven cryptography, not security through obscurity) - Conscious trade-offs (transparent about limitations) **The Breakthrough:** DERO achieved something no other blockchain has accomplished: combining account-based architecture with strong privacy guarantees through homomorphic encryption. This enables private smart contracts, instant transactions, and encrypted balances - all while maintaining complete privacy. Privacy Technologies Overview | Technology | What It Protects | Key Benefit | Learn More | |------------|-----------------|-------------|------------| | **Ring Signatures** | Sender identity | Hide among ring_size/2 potential senders (naive guess 1/(N/2)) | Explore → | | **Homomorphic Encryption** | Amounts, balances | Math on encrypted data (network never sees values) | Explore → | | **Bulletproofs** | Amount validity | 128-bit combined range proofs (logarithmic size) | Explore → | | **Account-Based Privacy** | Transaction patterns | Account model + privacy (unique to DERO) | Explore → | | **Payload Proofs** | Sender verification | Only YOU can prove you sent (third parties can't) | Explore → | --- Homomorphic Encryption **Math on encrypted data. Blockchain never sees your balance. Ever.** Do math on encrypted balances without ever decrypting them. Your balance stays private. Forever. **The Magic:** **Enables:** Instant balance queries, private tokens, private smart contracts. **Explore Homomorphic Encryption →** --- Account-Based Privacy **The Impossible Combination: Accounts + Privacy + Smart Contracts** DERO's unique architectural achievement: account-based model with strong privacy guarantees. **DERO's Unique Solution:** - Account-based model (simple, fast) - Private smart contracts (unique to DERO) - Target block time set by consensus parameters (BLOCK_TIME = 18s) - Lightweight wallets (no chain scanning required) **Explore Account-Based Privacy →** --- Bulletproofs **Zero-knowledge proofs that don't reveal amounts.** Proves your transaction values are valid **without revealing what they are**. DERO uses a 128-bit combined range proof that validates both the transfer amount (lower 64 bits) and remaining balance (upper 64 bits) in a single proof. Cryptographically secured by the bn256 elliptic curve discrete logarithm problem. **Key properties:** - Logarithmic-size proof (7 rounds for 128-bit range) - Triple-layer defense against negative transfers Privacy + Security = Perfect. **Explore Bulletproofs →** --- Ring Signatures **Hide among ring_size/2 potential senders.** Your address is mixed with other members in a ring. Rings are split evenly — half senders, half recipients. The blockchain sees ONE of the sender-half sent the transaction, but cannot determine which one. **Privacy Levels (naive guess):** - 1 in (ring_size/2) chance if no additional information is available (e.g., 1/8 for ring size 16) - Larger rings reduce the naive guess probability **Key Insight:** Ring members' encrypted balances change even as decoys - this is normal behavior, not a bug! **Explore Ring Signatures →** --- Payload Proofs **Only YOU can prove you sent it. Third parties can only guess.** Privacy by design: Only YOU (with your private keys) can prove you sent a transaction. Third parties can only make guesses - exactly as designed for maximum privacy! **The Design:** - Wallet-level convenience tools (not blockchain verification) - Can be faked - by design, for privacy - Third parties cannot definitively prove sender identity **This is a feature, not a bug.** **Explore Payload Proofs →** --- Complete Privacy Documentation **Core Technologies:** - Ring Signatures - Sender anonymity (2-128 members) - Homomorphic Encryption - Encrypted balances and operations - Bulletproofs - 128-bit combined range proofs (logarithmic size) **Privacy in Action:** - Transaction Privacy - Complete end-to-end flow - Account-Based Privacy - Unique architectural achievement - Private Smart Contracts - Contract privacy with encrypted state **Understanding Proofs:** - Payload Proofs - Wallet-level verification mechanisms",
+      "plainText": "DERO Privacy Suite Privacy by Design **Privacy is a spectrum, not binary.** DERO provides strong privacy guarantees while maintaining usability and functionality. DERO doesn't add privacy as an afterthought - it's built into every layer of the protocol, from network communication to smart contract execution. **Core Principles:** - Privacy by default (no opt-in required) - Layered privacy (TLS + anonymity set + homomorphic encryption) with a single verifier-enforced integrity gate (bulletproof soundness + balance proofs) - Mathematical guarantees (proven cryptography, not security through obscurity) - Conscious trade-offs (transparent about limitations) **The Breakthrough:** DERO achieved something no other blockchain has accomplished: combining account-based architecture with strong privacy guarantees through homomorphic encryption. This enables private smart contracts, instant transactions, and encrypted balances - all while maintaining complete privacy. **Naming note:** \"Ring signature\" is the user-facing name DERO uses for what the source actually implements as an Anonymous Zether-style anonymity-set ZK proof (see cryptography/crypto/proof_generate.go and proof_verify.go). The user-facing term is colloquial; the construction is not a classical (Schnorr/LSAG/MLSAG) ring signature. Privacy Technologies Overview | Technology | What It Protects | Key Benefit | Learn More | |------------|-----------------|-------------|------------| | **Ring Signatures** | Sender identity | Hide among ring_size/2 potential senders (naive guess 1/(N/2)) | Explore → | | **Homomorphic Encryption** | Amounts, balances | Math on encrypted data (network never sees values) | Explore → | | **Bulletproofs** | Amount validity | 128-bit combined range proofs (logarithmic size) | Explore → | | **Account-Based Privacy** | Transaction patterns | Account model + privacy (unique to DERO) | Explore → | | **Payload Proofs** | Sender verification | Only YOU can prove you sent (third parties can't) | Explore → | --- Homomorphic Encryption **Math on encrypted data. Blockchain never sees your balance. Ever.** Do math on encrypted balances without ever decrypting them. Your balance stays private. Forever. **The Magic:** **Enables:** Instant balance queries, private tokens, private smart contracts. **Explore Homomorphic Encryption →** --- Account-Based Privacy **The Impossible Combination: Accounts + Privacy + Smart Contracts** DERO's unique architectural achievement: account-based model with strong privacy guarantees. **DERO's Unique Solution:** - Account-based model (simple, fast) - Private smart contracts (unique to DERO) - Target block time set by consensus parameters (BLOCK_TIME = 18s) - Lightweight wallets (no chain scanning required) **Explore Account-Based Privacy →** --- Bulletproofs **Zero-knowledge proofs that don't reveal amounts.** Proves your transaction values are valid **without revealing what they are**. DERO uses a 128-bit combined range proof that validates both the transfer amount (lower 64 bits) and remaining balance (upper 64 bits) in a single proof. Cryptographically secured by the bn256 elliptic curve discrete logarithm problem. **Key properties:** - Logarithmic-size proof (7 rounds for 128-bit range) - Bulletproof soundness rejects any committed value outside the proven range — including the uint64 wraparound of a negative — at the verifier, on every node. **Explore Bulletproofs →** --- Ring Signatures **Hide among ring_size/2 potential senders.** Your address is mixed with other members in a ring. Rings are split evenly — half senders, half recipients. The blockchain sees ONE of the sender-half sent the transaction, but cannot determine which one. **Privacy Levels (naive guess):** - 1 in (ring_size/2) chance if no additional information is available (e.g., 1/8 for ring size 16) - Larger rings reduce the naive guess probability **Key Insight:** Ring members' encrypted balances change even as decoys - this is normal behavior, not a bug! **Explore Ring Signatures →** --- Payload Proofs **Only YOU can prove you sent it. Third parties can only guess.** Privacy by design: Only YOU (with your private keys) can prove you sent a transaction. Third parties can only make guesses - exactly as designed for maximum privacy! **The Design:** - Wallet-level convenience tools (not blockchain verification) - Can be faked - by design, for privacy - Third parties cannot definitively prove sender identity **This is a feature, not a bug.** **Explore Payload Proofs →** --- Complete Privacy Documentation **Core Technologies:** - Ring Signatures - Sender anonymity (2-128 members) - Homomorphic Encryption - Encrypted balances and operations - Bulletproofs - 128-bit combined range proofs (logarithmic size) **Privacy in Action:** - Transaction Privacy - Complete end-to-end flow - Account-Based Privacy - Unique architectural achievement - Private Smart Contracts - Contract code and state variables are PUBLIC; token balances **in user wallets** stay encrypted, transferable peer-to-peer without the contract seeing the amount **Understanding Proofs:** - Payload Proofs - Wallet-level verification mechanisms",
       "lastUpdated": "2026-01-26"
     },
     {
@@ -1153,7 +1162,7 @@
       "slug": "privacy/account-based-privacy",
       "title": "Account-Based Privacy: DERO's Architectural Innovation | DERO Blockchain",
       "description": "Learn why DERO's combination of account-based blockchain with homomorphic encryption creates unique capabilities impossible with UTXO-based privacy systems.",
-      "canonicalUrl": "https://derod.org/privacy/account-based-privacy",
+      "canonicalUrl": "https://derod.org/privacy/account-based-privacy.md",
       "sourcePath": "derod-main/pages/privacy/account-based-privacy.mdx",
       "headings": [
         "Account-Based Privacy: The Unprecedented Combination",
@@ -1182,7 +1191,7 @@
         "What It Enables",
         "Related Pages"
       ],
-      "plainText": "Account-Based Privacy: The Unprecedented Combination **Architectural Breakthrough:** DERO achieves something no other blockchain has accomplished: combining an account-based model with strong privacy guarantees through homomorphic encryption. This enables direct account updates, simple balance tracking, and private smart contracts - all with encrypted amounts. What Problem Does This Solve? **The Challenge:** **DERO's Solution:** - ✅ Account-based model (simple, fast) - ✅ Homomorphic encryption (privacy) - ✅ Private smart contracts (unique to DERO) - ✅ Best of both worlds --- The Account Model Advantage How DERO's Accounts Work **Account Structure:** - Balance is a single value that can be directly updated - Direct query - no need to sum outputs - Simple add/subtract operations - Natural fit for smart contracts - Lower complexity than output-based systems --- Why Account + Privacy Is Hard The Challenge DERO Solved **The Impossible Problem:** **Why This Was Thought Impossible:** **The Account Privacy Challenge** **DERO's Solution: Homomorphic Encryption** --- Three Key Advantages 1. Transaction Confirmation (Target Block Time) **DERO's Flow:** Submit to mini-block system → account update → main block target time (BLOCK_TIME = 18s) | Aspect | DERO Account Model | |--------|-------------------| | **Confirmation** | Target block time: 18 seconds | | **Validation** | Simple account update | | **Block Structure** | Mini-blocks + main blocks | | **Finality** | Same-block finality | **Advantage:** Fast confirmation with account model + privacy ✅ **Source:** Target block time is defined by config/config.go (BLOCK_TIME = 18). --- 2. Simple Balance Checking **DERO's Flow:** Query encrypted balance → decrypt with private key (no chain scanning) | Step | DERO Account Model | |------|-------------------| | **1** | Query encrypted balance | | **2** | Decrypt with private key | | **3** | See balance locally | | **Time** | No chain scanning required | | **Data Required** | One RPC call | **Advantage:** Balance checks without full sync ✅ --- 3. Smart Contract Compatibility **DERO Account Model:** Natural state storage, direct balance updates, encrypted state works | Feature | DERO Account Model | |---------|-------------------| | **State Storage** | ✅ Natural | | **Balance Updates** | ✅ Direct | | **Logic Complexity** | ✅ Full support | | **Encrypted State** | ✅ Works with DERO | **Advantage:** Rich smart contracts WITH privacy ✅ --- Technical Implementation How DERO Manages Encrypted Accounts **Account Structure:** - Address: dero1qy... - Encrypted balances stored in Graviton DB - Key: Address, Value: E(amount) - Supports multiple assets: DERO, tokens, etc. **Balance Updates:** **Simplified pseudocode** (blockchain/transaction_execute.go): --- Mini-Blocks and Finality How DERO Achieves Fast Confirmation **Mini-Block Architecture:** **Timeline:** | Step | Order | What Happens | |------|-------|--------------| | **1. Submit** | 1 | User submits transaction | | **2. Mini-Block** | 2 | Included in mini-block | | **3. Update** | 3 | Homomorphic balance update | | **4. Main Block** | 4 | Aggregated and confirmed | | **5. Final** | 5 | Transaction final | **Why This Works:** - Single account validation (simple) - Easy parallelization - Fast confirmation - Privacy maintained throughout **DERO combines:** Speed of accounts + Privacy of encryption ✅ --- Wallet Synchronization Lightweight Clients Possible **DERO Account-Based:** Query encrypted balance to Decrypt with private key = **Seconds** (optional history sync) | Aspect | DERO Wallet | |--------|-------------| | **Required** | Query encrypted balance | | **Time** | Seconds | | **Data** | Minimal (one query) | | **Optional** | Transaction history sync | **Advantage:** Lightweight wallets with full privacy ✅ --- Privacy Guarantees What Account Model Doesn't Compromise | Privacy Aspect | DERO Account Privacy | |----------------|---------------------| | **Sender** | ✅ Ring signatures (hidden among 8 potential senders at ring size 16) | | **Amount** | ✅ Encrypted (homomorphic operations) | | **Unlinkability** | ✅ Different rings per transaction | | **Smart Contracts** | ✅ Encrypted state (unique!) | **Result:** Complete privacy guarantees, plus smart contract privacy! --- Why DERO's Approach Works The Account Model Advantage | Feature | DERO Has | |---------|----------| | **Privacy** | ✅ Built-in (homomorphic encryption) | | **Speed** | ✅ Target block time: 18 seconds | | **Smart Contracts** | ✅ Natural support with privacy | | **Balance Check** | ✅ No chain scanning required | | **Complexity** | ✅ Low (simple account model) | | **Wallet Sync** | ✅ Lightweight clients supported | **DERO proved:** You CAN have account simplicity AND privacy! What Makes DERO Unique | Aspect | DERO | |--------|------| | **Privacy** | ✅ Built-in from architecture | | **Design** | ✅ Designed for encryption | | **Homomorphic** | ✅ Fundamental to the system | | **Status** | ✅ Proven in production | --- Key Takeaways What Account-Based Privacy Provides | Feature | Benefit | Impact | |---------|---------|--------| | **⚡ Target Block Time** | 18 seconds | Consensus target | | **🔍 Encrypted Balance** | Query encrypted balance | No sync needed | | **🔐 Smart Contract Privacy** | Encrypted state | Unique to DERO | | **📦 Simple Wallets** | Lightweight clients | Easy adoption | | **🎯 Account Simplicity** | One balance per account | Lower complexity | | **✅ Complete Privacy** | All guarantees maintained | Best of both | What It Enables - ✅ **Private Smart Contracts** - Unique to DERO - ✅ **Encrypted Balance Queries** - No blockchain scanning - ✅ **Lightweight Wallets** - No chain scanning required - ✅ **Target Block Time** - 18 seconds - ✅ **Account Simplicity** - Lower complexity - ✅ **Proven in Production** - Working system, not theoretical **Innovation:** DERO demonstrated that privacy with accounts was possible through homomorphic encryption. Accounts can be just as private - while being simpler and faster. --- Related Pages **Privacy Suite:** - Ring Signatures - Transaction anonymity - Homomorphic Encryption - Balance privacy - Transaction Privacy - Complete privacy model **Technical:** - DERO Wallets - Stealth address generation - Wallet RPC API - Integrated addresses **Understanding DERO:** - DERO Tokens - Account-based asset model - Privacy Features - Full privacy suite overview",
+      "plainText": "Account-Based Privacy: The Unprecedented Combination **Architectural Breakthrough:** DERO achieves something no other blockchain has accomplished: combining an account-based model with strong privacy guarantees through homomorphic encryption. This enables direct account updates, simple balance tracking, and private smart contracts - all with encrypted amounts. What Problem Does This Solve? **The Challenge:** **DERO's Solution:** - ✅ Account-based model (simple, fast) - ✅ Homomorphic encryption (privacy) - ✅ Private smart contracts (unique to DERO) - ✅ Best of both worlds --- The Account Model Advantage How DERO's Accounts Work **Account Structure:** - Balance is a single value that can be directly updated - Direct query - no need to sum outputs - Simple add/subtract operations - Natural fit for smart contracts - Lower complexity than output-based systems --- Why Account + Privacy Is Hard The Challenge DERO Solved **The Impossible Problem:** **Why This Was Thought Impossible:** **The Account Privacy Challenge** **DERO's Solution: Homomorphic Encryption** --- Three Key Advantages 1. Transaction Confirmation (Target Block Time) **DERO's Flow:** Submit to mini-block system → account update → main block target time (BLOCK_TIME = 18s) | Aspect | DERO Account Model | |--------|-------------------| | **Confirmation** | Target block time: 18 seconds | | **Validation** | Simple account update | | **Block Structure** | Mini-blocks + main blocks | | **Finality** | Same-block finality | **Advantage:** Fast confirmation with account model + privacy ✅ **Source:** Target block time is defined by config/config.go:34 (const BLOCK_TIME = uint64(18)). --- 2. Simple Balance Checking **DERO's Flow:** Query encrypted balance → decrypt with private key (no chain scanning) | Step | DERO Account Model | |------|-------------------| | **1** | Query encrypted balance | | **2** | Decrypt with private key | | **3** | See balance locally | | **Time** | No chain scanning required | | **Data Required** | One RPC call | **Advantage:** Balance checks without full sync ✅ --- 3. Smart Contract Compatibility **DERO Account Model:** Natural state storage, direct balance updates, contracts can move encrypted wallet balances homomorphically without seeing the amount | Feature | DERO Account Model | |---------|-------------------| | **State Storage** | ✅ Natural (STORE/LOAD to graviton tree, plaintext) | | **Balance Updates** | ✅ Direct (homomorphic on encrypted wallet balances) | | **Logic Complexity** | ✅ Full support | | **Encrypted Wallet Token Balances** | ✅ Contract can transfer without decrypting the amount | **Advantage:** Rich smart contracts whose **token movements** preserve user privacy (contract logic and state itself are public). --- Technical Implementation How DERO Manages Encrypted Accounts **Account Structure:** - Address: dero1qy... - Encrypted balances stored in Graviton DB - Key: the compressed public key (33 bytes — tx.MinerAddress[:] or the pubkey decoded from the bech32 address); the dero1qy... bech32 form is only the display encoding. Value: E(amount) (ElGamal (Left, Right) pair) - Supports multiple assets: DERO, tokens, etc. **Balance Updates:** **Simplified pseudocode** (blockchain/transaction_execute.go): --- Mini-Blocks and Finality How DERO Achieves Fast Confirmation **Mini-Block Architecture:** **Timeline:** | Step | Order | What Happens | |------|-------|--------------| | **1. Submit** | 1 | User submits transaction | | **2. Mini-Block** | 2 | Included in mini-block | | **3. Update** | 3 | Homomorphic balance update | | **4. Main Block** | 4 | Aggregated and confirmed | | **5. Final** | 5 | Transaction final | **Why This Works:** - Single account validation (simple) - Easy parallelization - Fast confirmation - Privacy maintained throughout **DERO combines:** Speed of accounts + Privacy of encryption ✅ --- Wallet Synchronization Lightweight Clients Possible **DERO Account-Based:** Query encrypted balance to Decrypt with private key = **Seconds** (optional history sync) | Aspect | DERO Wallet | |--------|-------------| | **Required** | Query encrypted balance | | **Time** | Seconds | | **Data** | Minimal (one query) | | **Optional** | Transaction history sync | **Advantage:** Lightweight wallets with full privacy ✅ --- Privacy Guarantees **Naming note:** \"Ring signature\" is the user-facing name DERO uses for what the source actually implements as an Anonymous Zether-style anonymity-set ZK proof (see cryptography/crypto/proof_generate.go and proof_verify.go). The user-facing term is colloquial; the construction is not a classical (Schnorr/LSAG/MLSAG) ring signature. What Account Model Doesn't Compromise | Privacy Aspect | DERO Account Privacy | |----------------|---------------------| | **Sender** | ✅ Anonymity-set proof (hidden among 8 potential senders at ring size 16) | | **Amount** | ✅ Encrypted (homomorphic operations) | | **Unlinkability** | ✅ Different rings per transaction | | **Smart Contracts** | ⚠️ Contract code and STORE/LOAD state are **public**; what's private is the **token balances in user wallets** that a contract can move homomorphically without seeing the amount (see Private Smart Contracts) | **Result:** Strong privacy guarantees on transfers and balances; contract logic is openly auditable. --- Why DERO's Approach Works The Account Model Advantage | Feature | DERO Has | |---------|----------| | **Privacy** | ✅ Built-in (homomorphic encryption) | | **Speed** | ✅ Target block time: 18 seconds | | **Smart Contracts** | ✅ Natural support with privacy | | **Balance Check** | ✅ No chain scanning required | | **Complexity** | ✅ Low (simple account model) | | **Wallet Sync** | ✅ Lightweight clients supported | **DERO proved:** You CAN have account simplicity AND privacy! What Makes DERO Unique | Aspect | DERO | |--------|------| | **Privacy** | ✅ Built-in from architecture | | **Design** | ✅ Designed for encryption | | **Homomorphic** | ✅ Fundamental to the system | | **Status** | ✅ Proven in production | --- Key Takeaways What Account-Based Privacy Provides | Feature | Benefit | Impact | |---------|---------|--------| | **⚡ Target Block Time** | 18 seconds | Consensus target | | **🔍 Encrypted Balance** | Query encrypted balance | No sync needed | | **🔐 Smart Contract Privacy** | Contract state is public; wallet token balances stay encrypted across SC transfers | Unique to DERO | | **📦 Simple Wallets** | Lightweight clients | Easy adoption | | **🎯 Account Simplicity** | One balance per account | Lower complexity | | **✅ Complete Privacy** | All guarantees maintained | Best of both | What It Enables - ✅ **Private Smart Contracts** - Unique to DERO - ✅ **Encrypted Balance Queries** - No blockchain scanning - ✅ **Lightweight Wallets** - No chain scanning required - ✅ **Target Block Time** - 18 seconds - ✅ **Account Simplicity** - Lower complexity - ✅ **Proven in Production** - Working system, not theoretical **Innovation:** DERO demonstrated that privacy with accounts was possible through homomorphic encryption. Accounts can be just as private - while being simpler and faster. --- Related Pages **Privacy Suite:** - Ring Signatures - Transaction anonymity - Homomorphic Encryption - Balance privacy - Transaction Privacy - Complete privacy model **Technical:** - DERO Wallets - Stealth address generation - Wallet RPC API - Integrated addresses **Understanding DERO:** - DERO Tokens - Account-based asset model - Privacy Features - Full privacy suite overview",
       "lastUpdated": "2026-01-26"
     },
     {
@@ -1190,7 +1199,7 @@
       "slug": "privacy/bulletproofs",
       "title": "Bulletproofs: DERO's Zero-Knowledge Range Proofs | DERO Blockchain",
       "description": "How DERO's bulletproofs prove amounts are valid without revealing them, using logarithmic-size range proofs and cryptographic protection against negative transfers.",
-      "canonicalUrl": "https://derod.org/privacy/bulletproofs",
+      "canonicalUrl": "https://derod.org/privacy/bulletproofs.md",
       "sourcePath": "derod-main/pages/privacy/bulletproofs.mdx",
       "headings": [
         "Bulletproofs: Zero-Knowledge Range Proofs",
@@ -1198,13 +1207,9 @@
         "How It Works (Simple Analogy)",
         "The Proof Flow",
         "Protection Against Negative Transfers",
-        "Three-Layer Defense",
-        "Layer 1: Bit Decomposition Protection",
-        "Layer 2: Range Proof (A_t)",
-        "Layer 3: Inner Product Proof - The Cryptographic Fail-Safe",
         "The Six Sigma Proofs",
-        "Inner Product Proof (The Core Algorithm)",
-        "Recursive Halving - How Logarithmic Scaling Works",
+        "Inner Product Proof — Closing A_t",
+        "Recursive Halving — How Logarithmic Scaling Works",
         "Zero-Knowledge Property Explained",
         "What \"Zero-Knowledge\" Means",
         "Where Bulletproofs Are Used",
@@ -1213,7 +1218,7 @@
         "What You're Protected From",
         "Related Pages"
       ],
-      "plainText": "Bulletproofs: Zero-Knowledge Range Proofs **Zero-Knowledge Magic:** Bulletproofs prove your transaction amounts are valid **without revealing what they are**. DERO uses a 128-bit combined range proof to validate both the transfer amount and remaining balance in a single proof. Privacy + Security = Perfect. What Problem Do Bulletproofs Solve? **The Challenge:** **The Solution: Bulletproofs** - ✅ Prove combined 128-bit value is valid (transfer + remaining balance, each 64-bit) - ✅ Never reveal the amount value - ✅ Logarithmic-size proof (7 rounds for 128-bit range) - ✅ No trusted setup needed --- How It Works (Simple Analogy) **The Bouncer Problem:** **Show ID (Reveals Everything)** **Bulletproof (Reveals Nothing)** **For DERO:** - Bulletproof proves: \"Combined 128-bit value is valid (transfer amount in lower 64 bits, remaining balance in upper 64 bits)\" - Network learns: ✅ Both values are valid (in [0, 2^64)) - Network learns: ❌ What either value actually is --- The Proof Flow **What Network Sees:** - ✅ Commitment (encrypted amount) - ✅ Bulletproof (logarithmic-size proof) - ✅ Proof is valid - ❌ Actual amount (hidden) --- Protection Against Negative Transfers Three-Layer Defense DERO uses **three cryptographic layers** to prevent negative transfers: Layer 1: Bit Decomposition Protection **What Happens with Negative Values:** | Scenario | Binary Representation | Result | |---------|----------------------|--------| | **Valid (100 DERO)** | 1100100 | ✅ Valid bit string | | **Invalid (-100)** | -1100100 | ❌ Contains - character | **From Source Code** (cryptography/crypto/proof_generate.go:473-487): **Technical Guarantee:** - Go's BigInt.Text(2) **always** returns \"-[binary]\" for negatives - This is standard library behavior (cannot be bypassed) - Bit processing loop expects only '0' (48) or '1' (49) - Minus sign '-' (45) breaks the proof generation Layer 2: Range Proof (A_t) **What A_t Validates:** DERO constructs a **combined 128-bit value** where the lower 64 bits represent the transfer amount and the upper 64 bits represent the remaining balance. This is created by: value = transfer_amount + (remaining_balance << 64). **If Layer 1 fails (has - character):** - Bit commitments cannot be created - A_t proof generation fails - Transaction rejected **Source:** cryptography/crypto/proof_generate.go:471 - Combined value construction: btransfer.Add(btransfer, bdiff.Lsh(bdiff, 64)) **Why 128 bits?** By combining transfer amount and remaining balance into a single 128-bit value, DERO proves both are valid in one proof while keeping both values hidden. Layer 3: Inner Product Proof - The Cryptographic Fail-Safe Layer 3 is the **cryptographic fail-safe** that ensures complete integrity across all proof components. Using a recursive halving algorithm, it creates cryptographic commitments at each step, making it mathematically impossible to have invalid bit vectors or any form of manipulation. **What It Validates:** **From Source Code** (cryptography/crypto/proof_innerproduct.go): **The Fail-Safe Guarantee:** Even if Layers 1 and 2 were somehow bypassed (mathematically impossible), Layer 3 would still reject the transaction because invalid bit vectors create inconsistent inner products, and the recursive structure cryptographically binds all components. The final verification checks mathematical consistency - any corruption is detected and rejected. **Triple Protection:** Layer 1 catches negatives at bit decomposition. Layer 2 validates range. **Layer 3 is the cryptographic fail-safe** that ensures complete integrity across all proof components. All three layers must pass - this is mathematically guaranteed. --- The Six Sigma Proofs DERO uses **six interconnected proofs** that all must pass: | Proof | What It Validates | Security Level | |-------|------------------|----------------| | **A_y** | Sender has private key | 🔒 Cryptographically secure | | **A_D** | Encrypted balance update correct | 🔒 Homomorphic validation | | **A_b** | Balance commitment valid | 🔒 Binding & hiding | | **A_X** | Additional protocol constraints | 🔒 Protocol-specific | | **A_t** | Combined 128-bit value valid (transfer + balance) | 🔒 Range proof (bulletproof) | | **A_u** | No double-spending | 🔒 Unspent validation | **All Bound Together:** **Source:** cryptography/crypto/proof_verify.go - Verifies all six sigma proofs + inner product --- Inner Product Proof (The Core Algorithm) Recursive Halving - How Logarithmic Scaling Works **The Algorithm:** **Iterations:** - Start: 128 elements - Iteration 1: 64 elements - Iteration 2: 32 elements - Iteration 3: 16 elements - Iteration 4: 8 elements - Iteration 5: 4 elements - Iteration 6: 2 elements - Iteration 7: 1 element **Total:** log₂(128) = 7 iterations **Source:** cryptography/crypto/proof_innerproduct.go - Recursive halving algorithm --- Zero-Knowledge Property Explained What \"Zero-Knowledge\" Means **After seeing a valid bulletproof, verifier learns:** | Information | Learned? | Reason | |------------|----------|--------| | **Combined 128-bit value is valid** | ✅ Yes | This is what's proven | | **Transfer and balance each in 0, 2^64)** | ✅ Yes | Implicit from 128-bit structure | | **Exact transfer amount** | ❌ No | Zero-knowledge property | | **Exact remaining balance** | ❌ No | Zero-knowledge property | | **Any bits of either value** | ❌ No | Bits are hidden | | **Any private information** | ❌ No | Perfect privacy | **Formal Properties:** - ✅ **Completeness:** Valid proofs always verify - ✅ **Soundness:** Invalid proofs never verify - ✅ **Zero-knowledge:** No information leaked --- Where Bulletproofs Are Used **Three Core Applications:** | Application | What It Validates | Protection | |------------|------------------|------------| | **Transaction Amounts** | Combined 128-bit value (transfer + remaining balance) | Prevents negative transfers | | **Balance Sufficiency** | Both transfer and remaining balance in [0, 2^64) | Prevents overdrafts | | **Smart Contract State** | State transitions valid, no negative balances | Ensures contract integrity | **All three use the same bulletproof mechanism:** - ✅ Prove value is in valid range - ✅ Never reveal the actual value - ✅ Cryptographic guarantee --- Key Takeaways What You Get | Feature | Benefit | Impact | |---------|---------|--------| | **🔒 Zero-Knowledge** | Amount hidden from network | Perfect privacy | | **📦 Logarithmic Proofs** | 7 rounds for 128-bit range | Efficient transactions | | **🔐 No Trusted Setup** | Pure cryptography | Decentralized security | | **🛡️ Triple-Layer Defense** | Multiple fail-safes | Negative transfers impossible | | **✅ Proven Security** | bn256 elliptic curve discrete log | Standard discrete log security assumption | What You're Protected From **The Bottom Line:** **Triple-Layer Security:** Layer 1 catches negatives at bit decomposition. Layer 2 validates range. Layer 3 provides cryptographic fail-safe integrity. All three must pass - mathematically guaranteed. **Performance + Privacy:** DERO's bulletproof implementation keeps proofs logarithmic in size while preserving strong cryptographic guarantees. --- Related Pages **Privacy Suite:** - [Ring Signatures - Sender anonymity - Homomorphic Encryption - Amount encryption - Transaction Privacy - Complete privacy model **Technical Details:** - DERO Tokens - How bulletproofs secure token balances - Transaction Structure - Bulletproof integration **Learn More:** - Privacy Features Overview - Full privacy suite - Private Smart Contracts - Contract privacy",
+      "plainText": "Bulletproofs: Zero-Knowledge Range Proofs **What bulletproofs prove:** Every transfer carries a zero-knowledge proof that the amount is valid **without revealing what it is**. DERO uses a 128-bit combined range proof that binds both the transfer amount and the sender's remaining balance to non-negative 64-bit ranges in a single proof. What Problem Do Bulletproofs Solve? **The Challenge:** **The Solution: Bulletproofs** - ✅ Prove combined 128-bit value is valid (transfer + remaining balance, each 64-bit) - ✅ Never reveal the amount value - ✅ Logarithmic-size proof (7 rounds for 128-bit range) - ✅ No trusted setup needed (the bulletproof generators G and H are derived deterministically from public protocol constants via hash-to-curve — cryptography/crypto/algebra_pedersen.go:36-37 — so there is no setup ceremony to trust) --- How It Works (Simple Analogy) **The Bouncer Problem:** **Show ID (Reveals Everything)** **Bulletproof (Reveals Nothing)** **For DERO:** - Bulletproof proves: \"Combined 128-bit value is valid (transfer amount in lower 64 bits, remaining balance in upper 64 bits)\" - Network learns: ✅ Both values are valid (in 0, 2^64)) - Network learns: ❌ What either value actually is --- The Proof Flow **What Network Sees:** - ✅ Commitment (encrypted amount) - ✅ Bulletproof (logarithmic-size proof) - ✅ Proof is valid - ❌ Actual amount (hidden) --- Protection Against Negative Transfers The guarantee is cryptographic, not a string-parsing quirk: by the **soundness** of the Bulletproof range proof, no prover can construct a proof that verifies for a committed value outside the proven range. Combined with DERO's homomorphic value conservation, value cannot be created from nothing. DERO packs **two** quantities into a single 128-bit value and range-proves them together — the transfer amount in the low 64 bits and the sender's remaining balance in the high 64 bits — so one Bulletproof binds **both** to non-negative 64-bit ranges (number = transfer + (balance << 64), cryptography/crypto/proof_generate.go:471). A \"negative\" transfer is the uint64 wraparound of a value near 2^64. It fails the range proof from both directions: | Attack framing | Why the range proof rejects it | |---|---| | Treat the wraparound as the **transfer amount** | A value near 2^64 lies outside [0, 2^64) — the low-64 range bound fails. | | Treat it as **receiving** (so your own balance jumps) | The conservation proof forces a matching decrease; the sender's **remaining balance** goes negative → wraps → the high-64 range bound fails. | The protection lives in **verification** (cryptography/crypto/proof_verify.go), not generation. The wallet builds the proof in proof_generate.go; an attacker controls their own wallet and could patch out any client-side check. The cryptographic guarantee comes from the verifier check that every node runs independently before accepting a block. **Common misconception:** A claim circulates that Go's BigInt.Text(2) emitting a '-' for negative values \"breaks the bit loop\" in proof generation, and that this is what stops negative transfers. It does not — the loop is if b == '1' { … } else { … }, which silently treats a stray '-' as a 0 bit. And for any real transaction the packed 128-bit number is positive, so no '-' appears at all. The actual safeguard is verifier-side Bulletproof soundness. See [Negative Transfer Protection for the full derivation. --- The Six Sigma Proofs DERO uses **six interconnected proofs** that all must pass: | Proof | What It Validates | Security Level | |-------|------------------|----------------| | **A_y** | Sender has private key | 🔒 Cryptographically secure | | **A_D** | Encrypted balance update correct | 🔒 Homomorphic validation | | **A_b** | Balance commitment valid | 🔒 Binding & hiding | | **A_X** | Additional protocol constraints | 🔒 Protocol-specific | | **A_t** | Range-proof commitment for the packed 128-bit value (transfer + balance << 64) — **closed by the inner product proof** below | 🔒 Bulletproof — soundness under DL on bn256 (random oracle model) | | **A_u** | Key image (linking tag) is correctly derived from the sender's secret key — ties tx to the sender within the anonymity-set without revealing which slot is the sender | 🔒 Anti-replay, account-model linking (see Transaction Proofs § A_u) | **All Bound Together:** **Source:** cryptography/crypto/proof_verify.go:98 — Verify() recomputes the challenge hash from all six recovered sigma components (lines 410-425), then closes A_t via the inner product proof at line 457. --- Inner Product Proof — Closing A_t The inner product proof is **not a seventh independent check**. It is the recursive closure of the **A_t** bulletproof above: A_t commits to polynomial coefficients of the range-proof relation; the inner product argument shows those coefficients fold consistently with the committed value, proving (with the rest of the bulletproof scaffolding) that the packed transfer + balance << 64 lies in [0, 2^128). A failed inner product check is a failed A_t — and therefore a failed transaction. There is one bulletproof gate, with two named pieces. Recursive Halving — How Logarithmic Scaling Works **The Algorithm:** **Iterations:** - Start: 128 elements - Iteration 1: 64 elements - Iteration 2: 32 elements - Iteration 3: 16 elements - Iteration 4: 8 elements - Iteration 5: 4 elements - Iteration 6: 2 elements - Iteration 7: 1 element **Total:** log₂(128) = 7 iterations **Source:** cryptography/crypto/proof_innerproduct.go:71 hardcodes length := 7 for the 128-bit range (note: this lives in Deserialize, so the 128-bit range size is fixed at the wire level — an attacker cannot submit a proof of a different range); the verifier closure call is proof.ip.Verify(...) at cryptography/crypto/proof_verify.go:457. The bulletproof input vector itself is packed at proof_innerproduct.go:41 (the \"7 entries\" structure). --- Zero-Knowledge Property Explained What \"Zero-Knowledge\" Means **After seeing a valid bulletproof, verifier learns:** | Information | Learned? | Reason | |------------|----------|--------| | **Combined 128-bit value is valid** | ✅ Yes | This is what's proven | | **Transfer and balance each in [0, 2^64)** | ✅ Yes | Implicit from 128-bit structure | | **Exact transfer amount** | ❌ No | Zero-knowledge property | | **Exact remaining balance** | ❌ No | Zero-knowledge property | | **Any bits of either value** | ❌ No | Bits are hidden | | **Any private information** | ❌ No | The proof reveals nothing beyond the validity claim | **Formal Properties:** - ✅ **Completeness:** Valid proofs always verify - ✅ **Soundness:** Invalid proofs never verify - ✅ **Zero-knowledge:** No information leaked --- Where Bulletproofs Are Used **Three Core Applications:** | Application | What It Validates | Protection | |------------|------------------|------------| | **Transaction Amounts** | Combined 128-bit value (transfer + remaining balance) | Prevents negative transfers | | **Balance Sufficiency** | Both transfer and remaining balance in [0, 2^64) | Prevents overdrafts | | **Asset (token) transfers via tx.Payloads[t]** | Range-proves the same packed value for each non-DERO asset moved in the transaction | Same negative/overflow protection applied per asset payload (note: smart-contract STORE/LOAD state is stored plaintext in the graviton tree — it is *not* bulletproof-protected) | **All three use the same bulletproof mechanism:** - ✅ Prove value is in valid range - ✅ Never reveal the actual value - ✅ Cryptographic guarantee --- Key Takeaways What You Get | Feature | Benefit | Impact | |---------|---------|--------| | **🔒 Zero-Knowledge** | Amount hidden from network | Transactions don't leak amounts to observers | | **📦 Logarithmic Proofs** | 7 rounds for 128-bit range | Efficient transactions | | **🔐 No Trusted Setup** | Pure cryptography | Decentralized security | | **🛡️ Soundness + Conservation** | No verifying proof for out-of-range values | Negative transfers cryptographically impossible | | **✅ Proven Security** | bn256 elliptic curve discrete log | Standard discrete log security assumption | What You're Protected From **The Bottom Line:** **Verifier-side guarantee:** Every node independently checks the Bulletproof. By soundness, no prover can construct a verifying proof for an out-of-range value. Combined with homomorphic value conservation, negative transfers are cryptographically impossible. **Performance + Privacy:** DERO's bulletproof implementation keeps proofs logarithmic in size while preserving strong cryptographic guarantees. --- Related Pages **Privacy Suite:** - Ring Signatures - Sender anonymity - Homomorphic Encryption - Amount encryption - Transaction Privacy - Complete privacy model **Technical Details:** - DERO Tokens - How bulletproofs secure token balances - Transaction Structure - Bulletproof integration **Learn More:** - Privacy Features Overview - Full privacy suite - Private Smart Contracts - Contract privacy",
       "lastUpdated": "2026-01-26"
     },
     {
@@ -1221,7 +1226,7 @@
       "slug": "privacy/homomorphic-encryption",
       "title": "Homomorphic Encryption: DERO's Account Privacy Innovation | DERO Blockchain",
       "description": "Technical deep dive into DERO's homomorphic encryption system using ElGamal, enabling encrypted account balances and operations on encrypted data for blockchain applications.",
-      "canonicalUrl": "https://derod.org/privacy/homomorphic-encryption",
+      "canonicalUrl": "https://derod.org/privacy/homomorphic-encryption.md",
       "sourcePath": "derod-main/pages/privacy/homomorphic-encryption.mdx",
       "headings": [
         "Homomorphic Encryption: Math on Locked Boxes",
@@ -1248,7 +1253,7 @@
         "What It Enables",
         "Related Pages"
       ],
-      "plainText": "Homomorphic Encryption: Math on Locked Boxes **The Innovation:** Do math on encrypted balances without ever decrypting them. Your balance stays private. Forever. Even the blockchain never sees it. What Problem Does It Solve? **The Challenge:** **The Solution: Homomorphic Encryption** - ✅ Math happens on encrypted data - ✅ No decryption ever required - ✅ Privacy never broken - ✅ Blockchain can verify without seeing amounts --- The Simple Analogy **Locked Safe (Regular Encryption)** **Magic Safe (Homomorphic Encryption)** **For DERO:** - Balance is **always** encrypted (safe always locked) - Math happens on the encrypted number - Safe never opens - Blockchain never sees actual balance --- How It Works The Encryption Flow **The Setup:** Encrypting an Amount **From Source Code** (cryptography/crypto/algebra_elgamal.go): | Step | What Happens | What Network Sees | |------|-------------|-------------------| | **1. Pick random 'r'** | Generate random number | Nothing | | **2. Calculate L** | L = 100×G + r×P | Random elliptic curve point | | **3. Calculate R** | R = r×G | Random elliptic curve point | | **4. Result** | E(100) = (L, R) | Random points (no amount visible) | The Magic: Homomorphic Operations **Addition & Subtraction on Encrypted Data:** **The Math:** **Mathematical Guarantee:** Based on the elliptic curve discrete logarithm problem on the bn256 (Barreto-Naehrig) curve. --- Transaction Flow: Alice → Bob **Alice sends 100 DERO to Bob:** What Happens at Each Step **Initial State** **Create Transfer** **Homomorphic Operations** **Final State** --- Comparison: Traditional vs DERO Balance Storage | Aspect | Traditional Blockchain | DERO Blockchain | |--------|----------------------|-----------------| | **Account** | alice.eth | dero1qy... | | **Balance shown** | 500 ETH 👁️ Public | E(???) 🔒 Encrypted | | **Everyone sees** | Exact amount | Random bytes (66 bytes) | | **Only owner sees** | Same as everyone | Actual balance (with private key) | | **Privacy** | ❌ Zero | ✅ Complete | | **Balance lookup** | Instant (public) | Instant (encrypted) | **The Difference:** - **Bitcoin/Ethereum:** Your balance is like your bank statement posted on a billboard - **DERO:** Your balance is permanently locked in a safe only you can open Blockchain Architecture Comparison | Feature | Bitcoin/UTXO | Ethereum (Account) | DERO (Account + Encrypted) | |---------|-------------|-------------------|---------------------------| | **Model** | Outputs | Accounts | Accounts | | **Privacy** | ❌ Pseudonymous | ❌ None | ✅ Encrypted | | **Smart Contracts** | ❌ Limited | ✅ Yes, public | ✅ Yes, **private** | | **Confirmations** | Slower | Fast | Fast | | **Balance Lookup** | Scan chain | Instant | Instant + private | **DERO = Ethereum's simplicity + Privacy coin encryption** 🎯 --- Real-World Applications 1. Instant Balance Queries **Traditional Privacy Coin:** **DERO:** 2. Private Token Systems **How It Works:** **Key Points:** **From Source Code** (dvm/dvm_functions.go:80): **Traditional tokens (ERC-20):** Balances public in contract **DERO tokens:** Balances encrypted in user wallets, transferable peer-to-peer 3. Private DeFi Operations **Swap Example:** --- Technical Implementation The C and D Commitments Every DERO transaction contains encrypted commitments: **C Commitment (Pedersen Commitment):** **D Commitment (Randomness):** **Together they enable:** - ✅ Encrypted amounts in transactions - ✅ Verifiable without revealing amounts - ✅ Homomorphic balance updates **Source:** cryptography/crypto/algebra_elgamal.go - ElGamal encryption implementation Technical Specifications | Aspect | Details | |--------|---------| | **Encryption Scheme** | ElGamal (additive homomorphism) | | **Curve** | bn256 (Barreto-Naehrig) curve | | **Security** | Discrete logarithm problem | | **Commitment Size** | 66 bytes (33 left + 33 right) | | **Trusted Setup** | ❌ None required | --- Key Takeaways What Homomorphic Encryption Provides | Feature | Benefit | Impact | |---------|---------|--------| | **🔒 Encrypted Balances** | Always encrypted | Perfect privacy | | **➕ Math on Encrypted** | Operations without decryption | Privacy never broken | | **⚡ Instant Queries** | No chain scanning | Fast balance checks | | **🔐 Private Tokens** | Encrypted token balances | Complete privacy | | **✅ Verifiable** | Network can verify | Security maintained | | **🚫 No Trusted Setup** | Pure cryptography | Decentralized | What It Enables - ✅ **Private Smart Contracts** - Impossible on other chains - ✅ **Instant Balance Lookup** - No blockchain scanning - ✅ **Encrypted Token Systems** - Private token transfers - ✅ **Private DeFi** - Encrypted swap operations - ✅ **Account-Based Privacy** - First blockchain to achieve this **Architectural Breakthrough:** Account-based blockchains were thought incompatible with strong privacy. DERO proved this assumption wrong through homomorphic encryption, enabling private smart contracts with encrypted balances. --- Related Pages **Privacy Suite:** - Ring Signatures - Transaction anonymity - Bulletproofs - Zero-knowledge range proofs - Transaction Privacy - Complete privacy flow - Payload Proofs - Prove transfers cryptographically **Technical Implementation:** - DERO Tokens - How tokens use homomorphic encryption - Private Smart Contracts - Contract encrypted balances **Build with Privacy:** - Token Contract - Private token example - Wallet RPC API - Send private transactions",
+      "plainText": "Homomorphic Encryption: Math on Locked Boxes **The Innovation:** Do math on encrypted balances without ever decrypting them. Your balance stays private. Forever. Even the blockchain never sees it. What Problem Does It Solve? **The Challenge:** **The Solution: Homomorphic Encryption** - ✅ Math happens on encrypted data - ✅ No decryption ever required - ✅ Privacy never broken - ✅ Blockchain can verify without seeing amounts --- The Simple Analogy **Locked Safe (Regular Encryption)** **Magic Safe (Homomorphic Encryption)** **For DERO:** - Balance is **always** encrypted (safe always locked) - Math happens on the encrypted number - Safe never opens - Blockchain never sees actual balance --- How It Works The Encryption Flow **The Setup:** Encrypting an Amount **Conceptual flow** (actual implementation: CommitElGamal at cryptography/crypto/algebra_elgamal.go:44-50; the numbered steps below are docs annotations, not source comments): | Step | What Happens | What Network Sees | |------|-------------|-------------------| | **1. Pick random 'r'** | Generate random number | Nothing | | **2. Calculate L** | L = 100×G + r×P | Random elliptic curve point | | **3. Calculate R** | R = r×G | Random elliptic curve point | | **4. Result** | E(100) = (L, R) | Random points (no amount visible) | The Magic: Homomorphic Operations **Addition & Subtraction on Encrypted Data:** **The Math:** **Mathematical Guarantee:** Based on the elliptic curve discrete logarithm problem on the bn256 (Barreto-Naehrig) curve. --- Transaction Flow: Alice → Bob **Alice sends 100 DERO to Bob:** **Teaching abstraction, not literal verifier flow.** The diagram above shows the *intuition* — value conservation across encrypted balances. The actual verifier does not perform explicit ciphertext arithmetic like E(500) + E(200) = E(400) + E(300) at consensus. Balance conservation is enforced by the sigma proof structure: A_b (one of the six sigma commitments) commits to the balance-update polynomial relation, and the prover must produce a valid proof that the relation holds for the encrypted before/after values. The verifier checks the proof, not the arithmetic. See proof_verify.go:98 for the actual Verify() entry point and proof_generate.go for what A_b commits to. What Happens at Each Step **Initial State** **Create Transfer** **Homomorphic Operations** **Final State** --- Comparison: Traditional vs DERO Balance Storage | Aspect | Traditional Blockchain | DERO Blockchain | |--------|----------------------|-----------------| | **Account** | alice.eth | dero1qy... | | **Balance shown** | 500 ETH 👁️ Public | E(???) 🔒 Encrypted | | **Everyone sees** | Exact amount | Random bytes (66 bytes) | | **Only owner sees** | Same as everyone | Actual balance (with private key) | | **Privacy** | ❌ Zero | ✅ Complete | | **Balance lookup** | Instant (public) | Instant (encrypted) | **The Difference:** - **Bitcoin/Ethereum:** Your balance is like your bank statement posted on a billboard - **DERO:** Your balance is permanently locked in a safe only you can open Blockchain Architecture Comparison | Feature | Bitcoin/UTXO | Ethereum (Account) | DERO (Account + Encrypted) | |---------|-------------|-------------------|---------------------------| | **Model** | Outputs | Accounts | Accounts | | **Privacy** | ❌ Pseudonymous | ❌ None | ✅ Encrypted | | **Smart Contracts** | ❌ Limited | ✅ Yes, public | ✅ Yes, **private** | | **Confirmations** | Slower | Fast | Fast | | **Balance Lookup** | Scan chain | Instant | Instant + private | **DERO = Ethereum's simplicity + Privacy coin encryption** 🎯 --- Real-World Applications 1. Instant Balance Queries **Traditional Privacy Coin:** **DERO:** 2. Private Token Systems **How It Works:** **Key Points:** **Source** (verbatim from tests/normal/multi_deposit_test/asset.bas:11-15): The SEND_ASSET_TO_ADDRESS DVM function is registered at dvm/dvm_functions.go:80; the BASIC sample above is the canonical example contract in the test suite. **Traditional tokens (ERC-20):** Balances public in contract **DERO tokens:** Balances encrypted in user wallets, transferable peer-to-peer 3. Private DeFi Operations **Swap Example:** --- Technical Implementation The C and D Commitments Every DERO transaction contains encrypted commitments: **C Commitment (per ring member — ElGamal-style, not Pedersen):** > **Why this is not Pedersen.** Pedersen uses a fixed generator pair (G, H). DERO's per-ring construction reuses each ring member's public key as the second generator (r × pubkey[i]), which is what makes the same encryption serve both as an anonymity-set commitment and as a per-receiver decryption hint. The two families share the homomorphic add property; the security argument differs. **D Commitment (shared across the whole anonymity set, not per recipient):** **Together they enable:** - ✅ Encrypted amounts in transactions - ✅ Verifiable without revealing amounts - ✅ Homomorphic balance updates **Source:** cryptography/crypto/algebra_elgamal.go — ElGamal encryption implementation. Key entry points: CommitElGamal at algebra_elgamal.go:44 (encryption / commitment construction) and Add at algebra_elgamal.go:69 (homomorphic ciphertext addition). Technical Specifications | Aspect | Details | |--------|---------| | **Encryption Scheme** | ElGamal (additive homomorphism) | | **Curve** | bn256 (Barreto-Naehrig) curve | | **Security** | Discrete logarithm problem | | **Commitment Size** | 66 bytes (33 left + 33 right) | | **Trusted Setup** | ❌ None required | --- Key Takeaways What Homomorphic Encryption Provides | Feature | Benefit | Impact | |---------|---------|--------| | **🔒 Encrypted Balances** | Always encrypted | Perfect privacy | | **➕ Math on Encrypted** | Operations without decryption | Privacy never broken | | **⚡ Instant Queries** | No chain scanning | Fast balance checks | | **🔐 Private Tokens** | Encrypted token balances | Complete privacy | | **✅ Verifiable** | Network can verify | Security maintained | | **🚫 No Trusted Setup** | Pure cryptography | Decentralized | What It Enables - ✅ **Private Smart Contracts** - Impossible on other chains - ✅ **Instant Balance Lookup** - No blockchain scanning - ✅ **Encrypted Token Systems** - Private token transfers - ✅ **Private DeFi** - Encrypted swap operations - ✅ **Account-Based Privacy** - First blockchain to achieve this **Architectural Breakthrough:** Account-based blockchains were thought incompatible with strong privacy. DERO proved this assumption wrong through homomorphic encryption, enabling private smart contracts with encrypted balances. --- Related Pages **Privacy Suite:** - Ring Signatures - Transaction anonymity - Bulletproofs - Zero-knowledge range proofs - Transaction Privacy - Complete privacy flow - Payload Proofs - Prove transfers cryptographically **Technical Implementation:** - DERO Tokens - How tokens use homomorphic encryption - Private Smart Contracts - Contract encrypted balances **Build with Privacy:** - Token Contract - Private token example - Wallet RPC API - Send private transactions",
       "lastUpdated": "2026-01-26"
     },
     {
@@ -1256,28 +1261,25 @@
       "slug": "privacy/payload-proofs",
       "title": "Understanding DERO Payload Proofs: Privacy by Design | DERO Blockchain",
       "description": "Learn how DERO's two-proof system works, why ring members can show successful verification, and how this intentional ambiguity protects sender privacy through ring signatures.",
-      "canonicalUrl": "https://derod.org/features/payload-proofs",
+      "canonicalUrl": "https://derod.org/features/payload-proofs.md",
       "sourcePath": "derod-main/pages/privacy/payload-proofs.mdx",
       "headings": [
-        "DERO Payload Proofs: Privacy That Actually Works",
-        "Why DERO Privacy Works",
+        "DERO Payload Proofs",
+        "How payload-proof ambiguity works",
         "How This Compares to Other Privacy Coins",
-        "Two Proof Types (Standard in Privacy Blockchains)",
-        "Two Proof Types",
         "How It Works",
         "How Ring Signatures Protect Privacy",
-        "Recognizing Authentic Transaction Metadata",
+        "Decoded Payload — Receiver's View Only",
         "What Explorers Can and Cannot Show",
         "Why Payload Proofs Can Be Faked",
-        "Payload Proofs Are Wallet-Level Tools",
         "Best Practices",
         "Technical Deep Dive",
-        "Why All Ring Members Use Same Amount",
-        "DERO's Privacy-First Design Choice",
+        "Why Ring-Member Commitments Are Indistinguishable",
+        "DERO's privacy posture",
         "The Bottom Line",
         "Related Pages"
       ],
-      "plainText": "DERO Payload Proofs: Privacy That Actually Works **Privacy Success:** Only YOU (with your private keys) can prove you sent a transaction. Third parties can only make guesses - exactly as designed for maximum privacy! Why DERO Privacy Works DERO uses **ring signatures** to provide class-leading transaction privacy. When you send a transaction, your real output is hidden among ring_size/2 potential senders (rings are split evenly between senders and recipients). This creates **plausible deniability**: observers cannot determine who actually sent the transaction. **This is a feature, not a bug.** If third parties could easily prove who sent what, privacy would be broken. How This Compares to Other Privacy Coins | Feature | DERO | Zcash (Shielded) | Bitcoin/Ethereum | |---------|------|-------------------|------------------| | **Ring Signatures** | ✅ 2-128 members | ❌ No rings | ❌ No privacy | | **Third-party Proof** | ❌ Ambiguous (private) | ✅ Transparent (viewkeys) | ✅ Fully public | | **Explorer Verification** | ⚠️ Probabilistic | ✅ Exact (less private) | ✅ Exact (no privacy) | | **Sender Privacy** | ✅ Maximum | 🟡 Opt-in viewkeys | ❌ None | **DERO's privacy model:** Third parties cannot definitively prove who sent a transaction. **This is the entire point of privacy technology!** Two Proof Types (Standard in Privacy Blockchains) | Proof Type | What It Does | Security Level | |-----------|--------------|----------------| | **Transaction Proof** | Validates blockchain consensus | 🔒 Cryptographically secure | | **Payload Proof** | Shows metadata (amount, recipient) | ⚠️ Convenience only, not cryptographic | **Important:** Explorers show **payload proofs** (convenience), not **transaction proofs** (cryptographic). This is standard across all privacy blockchains with ring signatures. --- Two Proof Types | Feature | Transaction Proofs | Payload Proofs | |---------|-------------------|----------------| | **Verified By** | All network nodes | Explorer software only | | **Security** | Cryptographically secure | Math consistency only | | **Can Be Faked?** | ❌ No | ⚠️ Yes | | **Checks** | Bulletproofs, range proofs, signatures | Commitment matching | | **Purpose** | Blockchain consensus | Display convenience | | **Shows** | Transaction validity | Amounts, addresses, comments | | **Trust Level** | Trustless | User-provided data | **For Certainty:** Use your wallet with private keys. Payload proofs are convenience tools, not cryptographic guarantees. --- How It Works **What this proves:** - ✅ Address is in ring - ✅ Math is consistent - ❌ **NOT** that this address sent the transaction How Ring Signatures Protect Privacy **Ring signatures hide the real sender among decoys (2-128 addresses)** All ring members use identical commitment structures with the **same amount**. This is mathematically required for privacy - if different amounts were visible, you could identify the sender. Rings are split evenly — half the members are potential senders, half are potential recipients. **Mathematical Privacy:** **Result:** Plausible deniability for all ring members. **This is how privacy works** - ambiguity protects identity in all ring-signature-based privacy systems. **Technical Note:** When an address is included as a ring member (decoy), its encrypted balance changes due to homomorphic operations, even though the address performed no actions. This is cryptographically required behavior - all ring members' encrypted balances participate in the transaction. Observing encrypted balance changes alone cannot identify the real sender, as this happens for all ring members by design. *Learn more: Ring Signatures - Encrypted Balance Changes* --- Recognizing Authentic Transaction Metadata Real senders typically include encrypted metadata (destination address, comment, amount). This helps wallets display transaction history. | Indicator | Authentic Sender | Ring Decoy | |-----------|------------------|------------| | **Payload** | Encrypted data (random bytes) | Often empty or sparse | | **Decoded** | Valid encrypted structure | Minimal data | | **Comment** | Encrypted message | Usually absent | | **Metadata** | Complete fields | Partial fields | **Note:** This is an observation, not a guarantee. Privacy systems require uncertainty - that's the entire point. What Explorers Can and Cannot Show **This applies to ALL privacy blockchains that use ring signatures** | Check Type | Explorer CAN Verify | Explorer CANNOT Verify (Privacy Protection) | |------------|---------------------|---------------------------------------------| | **Ring Membership** | ✅ Address is in the ring | ❌ Which address actually sent (privacy!) | | **Math Consistency** | ✅ Commitment calculations | ❌ Cryptographic proof of specific sender | | **Transaction Validity** | ✅ Transaction is on-chain | ❌ Which ring member is real | | **Amount Bounds** | ✅ Amount is reasonable | ❌ Proof cannot be for another member | **Why this is correct:** Privacy requires plausible deniability. If explorers could prove the exact sender, ring signatures would be useless. --- Why Payload Proofs Can Be Faked Payload Proofs Are Wallet-Level Tools **Key Distinction:** | Proof Type | Scope | Validation | Can Be Faked? | |-----------|-------|-----------|---------------| | **Transaction Proof** | Blockchain consensus | Cryptographic verification by all nodes | ❌ No | | **Payload Proof** | Explorer display | Math consistency check only | ⚠️ Yes | **Why Payload Proofs Can Be Faked:** 1. **User-Provided Data** - Payload proofs contain user-submitted metadata - Not cryptographically bound to transaction - Anyone can create matching proof for any ring member 2. **Math Consistency Only** - Explorer verifies: commitment = amount × G + address - Does NOT verify: This address was the actual sender - Any ring member can generate matching proof 3. **No Cryptographic Binding** - Payload proofs are separate from transaction proofs - They don't affect blockchain consensus - Fake proofs don't invalidate transactions **From Source Code** (proof/proof.go:34-149, cmd/explorer/explorerlib/explorerlib.go:689): The payload proof system is designed for **convenience and display**, not cryptographic verification. The explorer checks if the proof's commitment matches any ring member's commitment, but this doesn't prove the sender identity. **Code Evidence:** **Explorer Call** (cmd/explorer/explorerlib/explorerlib.go:689): **Why This Design is Correct:** - ✅ If explorers could prove exact senders, ring signatures would be useless - ✅ Allows users to verify their own transactions - ✅ Users can generate proofs for any ring member (privacy feature) - ✅ All ring-signature privacy coins work this way **For Real Verification:** - Use your wallet with private keys (only you can prove you sent) - Transaction proofs are cryptographically secure (network consensus) - Payload proofs are convenience tools (explorer display) --- Best Practices **For Users:** - ✅ **Certainty:** Check YOUR wallet with private keys - ✅ **Convenience:** Use payload proofs for general verification - ⚠️ **Understand:** Explorers show possibilities, not proof of sender **For Developers:** - 📚 **Educate:** Explain transaction vs payload proofs - 🔒 **Privacy First:** Don't promise definitive sender identification - ✅ **Standard Practice:** Ring signature privacy requires plausible deniability --- Technical Deep Dive Why All Ring Members Use Same Amount **Privacy Requirement:** **Result:** Cannot identify sender by commitment inspection **Trade-off:** Any ring member can generate \"valid\" proof DERO's Privacy-First Design Choice **Privacy blockchains make a fundamental choice:** | Approach | Benefits | Trade-offs | Used By | |----------|----------|------------|---------| | **Maximum Privacy** | Complete sender anonymity | Third parties use own wallets to verify | DERO | | **Optional Privacy** | User controls disclosure | Privacy only if used correctly | Zcash | | **Public Ledger** | Full transparency | No privacy | Bitcoin, Ethereum | **DERO's Choice:** Maximum privacy by default ✅ **Why this matters:** Privacy coins protect users from surveillance, financial tracking, and targeted attacks. Ambiguous proof verification is **proof that privacy works**. --- The Bottom Line **DERO delivers real privacy:** ✅ **Your transactions are private** - Only you can prove what you sent ✅ **Industry-standard technology** - Ring signatures proven in cryptography research ✅ **Mathematically secure** - Homomorphic encryption + bulletproofs ✅ **Working as designed** - Ambiguous proofs = successful privacy **Privacy through plausible deniability:** Observers see possibilities, not certainties. This is mathematically enforced and prevents mass surveillance. **Comparison:** Bitcoin/Ethereum explorers show exact senders (zero privacy). DERO explorers show possibilities (maximum privacy). You choose which model you prefer. --- --- Related Pages **Privacy Features:** - Transaction Privacy - How transactions stay private - Homomorphic Encryption - Why balances are encrypted - Ring Signatures - Sender anonymity **Use Cases:** - DERO Tokens - Prove token transfers - Private Smart Contracts - Prove SC interactions **For Developers:** - Wallet RPC API - Generate payload proofs - Daemon RPC API - Verify proofs on-chain",
+      "plainText": "DERO Payload Proofs **Privacy by construction:** Only you (holding the private key) can prove you sent a transaction. Third parties can guess but cannot prove — by design, so ring-signature plausible deniability remains intact. *For the integrity angle — why explorer \"Verified ✓\" on a payload proof isn't evidence of consensus — see Proof Types Explained.* **Naming note:** \"Ring signature\" is the user-facing name DERO uses for what the source actually implements as an Anonymous Zether-style anonymity-set ZK proof (see cryptography/crypto/proof_generate.go and proof_verify.go). The user-facing term is colloquial; the construction is not a classical (Schnorr/LSAG/MLSAG) ring signature. How payload-proof ambiguity works DERO uses **ring signatures** to hide the sender. When you send a transaction, your real sender slot is hidden among ring_size/2 potential senders (rings are split evenly between sender-parity and receiver-parity slots; DERO is account-based, so there are no outputs to hide — only signing positions within the anonymity set), creating **plausible deniability** — observers cannot determine who actually sent the transaction. That ambiguity is what makes payload-proof verification ambiguous. If a third party could verify exactly who sent what, ring signatures would not provide privacy. How This Compares to Other Privacy Coins | Feature | DERO | Zcash (Shielded) | Bitcoin/Ethereum | |---------|------|-------------------|------------------| | **Ring Signatures** | ✅ 2-128 members | ❌ No rings | ❌ No privacy | | **Third-party Proof** | ❌ Ambiguous (private) | ✅ Transparent (viewkeys) | ✅ Fully public | | **Explorer Verification** | ⚠️ Probabilistic | ✅ Exact (less private) | ✅ Exact (no privacy) | | **Sender Privacy** | ✅ Maximum | 🟡 Opt-in viewkeys | ❌ None | **DERO's privacy model:** Third parties cannot definitively prove who sent a transaction — this is the point of ring-signature privacy. --- How It Works **What this proves:** - ✅ Address is in ring - ✅ Math is consistent - ❌ **NOT** that this address sent the transaction How Ring Signatures Protect Privacy **Ring signatures hide the real sender among decoys (2-128 addresses)** All ring members use identical commitment structures with the **same amount**. This is mathematically required for privacy - if different amounts were visible, you could identify the sender. Rings are split evenly — half the members are potential senders, half are potential recipients. **Mathematical Privacy** (actual per-ring construction, walletapi/transaction_build.go:152-206): Each ring slot's commitment uses that slot's own **public key** as the second generator — this is what makes the same encryption serve both as anonymity-set membership and as a per-receiver decryption hint. **Result:** Plausible deniability for all ring members. This is the standard ring-signature mechanism — observable ambiguity is what protects sender identity. **Technical Note:** When an address is included as a ring member (decoy), its encrypted balance changes due to homomorphic operations, even though the address performed no actions. This is cryptographically required behavior - all ring members' encrypted balances participate in the transaction. Observing encrypted balance changes alone cannot identify the real sender, as this happens for all ring members by design. *Learn more: Ring Signatures - Encrypted Balance Changes* --- Decoded Payload — Receiver's View Only A real transaction carries an encrypted payload (destination address, optional comment, amount) inside the per-ring-member commitment structure. **Only the intended receiver can decrypt that payload** (using their secret key plus the shared D ElGamal half — see Ring Signatures: encrypted balance changes). The table below describes what the **receiver's wallet** sees after successful decryption of *its own* slot — not what a third-party observer sees on chain. | Indicator | What the receiver's wallet shows (after decrypt) | |-----------|---------------------------------------------------| | **Payload** | The plaintext fields the sender embedded for this receiver | | **Decoded** | Address, amount, comment recovered | | **Comment** | The plaintext comment, if the sender included one | | **Metadata** | The fields the sender chose to include | **Third-party observers see encrypted bytes for all 16 ring members identically.** They cannot use payload contents to identify the sender, the receiver, or the real ring slots — every slot looks the same on chain. The \"indicators\" above are wallet UX after decryption, not chain-level forensic signals. What Explorers Can and Cannot Show **This applies to ALL privacy blockchains that use ring signatures** | Check Type | Explorer CAN Verify | Explorer CANNOT Verify (Privacy Protection) | |------------|---------------------|---------------------------------------------| | **Ring Membership** | ✅ Address is in the ring | ❌ Which address actually sent (privacy!) | | **Math Consistency** | ✅ Commitment calculations | ❌ Cryptographic proof of specific sender | | **Transaction Validity** | ✅ Transaction is on-chain | ❌ Which ring member is real | | **Amount Bounds** | ✅ Amount is reasonable | ❌ Proof cannot be for another member | **Why this is correct:** Privacy requires plausible deniability. If explorers could prove the exact sender, ring signatures would be useless. --- Why Payload Proofs Can Be Faked The ambiguity that protects sender privacy comes at a cost: **any ring member can generate a verifying payload proof for the transaction.** This is not a defect — it is the visible consequence of how the anonymity-set construction works. The explorer's verification (proof.go:88-95) recomputes amount × G + shared_key and checks for a match against any ring commitment C[k]; since C[k] = ±amount × G + r × pubkey[k] and shared_key is derived from the proof string itself, the equation can be made to fit for any k by choosing a compatible shared_key (see Why Ring-Member Commitments Are Indistinguishable below). If only the real sender could produce a verifying proof, ring-signature privacy would not exist. Third parties cannot use payload-proof verification as cryptographic evidence of *who sent what*. **For the integrity-framed perspective** — why payload-proof \"Verified ✓\" in an explorer is not the same as consensus acceptance, and not evidence of chain state — see Proof Types Explained. --- Best Practices **For Users:** - ✅ **Certainty:** Check YOUR wallet with private keys - ✅ **Convenience:** Use payload proofs for general verification - ⚠️ **Understand:** Explorers show possibilities, not proof of sender **For Developers:** - 📚 **Educate:** Explain transaction vs payload proofs - 🔒 **Privacy First:** Don't promise definitive sender identification - ✅ **Standard Practice:** Ring signature privacy requires plausible deniability --- Technical Deep Dive Why Ring-Member Commitments Are Indistinguishable **Privacy Requirement:** If ring-slot commitments had obviously identifying differences (different generator pairs, different randomness sources, missing terms), an observer could: → identify the sender by inspection → break ring-signature privacy DERO's construction uses the **same algebraic shape** for every ring slot, with a single transaction-wide blinding scalar r (walletapi/transaction_build.go:152-206): The amount sign and value differ per slot, but the **construction is identical** — an observer sees 16 commitments of the same algebraic form, computed against the same r. Without the secret keys, none of them is distinguishable as \"the sender's\" or \"the receiver's.\" **Result:** Cannot identify sender by commitment inspection **Trade-off:** Any ring member's pubkey can be paired with an arbitrary amount + derived shared key to forge a \"valid\" payload proof — see the forgery walkthrough DERO's privacy posture Privacy blockchains make different trade-offs: | Approach | Benefits | Trade-offs | Used By | |----------|----------|------------|---------| | **Privacy by default** | Sender hidden among ring decoys; amounts encrypted | Third parties cannot verify the sender — must use their own wallet | DERO | | **Optional privacy** | User controls disclosure | Privacy only if explicitly used | Zcash | | **Public ledger** | Full transparency | No privacy | Bitcoin, Ethereum | DERO opts for privacy by default. Payload-proof ambiguity isn't a flaw — it's the visible consequence of the ring-signature construction. --- The Bottom Line **What payload proofs are, and aren't:** - **They are:** wallet-level display tools. Only you, with your private key, can prove you sent a specific transaction. - **They aren't:** a cryptographic identifier of the sender. Any ring member can generate a verifying payload proof for a given transaction. That ambiguity is the visible consequence of how ring signatures work. Bitcoin and Ethereum explorers show exact senders; DERO explorers show ring members. The trade-off is third-party verifiability for sender privacy. --- --- Related Pages **Privacy Features:** - Transaction Privacy - How transactions stay private - Homomorphic Encryption - Why balances are encrypted - Ring Signatures - Sender anonymity **Use Cases:** - DERO Tokens - Prove token transfers - Private Smart Contracts - Prove SC interactions **For Developers:** - Wallet RPC API - Generate payload proofs - Daemon RPC API - Verify proofs on-chain",
       "lastUpdated": "2026-01-26"
     },
     {
@@ -1285,7 +1287,7 @@
       "slug": "privacy/private-smart-contracts",
       "title": "Private Smart Contracts: DERO's Token Privacy Innovation | DERO Blockchain",
       "description": "Learn how DERO smart contracts issue tokens that become encrypted wallet balances - enabling private token transfers and rug-pull resistance through homomorphic encryption.",
-      "canonicalUrl": "https://derod.org/privacy/private-smart-contracts",
+      "canonicalUrl": "https://derod.org/privacy/private-smart-contracts.md",
       "sourcePath": "derod-main/pages/privacy/private-smart-contracts.mdx",
       "headings": [
         "Private Smart Contracts",
@@ -1323,7 +1325,7 @@
       "slug": "privacy/ring-signatures",
       "title": "Ring Signatures: DERO's Sender Privacy Mechanism | DERO Blockchain",
       "description": "How DERO's ring signatures hide sender identity among groups of 2-128 members, providing plausible deniability through proven cryptographic techniques.",
-      "canonicalUrl": "https://derod.org/privacy/ring-signatures",
+      "canonicalUrl": "https://derod.org/privacy/ring-signatures.md",
       "sourcePath": "derod-main/pages/privacy/ring-signatures.mdx",
       "headings": [
         "Ring Signatures",
@@ -1335,7 +1337,7 @@
         "The Rule",
         "Cryptographic Enforcement",
         "Concrete Example: Ring Size 16",
-        "Why Ring Size 2 Offers No Sender Privacy",
+        "Why Ring Size 2 Offers No Anonymity Set",
         "Verify It Yourself",
         "Encrypted Balance Changes for Ring Members",
         "What Ring Signatures Protect",
@@ -1345,7 +1347,7 @@
         "Key Takeaways",
         "Related Pages"
       ],
-      "plainText": "Ring Signatures **Core Concept:** Your address is mixed with others in a ring of 2-128. Rings are split evenly between senders and recipients — only half are possible senders. The blockchain can't determine which one actually sent. How It Works **Traditional signature:** **Ring signature:** --- Ring Size Impact | Ring Size | Privacy Level | TX Size (bytes) | Naive Guess Probability | |-----------|---------------|----------------|-------------------------| | 2 | Minimal | 1553 | 1 in 1 (no sender privacy) | | 4 | Low | 2013 | 1 in 2 | | 8 | Medium | 2605 | 1 in 4 | | 16 | Good | 3461 | 1 in 8 | | 32 | Strong | 4825 | 1 in 16 | | 64 | Very Strong | 7285 | 1 in 32 | | 128 | Maximum | 11839 | 1 in 64 | **Note:** Rings are split evenly — half the members are potential senders, half are potential recipients. The naive guess probability is therefore 1/(ring_size/2), not 1/ring_size. Ring size 2 (1 sender slot, 1 recipient slot) provides no meaningful sender privacy. **Sources:** - Ring size limits: config/config.go:58-59 - Transaction sizes: README.md (Transactions Sizes table) --- Real Example **Transaction:** 4b2ebb476849260f077865756b74248a3ced966628b82eb10cdc56482b852d59 **Blockchain shows (for this example ring):** - ✓ 8 possible senders (half the ring) - ✗ Amount (encrypted) - ✗ Cannot determine real sender - ✗ Cannot link to other TXs --- How Ring Members Are Selected **From source code** (cmd/derod/rpc/rpc_dero_getrandomaddress.go): **Why unchanged balances?** - Better decoys (less likely to exclude) - Prevents timing attacks - More plausible anonymity --- The Parity Constraint: How the Ring Is Split The even/odd split between sender and recipient positions is not a convention — it is a hard constraint enforced at both the wallet layer and the cryptographic proof layer. The Rule When the wallet shuffles ring positions, it keeps shuffling until the sender and receiver land on indices of **different parity** (one even, one odd). **From source code** (walletapi/transaction_build.go:79-90): The comment in the source says it plainly: sender and receiver must not share parity. One occupies an even index; the other occupies an odd index. Cryptographic Enforcement The proof generation encodes this split into two separate polynomial sets — P for even-indexed ring members, Q for odd-indexed ring members. An observer cannot determine which parity the sender occupies. **From source code** (cryptography/crypto/proof_generate.go:700-710): The witness index itself is encoded as an 8-bit string (for ring size 16, m=4 bits per role) that interleaves sender and receiver positions (proof_generate.go:523): This structure means the proof system treats even and odd positions as fundamentally separate roles — an attacker cannot forge a valid proof by swapping one for the other. Concrete Example: Ring Size 16 - **8 even indices** (0, 2, 4, 6, 8, 10, 12, 14) — one parity role - **8 odd indices** (1, 3, 5, 7, 9, 11, 13, 15) — the other parity role - The sender is one of the 8 members in their parity group → probability of correct identification: **1/8 = 12.5%** Why Ring Size 2 Offers No Sender Privacy With ring size 2: one even slot (index 0), one odd slot (index 1). The sender occupies one slot, the recipient the other. An observer who knows which parity role is \"sender\" trivially identifies both parties. This is why ring size 2 is listed as \"no sender privacy\" in the table above. Verify It Yourself | Protection | File | Lines | |------------|------|-------| | Parity constraint (wallet) | walletapi/transaction_build.go | 79-90 | | P/Q polynomial split (proof) | cryptography/crypto/proof_generate.go | 700-710 | | Witness index encoding | cryptography/crypto/proof_generate.go | 523 | | Ring size limits | config/config.go | 58-59 | --- Encrypted Balance Changes for Ring Members When an address is included as a ring member (decoy) in a transaction, its encrypted balance changes even though the address performed no actions. This is **normal behavior** and part of how ring signatures provide privacy. **From source code** (walletapi/daemon_communication.go): **What this means:** 1. Address with zero balance (never used) is selected as ring decoy 2. Encrypted balance changes due to homomorphic operations 3. This is **by design** - all ring members' encrypted balances participate in the transaction 4. The address didn't send anything; it was just included in the ring **Why this is important:** - Encrypted balance changes don't indicate the address was the sender - Ring members are passive participants in the privacy mechanism - This behavior is cryptographically required for ring signatures to work - Observing encrypted balance changes alone cannot identify the real sender **This is normal ring signature behavior, not a protocol flaw.** --- What Ring Signatures Protect | Threat | Protected? | How | |--------|-----------|-----| | **Sender Identity** | ✅ Yes | Hidden among ring members | | **Transaction Linking** | ✅ Yes | Each TX has independent ring | | **Third-Party Attribution** | ✅ Yes | Plausible deniability | | **Transaction Amounts** | ❌ No | Needs homomorphic encryption | | **Network Activity** | ❌ No | Needs TLS/Tor | **Ring signatures = Sender privacy ONLY** For complete privacy: Ring sigs + Homomorphic encryption + Bulletproofs + TLS --- Why ANY Ring Member Can Generate Proof All ring members use **same amount** in commitments: **Result:** Anyone can pick ANY member, calculate commitment, create \"valid\" proof. **This is privacy working as designed** - you can't identify sender by inspection! *Learn more: Payload Proofs* --- Best Practices **For Maximum Privacy:** - Ring size: 64-128 - Vary transaction timing - Run own node **For Balanced Privacy (Recommended):** - Ring size: 16 - Standard network - Trusted or own node **For Developers:** --- Common Misconceptions | Myth | Reality | |------|---------| | \"Ring sigs = complete anonymity\" | Strong privacy, not absolute. 1 in (N/2) chance | | \"Bigger always better\" | Trade-off: Privacy vs TX size | | \"Ring members know they're in ring\" | No - passive selection, no notification | | \"Decoys must be online\" | No - only their public keys used | | \"Encrypted balance change = sender\" | No - ring members' balances change by design even as decoys | --- Key Takeaways **What ring signatures provide:** - ✅ Sender identity hidden (1 in 1-64, i.e. 1 in ring_size/2) - ✅ Plausible deniability (\"might be decoy\") - ✅ Transaction unlinkability - ✅ No trusted setup needed - ✅ Proven cryptography **What they don't provide:** - ❌ Amount privacy (use homomorphic encryption) - ❌ Network privacy (use TLS/Tor) - ❌ Absolute anonymity (probabilistic hiding) **Plausible Deniability:** If accused of sending a transaction, you can truthfully say \"I might be just a decoy\" - and nobody can prove otherwise! --- Related Pages **Privacy Suite:** - Homomorphic Encryption - Encrypted balances - Bulletproofs - Range proofs - Transaction Privacy - Complete privacy model - Account-Based Privacy - Stealth addresses **How It Works:** - DERO Tokens - Ring signatures in token transfers - Transaction Structure - Ring member selection **For Developers:** - Wallet RPC API - Set ring size in transfers - DERO Daemon - Network anonymity layer",
+      "plainText": "Ring Signatures **Core Concept:** Your address is mixed with others in a ring of 2-128. Rings are split evenly between senders and recipients — only half are possible senders. The blockchain can't determine which one actually sent. **Naming note:** \"Ring signature\" is the user-facing name DERO uses for what the source actually implements as an Anonymous Zether-style anonymity-set ZK proof (see cryptography/crypto/proof_generate.go and proof_verify.go). The user-facing term is colloquial; the construction is not a classical (Schnorr/LSAG/MLSAG) ring signature. How It Works **Traditional signature:** **Ring signature:** --- Ring Size Impact | Ring Size | Privacy Level | TX Size (bytes) | Naive Guess Probability | |-----------|---------------|----------------|-------------------------| | 2 | Minimal | 1553 | 1 in 1 (no sender privacy) | | 4 | Low | 2013 | 1 in 2 | | 8 | Medium | 2605 | 1 in 4 | | 16 | Good | 3461 | 1 in 8 | | 32 | Strong | 4825 | 1 in 16 | | 64 | Very Strong | 7285 | 1 in 32 | | 128 | Maximum | 11839 | 1 in 64 | **Note:** Rings are split evenly — half the members are potential senders, half are potential recipients. The naive guess probability is therefore 1/(ring_size/2), not 1/ring_size. Ring size 2 (1 sender slot, 1 recipient slot) provides no meaningful sender privacy. **Sources:** - Ring size limits: config/config.go:58-59 - Transaction sizes: README.md (Transactions Sizes table) --- Real Example **Transaction:** 4b2ebb476849260f077865756b74248a3ced966628b82eb10cdc56482b852d59 **Blockchain shows (for this example ring):** - ✓ 8 possible senders (half the ring) - ✗ Amount (encrypted) - ✗ Cannot determine real sender - ✗ Cannot link to other TXs --- How Ring Members Are Selected **Source** (cmd/derod/rpc/rpc_dero_getrandomaddress.go:80-111 — quoted verbatim): **Why unchanged balances?** - Better decoys (less likely to exclude) - Prevents timing attacks - More plausible anonymity --- The Parity Constraint: How the Ring Is Split The even/odd split between sender and recipient positions is not a convention — it is a hard constraint enforced at both the wallet layer and the cryptographic proof layer. The Rule When the wallet shuffles ring positions, it keeps shuffling until the sender and receiver land on indices of **different parity** (one even, one odd). **From source code** (walletapi/transaction_build.go:79-90): The comment in the source says it plainly: sender and receiver must not share parity. One occupies an even index; the other occupies an odd index. Cryptographic Enforcement The proof generation encodes this split into two separate polynomial sets — P for even-indexed ring members, Q for odd-indexed ring members. An observer cannot determine which parity the sender occupies. **Source** (cryptography/crypto/proof_generate.go:700-723 — code below is verbatim; the // docs: lines are docs annotations, not in source): The witness index itself is encoded as an 8-bit string (for ring size 16, m=4 bits per role) that interleaves sender and receiver positions (proof_generate.go:523): This structure means the proof system treats even and odd positions as fundamentally separate roles — an attacker cannot forge a valid proof by swapping one for the other. Concrete Example: Ring Size 16 - **8 even indices** (0, 2, 4, 6, 8, 10, 12, 14) — one parity role - **8 odd indices** (1, 3, 5, 7, 9, 11, 13, 15) — the other parity role - The sender is one of the 8 members in their parity group → probability of correct identification: **1/8 = 12.5%** Why Ring Size 2 Offers No Anonymity Set With ring size 2: one even slot (index 0), one odd slot (index 1). The sender occupies one slot, the recipient the other. The parity assignment itself (which parity is the sender's role) is **cryptographically hidden** — the verifier's parity check at cryptography/crypto/proof_verify.go:130-141 rejects malformed parity but does not reveal the assignment to observers. So an observer sees the two ring members and knows one sent and one received, but cannot tell from on-chain data alone which is which. The reason ring size 2 is listed as \"no sender privacy\" is not that the parity leaks — it's that there is **no anonymity set within the sender's parity role**: there is exactly one candidate sender (the lone member of that parity), so the sender's identity collapses to the singleton on that side. Any additional out-of-band signal (timing, IP, repeated patterns across transactions, known counter-party relationships) then resolves the pair trivially. Ring size 2 should therefore be treated as no meaningful anonymity, even though the parity itself remains hidden. Verify It Yourself | Protection | File | Lines | |------------|------|-------| | Parity constraint (wallet) | walletapi/transaction_build.go | 79-90 | | P/Q polynomial split (proof) | cryptography/crypto/proof_generate.go | 700-710 | | Witness index encoding | cryptography/crypto/proof_generate.go | 523 | | Ring size limits | config/config.go | 58-59 | --- Encrypted Balance Changes for Ring Members When an address is included as a ring member (decoy) in a transaction, its encrypted balance changes even though the address performed no actions. This is **normal behavior** and part of how ring signatures provide privacy. **Source** (walletapi/daemon_communication.go:863-903 — code below is verbatim; the // docs: lines are docs annotations, not in source): **What this means:** 1. Address with zero balance (never used) is selected as ring decoy 2. Encrypted balance changes due to homomorphic operations 3. This is **by design** - all ring members' encrypted balances participate in the transaction 4. The address didn't send anything; it was just included in the ring **Why this is important:** - Encrypted balance changes don't indicate the address was the sender - Ring members are passive participants in the privacy mechanism - This behavior is cryptographically required for ring signatures to work - Observing encrypted balance changes alone cannot identify the real sender **This is normal ring signature behavior, not a protocol flaw.** --- What Ring Signatures Protect | Threat | Protected? | How | |--------|-----------|-----| | **Sender Identity** | ✅ Yes | Hidden among ring members | | **Transaction Linking** | ✅ Yes | Each TX has independent ring | | **Third-Party Attribution** | ✅ Yes | Plausible deniability | | **Transaction Amounts** | ❌ No | Needs homomorphic encryption | | **Network Activity** | ❌ No | Needs TLS/Tor | **Ring signatures = Sender privacy ONLY** For complete privacy: Ring sigs + Homomorphic encryption + Bulletproofs + TLS --- Why ANY Ring Member Can Generate Proof All ring members use **same amount** in commitments: **Result:** Anyone can pick ANY member, calculate commitment, create \"valid\" proof. **This is privacy working as designed** - you can't identify sender by inspection! *Learn more: Payload Proofs* --- Best Practices **For Maximum Privacy:** - Ring size: 64-128 - Vary transaction timing - Run own node **For Balanced Privacy (Recommended):** - Ring size: 16 - Standard network - Trusted or own node **For Developers:** --- Common Misconceptions | Myth | Reality | |------|---------| | \"Ring sigs = complete anonymity\" | Strong privacy, not absolute. 1 in (N/2) chance | | \"Bigger always better\" | Trade-off: Privacy vs TX size | | \"Ring members know they're in ring\" | No - passive selection, no notification | | \"Decoys must be online\" | No - only their public keys used | | \"Encrypted balance change = sender\" | No - ring members' balances change by design even as decoys | --- Key Takeaways **What ring signatures provide:** - ✅ Sender identity hidden (1 in 1-64, i.e. 1 in ring_size/2) - ✅ Plausible deniability (\"might be decoy\") - ✅ Transaction unlinkability - ✅ No trusted setup needed - ✅ Proven cryptography **What they don't provide:** - ❌ Amount privacy (use homomorphic encryption) - ❌ Network privacy (use TLS/Tor) - ❌ Absolute anonymity (probabilistic hiding) **Plausible Deniability:** If accused of sending a transaction, you can truthfully say \"I might be just a decoy\" - and nobody can prove otherwise! --- Related Pages **Privacy Suite:** - Homomorphic Encryption - Encrypted balances - Bulletproofs - Range proofs - Transaction Privacy - Complete privacy model - Account-Based Privacy - Stealth addresses **How It Works:** - DERO Tokens - Ring signatures in token transfers - Transaction Structure - Ring member selection **For Developers:** - Wallet RPC API - Set ring size in transfers - DERO Daemon - Network anonymity layer",
       "lastUpdated": "2026-01-26"
     },
     {
@@ -1353,7 +1355,7 @@
       "slug": "privacy/transaction-privacy",
       "title": "Complete Transaction Privacy: How DERO Protects Your Data | DERO Blockchain",
       "description": "See how DERO's privacy layers work together - ring signatures, homomorphic encryption, bulletproofs, and network encryption protecting every transaction.",
-      "canonicalUrl": "https://derod.org/privacy/transaction-privacy",
+      "canonicalUrl": "https://derod.org/privacy/transaction-privacy.md",
       "sourcePath": "derod-main/pages/privacy/transaction-privacy.mdx",
       "headings": [
         "Complete Transaction Privacy",
@@ -1364,7 +1366,7 @@
         "Key Takeaways",
         "Related Pages"
       ],
-      "plainText": "Complete Transaction Privacy **Multi-Layer Defense:** DERO combines ring signatures, homomorphic encryption, bulletproofs, and TLS encryption. Even if one layer weakens, others protect your privacy. How Privacy Layers Work Together DERO's privacy isn't a single feature—it's four independent layers that work together. Each layer protects different aspects of your transaction, and they're designed so that even if one layer weakens, others maintain your privacy. **The Flow:** **How They Interact:** When you send a transaction, each layer adds privacy at a different stage. Network encryption protects your traffic from ISPs. Ring signatures hide which address sent the transaction. Homomorphic encryption keeps all amounts secret. Bulletproofs prove validity without revealing anything. Together, they create defense in depth—multiple barriers that protect your privacy even if one layer is compromised. **Source Code References:** - Network: p2p/controller.go (TLS encryption) - Sender: cryptography/crypto/proof_verify.go (ring signatures) - Amount: cryptography/crypto/algebra_elgamal.go (homomorphic encryption) - Proofs: cryptography/crypto/proof_generate.go and cryptography/crypto/proof_innerproduct.go (range proof + inner product) --- What Each Observer Sees Understanding what different parties can and cannot see helps illustrate how DERO's privacy layers work together in practice. | Observer | Can See | Cannot See | Why Privacy Maintained | |----------|---------|-----------|----------------------| | **ISP/Network** | Encrypted traffic to DERO | Transaction details, amounts, addresses | TLS encryption hides all content | | **Blockchain** | Ring (2-128 members), encrypted commitments | Real sender, actual amounts, balances | Ring signatures + homomorphic encryption | | **Chainalysis** | Transaction patterns, metadata | Definitive sender, amounts, proof of sending | Cannot prove specific sender identity | | **Bob (receiver)** | Amount, comment, sender position | Alice's balance, other transactions | Only sees his own transaction details | | **Alice (sender)** | Everything (has private keys) | - | Controls own privacy through wallet | --- Real Transaction Example **Alice → Bob: 100 DERO** --- Privacy at Each Stage | Stage | Privacy Added | Source Code | |-------|--------------|-------------| | **Creation** | Local only | walletapi/wallet_transfer.go:62 | | **Ring Formation** | Sender hiding | cryptography/crypto/proof_generate.go | | **Encryption** | Amount hiding | cryptography/crypto/algebra_elgamal.go:69 | | **Proofs** | ZK validation | cryptography/crypto/proof_generate.go + cryptography/crypto/proof_innerproduct.go | | **Broadcast** | Network encryption | p2p/controller.go (TLS) | | **Verification** | Homomorphic check | blockchain/transaction_execute.go:239 | --- Key Takeaways **What's Protected:** - Sender identity (hidden among ring_size/2 potential senders; naive guess probability is 1/(ring_size/2), e.g., 1/8 for ring size 16) - All amounts (encrypted with homomorphic encryption, never decrypted) - All balances (encrypted at all times) - Transaction linkage (unlinkable, independent rings per transaction) **What's Visible (Necessary for Function):** - Transaction occurred (required for processing) - Ring member list (creates ambiguity, actually protects privacy) - Timing metadata (doesn't reveal transaction details) **DERO's Design:** Privacy over third-party verification. Only you (with private keys) can prove you sent a transaction. Third parties cannot definitively prove sender identity—this is by design. Plausible deniability is a feature, not a bug. **Remember:** Privacy requires ambiguity. If you could prove to others you sent a transaction, your privacy would be broken. Plausible deniability is a feature, not a bug. --- Related Pages **Privacy Technologies:** - Homomorphic Encryption - Encrypted balances - Ring Signatures - Sender anonymity - Bulletproofs - Range proofs - Payload Proofs - Prove your transactions **Understanding Transactions:** - DERO Tokens - Private token transfers - Account-Based Privacy - Stealth addresses **For Users:** - DERO Wallets - Send private transactions - Wallet RPC API - Programmatic transfers",
+      "plainText": "Complete Transaction Privacy **Multi-Layer Defense:** DERO combines ring signatures, homomorphic encryption, bulletproofs, and TLS encryption. Even if one layer weakens, others protect your privacy. How Privacy Layers Work Together DERO's privacy is layered. Network encryption (TLS), anonymity-set membership, amount encryption, and zero-knowledge proofs each address a different observer and a different question. They are **not** four interchangeable locks against the same attack — they cover different surfaces. **Naming note:** \"Ring signature\" is the user-facing name DERO uses for what the source actually implements as an Anonymous Zether-style anonymity-set ZK proof (see cryptography/crypto/proof_generate.go and proof_verify.go). The user-facing term is colloquial; the construction is not a classical (Schnorr/LSAG/MLSAG) ring signature. **The Flow:** **How They Interact:** When you send a transaction, each layer addresses a different observer at a different stage. Network encryption protects your traffic from ISPs. Anonymity-set membership hides which address sent the transaction. Homomorphic encryption keeps all amounts secret. Bulletproofs prove validity without revealing the underlying values — and, at the integrity layer, **bulletproof soundness is the single cryptographic gate that prevents negative-transfer / wraparound mints**. The privacy layers and the integrity gate are not \"defense in depth\" against the same attack; they cover different surfaces. **Source Code References:** - Network: p2p/controller.go (TLS encryption) - Sender: cryptography/crypto/proof_verify.go (ring signatures) - Amount: cryptography/crypto/algebra_elgamal.go (homomorphic encryption) - Proofs: cryptography/crypto/proof_generate.go and cryptography/crypto/proof_innerproduct.go (range proof + inner product) --- What Each Observer Sees Understanding what different parties can and cannot see helps illustrate how DERO's privacy layers work together in practice. | Observer | Can See | Cannot See | Why Privacy Maintained | |----------|---------|-----------|----------------------| | **ISP/Network** | Encrypted traffic to DERO | Transaction details, amounts, addresses | TLS encryption hides content from **passive** observers. Caveat: the p2p layer uses tls.Config{InsecureSkipVerify: true} with self-signed certs (p2p/controller.go:398, cert at :551), so an **active** MITM (e.g., a hostile ISP that can intercept and present its own self-signed cert) is *not* defended against by TLS alone — the upstream code itself acknowledges this with the comment // NOTE: this does NOT protect from individual active man-in-the-middle attacks at p2p/controller.go:716. | | **Blockchain** | Ring (2-128 members), encrypted commitments | Real sender, actual amounts, balances | Ring signatures + homomorphic encryption | | **Chainalysis** | Transaction patterns, metadata | Definitive sender, amounts, proof of sending | Cannot prove specific sender identity | | **Bob (receiver)** | Amount, comment, sender position | Alice's balance, other transactions | Only sees his own transaction details | | **Alice (sender)** | Everything (has private keys) | - | Controls own privacy through wallet | --- Real Transaction Example **Alice → Bob: 100 DERO** --- Privacy at Each Stage | Stage | Privacy Added | Source Code | |-------|--------------|-------------| | **Creation** | Local only | walletapi/wallet_transfer.go:62 | | **Ring Formation** | Sender hiding | cryptography/crypto/proof_generate.go | | **Encryption (ciphertext construction)** | Amount hiding | cryptography/crypto/algebra_elgamal.go:44 (CommitElGamal) | | **Homomorphic addition (during balance update)** | Update encrypted balance without decrypting | cryptography/crypto/algebra_elgamal.go:69 (Add) | | **Proofs** | ZK validation | cryptography/crypto/proof_generate.go + cryptography/crypto/proof_innerproduct.go | | **Broadcast** | Network encryption | p2p/controller.go:398 (TLS — self-signed, no client/server auth) | | **Verification** | Homomorphic balance update applied to ciphertexts | blockchain/transaction_execute.go:239 (nb.Balance.Add(echanges)) | --- Key Takeaways **What's Protected:** - Sender identity (hidden among ring_size/2 potential senders; naive guess probability is 1/(ring_size/2), e.g., 1/8 for ring size 16) - All amounts (encrypted with homomorphic encryption, never decrypted) - All balances (encrypted at all times) - Transaction linkage (unlinkable, independent rings per transaction) **What's Visible (Necessary for Function):** - Transaction occurred (required for processing) - Ring member list (creates ambiguity, actually protects privacy) - Timing metadata (doesn't reveal transaction details) **DERO's Design:** Privacy over third-party verification. Only you (with private keys) can prove you sent a transaction. Third parties cannot definitively prove sender identity—this is by design. Plausible deniability is a feature, not a bug. **Remember:** Privacy requires ambiguity. If you could prove to others you sent a transaction, your privacy would be broken. Plausible deniability is a feature, not a bug. --- Related Pages **Privacy Technologies:** - Homomorphic Encryption - Encrypted balances - Ring Signatures - Sender anonymity - Bulletproofs - Range proofs - Payload Proofs - Prove your transactions **Understanding Transactions:** - DERO Tokens - Private token transfers - Account-Based Privacy - Stealth addresses **For Users:** - DERO Wallets - Send private transactions - Wallet RPC API - Programmatic transfers",
       "lastUpdated": "2026-01-26"
     },
     {
@@ -1372,7 +1374,7 @@
       "slug": "rpc-api/daemon-rpc-api",
       "title": "DERO Daemon RPC API: Complete Reference Guide | DERO Blockchain",
       "description": "Comprehensive documentation for DERO Stargate daemon RPC API endpoints, with examples for blockchain interaction, node communication, and transaction management.",
-      "canonicalUrl": "https://derod.org/rpc-api/daemon-rpc-api",
+      "canonicalUrl": "https://derod.org/rpc-api/daemon-rpc-api.md",
       "sourcePath": "derod-main/pages/rpc-api/daemon-rpc-api.mdx",
       "headings": [
         "Dero Stargate RPC API",
@@ -1407,7 +1409,7 @@
       "slug": "rpc-api/wallet-rpc-api",
       "title": "DERO Wallet RPC API: Developer Integration Guide | DERO Blockchain",
       "description": "Complete reference for DERO wallet RPC API methods with examples for balance management, transaction creation, and address operations in applications.",
-      "canonicalUrl": "https://derod.org/rpc-api/wallet-rpc-api",
+      "canonicalUrl": "https://derod.org/rpc-api/wallet-rpc-api.md",
       "sourcePath": "derod-main/pages/rpc-api/wallet-rpc-api.mdx",
       "headings": [
         "DERO Wallet RPC API",
@@ -1438,7 +1440,7 @@
       "slug": "smartContracts/assets",
       "title": "DERO Assets Exchange: Token Swap Smart Contract | DERO Blockchain",
       "description": "Guide to creating and using DERO's asset interchange smart contracts for secure token swaps, with step-by-step instructions for deployment and token exchange.",
-      "canonicalUrl": "https://derod.org/smartContracts/assets",
+      "canonicalUrl": "https://derod.org/smartContracts/assets.md",
       "sourcePath": "derod-main/pages/smartContracts/assets.mdx",
       "headings": [
         "Assets Interchange Smart Contract",
@@ -1455,7 +1457,7 @@
       "slug": "smartContracts/lottery",
       "title": "DERO Lottery Smart Contract: Decentralized Gaming | DERO Blockchain",
       "description": "Complete guide to implementing a blockchain-based lottery system on DERO with smart contracts, including deployment, testing, and winner selection logic.",
-      "canonicalUrl": "https://derod.org/smartContracts/lottery",
+      "canonicalUrl": "https://derod.org/smartContracts/lottery.md",
       "sourcePath": "derod-main/pages/smartContracts/lottery.mdx",
       "headings": [
         "Lottery Smart Contract Guide",
@@ -1473,7 +1475,7 @@
       "slug": "smartContracts/name",
       "title": "DERO Name Service: Blockchain Username Registration | DERO Blockchain",
       "description": "Learn how to register and manage human-readable usernames on the DERO blockchain using the built-in Name Service smart contract for easy wallet addressing.",
-      "canonicalUrl": "https://derod.org/smartContracts/name",
+      "canonicalUrl": "https://derod.org/smartContracts/name.md",
       "sourcePath": "derod-main/pages/smartContracts/name.mdx",
       "headings": [
         "Nameservice",
@@ -1490,7 +1492,7 @@
       "slug": "smartContracts/token",
       "title": "DERO Token Smart Contract Guide: Implementation Tutorial | DERO Blockchain",
       "description": "Complete guide to creating, deploying, and managing private token smart contracts on DERO blockchain, with examples for token issuance and ownership management.",
-      "canonicalUrl": "https://derod.org/smartContracts/token",
+      "canonicalUrl": "https://derod.org/smartContracts/token.md",
       "sourcePath": "derod-main/pages/smartContracts/token.mdx",
       "headings": [
         "Token Smart Contract Guide",
@@ -1510,7 +1512,7 @@
       "slug": "tools/dapps",
       "title": "DERO dApps: Private Decentralized Applications | DERO Blockchain",
       "description": "Explore decentralized applications (dApps) on DERO - the first blockchain with private smart contracts using homomorphic encryption. Build censorship-resistant apps with DVM-BASIC.",
-      "canonicalUrl": "https://derod.org/tools/dapps",
+      "canonicalUrl": "https://derod.org/tools/dapps.md",
       "sourcePath": "derod-main/pages/tools/dapps.mdx",
       "headings": [
         "DERO dApps: Private Decentralized Applications",
@@ -1564,7 +1566,7 @@
       "slug": "tools/gnomon",
       "title": "Gnomon: Decentralized Blockchain Indexer | DERO Blockchain",
       "description": "Explore Gnomon, a decentralized search engine powered by DeroHE, empowering individual user nodes by enabling direct navigation, exploration, and search within the blockchain and its smart contracts.",
-      "canonicalUrl": "https://derod.org/tools/gnomon",
+      "canonicalUrl": "https://derod.org/tools/gnomon.md",
       "sourcePath": "derod-main/pages/tools/gnomon.mdx",
       "headings": [
         "Gnomon",
@@ -1581,12 +1583,12 @@
       "product": "derod",
       "slug": "tools/mcp-server",
       "title": "DERO MCP Server | AI Assistant Integration for the DERO Blockchain",
-      "description": "Run a read-only, agent-ready DERO MCP server locally. 20 daemon-read primitives, 5 composite tools that fuse live chain reads with the bundled DERO docs index, plus structured errors and curated citations — no middlemen, no API keys, no surveillance.",
-      "canonicalUrl": "https://derod.org/tools/mcp-server",
+      "description": "Run a read-only, agent-ready DERO MCP server — stdio for local hosts, streamable-HTTP for remote agents. 21 daemon primitives + 7 composite tools that fuse live chain reads with the bundled DERO docs index, plus structured errors and curated citations — no middlemen, no API keys, no surveillance.",
+      "canonicalUrl": "https://derod.org/tools/mcp-server.md",
       "sourcePath": "derod-main/pages/tools/mcp-server.mdx",
       "headings": [
         "MCP Server",
-        "What's New in 0.2.0",
+        "At a Glance",
         "Why This Matters",
         "Install",
         "Run Your Own Node",
@@ -1596,6 +1598,8 @@
         "OpenCode",
         "Continue · Cline · Zed · others",
         "Inspect interactively",
+        "HTTP Mode (Self-Hosted)",
+        "[dero-mcp-server] HTTP listening on 127.0.0.1:8787 (POST /mcp · GET /health)",
         "What You Can Ask",
         "Composite Tools",
         "Primitive Tools",
@@ -1610,15 +1614,15 @@
         "Verify, Don't Trust",
         "See Also"
       ],
-      "plainText": "MCP Server Query the DERO blockchain — and the canonical DERO documentation — from AI assistants. No middlemen, no API keys, no surveillance. The DERO MCP server implements the Model Context Protocol, the open standard for connecting AI models to external tools. Run it locally, point it at your own daemon, and let your AI assistant interact with DERO directly over local **stdio** transport. **AI discovery files:** llms.txt and /api/openapi.json are curated subsets for agents — not a full RPC catalog. Use the Daemon RPC API and Wallet RPC API for complete method reference. Examples assume a **local daemon** at http://127.0.0.1:10102 (there is no official public node.dero.io endpoint). What's New in 0.2.0 The 0.2.0 release expands the surface from 20 primitives to **25 tools** by adding 5 **composite tools** that fuse live daemon reads with the bundled DERO docs index. Every response includes curated related_docs citations, every tool carries read-only annotations (so MCP hosts can auto-approve safely), and four new structured _meta.error codes (NO_DOCS_MATCH, INVALID_INPUT, TX_NOT_FOUND, plus existing RPC_UNREACHABLE / RPC_INVALID_PARAMS) let agents react programmatically to failures. | Surface area | 0.1.x | 0.2.0 | |---|---:|---:| | Tools | 20 | **25** (+5 composites) | | Read-only annotations | none | **25/25** | | Curated docs citations | none | **16 across 7 tools** | | Structured error codes | none | **5** | | Resources | 3 | **4** (+composite catalog) | | Prompts | 3 | **5** (refreshed composite-first, +2 new) | All 20 primitives keep their identifiers, schemas, and behavior — clients pinned to 0.1.x will continue to work. Why This Matters AI assistants are powerful research and dev tools, but most blockchain integrations route through centralized APIs that log your queries. This server runs on **your machine**, talks to **your daemon** (or a public one you choose), and communicates with your AI over **local stdio**. No accounts, no analytics, no tracking — just code you can audit. The bundled DERO documentation index (145+ pages across derod, tela, hologram, and deropay) is shipped inside the package, so the AI can quote primary sources offline without a single network round-trip beyond the daemon you pointed it at. Install Requires Node.js 18+. Source code: github.com/DHEBP/dero-mcp-server · npm: dero-mcp-server Run Your Own Node The server defaults to a third-party public RPC. For real privacy, run your own daemon: Then point the MCP server at it via DERO_DAEMON_URL (see below). Configure Your MCP Client Claude Desktop Edit claude_desktop_config.json: | OS | Path | |----|------| | macOS | ~/Library/Application Support/Claude/claude_desktop_config.json | | Windows | %APPDATA%\\Claude\\claude_desktop_config.json | | Linux | ~/.config/claude/claude_desktop_config.json | Omit env to use the default public RPC. Cursor **Settings → MCP → Add Server** - Command: dero-mcp-server - Environment: DERO_DAEMON_URL=http://127.0.0.1:10102 (optional) OpenCode Or with a local node: Continue · Cline · Zed · others Any MCP-compatible client works. The server uses **stdio** transport: Consult your client's MCP documentation for the exact config format. Inspect interactively To explore the full surface without committing to a client config, use the official MCP Inspector: It opens a local web UI that lists every tool with its schema and annotations, lets you invoke any tool with form-filled args, and shows the structured response including _meta.error blocks. What You Can Ask Once connected, talk to your AI naturally — it will pick the right composite or primitive based on your intent: - *\"Is the DERO daemon healthy and synced?\"* → diagnose_chain_health - *\"What does the contract at SCID […] do?\"* → explain_smart_contract - *\"Look up transaction [txid] and tell me what it is.\"* → trace_transaction_with_context - *\"Which DERO docs page should I read to deploy a TELA app?\"* → recommend_docs_path - *\"Estimate the gas cost to deploy this DVM contract.\"* → estimate_deploy_cost - *\"What's the current block height?\"* → dero_get_info / dero_get_height - *\"Show me the source code for contract [SCID].\"* → dero_get_sc - *\"Resolve the name dero to a wallet address.\"* → dero_name_to_address Composite Tools Each composite replaces a multi-step primitive chain with a single call, returns a plain-language narrative summary, and stitches the most relevant bundled docs pages as related_docs citations. | Composite | Replaces | When to call | |---|---|---| | diagnose_chain_health | Ping + GetInfo + GetHeight + GetTxPool | Any \"is the chain healthy / are we synced\" question | | explain_smart_contract | GetSC + manual DVM-BASIC parsing + docs lookup | \"What does this contract do\" — returns function surface + token/registry/minimal/generic classification + 1-4 curated DVM docs | | recommend_docs_path | 4× parallel dero_docs_search + manual ranking | Natural-language intent → ranked docs across all 4 DERO products; product_hint is a 1.5× score bias, not a filter | | estimate_deploy_cost | GetGasEstimate + manual surface extraction + manual gas interpretation | DVM deploy pre-flight — returns gas estimate + plain-text breakdown + parsed function surface | | trace_transaction_with_context | GetTransaction + (for SC installs) GetSC + manual classification | \"What is this tx\" — returns confirmation status, kind classification, ring stats, and parsed SC install surface inline | Each composite is fully documented in docs/composites.md (design contract, accepted/rejected designs, failure modes), and every composite ships with a green flow test in CI that runs against a live public daemon. **Why composites matter for agents.** A generic JSON-RPC client can chain primitives, but it cannot stitch the right docs context or classify failure modes for free. Composites are the wedge: they deliver agent-ready answers from the canonical DERO data sources in one call. Primitive Tools The 20 primitives map 1:1 onto daemon RPC methods plus the bundled docs index. Use them when a composite is unavailable or you need raw data. Daemon RPC | Tool | RPC Method | Purpose | |------|------------|---------| | dero_daemon_ping | DERO.Ping | Liveness check | | dero_daemon_echo | DERO.Echo | Roundtrip string echo | | dero_get_info | DERO.GetInfo | Network height, difficulty, version, hashrate, testnet flag | | dero_get_height | DERO.GetHeight | Height, stableheight, topoheight | | dero_get_block_count | DERO.GetBlockCount | Total block count | | dero_get_block | DERO.GetBlock | Full block by hash or height | | dero_get_block_header_by_hash | DERO.GetBlockHeaderByHash | Block header by hash | | dero_get_block_header_by_topo_height | DERO.GetBlockHeaderByTopoHeight | Block header by topoheight | | dero_get_last_block_header | DERO.GetLastBlockHeader | Tip block header | | dero_get_block_template | DERO.GetBlockTemplate | Mining block template | | dero_get_transaction | DERO.GetTransaction | Transaction record by hash | | dero_get_tx_pool | DERO.GetTxPool | Mempool transaction hashes | | dero_get_sc | DERO.GetSC | Smart contract code, variables, balances | | dero_get_gas_estimate | DERO.GetGasEstimate | Daemon-side gas estimate for a contract source or call | | dero_get_encrypted_balance | DERO.GetEncryptedBalance | Encrypted balance for an address | | dero_get_random_address | DERO.GetRandomAddress | Random registered wallet addresses | | dero_name_to_address | DERO.NameToAddress | Resolve a registered name to its address | Bundled docs index | Tool | Purpose | |------|---------| | dero_docs_list | Enumerate available doc pages across derod, tela, hologram, deropay | | dero_docs_search | Full-text search across the bundled docs index — in-process, no network round-trip | | dero_docs_get_page | Fetch a single doc page by slug with full plain-text content and headings | Resources and Prompts Beyond tools, the server exposes 4 **resources** and 5 **prompts** so MCP-aware clients can surface them in their UI: Resources | URI | Content | |-----|---------| | dero://mcp/server-info | Server metadata, tool list, resource list, prompt names, daemon endpoint | | dero://mcp/safety-boundary | Read-only posture and excluded method list (transfer, scinvoke, etc.) | | dero://mcp/example-flows | Composite-first agent flow recipes for common DERO investigations | | dero://mcp/composites | Structured catalog of all 5 composites — what each replaces, when to call it, what it returns, and which _meta.error codes it can emit | Prompts | Prompt | What it scripts | |--------|----------------| | network_health_check | Drives diagnose_chain_health with optional reference_topoheight | | inspect_smart_contract | Drives explain_smart_contract for any SCID | | trace_transaction | Drives trace_transaction_with_context for any tx hash | | find_dero_docs_for_intent | Drives recommend_docs_path with a natural-language intent + optional product_hint | | estimate_deploy_for_contract | Drives estimate_deploy_cost with DVM-BASIC source | Structured Errors Every tool wraps failures in a structured _meta.error block so agents can react programmatically instead of parsing error strings: | Code | Emitted by | Meaning | Retryable | |------|------------|---------|:---------:| | RPC_UNREACHABLE | All tools | Daemon not reachable on DERO_DAEMON_URL | yes | | RPC_INVALID_PARAMS | Most tools | Daemon rejected the request shape | no | | NO_DOCS_MATCH | recommend_docs_path | Intent matched zero pages across all 4 products | no — rephrase first | | INVALID_INPUT | estimate_deploy_cost | DVM compile error (wraps daemon -32098); raw message preserved in _meta.error.raw | no | | TX_NOT_FOUND | trace_transaction_with_context | Daemon returned an empty record for the hash | yes — verify hash + network first | Every error code carries a hint string with actionable next steps so the agent can recover or explain the failure cleanly to the user. Read-Only by Design Every one of the 25 tools carries the MCP read-only annotation block: This lets MCP hosts safely auto-approve any tool call from this server without prompting on every read. The server **cannot**: - Send transactions - Transfer funds - Invoke smart contracts (only **estimate** deploy cost via estimate_deploy_cost — nothing is submitted to chain) - Submit blocks - Hold wallet keys or talk to wallet RPC Wallet RPC methods (transfer, scinvoke, DERO.SendRawTransaction, DERO.SubmitBlock) are explicitly excluded. The full read-only posture, the six AND-gated conditions that would be required to expand the boundary, and the rationale for each are documented in docs/decision-boundary.md. If you need write capabilities in the future, they will be gated behind explicit flags **and** a separate wallet URL **and** a distinct annotation block (readOnlyHint: false) **and** documented escalation — never enabled by default. Environment | Variable | Default | Description | |----------|---------|-------------| | DERO_DAEMON_URL | http://82.65.143.182:10102 | Daemon base URL. Set to http://127.0.0.1:10102 for a local node. | | DERO_DOCS_ROOT | _(unset; uses bundled index)_ | Optional dev override pointing at a local docs source tree. Production deployments should leave this unset to use the bundled index. | Verify, Don't Trust - Source code on GitHub — composite design contract in docs/composites.md, read-only posture in docs/decision-boundary.md, agent-ready evidence in docs/mcp-agent-ready-evidence.md - Package on npm - Listed in the official MCP registry as io.github.DHEBP/dero-mcp-server - CI runs full smoke probes, composite flow tests, primitive flow tests, and description / citation drift guards on every push - MIT licensed — fork it, audit it, improve it See Also - DERO Daemon RPC API — full RPC reference for the methods the primitives wrap - Running a DERO Node — set up your own daemon - Smart Contract Fundamentals — DVM concepts the composites cite - XSWD — browser wallet integration (for write flows the MCP server intentionally excludes)",
-      "lastUpdated": "2026-05-23"
+      "plainText": "MCP Server Query the DERO blockchain — and the canonical DERO documentation — from AI assistants. No middlemen, no API keys, no surveillance. The DERO MCP server implements the Model Context Protocol, the open standard for connecting AI models to external tools. Run it as a local **stdio** process for Claude Desktop / Cursor / OpenCode, or as a **streamable-HTTP** server behind your own domain (e.g. mcp.derod.org) for ChatGPT Custom Connectors, Cursor hosted mode, and any agent that needs a remote URL instead of a subprocess. **AI discovery files:** llms.txt and /api/openapi.json are curated subsets for agents — not a full RPC catalog. Use the Daemon RPC API and Wallet RPC API for complete method reference. Examples assume a **local daemon** at http://127.0.0.1:10102. At a Glance | Surface | Count | Notes | |---|---:|---| | **Tools** | **28** | 18 daemon RPC wrappers + 3 docs-index tools + 7 composites | | ↳ Daemon primitives | 18 | One per common daemon read method, plus local bech32 proof/address decode | | ↳ Docs primitives | 3 | Search, fetch-by-slug, enumerate across derod / tela / hologram / deropay | | ↳ Composite tools | 7 | Multi-step intent-shaped flows that fan out into primitives + docs and return a narrative with curated citations | | **Resources** | 4 | server-info, safety-boundary, example-flows, composites | | **Prompts** | 5 | Composite-first guided flows | | **Structured error codes** | 11 | Every error carries a hint and a retryable flag for agent self-correction | | **Transports** | 2 | Local **stdio** (default) + **streamable-HTTP** (self-hosted) — both drive the same buildServer() factory, so the tool surface, response shapes, and error contract are identical | | **Bundled in the npm package** | 3 docs | README.md, SKILL.md (per-tool agent runbook), POSITIONING.md (audience boundary + comparison vs. ACP / Stripe / Crossmint / Skyfire) | Latest version, install commands, and per-release notes: see npm and the GitHub releases. Tool identifiers, schemas, and behavior are semantically stable — once a tool ships, its name, args, and response shape are preserved across minor and patch releases. Breaking changes only land in majors and are flagged in the release notes. Why This Matters AI assistants are powerful research and dev tools, but most blockchain integrations route through centralized APIs that log your queries. This server runs on **your machine**, talks to **your daemon** (or a public one you choose), and communicates with your AI over **local stdio**. No accounts, no analytics, no tracking — just code you can audit. The bundled DERO documentation index (145+ pages across derod, tela, hologram, and deropay) is shipped inside the package, so the AI can quote primary sources offline without a single network round-trip beyond the daemon you pointed it at. Install Requires Node.js 18+. Source code: github.com/DHEBP/dero-mcp-server · npm: dero-mcp-server Run Your Own Node The server defaults to a third-party public RPC. For real privacy, run your own daemon: Then point the MCP server at it via DERO_DAEMON_URL (see below). Configure Your MCP Client Claude Desktop Edit claude_desktop_config.json: | OS | Path | |----|------| | macOS | ~/Library/Application Support/Claude/claude_desktop_config.json | | Windows | %APPDATA%\\Claude\\claude_desktop_config.json | | Linux | ~/.config/claude/claude_desktop_config.json | Omit env to use the default public RPC. Cursor **Settings → MCP → Add Server** - Command: dero-mcp-server - Environment: DERO_DAEMON_URL=http://127.0.0.1:10102 (optional) OpenCode Or with a local node: Continue · Cline · Zed · others Any MCP-compatible client works. The server uses **stdio** transport: Consult your client's MCP documentation for the exact config format. Inspect interactively To explore the full surface without committing to a client config, use the official MCP Inspector: It opens a local web UI that lists every tool with its schema and annotations, lets you invoke any tool with form-filled args, and shows the structured response including _meta.error blocks. HTTP Mode (Self-Hosted) For clients that can't launch a local subprocess — ChatGPT Custom Connectors, Cursor hosted mode, n8n / Zapier integrations — run the server in streamable-HTTP mode and put it behind your own domain: | Variable | Default | Description | |---|---|---| | DERO_MCP_HTTP | unset | Set to 1 (or pass --http) to start in HTTP mode | | DERO_MCP_HTTP_PORT | 8787 | Listen port | | DERO_MCP_HTTP_HOST | 127.0.0.1 | Bind address. Use 0.0.0.0 to bind publicly (do not without auth + TLS upstream) | | DERO_MCP_AUTH_TOKEN | unset | If set, every /mcp request must carry Authorization: Bearer . Constant-time compared. | For a turnkey deploy with Caddy + auto-TLS + Docker Compose, see the deploy/ reference in the repo. Anyone can fork and run their own mcp.derod.org-style instance. The stdio transport and the HTTP transport share the same buildServer() factory, so the tool surface, response shapes, and error codes are identical across both. What You Can Ask Once connected, talk to your AI naturally — it will pick the right composite or primitive based on your intent: - *\"Is the DERO daemon healthy and synced?\"* → diagnose_chain_health - *\"What does the contract at SCID […] do?\"* → explain_smart_contract - *\"Look up transaction [txid] and tell me what it is.\"* → trace_transaction_with_context - *\"Which DERO docs page should I read to deploy a TELA app?\"* → recommend_docs_path - *\"Estimate the gas cost to deploy this DVM contract.\"* → estimate_deploy_cost - *\"Verify the claim that DERO's total supply has been correctly minted at the current tip.\"* → audit_chain_artifact_claim - *\"Forge a payload proof showing any amount — to see why 'Verified ✓' on an explorer proves nothing.\"* → dero_forge_demo_proof - *\"What's the current block height?\"* → dero_get_info / dero_get_height - *\"Show me the source code for contract [SCID].\"* → dero_get_sc - *\"Resolve the name dero to a wallet address.\"* → dero_name_to_address - *\"Decode this bech32 proof string and tell me what it represents.\"* → dero_decode_proof_string Composite Tools Each composite replaces a multi-step primitive chain with a single call, returns a plain-language narrative summary, and stitches the most relevant bundled docs pages as related_docs citations. | Composite | Replaces | When to call | |---|---|---| | diagnose_chain_health | Ping + GetInfo + GetHeight + GetTxPool | Any \"is the chain healthy / are we synced\" question | | explain_smart_contract | GetSC + manual DVM-BASIC parsing + docs lookup | \"What does this contract do\" — returns function surface + token/registry/minimal/generic classification + 1-4 curated DVM docs | | recommend_docs_path | 4× parallel dero_docs_search + manual ranking | Natural-language intent → ranked docs across all 4 DERO products; product_hint is a 1.5× score bias, not a filter | | estimate_deploy_cost | GetGasEstimate + manual surface extraction + manual gas interpretation | DVM deploy pre-flight — returns gas estimate + plain-text breakdown + parsed function surface | | trace_transaction_with_context | GetTransaction + (for SC installs) GetSC + manual classification | \"What is this tx\" — returns confirmation status, kind classification, ring stats, and parsed SC install surface inline | | audit_chain_artifact_claim | Multiple primitives + docs lookups + proof decode | End-to-end verifier for chain-related claims — returns narrative + cited daemon state + flagged-artifact analysis + optional bech32 proof round-trips. Backbone of the adversarial-context defense layer | | dero_forge_demo_proof | dero_get_transaction + manual commitment math + bech32 encode | Forge a deroproof… display object for any tx / ring slot / amount — the one-call reproduction of the inflation-claim Part 3 demo that **Verified ✓ proves nothing**: payload proofs are user-forgeable. Also exercises SDK proof-decode paths. | Each composite is fully documented in docs/composites.md (design contract, accepted/rejected designs, failure modes), and every composite ships with a green flow test in CI that runs against a live public daemon. **Why composites matter for agents.** A generic JSON-RPC client can chain primitives, but it cannot stitch the right docs context or classify failure modes for free. Composites are the wedge: they deliver agent-ready answers from the canonical DERO data sources in one call. Primitive Tools The 21 primitives map 1:1 onto daemon RPC methods (18) plus the bundled docs index (3). Use them when a composite is unavailable or you need raw data. Daemon RPC | Tool | RPC Method | Purpose | |------|------------|---------| | dero_daemon_ping | DERO.Ping | Liveness check | | dero_daemon_echo | DERO.Echo | Roundtrip string echo | | dero_get_info | DERO.GetInfo | Network height, difficulty, version, hashrate, testnet flag | | dero_get_height | DERO.GetHeight | Height, stableheight, topoheight | | dero_get_block_count | DERO.GetBlockCount | Total block count | | dero_get_block | DERO.GetBlock | Full block by hash or height | | dero_get_block_header_by_hash | DERO.GetBlockHeaderByHash | Block header by hash | | dero_get_block_header_by_topo_height | DERO.GetBlockHeaderByTopoHeight | Block header by topoheight | | dero_get_last_block_header | DERO.GetLastBlockHeader | Tip block header | | dero_get_block_template | DERO.GetBlockTemplate | Mining block template | | dero_get_transaction | DERO.GetTransaction | Transaction record by hash | | dero_get_tx_pool | DERO.GetTxPool | Mempool transaction hashes | | dero_get_sc | DERO.GetSC | Smart contract code, variables, balances | | dero_get_gas_estimate | DERO.GetGasEstimate | Daemon-side gas estimate for a contract source or call | | dero_get_encrypted_balance | DERO.GetEncryptedBalance | Encrypted balance for an address | | dero_get_random_address | DERO.GetRandomAddress | Random registered wallet addresses | | dero_name_to_address | DERO.NameToAddress | Resolve a registered name to its address | | dero_decode_proof_string | _(local — no RPC)_ | Decode a DERO bech32 proof/address string locally. Powers the adversarial-context defense layer and the demo-proof composite | Bundled docs index | Tool | Purpose | |------|---------| | dero_docs_list | Enumerate available doc pages across derod, tela, hologram, deropay | | dero_docs_search | Full-text search across the bundled docs index — in-process, no network round-trip | | dero_docs_get_page | Fetch a single doc page by slug with full plain-text content and headings | Resources and Prompts Beyond tools, the server exposes 4 **resources** and 5 **prompts** so MCP-aware clients can surface them in their UI: Resources | URI | Content | |-----|---------| | dero://mcp/server-info | Server metadata, tool list, resource list, prompt names, daemon endpoint | | dero://mcp/safety-boundary | Read-only posture and excluded method list (transfer, scinvoke, etc.) | | dero://mcp/example-flows | Composite-first agent flow recipes for common DERO investigations | | dero://mcp/composites | Structured catalog of all 7 composites — what each replaces, when to call it, what it returns, and which _meta.error codes it can emit | Prompts | Prompt | What it scripts | |--------|----------------| | network_health_check | Drives diagnose_chain_health with optional reference_topoheight | | inspect_smart_contract | Drives explain_smart_contract for any SCID | | trace_transaction | Drives trace_transaction_with_context for any tx hash | | find_dero_docs_for_intent | Drives recommend_docs_path with a natural-language intent + optional product_hint | | estimate_deploy_for_contract | Drives estimate_deploy_cost with DVM-BASIC source | Structured Errors Every tool wraps failures in a structured _meta.error block so agents can react programmatically instead of parsing error strings: | Code | Emitted by | Meaning | Retryable | |------|------------|---------|:---------:| | INVALID_INPUT | estimate_deploy_cost + others | Tool input shape is wrong (wraps daemon -32098 for DVM compile errors); raw message preserved in _meta.error.raw | no — read the hint | | INVALID_BECH32 | dero_decode_proof_string, audit + forge composites | Bech32 proof/address string failed to decode | no — re-check input string | | NO_DOCS_MATCH | recommend_docs_path | Intent matched zero pages across all 4 products | no — rephrase intent (drop verbs) | | DOC_NOT_FOUND | dero_docs_get_page | Slug doesn't exist in the bundled index | no — use dero_docs_search to find valid slugs | | TX_NOT_FOUND | trace_transaction_with_context | Daemon returned an empty record for the hash | yes — verify hash + network; retryable if freshly broadcast | | RPC_UNREACHABLE | All daemon tools | Daemon not reachable on DERO_DAEMON_URL | yes — check daemon + run npm run doctor | | RPC_INVALID_PARAMS | Most daemon tools | Daemon rejected the request shape | no — check arg names and types | | RPC_METHOD_NOT_FOUND | All daemon tools | Daemon outdated or not Stargate | no — surface to user; they need to upgrade | | RPC_HTTP_ERROR | All daemon tools | HTTP-level error from the daemon | yes — check DERO_DAEMON_URL | | DOCS_UNAVAILABLE | All docs tools | Bundled docs index missing from the install | no — reinstall dero-mcp-server | | TOOL_EXECUTION_ERROR | All tools | Catch-all unexpected error | yes — retry once, then inspect daemon logs | Every error code carries a hint string with actionable next steps so the agent can recover or explain the failure cleanly to the user. Read-Only by Design Every one of the 28 tools carries the MCP read-only annotation block: This lets MCP hosts safely auto-approve any tool call from this server without prompting on every read. The server **cannot**: - Send transactions - Transfer funds - Invoke smart contracts (only **estimate** deploy cost via estimate_deploy_cost — nothing is submitted to chain) - Submit blocks - Hold wallet keys or talk to wallet RPC Wallet RPC methods (transfer, scinvoke, DERO.SendRawTransaction, DERO.SubmitBlock) are explicitly excluded. The full read-only posture, the six AND-gated conditions that would be required to expand the boundary, and the rationale for each are documented in docs/decision-boundary.md. If you need write capabilities in the future, they will be gated behind explicit flags **and** a separate wallet URL **and** a distinct annotation block (readOnlyHint: false) **and** documented escalation — never enabled by default. Environment | Variable | Default | Description | |----------|---------|-------------| | DERO_DAEMON_URL | http://82.65.143.182:10102 | Daemon base URL. Set to http://127.0.0.1:10102 for a local node. | | DERO_DOCS_ROOT | _(unset; uses bundled index)_ | Optional dev override pointing at a local docs source tree. Production deployments should leave this unset to use the bundled index. | | DERO_MCP_HTTP | unset | Set to 1 (or pass --http) to start in streamable-HTTP mode instead of stdio. | | DERO_MCP_HTTP_PORT | 8787 | HTTP listen port when running in HTTP mode. | | DERO_MCP_HTTP_HOST | 127.0.0.1 | HTTP bind address. Use 0.0.0.0 to bind publicly (only behind auth + TLS upstream). | | DERO_MCP_AUTH_TOKEN | unset | Bearer token for HTTP /mcp requests. If set, every request must carry Authorization: Bearer . Constant-time compared. | Verify, Don't Trust - Source code on GitHub — composite design contract in docs/composites.md, read-only posture in docs/decision-boundary.md, agent-ready evidence in docs/mcp-agent-ready-evidence.md - **Bundled with the npm package:** SKILL.md is the per-tool agent operating manual (composite-first rule, port reference, structured error contract, workflow recipes, safety rules); POSITIONING.md covers who this server is for vs. who it isn't, with a comparison vs. ACP / Stripe / Crossmint / Skyfire - Agent-discovery surfaces at /.well-known/agent-card.json (A2A v0.2-draft descriptor for the broader agent ecosystem) and /.well-known/mcp-server-card.json (MCP-specific descriptor) - Package on npm - Listed in the official MCP registry as io.github.DHEBP/dero-mcp-server - CI runs full smoke probes, composite flow tests, primitive flow tests, description / citation drift guards, and HTTP transport smoke tests on every push - MIT licensed — fork it, audit it, improve it See Also - DERO Daemon RPC API — full RPC reference for the methods the primitives wrap - Running a DERO Node — set up your own daemon - Smart Contract Fundamentals — DVM concepts the composites cite - XSWD — browser wallet integration (for write flows the MCP server intentionally excludes) - SKILL.md — agent operating manual served at the docs origin (mirror of the npm-bundled file) - agents.md — human-and-LLM-readable operating runbook for the whole DERO docs surface - llms.txt — curated agent map of the DERO docs corpus",
+      "lastUpdated": "2026-05-29"
     },
     {
       "product": "derod",
       "slug": "tools/tela",
       "title": "TELA Platform: Private Web3 Framework | DERO Blockchain",
       "description": "TELA is DERO's decentralized web framework for building privacy-focused dApps that run entirely on-chain with encrypted storage and local execution.",
-      "canonicalUrl": "https://derod.org/tools/tela",
+      "canonicalUrl": "https://derod.org/tools/tela.md",
       "sourcePath": "derod-main/pages/tools/tela.mdx",
       "headings": [
         "TELA Platform",
@@ -1637,7 +1641,7 @@
       "slug": "tools/xswd",
       "title": "XSWD WebSocket Layer | DERO Blockchain",
       "description": "The XSWD protocol revolutionizes the interaction between applications and user wallets through WebSocket connections, providing secure dApp authentication.",
-      "canonicalUrl": "https://derod.org/tools/xswd",
+      "canonicalUrl": "https://derod.org/tools/xswd.md",
       "sourcePath": "derod-main/pages/tools/xswd.mdx",
       "headings": [
         "Secure Web Sockets",
@@ -1655,7 +1659,7 @@
       "slug": "",
       "title": "DeroPay & DeroAuth Documentation — Payments and Authentication for DERO",
       "description": "Accept DERO payments with invoices, escrow, and webhooks. Authenticate users with privacy-preserving wallet signatures. TypeScript SDKs for the DERO ecosystem.",
-      "canonicalUrl": "https://deropay.derod.org/",
+      "canonicalUrl": "https://deropay.derod.org/.md",
       "sourcePath": "deropay-main/pages/index.mdx",
       "headings": [
         "DeroPay & DeroAuth",
@@ -1674,7 +1678,7 @@
       "slug": "dero-auth/api-reference",
       "title": "DeroAuth API Reference",
       "description": "Complete API reference for the dero-auth package — all exports, types, and interfaces.",
-      "canonicalUrl": "https://pay.derod.org/dero-auth/api-reference",
+      "canonicalUrl": "https://pay.derod.org/dero-auth/api-reference.md",
       "sourcePath": "deropay-main/pages/dero-auth/api-reference.mdx",
       "headings": [
         "API Reference",
@@ -1700,7 +1704,7 @@
       "slug": "dero-auth/auth-flow",
       "title": "Authentication Flow — Challenge, Sign, Verify",
       "description": "Detailed walkthrough of the DeroAuth authentication flow: challenge generation, wallet signing, and server-side verification.",
-      "canonicalUrl": "https://pay.derod.org/dero-auth/auth-flow",
+      "canonicalUrl": "https://pay.derod.org/dero-auth/auth-flow.md",
       "sourcePath": "deropay-main/pages/dero-auth/auth-flow.mdx",
       "headings": [
         "Authentication Flow",
@@ -1720,7 +1724,7 @@
       "slug": "dero-auth/cryptography",
       "title": "Cryptography — Schnorr Signatures on BN256",
       "description": "How DeroAuth verifies DERO wallet signatures: Schnorr on BN256, custom generator point, Keccak-256 hashing, and Bech32 address encoding.",
-      "canonicalUrl": "https://pay.derod.org/dero-auth/cryptography",
+      "canonicalUrl": "https://pay.derod.org/dero-auth/cryptography.md",
       "sourcePath": "deropay-main/pages/dero-auth/cryptography.mdx",
       "headings": [
         "Cryptography",
@@ -1741,7 +1745,7 @@
       "slug": "dero-auth/nextjs",
       "title": "Next.js Integration — DeroAuth Route Handlers & Middleware",
       "description": "Set up DeroAuth in a Next.js 14/15 App Router project with API route handlers and auth middleware.",
-      "canonicalUrl": "https://pay.derod.org/dero-auth/nextjs",
+      "canonicalUrl": "https://pay.derod.org/dero-auth/nextjs.md",
       "sourcePath": "deropay-main/pages/dero-auth/nextjs.mdx",
       "headings": [
         "Next.js Integration",
@@ -1762,7 +1766,7 @@
       "slug": "dero-auth/overview",
       "title": "DeroAuth Overview — Wallet-Based Authentication for DERO",
       "description": "DeroAuth enables 'Sign in with your DERO wallet' — privacy-preserving authentication using Schnorr signatures on BN256.",
-      "canonicalUrl": "https://pay.derod.org/dero-auth/overview",
+      "canonicalUrl": "https://pay.derod.org/dero-auth/overview.md",
       "sourcePath": "deropay-main/pages/dero-auth/overview.mdx",
       "headings": [
         "DeroAuth Overview",
@@ -1781,7 +1785,7 @@
       "slug": "dero-auth/quick-start",
       "title": "DeroAuth Quick Start — Add Wallet Login",
       "description": "Add DERO wallet-based authentication to your app in minutes with dero-auth.",
-      "canonicalUrl": "https://pay.derod.org/dero-auth/quick-start",
+      "canonicalUrl": "https://pay.derod.org/dero-auth/quick-start.md",
       "sourcePath": "deropay-main/pages/dero-auth/quick-start.mdx",
       "headings": [
         "Quick Start",
@@ -1802,7 +1806,7 @@
       "slug": "dero-auth/react",
       "title": "React Components — DeroAuth UI",
       "description": "Drop-in React components for DeroAuth: SignInWithDero button, DeroAuthProvider, and useDeroAuth hook.",
-      "canonicalUrl": "https://pay.derod.org/dero-auth/react",
+      "canonicalUrl": "https://pay.derod.org/dero-auth/react.md",
       "sourcePath": "deropay-main/pages/dero-auth/react.mdx",
       "headings": [
         "React Components",
@@ -1819,7 +1823,7 @@
       "slug": "dero-pay/api-reference",
       "title": "DeroPay API Reference",
       "description": "Complete API reference for the dero-pay package — all exports, types, and interfaces.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/api-reference",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/api-reference.md",
       "sourcePath": "deropay-main/pages/dero-pay/api-reference.mdx",
       "headings": [
         "API Reference",
@@ -1841,7 +1845,7 @@
       "slug": "dero-pay/invoice-engine",
       "title": "Invoice Engine — Core Payment Orchestrator",
       "description": "The InvoiceEngine is the central component of DeroPay, coordinating invoice creation, payment monitoring, storage, and webhook dispatch.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/invoice-engine",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/invoice-engine.md",
       "sourcePath": "deropay-main/pages/dero-pay/invoice-engine.mdx",
       "headings": [
         "Invoice Engine",
@@ -1859,7 +1863,7 @@
       "slug": "dero-pay/nextjs",
       "title": "Next.js Integration — DeroPay Route Handlers & Middleware",
       "description": "Set up DeroPay in a Next.js 14/15 App Router project with ready-made API handlers and middleware.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/nextjs",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/nextjs.md",
       "sourcePath": "deropay-main/pages/dero-pay/nextjs.mdx",
       "headings": [
         "Next.js Integration",
@@ -1881,7 +1885,7 @@
       "slug": "dero-pay/overview",
       "title": "DeroPay Overview — Payment Processing for DERO",
       "description": "DeroPay is a TypeScript SDK for accepting DERO payments with invoices, payment monitoring, webhooks, escrow, and a merchant dashboard.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/overview",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/overview.md",
       "sourcePath": "deropay-main/pages/dero-pay/overview.mdx",
       "headings": [
         "DeroPay Overview",
@@ -1900,7 +1904,7 @@
       "slug": "dero-pay/payment-monitor",
       "title": "Payment Monitor — Transaction Polling & Confirmation Tracking",
       "description": "The PaymentMonitor polls the DERO wallet for incoming transactions and tracks confirmations until invoices are complete.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/payment-monitor",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/payment-monitor.md",
       "sourcePath": "deropay-main/pages/dero-pay/payment-monitor.mdx",
       "headings": [
         "Payment Monitor",
@@ -1917,7 +1921,7 @@
       "slug": "dero-pay/quick-start",
       "title": "DeroPay Quick Start — Accept DERO Payments",
       "description": "Get started with DeroPay in under 5 minutes. Create invoices, monitor payments, and handle webhooks.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/quick-start",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/quick-start.md",
       "sourcePath": "deropay-main/pages/dero-pay/quick-start.mdx",
       "headings": [
         "Quick Start",
@@ -1938,7 +1942,7 @@
       "slug": "dero-pay/react",
       "title": "React Components — Payment UI",
       "description": "Drop-in React components for DeroPay: PayWithDero button, InvoiceView, PaymentStatus, and DeroPayProvider.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/react",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/react.md",
       "sourcePath": "deropay-main/pages/dero-pay/react.mdx",
       "headings": [
         "React Components",
@@ -1958,7 +1962,7 @@
       "slug": "dero-pay/rpc",
       "title": "RPC Clients — DERO Wallet & Daemon Communication",
       "description": "DeroPay provides typed JSON-RPC clients for the DERO wallet and daemon, handling all low-level communication.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/rpc",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/rpc.md",
       "sourcePath": "deropay-main/pages/dero-pay/rpc.mdx",
       "headings": [
         "RPC Clients",
@@ -1977,7 +1981,7 @@
       "slug": "dero-pay/storage",
       "title": "Storage Backends — Invoice Persistence",
       "description": "DeroPay supports pluggable storage backends. Use in-memory for development and SQLite for production, or implement your own.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/storage",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/storage.md",
       "sourcePath": "deropay-main/pages/dero-pay/storage.mdx",
       "headings": [
         "Storage Backends",
@@ -1992,7 +1996,7 @@
       "slug": "dero-pay/webhooks",
       "title": "Webhooks — HMAC-Signed Payment Notifications",
       "description": "DeroPay sends HMAC-SHA256 signed webhooks on payment state changes. Learn how to configure and verify them.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/webhooks",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/webhooks.md",
       "sourcePath": "deropay-main/pages/dero-pay/webhooks.mdx",
       "headings": [
         "Webhooks",
@@ -2010,7 +2014,7 @@
       "slug": "dero-pay/x402",
       "title": "x402 Payment Guard — DERO-Native HTTP 402 for APIs",
       "description": "Protect API routes with HTTP 402 Payment Required. Clients pay DERO, receive a signed receipt, and retry. No accounts, no API keys, no subscriptions.",
-      "canonicalUrl": "https://pay.derod.org/dero-pay/x402",
+      "canonicalUrl": "https://pay.derod.org/dero-pay/x402.md",
       "sourcePath": "deropay-main/pages/dero-pay/x402.mdx",
       "headings": [
         "x402 Payment Guard",
@@ -2041,7 +2045,7 @@
       "slug": "escrow/overview",
       "title": "Escrow System — Trustless On-Chain Payments",
       "description": "DeroPay includes a full escrow system with an on-chain smart contract and TypeScript SDK for trustless buyer-seller transactions.",
-      "canonicalUrl": "https://pay.derod.org/escrow/overview",
+      "canonicalUrl": "https://pay.derod.org/escrow/overview.md",
       "sourcePath": "deropay-main/pages/escrow/overview.mdx",
       "headings": [
         "Escrow System",
@@ -2060,7 +2064,7 @@
       "slug": "escrow/sdk",
       "title": "Escrow TypeScript SDK — EscrowContract & EscrowManager",
       "description": "Use the dero-pay/escrow module to create, fund, release, refund, and arbitrate escrow transactions programmatically.",
-      "canonicalUrl": "https://pay.derod.org/escrow/sdk",
+      "canonicalUrl": "https://pay.derod.org/escrow/sdk.md",
       "sourcePath": "deropay-main/pages/escrow/sdk.mdx",
       "headings": [
         "Escrow TypeScript SDK",
@@ -2076,7 +2080,7 @@
       "slug": "escrow/smart-contract",
       "title": "Escrow Smart Contract — On-Chain DERO Contract",
       "description": "The escrow.bas smart contract holds DERO funds in escrow with support for deposits, releases, refunds, disputes, and arbitration.",
-      "canonicalUrl": "https://pay.derod.org/escrow/smart-contract",
+      "canonicalUrl": "https://pay.derod.org/escrow/smart-contract.md",
       "sourcePath": "deropay-main/pages/escrow/smart-contract.mdx",
       "headings": [
         "Escrow Smart Contract",
@@ -2094,7 +2098,7 @@
       "slug": "guides/embeddable-widget",
       "title": "Guide: Embeddable Payment Widget",
       "description": "Add a 'Pay with DERO' button to any website with a single script tag. No framework required.",
-      "canonicalUrl": "https://pay.derod.org/guides/embeddable-widget",
+      "canonicalUrl": "https://pay.derod.org/guides/embeddable-widget.md",
       "sourcePath": "deropay-main/pages/guides/embeddable-widget.mdx",
       "headings": [
         "Embeddable Payment Widget",
@@ -2118,7 +2122,7 @@
       "slug": "guides/gateway-server",
       "title": "Guide: DeroPay Gateway Server",
       "description": "Deploy the standalone DeroPay gateway server — the foundation for all ecommerce plugins, widgets, and payment links.",
-      "canonicalUrl": "https://pay.derod.org/guides/gateway-server",
+      "canonicalUrl": "https://pay.derod.org/guides/gateway-server.md",
       "sourcePath": "deropay-main/pages/guides/gateway-server.mdx",
       "headings": [
         "DeroPay Gateway Server",
@@ -2142,7 +2146,7 @@
       "slug": "guides/medusa-plugin",
       "title": "Guide: Medusa.js Payment Plugin",
       "description": "Accept DERO payments in your Medusa.js v2 store with the DeroPay payment provider plugin.",
-      "canonicalUrl": "https://pay.derod.org/guides/medusa-plugin",
+      "canonicalUrl": "https://pay.derod.org/guides/medusa-plugin.md",
       "sourcePath": "deropay-main/pages/guides/medusa-plugin.mdx",
       "headings": [
         "Medusa.js Payment Plugin",
@@ -2168,7 +2172,7 @@
       "slug": "guides/merchant-dashboard",
       "title": "Merchant Dashboard — Self-Hosted Admin UI",
       "description": "Set up and run the DeroPay merchant dashboard for invoice management, payment history, and wallet status.",
-      "canonicalUrl": "https://pay.derod.org/guides/merchant-dashboard",
+      "canonicalUrl": "https://pay.derod.org/guides/merchant-dashboard.md",
       "sourcePath": "deropay-main/pages/guides/merchant-dashboard.mdx",
       "headings": [
         "Merchant Dashboard",
@@ -2188,7 +2192,7 @@
       "slug": "guides/nextjs-auth",
       "title": "Guide: DERO Wallet Auth in Next.js",
       "description": "End-to-end guide for adding DERO wallet authentication to a Next.js 15 App Router project.",
-      "canonicalUrl": "https://pay.derod.org/guides/nextjs-auth",
+      "canonicalUrl": "https://pay.derod.org/guides/nextjs-auth.md",
       "sourcePath": "deropay-main/pages/guides/nextjs-auth.mdx",
       "headings": [
         "DERO Wallet Auth in Next.js",
@@ -2211,7 +2215,7 @@
       "slug": "guides/nextjs-payments",
       "title": "Guide: Accept DERO Payments in Next.js",
       "description": "End-to-end guide for integrating DeroPay into a Next.js 15 App Router project.",
-      "canonicalUrl": "https://pay.derod.org/guides/nextjs-payments",
+      "canonicalUrl": "https://pay.derod.org/guides/nextjs-payments.md",
       "sourcePath": "deropay-main/pages/guides/nextjs-payments.mdx",
       "headings": [
         "Accept DERO Payments in Next.js",
@@ -2232,7 +2236,7 @@
       "slug": "guides/payment-links",
       "title": "Guide: Payment Links & Hosted Checkout",
       "description": "Create shareable payment links for DERO — no website needed. Works via email, social media, QR posters, or messaging.",
-      "canonicalUrl": "https://pay.derod.org/guides/payment-links",
+      "canonicalUrl": "https://pay.derod.org/guides/payment-links.md",
       "sourcePath": "deropay-main/pages/guides/payment-links.mdx",
       "headings": [
         "Payment Links & Hosted Checkout",
@@ -2254,7 +2258,7 @@
       "slug": "guides/prerequisites",
       "title": "Prerequisites — DERO Wallet & Environment Setup",
       "description": "Set up a DERO wallet and development environment for DeroPay and DeroAuth.",
-      "canonicalUrl": "https://pay.derod.org/guides/prerequisites",
+      "canonicalUrl": "https://pay.derod.org/guides/prerequisites.md",
       "sourcePath": "deropay-main/pages/guides/prerequisites.mdx",
       "headings": [
         "Prerequisites",
@@ -2275,7 +2279,7 @@
       "slug": "guides/woocommerce",
       "title": "Guide: WooCommerce Plugin",
       "description": "Accept DERO payments on your WordPress/WooCommerce store with the DeroPay payment gateway plugin.",
-      "canonicalUrl": "https://pay.derod.org/guides/woocommerce",
+      "canonicalUrl": "https://pay.derod.org/guides/woocommerce.md",
       "sourcePath": "deropay-main/pages/guides/woocommerce.mdx",
       "headings": [
         "WooCommerce Plugin",
@@ -2296,7 +2300,7 @@
       "slug": "payment-router/escrow-vs-router",
       "title": "Escrow vs. Payment Router — Which Smart Contract to Use",
       "description": "A comparison of DeroPay's two smart contracts: escrow for buyer-protected transactions and payment router for instant merchant payments.",
-      "canonicalUrl": "https://pay.derod.org/payment-router/escrow-vs-router",
+      "canonicalUrl": "https://pay.derod.org/payment-router/escrow-vs-router.md",
       "sourcePath": "deropay-main/pages/payment-router/escrow-vs-router.mdx",
       "headings": [
         "Escrow vs. Payment Router",
@@ -2314,7 +2318,7 @@
       "slug": "payment-router/overview",
       "title": "Payment Router — Instant On-Chain Payments",
       "description": "A reusable per-merchant smart contract for fast, single-transaction DERO payments with optional fee splitting.",
-      "canonicalUrl": "https://pay.derod.org/payment-router/overview",
+      "canonicalUrl": "https://pay.derod.org/payment-router/overview.md",
       "sourcePath": "deropay-main/pages/payment-router/overview.mdx",
       "headings": [
         "Payment Router",
@@ -2333,7 +2337,7 @@
       "slug": "payment-router/sdk",
       "title": "Payment Router TypeScript SDK — RouterContract & RouterManager",
       "description": "Use the dero-pay/router module to deploy payment routers, send payments, and query on-chain state programmatically.",
-      "canonicalUrl": "https://pay.derod.org/payment-router/sdk",
+      "canonicalUrl": "https://pay.derod.org/payment-router/sdk.md",
       "sourcePath": "deropay-main/pages/payment-router/sdk.mdx",
       "headings": [
         "Payment Router TypeScript SDK",
@@ -2352,7 +2356,7 @@
       "slug": "payment-router/smart-contract",
       "title": "Payment Router Smart Contract — On-Chain DERO Contract",
       "description": "The payment-router.bas smart contract handles instant payment splitting between a merchant and an optional fee recipient.",
-      "canonicalUrl": "https://pay.derod.org/payment-router/smart-contract",
+      "canonicalUrl": "https://pay.derod.org/payment-router/smart-contract.md",
       "sourcePath": "deropay-main/pages/payment-router/smart-contract.mdx",
       "headings": [
         "Payment Router Smart Contract",
@@ -2372,7 +2376,7 @@
       "slug": "",
       "title": "Hologram: DERO Decentralized Web Browser",
       "description": "Hologram documentation. Browse decentralized applications, manage wallets, support developers, and explore the blockchain - all in one native desktop application.",
-      "canonicalUrl": "https://hologram.derod.org/",
+      "canonicalUrl": "https://hologram.derod.org/.md",
       "sourcePath": "hologram-main/pages/index.mdx",
       "headings": [
         "HOLOGRAM",
@@ -2390,7 +2394,7 @@
       "slug": "api-reference",
       "title": "Full API Reference",
       "description": "Complete reference of all 300+ Hologram API methods across 30 functional areas.",
-      "canonicalUrl": "https://hologram.derod.org/api-reference",
+      "canonicalUrl": "https://hologram.derod.org/api-reference.md",
       "sourcePath": "hologram-main/pages/api-reference.mdx",
       "headings": [
         "Full API Reference",
@@ -2456,7 +2460,7 @@
       "slug": "browser",
       "title": "TELA Browser",
       "description": "Browse decentralized applications stored entirely on the DERO blockchain with Hologram's TELA Browser engine.",
-      "canonicalUrl": "https://hologram.derod.org/browser",
+      "canonicalUrl": "https://hologram.derod.org/browser.md",
       "sourcePath": "hologram-main/pages/browser.mdx",
       "headings": [
         "TELA Browser",
@@ -2505,7 +2509,7 @@
       "slug": "dero-auth",
       "title": "Sign In with DERO",
       "description": "HOLOGRAM-exclusive: authenticate on any HTTPS website using your DERO wallet address — no extensions, no passwords, no seed phrases in the browser.",
-      "canonicalUrl": "https://hologram.derod.org/dero-auth",
+      "canonicalUrl": "https://hologram.derod.org/dero-auth.md",
       "sourcePath": "hologram-main/pages/dero-auth.mdx",
       "headings": [
         "Sign In with DERO",
@@ -2527,7 +2531,7 @@
       "slug": "developer-support",
       "title": "Developer Support",
       "description": "Support TELA app developers through the EPOCH passive hashing system - no ads, no data collection.",
-      "canonicalUrl": "https://hologram.derod.org/developer-support",
+      "canonicalUrl": "https://hologram.derod.org/developer-support.md",
       "sourcePath": "hologram-main/pages/developer-support.mdx",
       "headings": [
         "Developer Support",
@@ -2562,7 +2566,7 @@
       "slug": "explorer",
       "title": "Block Explorer",
       "description": "Explore the DERO blockchain - blocks, transactions, smart contracts, and real-time analytics.",
-      "canonicalUrl": "https://hologram.derod.org/explorer",
+      "canonicalUrl": "https://hologram.derod.org/explorer.md",
       "sourcePath": "hologram-main/pages/explorer.mdx",
       "headings": [
         "Block Explorer",
@@ -2619,7 +2623,7 @@
       "slug": "installation",
       "title": "Installation",
       "description": "Download and install Hologram on macOS, Linux, or Windows.",
-      "canonicalUrl": "https://hologram.derod.org/installation",
+      "canonicalUrl": "https://hologram.derod.org/installation.md",
       "sourcePath": "hologram-main/pages/installation.mdx",
       "headings": [
         "Installation",
@@ -2667,7 +2671,7 @@
       "slug": "local-dev-server",
       "title": "Local Dev Server",
       "description": "Hot-reload development of TELA applications directly within Hologram.",
-      "canonicalUrl": "https://hologram.derod.org/local-dev-server",
+      "canonicalUrl": "https://hologram.derod.org/local-dev-server.md",
       "sourcePath": "hologram-main/pages/local-dev-server.mdx",
       "headings": [
         "Local Dev Server",
@@ -2706,7 +2710,7 @@
       "slug": "offline-first",
       "title": "Offline-First Browsing",
       "description": "Clone, cache, and diff TELA apps locally for instant access without network dependency.",
-      "canonicalUrl": "https://hologram.derod.org/offline-first",
+      "canonicalUrl": "https://hologram.derod.org/offline-first.md",
       "sourcePath": "hologram-main/pages/offline-first.mdx",
       "headings": [
         "Offline-First Browsing",
@@ -2747,7 +2751,7 @@
       "slug": "overview",
       "title": "Overview",
       "description": "Understanding Hologram's architecture, components, and core capabilities.",
-      "canonicalUrl": "https://hologram.derod.org/overview",
+      "canonicalUrl": "https://hologram.derod.org/overview.md",
       "sourcePath": "hologram-main/pages/overview.mdx",
       "headings": [
         "Overview",
@@ -2772,7 +2776,7 @@
       "slug": "proof-validation",
       "title": "Proof Validation",
       "description": "Security enhancement for validating payload proofs and blocking fake/fabricated proofs with impossible amounts.",
-      "canonicalUrl": "https://hologram.derod.org/proof-validation",
+      "canonicalUrl": "https://hologram.derod.org/proof-validation.md",
       "sourcePath": "hologram-main/pages/proof-validation.mdx",
       "headings": [
         "Proof Validation",
@@ -2802,7 +2806,7 @@
       "slug": "quick-start",
       "title": "Quick Start",
       "description": "Get started with Hologram in minutes - connect to the network, create a wallet, and browse your first dApp.",
-      "canonicalUrl": "https://hologram.derod.org/quick-start",
+      "canonicalUrl": "https://hologram.derod.org/quick-start.md",
       "sourcePath": "hologram-main/pages/quick-start.mdx",
       "headings": [
         "Quick Start",
@@ -2838,7 +2842,7 @@
       "slug": "security",
       "title": "Security Features",
       "description": "Understanding Hologram's security model, sandboxing, and privacy protections.",
-      "canonicalUrl": "https://hologram.derod.org/security",
+      "canonicalUrl": "https://hologram.derod.org/security.md",
       "sourcePath": "hologram-main/pages/security.mdx",
       "headings": [
         "Security Features",
@@ -2882,7 +2886,7 @@
       "slug": "settings",
       "title": "Settings Reference",
       "description": "Complete guide to Hologram's settings - node management, Gnomon, privacy, console, and more.",
-      "canonicalUrl": "https://hologram.derod.org/settings",
+      "canonicalUrl": "https://hologram.derod.org/settings.md",
       "sourcePath": "hologram-main/pages/settings.mdx",
       "headings": [
         "Settings Reference",
@@ -2924,7 +2928,7 @@
       "slug": "simulator",
       "title": "Simulator Mode",
       "description": "One-click integrated development environment for testing TELA applications and smart contracts.",
-      "canonicalUrl": "https://hologram.derod.org/simulator",
+      "canonicalUrl": "https://hologram.derod.org/simulator.md",
       "sourcePath": "hologram-main/pages/simulator.mdx",
       "headings": [
         "Simulator Mode",
@@ -2960,7 +2964,7 @@
       "slug": "studio",
       "title": "Studio",
       "description": "Create, deploy, and manage TELA applications with Hologram's integrated development studio.",
-      "canonicalUrl": "https://hologram.derod.org/studio",
+      "canonicalUrl": "https://hologram.derod.org/studio.md",
       "sourcePath": "hologram-main/pages/studio.mdx",
       "headings": [
         "Studio",
@@ -3016,7 +3020,7 @@
       "slug": "telahost-api",
       "title": "telaHost Bridge API",
       "description": "JavaScript API reference for TELA app developers. Connect your dApp to the DERO blockchain and wallet through Hologram.",
-      "canonicalUrl": "https://hologram.derod.org/telahost-api",
+      "canonicalUrl": "https://hologram.derod.org/telahost-api.md",
       "sourcePath": "hologram-main/pages/telahost-api.mdx",
       "headings": [
         "telaHost Bridge API",
@@ -3055,7 +3059,7 @@
       "slug": "wallet",
       "title": "Wallet Management",
       "description": "Complete DERO wallet management in Hologram - create, restore, send, receive, and track transactions.",
-      "canonicalUrl": "https://hologram.derod.org/wallet",
+      "canonicalUrl": "https://hologram.derod.org/wallet.md",
       "sourcePath": "hologram-main/pages/wallet.mdx",
       "headings": [
         "Wallet Management",
@@ -3133,7 +3137,7 @@
       "slug": "",
       "title": "TELA: Private Web3 Platform Documentation | Decentralized Applications on DERO",
       "description": "TELA documentation. Build private web applications on DERO blockchain with complete privacy and decentralized infrastructure. Learn XSWD protocol and deploy censorship-resistant apps.",
-      "canonicalUrl": "https://tela.derod.org/",
+      "canonicalUrl": "https://tela.derod.org/.md",
       "sourcePath": "tela-main/pages/index.mdx",
       "headings": [
         "Welcome to TELA Platform",
@@ -3150,7 +3154,7 @@
       "slug": "advanced-features/compression",
       "title": "Compression & Optimization in TELA | Advanced File Compression Techniques",
       "description": "Advanced compression techniques and optimization strategies for TELA applications. Learn Gzip compression, file optimization, and deployment efficiency for blockchain storage.",
-      "canonicalUrl": "https://tela.derod.org/advanced-features/compression",
+      "canonicalUrl": "https://tela.derod.org/advanced-features/compression.md",
       "sourcePath": "tela-main/pages/advanced-features/compression.mdx",
       "headings": [
         "Compression & Optimization",
@@ -3200,7 +3204,7 @@
       "slug": "advanced-features/docshards",
       "title": "DocShards | Large File Handling System for TELA Applications",
       "description": "Complete guide to TELA's DocShards system for handling files larger than blockchain limits. Split, deploy, and reconstruct files exceeding 18KB smart contract size limits.",
-      "canonicalUrl": "https://tela.derod.org/advanced-features/docshards",
+      "canonicalUrl": "https://tela.derod.org/advanced-features/docshards.md",
       "sourcePath": "tela-main/pages/advanced-features/docshards.mdx",
       "headings": [
         "DocShards: Large File Handling",
@@ -3256,7 +3260,7 @@
       "slug": "advanced-features/durl-explained",
       "title": "Understanding dURLs | Decentralized URL Identity & Resolution",
       "description": "Deep dive into TELA dURLs - why they're not unique, how resolution works, SCID vs dURL identity, and recovery strategies when things go wrong.",
-      "canonicalUrl": "https://tela.derod.org/advanced-features/durl-explained",
+      "canonicalUrl": "https://tela.derod.org/advanced-features/durl-explained.md",
       "sourcePath": "tela-main/pages/advanced-features/durl-explained.mdx",
       "headings": [
         "Understanding dURLs",
@@ -3293,7 +3297,7 @@
       "slug": "advanced-features/libraries-overview",
       "title": "TELA Libraries | Building Reusable Decentralized Code Modules",
       "description": "Building reusable, decentralized code libraries on the DERO blockchain. Complete guide to creating, deploying, and sharing blockchain-stored code modules.",
-      "canonicalUrl": "https://tela.derod.org/advanced-features/libraries-overview",
+      "canonicalUrl": "https://tela.derod.org/advanced-features/libraries-overview.md",
       "sourcePath": "tela-main/pages/advanced-features/libraries-overview.mdx",
       "headings": [
         "TELA Libraries: Complete Developer Guide",
@@ -3383,7 +3387,7 @@
       "slug": "advanced-features/tela-mods",
       "title": "TELA-MOD-1 | Extending INDEX Contracts with Modular Functionality",
       "description": "Complete guide to TELA-MOD-1 modules - extend INDEX smart contracts with variable storage, transfers, and custom functionality. Includes all MOD variants, API examples, and developer guide.",
-      "canonicalUrl": "https://tela.derod.org/advanced-features/tela-mods",
+      "canonicalUrl": "https://tela.derod.org/advanced-features/tela-mods.md",
       "sourcePath": "tela-main/pages/advanced-features/tela-mods.mdx",
       "headings": [
         "TELA-MOD-1: Modular Smart Contract Extensions",
@@ -3452,7 +3456,7 @@
       "slug": "api-reference/complete-api-guide",
       "title": "Complete TELA API Guide",
       "description": "Comprehensive API reference combining DERO RPC, XSWD protocol, Gnomon indexer, and EPOCH mining for TELA development",
-      "canonicalUrl": "https://tela.derod.org/api-reference/complete-api-guide",
+      "canonicalUrl": "https://tela.derod.org/api-reference/complete-api-guide.md",
       "sourcePath": "tela-main/pages/api-reference/complete-api-guide.mdx",
       "headings": [
         "Complete TELA API Guide",
@@ -3496,7 +3500,7 @@
       "slug": "best-practices",
       "title": "Best Practices | Production-Ready TELA Development",
       "description": "Best practices guide for building production-ready TELA applications with size constraints, performance optimization, and DERO integration",
-      "canonicalUrl": "https://tela.derod.org/best-practices",
+      "canonicalUrl": "https://tela.derod.org/best-practices.md",
       "sourcePath": "tela-main/pages/best-practices.mdx",
       "headings": [
         "Best Practices",
@@ -3539,7 +3543,7 @@
       "slug": "demo",
       "title": "Official TELA Demo (app1) | Verified Source Code Reference",
       "description": "Complete source code from tela_tests/app1 - the official TELA demonstration application. Verified working patterns for XSWD connections, API calls, and TELA development.",
-      "canonicalUrl": "https://tela.derod.org/demo",
+      "canonicalUrl": "https://tela.derod.org/demo.md",
       "sourcePath": "tela-main/pages/demo/index.mdx",
       "headings": [
         "Official TELA Demo (app1)",
@@ -3562,7 +3566,7 @@
       "slug": "demo/api-patterns",
       "title": "API Call Patterns | app1 Demo Analysis",
       "description": "Complete analysis of RPC API call patterns from app1 demo. Verified patterns for making DERO blockchain calls through XSWD.",
-      "canonicalUrl": "https://tela.derod.org/demo/api-patterns",
+      "canonicalUrl": "https://tela.derod.org/demo/api-patterns.md",
       "sourcePath": "tela-main/pages/demo/api-patterns.mdx",
       "headings": [
         "API Call Patterns",
@@ -3585,7 +3589,7 @@
       "slug": "demo/application-data",
       "title": "Application Data Handshake | app1 Demo Analysis",
       "description": "Complete analysis of the application data handshake pattern from app1 demo. Learn the exact format for wallet approval and connection establishment.",
-      "canonicalUrl": "https://tela.derod.org/demo/application-data",
+      "canonicalUrl": "https://tela.derod.org/demo/application-data.md",
       "sourcePath": "tela-main/pages/demo/application-data.mdx",
       "headings": [
         "Application Data Handshake",
@@ -3610,7 +3614,7 @@
       "slug": "demo/file-structure",
       "title": "File Structure & Size | app1 Demo Analysis",
       "description": "Complete file structure and size analysis from app1 demo. Learn how to organize TELA applications within 18KB limits.",
-      "canonicalUrl": "https://tela.derod.org/demo/file-structure",
+      "canonicalUrl": "https://tela.derod.org/demo/file-structure.md",
       "sourcePath": "tela-main/pages/demo/file-structure.mdx",
       "headings": [
         "File Structure & Size",
@@ -3633,7 +3637,7 @@
       "slug": "design-reference",
       "title": "TELA Design Reference | UI Components and Patterns for TELA Applications",
       "description": "Quick reference for common UI patterns, components, and styles optimized for TELA applications. Copy-paste ready components with TELA size constraints and modern design.",
-      "canonicalUrl": "https://tela.derod.org/design-reference",
+      "canonicalUrl": "https://tela.derod.org/design-reference.md",
       "sourcePath": "tela-main/pages/design-reference.mdx",
       "headings": [
         "TELA Design Reference",
@@ -3668,7 +3672,7 @@
       "slug": "epoch-mining",
       "title": "EPOCH Mining Complete Guide | DERO Proof-of-Work Mining Through TELA",
       "description": "Proof-of-work mining capabilities for DERO blockchain through TELA applications. Comprehensive guide to EPOCH mining API, session management, and mining dashboard integration.",
-      "canonicalUrl": "https://tela.derod.org/epoch-mining",
+      "canonicalUrl": "https://tela.derod.org/epoch-mining.md",
       "sourcePath": "tela-main/pages/epoch-mining.mdx",
       "headings": [
         "EPOCH Mining - Complete Guide",
@@ -3705,7 +3709,7 @@
       "slug": "error-troubleshooting",
       "title": "TELA Error Troubleshooting Guide | Debug and Fix Common TELA Development Issues",
       "description": "Comprehensive guide to diagnosing and fixing common TELA development and deployment errors. Solutions for XSWD connection issues, deployment failures, file size errors, and network problems.",
-      "canonicalUrl": "https://tela.derod.org/error-troubleshooting",
+      "canonicalUrl": "https://tela.derod.org/error-troubleshooting.md",
       "sourcePath": "tela-main/pages/error-troubleshooting.mdx",
       "headings": [
         "Error Troubleshooting Guide",
@@ -3795,7 +3799,7 @@
       "slug": "go-package-reference/api-reference",
       "title": "TELA Go Package API Reference | Complete Function Documentation",
       "description": "Complete TELA Go package API reference for content serving, smart contracts, and blockchain operations. Comprehensive documentation for github.com/civilware/tela package.",
-      "canonicalUrl": "https://tela.derod.org/go-package-reference/api-reference",
+      "canonicalUrl": "https://tela.derod.org/go-package-reference/api-reference.md",
       "sourcePath": "tela-main/pages/go-package-reference/api-reference.mdx",
       "headings": [
         "TELA Go Package API Reference",
@@ -3857,7 +3861,7 @@
       "slug": "go-package-reference/examples",
       "title": "TELA API Examples | Real-World Go Package Usage Patterns",
       "description": "Comprehensive examples demonstrating real-world TELA Go package usage. Complete code samples for deployment, serving, and smart contract operations.",
-      "canonicalUrl": "https://tela.derod.org/go-package-reference/examples",
+      "canonicalUrl": "https://tela.derod.org/go-package-reference/examples.md",
       "sourcePath": "tela-main/pages/go-package-reference/examples.mdx",
       "headings": [
         "TELA API Examples",
@@ -3875,7 +3879,7 @@
       "slug": "javascript-guidelines",
       "title": "JavaScript Guidelines",
       "description": "What JavaScript and CSS features actually work in TELA applications. Myth-busting guide based on verified working code.",
-      "canonicalUrl": "https://tela.derod.org/javascript-guidelines",
+      "canonicalUrl": "https://tela.derod.org/javascript-guidelines.md",
       "sourcePath": "tela-main/pages/javascript-guidelines.mdx",
       "headings": [
         "JavaScript Guidelines",
@@ -3907,7 +3911,7 @@
       "slug": "tela-cli/command-reference",
       "title": "TELA-CLI Command Reference | Complete A-Z Command Documentation",
       "description": "Complete alphabetical reference for all TELA-CLI commands. Comprehensive documentation for deployment, search, serving, Gnomon, file management, and blockchain operations.",
-      "canonicalUrl": "https://tela.derod.org/tela-cli/command-reference",
+      "canonicalUrl": "https://tela.derod.org/tela-cli/command-reference.md",
       "sourcePath": "tela-main/pages/tela-cli/command-reference.mdx",
       "headings": [
         "TELA-CLI Command Reference",
@@ -4044,7 +4048,7 @@
       "slug": "tela-cli/gnomon-guide",
       "title": "Gnomon Indexer Deep-Dive Guide | TELA Content Discovery and Indexing",
       "description": "Complete guide to Gnomon indexer for TELA-CLI - understand blockchain indexing, database management, performance tuning, and advanced search capabilities for DERO content discovery.",
-      "canonicalUrl": "https://tela.derod.org/tela-cli/gnomon-guide",
+      "canonicalUrl": "https://tela.derod.org/tela-cli/gnomon-guide.md",
       "sourcePath": "tela-main/pages/tela-cli/gnomon-guide.mdx",
       "headings": [
         "Gnomon Indexer Deep-Dive Guide",
@@ -4292,7 +4296,7 @@
       "slug": "tela-cli/installation",
       "title": "TELA-CLI Installation Guide | Setup TELA Command-Line Interface",
       "description": "Complete installation guide for TELA-CLI - install from source, build binaries, or use pre-built releases. Setup instructions for Windows, macOS, and Linux.",
-      "canonicalUrl": "https://tela.derod.org/tela-cli/installation",
+      "canonicalUrl": "https://tela.derod.org/tela-cli/installation.md",
       "sourcePath": "tela-main/pages/tela-cli/installation.mdx",
       "headings": [
         "TELA-CLI Installation Guide",
@@ -4446,7 +4450,7 @@
       "slug": "tela-cli/search-guide",
       "title": "TELA-CLI Search Guide | Advanced Search and Content Discovery Techniques",
       "description": "Master TELA-CLI search functionality - discover applications, filter by quality, find libraries, analyze smart contracts, and navigate the TELA ecosystem efficiently.",
-      "canonicalUrl": "https://tela.derod.org/tela-cli/search-guide",
+      "canonicalUrl": "https://tela.derod.org/tela-cli/search-guide.md",
       "sourcePath": "tela-main/pages/tela-cli/search-guide.mdx",
       "headings": [
         "TELA-CLI Search Guide",
@@ -4655,7 +4659,7 @@
       "slug": "tela-cli/troubleshooting",
       "title": "TELA-CLI Troubleshooting Guide",
       "description": "Common issues, solutions, and debugging techniques for TELA-CLI",
-      "canonicalUrl": "https://tela.derod.org/tela-cli/troubleshooting",
+      "canonicalUrl": "https://tela.derod.org/tela-cli/troubleshooting.md",
       "sourcePath": "tela-main/pages/tela-cli/troubleshooting.mdx",
       "headings": [
         "TELA-CLI Troubleshooting",
@@ -4853,7 +4857,7 @@
       "slug": "tela-cli/workflows",
       "title": "TELA-CLI Workflows & Examples | Step-by-Step Development Guides",
       "description": "Step-by-step development workflows, automation examples, and best practices for TELA-CLI. Complete guides for deployment, testing, and production workflows.",
-      "canonicalUrl": "https://tela.derod.org/tela-cli/workflows",
+      "canonicalUrl": "https://tela.derod.org/tela-cli/workflows.md",
       "sourcePath": "tela-main/pages/tela-cli/workflows.mdx",
       "headings": [
         "TELA-CLI Workflows",
@@ -5022,7 +5026,7 @@
       "slug": "tela/overview",
       "title": "TELA Platform Overview | Decentralized Web Standard for DERO Blockchain",
       "description": "Complete overview of TELA - The Enhanced Local Applications platform for building decentralized web applications on DERO blockchain with complete privacy and censorship resistance.",
-      "canonicalUrl": "https://tela.derod.org/tela/overview",
+      "canonicalUrl": "https://tela.derod.org/tela/overview.md",
       "sourcePath": "tela-main/pages/tela/overview.mdx",
       "headings": [
         "TELA Platform Overview",
@@ -5054,7 +5058,7 @@
       "slug": "tela/tela-content-rating-system",
       "title": "TELA Content Rating System | Community-Driven Quality Assessment on DERO",
       "description": "Understanding TELA's integrated rating system that helps users evaluate content quality and trustworthiness. On-chain ratings with blockchain transparency and one vote per account.",
-      "canonicalUrl": "https://tela.derod.org/tela/tela-content-rating-system",
+      "canonicalUrl": "https://tela.derod.org/tela/tela-content-rating-system.md",
       "sourcePath": "tela-main/pages/tela/tela-content-rating-system.mdx",
       "headings": [
         "TELA Content Rating System",
@@ -5075,7 +5079,7 @@
       "slug": "tela/tela-doc-index-structures",
       "title": "TELA DOC vs INDEX | Core Concepts of TELA Smart Contract Architecture",
       "description": "Understand TELA's two core contract types — DOC and INDEX — and how they work together to build decentralized apps on DERO blockchain. Learn modular, updatable contract design.",
-      "canonicalUrl": "https://tela.derod.org/tela/tela-doc-index-structures",
+      "canonicalUrl": "https://tela.derod.org/tela/tela-doc-index-structures.md",
       "sourcePath": "tela-main/pages/tela/tela-doc-index-structures.mdx",
       "headings": [
         "Core Concepts: DOC vs INDEX",
@@ -5105,7 +5109,7 @@
       "slug": "tela/tela-doc-specification",
       "title": "TELA-DOC-1 Specification | Smart Contract Standard for File Storage",
       "description": "Complete specification for TELA-DOC-1 smart contracts - the standard for storing code files on DERO blockchain. Includes docTypes, size limits, compression, and deployment procedures.",
-      "canonicalUrl": "https://tela.derod.org/tela/tela-doc-specification",
+      "canonicalUrl": "https://tela.derod.org/tela/tela-doc-specification.md",
       "sourcePath": "tela-main/pages/tela/tela-doc-specification.mdx",
       "headings": [
         "TELA-DOC-1 Specification",
@@ -5185,7 +5189,7 @@
       "slug": "tela/tela-index-specification",
       "title": "TELA-INDEX-1 Specification | Application Manifest Smart Contract Standard",
       "description": "Complete specification for TELA-INDEX-1 smart contracts - the manifest standard for TELA applications. Includes structure, UpdateCode function, MODs integration, and size limits.",
-      "canonicalUrl": "https://tela.derod.org/tela/tela-index-specification",
+      "canonicalUrl": "https://tela.derod.org/tela/tela-index-specification.md",
       "sourcePath": "tela-main/pages/tela/tela-index-specification.mdx",
       "headings": [
         "TELA-INDEX-1 Specification",
@@ -5285,7 +5289,7 @@
       "slug": "tela/tela-security-model",
       "title": "TELA Security Model | Zero-Trust Architecture for Decentralized Applications",
       "description": "A concise overview of TELA's security approach, including blockchain immutability, cryptographic verification, and trust mechanisms for decentralized applications on DERO.",
-      "canonicalUrl": "https://tela.derod.org/tela/tela-security-model",
+      "canonicalUrl": "https://tela.derod.org/tela/tela-security-model.md",
       "sourcePath": "tela-main/pages/tela/tela-security-model.mdx",
       "headings": [
         "TELA Security Model",
@@ -5311,7 +5315,7 @@
       "slug": "templates/basic-app",
       "title": "Basic TELA App Template | Complete Starter with XSWD Integration",
       "description": "Complete starter template based on proven tela_tests patterns. Production-ready TELA application with XSWD connection, modern UI, and dashboard components.",
-      "canonicalUrl": "https://tela.derod.org/templates/basic-app",
+      "canonicalUrl": "https://tela.derod.org/templates/basic-app.md",
       "sourcePath": "tela-main/pages/templates/basic-app.mdx",
       "headings": [
         "Basic TELA App Template",
@@ -5330,7 +5334,7 @@
       "slug": "templates/overview",
       "title": "TELA Project Templates",
       "description": "Ready-to-use project templates for building TELA applications quickly",
-      "canonicalUrl": "https://tela.derod.org/templates/overview",
+      "canonicalUrl": "https://tela.derod.org/templates/overview.md",
       "sourcePath": "tela-main/pages/templates/overview.mdx",
       "headings": [
         "TELA Project Templates",
@@ -5368,7 +5372,7 @@
       "slug": "templates/xswd-advanced",
       "title": "XSWD Advanced | Official Production-Grade TELA XSWD Library",
       "description": "Production-grade XSWD implementation with multi-endpoint fallback, privacy monitoring, and high-level API methods. The official XSWD library for TELA applications.",
-      "canonicalUrl": "https://tela.derod.org/templates/xswd-advanced",
+      "canonicalUrl": "https://tela.derod.org/templates/xswd-advanced.md",
       "sourcePath": "tela-main/pages/templates/xswd-advanced.mdx",
       "headings": [
         "XSWD Advanced - Official TELA Library",
@@ -5397,7 +5401,7 @@
       "slug": "templates/xswd-basic",
       "title": "XSWD Basic Core | Lightweight XSWD Library Under 18KB",
       "description": "Lightweight XSWD implementation under 18KB for basic TELA applications. Simple DERO wallet connectivity without advanced features for size-constrained apps.",
-      "canonicalUrl": "https://tela.derod.org/templates/xswd-basic",
+      "canonicalUrl": "https://tela.derod.org/templates/xswd-basic.md",
       "sourcePath": "tela-main/pages/templates/xswd-basic.mdx",
       "headings": [
         "XSWD Basic Core",
@@ -5419,7 +5423,7 @@
       "slug": "tutorials/first-app",
       "title": "First App Tutorial | Build Your First TELA Application",
       "description": "Complete step-by-step tutorial to build your first TELA application - from environment setup to deployment on DERO blockchain. Learn XSWD integration and deploy private web apps.",
-      "canonicalUrl": "https://tela.derod.org/tutorials/first-app",
+      "canonicalUrl": "https://tela.derod.org/tutorials/first-app.md",
       "sourcePath": "tela-main/pages/tutorials/first-app.mdx",
       "headings": [
         "First App Tutorial",
@@ -5470,7 +5474,7 @@
       "slug": "tutorials/launch-tela-site",
       "title": "How to Launch a TELA Site Using TELA-CLI | Complete Deployment Tutorial",
       "description": "A comprehensive step-by-step guide to creating and deploying your own decentralized TELA site on the DERO blockchain using the TELA-CLI tool. From local testing to production deployment.",
-      "canonicalUrl": "https://tela.derod.org/tutorials/launch-tela-site",
+      "canonicalUrl": "https://tela.derod.org/tutorials/launch-tela-site.md",
       "sourcePath": "tela-main/pages/tutorials/launch-tela-site.mdx",
       "headings": [
         "Launch a TELA site (CLI)",
@@ -5531,7 +5535,7 @@
       "slug": "tutorials/version-upgrades",
       "title": "TELA Version Upgrades & Changes | Managing Application Updates",
       "description": "Guide to upgrading TELA applications, handling breaking changes, and managing version compatibility. Complete strategy for immutable smart contract updates.",
-      "canonicalUrl": "https://tela.derod.org/tutorials/version-upgrades",
+      "canonicalUrl": "https://tela.derod.org/tutorials/version-upgrades.md",
       "sourcePath": "tela-main/pages/tutorials/version-upgrades.mdx",
       "headings": [
         "TELA Version Upgrades & Changes",
@@ -5652,7 +5656,7 @@
       "slug": "xswd",
       "title": "XSWD Protocol Overview | Secure WebSocket for DERO Wallet Integration",
       "description": "Complete guide to XSWD protocol for TELA application development. Learn secure wallet integration and blockchain communication.",
-      "canonicalUrl": "https://tela.derod.org/xswd",
+      "canonicalUrl": "https://tela.derod.org/xswd.md",
       "sourcePath": "tela-main/pages/xswd.mdx",
       "headings": [
         "XSWD Protocol Overview",