dero-mcp-server 0.4.1 → 0.4.2

package/data/docs-index.json

@@ -1,7 +1,7 @@
 {
   "version": 1,
-  "generated_at": "2026-05-31T20:35:13.976Z",
-  "page_count": 146,
+  "generated_at": "2026-06-06T01:53:21.762Z",
+  "page_count": 147,
   "pages": [
     {
       "product": "derod",
@@ -18,7 +18,7 @@
         "Developer Resources",
         "Community & Support"
       ],
-      "plainText": "DERO - Quick Reference Guide Complete guide to building on DERO DERO Blockchain This documentation covers everything from running nodes and mining to building private smart contracts and decentralized applications. Core Features <Card title=\"Homomorphic Encryption\" href=\"/privacy/homomorphic-encryption\" image > <>Homomorphic Encryption <Card title=\"Private Smart Contracts\" href=\"/features/smart-contracts\" image > <>Smart Contracts <Card title=\"DERO Virtual Machine\" href=\"/features/dvm\" image > <>DVM Essential Resources Get started with these essential DERO resources: <>Official Homepage <>Wallet <>GitHub <>GitHub <>GitHub <>Whitepaper Developer Resources <>Smart Contracts <>API Docs <>TELA Community & Support Join our active community: <>Discord <>Forum <>Matrix Ready to build on DERO? Explore the developer documentation to get started with smart contracts, learn about the DERO Virtual Machine, and discover how to integrate with the DERO blockchain.",
+      "plainText": "DERO - Quick Reference Guide Complete guide to building on DERO DERO Blockchain This documentation covers everything from running nodes and mining to building private smart contracts and decentralized applications. Core Features <>Homomorphic Encryption <>Smart Contracts <>DVM Essential Resources Get started with these essential DERO resources: <>Official Homepage <>Wallet <>GitHub <>GitHub <>GitHub <>Whitepaper Developer Resources <>Smart Contracts <>API Docs <>TELA Community & Support Join our active community: <>Discord <>Forum <>Matrix Ready to build on DERO? Explore the developer documentation to get started with smart contracts, learn about the DERO Virtual Machine, and discover how to integrate with the DERO blockchain.",
       "lastUpdated": "2025-05-29"
     },
     {
@@ -40,7 +40,7 @@
         "DERO in Production",
         "Related Pages"
       ],
-      "plainText": "What is DERO? What is DERO? The First Blockchain with Private Smart Contracts DERO combines **Bitcoin's security model** with **Ethereum's smart contracts** and **class-leading privacy** - all written from scratch in high-performance Golang. **What makes DERO unique:** - 🔒 **Private by Default** - All balances encrypted (homomorphic encryption) - ⚡ **Instant Confirmation** - Same-block finality (18 seconds) - 🎯 **Private Smart Contracts** - Full Turing-complete DVM with encrypted state - 🔐 **Ring Signatures** - Transaction anonymity (2-128 ring size) - 🌐 **TLS P2P Network** - Encrypted peer-to-peer communication Privacy-Preserving Features <Card icon={ <svg xmlns=\"http://www.w3.org/2000/svg\" fill=\"#2a9cbb\" viewBox=\"0 0 330.99 382.2\" style={{ width: '30px', height: '30px' }} > <path d=\"m254.78,139.55v103.1l-51.6,29.79c-.29-1.78-6.2-39.56-6.96-44.89l16.21-9.35v-54.2l-46.94-27.1-46.93,27.1v54.2l15.93,9.2c-.76,5.38-6.67,43.16-6.96,44.89l-51.33-29.64v-103.1l89.29-51.55,89.29,51.55Z\" /> <path d=\"m197.56,172.58v37.04l-17.5,10.1c.74,5.28,8.97,58.11,9.39,60.65l-23.96,13.83-23.61-13.63c.51-2.99,8.67-55.36,9.41-60.64l-17.87-10.31v-37.04l32.07-18.51,32.07,18.51Z\" /> } title=\"Homomorphic Encryption\" href=\"/privacy/homomorphic-encryption\" /> <Card icon={ } title=\"Private Smart Contracts\" href=\"/features/smart-contracts\" /> <Card icon={ } title=\"Turing Complete DVM\" href=\"/features/dvm\" /> <Card icon={ } title=\"Encrypted Network\" href=\"/features/encrypted-network\" /> <Card icon={ } title=\"PoW Mining\" href=\"/basics/mining\" /> <Card icon={ } title=\"Lightweight Wallet\" href=\"/basics/wallets\" /> Technical Specifications - Layer 1 Private Decentralized Application Platform - Fully Encrypted Blockchain - Fully Auditable Supply - 18 Second Blocktime - Same block/instant confirmation - No Soft Forks/Chain Splits - SSL/TLS UDP P2P Network - No Orphan Blocks - Homomorphic Encryption Protocol - Native dApp Support - Written from Scratch in Golang - 1.25 MB Block Size Cryptography & Consensus | Technology | Purpose | Why It Matters | |------------|---------|----------------| | **Bulletproofs** | Zero-knowledge range proofs | Proves amounts without revealing them | | **AstroBWT** | Mining algorithm (CPU-optimized) | Fair distribution, ASIC-resistant | | **Homomorphic Encryption** | Encrypted balance operations | Add/subtract without decryption | | **Ring Signatures** | Transaction anonymity | Hide sender among ring_size/2 potential senders (rings split evenly between senders and recipients) | | **Σ-blocks (Sigma)** | Fast consensus | 1-second miniblocks, 18-second settlement | **Source:** cryptography/crypto/ - Cryptographic implementations Tokenomics (Bitcoin Model) | Metric | Value | Notes | |--------|-------|-------| | **Ticker** | DERO | Native currency | | **Max Supply** | 21 Million | Same as Bitcoin | | **Mining Algorithm** | AstroBWT | CPU-optimized, ASIC-resistant | | **Block Time** | 18 seconds | vs Bitcoin's 10 minutes | | **Block Reward** | ~0.615 DERO | Halving every 4 years | | **Atomic Units** | 5 decimals | 1 DERO = 100,000 atomic units | | **Difficulty Adjustment** | Every block | Fast adaptation | **Emission:** Bitcoin-style halving schedule ensures predictable, deflationary supply. How DERO Compares | Feature | DERO | Other Privacy Coins | Ethereum | Bitcoin | |---------|------|---------------------|----------|---------| | **Privacy** | ✅ Default | ✅ Default | ❌ Public | ❌ Public | | **Smart Contracts** | ✅ Private | ❌ No | ✅ Public | ❌ No | | **Encrypted Balances** | ✅ Yes | ❌ No | ❌ No | ❌ No | | **Block Time** | ⚡ 18s | 🐢 2+ min | ⚡ 12s | 🐢 10 min | | **Language** | Golang | C++ | Various | C++ | | **ASIC Resistance** | ✅ Yes | ✅ Varies | N/A (PoS) | ❌ No | **DERO's Unique Position:** The only blockchain combining privacy-by-default with private smart contracts --- Why DERO Matters **For Users:** - Private transactions (no one can see your balance) - Fast confirmations (18 seconds vs Bitcoin's 10 minutes) - Private dApps (interact without revealing identity) **For Developers:** - Build private DeFi, games, DAOs with DVM-BASIC - Homomorphic encryption (balances stay encrypted on-chain) - No gas fees in Ethereum's sense (predictable costs) **For Miners:** - CPU mining (fair distribution, no ASICs) - Σ-blocks (earn rewards every second) - Integrator rewards (10% of blocks on your public node) --- DERO in Production **Live Since:** 2017 (8+ years) **Mainnet:** Stargate (current version) **Development:** Active, open-source **Community:** Discord, GitHub, Reddit **Built for:** Privacy-focused applications, private DeFi, anonymous gaming, secure messaging, confidential business logic --- Related Pages **Get Started:** - DERO Wallets - Choose a wallet - DERO Mining - Start mining - Running a Node - Run your own node **Core Features:** - Privacy Suite - Complete privacy overview - DERO Tokens - Private assets - Smart Contracts - DVM architecture **Technical Details:** - Homomorphic Encryption - Encrypted balances - Ring Signatures - Transaction anonymity - Golang Performance - Why DERO is fast **Build on DERO:** - DVM-BASIC Guide - Smart contract programming - Token Contract Tutorial - Build a token",
+      "plainText": "What is DERO? What is DERO? The First Blockchain with Private Smart Contracts DERO combines **Bitcoin's security model** with **Ethereum's smart contracts** and **class-leading privacy** - all written from scratch in high-performance Golang. **What makes DERO unique:** - 🔒 **Private by Default** - All balances encrypted (homomorphic encryption) - ⚡ **Instant Confirmation** - Same-block finality (18 seconds) - 🎯 **Private Smart Contracts** - Full Turing-complete DVM with encrypted state - 🔐 **Ring Signatures** - Transaction anonymity (2-128 ring size) - 🌐 **TLS P2P Network** - Encrypted peer-to-peer communication Privacy-Preserving Features } title=\"Homomorphic Encryption\" href=\"/privacy/homomorphic-encryption\" /> } title=\"Private Smart Contracts\" href=\"/features/smart-contracts\" /> } title=\"Turing Complete DVM\" href=\"/features/dvm\" /> } title=\"Encrypted Network\" href=\"/features/encrypted-network\" /> } title=\"PoW Mining\" href=\"/basics/mining\" /> } title=\"Lightweight Wallet\" href=\"/basics/wallets\" /> Technical Specifications - Layer 1 Private Decentralized Application Platform - Fully Encrypted Blockchain - Fully Auditable Supply - 18 Second Blocktime - Same block/instant confirmation - No Soft Forks/Chain Splits - SSL/TLS UDP P2P Network - No Orphan Blocks - Homomorphic Encryption Protocol - Native dApp Support - Written from Scratch in Golang - 1.25 MB Block Size Cryptography & Consensus | Technology | Purpose | Why It Matters | |------------|---------|----------------| | **Bulletproofs** | Zero-knowledge range proofs | Proves amounts without revealing them | | **AstroBWT** | Mining algorithm (CPU-optimized) | Fair distribution, ASIC-resistant | | **Homomorphic Encryption** | Encrypted balance operations | Add/subtract without decryption | | **Ring Signatures** | Transaction anonymity | Hide sender among ring_size/2 potential senders (rings split evenly between senders and recipients) | | **Σ-blocks (Sigma)** | Fast consensus | 1-second miniblocks, 18-second settlement | **Source:** cryptography/crypto/ - Cryptographic implementations Tokenomics (Bitcoin Model) | Metric | Value | Notes | |--------|-------|-------| | **Ticker** | DERO | Native currency | | **Max Supply** | 21 Million | Same as Bitcoin | | **Mining Algorithm** | AstroBWT | CPU-optimized, ASIC-resistant | | **Block Time** | 18 seconds | vs Bitcoin's 10 minutes | | **Block Reward** | ~0.615 DERO | Halving every 4 years | | **Atomic Units** | 5 decimals | 1 DERO = 100,000 atomic units | | **Difficulty Adjustment** | Every block | Fast adaptation | **Emission:** Bitcoin-style halving schedule ensures predictable, deflationary supply. How DERO Compares | Feature | DERO | Other Privacy Coins | Ethereum | Bitcoin | |---------|------|---------------------|----------|---------| | **Privacy** | ✅ Default | ✅ Default | ❌ Public | ❌ Public | | **Smart Contracts** | ✅ Private | ❌ No | ✅ Public | ❌ No | | **Encrypted Balances** | ✅ Yes | ❌ No | ❌ No | ❌ No | | **Block Time** | ⚡ 18s | 🐢 2+ min | ⚡ 12s | 🐢 10 min | | **Language** | Golang | C++ | Various | C++ | | **ASIC Resistance** | ✅ Yes | ✅ Varies | N/A (PoS) | ❌ No | **DERO's Unique Position:** The only blockchain combining privacy-by-default with private smart contracts --- Why DERO Matters **For Users:** - Private transactions (no one can see your balance) - Fast confirmations (18 seconds vs Bitcoin's 10 minutes) - Private dApps (interact without revealing identity) **For Developers:** - Build private DeFi, games, DAOs with DVM-BASIC - Homomorphic encryption (balances stay encrypted on-chain) - No gas fees in Ethereum's sense (predictable costs) **For Miners:** - CPU mining (fair distribution, no ASICs) - Σ-blocks (earn rewards every second) - Integrator rewards (10% of blocks on your public node) --- DERO in Production **Live Since:** 2017 (8+ years) **Mainnet:** Stargate (current version) **Development:** Active, open-source **Community:** Discord, GitHub, Reddit **Built for:** Privacy-focused applications, private DeFi, anonymous gaming, secure messaging, confidential business logic --- Related Pages **Get Started:** - DERO Wallets - Choose a wallet - DERO Mining - Start mining - Running a Node - Run your own node **Core Features:** - Privacy Suite - Complete privacy overview - DERO Tokens - Private assets - Smart Contracts - DVM architecture **Technical Details:** - Homomorphic Encryption - Encrypted balances - Ring Signatures - Transaction anonymity - Golang Performance - Why DERO is fast **Build on DERO:** - DVM-BASIC Guide - Smart contract programming - Token Contract Tutorial - Build a token",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -56,12 +56,17 @@
         "Network Ports",
         "Mainnet",
         "Testnet",
+        "Verify your binaries",
+        "Reading the derod prompt",
+        "MB / MBR / IB counters",
         "Running Your Own Node",
         "With custom settings",
         "Integrator Rewards",
         "The 10% Daemon Bonus",
         "Sync Status",
         "Daemon display",
+        "Pruned-node height — why your status looks short",
+        "When your node gets stuck — the pop escalation",
         "Daemon as Mining Pool",
         "Miner connects to daemon",
         "Key Features",
@@ -74,7 +79,7 @@
         "Why Run a Daemon?",
         "Related Pages"
       ],
-      "plainText": "DERO Daemon (Node) DERO Daemon The DERO daemon (derod) is the core software that runs the DERO blockchain network. It validates transactions, maintains the blockchain, and connects peers in a decentralized P2P network. **Download:** GitHub Releases --- What Does a Daemon Do? | Function | What It Does | Source Code | |----------|-------------|-------------| | **Transaction Validation** | Verify proofs, ring sigs, bulletproofs | blockchain/transaction_verify.go | | **Block Processing** | Execute transactions, update balances | blockchain/transaction_execute.go:239 | | **P2P Networking** | Sync with peers, propagate blocks/TXs | p2p/connection.go | | **Mining** | Provide PoW templates, validate solutions | blockchain/mining.go | | **RPC API** | Serve wallet requests, smart contract calls | rpc/rpc_dero.go | --- Network Ports Mainnet | Service | Port | Purpose | |---------|------|---------| | **P2P** | 10101 | Node-to-node communication | | **RPC** | 10102 | Daemon RPC API | | **Wallet RPC** | 10103 | Wallet communication | Testnet | Service | Port | Purpose | |---------|------|---------| | **P2P** | 40401 | Node-to-node communication | | **RPC** | 40402 | Daemon RPC API | | **Wallet RPC** | 40403 | Wallet communication | **Source:** config/config.go - Network configuration --- Running Your Own Node **Basic command:** **System Requirements:** - **CPU:** 2 to 4 cores minimum - **RAM:** 4GB minimum - **Disk:** 15GB+ SSD (grows over time) - **Network:** Stable internet connection --- Integrator Rewards The 10% Daemon Bonus **How it works:** **Why run your own daemon:** - ✅ Earn 10% integrator rewards (vs 1.6% fee to pool operators) - ✅ Support network decentralization - ✅ Full privacy (no third-party node) - ✅ Contribute to blockchain security **Source:** Miniblock system described in blockchain/blockchain.go --- Sync Status **Understanding the numbers:** **Fast sync vs Full sync:** - **Full sync:** Downloads and validates entire blockchain (slow, complete) - **Fast sync:** Downloads state snapshots (faster, still secure) --- Daemon as Mining Pool Each daemon acts as its own mining pool: | Role | Fee | How It Works | |------|-----|--------------| | **Daemon Operator** | 1.6% | Runs node, provides infrastructure | | **Miners** | 88.4% | Connect and mine, split proportionally | | **Integrator** | 10% | Daemon's address for integrator blocks | **Total:** 100% (nothing wasted) **Connect miners to your daemon:** **Daemon tracks shares and distributes rewards automatically** **Source:** Mining pool logic in blockchain/miniblocks.go --- Key Features Privacy-Preserving - ✅ TLS-encrypted P2P connections - ✅ Stores encrypted balances (ElGamal) - ✅ Validates without revealing amounts - ✅ No metadata leakage Lightweight Storage Fast Validation - Block time: ~18 seconds - Transaction verification: under 25ms - Instant balance queries: 66 bytes --- Daemon Commands **Interactive mode:** **Useful RPC calls:** --- Why Run a Daemon? **Benefits:** | Benefit | Description | |---------|-------------| | **Privacy** | No third-party sees your queries | | **Integrator Rewards** | Earn 10% of blocks mined on your node | | **Network Support** | Contribute to decentralization | | **Self-Sovereignty** | Complete control, no trust needed | | **Mining Pool** | Support friends/family mining | **Trade-offs:** - Requires: Always-on machine, disk space, bandwidth - Maintains: Full blockchain copy - Syncs: Initially time-consuming --- Related Pages **Get Started:** - Running a Node - Complete VPS setup guide - DERO Mining - How to mine with your node **API & Integration:** - Daemon RPC API - Full API reference - Network Ports & Setup - P2P network details **Understanding DERO:** - DERO Blockchain - How DERO works - Smart Contracts - DVM integration",
+      "plainText": "DERO Daemon (Node) DERO Daemon The DERO daemon (derod) is the core software that runs the DERO blockchain network. It validates transactions, maintains the blockchain, and connects peers in a decentralized P2P network. **Download:** GitHub Releases --- What Does a Daemon Do? | Function | What It Does | Source Code | |----------|-------------|-------------| | **Transaction Validation** | Verify proofs, ring sigs, bulletproofs | blockchain/transaction_verify.go | | **Block Processing** | Execute transactions, update balances | blockchain/transaction_execute.go:239 | | **P2P Networking** | Sync with peers, propagate blocks/TXs | p2p/connection.go | | **Mining** | Provide PoW templates, validate solutions | blockchain/mining.go | | **RPC API** | Serve wallet requests, smart contract calls | rpc/rpc_dero.go | --- Network Ports Mainnet | Service | Port | Purpose | |---------|------|---------| | **P2P** | 10101 | Node-to-node communication — **randomized at startup**; pin with --p2p-bind=0.0.0.0:10101 (details) | | **RPC** | 10102 | Daemon RPC API | | **Wallet RPC** | 10103 | Wallet communication | Testnet | Service | Port | Purpose | |---------|------|---------| | **P2P** | 40401 | Node-to-node communication (randomized; pin with --p2p-bind=0.0.0.0:40401) | | **RPC** | 40402 | Daemon RPC API | | **Wallet RPC** | 40403 | Wallet communication | **Source:** config/config.go (RPC + GETWORK ports); p2p/controller.go:502 (P2P default 0.0.0.0:0 — random); README.md:133 (10101 convention). --- Verify your binaries Before running derod or dero-wallet-cli from a download, confirm the binary matches Captain's published GPG signature and the release sha512sum: > Please every-time verify checksum of DERO binaries/source after downloading from github. > > — Captain, 2022-12-25, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1056519143932829716) Full instructions for installing Captain's GPG key and running the verification end-to-end are in the DERO forum thread. --- Reading the derod prompt When you start derod, the top of the terminal looks like this: > Details about DERO daemon prompt. Also run status/syncinfo/help cmd in daemon for details. > > — Captain, 2023-04-12, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/1095749633671712890) Every field on the prompt is a live signal. Once you can read it, you can diagnose almost any daemon problem at a glance. | # | Field on prompt | Meaning | |---|---|---| | 1 | 146658/146658 | **Local sync height** — your node's chain tip | | 2 | [146658/146658] | **Network height** — what your peers agree on | | 3 | P 17 | **Peers** — daemons currently connected to you | | 4 | TXp 0 | **TX pool** — transactions waiting to be included | | 5 | 0 | **Registration pool** — wallet registrations waiting | | 6 | NW 4.200 GH/s | **Global network hashrate** | | 7 | >Miners 1 | **Miners** connected to your daemon | | 8 | 98 | **Miniblocks** currently active in this machine's RAM | | 9 | 0s\\|0s | **Time offsets** — NTP vs peer-derived | | 10 | 2ms>> | **Latency** between this daemon and its peers | Read the prompt left to right: - When **1** and **2** match, you're synced. - When **9** shows non-zero seconds, your clock is drifting — fix NTP (see Mining → Time sync — install chrony). - When **10** climbs into the hundreds of ms, check your network. Three commands give you more detail any time you need it: MB / MBR / IB counters When you're mining (or operating a daemon other miners connect to), three additional counters appear under the prompt's Mining Stats: | Code | Meaning | Healthy? | |---|---|---| | MB | Miniblock submitted | yes | | MBR | Miniblock rejected (usually invalid PoW) | only if rare | | IB | Integrator block submitted | yes | > MB-> Minblock submitted. MBR: Miniblock rejected due to invalidPOW or so. IB-> Integrator Block submitted. > > — Captain, 2022-05-05, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/971678950562594946); verified · Release 142: cmd/derod/main.go:904 The status command's Block Minted line is (MB + IB) − MBR — so when MBR climbs, your minted count visibly drops. MBR is PoW-test rejection only (cmd/derod/rpc/websocket_getwork_server.go:137), so the root-causes to check, in order: (1) clock drift on the miner host (Mining → Time sync); (2) network instability dropping work mid-flight; (3) an unofficial miner binary submitting malformed work — switch back to the official dero-miner. --- Running Your Own Node **Basic command:** **System Requirements:** - **CPU:** 2 to 4 cores minimum - **RAM:** 4GB minimum - **Disk:** 15GB+ SSD (grows over time) - **Network:** Stable internet connection --- Integrator Rewards The 10% Daemon Bonus **How it works:** **Why run your own daemon:** - ✅ Earn 10% integrator rewards (vs 1.6% fee to pool operators) - ✅ Support network decentralization - ✅ Full privacy (no third-party node) - ✅ Contribute to blockchain security **Source:** Miniblock system described in blockchain/blockchain.go --- Sync Status **Understanding the numbers:** **Fast sync vs Full sync:** - **Full sync:** Downloads and validates entire blockchain (slow, complete) - **Fast sync:** Downloads state snapshots (faster, still secure) Pruned-node height — why your status looks short If you started your node with --fastsync, status will print a line like: …meaning blocks before that point exist only on full-history nodes. The chain still validates correctly — you just can't serve TX queries from before the prune point. > Pls run status cmd in daemon & see what is your pruned node height. TXs before pruned height will not appear. > > — Captain, 2022-12-20, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1054735099553386557) If you need full history (e.g. to serve TX queries from genesis), there is no \"backfill\" — --fastsync is a bootstrap-only flag (cmd/derod/main.go:73), and toggling it off post-bootstrap doesn't recover pruned blocks. Captain's recommended path for full history is to start over: stop derod, delete the mainnet/ folder, and run a full sync from zero (no --fastsync). > Don't use --fastsync. Sync full node. > > — Captain, 2022-03-05, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/949516853619855480) When your node gets stuck — the pop escalation If your daemon stops advancing or believes a wrong tip, Captain's recommended recovery is to rewind blocks from the top and let the chain re-sync from your peers. > pop 20 or 50000 blocks & see if you can start sync again. if not delete mainnet folder & start fullsync again, It takes 1 -2 days to do full sync on recent cpus with SSD. Sync may appear very slow for few hrs for some duration but it will sync very fast after that. > > — Captain, 2023-01-22, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/1066560738862301225); verified · Release 142: cmd/derod/main.go:981 (case command == 'pop') In practice the ladder operators converge on is: | Step | Command | When | |---|---|---| | 1 | pop 20 (in derod) | Brief hiccup, recent fork | | 2 | pop 50000 | After step 1 doesn't unstick within minutes | | 3 | Stop derod → delete the mainnet/ folder → restart with --fastsync | Nuclear option | Steps 1 and 2 are Captain's direct recommendation. Intermediate values (pop 1000, pop 10000) work the same way — pop N simply rewinds N blocks; pick whatever distance reflects how far back you suspect the wedge is. --- Daemon as Mining Pool Each daemon acts as its own mining pool: | Role | Fee | How It Works | |------|-----|--------------| | **Daemon Operator** | 1.6% | Runs node, provides infrastructure | | **Miners** | 88.4% | Connect and mine, split proportionally | | **Integrator** | 10% | Daemon's address for integrator blocks | **Total:** 100% (nothing wasted) **Connect miners to your daemon:** **Daemon tracks shares and distributes rewards automatically** **Source:** Mining pool logic in blockchain/miniblocks.go --- Key Features Privacy-Preserving - ✅ TLS-encrypted P2P connections - ✅ Stores encrypted balances (ElGamal) - ✅ Validates without revealing amounts - ✅ No metadata leakage Lightweight Storage Fast Validation - Block time: ~18 seconds - Transaction verification: under 25ms - Instant balance queries: 66 bytes --- Daemon Commands **Interactive mode:** **Useful RPC calls:** --- Why Run a Daemon? **Benefits:** | Benefit | Description | |---------|-------------| | **Privacy** | No third-party sees your queries | | **Integrator Rewards** | Earn 10% of blocks mined on your node | | **Network Support** | Contribute to decentralization | | **Self-Sovereignty** | Complete control, no trust needed | | **Mining Pool** | Support friends/family mining | **Trade-offs:** - Requires: Always-on machine, disk space, bandwidth - Maintains: Full blockchain copy - Syncs: Initially time-consuming --- Related Pages **Get Started:** - Running a Node - Complete VPS setup guide - DERO Mining - How to mine with your node **API & Integration:** - Daemon RPC API - Full API reference - Network Ports & Setup - P2P network details **Understanding DERO:** - DERO Blockchain - How DERO works - Smart Contracts - DVM integration",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -92,10 +97,15 @@
         "Mining Algorithm",
         "AstroBWT v3",
         "Solo Mining Setup",
+        "Time sync — install chrony",
+        "Debian / Ubuntu",
+        "CentOS / RHEL / Fedora",
+        "Start and enable",
         "Reward Breakdown",
         "Mining Performance",
         "Hashrate Expectations",
         "Mining Pools vs Solo",
+        "Captain's doctrine — solo on your own node",
         "Getting Started",
         "Optimizing Mining",
         "Use all cores except 1 (keep system responsive)",
@@ -107,7 +117,7 @@
         "Key Takeaways",
         "Related Pages"
       ],
-      "plainText": "DERO Mining DERO Mining DERO's **Σ-blocks** (Sigma blocks) system turns the entire network into one giant mining pool. Even miners with 100 KH/s get daily rewards based on their hashrate contribution. **Solo Mining Made Easy:** No pools needed - the network automatically distributes rewards proportionally to all miners every few minutes. --- The Σ-Blocks Revolution **Traditional mining:** **DERO Σ-mining:** --- How It Works | Metric | Value | Notes | |--------|-------|-------| | **Miniblock time** | ~1-2 seconds | Σ-block (miniblock) emission | | **Main block** | 18 seconds | Settles 10 miniblocks | | **Settlement** | Every block | ~18 seconds | | **Daily miniblocks** | ~48,000 | 4,800 blocks × 10 miniblocks | | **Blocks per day** | ~4,800 | 86,400 seconds ÷ 18 | --- Reward Calculator **Your hashrate vs network determines reward frequency:** | Your Share of Network | Reward Frequency | Example Hashrate* | |----------------------|------------------|------------------| | 1/48,000 | Daily | 1 KH/s (if network = 48 MH/s) | | 1/96,000 | Every 2 days | 500 H/s (if network = 48 MH/s) | | 1/480,000 | Every 10 days | 100 H/s (if network = 48 MH/s) | *Network hashrate varies - check current hashrate in your daemon/miner output **Formula:** --- Mining Algorithm AstroBWT v3 **CPU-optimized, ASIC-resistant:** **Why CPU-only?** - ✅ Democratizes mining (everyone has CPU) - ✅ Prevents ASIC dominance - ✅ Lower barrier to entry - ✅ Better decentralization **Source:** astrobwt/ directory, pow/pow.go --- Solo Mining Setup **Step 1: Run Daemon** **Step 2: Start Miner** **Step 3: Monitor** --- Reward Breakdown **Every Σ-block reward distributed as:** | Recipient | Percentage | Goes To | |-----------|-----------|---------| | **Miners** | 88.4% | Split among share contributors | | **Integrator** | 10% | Daemon operator's address | | **Pool Fee** | 1.6% | Daemon operator (your daemon = you keep this!) | **If mining on your own daemon:** - You get: 88.4% (miner share) + 10% (integrator) + 1.6% (fee) = **100%** - Pool miners get: 88.4% only **Advantage:** 11.6% more rewards by running your own node! --- Mining Performance Hashrate Expectations **CPU Performance (approximate):** | CPU | Threads | Expected Hashrate | |-----|---------|------------------| | Intel i5 (modern) | 4 | 5-8 KH/s | | Intel i7 (modern) | 8 | 10-15 KH/s | | AMD Ryzen 5 | 6 | 8-12 KH/s | | AMD Ryzen 9 | 16 | 20-30 KH/s | | Server (high-end) | 32+ | 50-100+ KH/s | **Benchmark your hardware:** This runs local performance tests and shows hashrate for different thread counts. --- Mining Pools vs Solo | Aspect | Traditional Pool | DERO Solo (Σ-blocks) | |--------|-----------------|---------------------| | **Rewards** | Daily, but 2-5% fee | Daily, 0% fee (own node) | | **Setup** | Easy (just connect) | Medium (run daemon) | | **Centralization** | High (pool controls) | Low (you control) | | **Trust** | Trust pool operator | Trustless | | **Small miner friendly** | ✅ Yes | ✅ Yes (even better!) | **DERO = Best of both worlds** --- Getting Started **Quick start:** 1. **Download:** 2. **Run daemon:** 3. **Mine:** 4. **Profit:** --- Optimizing Mining **CPU Settings:** **Multiple Machines:** --- Mining Economics **Block reward:** Currently ~0.615 DERO per block (decreases over time via halving) **Daily emission:** **Your daily earnings (example):** *Values are approximate and change with network hashrate and block rewards* --- Common Questions **Q: Can I mine with GPU/ASIC?** A: No - AstroBWT is memory-hard, CPU-optimized. GPUs/ASICs have no advantage. **Q: Do I need a pool?** A: No - Σ-blocks make solo mining practical for everyone. **Q: How often do I get paid?** A: Miniblocks settle every 18 seconds (each main block). You receive rewards proportional to your contributed shares in each block. **Q: What if my hashrate is tiny?** A: You'll still get rewards proportional to your hashrate share! Even 100 H/s contributes to miniblocks and earns rewards, just less frequently than higher hashrates. --- Key Takeaways **What makes DERO mining special:** - ✅ **Σ-blocks** - Network is one giant pool - ✅ **Solo mining works** - Even for small miners - ✅ **Daily rewards** - Proportional to hashrate - ✅ **No pools needed** - Decentralized by design - ✅ **CPU-only** - Fair, accessible to all - ✅ **Integrator rewards** - 10% bonus for node operators **Start small, earn daily:** Even a laptop can mine DERO profitably. Try it with 1-2 threads and see rewards within hours! --- Related Pages **Get Started Mining:** - Run a Daemon - Setup your own node - Running a Node - VPS integrator node guide - DERO Wallets - Store your mining rewards **Technical Details:** - AstroBWT Algorithm - Mining algorithm explained - Golang Performance - Why DERO is fast **Resources:** - Mining Pools Stats - Available mining pools - Daemon RPC API - Get block templates for mining - DERO Discord - Mining help and community",
+      "plainText": "DERO Mining DERO Mining DERO's **Σ-blocks** (also called *Sigma blocks*, *Sigma Mining* in older Captain posts, or MiniBlock in the source tree) turn the entire network into one giant mining pool. Even miners with 100 KH/s get daily rewards based on their hashrate contribution. **Solo Mining Made Easy:** No pools needed - the network automatically distributes rewards proportionally to all miners every few minutes. --- The Σ-Blocks Revolution **Traditional mining:** **DERO Σ-mining:** --- How It Works | Metric | Value | Notes | |--------|-------|-------| | **Miniblock time** | ~1-2 seconds | Σ-block (miniblock) emission | | **Main block** | 18 seconds | Settles 10 miniblocks | | **Settlement** | Every block | ~18 seconds | | **Daily miniblocks** | ~48,000 | 4,800 blocks × 10 miniblocks | | **Blocks per day** | ~4,800 | 86,400 seconds ÷ 18 | --- Reward Calculator **Your hashrate vs network determines reward frequency:** | Your Share of Network | Reward Frequency | Example Hashrate* | |----------------------|------------------|------------------| | 1/48,000 | Daily | 1 KH/s (if network = 48 MH/s) | | 1/96,000 | Every 2 days | 500 H/s (if network = 48 MH/s) | | 1/480,000 | Every 10 days | 100 H/s (if network = 48 MH/s) | *Network hashrate varies - check current hashrate in your daemon/miner output **Formula:** --- Mining Algorithm AstroBWT v3 **CPU-optimized, ASIC-resistant:** **Why CPU-only?** - ✅ Democratizes mining (everyone has CPU) - ✅ Prevents ASIC dominance - ✅ Lower barrier to entry - ✅ Better decentralization **Source:** astrobwt/ directory, pow/pow.go --- Solo Mining Setup **Step 1: Run Daemon** **Step 2: Start Miner** **Step 3: Monitor** Time sync — install chrony Miniblocks carry timestamps. derod's peer time check rejects clock offsets over **±1 second** (p2p/timecheck.go:86) — sustained drift breaks chain sync and your blocks can be rejected by peers. MBR is a separate counter that tracks PoW-test failures only (cmd/derod/rpc/websocket_getwork_server.go:137 — *\"only counting rejected as those which didnot pass Pow test\"*), so clock drift won't show up there directly — it'll surface as failed peer time syncs and lost miniblocks. Captain's recommendation is **chrony**, not the default ntpd: > Install chrony much better than ntp. > > — Captain, 2022-11-22, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1044465263577419796) **Install:** **Captain's recommended config** — add to /etc/chrony.conf or /etc/chrony/chrony.conf: > Add in /etc/chrony.conf or /etc/chrony/chrony.conf following: server time.google.com iburst prefer server time.cloudflare.com iburst prefer > > — Captain, 2023-01-25, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1067800565876260874) **Verify:** If your derod prompt shows non-zero values in field 9 (time offsets — Bs|Cs|Dms), your clock is the problem — fix chrony first. --- Reward Breakdown **Every Σ-block reward distributed as:** | Recipient | Percentage | Goes To | |-----------|-----------|---------| | **Miners** | 88.4% | Split among share contributors | | **Integrator** | 10% | Daemon operator's address | | **Pool Fee** | 1.6% | Daemon operator (your daemon = you keep this!) | **If mining on your own daemon:** - You get: 88.4% (miner share) + 10% (integrator) + 1.6% (fee) = **100%** - Pool miners get: 88.4% only **Advantage:** 11.6% more rewards by running your own node! --- Mining Performance Hashrate Expectations **CPU Performance (approximate):** | CPU | Threads | Expected Hashrate | |-----|---------|------------------| | Intel i5 (modern) | 4 | 5-8 KH/s | | Intel i7 (modern) | 8 | 10-15 KH/s | | AMD Ryzen 5 | 6 | 8-12 KH/s | | AMD Ryzen 9 | 16 | 20-30 KH/s | | Server (high-end) | 32+ | 50-100+ KH/s | **Benchmark your hardware:** This runs local performance tests and shows hashrate for different thread counts. --- Mining Pools vs Solo | Aspect | Traditional Pool | DERO Solo (Σ-blocks) | |--------|-----------------|---------------------| | **Rewards** | Daily, but 2-5% fee | Daily, 0% fee (own node) | | **Setup** | Easy (just connect) | Medium (run daemon) | | **Centralization** | High (pool controls) | Low (you control) | | **Trust** | Trust pool operator | Trustless | | **Small miner friendly** | ✅ Yes | ✅ Yes (even better!) | **DERO = Best of both worlds** Captain's doctrine — solo on your own node This isn't editorial framing. It's the architect's direct recommendation, repeated across the post-Stargate window: > DERO doesn't require pools to mine. Solo mining is recommended on DERO network. Just run your own node & mine on local node. No need to pay any fees to anyone. > > — Captain, 2022-11-16, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1042283825910263888) > Solo mining to your own node is preferred way for your privacy & security of DERO network. > > — Captain, 2023-04-04, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1092655318678384710) Captain also shared specific reasoning during the same period: a single daemon supports more than 10,000 miners (2022-11-17, #suggestions), and bench tests show solo mining has same-or-better rewards than pool (2023-04-04, #dero-mining). Sigma Mining's miniblock structure means even small miners produce shares regularly — the long variance penalty that drives pool culture on Bitcoin doesn't apply here the same way. A single daemon supports 10,000+ connected miners, so even a family or small mining group can share one node without scaling concerns. --- Getting Started **Quick start:** 1. **Download:** 2. **Run daemon:** 3. **Mine:** 4. **Profit:** --- Optimizing Mining **CPU Settings:** **Multiple Machines:** --- Mining Economics **Block reward:** Currently ~0.615 DERO per block (decreases over time via halving) **Daily emission:** **Your daily earnings (example):** *Values are approximate and change with network hashrate and block rewards* --- Common Questions **Q: Can I mine with GPU/ASIC?** A: No - AstroBWT is memory-hard, CPU-optimized. GPUs/ASICs have no advantage. **Q: Do I need a pool?** A: No - Σ-blocks make solo mining practical for everyone. **Q: How often do I get paid?** A: Miniblocks settle every 18 seconds (each main block). You receive rewards proportional to your contributed shares in each block. **Q: What if my hashrate is tiny?** A: You'll still get rewards proportional to your hashrate share! Even 100 H/s contributes to miniblocks and earns rewards, just less frequently than higher hashrates. --- Key Takeaways **What makes DERO mining special:** - ✅ **Σ-blocks** - Network is one giant pool - ✅ **Solo mining works** - Even for small miners - ✅ **Daily rewards** - Proportional to hashrate - ✅ **No pools needed** - Decentralized by design - ✅ **CPU-only** - Fair, accessible to all - ✅ **Integrator rewards** - 10% bonus for node operators **Start small, earn daily:** Even a laptop can mine DERO profitably. Try it with 1-2 threads and see rewards within hours! --- Related Pages **Get Started Mining:** - Run a Daemon - Setup your own node - Running a Node - VPS integrator node guide - DERO Wallets - Store your mining rewards **Technical Details:** - AstroBWT Algorithm - Mining algorithm explained - Golang Performance - Why DERO is fast **Resources:** - Mining Pools Stats - Available mining pools - Daemon RPC API - Get block templates for mining - DERO Discord - Mining help and community",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -150,9 +160,10 @@
         "Returns:",
         "Check Connected Peers",
         "Firewall Configuration",
-        "Required Ports",
-        "P2P (required for syncing)",
-        "RPC (optional, for local access only)",
+        "DERO ports (Stargate mainnet)",
+        "P2P (pin the port first with --p2p-bind, then open the same port here)",
+        "GETWORK (only if miners connect from outside the host)",
+        "RPC (local access only — never expose to the internet)",
         "Initial Sync",
         "Sync Methods",
         "Downloads and validates the entire blockchain from genesis",
@@ -162,6 +173,7 @@
         "Downloads recent state snapshots instead of replaying from genesis",
         "Time: 30-60 minutes",
         "Result: functional, secure node. Pair with --prune-history to keep disk small.",
+        "Fastsync vs `--add-priority-node` — what each flag does",
         "Monitoring Sync Progress",
         "Check height increasing",
         "Synced when local height = network height",
@@ -191,12 +203,16 @@
         "Optimize for server environment",
         "For Home PC",
         "Optimize for home use (lower resource usage)",
+        "Run your own block explorer",
+        "Seed nodes are bootstrap only",
+        "`--remote` is convenience, not sovereignty",
+        "Connects to node.derofoundation.org:11012 — config/config.go:140-141",
         "Security Best Practices",
         "Benefits of Running a Node",
         "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** | 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",
+      "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 DERO ports (Stargate mainnet) | Service | Default Port | Notes | |---|---|---| | P2P | 10101 | **Randomized at startup** — check derod log for actual port, or pin with --p2p-bind=0.0.0.0:10101 | | RPC | 10102 | Daemon JSON-RPC | | Wallet RPC | 10103 | Wallet JSON-RPC | | GETWORK | 10100 | Miner connections (dero-miner --daemon-rpc-address=127.0.0.1:10100) | > P2P Default Port: 10101 But Randomized, check daemon during startup for exact port used or use --p2p-bind=0.0.0.0:10102. > > — Captain, 2023-04-30, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1102114373692047430); verified · Release 142: p2p/controller.go:502 (default_address := \"0.0.0.0:0\" — random port; --p2p-bind override on :503-516); README.md:133 (documented 10101 default) **Typo in Captain's example.** The --p2p-bind=0.0.0.0:10102 above is verbatim from Discord — 10102 is the **RPC** port (see the table). For P2P, pin 0.0.0.0:10101 to match the convention and the UFW example below. If you're behind NAT, **pin the P2P port** before opening firewall rules — randomization will silently break port forwarding. **Mainnet (UFW example):** **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. Fastsync vs --add-priority-node — what each flag does These two flags are commonly conflated. They solve different problems: | Flag | What it does | When to use | |---|---|---| | --fastsync | Skip historical block bodies during initial sync; download recent state snapshots instead. | One-time onboarding to get your node online quickly. **Bootstrap-only flag** — it's a no-op after first sync, so you can leave it on or drop it; either way you'll keep validating new blocks normally. | | --add-priority-node=ip:port | Always keep this specific peer connected during sync. | When you want to bias the sync process toward a peer you trust (a friend's node, a foundation seed, etc.). | > Fastsync is used to sync your node only. After your node is synced by normal/fastsync you can use it for mining. Priority node option is used to select node of your preference for sync process. > > — Captain, 2023-04-13, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1096083241334755348); verified · Release 142: cmd/derod/main.go:62,73,81 (docopt flag declarations + bootstrap-only semantics); blockchain/blockchain.go:268-269 (chain.Sync toggled from --fastsync) You can use both at the same time — fastsync to skip history, priority node to choose your seed. 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 --- Run your own block explorer You don't have to rely on explorer.dero.io. The explorer binary ships in the same release as derod and talks to your local daemon. Open http://127.0.0.1:8080 in your browser. > Personal explorer ./explorer-linux-amd64 --daemon-address=127.0.0.1:10102 --http-address=0.0.0.0:8080 Open in browser 127.0.0.1:8080 for your local explorer. > > — Captain, 2022-11-22, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1044599223645122642) Running a local explorer is the privacy-preserving default: public explorers see every query you make — block lookups, address checks, TX inspections — while the command Captain shared above runs against your own daemon, so nothing leaves the host. --- Seed nodes are bootstrap only DERO's seed nodes are not a control plane. They exist so a fresh node can find its first peers; after that, peer exchange takes over and the seed nodes can vanish without affecting your daemon. > DERO seed nodes are not required except to bootstrap network. DERO is actual decentralized network & will remain so. DERO core devs will never be part of some centralized thing. There are so many other protocols & chains which can be freezed/halted/selective, feel free to join those networks. > > — Captain, 2023-04-08, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1094238692203315281); verified · Release 142: config/seed_nodes.go:23,36 (Mainnet_seed_nodes / Testnet_seed_nodes); p2p/controller.go:265-270 (bootstrap-only seed dial); :431-434 (random seed pick on rebootstrap) If you want to fully decouple from the default seed list, run --add-priority-node= :10101 (see Fastsync vs --add-priority-node above) and you never have to talk to a seed node again. --- --remote is convenience, not sovereignty The wallet CLI accepts a --remote flag that connects to a public DERO Foundation node instead of your own daemon: It works — and for read-only operations or quick balance checks it's fine. What you give up is the self-sovereignty premise of the rest of this page: with --remote, you're trusting one party's view of the chain. They could censor your transactions, lie about your balance, or correlate every query you make. For anything that matters — large balances, smart-contract operations, payment processing, anything you'd describe as \"real\" — point your wallet at your own daemon: This is the whole point of running a node. --- 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"
     },
     {
@@ -215,6 +231,7 @@
         "Privacy Features",
         "Rug-Pull Resistance",
         "Why DERO Tokens Are Safer",
+        "Captain on the wallet-native model",
         "Token Types",
         "Fungible Tokens",
         "Non-Fungible Tokens (NFTs)",
@@ -226,7 +243,7 @@
         "Learn More",
         "Related Pages"
       ],
-      "plainText": "DERO Tokens Tokens Tokens on DERO are user-created assets deployed through smart contracts. What makes DERO unique is that tokens are stored as **encrypted balances in user wallets**, not in the smart contract itself - providing privacy and rug-pull resistance. --- How DERO Tokens Are Different | Aspect | ERC-20 (Ethereum) | DERO Tokens | |--------|------------------|-------------| | **Storage** | In smart contract | In user wallets | | **Balance Privacy** | 👁️ Public | 🔒 Encrypted (66 bytes) | | **Transfers** | Through contract | Wallet-to-wallet (like DERO) | | **Contract Control** | Can freeze/lock | ❌ Cannot control after issuance | | **Rug-Pull Risk** | ⚠️ High | ✅ Resistant | | **Privacy** | ❌ None | ✅ Ring sigs + encryption | --- Token Storage Model Traditional Tokens (ERC-20) **Problem:** Contract controls everything. Owner can freeze, steal, or manipulate. DERO Tokens **Result in wallet:** **Source:** cryptography/crypto/algebra_elgamal.go:91-93, cryptography/crypto/balance_serdes.go:31 --- Privacy Features **Token transfers use DERO's full privacy stack:** 1. **Ring Signatures** - Sender hidden among ring_size/2 potential senders (rings split evenly) 2. **Homomorphic Encryption** - Amounts encrypted 3. **Bulletproofs** - Zero-knowledge validation 4. **TLS Network** - Encrypted transmission **Verified in source:** - Balance storage: blockchain/transaction_execute.go:239 - nb.Balance.Add(echanges) (homomorphic) - Token sending: dvm/dvm_functions.go:80 - SEND_ASSET_TO_ADDRESS implementation - Wallet updates: dvm/simulator.go:378 - nb.Balance.Plus() for tokens --- Rug-Pull Resistance Why DERO Tokens Are Safer **Ethereum ERC-20:** **DERO Tokens:** **The \"Cash Model\":** - Bank (contract) issues cash (tokens) - Cash leaves bank → in your wallet (encrypted) - Bank can't track or control it anymore - You can spend it peer-to-peer --- Token Types Fungible Tokens **Example:** Stablecoins, utility tokens, governance tokens **Each token is identical and interchangeable** Non-Fungible Tokens (NFTs) **Example:** Collectibles, game items, unique assets **Each token has unique ID, quantity = 1** --- Using DERO Tokens Receiving Tokens Tokens arrive in your wallet automatically via SEND_ASSET_TO_ADDRESS(): Sending Tokens Transfer like native DERO: **Privacy features:** - Ring signature hides sender - Amount encrypted - Balance stays encrypted --- Key Advantages **1. Wallet Storage = True Ownership** - ✅ You control private keys - ✅ Contract cannot take back - ✅ No freeze functions possible **2. Privacy = Full Encryption** - ✅ Balances encrypted (E(amount)) - ✅ Transfers use ring signatures - ✅ Cannot track ownership **3. Peer-to-Peer Transfers** - ✅ Send without contract involvement - ✅ Like sending DERO - ✅ Fast and private **4. Multiple Assets Per Wallet** - ✅ DERO + unlimited tokens - ✅ Each encrypted separately - ✅ All in one wallet --- Learn More - Private Smart Contracts - How token privacy works - Homomorphic Encryption - Why balances stay encrypted - DVM Smart Contracts - Building token contracts **Source Code References:** - Token implementation: dvm/dvm_functions.go:398 - SEND_ASSET_TO_ADDRESS - Wallet storage: cryptography/crypto/balance_serdes.go:31 - Balance *ElGamal - Homomorphic updates: blockchain/transaction_execute.go:239 - nb.Balance.Add(echanges) --- Related Pages **Understand Token Privacy:** - Homomorphic Encryption - How encrypted balances work - Ring Signatures - Transaction privacy layer - Private Smart Contracts - Token contract privacy **Build with Tokens:** - Token Smart Contract - Full token implementation example - Assets Exchange - Build a token swap contract - DVM-BASIC Guide - Smart contract programming language **Deploy & Use:** - Wallet RPC API - Send and receive tokens - DERO Wallets - Wallet options for managing tokens",
+      "plainText": "DERO Tokens Tokens Tokens on DERO are user-created assets deployed through smart contracts. What makes DERO unique is that tokens are stored as **encrypted balances in user wallets**, not in the smart contract itself - providing privacy and rug-pull resistance. --- How DERO Tokens Are Different | Aspect | ERC-20 (Ethereum) | DERO Tokens | |--------|------------------|-------------| | **Storage** | In smart contract | In user wallets | | **Balance Privacy** | 👁️ Public | 🔒 Encrypted (66 bytes) | | **Transfers** | Through contract | Wallet-to-wallet (like DERO) | | **Contract Control** | Can freeze/lock | ❌ Cannot control after issuance | | **Rug-Pull Risk** | ⚠️ High | ✅ Resistant | | **Privacy** | ❌ None | ✅ Ring sigs + encryption | --- Token Storage Model Traditional Tokens (ERC-20) **Problem:** Contract controls everything. Owner can freeze, steal, or manipulate. DERO Tokens **Result in wallet:** **Source:** cryptography/crypto/algebra_elgamal.go:91-93, cryptography/crypto/balance_serdes.go:31 --- Privacy Features **Token transfers use DERO's full privacy stack:** 1. **Ring Signatures** - Sender hidden among ring_size/2 potential senders (rings split evenly) 2. **Homomorphic Encryption** - Amounts encrypted 3. **Bulletproofs** - Zero-knowledge validation 4. **TLS Network** - Encrypted transmission **Verified in source:** - Balance storage: blockchain/transaction_execute.go:239 - nb.Balance.Add(echanges) (homomorphic) - Token sending: dvm/dvm_functions.go:80 - SEND_ASSET_TO_ADDRESS implementation - Wallet updates: dvm/simulator.go:378 - nb.Balance.Plus() for tokens --- Rug-Pull Resistance Why DERO Tokens Are Safer **Ethereum ERC-20:** **DERO Tokens:** **The \"Cash Model\":** - Bank (contract) issues cash (tokens) - Cash leaves bank → in your wallet (encrypted) - Bank can't track or control it anymore - You can spend it peer-to-peer Captain on the wallet-native model Captain summarized the same model in chat — native assets, wallet-custodied, contract-independent: > Yes, On DERO network assets/tokens etc. are native unlike ETH/other tokens. Assets/tokens once issued on DERO network are owned by DERO wallet NOT by issuing Smart Contract. Even if you update/delete/blacklist Smart Contract your assets won't be affected in any way on DERO NW & they will move freely as ever. > > — Captain, 2022-11-16, #random (https://discord.com/channels/419781880632836096/420040002878308352/1042285299713191987) The SC defines what an asset *is* (its SCID is the asset's identity); it does not custody the balances. --- Token Types Fungible Tokens **Example:** Stablecoins, utility tokens, governance tokens **Each token is identical and interchangeable** Non-Fungible Tokens (NFTs) **Example:** Collectibles, game items, unique assets **Each token has unique ID, quantity = 1** --- Using DERO Tokens Receiving Tokens Tokens arrive in your wallet automatically via SEND_ASSET_TO_ADDRESS(): Sending Tokens Transfer like native DERO: **Privacy features:** - Ring signature hides sender - Amount encrypted - Balance stays encrypted --- Key Advantages **1. Wallet Storage = True Ownership** - ✅ You control private keys - ✅ Contract cannot take back - ✅ No freeze functions possible **2. Privacy = Full Encryption** - ✅ Balances encrypted (E(amount)) - ✅ Transfers use ring signatures - ✅ Cannot track ownership **3. Peer-to-Peer Transfers** - ✅ Send without contract involvement - ✅ Like sending DERO - ✅ Fast and private **4. Multiple Assets Per Wallet** - ✅ DERO + unlimited tokens - ✅ Each encrypted separately - ✅ All in one wallet --- Learn More - Private Smart Contracts - How token privacy works - Homomorphic Encryption - Why balances stay encrypted - DVM Smart Contracts - Building token contracts **Source Code References:** - Token implementation: dvm/dvm_functions.go:398 - SEND_ASSET_TO_ADDRESS - Wallet storage: cryptography/crypto/balance_serdes.go:31 - Balance *ElGamal - Homomorphic updates: blockchain/transaction_execute.go:239 - nb.Balance.Add(echanges) --- Related Pages **Understand Token Privacy:** - Homomorphic Encryption - How encrypted balances work - Ring Signatures - Transaction privacy layer - Private Smart Contracts - Token contract privacy **Build with Tokens:** - Token Smart Contract - Full token implementation example - Assets Exchange - Build a token swap contract - DVM-BASIC Guide - Smart contract programming language **Deploy & Use:** - Wallet RPC API - Send and receive tokens - DERO Wallets - Wallet options for managing tokens",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -249,6 +266,107 @@
       "plainText": "What is a wallet? What is a wallet A cryptocurrency wallet is a digital tool or software application that allows users to securely store, manage, and interact with their cryptocurrencies. It serves as a virtual wallet for storing private keys, which are essential for accessing and controlling the user's cryptocurrency holdings on the blockchain. Many cryptocurrency wallets, including Dero's, employ seed phrases—a sequence of random dictionary words. These seed phrases enable the regeneration of a lost private key, underscoring their crucial role in wallet security. It is strongly advised to diligently record and store your seed phrase. Dero adopts a 25-word seed phrase, displayed during wallet creation and accessible for printing at any time within the wallet interface. Download here: https://github.com/deroproject/derohe/releases Dero Wallet Options CLI (Command Line Interface) Wallet The CLI wallet, the fundamental and official wallet, resides here within the official Dero suite of software. Offering all necessary functions, starting with this wallet is recommended. Usage: To utilize the CLI wallet, execute the binary file via the command line or terminal. The process might slightly differ based on your operating system. Nevertheless, navigate to the folder containing the executable and run it accordingly: - Linux: ./dero-wallet-cli-linux-amd64 - Windows: dero-wallet-cli-windows-amd64.exe - Mac (Intel): ./dero-wallet-cli-darwin-amd64 - Mac (Apple Silicon): ./dero-wallet-cli-darwin-arm64 ENGRAM (Graphical) Wallet Engram is DERO's official desktop wallet application - a privacy-focused gateway to decentralized applications (dApps) on the DERO blockchain. It provides a secure, sandboxed environment for browsing dApps whose code and data reside entirely on-chain through smart contracts. **Key Features:** - 🖥️ Desktop wallet with full GUI - 🔒 Privacy-focused browsing for blockchain dApps - ⛏️ Built-in miner (Netrunner) - 🔐 dApp authentication system (Cyberdeck) - 💬 Encrypted messaging - 🌐 Gateway to TELA platform **Learn More:** - Engram Introduction - What is Engram? - Engram Features - Full feature list - User Guide - Getting started - Wallet Integration - Build for Engram **Download:** GitHub Releases Cold Wallet (Offline Storage) Cold storage refers to keeping your private keys and wallet on an offline, air-gapped computer for maximum security. However, **DERO's account-based model makes cold storage different** from traditional cryptocurrencies. **Important:** DERO Stargate (current version) uses an **account-based model** that requires **wallet registration** on the blockchain. This makes fully offline cold storage more complex than UTXO-based coins. How DERO Cold Storage Works **The Challenge:** - Traditional cold wallets (Bitcoin, Monero) can be created and funded completely offline - DERO wallets **must register** on-chain before they can receive funds - Registration requires a one-time network connection **Current Cold Storage Process:** 1. **Create Wallet Offline** (Air-gapped computer) 2. **Get Wallet Address** - Note your wallet address (starts with dero1...) - Write down seed phrase on paper (NOT on USB) - Save address to USB drive (safe to copy - it's public) 3. **Register Wallet** (Requires network connection) - Option A: Send DERO to the address from another wallet (auto-registers) - Option B: Temporarily connect the air-gapped wallet to register it - After registration, wallet can receive funds 4. **Return to Cold Storage** - Disconnect from network - Keep seed phrase offline and secure - Only connect when you need to send funds **View-Only Wallet:** Best Practices for Secure Storage **Security Checklist:** - ✅ Write seed phrase on paper (NEVER digital) - ✅ Store in multiple secure locations (safe, bank vault) - ✅ Use encrypted storage for wallet files - ✅ Never expose seed to internet-connected devices - ✅ Test recovery process with small amounts first - ✅ Use strong passwords for wallet encryption Related Pages **Get Started:** - DERO Tokens - Understanding tokens and assets - DERO Mining - Mine DERO to your wallet - Running a Node - Run your own node **Privacy Features:** - Transaction Privacy - How wallet privacy works - Homomorphic Encryption - Encrypted balances - Payload Proofs - Prove your transactions **For Developers:** - Wallet RPC API - Automate wallet operations - Smart Contracts - Deploy and interact with contracts",
       "lastUpdated": "2025-10-19"
     },
+    {
+      "product": "derod",
+      "slug": "captain",
+      "title": "Captain Archive: DERO in His Own Words | DERO Blockchain",
+      "description": "Primary-source archive of Captain's statements on DERO's design — homomorphic encryption, DVM-BASIC, consensus, governance, and protocol integrity. Sourced directly from Discord and Bitcointalk.",
+      "canonicalUrl": "https://derod.org/captain.md",
+      "sourcePath": "derod-main/pages/captain.mdx",
+      "headings": [
+        "Captain Archive: DERO in His Own Words",
+        "Origins: Founding Doctrine (2017-2018)",
+        "The Original ANN Thesis",
+        "Status Report: 44 Days Into the Go Rewrite",
+        "Engineering Self-Description: Bulletproofs, Batched and Optimized",
+        "Absorbing the ASIC Invasion as a Free Stress Test",
+        "What the Privacy Layer Was Actually For",
+        "Why DERO exists — the 2023 retrospective",
+        "Protocol Design Decisions",
+        "Why the daemon doesn't ship HTTPS",
+        "DAG propagation, uncles, and where conflict rules live",
+        "Resource exhaustion is not a bug to patch",
+        "Privacy & Homomorphic Encryption",
+        "Homomorphic encryption replaces the entire obfuscation stack",
+        "Even the wallet has to compute to know its own balance",
+        "No master key, and only 66 bytes from the network to open a wallet",
+        "The account model is itself a privacy feature",
+        "DHEBP: building on Zether, then past it",
+        "What \"double-spend\" even means without outputs",
+        "Same homomorphic guarantees for every native asset",
+        "DVM, Smart Contracts, and DVM-BASIC",
+        "GOTO is the building block, not a smell",
+        "The DVM-BASIC language contract",
+        "Funds sent to a contract are burned, not deposited",
+        "Ordering guarantees inside a block",
+        "Keep search off-chain",
+        "Some features are missing on purpose",
+        "Consensus, DAG Ordering & Mining Policy",
+        "Reading the daemon prompt: chain height, topo height, and side blocks",
+        "Stargate-95: the AstroBWT v3 hard fork",
+        "Why the algorithm keeps moving",
+        "Governance & Community Contributions",
+        "The two-branch model for community contributions",
+        "Protocol Integrity: Captain in His Own Words",
+        "No Dev Tax — 100% to Miners, 8% on Side Blocks as a Time-Sync Incentive",
+        "Philosophy & Inspirational Quotes",
+        "We choose the hard way",
+        "Not an ICO. A community project.",
+        "Why DERO, in plain language",
+        "A blockchain that affects society",
+        "No permission needed, no mercy asked",
+        "Not anti-anyone. Pro-users.",
+        "No optional privacy",
+        "On false privacy and VCs",
+        "Privacy as a requirement",
+        "Core devs will never be part of some centralized thing",
+        "Quantum Resistance & DERO-QR",
+        "State tracking with crypto-backed proofs",
+        "Opening posture: not a big deal",
+        "Threat surface: hacker's garage, IBM, Intel",
+        "DERO-QR on the current network",
+        "Enigma-cracking: you won't know until you do",
+        "GravitonDB is a complete project in itself",
+        "Current & Coming Times: What Ships vs What's Ready",
+        "Downgrades for current times and weak machines",
+        "Designed from scratch, because the field stalled",
+        "AI making private transactions",
+        "Decades of experience for current & coming times",
+        "Stargate is the explainable version",
+        "Why his heart still doesn't allow SC interactions",
+        "Blackbox DERO: The Long-Term Vision",
+        "HE scope is intentionally limited \"for now\"",
+        "Everything floating in DERO-sea is encrypted",
+        "CryptoNote is outdated for DERO",
+        "Obfuscation out, HE in, plaintext never",
+        "\"Most of these projects will be seen running on DERO network\"",
+        "Entirely blackbox DERO",
+        "Broadcasts & Slogans",
+        "Not your keys, not your coins",
+        "Actual decentralized blockchain",
+        "Mine on your own node",
+        "No heroes, only community",
+        "Run your own node",
+        "Biographical Notes",
+        "Nature, discipline, values",
+        "The teacher called Experience",
+        "Environment and society",
+        "Traveling, meeting friends",
+        "First specialized compilers, two decades back",
+        "Exchange listings, time, and money lost",
+        "The Trail: Cryptic Clues and Last Words",
+        "Tomorrow never comes (Christmas 2017)",
+        "Third person — 'captain's msgs'",
+        "Rest & peace only",
+        "Higher level of peace",
+        "Coming times",
+        "Down forever",
+        "Severely disconnected",
+        "Bless you all"
+      ],
+      "plainText": "Captain Archive: DERO in His Own Words *Captain (CaptDero / captain030317) on Discord and Bitcointalk, 2017–2024. Pre-2022 quotes predate the DERO-HE architectural transition.* --- Origins: Founding Doctrine (2017-2018) DERO's first public year on Bitcointalk reads like a project manifesto being written in real time. Between late 2017 and mid-2018, Captain (posting as CaptDero) laid out the original thesis — a CryptoNote-derived chain rewritten from scratch in Go, with bulletproofs, TLS across the P2P layer, and a DAG that swallowed reorgs instead of orphaning them — and made the strategic calls that shaped the project's early identity: refusing to emergency-fork away an ASIC invasion, and pivoting from the original Cryptonote codebase to the \"DERO Atlantis\" network. These posts predate every architectural milestone DERO is known for today. Smart contracts were still on the roadmap. Homomorphic encryption (DERO-HE) was four years away. Ring signatures, mixins, and the CryptoNote heritage described here were retired in the 2022 migration. Read this section as founding-era doctrine — the engineering posture and design instincts that survived, even after the substrate they were built on did not. The Original ANN Thesis The Bitcointalk announcement thread is the closest thing to a founding charter. Captain frames DERO as the first chain to combine a specific stack of primitives, and commits the project to a 2018 roadmap. Bitcointalk ANN OPs are edited in place over time — the version quoted here reflects the consolidated thread as it stood by mid-2018 (the same post contains a 'Full Premine intact as of 12 July 2018' line and references the post-April Atlantis network), not the verbatim December 2017 first post. > The Dero Project has written a unique new blockchain technology that is based on the Dag and CryptoNote protocol with double spend protection. Dero's goal is to create a unique state of the art blockchain technology with enhanced reliability, privacy, security, usability, and portability by bringing together some of the best proven technologies like the CryptoNote protocol and smart contracts, thereby allowing for the creation of truly private smart contracts. The Dero development team has implemented complete SSL across the Dero network which is a first on any blockchain. [...] First blockchain to have: DeroDAG + Cryptonote + Bulletproofs + Complete SSL + POW. Blocktime 12 secs + Confirmation times 2 mins. Traditional 51% attacks are not possible on DERO network. Dero is one of the very few blockchains built from scratch [...] DERO blockchain has the following salient features: - DAG Based: No orphan blocks, No soft-forks. - 12 Second Block time. - Extremely fast transactions with 2 minutes confirmation time. - SSL/TLS P2P Network. - CryptoNote: Fully Encrypted Blockchain - BulletProofs: Zero Knowledge range-proofs (NIZK). - Ring signatures. - Fully Auditable Supply. - DERO blockchain is written from scratch in Golang. > > — CaptDero, 2017-12-05 → mid-2018, Bitcointalk [ANN] thread OP Two design commitments here outlived everything else in the post: the from-scratch Go rewrite, and the insistence on auditable supply. The CryptoNote substrate, ring signatures, and the 12-second block time were all replaced in the DERO-HE migration (2022), which moved DERO to homomorphic encryption with an 18-second block time. The roadmap dates in the original post are obviously historical. Status Report: 44 Days Into the Go Rewrite Six weeks after the announcement, Captain posted a component-by-component status update on the from-scratch Go daemon — wire protocol, consensus, the ringct primitives, BoltDB. Read it as a checklist of what \"built from scratch\" actually meant in practice. > In the status update release 1, Following parts of cryptonote has been rewritten in golang. At present, Golang DERO daemon can sync and verify blockchain with the existing DERO network. [...] **Cryptonight Hash:** This is an ASIC resistant, memory-bound algorithm. [...] **Wire protocol (90% completed):** This protocol is used to exchange data between 2 DERO daemon nodes. At this point, Go daemon can connect to C daemon and vice-versa, sync blockchain and exchange, already possible. Complete interoperability has been achieved. [...] **Pederson Commitment** (Part of ring confidential transactions): [...] a cryptographic primitive that allows user to commit to a chosen value while keeping it hidden to others. [...] **Borromean Signature** (Part of ring confidential transactions): Borromean Signatures are used to prove that the commitment has a specific value, without revealing the value itself. **Additive Homomorphic Encryption:** [...] used to prove that sum of encrypted Input transaction amounts is EQUAL to sum of encrypted output amounts. [...] **MLSAG** (Work-in-Progress): MLSAG gives DERO untraceability and increases privacy and fungibility. [...] **BOLT Database:** DERO Blockchain uses BoltDB for future scalability and low latency reads. > > — CaptDero, 2018-01-18, Bitcointalk DERO thread Engineering Self-Description: Bulletproofs, Batched and Optimized Inviting the community to audit the source, Captain attached a self-description of the bulletproofs work. It is one of the rare moments where the project's engineering posture — measure, optimize, batch, attribute — is laid out in his own voice. > Secure and fast crypto is the basic necessity of this project and adequate amount of time has been devoted to develop/study/implement/audit it. [...] As far as the Bulletproofs are considered, since DERO is the first one to implement/deploy, they have been given a more detailed look. First, a bare bones bulletproofs was implemented, then implementations in development were studied (Benedict Bunz, XMR, Dalek Bulletproofs) and thus improving our own implementation. Some new improvements were discovered and implemented [...]. Major improvements are in the Double-Base Double-Scalar Multiplication while validating bulletproofs. A typical bulletproof takes ~15-17 ms to verify. Optimized bulletproofs takes ~1 to ~2 ms (simple bulletproof, no aggregate/batching). Since, in the case of bulletproofs the bases are fixed, we can use precompute table to convert 64*2 Base Scalar multiplication into doublings and additions (NOTE: We do not use Bos-Coster/Pippienger methods). This time can be again easily decreased to .5 ms with some more optimizations. With batching and aggregation, 5000 range-proofs (~2500 TX) can be easily verified on even a laptop. The implementation for bulletproofs is in github.com/deroproject/derosuite/crypto/ringct/bulletproof.go, optimized version is in github.com/deroproject/derosuite/crypto/ringct/bulletproof_ultrafast.go. > > — CaptDero, 2018-07-21, Bitcointalk source-review invitation Absorbing the ASIC Invasion as a Free Stress Test When ASICs landed on the early DERO network, the obvious response was to fork the algorithm immediately. Captain made the opposite call: treat the attack as a load test, ship the next milestone on schedule, and announce a pivot to \"DERO Atlantis\" instead of a panic patch. > Thanks [Speedie] for your time and efforts for understanding and explaining the same. Everyone was more than happy and satisfied with Golang Alpha release and no one would have ever required/asked for more than what was already being offered. Everything was moving ahead of schedule and smooth. But we decided to go for **DERO Atlantis** as we can see clearly the journey ahead. > > — CaptDero, 2018-04-22, Bitcointalk DERO ANN thread (https://bitcointalk.org/index.php?topic=2525508.msg35314263#msg35314263) What the Privacy Layer Was Actually For Replying to a community essay (by the user *fellestreum*) that articulated DERO's privacy thesis better than any whitepaper line, Captain endorsed it openly. This is one of the few places where the project's social purpose — not the engineering — gets stated in his voice. > This post deserves much more than thank you and sMerit. thank you [fellestreum]. You have expressed the IDEA behind Dero. We hope to create a Blockchain which will affect the entire society from increasing the privacy to daily utilities. Users will have confidence that no copy/access of his data exists on the shops/counters/merchants/agents he has visited since start of the day. He lives a private life and he knows who has access/copy of his data. This is a very big and huge impacting topic. In parallel to technological development of DERO Blockchain we are also working for practical life example to express the DERO concept. > > — CaptDero, 2018-02-19, Bitcointalk DERO thread (https://bitcointalk.org/index.php?topic=2525508.msg30585516#msg30585516) Why DERO exists — the 2023 retrospective This one quote breaks the section's 2017-2018 framing on purpose. In April 2023, with five years of DERO development behind him and the founding thesis having played out across the Atlantis-to-Stargate migration, Captain compressed the original *why* into two numbered bullets — a retrospective restatement that maps cleanly onto the ANN OP at the top of this section. It is included here because it answers the same question the 2017 thread opened with, in 2023's vocabulary. > DERO was designed due to short comings of Bitcoin, particularly: 1] Bitcoin has no privacy, missing non-fungibility & no ability to hide/protect it's senders & receivers from public records. 2] Lack of programmability(Smart Contracts). Also it was impossible to push privacy feature in BTC code due to lack of interest in core DEVS with respect to privacy. > > — captain030317, 2023-04-15, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1096719975370194984) The two-point indictment is straightforward — privacy and programmability are the gaps the project was built to fill. The third sentence is the one worth pausing on: it is Captain saying, in plain language, that he did not believe privacy could ever be added *upstream* of where DERO already sat. The implication is not that Bitcoin is the wrong tool for some users; the implication is that the people maintaining Bitcoin would not accept the change DERO is, so the change had to ship as a separate chain. --- Protocol Design Decisions The three quotes in this section come from different years (2018, 2022, 2023) but share a single posture: when a feature feels obviously missing — HTTPS on the daemon, a chain-side search API, looser query limits — the answer is usually that the absence is the design, not the omission. Each post argues from the threat model down, not from convenience up. Why the daemon doesn't ship HTTPS A recurring request from newcomers was that the daemon JSON-RPC should be served over HTTPS. Captain's standing reply, posted in #technical-questions in late 2022, treats HTTPS as a misplaced trust anchor rather than a security upgrade. > https is not supported intentionally. HTTPS gives false sense of security as certificate issuer has the private key to decrypt the traffic. And issuer can share the private-keys to others also when required. https can only help with local ISP/telecom sniffing, In that case use vpn etc.. > > — Captain, 2022-12-21, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/1054919216400175104) The argument is the CA-trust critique: a CA-issued certificate gives the issuer (and anyone they hand the key to) the ability to decrypt the traffic. For an RPC endpoint that you should already trust at the wire level — your own daemon, on your own machine, behind your own VPN — HTTPS adds an additional trusted party rather than removing one. DAG propagation, uncles, and where conflict rules live In the project's first year, a deep-dive Q&A in #technical-questions walked through six questions about DERO's then-architecture. Three of Captain's answers are still operative today: where conflict resolution lives (the client protocol, not the consensus rule), how side blocks count, and an honest admission about the proof-of-work search. > Ans 2: Dero DAG like other chains requires block propgation time to propgate blocks. Block propgation times AVGs 99.99% ~15 seconds. Ans 3: By client protocol. Ans 4: 2 uncles (Dero side blocks if you are referring to them only) are allowed depending on NW. Ans 5: RingCT is core part of Dero architecture. Ans 6: We are still searching better algo than POW. > > — Captain, 2018-09-11, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/489052835573399563) \"Ans 5\" is the time-locked line — RingCT was the privacy primitive of pre-2022 DERO and was retired in the DERO-HE migration. \"Ans 3\" and \"Ans 4\" are still load-bearing: conflict resolution lives in the client protocol layer, and DERO still treats side blocks as first-class citizens (not orphans) up to a network-determined cap. Resource exhaustion is not a bug to patch When the Bitcoin Ordinals surge stressed node operators in early 2023, the question came up in #dero-discussion: shouldn't DERO just raise its limits so clients can request larger ranges of chain data? Captain's answer reframed the request as a category error. > As with the Bitcoin Network issue recently in news if you will ask entire chain of data then nodes are being going to be overloaded eventually. There is no good fix to solve this permanently. We can increase the RAM/resources limit however keep in mind they are finite & can be consumed by asking for more & more data to consume the increased resources. It is like just asking the webserver to serve more users beyond capacity. > > — Captain, 2023-05-09, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1105507901331742840) Captain treats unbounded query limits as the bug, not the limit itself. Any resource ceiling is a moving target as long as the network is willing to fulfill arbitrary-size requests — the only stable answer is to bound what clients can ask for in the first place. This is the same philosophy that lives in DERO's current --mine-block-uncle-limit, --p2p-tx-batch, and similar knobs: hard ceilings rather than dynamic scaling. --- Privacy & Homomorphic Encryption The defining bet behind DERO-HE is that privacy should not be a layer of obfuscation bolted onto a transparent ledger, but a property of the cryptography itself. Across late 2021 and 2022 — spanning the testnet rollout of the new account-model chain and the year that followed mainnet migration — Captain returned again and again to the same point: balances and transfers live as ElGamal ciphertexts, every operation runs over encrypted data, and there is no master key, view key, or audit hatch that lets anyone other than the seed-holder read an account. The quotes below trace that thesis from its highest-level statement down to the specific mechanics: why the account model is itself a privacy feature, what the wallet actually does when it opens, how DHEBP nonces prevent double-spends without outputs to track, and how the same homomorphic guarantees extend to every native asset on the chain. Homomorphic encryption replaces the entire obfuscation stack Two weeks before the DERO-HE mainnet upgrade, Captain spelled out the thesis in a single paragraph: nothing on the chain is ever observable in plaintext, not even briefly. > Yes absolutely. HE encryption replacing all obfuscation stack completely. No more obfuscations on DERO network now. No one will be able to see/confirm your data on DERO blockchain without your seed/wallet. All operations will be on encrypted data only. So no requirement/gimmick to ask for your data to be in decrypted state ever. Not even once your data will ever be in decrypted state. > > — Captain, 2021-10-20, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/900312094157705217) This is the cleanest one-paragraph statement of the DERO-HE design goal. \"Obfuscation stack\" is the ring-signatures / stealth-addresses / view-keys approach used by Monero-family chains; Captain's claim is that HE makes that whole apparatus unnecessary because the ciphertexts themselves are the privacy boundary. Even the wallet has to compute to know its own balance In a #dapps thread comparing DERO to public-ledger smart-contract platforms, Captain pushed back on the comparison by pointing at what \"private balance\" actually costs the wallet itself. > There is no point in comparing DERO with ADA/ETH as DERO balances are private unlike public blockchains. There is no way in DERO you can know any other account balances. DERO-wallet has to run lots of computations to know it's own balance. So basically there is no way you can know balances of other DERO wallets. There would be no point of DERO privacy if thats possible. > > — Captain, 2022-05-12, #dapps (https://discord.com/channels/419781880632836096/947922694387679262/974347052794384464) The line \"DERO-wallet has to run lots of computations to know it's own balance\" is the tell. The wallet receives an encrypted balance and has to decrypt it locally using the spend key — there is no plaintext figure cached anywhere on the network to read. If the wallet could shortcut that, so could everyone else. No master key, and only 66 bytes from the network to open a wallet Responding to a recurring \"who holds the keys\" question in #dero-discussion, Captain laid out what a wallet actually needs from the chain to function. > There is no concept of any master private/secret key on DERO. DERO creates a elgamal balance ciphertext associated to any wallet-account. The private key is NOT broken or distributed among other nodes in any way or form. When user opens wallet, no communication with DERO network except 66 bytes are required. This process is completely done within wallet and is not linked with DERO network. As DERO is account model, Only 66 bytes are required by wallet from DERO blockchain to operate. Blocks & transactions are required to create & maintain history on DERO network. > > — Captain, 2022-12-08, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1050433141875155064) Captain does not spell out what the 66 bytes are in this message — only that the wallet needs that much from the chain, and nothing else, to operate. The size is consistent with an ElGamal balance ciphertext (two compressed curve points), but treat that as inference rather than Captain's claim. The structural point stands either way: full blocks and transactions exist to maintain network history, not to make a wallet functional. The account model is itself a privacy feature A few months after mainnet, Captain framed the account-vs-UTXO choice as a privacy decision, not just an engineering one. > Another privacy enhancing part of DERO is it's account model. You can drop the entire transactions logs anytime from DERO database like(--fastsync) & DERO will still work unlike Monero which requires scanning/tracking/recording of key-images from first transaction. After dropping you will never abile to do any statistical analysis as there will be no such data. > > — Captain, 2022-08-29, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1013849719073681468) Because state lives in account ciphertexts rather than a forever-growing set of unspent outputs and key-images, history is disposable from a node's point of view. A pruned node can still validate and transact; anyone hoping to do retroactive chain analysis on the dropped data simply has nothing to analyze. DHEBP: building on Zether, then past it During the DERO-HE testnet, the contributor vanitas was reading the transaction-build code and asking how proofs bind to height. Captain confirmed the mechanism and named the protocol. > [vanitas asked, paraphrased: u and u1 in transaction_build.go appear to be curve points tied to height and a sender secret; u1 also includes block batch size. How is this used to prevent double-spends, and how does it interact with the DAG?] Yes, u and u1 are set to a curve point represent height at which TX was build. Height is mentioned in the TX. This value is calculated at run-time by blockchain to verify the the claim by the TX originator. DHEBP protocol and design is an improvement over zether/anonymous zether. > > — Captain, 2021-10-04, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/894611662303293541) DHEBP — DERO Homomorphic Encryption Blockchain Protocol — is the in-house protocol that ships in DERO-HE. Captain situates it as a descendant of Bunz et al.'s Zether and Anonymous Zether work. The u/u1 curve points bind each transaction to the height it was built at, and the chain recomputes the expected value at verification time to confirm the originator's claim. What \"double-spend\" even means without outputs vanitas followed up with the right structural question: in an account model with no UTXOs, what does double-spend prevention actually look like? Captain answered with the bank analogy. > [vanitas asked, paraphrased: if the nonce ties to height plus a secret, can the same tx repeat at a different height with a different nonce? Or is the question moot under an account model — and what is a double-spend attack when there are no outputs to double-spend?] Nonce prevents not only the same TX but also any other TX from the same secret owner at the same time. In DHEBP basically TX is just an entry with deductions and additions. Nonces are used to prevent duplicate and/or double spend attacks. In simple terms, Assume that DERO blockchain acts as bank to which users submit TXs and the DERO blockchain filters out invalid/incorrect/stale TXs and processes only valid TXs that too one at a time. > > — Captain, 2021-10-04, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/894612571863265400) The mental model is double-entry bookkeeping under encryption: a transaction is a deduction-plus-addition pair, and the height-bound nonce ensures only one transaction per account can be admitted per slot. There is nothing to \"spend twice\" because there are no outputs — just an account ciphertext that the chain refuses to mutate more than once at a time. Same homomorphic guarantees for every native asset Earlier in the same testnet conversation, vanitas noticed that Payloads[0] looked special and wondered if it represented the native DERO asset. Captain confirmed and generalized. > [vanitas observed: Payloads[0] is referenced in multiple places — possibly the native DERO asset, or something about the tx itself; the payloads appear to map to specific SC assets.] DERO supports multiple (~ 2 ^ 256 ) native assets. DERO itself is a native asset with SCID \"000000..000000\". However, most users will use the native DERO asset. Also all assets are backed by the same homomorphic guarantees and cryptography.. Eg. We need to write DERO if we are using native \"DERO\" asset, For others we need to write \"TOKEN\" etc. > > — Captain, 2021-10-04, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/894610789292445697) Worth holding onto: any token issued on DERO inherits the same encrypted-balance semantics as DERO itself. There is no \"transparent token\" tier — every native asset, identified by its 256-bit SCID, ships with the same ElGamal/HE protection. The zero SCID is just the convention for the base asset. --- DVM, Smart Contracts, and DVM-BASIC The DERO Virtual Machine has always been a deliberately small target. Where most smart-contract platforms ship a sprawling instruction set and let developers reach for whatever abstraction feels natural, Captain stripped DVM-BASIC down to a handful of types, a single jump primitive, and a tight contract for how calls land in a block. The quotes below — drawn mostly from 2019 through 2022, spanning the original mainnet contract experiments and the DERO-HE testnet that became Stargate — lay out the reasoning behind those constraints. Read them as a worldview rather than a feature list: GOTO is enough because everything compiles to it anyway, fund movement into a contract is a burn rather than a transfer, search belongs on your node and not on consensus, and ordering inside a block is a guarantee the protocol owes you. The language reference in the middle is the closest thing to an official DVM-BASIC spec Captain published in chat. GOTO is the building block, not a smell DVM-BASIC ships with GOTO and no for, while, or switch. Newcomers regularly read this as a missing feature. Captain's standing reply is that the criticism mistakes a high-level convenience for a primitive. > GOTO is basic building block of any computing CHIP atm. if you cannot see it directly it doesn't mean it doesn't exists. Every switch-case, break, loop etc. all are implemented in form of GOTO. Rest all is propganda. > > — Captain, 2019-12-22, #mainnet (https://discord.com/channels/419781880632836096/530654307624943616/658142960910598185) The design choice is enduring: every DVM-BASIC contract written today still expresses loops and branches as labeled GOTO targets, and the verifier benefits from the smaller surface. If the absence of for loops feels wrong, the lesson is to write the jump explicitly rather than wait for sugar that is not coming. The DVM-BASIC language contract During the DERO-HE testnet, Captain posted what amounts to a one-screen language reference for DVM-BASIC, pointing at the in-repo guide on GitHub at the time. > https://github.com/deroproject/derohe/tree/main/guide#dvm-interprets-the-smart-contract-and-processes-the-sc-line-line > > — Captain, 2021-02-24, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/814071165869621248) The behavior described here still holds on Stargate: two types (Uint64 and String), mandatory declaration with zero/empty defaults, line-by-line interpretation, and the rule that a non-zero return — or any panic — rolls back every state change in the call. The derohe/guide path Captain linked in 2021 no longer resolves; the equivalent material today lives in the dvm/ package source and in the DVM-BASIC reference on the dero-docs site. Funds sent to a contract are burned, not deposited A recurring point of confusion on the DERO-HE testnet was what it means to \"send DERO to a smart contract.\" Captain reframed the mental model away from the EVM-style deposit. > It's more of burning than deposit or transfer because when you transfer some DERO from any wallet to SC this amount gets burned from the DERO Network and comes into the Smart Contract universe where it is open and visible to all. And this transferred amount is not accounted in DERO network unless it gets back to DERO Network from SC. > > — Captain, 2021-02-25, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/814444034302410793) This is one of the most important conceptual differences between DVM and EVM. Funds inside the contract universe are public and accounted to the contract; they only re-enter the encrypted DERO supply when a contract explicitly sends them out via SEND_DERO_TO_ADDRESS. The model still governs how contracts handle escrow, payouts, and reserve accounting on Stargate. Ordering guarantees inside a block When developers started building higher-throughput dApps, the question of what the chain actually promises about call ordering came up. Captain laid out the contract in four lines. > A contract can accept n contract calls per block. A single txn can only dispatch a single call. Contract can accept n calls per signer per block. Above are guarantees of order. > > — Captain, 2022-04-18, #dapps (https://discord.com/channels/419781880632836096/947922694387679262/965456557431214130) These are the rules contract authors should design against: one call per transaction, multiple calls per signer per block, and ordered execution within the block. Anything that requires batching multiple state mutations atomically has to be expressed as a single call inside the contract — not assembled out of several transactions. Keep search off-chain Asked about adding richer query and search capabilities at the protocol layer, Captain pushed back on the premise. > It will bring lots of complexities if we bring extra processing to blockchain. It would be better if we do all search/similar operations on your local node. Anyways will dig deep if we can add some small and less complex functions. > > — Captain, 2019-06-27, #mainnet (https://discord.com/channels/419781880632836096/530654307624943616/593689771994513417) This is the philosophy that produced the local-node-first tooling we have today: Gnomon indexing on the operator's machine, TELA discovery via the publisher bridge, and clients that walk the chain themselves rather than asking consensus to do it for them. The chain stays small; the smarts live at the edge. Some features are missing on purpose A user, lifetyper, asked whether arbitrary message payloads could be stuffed into transactions to deliver private messages. Captain answered with a posture rather than a feature flag. > How long do you expect Dero Network will survive after such features are implemented before everyone comes after it. Let me speak today almost all of the missing features discussed/asked above in this channel are not due to lack of technical exoertise/capabilities. > > — Captain, 2019-01-19, #mainnet (https://discord.com/channels/419781880632836096/530654307624943616/536228750128578570) Read in context, this is less a feature-gap admission than a survival-posture statement: in 2019 Captain weighed feature additions against how the network would be perceived and attacked, not just against design cleanliness. Stargate later shipped encrypted RPC arguments and account-bound messaging patterns under a very different threat model — not a direct fulfillment of the plaintext message-stuffing the questioner asked about here. --- Consensus, DAG Ordering & Mining Policy This section covers two related-but-distinct strands of DERO's chain design. The first is how the ledger is *ordered*: not as a strictly linear chain, but as a DAG in which side blocks are first-class citizens counted into a separate topological height. The second is how the team approaches *mining* — specifically, a stated willingness to change the proof-of-work algorithm when they judge it necessary, as demonstrated by the Stargate-95 hard fork and Captain's follow-up to miners who pushed back on it. The quotes span 2018 through mid-2022. The earliest message predates the 2022 DERO-HE migration; the mechanics it describes (chain height, topo height, side blocks) survived that migration largely intact, but the prompt output and block numbers it references are from the pre-Stargate codebase. Reading the daemon prompt: chain height, topo height, and side blocks Early node operators were confused by the four numbers DERO's daemon printed at the prompt. In mid-2018 Captain walked through them in #technical-questions and used the explanation to introduce the DAG concept that distinguishes DERO from a strictly linear chain. > Explanation DERO prompt: DERO:A->100861/B->101420 [C->100861/D->101420] where A-> Current chain height of local node. B-> Current chain Topo height of local node. C-> Network median chain height of connected/visible peers to local node. D-> Network median chain Top height of connected/visible peers to local node. Topo height: Dag topological ordered height. Dero side blocks: D-C or B-A. Contributes to chain security and increased scalability. Expected 10-15%. > > — Captain, 2018-07-24, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/471358881533132801) The distinction between *chain height* (the main sequence) and *topo height* (the DAG-ordered count including side blocks) is the load-bearing concept here: side blocks are not orphans to be thrown away, they are first-class citizens that contribute hashpower to security. The specific block numbers and prompt format belong to the pre-Stargate (pre-2022) daemon, but the height/topo-height/side-block model still describes how DERO orders its ledger today. Stargate-95: the AstroBWT v3 hard fork In June 2022, Captain announced a mandatory hard fork at block 481600. The release rotated DERO's PoW to AstroBWT v3 and temporarily restricted mining to the official CPU miner until third-party miners (XMRig and the GPU ports) could catch up. > @here New version of DERO Stargate-95 released. Update is mandatory as this release is HardFork. Please update your DERO daemon and official miner. No need to delete any file, Just update the derod-daemon (exit the daemon, miner & wallet gracefully. Download, extract & replace the files. After replace start again.). POW is changed to AstroBWT v3. Use official miner only for next few days till other/GPU miners are updated. Only CPU miner is released atm. XMRig etc. are not updated atm. https://github.com/deroproject/derohe/releases/tag/Release95 HardFork will happen in next few hrs at block 481600 . > > — Captain, 2022-06-10, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/984677734716416000) Stargate-95 is the canonical example of DERO's mining policy in motion: a PoW change shipped as a hard fork on a few hours' notice, with the explicit expectation that the third-party miner ecosystem would catch up afterward rather than gate the rollout. The Release95 tag and the AstroBWT v3 algorithm are still live on mainnet. Why the algorithm keeps moving Six days after the Stargate-95 fork, miners who had built around the old algorithm pushed back in #dero-mining. Captain's response framed the change as a deliberate policy choice: DERO will keep experimenting, and will rotate the algorithm again when the team judges it necessary. > Yes we are well aware of above scenarios. But we would like to make very clear that just because someone is not happy with new updates/changes/releases DERO will not stop experimenting new ideas/technologies. We are at very early stage & we need to fix/upgrade lots of things. There was no point in continuing old ALGO when only few were taking advantage of that. We will change the ALGO again if required. > > — Captain, 2022-06-16, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/986970804484984852) Captain doesn't specify who the \"few\" were — whether they were running optimized private miners, dominant pools, specialized hardware, or something else — only that the previous algorithm had narrowed to a small group's benefit and that this was reason enough to rotate it. The closing line (\"We will change the ALGO again if required\") is the durable statement of policy: the design surface is treated as in-progress, and the willingness to fork again is the feature, not the bug. --- Governance & Community Contributions DERO's development has always run through a small core team, but in May 2023 Captain formalized a path for outside contributors. The mechanism was deliberately narrow — two named branches, a clear split between \"fits the current vision\" and \"requires a hardfork,\" and a single license under which any external code would be accepted. The statements below are from that May 20, 2023 announcement, posted in parallel to #dero-discussion and #announcement (the two messages are duplicates of each other). They remain the most explicit public description of how Captain intended community code to enter the project. No follow-up governance document has been published since Captain went MIA in January 2024, so this framing is what's on the record — as a 2023 plan, not as a workflow that ever visibly operated. The two-branch model for community contributions Captain laid out the structure in a single message, distinguishing minor improvements from changes that would require a hardfork. The same text went up in #dero-discussion first and then in #announcement about 37 minutes later — the version below is the announcement-channel post. > Respected DERO Members, To incoporate community development in DERO Project two community branches has been planned. Community-mainnet(for mainnet) & community-testnet(for testnet) branches. DERO Community DEVs can create commits for above branches and after testing & discussions commits will be migrated/merged to main mainnet branch. Community-mainnet(for mainnet) branch will be used for commits that are minor & doesn't require hardfork or substantial change in the current codebase/vision. Community-testnet(for testnet) branch will be used for commits like that are entirely new concept, experimental in nature & require hardfork. This branch can be used to test ideas like removal of account registration requirement or support of Inter communication between Smart Contracts on DERO network. Any code published/committed will be accepted under DERO Research License only. Thank you all of you. Captain > > — Captain, 2023-05-20, #announcement (https://discord.com/channels/419781880632836096/419798745811779586/1109506858869346344) The split is the substantive part: community-mainnet is the on-ramp for changes that fit the existing protocol, and community-testnet is a sandbox for ideas big enough to need a hardfork. The two examples Captain names for the testnet branch — dropping mandatory account registration, and inter-contract communication — are concrete signals about what he considered protocol-level open questions in 2023, not casual asides. In practice, this branch model never produced a visible community-contribution pipeline before Captain went MIA in January 2024, and no merges from those branches into mainnet were ever announced. Read this as the 2023 plan of record, not as an active intake path a contributor can use today. --- Protocol Integrity: Captain in His Own Words DERO's economics have been the target of recurring claims about a hidden dev tax, premine, or skimmed block rewards. The clearest rebuttal isn't a third-party doc — it's Captain directly addressing the question in #technical-questions and pointing readers back at the code. This section anchors the integrity record on a primary source: Captain's own statement of how main-block and side-block rewards actually work. The quote below is from late 2021, before the DERO-HE migration, but the reward structure it describes is the same one operating on mainnet today. No Dev Tax — 100% to Miners, 8% on Side Blocks as a Time-Sync Incentive Asked in #technical-questions about the existence of a developer tax baked into block rewards, Captain answered bluntly and pointed at the code: > There is no such thing as DEV TAX etc. , Pls read the code carefully again. Main block rewards are full 100% and side block reward are 8% and both rewards goes fully to to miners. Side block has 8% rewards to force miners to sync their time and update/submit their job on time. > > — Captain, 2021-10-21, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/900801463511572580) Two things to take away. First: main-block rewards are 100% miner, side-block rewards are 8% miner, and nothing is siphoned off to a developer address — this is verifiable directly in the consensus code. Second: the 8% side-block reward isn't charity, it's a mechanism. It pays miners to keep their clocks synced and submit jobs on time, which matters for a chain that uses a DAG-aware structure rather than a strict longest-chain rule. This statement predates the late-2022 DERO-HE migration, but the reward structure it describes — main 100%, side 8%, no dev cut — is the same one in force on mainnet today. --- Philosophy & Inspirational Quotes The technical work has its own page. This one is for the posture behind it — why Captain built DERO the way he did, what he expected of the community, and the values he kept restating across seven years of public messages. The lines collected here are not slogans drafted for a website. They are answers given inside development channels, in support threads, in replies to skeptics and well-wishers alike. Read in sequence, a coherent project ethos emerges: privacy is not optional, the network is not anyone's property, the work is hard on purpose, and the community — not the core devs — is the long-term guardian. We choose the hard way Day one of the bitcointalk announcement thread. A poster thanks Captain for the work, and Captain answers with what reads, in hindsight, as the project's founding posture. > thanks, you are welcome, we have the skills and we choose the hard way its better for whole crypto community if there are any advancements. > > — Captain, 2017-12-05, Bitcointalk DERO thread (https://bitcointalk.org/index.php?topic=2525508.msg25787409#msg25787409) The frame is set in one sentence: the team is capable, the path is deliberately hard, and the justification is that the broader ecosystem benefits when somebody actually pushes the cryptography forward. Every later design choice — Bulletproofs, homomorphic encryption, no optional-privacy toggle — is downstream of this line. Not an ICO. A community project. Ten days into the bitcointalk thread, with the usual ICO-era questions arriving, Captain draws the line on what DERO is and is not. > Will be updated in details and this is not ICO. Community project where everyone is invited to contribute. > > — Captain, 2017-12-15, Bitcointalk DERO thread (https://bitcointalk.org/index.php?topic=2525508.msg26400734#msg26400734) The contributor-led framing is staked out before there is much of a community to lead it. This becomes the structural reason DERO never had a foundation, a treasury, or a token sale to point at. Why DERO, in plain language Two months in, Captain writes out the canonical answer to the question that would follow the project for years: why does a smart-contract chain need privacy at all? He skips the jargon and reaches for a door. > WHY DERO AND WHY SMART CONTRACTS NEED PRIVACY ? In very simple and few words: Assume you design a smart contract and integrate to access/authorize a building/open a door or any other service like asset-management/tickets/shares distribution based on smart contract. Many would not like like to share/view details of all other users/customers who used/participated/access that contract/service. I hope you too would like transparency in contract details but would not like to share/disclose your details to rest of the world. On DERO blockchain smart contracts details are transparent on blockchain but not user details. > > — Captain, 2018-01-30, Bitcointalk DERO thread (https://bitcointalk.org/index.php?topic=2525508) The split he names — transparent contract logic, private user data — is the architecture DERO eventually shipped. The mission was articulated before the engine to deliver it existed. A blockchain that affects society Three weeks later in the same thread, Captain expands on the social vision in the most sweeping mission statement of the early archive. > You have expressed the IDEA behind Dero. We hope to create a Blockchain which will affect the entire society from increasing the privacy to daily utilities. Users will have confidence that no copy/access of his data exists on the shops/counters/merchants/agents he has visited since start of the day. He lives a private life and he knows who has access/copy of his data. This is a very big and huge impacting topic. In parallel to technological development of DERO Blockchain we are also working for practical life example to express the DERO concept. > > — Captain, 2018-02-19, Bitcointalk DERO thread (https://bitcointalk.org/index.php?topic=2525508.msg30585516#msg30585516) The scope is deliberately wider than crypto: a person walks through their day and knows who has copies of their data. Privacy as a daily-life property, not a coin feature. No permission needed, no mercy asked September 2020, in technical-questions. A user asks about official cooperation or partnership for a business that wants to integrate DERO. The answer is short. > In Crypto DERO doesn't need/expect any mercy or so of any kind. Also you don't need DERO permission for any cooperation to use DERO in your business as DERO is opensource and you can find all code/API on github. > > — Captain, 2020-09-19, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/756772084192903258) Permissionless on both sides — the project asks nothing from anyone, and nobody needs to ask anything of the project. The codebase is the API; that is the entire relationship. Not anti-anyone. Pro-users. April 2022, in #random. A familiar question surfaces — is DERO trying to replace X, beat Y, kill Z? Captain reframes the entire posture. > DERO have no interested in fear or making somone obsolete . Objective is very clear that users using DERO should have max privacy & security. > > — Captain, 2022-04-22, #random (https://discord.com/channels/419781880632836096/420040002878308352/967086547600048179) The mission is not competitive. It is internal: maximum privacy and security for the people who use the chain. Everything else is noise. No optional privacy The next day, in error-support, a user worries they might leak information by misusing the wallet. Captain answers with what is essentially the design ethos of the protocol in one sentence. > There is no concept of optional privacy in DERO. So don't worry of loosing/degrading privacy in DERO if you are doing something wrong. > > — Captain, 2022-04-23, #error-support (https://discord.com/channels/419781880632836096/419798691088695318/967442505371099196) Privacy is not a toggle, a tier, or a careful-mode. It is structural — you cannot use the chain incorrectly in a way that leaks user data, because there is no shielded/transparent split to misuse. On false privacy and VCs A week later, in #suggestions, the discussion turns to projects that market themselves as private but are closed-source or VC-backed. Captain states the values position directly. > DERO would never risk its users in false sense of privacy. Secret blockchain is blackbox-closed source technology with VCs. And VCs have only one goal. > > — Captain, 2022-04-30, #suggestions (https://discord.com/channels/419781880632836096/557277155436789760/969882713022685184) The bar is not whether something is marketed as private. It is whether the user can verify it. Two sentences capture the anti-blackbox, anti-extractive-funding stance of the project. Privacy as a requirement February 2023, in #trading, against a backdrop of tightening surveillance regimes and exchange collapses. Captain offers one of his shorter and more pointed lines. > We will soon see the requirement of privacy & freedom. > > — Captain, 2023-02-24, #trading (https://discord.com/channels/419781880632836096/419799315079364609/1078656523875659806) Eight words. Privacy and freedom not framed as features to offer, but as requirements to meet. The reframing is the whole point. Core devs will never be part of some centralized thing April 2023, in #dero-mining. A user asks about seed nodes and whether they create a centralization risk. Captain uses the answer to draw a wider line. > DERO seed nodes are not required except to bootstrap network. DERO is actual decentralized network & will remain so. DERO core devs will never be part of some centralized thing. There are so many other protocols & chains which can be freezed/halted/selective, feel free to join those networks. > > — Captain, 2023-04-08, #dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1094238692203315281) Seed nodes are convenience, not control. The closing line — that other protocols exist for anyone who wants freezable, halted, or selective behavior — is the project's posture in one breath. --- --- Quantum Resistance & DERO-QR Quantum resistance is one of the few topics where Captain spoke about a future DERO upgrade in concrete engineering terms. The plan, surfaced in a March 2022 exchange with community member Robyer, is DERO-QR — a quantum-resistant scheme that lands on the existing DERO network, with GravitonDB acting as the migration substrate from DERO-HE to DERO-QR. The supporting context stretches back to 2020, when Captain first pointed at Graviton as the reason DERO could move state under cryptographic proofs at all, and forward into mid-2022, when he kept the threat surface in view by quietly sharing news of broken \"quantum-safe\" schemes. Captain's posture is consistent throughout: quantum is a \"when needed\" problem, the real threat is selective and hidden, and the migration tooling is already in the tree. State tracking with crypto-backed proofs Two minutes later in the same thread, Captain names Graviton's actual design intent — not just storage, but verifiable state. > So GravitonDB was written for state tracking with crypto backed proofs. > > — Captain, 2020-10-18, technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/767413032783183913) This is the property that makes the later DERO-QR migration plausible. A database that already commits to state under cryptographic proofs can re-map that state under a different cryptographic scheme without breaking the chain of custody. Opening posture: not a big deal Jump forward to March 31, 2022. A discussion about quantum threats opens in #trading, and Captain sets the tone with a single line. > DERO will have Quantum Tech when it will be required. It's not a big deal. > > — Captain, 2022-03-31, trading (https://discord.com/channels/419781880632836096/419799315079364609/959090674379149382) The framing is deliberate. Quantum is a when-needed problem, not a panic — but the rest of the thread shows he is already engineering for it. Threat surface: hacker's garage, IBM, Intel Robyer pushes back with the standard academic timeline argument — large-scale quantum computers are years away. Captain redirects to where the real threat actually lives. > Robyer you may be right but Pls don't underestimate hacker's garage. And also go though IBM/Intel's recent innovations list. > > — Captain, 2022-03-31, trading (https://discord.com/channels/419781880632836096/419799315079364609/959097200871342221) Two threat vectors in one line — corporate R&D pipelines and unannounced private capability. Neither shows up in conference papers, and both can be operational long before the public timeline says they should be. DERO-QR on the current network Fifteen minutes later, Captain drops the keystone announcement. This is the most concrete public statement of DERO's quantum-resistance plan. > Robyer, We are ready, You will have DERO-QR(Quantum-Resistant) on current DERO-NW. GravitonDB will help to internal-map exisitng DERO-HE to DERO-QR. > > — Captain, 2022-03-31, trading (https://discord.com/channels/419781880632836096/419799315079364609/959100735893700639) Three engineering claims compressed into one sentence: DERO-QR will run on the existing network (no fork, no new chain), the upgrade path is DERO-HE to DERO-QR, and GravitonDB is the substrate that does the internal mapping between the two cryptographic regimes. The 2020 Graviton work is what makes this an upgrade rather than a migration. Enigma-cracking: you won't know until you do Later in the same thread Captain reaches for a historical analog to explain why quantum capability will not announce itself. > Exactly, Most things will be down. But expect attacks to be very selective and occasional just like as Robyer said above Eg: Enigma cracking so you will never know till mass attacks in open. > > — Captain, 2022-03-31, trading (https://discord.com/channels/419781880632836096/419799315079364609/959117179259871292) The Enigma analogy is the load-bearing one. Bletchley Park's capability stayed secret for decades while it was used selectively to avoid revealing the break. A real quantum capability would behave the same way — visible only when the operator decides the strategic value of using it openly exceeds the value of keeping it hidden. By then the migration window is closed. GravitonDB is a complete project in itself September 2022, in #dero-discussion, Captain reframes how to think about Graviton's scope inside the DERO codebase. > GravitonDB which is complete project in itself is side project for DERO-HE. > > — Captain, 2022-09-14, dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1019408924321009734) Read alongside the March quotes, this lands differently than it might in isolation. Graviton is a standalone project that happens to currently serve DERO-HE — which is exactly what you would want if you planned to swap the cryptographic layer above it for something quantum-resistant without rewriting the storage and proof substrate underneath. --- Current & Coming Times: What Ships vs What's Ready There is a recurring theme in Captain's posts that is easy to miss if you only read DERO's release notes: what ships is deliberately less than what is built. Stargate, in his telling, is a *downgrade* — tuned for the machines on the network today and for users who need to understand what they are running. The harder primitives sit behind it, waiting. Read together, these messages frame DERO not as a finished product but as a design horizon. The privacy is sized for \"current & coming times,\" the architecture is backed by \"decades of experience,\" and the AI-agent future Captain described in 2022 reads, in 2026, less like speculation and more like a roadmap. Downgrades for current times and weak machines Asked in August 2022 about homomorphically encrypting addresses, Captain answers in a single beat — it is not the hard part. The hard part is restraint. > `How hard would it be to Homomorphically encrypt addresses?` Not a big deal, Lots of downgrades have been done to DHEBP for keeping in view of current times & computational powers of weak machines on NW. > > — Captain, 2022-08-27, random The line to sit with is *Lots of downgrades have been done to DHEBP*. The shipped protocol is not the ceiling of what was designed — it is the floor that the weakest machine on the network can still keep up with. Designed from scratch, because the field stalled Four minutes later, Captain explains why those downgrades exist in the first place: there was nothing serious to build on. > Lots of new things have to be designed in DERO from scratch for maximum privacy. There is nothing in existing blockchain tech world to develop something serious. Blockchain research & progress haven been neglected/over-taken due to hype & scams. > > — Captain, 2022-08-27, random This is the frame for every other quote in this section. DERO is not assembling other people's primitives. It is building the primitives, and shipping a tuned-down version of them so the network can actually run. AI making private transactions Thirteen minutes later, the picture sharpens. The AI is not just *aligned with* privacy — it is transacting. > It would be interesting to see AI making private transactions/payments in different meta/games/real world etc. > > — Captain, 2022-10-13, dero-discussion Agentic payments across games, virtual worlds, and the real world — described in 2022, on a chain that already has the encrypted-balance and SC primitives to support them. Decades of experience for current & coming times In December 2022, Captain compresses the entire design philosophy into one sentence. > In-addition to above DERO uses decades of experience to make sure DERO offers best privacy possible required in current & coming times. > > — Captain, 2022-12-08, dero-discussion *Decades of experience*, *best privacy possible*, *current & coming times* — the triad Captain returns to whenever someone asks why DERO looks the way it does. The chain is not optimized for today's threat model alone. Stargate is the explainable version By April 2023, Stargate is live and people are reading the protocol. Captain wants the record clear about what they are reading. > Current DERO Stargate is heavily downgraded so that people can understand it easily. > > — Captain, 2023-04-15, dero-discussion The companion to the 2022 downgrade quote, and arguably the more pointed of the two. Stargate is the version of DERO that fits in a developer's head. There is more behind it. Why his heart still doesn't allow SC interactions August 2023. Asked why DERO still does not allow smart contracts to interact with each other, Captain reaches for the same phrase he used eight months earlier. > Just for such & similar reasons, My heart doesn't allow SCs interactions. Till current state each & every part has been designed & backed by decades of experience. > > — Captain, 2023-08-03, random The second invocation of *decades of experience*, used this time to defend a missing feature rather than a shipped one. The restraint is the design. --- Blackbox DERO: The Long-Term Vision A recurring pattern in Captain's public messages is the hint that Stargate — the protocol you can run today — is a deliberately constrained subset of a larger design. The quotes below are the moments where Captain steps furthest forward, sketching a future \"entirely blackbox\" DERO with no visible TXIDs, no mining-reward visibility, and no explorer. Read these as statements of design intent, not as committed roadmap. The credo is six words: *Before Protocol you need Vision/Future.* What ships at any given moment is the slice of that vision the protocol can carry now. HE scope is intentionally limited \"for now\" Asked why DERO-HE applies homomorphic encryption only to balances and transfers rather than the full state, Captain frames the current scope as a starting point, not a destination. > No, DERO is using HE for just balances etc. for now because it more than the enough for the current requirement. Also it will help to learn more. In future this will change based on the requirements and use cases. > > — Captain, 2021-09-24, dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/890889061466791956) The first hint that what's shipped is not what's planned — HE coverage is sized to current needs, with explicit room to grow. Everything floating in DERO-sea is encrypted Later the same day, Captain restates the invariant in its most poetic form — wallets exist only to prove ownership over data the network itself never sees in cleartext. > In DERO-HE user balances/transfers etc. are never decrypted and all logics operate on encrypted data only. Wallets are just required to prove your ownership to the encrypted data. Everyone and everything floating in DERO-sea is encrypted. > > — Captain, 2021-09-24, dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/890894489609199667) The always-encrypted invariant, stated as a property of the medium rather than a feature of the wallet. CryptoNote is outdated for DERO Minutes later, Captain publicly retires the old privacy stack — not as a value judgement on CryptoNote itself, but as a statement about which protocol family DERO belongs to going forward. > DERO has moved beyond outdated CryptoNote Protocol . Not interested in any new developments /improvements/exploits in CryptoNote Protocol. Good if [user] has done some improvements on CryptoNote Protocol but for DERO it is outdated protocol. > > — Captain, 2021-10-20, technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/900253989646532648) The moment the old privacy stack is publicly retired — improvements there are someone else's project, not DERO's. Obfuscation out, HE in, plaintext never Asked to spell out the substitution, Captain gives the replacement thesis in one paragraph: obfuscation is a workaround, HE is the actual primitive. > CryptoNote Protocol is full of obfuscation only. DERO is migrating to Homomorphic Encryption which supports operations/audit etc. on encrypted data only, No need of any plaintext data/balance/TXs calculations. DATA/Balances/TXs will always stay in encrypted state on DERO network and only user/wallet can decrypt balances/data. > > — Captain, 2021-10-20, technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/900256409818640425) The contrast is the point: obfuscation hides plaintext that still exists; HE removes the plaintext from the network's view entirely. \"Most of these projects will be seen running on DERO network\" Responding to critics who couldn't see what DERO was building, Captain reframes the disagreement as a vision gap rather than a technical one. > Looks these people/DEV seems have no idea what DERO is building and aiming for. Coming times No surprises if most of these projects will be seen running on DERO network. > > — Captain, 2021-10-20, technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/900262241876725780) The thesis: if the substrate is right, the applications migrate. Said in 2021, before most of the surface area existed. Entirely blackbox DERO Eighteen months later, Captain sketches the endgame explicitly. Ring members go away; so does the explorer, the mining-channel reward visibility, and the very concept of external audit. > Also DERO design can also be upgraded to remove concept of ring members entirely. In upgraded design there will no visible TXIDs, no mining rewards visibilty, no fuss in mining channel & no concept of explorer. And of-course no concept of audit etc. Entirely blackbox DERO. 🙂 > > — Captain, 2023-04-15, dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1096733857824383029) This is the anchor the section is named for. Every other quote points at this end-state from a different angle. --- Broadcasts & Slogans Captain wrote in compressed declaratives. When he wanted a principle to stick, he stripped it to a single line and let it land as identity rather than argument — the kind of phrasing that doubles as a status message, a channel broadcast, and a community password. The lines below are the recurring anchors: short, repeatable, and structurally identical across years. They are the slogans the network rallied around, in his own words. Not your keys, not your coins Dropped into #trading during exchange-listing chatter. The most iconic crypto custody mantra, repeated by Captain across years as a project-level anchor. > Not your keys, Not your coins. > > — Captain, 2022-03-09, trading (https://discord.com/channels/419781880632836096/419799315079364609/950960399090589759) The canonical self-custody line, stated without elaboration. Captain treated it as load-bearing — the precondition for everything else DERO claimed about privacy. Actual decentralized blockchain Answering a question in #technical-questions, Captain reframed the conversation away from feature comparison and toward a binary choice. > Welcome to actual decentralized blockchain else pls stay with Central Banking systems. > > — Captain, 2022-04-01, technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/959251609429344378) A dichotomy slogan — either you are running an actually decentralized chain or you are inside the system DERO was built to refuse. No middle category. Mine on your own node A mining-channel one-liner that fuses three of Captain's recurring positions — solo mining, decentralization, and self-hosting — into a single sentence. > Best thing for network security, decentralization is to mine on your own node. > > — Captain, 2022-10-13, dero-mining (https://discord.com/channels/419781880632836096/427613001537814540/1029974224829415434) Mining policy stated as security policy. The slogan format hides the load-bearing claim: pool mining and network security are not the same goal. No heroes, only community Posted into #dero-discussion in response to attempts to lionize individual contributors. Captain rejected the framing outright. > There are no HERO/S in decentralized network. Community is the actual guardian in decentralized network. > > — Captain, 2023-03-18, dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1086701086770999388) A pure aphorism, and a direct rebuke of personality-cult thinking. The guardian of a decentralized network is, by definition, plural. Run your own node Two weeks after the no-heroes line, Captain returned to operational ground. The refined wallet-and-node mantra he repeated in many variations. > For best security & privacy, run your own node & connect wallet to your own node. > > — Captain, 2023-04-02, dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1092114303722725527) Security and privacy collapsed into one action. The slogan is short enough to fit in a status message and specific enough to function as a configuration instruction. --- Biographical Notes Captain rarely talked about himself. When he did, it came in fragments — a sentence about upbringing, a reference to writing compilers decades ago, a note that he was traveling. No timeline, no biography, no resume. What we have is what slipped out around the technical work. Read together, these fragments include a reference to compiler work decades ago, a sentence about upbringing, named acknowledgments of contributors, notes about travel, and the occasional cost admission. We draw no portrait beyond what he wrote. Nature, discipline, values January 2018 on Bitcointalk, weeks after the DERO mainnet launch. Someone had offered praise and, implicitly, the suggestion that DERO should chase ICO money like everyone else that cycle. Captain answered with what reads as a personal credo. > ...thanks for your words but It depends more on the nature, discipline, values in your life. We will work and build together a strong community slowly our own in hard way. We don't need anything big in millions or so like ICO. We will work hard and produce something & if remarkable DERO will get its success. Thank you. > > — CaptDero, 2018-01-06, Bitcointalk DERO ANN thread (https://bitcointalk.org/index.php?topic=2525508.msg27600667#msg27600667) The refusal of ICO money and the framing of character — nature, discipline, values — sets the posture the rest of the archive keeps returning to. \"Slowly our own in hard way\" is close to a thesis statement for how the project would be run. The teacher called Experience July 2018. Serena, a long-time contributor, had left the project after an incident. Captain's first public reply to her after the departure is reconciliatory rather than defensive. No stable per-message permalink survives — only the thread context. > Hello @Serena, My first reply to you since you left. I believe you have contributed lots of efforts and time for the DERO Community. Thanks for that. For me you are still the same kind and sweet person. Pls don't allow this incident to affect you any way. Let the good and positive in you be more powerful. I have seen and handle lots of such in life, thanks to the teacher called Experience. You will always have my good wishes. Feel free for anything else. Thanks. Regards. > > — CaptDero, 2018-07-20, Bitcointalk DERO ANN thread \"The teacher called Experience\" is the older-mentor register that surfaces throughout the archive. The phrasing — formal, deliberate, slightly archaic — is also a recognizable voice fingerprint. Environment and society June 2022 in #random, mid-conversation about beliefs and worldview. This is the closest Captain ever comes to placing himself culturally on the map. > Perhaps most of my view/beliefs are due to the enviroment/society I have been raised. > > — captain030317, 2022-06-27, #random (https://discord.com/channels/419781880632836096/420040002878308352/990884968722993162) One sentence, no elaboration. He never named a country, a language, or a tradition. He attributed his worldview to where he came from and left it there. Traveling, meeting friends Mid-December 2022, posted to #dero-discussion. A rare note about being away from the desk. > As I am traveling & meeting some friends atm. Would like to say that world is changing/evolving faster than our beliefs. Lots of extra-ordinary achievements in medical,astrophysics & other sciences. I am also surprised to see the developments. Looks coming times will be totally different. > > — captain030317, 2022-12-14, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1052601797002399775) He names medical and astrophysics alongside other sciences. He does not elaborate on where he was traveling or whom he was meeting. First specialized compilers, two decades back August 2023 in #random, explaining why DVM uses an interpreter instead of a compiler. The aside is the closest Captain comes to dating his own professional origin. > That's why DERO has interpreter instead of compiler. Even though team has experience of writing some of the first specialized compilers more than 2 decades back. > > — Captain, 2023-08-03, #random (https://discord.com/channels/419781880632836096/420040002878308352/1136657488037548162) Compiler work \"more than 2 decades back\" places the team's systems-engineering roots in the 1990s or earlier — long before crypto. It also fits a pattern that recurs across the archive: we know how to do it the other way, we chose this on purpose. Exchange listings, time, and money lost December 11, 2023, in #dero-discussion — a rare cost admission. > We lost several $100K & lot's of precious time in this exchange listings. > > — captain030317, 2023-12-11, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1183793445949689937) A rare admission of cost — both money and time — from someone who almost never talked about either. --- The Trail: Cryptic Clues and Last Words What follows is a curated arc of messages from Captain that, in retrospect, read differently than they did in the moment. Most are short. Several are signoffs. A few are practical announcements where the word choice lands harder than it needed to. The collection opens with his first public Christmas in 2017, then picks up again in his late period from late 2022 through his last message on New Year's Day 2024. Together they trace a shift in voice — from technical build updates to short broadcast greetings — visible in the last stretch before he went MIA in January 2024. This page draws no conclusions about what happened to him. The pattern is the point: certain phrases recur (\"tomorrow never comes,\" \"coming times,\" \"rest & peace,\" \"bless\"), and the rhythm of his presence changes. Read them as Captain wrote them. The community has continued without him since. Tomorrow never comes (Christmas 2017) Captain's first public Christmas message on the original Bitcointalk DERO thread, six months into the project. Signed 'Capt. Dero' — the handle that would stick for seven years. The phrase he opens with here will echo, in different forms, until his final week. > Happy Holidays to everyone, Live your life and enjoy it to the fullest. Tomorrow never comes. Be safe and responsible. Capt. Dero. > > — captain030317, 2017-12-25, Bitcointalk — Re: DERO: A secure, private blockchain with Smart Contracts. 'Tomorrow never comes' is the anchor phrase of this collection. It appears here on his first public Christmas and bookends a seven-year arc. Third person — 'captain's msgs' From #random in September 2022, in a thread about community waiting on his replies. Captain answers in the third person about himself — a register he uses rarely, and almost always when redirecting attention away from his own role. > Thats the real issue, why depend/wait for captain's msgs. 🙂 > > — Captain, 2022-09-11, #random (https://discord.com/channels/419781880632836096/420040002878308352/1018550416558018630) Sixteen months before the messages stopped, he was already nudging the community to not depend on them. This 'don't wait for me' theme repeats elsewhere in the same period. Rest & peace only Two weeks later, in #dero-discussion, someone asked him a question that required a longer answer than he had energy for. He demurred in a way he almost never did. > Complex to answer . ATM looking for some rest & peace only. > > — Captain, 2022-09-28, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1024739074856202250) Captain rarely spoke about his own state. This is one of the few times the word 'rest' surfaces in first person. Higher level of peace A December 2022 message in #random about wallet-side ring configuration. The technical content is unremarkable; the closing phrase is what makes it sit in this collection. > Feel free to optimize/update Rings/wallets etc. This is purely wallet-side & independent of core. Advance users can define their own private logic also in wallet for higher level of peace. > > — Captain, 2022-12-27, #random (https://discord.com/channels/419781880632836096/420040002878308352/1057300776084578304) The word 'peace' recurs across this period. Coming times From #dero-discussion in mid-January 2023, in a conversation about why anyone should care about privacy tech now. Captain's answer reframes the question as a survival skill rather than a feature. > Better to start learning more about privacy now. Because in coming times that knowledge will be required anyhow to survive & maintain edge with respect to others. > > — Captain, 2023-01-13, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1063269415237472318) 'Coming times' is the most urgent register Captain uses in this period. The phrase recurs in adjacent messages through 2023. Down forever A February 2023 announcement that the hosted browser wallet at wallet.dero.io would be shut down. The substance is operational; the word choice is the part that registers in this list. > wallet.dero.io will be down forever in coming weeks. Pls familiarize yourself with cli or Engram wallet. > > — Captain, 2023-02-19, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1076869262511185931) Part of a pattern in this stretch where Captain routes users toward self-sufficient tooling — CLI, Engram, local nodes — over anything he himself hosts. Severely disconnected Mid-March 2023, in #dero-discussion. Someone had asked, again, about his periodic disappearances. This is one of the few times he explained them directly. > I always travel to parts which are severely disconnected to rest of the world both physically & with network capabilities. All good ,Nothing new. 🙂 > > — Captain, 2023-03-18, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1086696541080797305) Addressed to the community as a whole, in passing. The line stands out because Captain almost never described his own movements. Bless you all New Year's Eve into New Year's Day 2024, in #dero-discussion. A broadcast greeting, addressed to everyone. > Very Very Happy New year to everyone. Bless you all. > > — Captain, 2024-01-01, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1191443862232604752) His last message. The seven-year arc that opened with 'Tomorrow never comes' on Christmas 2017 closes here, with 'Bless you all' on New Year's 2024.",
+      "lastUpdated": "2026-06-04"
+    },
     {
       "product": "derod",
       "slug": "dvm/create-deploy-use-smart-contract",
@@ -275,6 +393,7 @@
         "Step 5: Call a Function (Send a Tip)",
         "Call a Function with Arguments",
         "Step 6: Verify the State Changed",
+        "The three-step pattern — minimal reference",
         "Complete Workflow Summary",
         "Write the contract",
         "Deploy",
@@ -285,7 +404,7 @@
         "Common Mistakes",
         "What's Next"
       ],
-      "plainText": "Create, Deploy & Use a Smart Contract This is a hands-on tutorial that takes you from a blank file to a working smart contract on the DERO blockchain. By the end, you will have written a contract, deployed it, called its functions, and queried its state — all from the command line. **New to DERO contracts?** Read Smart Contract Fundamentals first for the concepts behind everything in this tutorial. --- Prerequisites You need three things running: | Component | Purpose | Default Port | |-----------|---------|-------------| | **DERO Daemon** (derod) | Connects to the blockchain | 10102 (mainnet) | | **DERO Wallet CLI** | Signs and broadcasts transactions | 10103 (mainnet) | | **Some DERO** | Gas fees for deployment and calls | ~0.01 DERO minimum | Verify everything is running: --- Step 1: Write the Contract Create a file called tipjar.bas with this content: **What each function does:** | Function | Who Can Call | What Happens | |----------|-------------|-------------| | Initialize | Deployer (once) | Sets the deployer as owner, initializes counters | | Tip | Anyone | Accepts DERO, increments counters, records last tipper | | Withdraw | Owner only | Sends DERO from the contract to the owner | | GetStats | Anyone | Returns the tip count | **RETURN 0 = success, RETURN 1 = failure.** If a function returns 1, all state changes revert and any DERO sent is returned to the caller. --- Step 2: Deploy the Contract Deployment uses the wallet's transfer RPC method with the contract source in the sc field. The wallet accepts the code as **base64**. The response contains the **TXID**, which is also the **SCID** (Smart Contract ID): Save this TXID — it's the permanent address of your contract on the blockchain. **SCID = TXID.** On DERO, the smart contract's unique identifier is the hash of the deployment transaction. There is no separate \"contract address\" concept. Deploy with Initialize Parameters If your Initialize function accepts parameters, pass them via sc_rpc: Data types: \"S\" = String, \"U\" = Uint64, \"H\" = Hash. --- Step 3: Wait for Confirmation DERO blocks are produced roughly every 18 seconds. Wait at least one block before interacting with the contract: **One TX at a time.** DERO's encrypted balance system only allows one pending (unconfirmed) transaction per wallet. Always wait for a transaction to confirm before sending the next one. Attempting concurrent transactions will cause the second one to be silently dropped. --- Step 4: Verify Deployment Query the contract's state using the daemon's getsc method: A successful deployment returns the contract's stored variables: | Field | Meaning | |-------|---------| | stringkeys.C | The contract source code (hex-encoded) | | stringkeys.owner | The raw address of the deployer | | stringkeys.totalTips | Current total tips (0 after deploy) | | balance | DERO held by the contract | If stringkeys is missing or empty, the deployment failed — likely a syntax error in the contract or an Initialize that returned 1. Query Specific Variables Instead of fetching all variables, you can request specific keys: This returns valuesstring with the values in the same order as the requested keys. --- Step 5: Call a Function (Send a Tip) Use the scinvoke method to call contract functions. To send a tip, call Tip with some DERO attached: | Parameter | Purpose | |-----------|---------| | scid | The contract to call | | sc_rpc[0].value | The function name (\"Tip\") | | sc_dero_deposit | DERO to send (in atomic units: 10000 = 0.1 DERO) | | ringsize | Must be 2 for functions that use SIGNER() | **Atomic units:** 1 DERO = 100,000 atomic units. So 10000 = 0.1 DERO, 100000 = 1 DERO. Call a Function with Arguments For functions that take parameters (like Withdraw), add them to sc_rpc: --- Step 6: Verify the State Changed After waiting for confirmation (~20 seconds), query the state again: Expected output after one 0.1 DERO tip: --- Complete Workflow Summary Write the contract Create a .bas file with Initialize and your business logic functions. Deploy Base64-encode the source and send it via the wallet's transfer method with the sc field. Wait for confirmation At least one block (~18 seconds). Always wait between transactions. Verify deployment Query with DERO.GetSC — check that stringkeys contains your stored variables. Interact Call functions with scinvoke. Attach DERO with sc_dero_deposit. Pass arguments in sc_rpc. Query state Use DERO.GetSC with variables: true or targeted keysstring queries. --- Common Mistakes | Mistake | Symptom | Fix | |---------|---------|-----| | Putting SC_CODE in sc_rpc instead of the sc field | Contract deploys but has no state (empty stringkeys) | Use the top-level \"sc\" parameter — the wallet auto-decodes base64 from this field only | | Sending two transactions without waiting | Second TX silently dropped (TXID returned but never mined) | Wait ≥20 seconds between transactions | | Using ringsize > 2 with SIGNER() | Function returns 1 (access check fails) | Use ringsize: 2 for any function that checks SIGNER() | | Forgetting DEROVALUE() check | Contract accepts 0-value calls as deposits | Always guard with IF DEROVALUE() == 0 THEN GOTO [fail] | | Not checking stringkeys after deploy | Assuming deploy succeeded when Initialize actually failed | Always verify with GetSC — if stringkeys is empty, the contract has no state | --- What's Next - DVM-BASIC Language Reference — Full syntax, types, and built-in functions - DVM Function Reference — Complete function list with gas costs - Token Contract — Deploy a private fungible token - Wallet RPC API — Full reference for transfer, scinvoke, and more - Daemon RPC API — Full reference for GetSC, GetTransaction, and more",
+      "plainText": "Create, Deploy & Use a Smart Contract This is a hands-on tutorial that takes you from a blank file to a working smart contract on the DERO blockchain. By the end, you will have written a contract, deployed it, called its functions, and queried its state — all from the command line. **New to DERO contracts?** Read Smart Contract Fundamentals first for the concepts behind everything in this tutorial. --- Prerequisites > SC download/balance/parameters checks are done on blockchain using daemon port 40402. But sending/SC install/update/balance transfer etc. are done using wallet port 40403 by rpc methods. > > — Captain, 2021-02-24, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/813934126636859454); verified · Release 142: config/config.go (mainnet 10102/10103, testnet 40402/40403); walletapi/rpcserver/rpc_websocket_server.go:208,319 **Mental model:** **reads → daemon, writes → wallet.** Every example below follows that split. Captain's 2021 quote uses testnet ports (40402/40403); mainnet is 10102/10103. Same logic. You need three things running: | Component | Purpose | Default Port | |-----------|---------|-------------| | **DERO Daemon** (derod) | Connects to the blockchain | 10102 (mainnet) | | **DERO Wallet CLI** | Signs and broadcasts transactions | 10103 (mainnet) | | **Some DERO** | Gas fees for deployment and calls | ~0.01 DERO minimum | Verify everything is running: --- Step 1: Write the Contract Create a file called tipjar.bas with this content: **What each function does:** | Function | Who Can Call | What Happens | |----------|-------------|-------------| | Initialize | Deployer (once) | Sets the deployer as owner, initializes counters | | Tip | Anyone | Accepts DERO, increments counters, records last tipper | | Withdraw | Owner only | Sends DERO from the contract to the owner | | GetStats | Anyone | Returns the tip count | **RETURN 0 = success, RETURN 1 = failure.** If a function returns 1, all state changes revert and any DERO sent is returned to the caller. --- Step 2: Deploy the Contract Deployment uses the wallet's transfer RPC method with the contract source in the sc field. The wallet accepts the code as **base64**. The response contains the **TXID**, which is also the **SCID** (Smart Contract ID): Save this TXID — it's the permanent address of your contract on the blockchain. **SCID = TXID.** On DERO, the smart contract's unique identifier is the hash of the deployment transaction. There is no separate \"contract address\" concept. Deploy with Initialize Parameters If your Initialize function accepts parameters, pass them via sc_rpc: Data types: \"S\" = String, \"U\" = Uint64, \"H\" = Hash. --- Step 3: Wait for Confirmation DERO blocks are produced roughly every 18 seconds. Wait at least one block before interacting with the contract: **One TX at a time.** DERO's encrypted balance system only allows one pending (unconfirmed) transaction per wallet. Always wait for a transaction to confirm before sending the next one. Attempting concurrent transactions will cause the second one to be silently dropped. --- Step 4: Verify Deployment Query the contract's state using the daemon's getsc method: A successful deployment returns the contract's stored variables: | Field | Meaning | |-------|---------| | stringkeys.C | The contract source code (hex-encoded — recover with echo \" \" \\| xxd -r -p) | | stringkeys.owner | The raw address of the deployer (whatever your Initialize stored) | | stringkeys.totalTips | Current total tips (0 after deploy) | | balances | Map keyed by SCID. **0x000...000 is native DERO.** Any other 32-byte key is a token SCID. | | balance | Convenience field — same as balances[\"0000...0000\"] | If stringkeys is missing or empty, the deployment failed — likely a syntax error in the contract or an Initialize that returned 1. **Where the shape comes from.** Captain demonstrated this exact getsc response in #dero-he-testnet on 2021-11-28 — same hex-encoded C, same zerohash balance key. The contract Code lives at dvm/sc.go (SC_Code_Key = 'C'); the balance map convention is in cmd/derod/rpc/rpc_dero_getsc.go. Query Specific Variables Instead of fetching all variables, you can request specific keys: This returns valuesstring with the values in the same order as the requested keys. --- Step 5: Call a Function (Send a Tip) Use the scinvoke method to call contract functions. To send a tip, call Tip with some DERO attached: | Parameter | Purpose | |-----------|---------| | scid | The contract to call | | sc_rpc[0].value | The function name (\"Tip\") | | sc_dero_deposit | DERO to send (in atomic units: 10000 = 0.1 DERO) | | ringsize | Must be 2 for functions that use SIGNER() | **Atomic units:** 1 DERO = 100,000 atomic units. So 10000 = 0.1 DERO, 100000 = 1 DERO. Call a Function with Arguments For functions that take parameters (like Withdraw), add them to sc_rpc: --- Step 6: Verify the State Changed After waiting for confirmation (~20 seconds), query the state again: Expected output after one 0.1 DERO tip: --- The three-step pattern — minimal reference The TipJar tutorial above shows the full lifecycle. If you just want the smallest possible reference template to copy-paste, this is Captain's original three-step example. **The contract** (helloworld.bas): **Step 1 — Install via wallet RPC:** The response contains the SCID — use it in the next two steps. **Step 2 — Query state via daemon RPC:** **Step 3 — Call a function via wallet RPC:** **Pattern source.** This three-step flow — install_sc (wallet) → getsc (daemon) → scinvoke (wallet) — comes from Captain's helloworld.bas walkthrough in #dero-he-testnet on 2021-11-28. The original used testnet ports (40402/40403); the examples above are converted to mainnet (10102/10103). RPC shapes (sc_dero_deposit, sc_rpc array, ringsize) are unchanged on Release 142 — see walletapi/rpcserver/rpc_websocket_server.go:208,319 and walletapi/rpcserver/rpc_scinvoke.go:28. --- Complete Workflow Summary Write the contract Create a .bas file with Initialize and your business logic functions. Deploy Base64-encode the source and send it via the wallet's transfer method with the sc field. Wait for confirmation At least one block (~18 seconds). Always wait between transactions. Verify deployment Query with DERO.GetSC — check that stringkeys contains your stored variables. Interact Call functions with scinvoke. Attach DERO with sc_dero_deposit. Pass arguments in sc_rpc. Query state Use DERO.GetSC with variables: true or targeted keysstring queries. --- Common Mistakes | Mistake | Symptom | Fix | |---------|---------|-----| | Putting SC_CODE in sc_rpc instead of the sc field | Contract deploys but has no state (empty stringkeys) | Use the top-level \"sc\" parameter — the wallet auto-decodes base64 from this field only | | Sending two transactions without waiting | Second TX silently dropped (TXID returned but never mined) | Wait ≥20 seconds between transactions | | Using ringsize > 2 with SIGNER() | Function returns 1 (access check fails) | Use ringsize: 2 for any function that checks SIGNER() | | Forgetting DEROVALUE() check | Contract accepts 0-value calls as deposits | Always guard with IF DEROVALUE() == 0 THEN GOTO [fail] | | Not checking stringkeys after deploy | Assuming deploy succeeded when Initialize actually failed | Always verify with GetSC — if stringkeys is empty, the contract has no state | --- What's Next - DVM-BASIC Language Reference — Full syntax, types, and built-in functions - DVM Function Reference — Complete function list with gas costs - Token Contract — Deploy a private fungible token - Wallet RPC API — Full reference for transfer, scinvoke, and more - Daemon RPC API — Full reference for GetSC, GetTransaction, and more",
       "lastUpdated": "2026-03-02"
     },
     {
@@ -307,7 +426,7 @@
         "Execution Limits & Constraints",
         "Related Pages"
       ],
-      "plainText": "DERO Virtual Machine (DVM) DERO Virtual Machine represents the entire DERO Smart Contracts eco-system which runs on the DERO blockchain. DVM is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference. DERO's unique innovation is that tokens issued by smart contracts become encrypted balances in user wallets through homomorphic encryption. While contract code and state remain public and auditable, token balances and transfer amounts are completely private. Smart Contracts are nothing but rules which apply on transacting parties. Current version of DVM is an interpreter based system to avoid security vulnerabilities, issues and compiler backdoors. This also allows easy audits of Smart Contracts for quality, bug-testing and security assurances. DVM supports a new language DVM-BASIC. DVM apps run on a from scratch custom built privacy supporting, encrypted blockchain, an enormously powerful shared global infrastructure that can move value around and represent the ownership of assets/property without leaking any information. No one knows who owns what and who transferred to whom. - This enables developers to create puzzles, games, voting, markets, store registries of debts or promises, move funds in accordance with instructions given long in the past (like a will or a futures contract) and many other ideas/things that have not been invented yet, all without a middleman or counterparty risk. - DVM-BASIC is a contract-oriented, high-level language for implementing smart contracts. It is influenced by GW-BASIC, Visual Basic and C and is designed to target the DERO Virtual Machine (DVM). It is very easy to program and very readable. - DVM runs Smart Contracts which are a collection of functions written in DVM-BASIC. These functions can be invoked over the blockchain to do something. Each smart contract is currently self-contained — cross-contract calls are architecturally planned but not yet enabled. - DVM supports a number of comment formats such as ', //, /* */ as good documentation is necessary. DVM-Basic DVM Example Factorial program ' This is a comment // This comment is supported /* this is multi-line comment */ Function Factorial(s Uint64) Uint64 // this is a comment 10 DIM result,scopy as Uint64 /* this is also comment */ 15 LET scopy = s 20 LET result = 1 30 LET result = result * s 40 LET s = s - 1 50 IF s >= 2 THEN GOTO 30 70 RETURN result End Function - DVM smart contracts are written in a DVM-BASIC custom BASIC style language with line numbers. - DVM supports uint64 and string data types. - DVM interprets the smart contract and processes it line by line. - uint64 supports almost all operators, namely +, -, *, /, %. - uint64 supports the following bitwise operators: &, |, ^, !, >>, <<. - uint64 supports the following logical operators: >, >=, <, <=, ==, !=. - string supports only the + operator. It supports concatenation with a uint64. - string supports == and != logical operators. - All DVM variables are mandatory to define and are initialized to default values, namely 0 and an empty string (\"\"). Smart Contract Execution Guidelines - Smart Contract execution must return 0 to persist any changes made during execution. No panics should occur during execution. DERO Smart Contract Examples - Launching your token/asset on DERO blockchain - Launching your exchange for interchanging tokens/assets - DERO Smart Contract Examples - More Examples DERO Default Ports **Mainnet:** - Mining Getwork Port: 10100 TCP - P2P Default Port: 10101 UDP - RPC Default Port: 10102 TCP - Wallet RPC Default Port: 10103 TCP **Testnet:** - P2P Default Port: 40401 - RPC Default Port: 40402 - Wallet RPC Default Port: 40403 *NB: Change ports to mainnet or testnet based on your requirements.* Statements Supported by DERO Virtual Machine - DIM - FUNCTION - GOTO - IF - LET - RETURN DIM - DIM stands for data in memory and is used to define variable names within a function. Syntax: Supported types in DVM are Uint64 and String. All DVM variables are mandatory to be defined and are initialized to default values: 0 for Uint64 and \"\" for String. FUNCTION - Function statement is used to define a function. Syntax: Function Syntax Function syntax can be of two types: 1. Function function_name(0 or more arguments) 2. Function function_name(0 or more arguments) return type DVM Function Rules - All functions start with the Function keyword. - Function names should be alphanumeric. - If the first letter of the function is an uppercase alphabet, the function is exported and can be invoked externally via blockchain transactions. - If the first letter of the function is a lowercase alphabet, the function can only be invoked by other functions within the smart contract. - Functions may or may not have a return type. - All functions must use RETURN to return from the function or to return a value. RETURN is mandatory. - All functions must end with End Function. End Function is mandatory. - A function can have an implicit parameter value of type uint64, which contains the amount of DERO value sent with the transaction. - Any error during processing will immediately stop execution and discard all changes that occur during SC execution. - Any entrypoint which returns a uint64 value of 0 is termed as success and will make the transaction commit all state changes. Specific Function Commands - **GOTO**: Used to jump to any line number within the function. It cannot cross function boundaries. Syntax: - **IF**: Executes a statement if a specified condition is true. It has two forms. Syntax: - **LET**: Used to assign a value to a variable. Value can be as complex as possible and can contain complex expressions. Syntax: - **RETURN**: Used to return from a function. It has two forms. Syntax: Return value must match the type defined while declaring the function. RETURN can be used anywhere within a function. DVM Inbuilt Support Functions DVM includes support functions that provide specific functionality or expose DVM internals. Support Functions VERSION(v String) - **Description:** Sets a version to dvm.VERSION. Returns 1 if successful, panics otherwise. - **Return Type:** Uint64 - **ComputeCost:** 1000 - **StorageCost:** 0 LOAD(variable) - **Description:** Loads a variable previously stored in the blockchain using STORE function. Return type depends on what is stored. It panics if the value does NOT exist. - **Return Type:** Uint64/String (depending on what is stored) - **ComputeCost:** 5000 - **StorageCost:** 0 - **Syntax:** EXISTS(variable) - **Description:** Returns 1 if the variable is stored in the database via STORE and 0 otherwise. - **Return Type:** Uint64 - **ComputeCost:** 5000 - **StorageCost:** 0 - **Syntax:** STORE(key variable, value variable) - **Description:** Stores key and value in the database. All storage state of the smart contract is accessible only from the smart contract which created it. Returns 1. - **Return Type:** Uint64 - **ComputeCost:** 10000 - **StorageCost:** 0 - **Syntax:** DELETE(variable) - **Description:** Sets the rawkey value to []byte{} effectively deleting it from storage. Returns 1. - **Return Type:** Uint64 - **ComputeCost:** 3000 - **StorageCost:** 0 MAPEXISTS(variable) - **Description:** Returns 1 if the variable has been stored in RAM (current invoke session) via MAPSTORE and 0 otherwise. - **Return Type:** Uint64 - **ComputeCost:** 1000 - **StorageCost:** 0 MAPGET(variable) - **Description:** Loads a variable previously stored in RAM (current invoke session) via MAPSTORE. Return type depends on what is stored. It panics if the value does NOT exist. - **Return Type:** Uint64/String (depending on what is stored) - **ComputeCost:** 1000 - **StorageCost:** 0 MAPSTORE(key variable, value variable) - **Description:** Stores key and value in RAM (current invoke session). All MAPSTORE state is accessible only from the session in which it is stored. Returns 1. - **Return Type:** Uint64 - **ComputeCost:** 1000 - **StorageCost:** 0 MAPDELETE(variable) - **Description:** Deletes the element from the map in RAM (current invoke session). If the key does not exist, delete has no action. Returns 1. - **Return Type:** Uint64 - **ComputeCost:** 1000 - **StorageCost:** 0 RANDOM(limit Uint64) - **Description:** RANDOM returns a random number using a PRNG seeded on BLID, SCID, TXID. The first form gives a uint64, the second form returns a random number in the range 0 - (limit), 0 is inclusive, limit is exclusive. - **Return Type:** Uint64 - **ComputeCost:** 2500 - **StorageCost:** 0 - **Syntax:** SCID() - **Description:** Returns SMART CONTRACT ID which is currently running. - **Return Type:** String - **ComputeCost:** 2000 - **StorageCost:** 0 BLID() - **Description:** Returns current BLOCK ID which contains the current execution-in-progress TXID. - **Return Type:** String - **ComputeCost:** 2000 - **StorageCost:** 0 TXID() - **Description:** Returns current TXID which is execution-in-progress. - **Return Type:** String - **ComputeCost:** 2000 - **StorageCost:** 0 DERO() - **Description:** Returns a string representation of zerohash which is of type crypto.Hash. - **Return Type:** String - **ComputeCost:** 10000 - **StorageCost:** 0 BLOCK_HEIGHT() - **Description:** Returns current chain height of BLID(). - **Return Type:** Uint64 - **ComputeCost:** 2000 - **StorageCost:** 0 BLOCK_TIMESTAMP() - **Description:** Returns current timestamp of BLID(). - **Return Type:** Uint64 - **ComputeCost:** 2500 - **StorageCost:** 0 SIGNER() - **Description:** Returns the address of who signed/sent this transaction. Ringsize of tx must be 2 for this value to be known or else empty. SIGNER() returns the raw address. - **Return Type:** String - **ComputeCost:** 5000 - **StorageCost:** 0 - **Syntax:** UPDATE_SC_CODE(sc_code String) - **Description:** Stores updated SC code of type string. If it is not of type string, return 0, else return 1. - **Return Type:** Uint64 - **ComputeCost:** 5000 - **StorageCost:** 0 IS_ADDRESS_VALID(address String) - **Description:** Returns 1 if address is valid, 0 otherwise. - **Return Type:** Uint64 - **ComputeCost:** 50000 - **StorageCost:** 0 ADDRESS_RAW(address String) - **Description:** Returns address in RAW form as 33 byte keys, stripping away textual/presentation form. Two addresses should always be compared in RAW form. - **Return Type:** String - **ComputeCost:** 60000 - **StorageCost:** 0 ADDRESS_STRING(p String) - **Description:** Returns address in STRING form. If it can be evaluated, a string form of an address will be returned, otherwise, return an empty string. - **Return Type:** String - **ComputeCost:** 50000 - **StorageCost:** 0 SEND_DERO_TO_ADDRESS(a String, amount Uint64) - **Description:** Sends amount DERO from SC DERO balance to an address which should be in raw form. Address must be in string DERO/DETO form. If the SC does not have enough balance, it will panic. - **Return Type:** Uint64 - **ComputeCost:** 70000 - **StorageCost:** 0 SEND_ASSET_TO_ADDRESS(a String, amount Uint64, asset String) - **Description:** Sends amount ASSET from SC ASSET balance to an address which should be in raw form. Address must be in string DERO/DETO form. If the SC does not have enough balance, it will panic. - **Return Type:** Uint64 - **ComputeCost:** 90000 - **StorageCost:** 0 DEROVALUE() - **Description:** Gets the amount of DERO sent within this transaction. - **Return Type:** Uint64 - **ComputeCost:** 10000 - **StorageCost:** 0 ASSETVALUE(asset String) - **Description:** Gets the amount of a given ASSET sent within this transaction. - **Return Type:** Uint64 - **ComputeCost:** 10000 - **StorageCost:** 0 ATOI(s String) - **Description:** Returns a Uint64 representation of a string. Else, panic. - **Return Type:** Uint64 - **ComputeCost:** 5000 - **StorageCost:** 0 ITOA(n Uint64) - **Description:** Returns string representation of a Uint64. Else, panic. - **Return Type:** String - **ComputeCost:** 5000 - **StorageCost:** 0 SHA256(s String) - **Description:** Returns a string sha2-256 hash of a given string. Else, panic. - **Return Type:** String - **ComputeCost:** 25000 - **StorageCost:** 0 SHA3256(s String) - **Description:** Returns a string sha3-256 hash of a given string. Else, panic. - **Return Type:** String - **ComputeCost:** 25000 - **StorageCost:** 0 KECCAK256(s String) - **Description:** Returns a string sha3-keccak256 hash of a given string. Else, panic. - **Return Type:** String - **ComputeCost:** 25000 - **StorageCost:** 0 HEX(s String) - **Description:** Returns a hex encoded string value of a given string. Else, panic. - **Return Type:** String - **ComputeCost:** 10000 - **StorageCost:** 0 HEXDECODE(s String) - **Description:** Returns a hex decoded string value of a given hex string. Else, panic. - **Return Type:** String - **ComputeCost:** 10000 - **StorageCost:** 0 MIN(f Uint64, s Uint64) - **Description:** Returns the minimum value of 2 Uint64 values. Else, panic. - **Return Type:** Uint64 - **ComputeCost:** 5000 - **StorageCost:** 0 MAX(f Uint64, s Uint64) - **Description:** Returns the maximum value of 2 Uint64 values. Else, panic. - **Return Type:** Uint64 - **ComputeCost:** 5000 - **StorageCost:** 0 STRLEN(s String) - **Description:** Returns the length of a given string in Uint64. Else, panic. - **Return Type:** Uint64 - **ComputeCost:** 20000 - **StorageCost:** 0 SUBSTR(s String, offset Uint64, length Uint64) - **Description:** Returns the substring of a given string with offset and length defined. Else, panic. - **Return Type:** String - **ComputeCost:** 20000 - **StorageCost:** 0 PANIC - **Description:** Panics. - **Return Type:** Panic - **ComputeCost:** 10000 - **StorageCost:** 0 More about DVM-Basic here: Explaining DVM-Basic --- Execution Limits & Constraints The DVM enforces hard limits to ensure deterministic execution and prevent abuse. Exceeding any of these causes the contract call to panic and revert. | Limit | Value | Source | |-------|-------|--------| | **Interpreted lines per call** | 2,000 | dvm/dvm.go LIMIT_interpreted_lines | | **Expression evaluations per call** | 11,000 | dvm/dvm.go LIMIT_evals | | **Compute gas per call** | 10,000,000 | dvm/sc.go GasComputeLimit | | **Max storage gas per TX** | 20,000 atomic units | config/config.go MAX_STORAGE_GAS_ATOMIC_UNITS | | **String concatenation** | 1 MiB total | Panics if len(a) + len(b) >= 1,048,576 | | **Line numbers** | 1 to 2^64 − 2 | 0 and MaxUint64 are invalid | | **Line number order** | Strictly ascending | Duplicate or out-of-order lines are rejected at parse time | | **Nested functions** | Not allowed | Parser rejects Function inside another function | **The 2,000-line and 11,000-eval limits are per function call, not per contract.** A contract can have many functions, but each individual invocation must complete within these bounds. Design complex logic across multiple calls rather than one monolithic function. --- Related Pages **Learn the Language:** - DVM-BASIC Programming Guide - Complete language reference - Smart Contract Examples - Full code examples **Privacy Features:** - Private Smart Contracts - How contract privacy works - Homomorphic Encryption - Encrypted state storage **Build & Deploy:** - Token Contract Tutorial - Step-by-step guide - Wallet RPC API - Deploy via RPC - Daemon RPC API - Query contract state **Technical Details:** - Golang Performance - Why DVM is fast - DERO Tokens - Understanding asset transfers",
+      "plainText": "DERO Virtual Machine (DVM) DERO Virtual Machine represents the entire DERO Smart Contracts eco-system which runs on the DERO blockchain. DVM is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference. DERO's unique innovation is that tokens issued by smart contracts become encrypted balances in user wallets through homomorphic encryption. While contract code and state remain public and auditable, token balances and transfer amounts are completely private. Smart Contracts are nothing but rules which apply on transacting parties. Current version of DVM is an interpreter based system to avoid security vulnerabilities, issues and compiler backdoors. This also allows easy audits of Smart Contracts for quality, bug-testing and security assurances. DVM supports a new language DVM-BASIC. DVM apps run on a from scratch custom built privacy supporting, encrypted blockchain, an enormously powerful shared global infrastructure that can move value around and represent the ownership of assets/property without leaking any information. No one knows who owns what and who transferred to whom. - This enables developers to create puzzles, games, voting, markets, store registries of debts or promises, move funds in accordance with instructions given long in the past (like a will or a futures contract) and many other ideas/things that have not been invented yet, all without a middleman or counterparty risk. - DVM-BASIC is a contract-oriented, high-level language for implementing smart contracts. It is influenced by GW-BASIC, Visual Basic and C and is designed to target the DERO Virtual Machine (DVM). It is very easy to program and very readable. - DVM runs Smart Contracts which are a collection of functions written in DVM-BASIC. These functions can be invoked over the blockchain to do something. Each smart contract is currently self-contained — cross-contract calls are architecturally planned but not yet enabled. - DVM supports a number of comment formats such as ', //, /* */ as good documentation is necessary. DVM-Basic DVM Example Factorial program ' This is a comment // This comment is supported /* this is multi-line comment */ Function Factorial(s Uint64) Uint64 // this is a comment 10 DIM result,scopy as Uint64 /* this is also comment */ 15 LET scopy = s 20 LET result = 1 30 LET result = result * s 40 LET s = s - 1 50 IF s >= 2 THEN GOTO 30 70 RETURN result End Function - DVM smart contracts are written in a DVM-BASIC custom BASIC style language with line numbers. - DVM supports uint64 and string data types. - DVM interprets the smart contract and processes it line by line. - uint64 supports almost all operators, namely +, -, *, /, %. - uint64 supports the following bitwise operators: &, |, ^, !, >>, , >=, = 1,048,576 | | **Line numbers** | 1 to 2^64 − 2 | 0 and MaxUint64 are invalid | | **Line number order** | Strictly ascending | Duplicate or out-of-order lines are rejected at parse time | | **Nested functions** | Not allowed | Parser rejects Function inside another function | **The 2,000-line and 11,000-eval limits are per function call, not per contract.** A contract can have many functions, but each individual invocation must complete within these bounds. Design complex logic across multiple calls rather than one monolithic function. --- Related Pages **Learn the Language:** - DVM-BASIC Programming Guide - Complete language reference - Smart Contract Examples - Full code examples **Privacy Features:** - Private Smart Contracts - How contract privacy works - Homomorphic Encryption - Encrypted state storage **Build & Deploy:** - Token Contract Tutorial - Step-by-step guide - Wallet RPC API - Deploy via RPC - Daemon RPC API - Query contract state **Technical Details:** - Golang Performance - Why DVM is fast - DERO Tokens - Understanding asset transfers",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -321,6 +440,7 @@
         "DVM-BASIC Programming Guide",
         "Language Features",
         "Quick Start",
+        "Authorization patterns",
         "Data Types & Variables",
         "Operators",
         "Control Flow",
@@ -337,7 +457,7 @@
         "Learn More",
         "Related Pages"
       ],
-      "plainText": "DVM-BASIC Programming Guide DVM-BASIC is DERO's smart contract programming language - a blockchain-optimized BASIC variant that's easy to learn yet powerful enough for complex dApps with privacy features. **Source:** dvm/ - Virtual Machine implementation Language Features - Line-numbered syntax (like GW-BASIC) - Strong typing: Uint64 and String - Built-in blockchain functions - Privacy-preserving operations - Deterministic execution Quick Start Data Types & Variables | Type | Range | Default | Usage | |------|-------|---------|-------| | Uint64 | 0 to 18,446,744,073,709,551,615 | 0 | Numbers, balances, counts | | String | Variable (size limits apply) | \"\" | Text, addresses, keys | **Declare variables:** Operators | Type | Operators | |------|-----------| | **Arithmetic** | + - * / % | | **Bitwise** | & \\| ^ ! >> << | | **Comparison** | > >= < <= == != | | **String** | + (concat), ==, != | Control Flow **IF-THEN-ELSE:** **Loops with GOTO:** Comments Functions **Syntax:** **Visibility:** - **Uppercase** first letter → Public (callable externally) - **Lowercase** first letter → Private (internal only) **Return values:** - 0 = success - Non-zero = error code Blockchain Functions State Management | Function | Purpose | |----------|---------| | STORE(key, value) | Save to blockchain state | | LOAD(key) | Read from blockchain state | | EXISTS(key) | Check if key exists | Identity & Transaction | Function | Purpose | |----------|---------| | SIGNER() | Get transaction sender address | | TXID() | Get current transaction ID | | ADDRESS_RAW(string) | Convert address string to raw format | | IS_ADDRESS_VALID(string) | Validate address format | Asset Operations | Function | Purpose | |----------|---------| | SEND_DERO_TO_ADDRESS(addr, amount) | Transfer DERO | | SEND_ASSET_TO_ADDRESS(addr, amount, scid) | Transfer asset/token | | DEROVALUE() | Get DERO sent in transaction | | ASSETVALUE(scid) | Get asset sent in transaction | Blockchain Info | Function | Purpose | |----------|---------| | BLOCK_HEIGHT() | Current block height | | BLOCK_TIMESTAMP() | Current block timestamp | | SCID() | This contract's ID | Cryptographic | Function | Purpose | |----------|---------| | SHA256(data) | Compute SHA256 hash | | KECCAK256(data) | Compute Keccak256 hash | Best Practices 1. **Security** - Always validate inputs and permissions 2. **Gas efficiency** - Minimize STORE/LOAD operations 3. **Line spacing** - Use increments of 10 for future insertions 4. **Error codes** - Return meaningful error codes 5. **Testing** - Use Simulator before deployment Example: Token Contract Learn More - DERO Virtual Machine - DVM architecture - Token Contract Tutorial - Build a full token - Smart Contract Examples - More examples **Tip:** The DVM-BASIC language evolves with DERO. Check official docs for updates! --- Related Pages **Smart Contract Examples:** - Token Contract - Build a private token - Assets Exchange - Token swap contract - Lottery Contract - Decentralized lottery - Name Service - Register usernames **Understanding the DVM:** - DERO Virtual Machine - DVM architecture - Private Smart Contracts - Contract privacy features **Deploy & Test:** - Wallet RPC API - Deploy contracts programmatically - Running a Node - Setup testnet for development",
+      "plainText": "DVM-BASIC Programming Guide DVM-BASIC is DERO's smart contract programming language - a blockchain-optimized BASIC variant that's easy to learn yet powerful enough for complex dApps with privacy features. **Source:** dvm/ - Virtual Machine implementation Language Features - Line-numbered syntax (like GW-BASIC) - Strong typing: Uint64 and String - Built-in blockchain functions - Privacy-preserving operations - Deterministic execution Quick Start Authorization patterns SIGNER() returns the wallet address that sent the current transaction — Captain's words: *\"may not be the owner of the SC.\"* It coincides with the owner during Initialize (canonical pattern below) but on every other call you must check explicitly. If your contract has no stored-owner gate, anyone can call UpdateCode and overwrite your logic — the DVM does not gate UpdateCode at the protocol level. > SIGNER() -> its the wallet adress which is sending this TX. It may not be the owner of the SC. Please install owner address in DB during SC install. If you have no owner stored & verification anyone can update your SC. > > — Captain, 2021-02-24, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/813933195850416168); verified · Release 142: dvm/dvm_functions.go (dvm_signer, dvm_update_sc_code — // TODO verify code authenticity how) The canonical pattern: store the owner during Initialize, then gate every privileged function with IF LOAD(\"owner\") == SIGNER() THEN .... Without line 10, anyone can call UpdateOwner and seize the contract. Data Types & Variables | Type | Range | Default | Usage | |------|-------|---------|-------| | Uint64 | 0 to 18,446,744,073,709,551,615 | 0 | Numbers, balances, counts | | String | Variable (size limits apply) | \"\" | Text, addresses, keys | **Declare variables:** Operators | Type | Operators | |------|-----------| | **Arithmetic** | + - * / % | | **Bitwise** | & \\| ^ ! >> >= < <= == != | | **String** | + (concat), ==, != | Control Flow **IF-THEN-ELSE:** **Loops with GOTO:** Comments Functions **Syntax:** **Visibility:** - **Uppercase** first letter → Public (callable externally) - **Lowercase** first letter → Private (internal only) **Return values:** - 0 = success - Non-zero = error code Blockchain Functions State Management | Function | Purpose | |----------|---------| | STORE(key, value) | Save to blockchain state | | LOAD(key) | Read from blockchain state | | EXISTS(key) | Check if key exists | Identity & Transaction | Function | Purpose | |----------|---------| | SIGNER() | Get transaction sender address | | TXID() | Get current transaction ID | | ADDRESS_RAW(string) | Convert address string to raw format | | IS_ADDRESS_VALID(string) | Validate address format | Asset Operations | Function | Purpose | |----------|---------| | SEND_DERO_TO_ADDRESS(addr, amount) | Transfer DERO | | SEND_ASSET_TO_ADDRESS(addr, amount, scid) | Transfer asset/token | | DEROVALUE() | Get DERO sent in transaction | | ASSETVALUE(scid) | Get asset sent in transaction | Blockchain Info | Function | Purpose | |----------|---------| | BLOCK_HEIGHT() | Current block height | | BLOCK_TIMESTAMP() | Current block timestamp | | SCID() | This contract's ID | Cryptographic | Function | Purpose | |----------|---------| | SHA256(data) | Compute SHA256 hash | | KECCAK256(data) | Compute Keccak256 hash | Best Practices 1. **Security** - Always validate inputs and permissions 2. **Gas efficiency** - Minimize STORE/LOAD operations 3. **Line spacing** - Use increments of 10 for future insertions 4. **Error codes** - Return meaningful error codes 5. **Testing** - Use Simulator before deployment Example: Token Contract Learn More - DERO Virtual Machine - DVM architecture - Token Contract Tutorial - Build a full token - Smart Contract Examples - More examples **Tip:** The DVM-BASIC language evolves with DERO. Check official docs for updates! --- Related Pages **Smart Contract Examples:** - Token Contract - Build a private token - Assets Exchange - Token swap contract - Lottery Contract - Decentralized lottery - Name Service - Register usernames **Understanding the DVM:** - DERO Virtual Machine - DVM architecture - Private Smart Contracts - Contract privacy features **Deploy & Test:** - Wallet RPC API - Deploy contracts programmatically - Running a Node - Setup testnet for development",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -582,6 +702,7 @@
         "TLS over KCP/UDP",
         "TLS Implementation",
         "Self-Signed Certificates",
+        "Why HTTPS is intentionally absent from RPC",
         "ECDSA vs RSA Choice",
         "Performance Comparison",
         "UDP vs TCP",
@@ -609,7 +730,7 @@
         "Key Takeaways",
         "Further Reading"
       ],
-      "plainText": "TLS-Encrypted P2P Network Encrypted Network DERO is the first blockchain to use **TLS-encrypted UDP** for all P2P network communication, protecting against eavesdropping and tampering while maintaining high performance. **Innovation:** Self-signed TLS certificates over KCP/UDP provide privacy without certificate authorities or trusted third parties. --- Why Network Encryption Matters **Without encryption (Bitcoin, Ethereum):** **With TLS encryption (DERO):** --- DERO's Network Architecture TLS over KCP/UDP | Layer | Technology | Purpose | |-------|-----------|---------| | **Transport** | UDP | Low latency, reduced kernel exposure | | **Reliability** | KCP | Reliable delivery over UDP | | **Encryption** | TLS | Confidentiality and integrity | | **Authentication** | Self-signed certs | No central authority | **Source:** p2p/controller.go:34-35, 48, 609 --- TLS Implementation Self-Signed Certificates Simplified from source — see p2p/tlsconfig.go for full implementation (p2p/controller.go:717-776): **Why self-signed?** - ✅ No certificate authorities (decentralized) - ✅ Each node generates own cert - ✅ No trusted third parties - ✅ Prevents network-level eavesdropping --- ECDSA vs RSA Choice Performance Comparison **From source code comments** (p2p/controller.go:721-734): | Algorithm | Handshakes/Second | DERO's Choice | |-----------|------------------|---------------| | **RSA** | ~500 | ❌ Too slow | | **ECDSA P256** | ~20,000 | ✅ Used | **Why this matters:** - Enterprise services handle thousands of connections/second - Fast handshakes = better scalability - 40× performance improvement --- UDP vs TCP Why DERO Uses UDP | Aspect | TCP | UDP (with KCP) | |--------|-----|----------------| | **Network Overhead** | Higher | Lower | | **Kernel Exposure** | More syscalls | Fewer syscalls | | **Latency** | Higher | Lower | | **Reliability** | Built-in | KCP adds it | | **For Blockchain** | Slower propagation | Faster propagation | **KCP (UDP-based reliability):** - Provides TCP-like reliability over UDP - Lower latency than TCP - Configurable for blockchain needs - Used by many high-performance systems **Source:** p2p/controller.go:48 - github.com/xtaci/kcp-go/v5 --- Network Privacy Stack --- What TLS Protects **Network-Level Attacks Prevented:** | Attack | Without TLS | With TLS | |--------|-------------|----------| | **Eavesdropping** | ISP sees all data | ✅ Only sees encrypted packets | | **Tampering** | Can modify packets | ✅ Detected and rejected | | **Traffic Analysis** | Can identify TX types | ⚠️ Timing still visible | | **MITM** | Possible | ⚠️ Not prevented (no cert verification) | **What TLS does NOT hide (network layer metadata):** - ⚠️ Your IP address (visible at network layer) - ⚠️ Packet sizes (observable by network) - ⚠️ Connection timing (metadata analysis) - ⚠️ That you're using DERO (traffic patterns) *Note: These limitations apply to ALL TLS implementations (network layer metadata is below TLS's encryption layer)* **Additional privacy:** DERO supports SOCKS proxy (for Tor/other proxies): **Note:** VPN would hide DERO usage from ISP, but is NOT configurable via daemon (system-level). --- Network Configuration **Default ports:** **Firewall rules:** **Source:** config/config.go - Network port constants --- Key Advantages **1. Privacy** - ✅ ISP cannot read network traffic - ✅ Government cannot inspect packets - ✅ No plaintext transaction broadcasts **2. Security** - ✅ Prevents packet tampering - ✅ Authenticates peers - ✅ Protects integrity **3. Performance** - ✅ Fast handshakes (20,000/sec with ECDSA) - ✅ Low latency (UDP-based) - ✅ Efficient propagation **4. Decentralization** - ✅ No certificate authorities - ✅ Self-signed certs - ✅ No central trust point --- Comparison with Other Blockchains | Blockchain | Network Encryption | Protocol | Performance | |------------|-------------------|----------|-------------| | **Bitcoin** | ✅ BIP 324 (v2 transport, since Core 26.0) | TCP | Slower, public | | **Ethereum** | ✅ RLPx (ECIES encrypted transport) | TCP | Slower, public | | **Other Privacy Coins** | ⚠️ Varies by implementation | TCP | Slower, public | | **DERO** | ✅ TLS | UDP/KCP | Faster, private | **DERO = Only blockchain with encrypted P2P layer** --- Technical Implementation Connection Flow **Source code:** - TLS setup: p2p/controller.go:551, 609 - Outgoing: p2p/controller.go:398 - tls.Client(conn, &tls.Config{InsecureSkipVerify: true}) - Incoming: p2p/controller.go:609 - tls.Server(conn, tlsconfig) --- Limitations & Mitigations **What TLS Encrypts:** - ✅ All packet contents - ✅ Transaction data - ✅ Block data - ✅ Peer communications **What TLS Does NOT Hide:** - ⚠️ That you're using DERO - ⚠️ Connection timing - ⚠️ Packet sizes - ⚠️ Your IP address **Additional Privacy Layers:** --- Key Takeaways **DERO's encrypted network provides:** - ✅ **TLS encryption** - All P2P traffic encrypted - ✅ **UDP/KCP protocol** - Fast, low latency - ✅ **ECDSA certificates** - 20,000 handshakes/sec (40× faster than RSA) - ✅ **Self-signed** - No certificate authorities - ✅ **Privacy** - ISP cannot read network data - ✅ **Security** - Tampering detected and prevented **Note:** TLS protects network layer. For complete privacy, DERO also uses ring signatures (sender), homomorphic encryption (amounts), and bulletproofs (validation). --- Further Reading - Transaction Privacy - How all privacy layers work together - Running a Node - Setup your own node - DERO Daemon - Understanding daemon operations **Source Code:** - Network implementation: p2p/controller.go - TLS cert generation: p2p/controller.go:717-776 - KCP/UDP: github.com/xtaci/kcp-go/v5",
+      "plainText": "TLS-Encrypted P2P Network Encrypted Network DERO is the first blockchain to use **TLS-encrypted UDP** for all P2P network communication, protecting against eavesdropping and tampering while maintaining high performance. **Innovation:** Self-signed TLS certificates over KCP/UDP provide privacy without certificate authorities or trusted third parties. --- Why Network Encryption Matters **Without encryption (Bitcoin, Ethereum):** **With TLS encryption (DERO):** --- DERO's Network Architecture TLS over KCP/UDP | Layer | Technology | Purpose | |-------|-----------|---------| | **Transport** | UDP | Low latency, reduced kernel exposure | | **Reliability** | KCP | Reliable delivery over UDP | | **Encryption** | TLS | Confidentiality and integrity | | **Authentication** | Self-signed certs | No central authority | **Source:** p2p/controller.go:34-35, 48, 609 --- TLS Implementation Self-Signed Certificates Simplified from source — see p2p/tlsconfig.go for full implementation (p2p/controller.go:717-776): **Why self-signed?** - ✅ No certificate authorities (decentralized) - ✅ Each node generates own cert - ✅ No trusted third parties - ✅ Prevents network-level eavesdropping --- Why HTTPS is intentionally absent from RPC Every integrator who looks at the DERO daemon eventually asks: \"why doesn't derod ship HTTPS on the RPC port?\" The answer is two-part, and Captain has stated it directly: > https is not supported intentionally. HTTPS gives false sense of security as certificate issuer has the private key to decrypt the traffic. And issuer can share the private-keys to others also when required. https can only help with local ISP/telecom sniffing, In that case use vpn etc.. > > — Captain, 2022-12-21, #technical-questions (https://discord.com/channels/419781880632836096/419798461039509504/1054919216400175104); verified · Release 142: cmd/derod/rpc/websocket_server.go:241 (daemon RPC plain ListenAndServe); walletapi/rpcserver/rpc_websocket_server.go:266 (wallet RPC plain ListenAndServe) **The two arguments unpacked:** 1. **HTTPS as a trust model is compromised by design.** A public CA can mint a valid certificate for any domain it wants (sometimes under legal compulsion, sometimes through compromise) and from that point, any \"encrypted\" HTTPS session can be silently intercepted. The padlock icon does not mean the traffic is private from the CA, only that it's private from passive sniffers on the wire. 2. **VPN is the right tool for the only legitimate HTTPS use case.** If your concern is local ISP / telecom / coffee-shop wifi sniffing, a VPN solves it at the transport layer — without inheriting the CA-as-trusted-third-party problem. RPC traffic should already be on a trusted bus (127.0.0.1, a private VPN, an SSH tunnel, WireGuard). The architectural pattern that follows from this: | Port | Protocol | Encryption | Why | |---|---|---|---| | P2P (10101) | TLS over KCP/UDP | **Self-signed TLS** (per the section above) | Nodes talk across the public internet; encryption is required, but CAs are unwanted | | Daemon RPC (10102) | Plain HTTP | None (local trust) | Designed for 127.0.0.1 traffic; if you tunnel it, the tunnel provides encryption | | Wallet RPC (10103) | Plain HTTP | None (local trust) | Same model as daemon RPC | If you need to expose RPC over a network, **don't add HTTPS to derod** — put it behind an authenticated TLS terminator you control (nginx, Caddy, an SSH tunnel, WireGuard). The threat model assumes the RPC port is on a trusted bus, and the encryption decision is delegated to whatever transport you choose to expose it over. --- ECDSA vs RSA Choice Performance Comparison **From source code comments** (p2p/controller.go:721-734): | Algorithm | Handshakes/Second | DERO's Choice | |-----------|------------------|---------------| | **RSA** | ~500 | ❌ Too slow | | **ECDSA P256** | ~20,000 | ✅ Used | **Why this matters:** - Enterprise services handle thousands of connections/second - Fast handshakes = better scalability - 40× performance improvement --- UDP vs TCP Why DERO Uses UDP | Aspect | TCP | UDP (with KCP) | |--------|-----|----------------| | **Network Overhead** | Higher | Lower | | **Kernel Exposure** | More syscalls | Fewer syscalls | | **Latency** | Higher | Lower | | **Reliability** | Built-in | KCP adds it | | **For Blockchain** | Slower propagation | Faster propagation | **KCP (UDP-based reliability):** - Provides TCP-like reliability over UDP - Lower latency than TCP - Configurable for blockchain needs - Used by many high-performance systems **Source:** p2p/controller.go:48 - github.com/xtaci/kcp-go/v5 --- Network Privacy Stack --- What TLS Protects **Network-Level Attacks Prevented:** | Attack | Without TLS | With TLS | |--------|-------------|----------| | **Eavesdropping** | ISP sees all data | ✅ Only sees encrypted packets | | **Tampering** | Can modify packets | ✅ Detected and rejected | | **Traffic Analysis** | Can identify TX types | ⚠️ Timing still visible | | **MITM** | Possible | ⚠️ Not prevented (no cert verification) | **What TLS does NOT hide (network layer metadata):** - ⚠️ Your IP address (visible at network layer) - ⚠️ Packet sizes (observable by network) - ⚠️ Connection timing (metadata analysis) - ⚠️ That you're using DERO (traffic patterns) *Note: These limitations apply to ALL TLS implementations (network layer metadata is below TLS's encryption layer)* **Additional privacy:** DERO supports SOCKS proxy (for Tor/other proxies): **Note:** VPN would hide DERO usage from ISP, but is NOT configurable via daemon (system-level). --- Network Configuration **Default ports:** **Firewall rules:** **Source:** config/config.go - Network port constants --- Key Advantages **1. Privacy** - ✅ ISP cannot read network traffic - ✅ Government cannot inspect packets - ✅ No plaintext transaction broadcasts **2. Security** - ✅ Prevents packet tampering - ✅ Authenticates peers - ✅ Protects integrity **3. Performance** - ✅ Fast handshakes (20,000/sec with ECDSA) - ✅ Low latency (UDP-based) - ✅ Efficient propagation **4. Decentralization** - ✅ No certificate authorities - ✅ Self-signed certs - ✅ No central trust point --- Comparison with Other Blockchains | Blockchain | Network Encryption | Protocol | Performance | |------------|-------------------|----------|-------------| | **Bitcoin** | ✅ BIP 324 (v2 transport, since Core 26.0) | TCP | Slower, public | | **Ethereum** | ✅ RLPx (ECIES encrypted transport) | TCP | Slower, public | | **Other Privacy Coins** | ⚠️ Varies by implementation | TCP | Slower, public | | **DERO** | ✅ TLS | UDP/KCP | Faster, private | **DERO = Only blockchain with encrypted P2P layer** --- Technical Implementation Connection Flow **Source code:** - TLS setup: p2p/controller.go:551, 609 - Outgoing: p2p/controller.go:398 - tls.Client(conn, &tls.Config{InsecureSkipVerify: true}) - Incoming: p2p/controller.go:609 - tls.Server(conn, tlsconfig) --- Limitations & Mitigations **What TLS Encrypts:** - ✅ All packet contents - ✅ Transaction data - ✅ Block data - ✅ Peer communications **What TLS Does NOT Hide:** - ⚠️ That you're using DERO - ⚠️ Connection timing - ⚠️ Packet sizes - ⚠️ Your IP address **Additional Privacy Layers:** --- Key Takeaways **DERO's encrypted network provides:** - ✅ **TLS encryption** - All P2P traffic encrypted - ✅ **UDP/KCP protocol** - Fast, low latency - ✅ **ECDSA certificates** - 20,000 handshakes/sec (40× faster than RSA) - ✅ **Self-signed** - No certificate authorities - ✅ **Privacy** - ISP cannot read network data - ✅ **Security** - Tampering detected and prevented **Note:** TLS protects network layer. For complete privacy, DERO also uses ring signatures (sender), homomorphic encryption (amounts), and bulletproofs (validation). --- Further Reading - Transaction Privacy - How all privacy layers work together - Running a Node - Setup your own node - DERO Daemon - Understanding daemon operations **Source Code:** - Network implementation: p2p/controller.go - TLS cert generation: p2p/controller.go:717-776 - KCP/UDP: github.com/xtaci/kcp-go/v5",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -786,7 +907,7 @@
         "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: **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",
+      "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 | |-------------------|-----------------|--------| | ** **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"
     },
     {
@@ -835,8 +956,8 @@
         "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"
+      "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. Read the chain directly and what you see is an **ordinary transfer of coins the sender 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. Read the chain directly and what you see is an **ordinary transfer of coins the sender 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, or to a privacy-first client like OpenCode or Goose running on a local model via Ollama. Either way it finds a node automatically: your own if you're running one, 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/mcp, 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-31"
     },
     {
       "product": "derod",
@@ -857,7 +978,7 @@
         "Why this cannot be bypassed",
         "Related Pages"
       ],
-      "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",
+      "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 --- 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 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"
     },
     {
@@ -939,7 +1060,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-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",
+      "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 --- 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"
     },
     {
@@ -1183,6 +1304,7 @@
         "Lightweight Clients Possible",
         "Privacy Guarantees",
         "What Account Model Doesn't Compromise",
+        "What a verified DERO-PROOF reveals",
         "Why DERO's Approach Works",
         "The Account Model Advantage",
         "What Makes DERO Unique",
@@ -1191,7 +1313,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: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",
+      "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. What a verified DERO-PROOF reveals The privacy guarantees above are the **defaults** — what the chain hides from every observer. DERO also gives the sender a per-transaction escape hatch: the **DERO-PROOF** (a.k.a. *DERO proof* or *transaction proof* elsewhere in these docs — same thing, single canonical wire-format string). By sharing the proof string for one specific transaction, the sender lets a verifier confirm what was sent to whom — on-chain equivalent of handing someone a receipt. A verified DERO-PROOF on the public explorer surfaces exactly three fields: | Field | What it reveals | |---|---| | **Receiver address** | The dero1q... that was paid. **The sender remains hidden in the ring.** | | **Amount** | Exact DERO transferred, in standard units | | **Memo / decoded payload** | The optional comment field from the transfer, if one was attached | The proof scheme is sender-driven: the sender holds the tx key, runs the proof tool, and hands the resulting string to whoever needs to verify the payment. The verifier resolves it against the on-chain transaction; the chain confirms that the named receiver was paid the named amount. **Source:** proof/proof.go (Prove() returns receivers, amounts, payload_raw, payload_decoded); cmd/explorer/explorerlib/explorerlib.go wires the result into the explorer UI; cmd/explorer/explorerlib/templates/tx.tmpl renders the verified-proof block as {receiver} Received {amount} DERO. Note: scope is one transaction at a time. A proof for tx-A reveals nothing about tx-B, even between the same parties. --- 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"
     },
     {
@@ -1218,7 +1340,7 @@
         "What You're Protected From",
         "Related Pages"
       ],
-      "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",
+      "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 **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 **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"
     },
     {
@@ -1253,7 +1375,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 **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",
+      "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. A common point of confusion: **ring size and amount privacy are independent properties.** The conservation above holds regardless of how many decoys the ring contains — the cryptographic reason amounts stay hidden has nothing to do with how many ring members there are. > Whatever the RingSize is set in DERO amounts are never revealed. > > — Captain, 2022-02-24, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/946298626005672016); verified · Release 142: walletapi/transaction_build.go (per-ring-member ElGamal commitment loop) — every commitment is blinded uniformly with the same random r, so sender (−value), receiver (+value), and decoy (0) commitments are indistinguishable regardless of ring size This is why ring size 2 — which removes *sender* anonymity by design — still leaves the *transferred amount* fully encrypted. The two privacy properties are decoupled. 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:** The 66 bytes referenced above are load-bearing — they are literally all a DERO wallet pulls from the network to operate. Captain on the wallet sync model: > There is no concept of any master private/secret key on DERO. DERO creates a elgamal balance ciphertext associated to any wallet-account. The private key is NOT broken or distributed among other nodes in any way or form. When user opens wallet, no communication with DERO network except 66 bytes are required. This process is completely done within wallet and is not linked with DERO network. As DERO is account model, Only 66 bytes are required by wallet from DERO blockchain to operate. Blocks & transactions are required to create & maintain history on DERO network. > > — Captain, 2022-12-08, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1050433141875155064); verified · Release 142: cryptography/crypto/algebra_elgamal.go (66-byte ElGamal codec — 33B Left ‖ 33B Right compressed G1 points); walletapi/daemon_communication.go (GetEncryptedBalanceAtTopoHeight) This is why DERO wallets **open in seconds** — to display your current balance the wallet pulls only the 66-byte ciphertext (GetEncryptedBalanceAtTopoHeight) and decrypts locally. Captain's quote above is explicit about the split: blocks and transactions *are* required to build and maintain history, so when balance changes the wallet binary-searches to the specific blocks where the change happened (walletapi/daemon_communication.go SyncHistory) — but that's bounded by activity, not by chain length. Traditional privacy-coin wallets that linearly scan every block don't have that shortcut. 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"
     },
     {
@@ -1333,6 +1455,7 @@
         "Ring Size Impact",
         "Real Example",
         "How Ring Members Are Selected",
+        "Roadmap: polymorphic ring selection",
         "The Parity Constraint: How the Ring Is Split",
         "The Rule",
         "Cryptographic Enforcement",
@@ -1347,7 +1470,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. **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",
+      "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 Roadmap: polymorphic ring selection The selection algorithm described above — uniform random sampling of recently-unchanged-balance addresses — is the current implementation, not the long-term design. Captain has signaled the wallet layer is targeted for *polymorphic* per-wallet selection logic so that no two wallets pick decoys the same way. > Also in free time wallet part will have new/modified code to handle more chain-analysis & some points discussed above. Wallet will have some polymorphic code & algo so that no single or two wallets work & selects ring members in same way single/everytime. Also users will be able to configure this part to their preferences. > > — Captain, 2022-12-08, #dero-discussion (https://discord.com/channels/419781880632836096/419781880632836098/1050436403042988153) No timeline has been published. The uniform algorithm above remains in force on Release 142. --- 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. Captain has stated explicitly that this collapse is **intentional** — ring size 2 is the opt-in mode for transactions where the sender wants to be mathematically provable (audit trails, exchange deposits, KYC reconciliation): > This is by design. By this you can prove sender mathematically. This is a feature not a bug. There may be some situations/applications when you need to reveal sender, In that case send TX by setting RingSize to 2. > > — Captain, 2021-11-20, #dero-he-testnet (https://discord.com/channels/419781880632836096/737351309396541471/911455371766407210); verified · Release 142: config/config.go:58 (MIN_RINGSIZE = 2); walletapi/daemon_communication.go:1067-1074 (// if ring size is 2, the other party is the sender so mark it so) In other words: the table above is correct that ring size 2 provides no sender anonymity — and that is the point. The sender is choosing to be derivable. Note: DERO-PROOF is a separate mechanism — it's a receiver-side receipt that reveals receiver+amount+payload and works at *any* ring size. See Account-Based Privacy → What a verified DERO-PROOF reveals. 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"
     },
     {
@@ -2368,7 +2491,7 @@
         "Payment Flow",
         "Mainnet Validation"
       ],
-      "plainText": "Payment Router Smart Contract The payment router contract is written in DERO's DVM-BASIC smart contract language. It receives payments and instantly forwards them to the merchant, with an optional fee split. Contract Functions | Function | Who Can Call | Description | |---|---|---| | Initialize | Deployer | Set up merchant, fee recipient, and fee rate | | Pay | Anyone | Send DERO through the router (splits to merchant + fee recipient) | | UpdateMerchant | Merchant | Change the merchant address | | Pause | Merchant | Stop accepting payments | | Resume | Merchant | Resume accepting payments | | WithdrawTrapped | Merchant | Recover any DERO accidentally trapped in the contract | | GetStats | Anyone | Returns totalProcessed | Roles - **Merchant** — The wallet that deploys the contract. Receives payment payouts. Can pause, resume, update their address, and withdraw trapped funds. - **Fee Recipient** — An optional address that receives a percentage of each payment. Set at deployment, cannot be changed. Deployment Model The payment router is deployed **once per merchant** and reused for every payment. The merchant deploys it from their own wallet and owns it permanently. This is the opposite of the escrow contract, which deploys a fresh instance per transaction. The deployer's wallet address automatically becomes the merchant. The contract stores aggregate statistics (totalProcessed, totalFees, paymentCount) that accumulate across all payments. Fee Splitting The contract supports an optional fee split in **basis points** (1 basis point = 0.01%): - Set at deployment via feeBasisPoints — immutable after deploy - Automatically deducted from every payment - Sent to the feeRecipient address - If feeBasisPoints is 0, no fee is taken (merchant receives 100%) Security Features The contract includes several hardened security measures: | Guard | Purpose | |-------|---------| | DEROVALUE() > 0 on non-payable functions | Prevents accidental DERO trapping | | feeBasisPoints <= 10000 | Fee cannot exceed 100% | | merchant != feeRecipient (when fee > 0) | Prevents misconfigured self-fee | | payout > 0 / fee > 0 guards | No zero-value transfers | | paused flag | Merchant can halt payments | | SIGNER() checks | Only merchant can call admin functions | | EXISTS(\"merchant\") | Prevents re-initialization | Payment Flow Mainnet Validation The payment router has been deployed and tested on DERO mainnet (2026-03-03): - Full cycle: deploy → pay (0.1 DERO) → verify split → pay (0.05 DERO) → verify accumulation - All funds forwarded correctly (SC balance = 0 after each payment) - Fee counters accumulated as expected - No trapped funds See TypeScript SDK for the programmatic interface.",
+      "plainText": "Payment Router Smart Contract The payment router contract is written in DERO's DVM-BASIC smart contract language. It receives payments and instantly forwards them to the merchant, with an optional fee split. Contract Functions | Function | Who Can Call | Description | |---|---|---| | Initialize | Deployer | Set up merchant, fee recipient, and fee rate | | Pay | Anyone | Send DERO through the router (splits to merchant + fee recipient) | | UpdateMerchant | Merchant | Change the merchant address | | Pause | Merchant | Stop accepting payments | | Resume | Merchant | Resume accepting payments | | WithdrawTrapped | Merchant | Recover any DERO accidentally trapped in the contract | | GetStats | Anyone | Returns totalProcessed | Roles - **Merchant** — The wallet that deploys the contract. Receives payment payouts. Can pause, resume, update their address, and withdraw trapped funds. - **Fee Recipient** — An optional address that receives a percentage of each payment. Set at deployment, cannot be changed. Deployment Model The payment router is deployed **once per merchant** and reused for every payment. The merchant deploys it from their own wallet and owns it permanently. This is the opposite of the escrow contract, which deploys a fresh instance per transaction. The deployer's wallet address automatically becomes the merchant. The contract stores aggregate statistics (totalProcessed, totalFees, paymentCount) that accumulate across all payments. Fee Splitting The contract supports an optional fee split in **basis points** (1 basis point = 0.01%): - Set at deployment via feeBasisPoints — immutable after deploy - Automatically deducted from every payment - Sent to the feeRecipient address - If feeBasisPoints is 0, no fee is taken (merchant receives 100%) Security Features The contract includes several hardened security measures: | Guard | Purpose | |-------|---------| | DEROVALUE() > 0 on non-payable functions | Prevents accidental DERO trapping | | feeBasisPoints 0) | Prevents misconfigured self-fee | | payout > 0 / fee > 0 guards | No zero-value transfers | | paused flag | Merchant can halt payments | | SIGNER() checks | Only merchant can call admin functions | | EXISTS(\"merchant\")` | Prevents re-initialization | Payment Flow Mainnet Validation The payment router has been deployed and tested on DERO mainnet (2026-03-03): - Full cycle: deploy → pay (0.1 DERO) → verify split → pay (0.05 DERO) → verify accumulation - All funds forwarded correctly (SC balance = 0 after each payment) - Fee counters accumulated as expected - No trapped funds See TypeScript SDK for the programmatic interface.",
       "lastUpdated": null
     },
     {
@@ -2743,7 +2866,7 @@
         "Version Pinning",
         "Benefits"
       ],
-      "plainText": "Offline-First Browsing Offline-First Browsing Hologram enables true offline-first TELA browsing. Clone your favorite dApps locally, cache them in Graviton storage, and access them instantly—no network, no Gnomon, no waiting. **Your data, your machine, your rules**. Once synced, TELA apps load from local storage with zero network latency. Combine with Privacy Mode for complete network isolation. Why Offline-First? | Traditional Web | Hologram Offline-First | |-----------------|------------------------| | Fetch from server every time | Cached locally in Graviton | | Requires network connection | Works completely offline | | Depends on external services | Self-sovereign operation | | Servers can go down | Content lives on your machine | | CDNs track your requests | Zero network fingerprinting | How It Works 1. **Favorite apps** in the Browser's app discovery 2. **Sync Manager** fetches and caches them locally (filtered by rating) 3. **Graviton storage** holds the cached content 4. **TELA Browser** loads instantly from local cache Getting Started Favorite Your Apps Browse TELA apps in the TELA Browser and click the heart icon to add them to your favorites. Favorites are stored locally and persist across sessions. Open Sync Manager Navigate to **Settings → Sync Manager** to access batch sync controls. Configure Rating Threshold Use the slider to set a minimum rating (0-99). Apps rated below this threshold will be skipped during sync—useful for filtering out low-quality or potentially malicious content. Sync Favorites Click **\"Sync Favorites\"** to batch-prefetch all favorited apps that meet your rating threshold. For each favorite app: 1. Resolve dURL to SCID 2. Check rating against threshold 3. If passes: fetch from blockchain → store in cache 4. If fails: skip Sync Manager Features Batch Prefetch Prefetch all favorites in one operation: Update Checking Compare all cached apps against their current on-chain versions: Update checking requires a connection to a DERO daemon to fetch current SC state. Once you've reviewed and accepted updates, you're back to fully offline operation. Visual Diffing Before updating, view exactly what changed: The diff viewer shows: - **Green (+)**: New lines added - **Red (-)**: Lines removed - **Yellow (~)**: Lines modified Selective Updates You're always in control: - Review diffs before updating - Update individual apps (not all-or-nothing) - Keep your preferred version indefinitely - Roll back by re-cloning at specific commit Offline Cache Management Settings → Offline Cache The Offline Cache Manager shows: | Stat | Description | |------|-------------| | **Cached Apps** | Number of apps stored locally | | **Files** | Total file count across all apps | | **Used** | Current cache size | | **Max Size** | Configurable limit (default 500MB) | Cache Behavior - **LRU Eviction**: Oldest-accessed apps are removed when space is needed - **Complete vs Partial**: Full app caches include all assets - **Version Tracking**: Each cached app tracks its blockchain version - **Content Hashing**: SHA256 verification ensures integrity API Reference Prefetch Query Manage Version Control Integration TELA's built-in commit system enables powerful version control: Cached Version Tracking Each cached app stores: Clone at Commit For filesystem access (vs Graviton cache), use Clone with version pinning: This downloads the exact version specified, regardless of current on-chain state. Security Considerations Rating Threshold The minimum rating filter provides a first-line defense: | Rating | Typical Meaning | |--------|-----------------| | 0-9 | Flagged as malicious | | 10-49 | Unverified/new apps | | 50-79 | Community-vetted | | 80-99 | Highly trusted | Ratings are community-driven and not a guarantee of safety. Always review diffs before updating and be cautious with apps from unknown developers. Content Verification - All cached content is fetched from immutable blockchain storage - Content hashes can verify integrity - Diffing shows exact changes before updating - You control when (and if) to update Performance | Operation | Typical Time | |-----------|--------------| | Load cached app | < 50ms | | Check single app for updates | ~200ms | | Batch check 10 apps | ~1.5s | | Prefetch single app | 1-3s | | Batch prefetch 10 apps | 10-30s | After initial sync, apps load from local Graviton storage in under 50ms—faster than any CDN. Use Cases Daily Driver Setup 1. Favorite your essential dApps 2. Sync with rating threshold 50+ 3. Check for updates weekly 4. Review diffs before updating Air-Gapped Operation 1. Sync favorites on connected machine 2. Transfer Graviton cache to air-gapped system 3. Run Hologram completely offline 4. Periodically connect to sync updates Version Pinning 1. Find stable version of critical app 2. Clone at that commit (scid@txid) 3. Never auto-update 4. Manually review all updates before applying Benefits Offline-first browsing provides: - **Self-sovereignty**: Your apps, your machine, your rules - **Privacy**: No network requests after sync - **Resilience**: Works when network is down - **Verification**: See exactly what changed before updating - **Control**: You decide when to update (or not)",
+      "plainText": "Offline-First Browsing Offline-First Browsing Hologram enables true offline-first TELA browsing. Clone your favorite dApps locally, cache them in Graviton storage, and access them instantly—no network, no Gnomon, no waiting. **Your data, your machine, your rules**. Once synced, TELA apps load from local storage with zero network latency. Combine with Privacy Mode for complete network isolation. Why Offline-First? | Traditional Web | Hologram Offline-First | |-----------------|------------------------| | Fetch from server every time | Cached locally in Graviton | | Requires network connection | Works completely offline | | Depends on external services | Self-sovereign operation | | Servers can go down | Content lives on your machine | | CDNs track your requests | Zero network fingerprinting | How It Works 1. **Favorite apps** in the Browser's app discovery 2. **Sync Manager** fetches and caches them locally (filtered by rating) 3. **Graviton storage** holds the cached content 4. **TELA Browser** loads instantly from local cache Getting Started Favorite Your Apps Browse TELA apps in the TELA Browser and click the heart icon to add them to your favorites. Favorites are stored locally and persist across sessions. Open Sync Manager Navigate to **Settings → Sync Manager** to access batch sync controls. Configure Rating Threshold Use the slider to set a minimum rating (0-99). Apps rated below this threshold will be skipped during sync—useful for filtering out low-quality or potentially malicious content. Sync Favorites Click **\"Sync Favorites\"** to batch-prefetch all favorited apps that meet your rating threshold. For each favorite app: 1. Resolve dURL to SCID 2. Check rating against threshold 3. If passes: fetch from blockchain → store in cache 4. If fails: skip Sync Manager Features Batch Prefetch Prefetch all favorites in one operation: Update Checking Compare all cached apps against their current on-chain versions: Update checking requires a connection to a DERO daemon to fetch current SC state. Once you've reviewed and accepted updates, you're back to fully offline operation. Visual Diffing Before updating, view exactly what changed: The diff viewer shows: - **Green (+)**: New lines added - **Red (-)**: Lines removed - **Yellow (~)**: Lines modified Selective Updates You're always in control: - Review diffs before updating - Update individual apps (not all-or-nothing) - Keep your preferred version indefinitely - Roll back by re-cloning at specific commit Offline Cache Management Settings → Offline Cache The Offline Cache Manager shows: | Stat | Description | |------|-------------| | **Cached Apps** | Number of apps stored locally | | **Files** | Total file count across all apps | | **Used** | Current cache size | | **Max Size** | Configurable limit (default 500MB) | Cache Behavior - **LRU Eviction**: Oldest-accessed apps are removed when space is needed - **Complete vs Partial**: Full app caches include all assets - **Version Tracking**: Each cached app tracks its blockchain version - **Content Hashing**: SHA256 verification ensures integrity API Reference Prefetch Query Manage Version Control Integration TELA's built-in commit system enables powerful version control: Cached Version Tracking Each cached app stores: Clone at Commit For filesystem access (vs Graviton cache), use Clone with version pinning: This downloads the exact version specified, regardless of current on-chain state. Security Considerations Rating Threshold The minimum rating filter provides a first-line defense: | Rating | Typical Meaning | |--------|-----------------| | 0-9 | Flagged as malicious | | 10-49 | Unverified/new apps | | 50-79 | Community-vetted | | 80-99 | Highly trusted | Ratings are community-driven and not a guarantee of safety. Always review diffs before updating and be cautious with apps from unknown developers. Content Verification - All cached content is fetched from immutable blockchain storage - Content hashes can verify integrity - Diffing shows exact changes before updating - You control when (and if) to update Performance | Operation | Typical Time | |-----------|--------------| | Load cached app | After initial sync, apps load from local Graviton storage in under 50ms—faster than any CDN. Use Cases Daily Driver Setup 1. Favorite your essential dApps 2. Sync with rating threshold 50+ 3. Check for updates weekly 4. Review diffs before updating Air-Gapped Operation 1. Sync favorites on connected machine 2. Transfer Graviton cache to air-gapped system 3. Run Hologram completely offline 4. Periodically connect to sync updates Version Pinning 1. Find stable version of critical app 2. Clone at that commit (scid@txid) 3. Never auto-update 4. Manually review all updates before applying Benefits Offline-first browsing provides: - **Self-sovereignty**: Your apps, your machine, your rules - **Privacy**: No network requests after sync - **Resilience**: Works when network is down - **Verification**: See exactly what changed before updating - **Control**: You decide when to update (or not)",
       "lastUpdated": null
     },
     {
@@ -3146,7 +3269,7 @@
         "Developer Resources",
         "Related Pages"
       ],
-      "plainText": "Welcome to TELA Platform TELA Quick Start Guide TELA Platform TELA is a revolutionary private web3 platform built on DERO blockchain, enabling truly private and decentralized web applications. With TELA, you can build, host, and access web content with complete privacy, censorship resistance, and decentralized infrastructure. New to TELA? Start by setting up your TELA environment, exploring the documentation, and building your first private web application. Core Features <Card title=\"Decentralized Web Standard\" href=\"/tela/overview\" image > <>Private Web3 <Card title=\"TELA Security Model\" href=\"/tela/tela-security-model\" image > <>Decentralized Storage <Card title=\"Content Rating System\" href=\"/tela/tela-content-rating-system\" image > <>Rating System Developer Resources <>Quick Start <>API Guide <>Templates Ready to build with TELA? Explore the TELA documentation to get started with private web applications, learn about the TELA platform, and discover how to build on the private web3. --- Related Pages **Get Started:** - TELA Overview - What is TELA? - Quick Start Tutorial - Build your first TELA app - Installation Guide - Setup TELA CLI **Core Concepts:** - XSWD Protocol - Secure wallet deployment - TELA Security Model - How privacy works - Working Code - Real patterns from working apps **For Developers:** - First App Tutorial - Start building - API Reference - Complete API docs - Templates - Ready-to-use templates",
+      "plainText": "Welcome to TELA Platform TELA Quick Start Guide TELA Platform TELA is a revolutionary private web3 platform built on DERO blockchain, enabling truly private and decentralized web applications. With TELA, you can build, host, and access web content with complete privacy, censorship resistance, and decentralized infrastructure. New to TELA? Start by setting up your TELA environment, exploring the documentation, and building your first private web application. Core Features <>Private Web3 <>Decentralized Storage <>Rating System Developer Resources <>Quick Start <>API Guide <>Templates Ready to build with TELA? Explore the TELA documentation to get started with private web applications, learn about the TELA platform, and discover how to build on the private web3. --- Related Pages **Get Started:** - TELA Overview - What is TELA? - Quick Start Tutorial - Build your first TELA app - Installation Guide - Setup TELA CLI **Core Concepts:** - XSWD Protocol - Secure wallet deployment - TELA Security Model - How privacy works - Working Code - Real patterns from working apps **For Developers:** - First App Tutorial - Start building - API Reference - Complete API docs - Templates - Ready-to-use templates",
       "lastUpdated": "2025-10-22"
     },
     {
@@ -3196,7 +3319,7 @@
         "Compression Performance Data",
         "Key Insights"
       ],
-      "plainText": "Compression & Optimization Advanced compression techniques and optimization strategies for building efficient TELA applications. TELA Compression System TELA includes built-in compression support to reduce storage costs and improve deployment efficiency. Supported Compression Formats Currently supported: - **Gzip (.gz)** - Standard compression with excellent ratios for text content When to Use Compression **Compression Decision Matrix** - **< 10KB**: Optional (minimal benefit) - **10-15KB**: Recommended (good reduction) - **15-18KB**: Highly recommended (may prevent sharding) - **18KB+**: Required (combine with sharding) Compression API Basic Compression Compression Utilities Optimization Strategies Content Type Optimization Different content types compress differently: Content Type Performance | Content Type | Typical Compression | Best Practices | |--------------|-------------------|----------------| | **HTML** | 60-80% reduction | Remove whitespace, minimize inline styles | | **CSS** | 50-70% reduction | Remove comments, minimize selectors | | **JavaScript** | 40-60% reduction | Minify first, remove console.log | | **JSON** | 70-90% reduction | Excellent compression candidate | | **Markdown** | 50-70% reduction | Good for documentation | | **SVG** | 60-80% reduction | Remove metadata, optimize paths | Pre-Compression Optimization Advanced Optimization Techniques Intelligent File Processing Batch Optimization Real-World Optimization Examples React Application Optimization CSS Framework Optimization Deployment Optimization Smart Deployment Order Gas Fee Optimization Performance Monitoring Compression Analytics Advanced Compression Techniques Content-Aware Compression Progressive Loading Optimization **decompression-worker.js:** Optimization Best Practices Development Workflow **Optimization Workflow** 1. **Develop normally** - Don't optimize prematurely 2. **Measure first** - Use file-info to check sizes 3. **Optimize systematically** - Minify, then compress, then shard if needed 4. **Test thoroughly** - Ensure optimizations don't break functionality 5. **Monitor performance** - Track load times and user experience Production Optimization Checklist --- Compression Performance Data Based on real-world testing: | Framework/Library | Original Size | Compressed Size | Reduction | Shards Needed | |-------------------|---------------|-----------------|-----------|---------------| | **React 18** | ~42KB | ~12KB | 71% | No | | **Vue 3** | ~38KB | ~11KB | 71% | No | | **Bootstrap CSS** | ~25KB | ~6KB | 76% | No | | **Tailwind CSS** | ~35KB | ~8KB | 77% | No | | **Large Dataset** | ~150KB | ~25KB | 83% | 2 shards | | **Image Bundle** | ~80KB | ~78KB | 3% | 5 shards | Key Insights 1. **Text content compresses excellently** (60-80% reduction typical) 2. **Frameworks benefit greatly** from compression 3. **JSON data** has exceptional compression ratios 4. **Binary content** (images) compresses poorly 5. **Combination strategies** (minify + compress) are most effective This compression and optimization guide provides the tools and techniques needed to build efficient TELA applications that minimize storage costs while maximizing performance. Next: **Best Practices** - Advanced techniques for building high-performance TELA applications.",
+      "plainText": "Compression & Optimization Advanced compression techniques and optimization strategies for building efficient TELA applications. TELA Compression System TELA includes built-in compression support to reduce storage costs and improve deployment efficiency. Supported Compression Formats Currently supported: - **Gzip (.gz)** - Standard compression with excellent ratios for text content When to Use Compression **Compression Decision Matrix** - ** Compression API Basic Compression Compression Utilities Optimization Strategies Content Type Optimization Different content types compress differently: Content Type Performance | Content Type | Typical Compression | Best Practices | |--------------|-------------------|----------------| | **HTML** | 60-80% reduction | Remove whitespace, minimize inline styles | | **CSS** | 50-70% reduction | Remove comments, minimize selectors | | **JavaScript** | 40-60% reduction | Minify first, remove console.log | | **JSON** | 70-90% reduction | Excellent compression candidate | | **Markdown** | 50-70% reduction | Good for documentation | | **SVG** | 60-80% reduction | Remove metadata, optimize paths | Pre-Compression Optimization Advanced Optimization Techniques Intelligent File Processing Batch Optimization Real-World Optimization Examples React Application Optimization CSS Framework Optimization Deployment Optimization Smart Deployment Order Gas Fee Optimization Performance Monitoring Compression Analytics Advanced Compression Techniques Content-Aware Compression Progressive Loading Optimization **decompression-worker.js:** Optimization Best Practices Development Workflow **Optimization Workflow** 1. **Develop normally** - Don't optimize prematurely 2. **Measure first** - Use file-info to check sizes 3. **Optimize systematically** - Minify, then compress, then shard if needed 4. **Test thoroughly** - Ensure optimizations don't break functionality 5. **Monitor performance** - Track load times and user experience Production Optimization Checklist --- Compression Performance Data Based on real-world testing: | Framework/Library | Original Size | Compressed Size | Reduction | Shards Needed | |-------------------|---------------|-----------------|-----------|---------------| | **React 18** | ~42KB | ~12KB | 71% | No | | **Vue 3** | ~38KB | ~11KB | 71% | No | | **Bootstrap CSS** | ~25KB | ~6KB | 76% | No | | **Tailwind CSS** | ~35KB | ~8KB | 77% | No | | **Large Dataset** | ~150KB | ~25KB | 83% | 2 shards | | **Image Bundle** | ~80KB | ~78KB | 3% | 5 shards | Key Insights 1. **Text content compresses excellently** (60-80% reduction typical) 2. **Frameworks benefit greatly** from compression 3. **JSON data** has exceptional compression ratios 4. **Binary content** (images) compresses poorly 5. **Combination strategies** (minify + compress) are most effective This compression and optimization guide provides the tools and techniques needed to build efficient TELA applications that minimize storage costs while maximizing performance. Next: **Best Practices** - Advanced techniques for building high-performance TELA applications.",
       "lastUpdated": "2025-10-22"
     },
     {
@@ -3535,7 +3658,7 @@
         "Post-Deployment",
         "Related Documentation"
       ],
-      "plainText": "Best Practices Essential guide for building production-ready TELA applications with size constraints, performance optimization, and DERO blockchain integration. **Critical Size Constraints** TELA has strict size limitations that are **absolute requirements**. Never exceed these limits or deployment will fail. 📏 Size Constraints (CRITICAL) File Size Limits | File Type | Content Limit | Total Limit | Status | |-----------|--------------|-------------|--------| | **TELA-DOC-1** | 18.00 KB | 19.20 KB | ⚠️ Absolute max | | **TELA-INDEX-1** | 9 KB recommended | 11.64 KB max | ⚠️ May break updates | | **Shard Size** | 17,500 bytes | - | ⚠️ Auto-split point | **Actual Error Messages from parse.go**: - \"docCode size is to large, max %.2fKB\" - \"DOC SC size is to large, max %.2fKB\" - \"contract exceeds max INDEX install size by %.2fKB\" Size Planning Guide | File Size | Action | Strategy | Compression | |-----------|--------|----------|------------| | **< 10 KB** | ✅ Deploy | Direct deployment | Optional | | **10-15 KB** | ⚠️ Monitor | Standard workflow | Consider .gz | | **15-18 KB** | ⚠️ Critical | Optimize first | **Required** | | **18 KB+** | ❌ Too large | Split into modules | Use DocShards | 🎯 Core Principles Entry Point: index.html (CRITICAL) **Your main HTML file MUST be named index.html** TELA browsers (including Hologram) look for index.html as the default entry point. If your DOC1 file has any other name (like myapp.html, main.html, or Snake_Deluxe.html), **your app will NOT render** - users will see a file listing instead. **Always rename your main HTML file to index.html before deployment.** HTML-First Development **TELA Principle: HTML-First, JavaScript-Minimal** Write fast, zippy static HTML-based applications using proven patterns from tela_tests/app1. Proven JavaScript Patterns ⚡ Size Optimization Quick Reference Optimization Techniques Comparison | Technique | Before | After | Savings | |-----------|--------|-------|---------| | **Variable Names** | calculateDEROAmount() | calcDERO() | ~40% | | **String Concatenation** | 4 statements | 1 statement | Overhead reduction | | **Function Compression** | 127 bytes | 64 bytes | 50% | | **CSS Shorthand** | 4 properties | 1 property | 75% | | **Template Compression** | Multi-line | Single-line | ~30% | CSS Optimization | What | ❌ Avoid | ✅ Optimize | |------|----------|------------| | **Properties** | margin-top: 1rem; margin-right: 0; margin-bottom: 1rem; margin-left: 0; | margin: 1rem 0; | | **Colors** | rgba(255, 255, 255, 1) | #fff | | **Formatting** | Multi-line verbose | Single-line compressed | | **Selectors** | Long descriptive names | Short functional names | JavaScript Optimization | What | ❌ Avoid | ✅ Optimize | |------|----------|------------| | **Variables** | currentBlockHeight, transactionHashList | h, txs | | **Functions** | Separate helpers | Combined operations | | **Templates** | Multi-line template literals | Single concatenation | | **Objects** | applicationName, connectionTimeout | name, timeout | | **Styles** | Repeated inline styles | Shared constants | **Quick Examples**: HTML Optimization | What | ❌ Avoid | ✅ Optimize | |------|----------|------------| | **Attributes** | id=\"main-container\" style=\"display: block;\" | id=\"main\" | | **Whitespace** | Formatted with indentation | Compressed single-line | | **Structure** | Verbose nested divs | Minimal semantic HTML | 📦 Module Organization | Scenario | Strategy | File Count | Example | |----------|----------|------------|---------| | **< 18 KB total** | Single file | 1 | Simple apps | | **18-35 KB** | Split by feature | 2-3 | Core + UI modules | | **35 KB+** | Full modular split | 4+ | Use DocShards system | **Single File Pattern**: **Multi-Module Pattern**: 🔗 DERO Blockchain Integration XSWD Protocol Requirements **MANDATORY: XSWD Protocol Only** ALL blockchain data must come from DERO daemon via XSWD WebSocket protocol. External APIs are forbidden. | Data Source | ✅ Allowed | ❌ Forbidden | |-------------|-----------|-------------| | **DERO Daemon** | xswd.call('DERO.GetInfo') | - | | **Wallet via XSWD** | xswd.call('GetBalance') | - | | **External APIs** | - | fetch('https://api.example.com') | | **CDN Libraries** | - | | Real Data Only Policy 🚫 No External Dependencies | Dependency Type | ❌ Forbidden | ✅ Solution | |-----------------|--------------|------------| | **CSS Frameworks** | Bootstrap, Tailwind CDN | Custom minimal CSS | | **JavaScript Libraries** | jQuery, Chart.js CDN | Lightweight custom implementations | | **Fonts** | Google Fonts CDN | System fonts or embedded | | **Icons** | Font Awesome CDN | SVG icons or emoji | ⚡ Performance Targets | Metric | Target | Critical | |--------|--------|----------| | **Load Time** | < 2 seconds | Required | | **Animation FPS** | 60 fps | Smooth | | **Memory Footprint** | Minimal | Long-running apps | **Efficient DOM Updates**: 🔐 Security & Privacy | Practice | ✅ Good | ❌ Avoid | |----------|---------|----------| | **Data Storage** | Local preferences only | Sensitive wallet data | | **External Tracking** | None | Analytics services | | **User Input** | Sanitize all inputs | Direct injection | | **Content Security** | CSP compliant | Inline scripts from user data | ✅ What Works in TELA Proven JavaScript Features | Feature | Status | Example | |---------|--------|---------| | **ES6 let/const** | ✅ Works | let socket; const data = {}; | | **Arrow Functions** | ✅ Works | document.addEventListener('mousemove', (e) => {...}) | | **Template Literals** | ✅ Works | ` ${title} | | **String Concatenation** | ✅ Works | \"http://localhost:\" + location.port | | **Traditional Functions** | ✅ Works | function connect() {...} | | **Event Listeners** | ✅ Works | socket.addEventListener('open', fn) | CSS Features That Work | Feature | Status | Example | |---------|--------|---------| | **CSS Variables** | ✅ Works | :root { --color: #52c8db; } | | **Animations** | ✅ Works | @keyframes spin { 0% { ... } } | | **Grid/Flexbox** | ✅ Works | display: grid; grid-template-columns: ... | | **Gradients** | ✅ Works | background: linear-gradient(...) | | **Transforms** | ✅ Works | transform: rotate(360deg) | 📋 Development Checklist **Quick Development Checklist** - Use this for every TELA application Pre-Development - [ ] Plan file structure (< 18KB per file) - [ ] Identify modules needed - [ ] Design XSWD-only data access - [ ] Plan caching strategy During Development - [ ] Monitor sizes: wc -c *.js *.css *.html - [ ] Test with real DERO daemon - [ ] Validate XSWD integration - [ ] Optimize for < 2s load time Pre-Deployment - [ ] All files < 18KB verified - [ ] Test compression if 15-18KB - [ ] Validate with tela-cli serve local ./project` - [ ] No external dependencies Post-Deployment - [ ] Test deployed functionality - [ ] Monitor performance - [ ] Gather user feedback Related Documentation - **First App Tutorial** - Step-by-step tutorial for beginners - **Basic App Template** - Complete starter application - **XSWD Advanced** - Production XSWD library - **Advanced Features** - DocShards and compression - **TELA-CLI** - Development tools - **JavaScript Guidelines** - Proven code patterns - **XSWD Protocol** - Wallet integration",
+      "plainText": "Best Practices Essential guide for building production-ready TELA applications with size constraints, performance optimization, and DERO blockchain integration. **Critical Size Constraints** TELA has strict size limitations that are **absolute requirements**. Never exceed these limits or deployment will fail. 📏 Size Constraints (CRITICAL) File Size Limits | File Type | Content Limit | Total Limit | Status | |-----------|--------------|-------------|--------| | **TELA-DOC-1** | 18.00 KB | 19.20 KB | ⚠️ Absolute max | | **TELA-INDEX-1** | 9 KB recommended | 11.64 KB max | ⚠️ May break updates | | **Shard Size** | 17,500 bytes | - | ⚠️ Auto-split point | **Actual Error Messages from parse.go**: - \"docCode size is to large, max %.2fKB\" - \"DOC SC size is to large, max %.2fKB\" - \"contract exceeds max INDEX install size by %.2fKB\" Size Planning Guide | File Size | Action | Strategy | Compression | |-----------|--------|----------|------------| | ** **Your main HTML file MUST be named index.html** TELA browsers (including Hologram) look for index.html as the default entry point. If your DOC1 file has any other name (like myapp.html, main.html, or Snake_Deluxe.html), **your app will NOT render** - users will see a file listing instead. **Always rename your main HTML file to index.html before deployment.** HTML-First Development **TELA Principle: HTML-First, JavaScript-Minimal** Write fast, zippy static HTML-based applications using proven patterns from tela_tests/app1. Proven JavaScript Patterns ⚡ Size Optimization Quick Reference Optimization Techniques Comparison | Technique | Before | After | Savings | |-----------|--------|-------|---------| | **Variable Names** | calculateDEROAmount() | calcDERO() | ~40% | | **String Concatenation** | 4 statements | 1 statement | Overhead reduction | | **Function Compression** | 127 bytes | 64 bytes | 50% | | **CSS Shorthand** | 4 properties | 1 property | 75% | | **Template Compression** | Multi-line | Single-line | ~30% | CSS Optimization | What | ❌ Avoid | ✅ Optimize | |------|----------|------------| | **Properties** | margin-top: 1rem; margin-right: 0; margin-bottom: 1rem; margin-left: 0; | margin: 1rem 0; | | **Colors** | rgba(255, 255, 255, 1) | #fff | | **Formatting** | Multi-line verbose | Single-line compressed | | **Selectors** | Long descriptive names | Short functional names | JavaScript Optimization | What | ❌ Avoid | ✅ Optimize | |------|----------|------------| | **Variables** | currentBlockHeight, transactionHashList | h, txs | | **Functions** | Separate helpers | Combined operations | | **Templates** | Multi-line template literals | Single concatenation | | **Objects** | applicationName, connectionTimeout | name, timeout | | **Styles** | Repeated inline styles | Shared constants | **Quick Examples**: HTML Optimization | What | ❌ Avoid | ✅ Optimize | |------|----------|------------| | **Attributes** | id=\"main-container\" style=\"display: block;\" | id=\"main\" | | **Whitespace** | Formatted with indentation | Compressed single-line | | **Structure** | Verbose nested divs | Minimal semantic HTML | 📦 Module Organization | Scenario | Strategy | File Count | Example | |----------|----------|------------|---------| | ** **MANDATORY: XSWD Protocol Only** ALL blockchain data must come from DERO daemon via XSWD WebSocket protocol. External APIs are forbidden. | Data Source | ✅ Allowed | ❌ Forbidden | |-------------|-----------|-------------| | **DERO Daemon** | xswd.call('DERO.GetInfo') | - | | **Wallet via XSWD** | xswd.call('GetBalance') | - | | **External APIs** | - | fetch('https://api.example.com') | | **CDN Libraries** | - | | Real Data Only Policy 🚫 No External Dependencies | Dependency Type | ❌ Forbidden | ✅ Solution | |-----------------|--------------|------------| | **CSS Frameworks** | Bootstrap, Tailwind CDN | Custom minimal CSS | | **JavaScript Libraries** | jQuery, Chart.js CDN | Lightweight custom implementations | | **Fonts** | Google Fonts CDN | System fonts or embedded | | **Icons** | Font Awesome CDN | SVG icons or emoji | ⚡ Performance Targets | Metric | Target | Critical | |--------|--------|----------| | **Load Time** | {...}) | | **Template Literals** | ✅ Works | ${title} | | **String Concatenation** | ✅ Works | \"http://localhost:\" + location.port | | **Traditional Functions** | ✅ Works | function connect() {...} | | **Event Listeners** | ✅ Works | socket.addEventListener('open', fn) | CSS Features That Work | Feature | Status | Example | |---------|--------|---------| | **CSS Variables** | ✅ Works | :root { --color: #52c8db; } | | **Animations** | ✅ Works | @keyframes spin { 0% { ... } } | | **Grid/Flexbox** | ✅ Works | display: grid; grid-template-columns: ... | | **Gradients** | ✅ Works | background: linear-gradient(...) | | **Transforms** | ✅ Works | transform: rotate(360deg) | 📋 Development Checklist **Quick Development Checklist** - Use this for every TELA application Pre-Development - [ ] Plan file structure (< 18KB per file) - [ ] Identify modules needed - [ ] Design XSWD-only data access - [ ] Plan caching strategy During Development - [ ] Monitor sizes: wc -c *.js *.css *.html - [ ] Test with real DERO daemon - [ ] Validate XSWD integration - [ ] Optimize for < 2s load time Pre-Deployment - [ ] All files < 18KB verified - [ ] Test compression if 15-18KB - [ ] Validate with tela-cli serve local ./project` - [ ] No external dependencies Post-Deployment - [ ] Test deployed functionality - [ ] Monitor performance - [ ] Gather user feedback Related Documentation - **First App Tutorial** - Step-by-step tutorial for beginners - **Basic App Template** - Complete starter application - **XSWD Advanced** - Production XSWD library - **Advanced Features** - DocShards and compression - **TELA-CLI** - Development tools - **JavaScript Guidelines** - Proven code patterns - **XSWD Protocol** - Wallet integration",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -3791,7 +3914,7 @@
         "Additional Resources",
         "Verified Demo Reference"
       ],
-      "plainText": "Error Troubleshooting Guide Comprehensive guide to diagnosing and fixing common errors in TELA development and deployment. **Quick Debug**: Most issues fall into 5 categories: XSWD connection, file size, deployment errors, runtime errors, and network issues. Table of Contents - App Not Rendering (Shows File Listing) - XSWD Connection Errors - XSWD Error Codes Reference - Deployment Errors - File Size Errors - Runtime Errors - Network & Blockchain Errors - Performance Issues - Development Environment Issues --- App Not Rendering (Shows File Listing) **Most Common Deployment Mistake**: Your main HTML file is not named index.html Symptoms When you navigate to your deployed TELA app in Hologram or any TELA browser, instead of seeing your application, you see: or The browser shows a **file listing** with a clickable link instead of rendering your app. Cause TELA browsers look for index.html as the **default entry point**. If your DOC1 file has any other name, the browser doesn't know which file to render automatically, so it displays a file listing instead. **This is NOT a bug** - it's how web servers work. Just like Apache or Nginx serve index.html by default, TELA browsers do the same. Solution **Before deploying**, rename your main HTML file to index.html: If Already Deployed If you've already deployed with the wrong filename, you have two options: **Option 1: Redeploy with correct filename** (Recommended) 1. Rename your file to index.html 2. Deploy as a new DOC: tela-cli install-doc 3. Update your INDEX to point to the new DOC SCID **Option 2: Create a redirect index.html** (Workaround) Create a new index.html that redirects to your existing file: Deploy this index.html as DOC1, and keep your original file as DOC2. Prevention Checklist Before every TELA deployment: - [ ] Main HTML file is named index.html - [ ] index.html is deployed as DOC1 (first document) - [ ] All other files (CSS, JS, images) are referenced correctly from index.html **Pro Tip**: Create a deployment checklist and always verify your entry point filename before running tela-cli install-index. --- XSWD Connection Errors Error: \"Invalid name\" or \"Invalid description\" **Symptoms:** or **Common Causes:** 1. **Unicode characters in name or description** (most common!) 2. Empty name or description 3. Name or description exceeds 255 characters **ASCII Only**: The XSWD server strictly validates that name and description contain only ASCII characters (bytes 0-127). Unicode characters like smart quotes, emojis, or non-English characters will cause silent rejection. **Diagnosis:** **Common Unicode Culprits:** | Character | Code | Replacement | |-----------|------|-------------| | \" \" (smart quotes) | 8220, 8221 | \" (straight quote) | | ' ' (smart apostrophes) | 8216, 8217 | ' (straight apostrophe) | | — (em dash) | 8212 | -- or - | | – (en dash) | 8211 | - | | … (ellipsis) | 8230 | ... | | • (bullet) | 8226 | * or - | | Emojis | Various | Remove or use text | **Solution:** Error: \"Invalid ID size\" or \"Invalid hexadecimal ID\" **Symptoms:** **Cause:** The id field must be exactly 64 hexadecimal characters. **Solution:** Error: \"Invalid URL compared to origin\" **Symptoms:** **Cause:** The url field doesn't match the HTTP Origin header sent by the browser. **Solution:** Error: \"Application is requesting permissions without signature\" **Symptoms:** **Cause:** You included a permissions object but didn't provide a valid DERO signature. **Solution:** Either remove the permissions field, or provide a valid signature: Error: \"WebSocket connection failed\" **Symptoms:** **Common Causes:** 1. Wallet not running 2. XSWD not enabled in wallet 3. Wrong port 4. Firewall blocking connection **Diagnosis:** **Solutions:** 1. **Check Wallet is Running** 2. **Enable XSWD in Engram** - Open Engram wallet - Go to Settings → XSWD - Ensure \"Enable XSWD\" is checked - Check port (default: 44326) 3. **Try Alternative Ports** 4. **Check Firewall** Error: \"XSWD connection closed unexpectedly\" **Symptoms:** **Causes:** 1. Wallet crashed 2. Network interruption 3. Too many requests 4. Timeout **Solution:** XSWD Error Codes Reference The XSWD server returns standard JSON-RPC error codes. Understanding these helps diagnose issues quickly: | Code | Meaning | Common Cause | |------|---------|--------------| | -32700 | Parse error | Invalid JSON in request | | -32600 | Invalid request | Missing required fields | | -32601 | Method not found | Typo in method name, or method not available | | -32602 | Invalid params | Wrong parameter types or values | | -32603 | Internal error | Server-side error | | -32000 to -32099 | Server error | Application-specific errors | **Rate Limiting:** The XSWD server enforces a rate limit of **10 requests per second** with a burst allowance of **20 requests**. Exceeding this will result in requests being dropped or delayed. Error: \"Method not found\" **Symptoms:** **Causes:** 1. Typo in method name 2. Method not available in DERO version 3. Wrong RPC endpoint **Solution:** --- Deployment Errors Error: \"Simulator daemon crashed\" or Daemon Crash During Deployment **Symptoms:** The daemon crashes immediately after sending a transaction, and subsequent RPC calls fail with \"connection refused\". **Critical Issue**: This is often caused by Unicode characters in your deployment files. The DERO daemon or Graviton database cannot process certain UTF-8 multi-byte characters, causing a crash. **Common Causes:** 1. **Unicode characters in JavaScript, HTML, or CSS files** 2. Smart quotes copied from word processors 3. Emojis in comments or strings 4. Non-ASCII characters in any file content **Diagnosis:** **Common Unicode Culprits in Code:** | Character | Unicode | ASCII Replacement | |-----------|---------|-------------------| | \" \" (smart quotes) | U+201C, U+201D | \" | | ' ' (smart apostrophes) | U+2018, U+2019 | ' | | — (em dash) | U+2014 | -- | | – (en dash) | U+2013 | - | | … (ellipsis) | U+2026 | ... | | → (arrow) | U+2192 | -> or => | | × (multiply) | U+00D7 | * or x | | ≥ ≤ | U+2265, U+2264 | >= <= | | • (bullet) | U+2022 | * or - | **Solution:** 1. **Replace Unicode with ASCII equivalents:** 2. **Use sed to fix common issues:** 3. **Verify files are ASCII:** 4. **Prevent future issues:** - Configure your editor to use straight quotes - Disable \"smart quotes\" in your OS settings - Use a linter that warns about non-ASCII characters Error: \"File too large\" **Symptoms:** **Diagnosis:** **Solutions:** 1. **Minify Code** 2. **Enable Compression** 3. **Split into Multiple DOCs** 4. **Remove Unused Code** Error: \"Expecting declaration of function but found ':'\" or \"File contains '*/' which breaks TELA deployment\" **Symptoms:** or **Critical Issue**: TELA wraps your code in a DVM-BASIC comment block. If your file contains */ (even in a string or CSS comment), it prematurely closes the wrapper comment and the parser tries to read your code as DVM-BASIC syntax, causing deployment to fail. **Why This Happens:** TELA stores your file content inside a DVM-BASIC comment block like this: If your file contains */, it closes the wrapper comment early: **Common Causes:** 1. **CSS comment blocks** - /* DERO Explorer v2.0 */ 2. **JavaScript multi-line comments** - /* This is a comment */ 3. **String literals containing */** - const pattern = \"*/\"; 4. **Regular expressions** - const regex = /\\*/; **Diagnosis:** **Solution:** 1. **Remove CSS comment blocks:** 2. **Replace JavaScript multi-line comments with single-line:** 3. **Fix string literals containing */:** 4. **Fix regular expressions:** 5. **Automated fix for CSS files:** 6. **Automated fix for JavaScript files:** **Best Practice:** - **CSS**: Remove all /* */ comment blocks before deployment - **JavaScript**: Use // single-line comments instead of /* */ - **Always**: Test deployment in simulator mode first to catch these issues early **Prevention:** - Configure your build process to strip comments automatically - Use TELA-CLI's compression feature which handles this automatically - Add a pre-deployment check: Error: \"Invalid SCID format\" **Symptoms:** **Causes:** 1. Typo in SCID 2. Copied with extra characters 3. Wrong SCID type (TXID instead of SCID) **Solution:** Error: \"Insufficient funds\" **Symptoms:** **Solution:** 1. **Check Balance** 2. **Get More DERO** - **Testnet**: Use faucet at https://testnet.dero.io/faucet - **Mainnet**: Purchase DERO from exchange 3. **Reduce Transaction Cost** Error: \"Transaction rejected\" **Symptoms:** **Causes:** 1. Invalid parameters 2. Smart contract error 3. Network congestion 4. Ringsize too small **Solution:** --- File Size Errors Error: \"Code size exceeds 18KB after processing\" **Diagnosis:** **Solutions:** 1. **Aggressive Minification** 2. **Use DocShards** 3. **External Resources via TELA Links** --- Runtime Errors Error: \"Cannot read property of undefined\" **Symptoms:** **Causes:** 1. API call failed silently 2. Network timing issue 3. Missing null check **Solution:** Error: \"Promise rejection unhandled\" **Symptoms:** **Solution:** Error: \"Memory leak detected\" **Symptoms:** - Browser tab memory usage increases over time - Page becomes slow after being open for hours - Eventually browser crashes **Diagnosis:** **Solution:** --- Network & Blockchain Errors Error: \"Block not found\" **Symptoms:** **Causes:** 1. Block height doesn't exist yet 2. Blockchain not synced 3. Invalid block hash **Solution:** Error: \"Node not synced\" **Symptoms:** **Solution:** Error: \"Network timeout\" **Symptoms:** **Solution:** --- Performance Issues Issue: \"Slow page load (> 5 seconds)\" **Diagnosis:** **Solutions:** 1. **Defer Non-Critical JS** 2. **Lazy Load Images** 3. **Minimize Rendering Blocking** --- Development Environment Issues Error: \"TELA-CLI not found\" **Solution:** Error: \"Go build failed\" **Symptoms:** **Solution:** --- Diagnostic Tools Quick Diagnostic Script --- Getting Help When reporting issues, include: 1. **Error Message** (complete error text) 2. **Environment** (browser, OS, DERO version) 3. **Steps to Reproduce** 4. **Diagnostic Results** (from script above) 5. **Expected vs Actual Behavior** **Support Channels:** - **Discord**: #support - **Forum**: forum.dero.io - **GitHub**: Issue Tracker **Pro Tip**: Before reporting an issue, run the diagnostic script and include the results. It helps maintainers debug issues faster! --- Additional Resources Production deployment and development best practices XSWD connection details Command-line deployment and workflows Complete API documentation --- Verified Demo Reference **Working Examples for Reference:** - Official Demo (app1) - Complete verified source code with working error handling - API Call Patterns - Error handling patterns from working code - XSWD Protocol - Complete XSWD protocol reference",
+      "plainText": "Error Troubleshooting Guide Comprehensive guide to diagnosing and fixing common errors in TELA development and deployment. **Quick Debug**: Most issues fall into 5 categories: XSWD connection, file size, deployment errors, runtime errors, and network issues. Table of Contents - App Not Rendering (Shows File Listing) - XSWD Connection Errors - XSWD Error Codes Reference - Deployment Errors - File Size Errors - Runtime Errors - Network & Blockchain Errors - Performance Issues - Development Environment Issues --- App Not Rendering (Shows File Listing) **Most Common Deployment Mistake**: Your main HTML file is not named index.html Symptoms When you navigate to your deployed TELA app in Hologram or any TELA browser, instead of seeing your application, you see: or The browser shows a **file listing** with a clickable link instead of rendering your app. Cause TELA browsers look for index.html as the **default entry point**. If your DOC1 file has any other name, the browser doesn't know which file to render automatically, so it displays a file listing instead. **This is NOT a bug** - it's how web servers work. Just like Apache or Nginx serve index.html by default, TELA browsers do the same. Solution **Before deploying**, rename your main HTML file to index.html: If Already Deployed If you've already deployed with the wrong filename, you have two options: **Option 1: Redeploy with correct filename** (Recommended) 1. Rename your file to index.html 2. Deploy as a new DOC: tela-cli install-doc 3. Update your INDEX to point to the new DOC SCID **Option 2: Create a redirect index.html** (Workaround) Create a new index.html that redirects to your existing file: Deploy this index.html as DOC1, and keep your original file as DOC2. Prevention Checklist Before every TELA deployment: - [ ] Main HTML file is named index.html - [ ] index.html is deployed as DOC1 (first document) - [ ] All other files (CSS, JS, images) are referenced correctly from index.html **Pro Tip**: Create a deployment checklist and always verify your entry point filename before running tela-cli install-index. --- XSWD Connection Errors Error: \"Invalid name\" or \"Invalid description\" **Symptoms:** or **Common Causes:** 1. **Unicode characters in name or description** (most common!) 2. Empty name or description 3. Name or description exceeds 255 characters **ASCII Only**: The XSWD server strictly validates that name and description contain only ASCII characters (bytes 0-127). Unicode characters like smart quotes, emojis, or non-English characters will cause silent rejection. **Diagnosis:** **Common Unicode Culprits:** | Character | Code | Replacement | |-----------|------|-------------| | \" \" (smart quotes) | 8220, 8221 | \" (straight quote) | | ' ' (smart apostrophes) | 8216, 8217 | ' (straight apostrophe) | | — (em dash) | 8212 | -- or - | | – (en dash) | 8211 | - | | … (ellipsis) | 8230 | ... | | • (bullet) | 8226 | * or - | | Emojis | Various | Remove or use text | **Solution:** Error: \"Invalid ID size\" or \"Invalid hexadecimal ID\" **Symptoms:** **Cause:** The id field must be exactly 64 hexadecimal characters. **Solution:** Error: \"Invalid URL compared to origin\" **Symptoms:** **Cause:** The url field doesn't match the HTTP Origin header sent by the browser. **Solution:** Error: \"Application is requesting permissions without signature\" **Symptoms:** **Cause:** You included a permissions object but didn't provide a valid DERO signature. **Solution:** Either remove the permissions field, or provide a valid signature: Error: \"WebSocket connection failed\" **Symptoms:** **Common Causes:** 1. Wallet not running 2. XSWD not enabled in wallet 3. Wrong port 4. Firewall blocking connection **Diagnosis:** **Solutions:** 1. **Check Wallet is Running** 2. **Enable XSWD in Engram** - Open Engram wallet - Go to Settings → XSWD - Ensure \"Enable XSWD\" is checked - Check port (default: 44326) 3. **Try Alternative Ports** 4. **Check Firewall** Error: \"XSWD connection closed unexpectedly\" **Symptoms:** **Causes:** 1. Wallet crashed 2. Network interruption 3. Too many requests 4. Timeout **Solution:** XSWD Error Codes Reference The XSWD server returns standard JSON-RPC error codes. Understanding these helps diagnose issues quickly: | Code | Meaning | Common Cause | |------|---------|--------------| | -32700 | Parse error | Invalid JSON in request | | -32600 | Invalid request | Missing required fields | | -32601 | Method not found | Typo in method name, or method not available | | -32602 | Invalid params | Wrong parameter types or values | | -32603 | Internal error | Server-side error | | -32000 to -32099 | Server error | Application-specific errors | **Rate Limiting:** The XSWD server enforces a rate limit of **10 requests per second** with a burst allowance of **20 requests**. Exceeding this will result in requests being dropped or delayed. Error: \"Method not found\" **Symptoms:** **Causes:** 1. Typo in method name 2. Method not available in DERO version 3. Wrong RPC endpoint **Solution:** --- Deployment Errors Error: \"Simulator daemon crashed\" or Daemon Crash During Deployment **Symptoms:** The daemon crashes immediately after sending a transaction, and subsequent RPC calls fail with \"connection refused\". **Critical Issue**: This is often caused by Unicode characters in your deployment files. The DERO daemon or Graviton database cannot process certain UTF-8 multi-byte characters, causing a crash. **Common Causes:** 1. **Unicode characters in JavaScript, HTML, or CSS files** 2. Smart quotes copied from word processors 3. Emojis in comments or strings 4. Non-ASCII characters in any file content **Diagnosis:** **Common Unicode Culprits in Code:** | Character | Unicode | ASCII Replacement | |-----------|---------|-------------------| | \" \" (smart quotes) | U+201C, U+201D | \" | | ' ' (smart apostrophes) | U+2018, U+2019 | ' | | — (em dash) | U+2014 | -- | | – (en dash) | U+2013 | - | | … (ellipsis) | U+2026 | ... | | → (arrow) | U+2192 | -> or => | | × (multiply) | U+00D7 | * or x | | ≥ ≤ | U+2265, U+2264 | >= **Critical Issue**: TELA wraps your code in a DVM-BASIC comment block. If your file contains */ (even in a string or CSS comment), it prematurely closes the wrapper comment and the parser tries to read your code as DVM-BASIC syntax, causing deployment to fail. **Why This Happens:** TELA stores your file content inside a DVM-BASIC comment block like this: If your file contains */, it closes the wrapper comment early: **Common Causes:** 1. **CSS comment blocks** - /* DERO Explorer v2.0 */ 2. **JavaScript multi-line comments** - /* This is a comment */ 3. **String literals containing */** - const pattern = \"*/\"; 4. **Regular expressions** - const regex = /\\*/; **Diagnosis:** **Solution:** 1. **Remove CSS comment blocks:** 2. **Replace JavaScript multi-line comments with single-line:** 3. **Fix string literals containing */:** 4. **Fix regular expressions:** 5. **Automated fix for CSS files:** 6. **Automated fix for JavaScript files:** **Best Practice:** - **CSS**: Remove all /* */ comment blocks before deployment - **JavaScript**: Use // single-line comments instead of /* */` - **Always**: Test deployment in simulator mode first to catch these issues early **Prevention:** - Configure your build process to strip comments automatically - Use TELA-CLI's compression feature which handles this automatically - Add a pre-deployment check: Error: \"Invalid SCID format\" **Symptoms:** **Causes:** 1. Typo in SCID 2. Copied with extra characters 3. Wrong SCID type (TXID instead of SCID) **Solution:** Error: \"Insufficient funds\" **Symptoms:** **Solution:** 1. **Check Balance** 2. **Get More DERO** - **Testnet**: Use faucet at https://testnet.dero.io/faucet - **Mainnet**: Purchase DERO from exchange 3. **Reduce Transaction Cost** Error: \"Transaction rejected\" **Symptoms:** **Causes:** 1. Invalid parameters 2. Smart contract error 3. Network congestion 4. Ringsize too small **Solution:** --- File Size Errors Error: \"Code size exceeds 18KB after processing\" **Diagnosis:** **Solutions:** 1. **Aggressive Minification** 2. **Use DocShards** 3. **External Resources via TELA Links** --- Runtime Errors Error: \"Cannot read property of undefined\" **Symptoms:** **Causes:** 1. API call failed silently 2. Network timing issue 3. Missing null check **Solution:** Error: \"Promise rejection unhandled\" **Symptoms:** **Solution:** Error: \"Memory leak detected\" **Symptoms:** - Browser tab memory usage increases over time - Page becomes slow after being open for hours - Eventually browser crashes **Diagnosis:** **Solution:** --- Network & Blockchain Errors Error: \"Block not found\" **Symptoms:** **Causes:** 1. Block height doesn't exist yet 2. Blockchain not synced 3. Invalid block hash **Solution:** Error: \"Node not synced\" **Symptoms:** **Solution:** Error: \"Network timeout\" **Symptoms:** **Solution:** --- Performance Issues Issue: \"Slow page load (> 5 seconds)\" **Diagnosis:** **Solutions:** 1. **Defer Non-Critical JS** 2. **Lazy Load Images** 3. **Minimize Rendering Blocking** --- Development Environment Issues Error: \"TELA-CLI not found\" **Solution:** Error: \"Go build failed\" **Symptoms:** **Solution:** --- Diagnostic Tools Quick Diagnostic Script --- Getting Help When reporting issues, include: 1. **Error Message** (complete error text) 2. **Environment** (browser, OS, DERO version) 3. **Steps to Reproduce** 4. **Diagnostic Results** (from script above) 5. **Expected vs Actual Behavior** **Support Channels:** - **Discord**: #support - **Forum**: forum.dero.io - **GitHub**: Issue Tracker **Pro Tip**: Before reporting an issue, run the diagnostic script and include the results. It helps maintainers debug issues faster! --- Additional Resources Production deployment and development best practices XSWD connection details Command-line deployment and workflows Complete API documentation --- Verified Demo Reference **Working Examples for Reference:** - Official Demo (app1) - Complete verified source code with working error handling - API Call Patterns - Error handling patterns from working code - XSWD Protocol - Complete XSWD protocol reference",
       "lastUpdated": "2025-10-22"
     },
     {
@@ -4288,7 +4411,7 @@
         "What Gets Indexed",
         "Related Documentation"
       ],
-      "plainText": "Gnomon Indexer Deep-Dive Guide Complete guide to understanding and using Gnomon - the blockchain indexer that powers TELA content discovery. **What is Gnomon?** A blockchain indexer that scans the DERO network for TELA smart contracts, indexes their content and variables, and enables fast searching and discovery. What Gnomon Does Core Functions | Function | Description | |----------|-------------| | **Scans Blockchain** | Reads every block looking for TELA contracts | | **Indexes Smart Contracts** | Stores TELA-DOC and TELA-INDEX metadata | | **Tracks Variables** | Records all contract variables and values | | **Monitors Ratings** | Tracks rating transactions and scores | | **Enables Search** | Powers all search commands in TELA-CLI | | **Maintains History** | Preserves version updates and changes | Why Gnomon is Essential **Without Gnomon:** - ❌ Cannot search for TELA content - ❌ Cannot discover new applications - ❌ Cannot view ratings - ❌ Must know exact SCIDs to access content - ❌ No content discovery **With Gnomon:** - ✅ Search by name, author, dURL, content - ✅ Discover quality applications (min-likes) - ✅ Browse libraries and DocShards - ✅ View your own deployed content - ✅ Analyze smart contract variables - ✅ Complete content ecosystem navigation --- Starting Gnomon Basic Start **First-time sync:** Startup Options **Start with TELA-CLI flags:** --- Sync Strategies Full Sync (Default) **How it works:** **Use When:** - First-time setup - Need complete history - Analyzing historical data - Production/mainnet deployments **Time:** - **Simulator:** ~30 seconds (low block count) - **Testnet:** ~5-10 minutes - **Mainnet:** ~30-60 minutes (depends on network) Fast Sync **How it works:** **Enable:** **Use When:** - Development and testing - Don't need historical data - Quick content discovery - Temporary instances **Time:** - **All Networks:** ~5 seconds to start - Only indexes new blocks as they arrive **Fast Sync Limitation:** You won't see historical TELA contracts. Only new deployments after Gnomon started. Continuing Sync **How it works:** **Automatic:** Happens when you restart Gnomon after previous sync **Example:** --- Database Management Storage Locations **macOS/Linux:** **Windows:** Database Sizes | Network | Typical Size | Growth Rate | |---------|--------------|-------------| | **Simulator** | &lt; 10 MB | Minimal (testing only) | | **Testnet** | 50-200 MB | Moderate | | **Mainnet** | 200-500+ MB | Grows with TELA adoption | **Monitor Size:** Database Types TELA-CLI supports two database backends: **GravDB (Default):** - ✅ Better performance - ✅ Recommended for most users - ✅ Default choice **BoltDB (Alternative):** - ✅ More mature - ✅ Alternative if GravDB has issues --- Gnomon Operations gnomon start Start the Gnomon indexer. **What happens:** 1. Connects to daemon 2. Checks last indexed height 3. Begins scanning blocks 4. Indexes TELA contracts found 5. Updates status to [G:▲] **Output:** --- gnomon stop Stop the Gnomon indexer. **What happens:** 1. Saves current indexed height 2. Closes database connections 3. Stops block scanning 4. Updates status to [G:▼] **Use When:** - Switching networks - Freeing system resources - Shutting down TELA-CLI - Performing database maintenance --- gnomon resync Complete database reset and resync. **What happens:** 1. Stops Gnomon (if running) 2. **Deletes entire database** for current network 3. Restarts Gnomon 4. Performs full sync from block 0 **Use When:** - Database corruption suspected - Want fresh index - Network had major update - Strange search results **Data Loss Warning:** gnomon resync deletes all indexed data for the current network. You'll need to re-sync from scratch. **Example:** --- gnomon add Manually add specific SCIDs to index. **Use Cases:** **Index Specific Known Contracts:** **Targeted Development:** **Quick Testing:** **Benefits:** - ⚡ Instant indexing (no waiting for sync) - 🎯 Targeted indexing (save resources) - 🔧 Development efficiency --- gnomon clean Delete Gnomon database for specific network. **What happens:** - Deletes database file for specified network - Does NOT delete databases for other networks - Does NOT restart Gnomon - Frees disk space **Use Cases:** **Disk Space Management:** **Network Switching Cleanup:** **Fresh Start for Specific Network:** --- Performance Tuning Parallel Block Processing **Concept:** Process multiple blocks simultaneously for faster indexing. **Configure:** **Guidelines:** | Node Type | Recommended Setting | Reason | |-----------|---------------------|--------| | **Local Daemon** | 5-10 | Fast, reliable connection | | **Remote Public Node** | 1-2 | Avoid overwhelming remote server | | **Slow Connection** | 1 | Prevent timeouts | **Remote Node Warning:** Using high parallel blocks (greater than 5) on remote nodes can cause timeouts, connection failures, or get you rate-limited. Memory Management **Gnomon memory usage depends on:** - Number of indexed contracts - Parallel block processing - Database size - Network activity **Optimization:** --- Indexing Workflows Development Workflow (Fast) **Time:** ~10 seconds total --- Production Workflow (Complete) **Time:** Initial sync ~30-60 min, then real-time updates --- Content Discovery Workflow --- Selective Indexing Workflow **Benefits:** - ⚡ Instant start (no waiting) - 💾 Minimal disk usage - 🎯 Focused indexing --- Database Maintenance When to Clean Databases **Network Switching:** **Disk Space Issues:** **Multiple Network Testing:** When to Resync **Indicators you need resync:** - Strange search results - Missing known contracts - Database errors in logs - After network hard fork - Corrupted database file **Process:** --- Advanced Search with Gnomon Search by Variable Keys Find contracts with specific stored variables: **Use Case:** Discover apps using specific features or patterns --- Search by Variable Values Find contracts storing specific values: **Use Case:** Category-based discovery, status checking --- Search Code Analysis **Search for specific code patterns:** **Use Case:** Learn from existing implementations, find similar apps --- Combined Search Strategies **Quality-filtered discovery:** **Author-focused discovery:** **Exclusion-based filtering:** --- Gnomon Performance Optimization Local vs Remote Nodes **Local Node (Best Performance):** **Remote Node (Conservative):** Sync Speed Comparison | Configuration | Mainnet Sync Time | |---------------|-------------------| | Local node, 10 parallel | ~20 minutes | | Local node, 3 parallel | ~35 minutes | | Local node, 1 parallel | ~60 minutes | | Remote node, 1 parallel | ~90+ minutes | | Fast sync | ~5 seconds (no history) | Memory Optimization **High memory usage (over 500MB)?** **Solutions:** --- Network-Specific Strategies Simulator Network **Characteristics:** - Very few blocks - Mostly test contracts - Fast sync (under 30 seconds) - Clean frequently **Recommended Setup:** --- Testnet Network **Characteristics:** - Moderate block count - Mix of test and real apps - Medium sync time (5-10 min) - Good for staging **Recommended Setup:** --- Mainnet Network **Characteristics:** - Large block count - Production applications - Long sync time (30-60 min) - Keep database persistent **Recommended Setup:** --- Troubleshooting Gnomon Issue: Gnomon won't start **Diagnostic:** **Solution:** --- Issue: Sync is very slow **Causes:** - Remote node + high parallel blocks - Network latency - Large blockchain (mainnet) **Solutions:** --- Issue: No search results **Diagnostic:** **Solutions:** --- Issue: Database corruption **Symptoms:** - Gnomon crashes on start - Error messages in logs - Strange search results - Database file errors **Solution:** --- Issue: High memory usage **Solution:** --- Advanced Use Cases Blockchain Analysis --- Developer Discovery --- Library Discovery --- Quality Assurance --- Gnomon + Search Workflows Content Curator Workflow --- Developer Learning Workflow --- Library User Workflow --- Best Practices **Gnomon Best Practices** 1. **Start Gnomon with daemon flag** - Ensures proper initialization 2. **Use local nodes for development** - Much faster syncing 3. **Keep mainnet DB persistent** - Sync once, reuse forever 4. **Clean unused networks** - Free up disk space 5. **Use fastsync for testing** - When history doesn't matter 6. **Add specific SCIDs for quick testing** - Skip full sync 7. **Monitor database size** - Clean periodically Recommended Setups **Development Setup:** **Testing Setup:** **Production Setup:** **Low-Resource Setup:** --- Monitoring Gnomon Check Sync Status Watch Sync Progress **During sync, status updates appear:** Verify Indexing --- Gnomon Data Structure What Gets Indexed **For each TELA contract found:** - ✅ SCID - ✅ Contract type (DOC or INDEX) - ✅ All STORE variables - ✅ Author address - ✅ Deployment height - ✅ All rating transactions - ✅ Update history (for INDEX) **Searchable Fields:** - SCID - dURL - var_header_name - var_header_description - All var_* variables - Author address - docType (for DOCs) - Contract code --- Related Documentation Advanced search techniques All Gnomon commands Development workflows Common issues and solutions --- **Gnomon Mastery Achieved:** You now understand how to efficiently index, search, and discover TELA content across the DERO blockchain!",
+      "plainText": "Gnomon Indexer Deep-Dive Guide Complete guide to understanding and using Gnomon - the blockchain indexer that powers TELA content discovery. **What is Gnomon?** A blockchain indexer that scans the DERO network for TELA smart contracts, indexes their content and variables, and enables fast searching and discovery. What Gnomon Does Core Functions | Function | Description | |----------|-------------| | **Scans Blockchain** | Reads every block looking for TELA contracts | | **Indexes Smart Contracts** | Stores TELA-DOC and TELA-INDEX metadata | | **Tracks Variables** | Records all contract variables and values | | **Monitors Ratings** | Tracks rating transactions and scores | | **Enables Search** | Powers all search commands in TELA-CLI | | **Maintains History** | Preserves version updates and changes | Why Gnomon is Essential **Without Gnomon:** - ❌ Cannot search for TELA content - ❌ Cannot discover new applications - ❌ Cannot view ratings - ❌ Must know exact SCIDs to access content - ❌ No content discovery **With Gnomon:** - ✅ Search by name, author, dURL, content - ✅ Discover quality applications (min-likes) - ✅ Browse libraries and DocShards - ✅ View your own deployed content - ✅ Analyze smart contract variables - ✅ Complete content ecosystem navigation --- Starting Gnomon Basic Start **First-time sync:** Startup Options **Start with TELA-CLI flags:** --- Sync Strategies Full Sync (Default) **How it works:** **Use When:** - First-time setup - Need complete history - Analyzing historical data - Production/mainnet deployments **Time:** - **Simulator:** ~30 seconds (low block count) - **Testnet:** ~5-10 minutes - **Mainnet:** ~30-60 minutes (depends on network) Fast Sync **How it works:** **Enable:** **Use When:** - Development and testing - Don't need historical data - Quick content discovery - Temporary instances **Time:** - **All Networks:** ~5 seconds to start - Only indexes new blocks as they arrive **Fast Sync Limitation:** You won't see historical TELA contracts. Only new deployments after Gnomon started. Continuing Sync **How it works:** **Automatic:** Happens when you restart Gnomon after previous sync **Example:** --- Database Management Storage Locations **macOS/Linux:** **Windows:** Database Sizes | Network | Typical Size | Growth Rate | |---------|--------------|-------------| | **Simulator** | < 10 MB | Minimal (testing only) | | **Testnet** | 50-200 MB | Moderate | | **Mainnet** | 200-500+ MB | Grows with TELA adoption | **Monitor Size:** Database Types TELA-CLI supports two database backends: **GravDB (Default):** - ✅ Better performance - ✅ Recommended for most users - ✅ Default choice **BoltDB (Alternative):** - ✅ More mature - ✅ Alternative if GravDB has issues --- Gnomon Operations gnomon start Start the Gnomon indexer. **What happens:** 1. Connects to daemon 2. Checks last indexed height 3. Begins scanning blocks 4. Indexes TELA contracts found 5. Updates status to [G:▲] **Output:** --- gnomon stop Stop the Gnomon indexer. **What happens:** 1. Saves current indexed height 2. Closes database connections 3. Stops block scanning 4. Updates status to [G:▼] **Use When:** - Switching networks - Freeing system resources - Shutting down TELA-CLI - Performing database maintenance --- gnomon resync Complete database reset and resync. **What happens:** 1. Stops Gnomon (if running) 2. **Deletes entire database** for current network 3. Restarts Gnomon 4. Performs full sync from block 0 **Use When:** - Database corruption suspected - Want fresh index - Network had major update - Strange search results **Data Loss Warning:** gnomon resync deletes all indexed data for the current network. You'll need to re-sync from scratch. **Example:** --- gnomon add Manually add specific SCIDs to index. **Use Cases:** **Index Specific Known Contracts:** **Targeted Development:** **Quick Testing:** **Benefits:** - ⚡ Instant indexing (no waiting for sync) - 🎯 Targeted indexing (save resources) - 🔧 Development efficiency --- gnomon clean Delete Gnomon database for specific network. **What happens:** - Deletes database file for specified network - Does NOT delete databases for other networks - Does NOT restart Gnomon - Frees disk space **Use Cases:** **Disk Space Management:** **Network Switching Cleanup:** **Fresh Start for Specific Network:** --- Performance Tuning Parallel Block Processing **Concept:** Process multiple blocks simultaneously for faster indexing. **Configure:** **Guidelines:** | Node Type | Recommended Setting | Reason | |-----------|---------------------|--------| | **Local Daemon** | 5-10 | Fast, reliable connection | | **Remote Public Node** | 1-2 | Avoid overwhelming remote server | | **Slow Connection** | 1 | Prevent timeouts | **Remote Node Warning:** Using high parallel blocks (greater than 5) on remote nodes can cause timeouts, connection failures, or get you rate-limited. Memory Management **Gnomon memory usage depends on:** - Number of indexed contracts - Parallel block processing - Database size - Network activity **Optimization:** --- Indexing Workflows Development Workflow (Fast) **Time:** ~10 seconds total --- Production Workflow (Complete) **Time:** Initial sync ~30-60 min, then real-time updates --- Content Discovery Workflow --- Selective Indexing Workflow **Benefits:** - ⚡ Instant start (no waiting) - 💾 Minimal disk usage - 🎯 Focused indexing --- Database Maintenance When to Clean Databases **Network Switching:** **Disk Space Issues:** **Multiple Network Testing:** When to Resync **Indicators you need resync:** - Strange search results - Missing known contracts - Database errors in logs - After network hard fork - Corrupted database file **Process:** --- Advanced Search with Gnomon Search by Variable Keys Find contracts with specific stored variables: **Use Case:** Discover apps using specific features or patterns --- Search by Variable Values Find contracts storing specific values: **Use Case:** Category-based discovery, status checking --- Search Code Analysis **Search for specific code patterns:** **Use Case:** Learn from existing implementations, find similar apps --- Combined Search Strategies **Quality-filtered discovery:** **Author-focused discovery:** **Exclusion-based filtering:** --- Gnomon Performance Optimization Local vs Remote Nodes **Local Node (Best Performance):** **Remote Node (Conservative):** Sync Speed Comparison | Configuration | Mainnet Sync Time | |---------------|-------------------| | Local node, 10 parallel | ~20 minutes | | Local node, 3 parallel | ~35 minutes | | Local node, 1 parallel | ~60 minutes | | Remote node, 1 parallel | ~90+ minutes | | Fast sync | ~5 seconds (no history) | Memory Optimization **High memory usage (over 500MB)?** **Solutions:** --- Network-Specific Strategies Simulator Network **Characteristics:** - Very few blocks - Mostly test contracts - Fast sync (under 30 seconds) - Clean frequently **Recommended Setup:** --- Testnet Network **Characteristics:** - Moderate block count - Mix of test and real apps - Medium sync time (5-10 min) - Good for staging **Recommended Setup:** --- Mainnet Network **Characteristics:** - Large block count - Production applications - Long sync time (30-60 min) - Keep database persistent **Recommended Setup:** --- Troubleshooting Gnomon Issue: Gnomon won't start **Diagnostic:** **Solution:** --- Issue: Sync is very slow **Causes:** - Remote node + high parallel blocks - Network latency - Large blockchain (mainnet) **Solutions:** --- Issue: No search results **Diagnostic:** **Solutions:** --- Issue: Database corruption **Symptoms:** - Gnomon crashes on start - Error messages in logs - Strange search results - Database file errors **Solution:** --- Issue: High memory usage **Solution:** --- Advanced Use Cases Blockchain Analysis --- Developer Discovery --- Library Discovery --- Quality Assurance --- Gnomon + Search Workflows Content Curator Workflow --- Developer Learning Workflow --- Library User Workflow --- Best Practices **Gnomon Best Practices** 1. **Start Gnomon with daemon flag** - Ensures proper initialization 2. **Use local nodes for development** - Much faster syncing 3. **Keep mainnet DB persistent** - Sync once, reuse forever 4. **Clean unused networks** - Free up disk space 5. **Use fastsync for testing** - When history doesn't matter 6. **Add specific SCIDs for quick testing** - Skip full sync 7. **Monitor database size** - Clean periodically Recommended Setups **Development Setup:** **Testing Setup:** **Production Setup:** **Low-Resource Setup:** --- Monitoring Gnomon Check Sync Status Watch Sync Progress **During sync, status updates appear:** Verify Indexing --- Gnomon Data Structure What Gets Indexed **For each TELA contract found:** - ✅ SCID - ✅ Contract type (DOC or INDEX) - ✅ All STORE variables - ✅ Author address - ✅ Deployment height - ✅ All rating transactions - ✅ Update history (for INDEX) **Searchable Fields:** - SCID - dURL - var_header_name - var_header_description - All var_* variables - Author address - docType (for DOCs) - Contract code --- Related Documentation Advanced search techniques All Gnomon commands Development workflows Common issues and solutions --- **Gnomon Mastery Achieved:** You now understand how to efficiently index, search, and discover TELA content across the DERO blockchain!",
       "lastUpdated": "2025-10-22"
     },
     {
@@ -5050,7 +5173,7 @@
         "Next Steps",
         "Related Pages"
       ],
-      "plainText": "TELA Platform Overview **TELA** is the Decentralized Web Standard for DERO blockchain. Build privacy-first web applications that run entirely on-chain with zero servers, zero censorship, and complete user control. **The Future of Web3:** TELA is the ONLY platform enabling fully private, censorship-resistant web applications with encrypted storage and local execution. The TELA Difference **Traditional Web Architecture:** **TELA Architecture:** What Makes TELA Special? ✨ **Three Revolutionary Features:** | Feature | Traditional Web | TELA | |---------|----------------|------| | **🗄️ Storage** | Centralized servers | DERO blockchain (distributed) | | **🔒 Privacy** | Server logs everything | Local execution (zero tracking) | | **⚡ Performance** | Server latency + downtime | Instant local execution | | **📡 Network** | Always online required | Works offline | | **💰 Costs** | Monthly hosting fees | One-time blockchain fee | | **🌍 Access** | Geo-restrictions possible | Global, unstoppable | | **🛡️ Censorship** | Can be taken down | Impossible to censor | --- 🔐 **True Decentralization** **No servers = No single point of failure** **Traditional Web:** **TELA:** **Result:** TELA applications remain globally available around the clock - no servers to go down, no hosting companies to fail. --- 🔒 **Privacy by Design** **Your data stays on YOUR device** | What Happens | Traditional Web | TELA | |--------------|----------------|------| | **Code execution** | Server-side (they see everything) | Local (you control everything) | | **User data** | Stored on company servers | Stays on your device | | **Activity logs** | Server tracks every action | Zero tracking, zero logs | | **Third parties** | Analytics, ads, trackers | None - completely private | | **Blockchain** | Public ledger (addresses visible) | DERO privacy (encrypted) | --- ⚡ **Local-First Performance** **Instant loading, works offline** | Metric | Traditional Web | TELA | |--------|-----------------|------| | **Initial Load** | Depends on server location | Instant (cached locally) | | **Navigation** | HTTP requests per page | Instant (already local) | | **Offline** | ❌ Doesn't work | ✅ Full functionality | | **Latency** | 50-500ms+ | Under 1ms (local) | | **Blockchain Sync** | N/A | Only when updating content | --- How TELA Works: Dual-Contract System **TELA uses two smart contract types:** **Deployment Flow:** **User Access Flow:** 📋 **INDEX Contract** (Application Manifest) | Contains | Purpose | |----------|---------| | **App Name** | \"My TELA App\" | | **Description** | What the app does | | **Icon** | App thumbnail | | **DOC References** | SCIDs of all files | | **File Paths** | How files are organized | | **Version** | App version number | **Think:** Package.json for on-chain apps --- 📦 **DOC Contract** (Application Files) **Supported File Types:** | Type | File Extension | Max Size | Use Case | |------|----------------|----------|----------| | **HTML** | .html | 18KB | Page structure | | **CSS** | .css | 18KB | Styling | | **JavaScript** | .js | 18KB | Logic & interactivity | | **JSON** | .json | 18KB | Data & config | | **Markdown** | .md | 18KB | Documentation | | **Static Assets** | Images, fonts | 18KB | Assets | **Size limit:** 18KB per DOC contract (blockchain constraint) **Solution:** Split large files across multiple DOC contracts --- Development Workflow **From idea to deployed app:** | Step | Action | Tool | Output | |------|--------|------|--------| | **A** | Write your app | Any code editor | HTML, CSS, JS files | | **B** | Test locally | TELA-CLI serve | Preview in browser | | **C** | Deploy files | TELA-CLI install-doc | DOC contracts (SCIDs) | | **D** | Create manifest | TELA-CLI install-index | INDEX contract (SCID) | | **E** | Share & access | Give users INDEX SCID | App live on blockchain! | Complete Architecture **Full TELA Stack (4 Layers):** | Layer | Component | Function | |-------|-----------|----------| | **👤 User Layer** | User in Engram | Browses and interacts with apps | | **📱 TELA Protocol** | INDEX + DOC contracts | App manifest + code files | | **🔐 Security Layer** | XSWD (port 44326) + Verification | Wallet connection + hash checking | | **💾 Storage Layer** | DERO Blockchain + Wallet | Immutable storage + private keys | **Data Flow:** **Every layer is decentralized, private, and verifiable!** --- Technical Foundation Smart Contract Architecture | Contract Type | Mutability | Purpose | Size Limit | |---------------|------------|---------|------------| | **DOC Contract** | 🔒 Immutable | Store code files | 18KB per file | | **INDEX Contract** | ✏️ Updateable | App metadata & references | Variable | **Why two types?** - **DOC immutability** → Code integrity guaranteed - **INDEX updateability** → Apps can evolve (point to new DOCs) - **User control** → Can verify exact code version running **Version Control:** Supported Languages TELA supports a wide range of file types through its document type system: Community Rating System TELA includes an integrated rating system that helps users evaluate content quality and trustworthiness: - **One rating per DERO account** per contract prevents spam - **Structured 0-99 scale** with meaningful categories and detail tags - **Blockchain transparency** - All ratings are publicly visible - **Community moderation** without centralized gatekeepers Rating Categories | Rating | Category | Meaning | |--------|----------|---------| | 0-9 | Do not use → Broken | Content has serious issues | | 10-49 | Major → Minor issues | Content needs improvement | | 50-59 | Could be improved | Decent quality with room for growth | | 60-69 | Average | Standard quality, meets expectations | | 70-89 | Good → Very good | High quality content | | 90-99 | Exceptional | Outstanding, best-in-class content | Learn more about the Content Rating System. TELA vs Traditional Web | Traditional Web | TELA Applications | |----------------|-------------------| | **Hosted on servers** | **Stored on blockchain** | | **Centralized** | **Decentralized** | | **Privacy concerns** | **Complete privacy** | | **Server dependencies** | **No external dependencies** | | **Can be censored** | **Censorship resistant** | | **Server maintenance costs** | **One-time deployment cost** | | **Geographic restrictions** | **Globally accessible** | Next Steps Ready to start building with TELA? Choose your path: <Card icon={ 🎯 } title=\"Quick Start\" href=\"/best-practices\" /> <Card icon={ 📚 } title=\"Learn the Concepts\" href=\"/tela/tela-doc-index-structures\" /> <Card icon={ 🔧 } title=\"Dive Deep\" href=\"/advanced-features/libraries-overview\" /> --- Related Pages **Understanding TELA:** - TELA Security Model - Privacy and security features - TELA Links - Deep linking system - Content Rating System - Content moderation **Build with TELA:** - Quick Start Tutorial - Your first TELA app - XSWD Overview - Secure deployment protocol - TELA CLI - Command-line tools **Advanced Topics:** - TELA Libraries - Reusable components - DocShards - Multi-file applications - Compression - Optimize file sizes",
+      "plainText": "TELA Platform Overview **TELA** is the Decentralized Web Standard for DERO blockchain. Build privacy-first web applications that run entirely on-chain with zero servers, zero censorship, and complete user control. **The Future of Web3:** TELA is the ONLY platform enabling fully private, censorship-resistant web applications with encrypted storage and local execution. The TELA Difference **Traditional Web Architecture:** **TELA Architecture:** What Makes TELA Special? ✨ **Three Revolutionary Features:** | Feature | Traditional Web | TELA | |---------|----------------|------| | **🗄️ Storage** | Centralized servers | DERO blockchain (distributed) | | **🔒 Privacy** | Server logs everything | Local execution (zero tracking) | | **⚡ Performance** | Server latency + downtime | Instant local execution | | **📡 Network** | Always online required | Works offline | | **💰 Costs** | Monthly hosting fees | One-time blockchain fee | | **🌍 Access** | Geo-restrictions possible | Global, unstoppable | | **🛡️ Censorship** | Can be taken down | Impossible to censor | --- 🔐 **True Decentralization** **No servers = No single point of failure** **Traditional Web:** **TELA:** **Result:** TELA applications remain globally available around the clock - no servers to go down, no hosting companies to fail. --- 🔒 **Privacy by Design** **Your data stays on YOUR device** | What Happens | Traditional Web | TELA | |--------------|----------------|------| | **Code execution** | Server-side (they see everything) | Local (you control everything) | | **User data** | Stored on company servers | Stays on your device | | **Activity logs** | Server tracks every action | Zero tracking, zero logs | | **Third parties** | Analytics, ads, trackers | None - completely private | | **Blockchain** | Public ledger (addresses visible) | DERO privacy (encrypted) | --- ⚡ **Local-First Performance** **Instant loading, works offline** | Metric | Traditional Web | TELA | |--------|-----------------|------| | **Initial Load** | Depends on server location | Instant (cached locally) | | **Navigation** | HTTP requests per page | Instant (already local) | | **Offline** | ❌ Doesn't work | ✅ Full functionality | | **Latency** | 50-500ms+ | Under 1ms (local) | | **Blockchain Sync** | N/A | Only when updating content | --- How TELA Works: Dual-Contract System **TELA uses two smart contract types:** **Deployment Flow:** **User Access Flow:** 📋 **INDEX Contract** (Application Manifest) | Contains | Purpose | |----------|---------| | **App Name** | \"My TELA App\" | | **Description** | What the app does | | **Icon** | App thumbnail | | **DOC References** | SCIDs of all files | | **File Paths** | How files are organized | | **Version** | App version number | **Think:** Package.json for on-chain apps --- 📦 **DOC Contract** (Application Files) **Supported File Types:** | Type | File Extension | Max Size | Use Case | |------|----------------|----------|----------| | **HTML** | .html | 18KB | Page structure | | **CSS** | .css | 18KB | Styling | | **JavaScript** | .js | 18KB | Logic & interactivity | | **JSON** | .json | 18KB | Data & config | | **Markdown** | .md | 18KB | Documentation | | **Static Assets** | Images, fonts | 18KB | Assets | **Size limit:** 18KB per DOC contract (blockchain constraint) **Solution:** Split large files across multiple DOC contracts --- Development Workflow **From idea to deployed app:** | Step | Action | Tool | Output | |------|--------|------|--------| | **A** | Write your app | Any code editor | HTML, CSS, JS files | | **B** | Test locally | TELA-CLI serve | Preview in browser | | **C** | Deploy files | TELA-CLI install-doc | DOC contracts (SCIDs) | | **D** | Create manifest | TELA-CLI install-index | INDEX contract (SCID) | | **E** | Share & access | Give users INDEX SCID | App live on blockchain! | Complete Architecture **Full TELA Stack (4 Layers):** | Layer | Component | Function | |-------|-----------|----------| | **👤 User Layer** | User in Engram | Browses and interacts with apps | | **📱 TELA Protocol** | INDEX + DOC contracts | App manifest + code files | | **🔐 Security Layer** | XSWD (port 44326) + Verification | Wallet connection + hash checking | | **💾 Storage Layer** | DERO Blockchain + Wallet | Immutable storage + private keys | **Data Flow:** **Every layer is decentralized, private, and verifiable!** --- Technical Foundation Smart Contract Architecture | Contract Type | Mutability | Purpose | Size Limit | |---------------|------------|---------|------------| | **DOC Contract** | 🔒 Immutable | Store code files | 18KB per file | | **INDEX Contract** | ✏️ Updateable | App metadata & references | Variable | **Why two types?** - **DOC immutability** → Code integrity guaranteed - **INDEX updateability** → Apps can evolve (point to new DOCs) - **User control** → Can verify exact code version running **Version Control:** Supported Languages TELA supports a wide range of file types through its document type system: Community Rating System TELA includes an integrated rating system that helps users evaluate content quality and trustworthiness: - **One rating per DERO account** per contract prevents spam - **Structured 0-99 scale** with meaningful categories and detail tags - **Blockchain transparency** - All ratings are publicly visible - **Community moderation** without centralized gatekeepers Rating Categories | Rating | Category | Meaning | |--------|----------|---------| | 0-9 | Do not use → Broken | Content has serious issues | | 10-49 | Major → Minor issues | Content needs improvement | | 50-59 | Could be improved | Decent quality with room for growth | | 60-69 | Average | Standard quality, meets expectations | | 70-89 | Good → Very good | High quality content | | 90-99 | Exceptional | Outstanding, best-in-class content | Learn more about the Content Rating System. TELA vs Traditional Web | Traditional Web | TELA Applications | |----------------|-------------------| | **Hosted on servers** | **Stored on blockchain** | | **Centralized** | **Decentralized** | | **Privacy concerns** | **Complete privacy** | | **Server dependencies** | **No external dependencies** | | **Can be censored** | **Censorship resistant** | | **Server maintenance costs** | **One-time deployment cost** | | **Geographic restrictions** | **Globally accessible** | Next Steps Ready to start building with TELA? Choose your path: 🎯 } title=\"Quick Start\" href=\"/best-practices\" /> 📚 } title=\"Learn the Concepts\" href=\"/tela/tela-doc-index-structures\" /> 🔧 } title=\"Dive Deep\" href=\"/advanced-features/libraries-overview\" /> --- Related Pages **Understanding TELA:** - TELA Security Model - Privacy and security features - TELA Links - Deep linking system - Content Rating System - Content moderation **Build with TELA:** - Quick Start Tutorial - Your first TELA app - XSWD Overview - Secure deployment protocol - TELA CLI - Command-line tools **Advanced Topics:** - TELA Libraries - Reusable components - DocShards - Multi-file applications - Compression - Optimize file sizes",
       "lastUpdated": "2025-10-22"
     },
     {
@@ -5181,7 +5304,7 @@
         "Contract Code Example",
         "Related Documentation"
       ],
-      "plainText": "TELA-DOC-1 Specification Complete technical specification for TELA-DOC-1 smart contracts - the standard for storing code files on the DERO blockchain. **What is TELA-DOC-1?** A smart contract standard that stores individual files (HTML, CSS, JavaScript, etc.) on the DERO blockchain with cryptographic verification and immutability. Overview TELA-DOC-1 contracts contain the essential code required by TELA applications. Each DOC contract stores a single file with metadata, cryptographic signatures, and content. Key Characteristics | Property | Value | |----------|-------| | **Mutability** | 🔒 Immutable (cannot be changed after deployment) | | **Max Size** | 20KB total contract size | | **Code Limit** | 18KB code content | | **Purpose** | Store individual application files | | **Versioning** | New versions = new SCID (immutable history) | | **Security** | Cryptographically signed by author | --- Supported File Types (docTypes) TELA-DOC-1 supports these document types: | docType | Extension | Purpose | Examples | |---------|-----------|---------|----------| | **TELA-HTML-1** | .html | Page structure | index.html, about.html | | **TELA-CSS-1** | .css | Styling | style.css, theme.css | | **TELA-JS-1** | .js | Application logic | app.js, utils.js | | **TELA-JSON-1** | .json | Data & configuration | config.json, data.json | | **TELA-MD-1** | .md | Documentation | README.md, docs.md | | **TELA-GO-1** | .go | Go source code | main.go, utils.go | | **TELA-STATIC-1** | Other | Images, fonts, assets | logo.png, font.woff | Accepted Languages The civilware/tela Go package validates these languages: **Static Type:** Encompasses any desired files not listed as accepted languages (images, fonts, assets, build files, etc.) --- Size Constraints **Critical Limits - NEVER Exceed These** These are absolute blockchain limits enforced by the DERO network. Hard Limits (from parse.go) | Limit | Size | Constant Name | |-------|------|---------------| | **DOC Code Content** | 18.00 KB | MAX_DOC_CODE_SIZE | | **DOC Total Contract** | 20.00 KB | MAX_DOC_INSTALL_SIZE | | **Recommended Maximum** | 18.00 KB | For reliable deployment | **Why 18KB for code?** - Contract headers and structure use ~2KB - 18KB code + 2KB structure = 20KB total - Staying at 18KB ensures room for headers Size Violations **Error Messages (from source):** **Solutions:** 1. **Minify code** - Remove whitespace and comments 2. **Use compression** - Gzip encoding (automatic with TELA-CLI) 3. **Split into multiple DOCs** - Use DocShards for files >18KB --- Smart Contract Structure TELA-DOC-1 Template The smart contract consists of: Contract Variables (STORE Parameters) | Variable | Type | Required | Description | |----------|------|----------|-------------| | var_header_name | String | Yes | File name (e.g., \"index.html\") | | var_header_description | String | No | Description of the file | | var_header_icon | String | No | Icon URL or SCID (100x100px recommended) | | dURL | String | Yes | Decentralized URL identifier | | docType | String | Yes | File type (TELA-HTML-1, TELA-JS-1, etc.) | | subDir | String | No | Subdirectory path (e.g., \"/assets/\", \"/js/\") | | fileCheckC | String | Yes | Signature C value (cryptographic proof) | | fileCheckS | String | Yes | Signature S value (cryptographic proof) | --- dURL (Decentralized URL) The dURL is a human-readable identifier for the DOC contract. **Important:** dURLs are labels, not enforced unique identifiers. Multiple contracts can have the same dURL. For details on how resolution works and best practices, see Understanding dURLs. Format Guidelines **Standard DOC:** **Library DOC:** **DocShard DOC:** dURL Best Practices - ✅ Use lowercase - ✅ Use descriptive names - ✅ Include file purpose - ✅ Use .lib suffix for libraries - ✅ Use .shard/.shards for DocShards - ❌ Don't use spaces or special characters - ❌ Don't duplicate existing dURLs in your INDEX --- Subdirectories (subDir) Organize files in directory structure: | subDir Value | Result Path | Use Case | |--------------|-------------|----------| | \"\" | /index.html | Root directory | | \"assets/\" | /assets/logo.png | Asset files | | \"js/\" | /js/app.js | JavaScript files | | \"css/\" | /css/style.css | Stylesheets | | \"lib/\" | /lib/utils.js | Libraries | | \"assets/icons/\" | /assets/icons/logo.svg | Nested directories | **Rules:** - Always use forward slashes / - End with / for directories - Can be nested: sub1/sub2/sub3/ --- Cryptographic Signatures TELA-DOC contracts include DERO signatures for file verification. Signature Components | Component | Description | |-----------|-------------| | fileCheckC | C value from DERO signature (hex string) | | fileCheckS | S value from DERO signature (hex string) | How Signatures Work **Purpose:** - **Authenticity** - Proves author created the file - **Integrity** - Detects any tampering - **Trust** - Users can verify code origin --- Deployment Preparation Guidelines Before deploying a TELA-DOC-1: 1. **Size Check:** 2. **Character Encoding:** - Use ASCII characters when possible - Non-ASCII characters should be encoded - Compression handles encoding automatically 3. **Comments:** - /* */ multiline comments **will break deployment** - TELA wraps your code in a DVM-BASIC comment block, so */ prematurely closes it - Use // single-line comments for JavaScript - Remove all /* */ comment blocks from CSS files - Or use compression (recommended) which handles this automatically 4. **Test Locally:** File Content Preparation **HTML Example:** **JavaScript Example:** **CSS Example:** --- Compression TELA supports Gzip compression for DOC content. When to Compress | File Size | Recommendation | |-----------|----------------| | < 10KB | Optional | | 10-15KB | Recommended | | 15-18KB | Strongly recommended | | > 18KB | Required (or use DocShards) | Compression Format **Filename Convention:** **TELA-CLI Handling:** - Automatically compresses when beneficial - Adds .gz extension to nameHdr - Decompresses automatically when serving **Manual Compression:** --- TELA Libraries TELA libraries are reusable code modules designed for universal use across applications. Library Identification **dURL Convention:** **Benefits:** - ✅ Code reuse across applications - ✅ Reduced blockchain bloat - ✅ Community-tested solutions - ✅ Faster development - ✅ Consistent patterns Library Usage **Include in your INDEX:** **Access in your code:** Library Creation **Single-file library:** **Multi-file library:** --- DocShards DocShards enable files larger than 18KB to be deployed across multiple DOC contracts and automatically reconstructed. Shard Size | Constant | Value | Purpose | |----------|-------|---------| | **SHARD_SIZE** | 17,500 bytes | Exact size per shard | **Why 17,500?** - Leaves room for contract structure - Ensures reliable deployment - Prevents size limit violations DocShard Creation **Automatic (TELA-CLI):** **Deploy Shards:** DocShard Reconstruction When cloned or served, shards are automatically reconstructed: **Important:** DocShards cannot be the entrypoint (DOC1) of an INDEX. Use regular DOCs for entrypoint, DocShards for additional files. --- Smart Contract Functions InitializePrivate() **Purpose:** Called once when contract is deployed **Actions:** 1. Stores all metadata (name, description, icon, dURL, etc.) 2. Stores file content in multiline comment 3. Stores cryptographic signature 4. Initializes contract state **Cannot be called again** - Contract is immutable after deployment --- Rate(r Uint64) **Purpose:** Rate the DOC contract quality **Parameters:** - r - Rating value (0-99) **Access:** Public - any wallet can rate **Effect:** - Stores rating from calling wallet - One rating per wallet per contract - Updates overall rating statistics --- Deployment Procedures Using TELA-CLI (Recommended) Manual Deployment (Advanced) **Step 1: Prepare Contract** Edit TELA-DOC-1.bas template: **Step 2: Deploy Contract** **Step 3: Note SCID** The response includes the new contract SCID - save this for use in INDEX contracts. --- Best Practices File Organization **Single-purpose files:** **Avoid kitchen-sink files:** Naming Conventions **File names (var_header_name):** **dURLs:** Size Optimization 1. **Remove unnecessary content:** 2. **Minify before deployment:** 3. **Use compression:** - TELA-CLI handles this automatically - Can reduce size by 60-70% for text files --- Immutability Implications **Critical Understanding:** Once a TELA-DOC-1 is deployed, it **CANNOT be modified**. Plan accordingly! What Immutability Means **Cannot Change:** - ❌ File content - ❌ Metadata (name, description, icon) - ❌ Signature - ❌ Any STORE values **Can Do:** - ✅ Deploy new version (new SCID) - ✅ Update INDEX to point to new version - ✅ Rate the content - ✅ Keep old version accessible Version Management Strategy **Example:** --- Error Handling Common Deployment Errors **Error: \"File too large\"** **Error: \"Invalid docType\"** **Error: \"Invalid signature\"** **Error: \"Contract installation failed\"** --- Advanced Topics Character Encoding **ASCII vs Non-ASCII:** Multi-line Comments **Critical**: /* */ comment blocks **will break TELA deployment**. TELA wraps your code in a DVM-BASIC comment block, so any */ in your file (even in CSS comments or strings) prematurely closes the wrapper and causes parser errors. **Why This Breaks:** TELA stores your file content inside a DVM-BASIC comment: If your file contains */, it closes the wrapper early and the parser tries to read your code as DVM-BASIC syntax → deployment fails. **Problematic:** **Safe:** **Best Solution:** Use compression which handles all comment types automatically, or manually remove all /* */ comment blocks before deployment. File References **Relative paths work:** **How TELA resolves:** --- Contract Code Example Complete example TELA-DOC-1 for an HTML file: --- Related Documentation INDEX contract specification Handling large files File compression techniques Optimize files for blockchain --- **Specification Complete:** You now understand the complete TELA-DOC-1 standard for storing files on the DERO blockchain!",
+      "plainText": "TELA-DOC-1 Specification Complete technical specification for TELA-DOC-1 smart contracts - the standard for storing code files on the DERO blockchain. **What is TELA-DOC-1?** A smart contract standard that stores individual files (HTML, CSS, JavaScript, etc.) on the DERO blockchain with cryptographic verification and immutability. Overview TELA-DOC-1 contracts contain the essential code required by TELA applications. Each DOC contract stores a single file with metadata, cryptographic signatures, and content. Key Characteristics | Property | Value | |----------|-------| | **Mutability** | 🔒 Immutable (cannot be changed after deployment) | | **Max Size** | 20KB total contract size | | **Code Limit** | 18KB code content | | **Purpose** | Store individual application files | | **Versioning** | New versions = new SCID (immutable history) | | **Security** | Cryptographically signed by author | --- Supported File Types (docTypes) TELA-DOC-1 supports these document types: | docType | Extension | Purpose | Examples | |---------|-----------|---------|----------| | **TELA-HTML-1** | .html | Page structure | index.html, about.html | | **TELA-CSS-1** | .css | Styling | style.css, theme.css | | **TELA-JS-1** | .js | Application logic | app.js, utils.js | | **TELA-JSON-1** | .json | Data & configuration | config.json, data.json | | **TELA-MD-1** | .md | Documentation | README.md, docs.md | | **TELA-GO-1** | .go | Go source code | main.go, utils.go | | **TELA-STATIC-1** | Other | Images, fonts, assets | logo.png, font.woff | Accepted Languages The civilware/tela Go package validates these languages: **Static Type:** Encompasses any desired files not listed as accepted languages (images, fonts, assets, build files, etc.) --- Size Constraints **Critical Limits - NEVER Exceed These** These are absolute blockchain limits enforced by the DERO network. Hard Limits (from parse.go) | Limit | Size | Constant Name | |-------|------|---------------| | **DOC Code Content** | 18.00 KB | MAX_DOC_CODE_SIZE | | **DOC Total Contract** | 20.00 KB | MAX_DOC_INSTALL_SIZE | | **Recommended Maximum** | 18.00 KB | For reliable deployment | **Why 18KB for code?** - Contract headers and structure use ~2KB - 18KB code + 2KB structure = 20KB total - Staying at 18KB ensures room for headers Size Violations **Error Messages (from source):** **Solutions:** 1. **Minify code** - Remove whitespace and comments 2. **Use compression** - Gzip encoding (automatic with TELA-CLI) 3. **Split into multiple DOCs** - Use DocShards for files >18KB --- Smart Contract Structure TELA-DOC-1 Template The smart contract consists of: Contract Variables (STORE Parameters) | Variable | Type | Required | Description | |----------|------|----------|-------------| | var_header_name | String | Yes | File name (e.g., \"index.html\") | | var_header_description | String | No | Description of the file | | var_header_icon | String | No | Icon URL or SCID (100x100px recommended) | | dURL | String | Yes | Decentralized URL identifier | | docType | String | Yes | File type (TELA-HTML-1, TELA-JS-1, etc.) | | subDir | String | No | Subdirectory path (e.g., \"/assets/\", \"/js/\") | | fileCheckC | String | Yes | Signature C value (cryptographic proof) | | fileCheckS | String | Yes | Signature S value (cryptographic proof) | --- dURL (Decentralized URL) The dURL is a human-readable identifier for the DOC contract. **Important:** dURLs are labels, not enforced unique identifiers. Multiple contracts can have the same dURL. For details on how resolution works and best practices, see Understanding dURLs. Format Guidelines **Standard DOC:** **Library DOC:** **DocShard DOC:** dURL Best Practices - ✅ Use lowercase - ✅ Use descriptive names - ✅ Include file purpose - ✅ Use .lib suffix for libraries - ✅ Use .shard/.shards for DocShards - ❌ Don't use spaces or special characters - ❌ Don't duplicate existing dURLs in your INDEX --- Subdirectories (subDir) Organize files in directory structure: | subDir Value | Result Path | Use Case | |--------------|-------------|----------| | \"\" | /index.html | Root directory | | \"assets/\" | /assets/logo.png | Asset files | | \"js/\" | /js/app.js | JavaScript files | | \"css/\" | /css/style.css | Stylesheets | | \"lib/\" | /lib/utils.js | Libraries | | \"assets/icons/\" | /assets/icons/logo.svg | Nested directories | **Rules:** - Always use forward slashes / - End with / for directories - Can be nested: sub1/sub2/sub3/ --- Cryptographic Signatures TELA-DOC contracts include DERO signatures for file verification. Signature Components | Component | Description | |-----------|-------------| | fileCheckC | C value from DERO signature (hex string) | | fileCheckS | S value from DERO signature (hex string) | How Signatures Work **Purpose:** - **Authenticity** - Proves author created the file - **Integrity** - Detects any tampering - **Trust** - Users can verify code origin --- Deployment Preparation Guidelines Before deploying a TELA-DOC-1: 1. **Size Check:** 2. **Character Encoding:** - Use ASCII characters when possible - Non-ASCII characters should be encoded - Compression handles encoding automatically 3. **Comments:** - /* */ multiline comments **will break deployment** - TELA wraps your code in a DVM-BASIC comment block, so */ prematurely closes it - Use // single-line comments for JavaScript - Remove all /* */ comment blocks from CSS files - Or use compression (recommended) which handles this automatically 4. **Test Locally:** File Content Preparation **HTML Example:** **JavaScript Example:** **CSS Example:** --- Compression TELA supports Gzip compression for DOC content. When to Compress | File Size | Recommendation | |-----------|----------------| | 18KB | Required (or use DocShards) | Compression Format **Filename Convention:** **TELA-CLI Handling:** - Automatically compresses when beneficial - Adds .gz extension to nameHdr - Decompresses automatically when serving **Manual Compression:** --- TELA Libraries TELA libraries are reusable code modules designed for universal use across applications. Library Identification **dURL Convention:** **Benefits:** - ✅ Code reuse across applications - ✅ Reduced blockchain bloat - ✅ Community-tested solutions - ✅ Faster development - ✅ Consistent patterns Library Usage **Include in your INDEX:** **Access in your code:** Library Creation **Single-file library:** **Multi-file library:** --- DocShards DocShards enable files larger than 18KB to be deployed across multiple DOC contracts and automatically reconstructed. Shard Size | Constant | Value | Purpose | |----------|-------|---------| | **SHARD_SIZE** | 17,500 bytes | Exact size per shard | **Why 17,500?** - Leaves room for contract structure - Ensures reliable deployment - Prevents size limit violations DocShard Creation **Automatic (TELA-CLI):** **Deploy Shards:** DocShard Reconstruction When cloned or served, shards are automatically reconstructed: **Important:** DocShards cannot be the entrypoint (DOC1) of an INDEX. Use regular DOCs for entrypoint, DocShards for additional files. --- Smart Contract Functions InitializePrivate() **Purpose:** Called once when contract is deployed **Actions:** 1. Stores all metadata (name, description, icon, dURL, etc.) 2. Stores file content in multiline comment 3. Stores cryptographic signature 4. Initializes contract state **Cannot be called again** - Contract is immutable after deployment --- Rate(r Uint64) **Purpose:** Rate the DOC contract quality **Parameters:** - r - Rating value (0-99) **Access:** Public - any wallet can rate **Effect:** - Stores rating from calling wallet - One rating per wallet per contract - Updates overall rating statistics --- Deployment Procedures Using TELA-CLI (Recommended) Manual Deployment (Advanced) **Step 1: Prepare Contract** Edit TELA-DOC-1.bas template: **Step 2: Deploy Contract** **Step 3: Note SCID** The response includes the new contract SCID - save this for use in INDEX contracts. --- Best Practices File Organization **Single-purpose files:** **Avoid kitchen-sink files:** Naming Conventions **File names (var_header_name):** **dURLs:** Size Optimization 1. **Remove unnecessary content:** 2. **Minify before deployment:** 3. **Use compression:** - TELA-CLI handles this automatically - Can reduce size by 60-70% for text files --- Immutability Implications **Critical Understanding:** Once a TELA-DOC-1 is deployed, it **CANNOT be modified**. Plan accordingly! What Immutability Means **Cannot Change:** - ❌ File content - ❌ Metadata (name, description, icon) - ❌ Signature - ❌ Any STORE values **Can Do:** - ✅ Deploy new version (new SCID) - ✅ Update INDEX to point to new version - ✅ Rate the content - ✅ Keep old version accessible Version Management Strategy **Example:** --- Error Handling Common Deployment Errors **Error: \"File too large\"** **Error: \"Invalid docType\"** **Error: \"Invalid signature\"** **Error: \"Contract installation failed\"** --- Advanced Topics Character Encoding **ASCII vs Non-ASCII:** Multi-line Comments **Critical**: /* */ comment blocks **will break TELA deployment**. TELA wraps your code in a DVM-BASIC comment block, so any */ in your file (even in CSS comments or strings) prematurely closes the wrapper and causes parser errors. **Why This Breaks:** TELA stores your file content inside a DVM-BASIC comment: If your file contains */, it closes the wrapper early and the parser tries to read your code as DVM-BASIC syntax → deployment fails. **Problematic:** **Safe:** **Best Solution:** Use compression which handles all comment types automatically, or manually remove all /* */ comment blocks before deployment. File References **Relative paths work:** **How TELA resolves:** --- Contract Code Example Complete example TELA-DOC-1 for an HTML file: --- Related Documentation INDEX contract specification Handling large files File compression techniques Optimize files for blockchain --- **Specification Complete:** You now understand the complete TELA-DOC-1 standard for storing files on the DERO blockchain!",
       "lastUpdated": "2025-10-22"
     },
     {
@@ -5281,7 +5404,7 @@
         "Complete Contract Example",
         "Related Documentation"
       ],
-      "plainText": "TELA-INDEX-1 Specification Complete technical specification for TELA-INDEX-1 smart contracts - the manifest standard that ties TELA applications together. **What is TELA-INDEX-1?** A smart contract that serves as the entrypoint for TELA applications. It references all DOC contracts (files) and provides updateable metadata for your application. Overview TELA-INDEX-1 contracts serve as the \"package.json\" or \"manifest\" for TELA applications. Users enter a single INDEX SCID to access the entire application. Key Characteristics | Property | Value | |----------|-------| | **Mutability** | ✏️ Updateable (if deployed with ringsize 2) | | **Purpose** | Application manifest and entrypoint | | **References** | Lists all DOC contract SCIDs | | **Versioning** | Built-in commit system tracks updates | | **Max Size** | Variable (see size limits below) | | **MOD Support** | Can integrate TELA-MOD-1 extensions | --- Size Limitations **Critical Size Constraints** INDEX size directly impacts updateability and capacity. Size Limits (from source code) | Limit | Size | Purpose | |-------|------|---------| | **Maximum Installation** | 11.64 KB | MAX_INDEX_INSTALL_SIZE | | **Recommended for Updates** | 9 KB | Ensures room for future updates | | **Maximum Practical** | ~11 KB | Absolute deployment limit | Capacity Estimates | INDEX Size | DOC Capacity | Updateable? | |------------|--------------|-------------| | **< 9 KB** | ~90 DOCs | ✅ Yes (room for growth) | | **9-11 KB** | ~100-120 DOCs | ⚠️ Limited update capacity | | **> 11.64 KB** | N/A | ❌ Cannot deploy | **Testing Results (from source):** - **~90 DOCs**: Reliable updates, can add more later - **~120 DOCs**: Maximum capacity, may not accept additional DOCs in updates **Size Management:** Use DocShards and Libraries to include more content without bloating INDEX size. Each SCID reference is ~64 bytes. --- Smart Contract Structure TELA-INDEX-1 Template Contract Variables | Variable | Type | Required | Description | |----------|------|----------|-------------| | var_header_name | String | Yes | Application name | | var_header_description | String | No | App description | | var_header_icon | String | No | Icon URL or SCID (100x100px) | | dURL | String | Yes | Unique app identifier (e.g., \"myapp.tela\") | | mods | String | No | Comma-separated MOD tags (e.g., \"vsoo,txdwd\") | | DOC1 | String | Yes | Entrypoint DOC SCID (minimum requirement) | | DOC2...DOCn | String | No | Additional DOC SCIDs | | commit | Uint64 | Auto | Version counter (0, 1, 2, 3...) | | 0, 1, 2... | String | Auto | Commit TXID history | | hash | String | Auto | Current commit hash | --- Smart Contract Functions InitializePrivate() **Purpose:** Initialize contract on deployment **Called:** Once, automatically at deployment **Actions:** 1. Stores application metadata 2. Stores all DOC references 3. Initializes version tracking 4. Sets up MOD integration (if specified) **Cannot be modified** after deployment (immutable initialization) --- UpdateCode(mods String, code String) **Purpose:** Update INDEX contract with new configuration **Parameters:** - mods (String) - MOD tags to enable/disable - code (String) - New smart contract code **Access:** Contract owner only **Actions:** 1. Increments commit counter 2. Stores update TXID 3. Updates hash to current TXID 4. Deploys new contract code **Version Tracking:** **Complete History:** Every update is preserved on the blockchain. Users can access any historical version using commit TXIDs. --- Rate(r Uint64) **Purpose:** Rate the INDEX contract quality **Parameters:** - r (Uint64) - Rating value (0-99) **Access:** Public - any wallet can rate **Effect:** - Stores rating from calling wallet - One rating per wallet per contract - Updates overall rating statistics --- Updateability & Immutability Update Rules | Deployment Type | Ringsize | Updateable? | |----------------|----------|-------------| | **Public Deployment** | 2 | ✅ Yes - owner can update | | **Anonymous Deployment** | > 2 | ❌ No - permanently immutable | **Critical:** Once deployed with ringsize > 2, the INDEX is **permanently immutable**. Choose wisely during deployment! What Can Be Updated **Via UpdateCode:** - ✅ DOC references (add/remove/change DOCs) - ✅ Application metadata (name, description, icon) - ✅ MOD configuration (add/remove MODs) - ✅ dURL identifier - ❌ Contract SCID (this never changes) - ❌ Contract owner (without Transfer Ownership MOD) **Via SetVar (with MOD):** - ✅ Dynamic variables (var_*) - ✅ Custom metadata (var_meta_*) - ✅ Owner notes (var_owners_note) - ❌ Does NOT create new commit version UpdateCode vs SetVar | Operation | Creates Commit? | Use Case | |-----------|----------------|----------| | **UpdateCode** | ✅ Yes | Code changes, DOC updates, major versions | | **SetVar** | ❌ No | Dynamic data, metadata updates, minor tweaks | **Example:** --- TELA-MOD-1 Integration INDEX contracts can integrate TELA-MOD-1 modules for extended functionality. MODs Field **Format:** Comma-separated MOD tags **Available MODs:** - **Variable Store:** vsoo, vsooim, vspubsu, vspubow, vspubim - **Transfers:** txdwd, txdwa, txto MODs at Deployment MODs in Updates **Learn more:** TELA-MOD-1 Documentation --- Deployment Procedures Using TELA-CLI (Recommended) Manual Deployment (Advanced) **Step 1: Prepare TELA-INDEX-1.bas** Edit the template with your values: **Step 2: Deploy** --- Update Procedures Update INDEX with TELA-CLI Manual Update (Advanced) **GetGasEstimate:** **Execute Update Transaction:** --- Version Control System Built-in Commit Tracking TELA-INDEX-1 automatically tracks all updates: Accessing Version History Clone Specific Version Serve Version Control --- DOC References DOC1 (Entrypoint) **Special Requirement:** DOC1 must be a valid TELA-DOC-1 SCID **Purpose:** - Primary file loaded when INDEX is accessed - Usually index.html for web apps - Must exist and be valid for INDEX to work **Validation:** - Cannot be empty - Must be 64-character hex SCID - Must reference valid TELA-DOC-1 contract **CRITICAL: Your entrypoint file MUST be named index.html** TELA browsers (including Hologram) look for index.html as the default entry point. If your DOC1 file is named something else (like myapp.html, main.html, or Snake_Deluxe.html), **your app will NOT render correctly** - users will see a file listing instead of your application. **Common Mistake:** **Solution:** Always name your main HTML file index.html before deploying as DOC1. Additional DOCs (DOC2, DOC3, etc.) **Format:** **Rules:** - Sequential numbering (DOC1, DOC2, DOC3...) - All DOC stores must have valid SCID values - Empty/invalid DOC stores will cause validation failure - Can include regular DOCs, libraries, and DocShards Maximum DOCs **Practical Limits:** **Each DOC SCID adds:** - ~64 bytes for the SCID itself - ~10-20 bytes for STORE structure - ~80 bytes total per DOC reference **Calculation:** --- dURL Conventions The INDEX dURL identifies your application: **Deep Dive:** dURLs are human-friendly labels, not unique identifiers. Multiple contracts can share the same dURL. For a complete explanation of how dURL resolution works and what to do when things go wrong, see Understanding dURLs. Standard Applications Special Suffixes | Suffix | Purpose | Example | |--------|---------|---------| | .lib | Library INDEX | mylib.tela.lib | | .shards | DocShard reconstruction | largefile.tela.shards | dURL Best Practices - ✅ Descriptive and memorable - ✅ Lowercase preferred - ✅ Use hyphens for spaces (my-app.tela) - ✅ Unique within your application ecosystem - ❌ Don't use special characters - ❌ Don't use spaces - ❌ Don't exceed reasonable length (keep under 32 chars) --- Rating Integration INDEX contracts include built-in rating functionality: Rating via TELA-CLI Rating via Manual Transaction **GetGasEstimate:** **Execute Transaction:** --- Complete Example Minimal INDEX (1 DOC) Multi-File INDEX (5 DOCs) INDEX with MODs --- Best Practices Deployment Strategy **1. Plan Your Structure:** **2. Deploy DOCs First:** **3. Create INDEX Last:** Update Strategy **When to Update:** - ✅ Adding new files (new DOC) - ✅ Replacing old files (point to new DOC SCID) - ✅ Removing unused files (reduce DOC count) - ✅ Adding/removing MODs - ✅ Updating metadata **When to Deploy New INDEX:** - ✅ Complete redesign - ✅ Forking/cloning app - ✅ Creating alternative version Ringsize Decisions **Ringsize 2 (Updateable):** - ✅ Can update later - ✅ Owner address is public - ✅ Flexible development **Ringsize > 2 (Immutable):** - ✅ Maximum privacy/anonymity - ✅ Cannot be censored by owner - ❌ Cannot be updated (permanent!) --- Error Handling Common Errors **Error: \"Invalid DOC1 SCID\"** **Error: \"INDEX size exceeds maximum\"** **Error: \"Cannot update INDEX\"** **Error: \"MOD validation failed\"** --- Advanced Features Dynamic Metadata (with MODs) **Update metadata without UpdateCode:** **Benefits:** - ❌ Doesn't create new commit version - ✅ Instant metadata updates - ✅ Lower transaction fees - ✅ Useful for status messages Library Bundles Create an INDEX that bundles multiple libraries: **Usage:** Other apps can reference this one INDEX SCID to get all libraries DocShard INDEX Create an INDEX that reconstructs large files: **Auto-reconstruction:** TELA detects .shards tag and rebuilds the file --- Complete Contract Example Full TELA-INDEX-1 with MODs and multiple DOCs: --- Related Documentation DOC contract specification Extend INDEX with MODs Managing updates and versions Handle large file collections --- **Specification Complete:** You now understand the complete TELA-INDEX-1 standard for creating application manifests on the DERO blockchain!",
+      "plainText": "TELA-INDEX-1 Specification Complete technical specification for TELA-INDEX-1 smart contracts - the manifest standard that ties TELA applications together. **What is TELA-INDEX-1?** A smart contract that serves as the entrypoint for TELA applications. It references all DOC contracts (files) and provides updateable metadata for your application. Overview TELA-INDEX-1 contracts serve as the \"package.json\" or \"manifest\" for TELA applications. Users enter a single INDEX SCID to access the entire application. Key Characteristics | Property | Value | |----------|-------| | **Mutability** | ✏️ Updateable (if deployed with ringsize 2) | | **Purpose** | Application manifest and entrypoint | | **References** | Lists all DOC contract SCIDs | | **Versioning** | Built-in commit system tracks updates | | **Max Size** | Variable (see size limits below) | | **MOD Support** | Can integrate TELA-MOD-1 extensions | --- Size Limitations **Critical Size Constraints** INDEX size directly impacts updateability and capacity. Size Limits (from source code) | Limit | Size | Purpose | |-------|------|---------| | **Maximum Installation** | 11.64 KB | MAX_INDEX_INSTALL_SIZE | | **Recommended for Updates** | 9 KB | Ensures room for future updates | | **Maximum Practical** | ~11 KB | Absolute deployment limit | Capacity Estimates | INDEX Size | DOC Capacity | Updateable? | |------------|--------------|-------------| | ** 11.64 KB** | N/A | ❌ Cannot deploy | **Testing Results (from source):** - **~90 DOCs**: Reliable updates, can add more later - **~120 DOCs**: Maximum capacity, may not accept additional DOCs in updates **Size Management:** Use DocShards and Libraries to include more content without bloating INDEX size. Each SCID reference is ~64 bytes. --- Smart Contract Structure TELA-INDEX-1 Template Contract Variables | Variable | Type | Required | Description | |----------|------|----------|-------------| | var_header_name | String | Yes | Application name | | var_header_description | String | No | App description | | var_header_icon | String | No | Icon URL or SCID (100x100px) | | dURL | String | Yes | Unique app identifier (e.g., \"myapp.tela\") | | mods | String | No | Comma-separated MOD tags (e.g., \"vsoo,txdwd\") | | DOC1 | String | Yes | Entrypoint DOC SCID (minimum requirement) | | DOC2...DOCn | String | No | Additional DOC SCIDs | | commit | Uint64 | Auto | Version counter (0, 1, 2, 3...) | | 0, 1, 2... | String | Auto | Commit TXID history | | hash | String | Auto | Current commit hash | --- Smart Contract Functions InitializePrivate() **Purpose:** Initialize contract on deployment **Called:** Once, automatically at deployment **Actions:** 1. Stores application metadata 2. Stores all DOC references 3. Initializes version tracking 4. Sets up MOD integration (if specified) **Cannot be modified** after deployment (immutable initialization) --- UpdateCode(mods String, code String) **Purpose:** Update INDEX contract with new configuration **Parameters:** - mods (String) - MOD tags to enable/disable - code (String) - New smart contract code **Access:** Contract owner only **Actions:** 1. Increments commit counter 2. Stores update TXID 3. Updates hash to current TXID 4. Deploys new contract code **Version Tracking:** **Complete History:** Every update is preserved on the blockchain. Users can access any historical version using commit TXIDs. --- Rate(r Uint64) **Purpose:** Rate the INDEX contract quality **Parameters:** - r (Uint64) - Rating value (0-99) **Access:** Public - any wallet can rate **Effect:** - Stores rating from calling wallet - One rating per wallet per contract - Updates overall rating statistics --- Updateability & Immutability Update Rules | Deployment Type | Ringsize | Updateable? | |----------------|----------|-------------| | **Public Deployment** | 2 | ✅ Yes - owner can update | | **Anonymous Deployment** | > 2 | ❌ No - permanently immutable | **Critical:** Once deployed with ringsize > 2, the INDEX is **permanently immutable**. Choose wisely during deployment! What Can Be Updated **Via UpdateCode:** - ✅ DOC references (add/remove/change DOCs) - ✅ Application metadata (name, description, icon) - ✅ MOD configuration (add/remove MODs) - ✅ dURL identifier - ❌ Contract SCID (this never changes) - ❌ Contract owner (without Transfer Ownership MOD) **Via SetVar (with MOD):** - ✅ Dynamic variables (var_*) - ✅ Custom metadata (var_meta_*) - ✅ Owner notes (var_owners_note) - ❌ Does NOT create new commit version UpdateCode vs SetVar | Operation | Creates Commit? | Use Case | |-----------|----------------|----------| | **UpdateCode** | ✅ Yes | Code changes, DOC updates, major versions | | **SetVar** | ❌ No | Dynamic data, metadata updates, minor tweaks | **Example:** --- TELA-MOD-1 Integration INDEX contracts can integrate TELA-MOD-1 modules for extended functionality. MODs Field **Format:** Comma-separated MOD tags **Available MODs:** - **Variable Store:** vsoo, vsooim, vspubsu, vspubow, vspubim - **Transfers:** txdwd, txdwa, txto MODs at Deployment MODs in Updates **Learn more:** TELA-MOD-1 Documentation --- Deployment Procedures Using TELA-CLI (Recommended) Manual Deployment (Advanced) **Step 1: Prepare TELA-INDEX-1.bas** Edit the template with your values: **Step 2: Deploy** --- Update Procedures Update INDEX with TELA-CLI Manual Update (Advanced) **GetGasEstimate:** **Execute Update Transaction:** --- Version Control System Built-in Commit Tracking TELA-INDEX-1 automatically tracks all updates: Accessing Version History Clone Specific Version Serve Version Control --- DOC References DOC1 (Entrypoint) **Special Requirement:** DOC1 must be a valid TELA-DOC-1 SCID **Purpose:** - Primary file loaded when INDEX is accessed - Usually index.html for web apps - Must exist and be valid for INDEX to work **Validation:** - Cannot be empty - Must be 64-character hex SCID - Must reference valid TELA-DOC-1 contract **CRITICAL: Your entrypoint file MUST be named index.html** TELA browsers (including Hologram) look for index.html as the default entry point. If your DOC1 file is named something else (like myapp.html, main.html, or Snake_Deluxe.html), **your app will NOT render correctly** - users will see a file listing instead of your application. **Common Mistake:** **Solution:** Always name your main HTML file index.html before deploying as DOC1. Additional DOCs (DOC2, DOC3, etc.) **Format:** **Rules:** - Sequential numbering (DOC1, DOC2, DOC3...) - All DOC stores must have valid SCID values - Empty/invalid DOC stores will cause validation failure - Can include regular DOCs, libraries, and DocShards Maximum DOCs **Practical Limits:** **Each DOC SCID adds:** - ~64 bytes for the SCID itself - ~10-20 bytes for STORE structure - ~80 bytes total per DOC reference **Calculation:** --- dURL Conventions The INDEX dURL identifies your application: **Deep Dive:** dURLs are human-friendly labels, not unique identifiers. Multiple contracts can share the same dURL. For a complete explanation of how dURL resolution works and what to do when things go wrong, see Understanding dURLs. Standard Applications Special Suffixes | Suffix | Purpose | Example | |--------|---------|---------| | .lib | Library INDEX | mylib.tela.lib | | .shards | DocShard reconstruction | largefile.tela.shards | dURL Best Practices - ✅ Descriptive and memorable - ✅ Lowercase preferred - ✅ Use hyphens for spaces (my-app.tela) - ✅ Unique within your application ecosystem - ❌ Don't use special characters - ❌ Don't use spaces - ❌ Don't exceed reasonable length (keep under 32 chars) --- Rating Integration INDEX contracts include built-in rating functionality: Rating via TELA-CLI Rating via Manual Transaction **GetGasEstimate:** **Execute Transaction:** --- Complete Example Minimal INDEX (1 DOC) Multi-File INDEX (5 DOCs) INDEX with MODs --- Best Practices Deployment Strategy **1. Plan Your Structure:** **2. Deploy DOCs First:** **3. Create INDEX Last:** Update Strategy **When to Update:** - ✅ Adding new files (new DOC) - ✅ Replacing old files (point to new DOC SCID) - ✅ Removing unused files (reduce DOC count) - ✅ Adding/removing MODs - ✅ Updating metadata **When to Deploy New INDEX:** - ✅ Complete redesign - ✅ Forking/cloning app - ✅ Creating alternative version Ringsize Decisions **Ringsize 2 (Updateable):** - ✅ Can update later - ✅ Owner address is public - ✅ Flexible development **Ringsize > 2 (Immutable):** - ✅ Maximum privacy/anonymity - ✅ Cannot be censored by owner - ❌ Cannot be updated (permanent!) --- Error Handling Common Errors **Error: \"Invalid DOC1 SCID\"** **Error: \"INDEX size exceeds maximum\"** **Error: \"Cannot update INDEX\"** **Error: \"MOD validation failed\"** --- Advanced Features Dynamic Metadata (with MODs) **Update metadata without UpdateCode:** **Benefits:** - ❌ Doesn't create new commit version - ✅ Instant metadata updates - ✅ Lower transaction fees - ✅ Useful for status messages Library Bundles Create an INDEX that bundles multiple libraries: **Usage:** Other apps can reference this one INDEX SCID to get all libraries DocShard INDEX Create an INDEX that reconstructs large files: **Auto-reconstruction:** TELA detects .shards tag and rebuilds the file --- Complete Contract Example Full TELA-INDEX-1 with MODs and multiple DOCs: --- Related Documentation DOC contract specification Extend INDEX with MODs Managing updates and versions Handle large file collections --- **Specification Complete:** You now understand the complete TELA-INDEX-1 standard for creating application manifests on the DERO blockchain!",
       "lastUpdated": "2025-10-22"
     },
     {
@@ -5364,7 +5487,7 @@
         "Next Steps",
         "Related Pages"
       ],
-      "plainText": "TELA Project Templates Ready-to-use project templates for building TELA applications quickly. All templates follow TELA size constraints and best practices. 🚀 Quick Start Templates These templates provide working TELA applications you can customize and deploy immediately. Each template includes complete HTML, CSS, and JavaScript with XSWD integration and follows TELA design system patterns. Available Templates <Card icon={ ⚡ } title=\"XSWD Advanced (Official)\" href=\"/templates/xswd-advanced\" > Production-grade XSWD library with comprehensive API coverage (25KB, requires compression) <Card icon={ 🔋 } title=\"XSWD Basic Core\" href=\"/templates/xswd-basic\" > Lightweight XSWD library for basic connectivity (15KB, no compression needed) <Card icon={ 📄 } title=\"Basic TELA App\" href=\"/templates/basic-app\" > Complete starter application with XSWD integration, wallet connectivity, and modern UI <Card icon={ 📦 } title=\"TELA API Template (Downloadable)\" href=\"/examples/templates/tela-api-template.js\" > Complete JavaScript library with all DERO/TELA RPC methods (~17KB, pure JS, no dependencies) Downloadable Code Templates **Direct Download**: tela-api-template.js - Complete DERO/TELA API implementation you can include in any TELA application. Right-click and save, or copy the code directly. Template Features What's Included in Every Template ✅ **Complete file structure** (HTML, CSS, JS) ✅ **TELA design system** styling ✅ **XSWD Advanced integration** for robust wallet connectivity ✅ **Size optimization** (with compression guidance) ✅ **Responsive design** for all devices ✅ **Production-grade error handling** and loading states ✅ **Real DERO data** integration with fallback modes ✅ **Copy-paste ready** code with deployment instructions Template Structure Quick Start Workflow 1. Choose Your Template Pick the template that best matches your project needs: **For Most Applications:** - **Basic TELA App** - Complete starter with wallet integration and UI **XSWD Libraries (Choose One):** - **XSWD Advanced** - Full-featured, production-ready (recommended) - **XSWD Basic Core** - Lightweight for size-constrained apps 2. Copy Template Files Each template page provides complete, copy-paste ready code for all files. 3. Customize for Your Needs - Update application name and description - Modify colors and styling as needed - Add your specific functionality - Test locally with tela-cli serve local 4. Deploy to TELA Template Customization Guide Color Theme Customization Application Name Customization Adding Custom Features Best Practices for Templates **Template Development Guidelines** - **Keep it simple** - Templates should be easy to understand and modify - **Follow size limits** - All files must stay under 18KB - **Use proven patterns** - Based on working TELA applications - **Include error handling** - Graceful degradation for network issues - **Test thoroughly** - Verify templates work with real DERO data File Size Management Template Testing Workflow --- Next Steps 1. **Choose a Template** - Start with the basic app template 2. **Learn Best Practices** - Production development guide 3. **Customize Design** - Use design system components 4. **Deploy Your App** - Deploy using TELA-CLI Ready to Build Your TELA Application? These templates provide everything you need to start building immediately. Choose a template, customize it, and deploy to the DERO blockchain. <a href=\"/templates/basic-app\" className=\"px-6 py-3 bg-purple-600 text-white rounded-lg hover:bg-purple-700 transition-colors\" > Start with Basic App <a href=\"/templates/xswd-advanced\" className=\"px-6 py-3 border border-purple-600 text-purple-600 dark:text-purple-400 rounded-lg hover:bg-purple-50 dark:hover:bg-purple-900/20 transition-colors\" > Get XSWD Library --- Related Pages **Available Templates:** - Basic TELA App - Complete starter template - XSWD Advanced - Official XSWD library - XSWD Basic Core - Lightweight XSWD - TELA API Template (Download) - Complete API library **Development Resources:** - First App Tutorial - From zero to deployed app - API Reference - Complete API documentation - JavaScript Guidelines - Proven code patterns **Deployment:** - TELA CLI Workflows - Production deployment - XSWD Protocol - Wallet integration - Size Optimization - File optimization",
+      "plainText": "TELA Project Templates Ready-to-use project templates for building TELA applications quickly. All templates follow TELA size constraints and best practices. 🚀 Quick Start Templates These templates provide working TELA applications you can customize and deploy immediately. Each template includes complete HTML, CSS, and JavaScript with XSWD integration and follows TELA design system patterns. Available Templates ⚡ } title=\"XSWD Advanced (Official)\" href=\"/templates/xswd-advanced\" > Production-grade XSWD library with comprehensive API coverage (25KB, requires compression) 🔋 } title=\"XSWD Basic Core\" href=\"/templates/xswd-basic\" > Lightweight XSWD library for basic connectivity (15KB, no compression needed) 📄 } title=\"Basic TELA App\" href=\"/templates/basic-app\" > Complete starter application with XSWD integration, wallet connectivity, and modern UI 📦 } title=\"TELA API Template (Downloadable)\" href=\"/examples/templates/tela-api-template.js\" > Complete JavaScript library with all DERO/TELA RPC methods (~17KB, pure JS, no dependencies) Downloadable Code Templates **Direct Download**: tela-api-template.js - Complete DERO/TELA API implementation you can include in any TELA application. Right-click and save, or copy the code directly. Template Features What's Included in Every Template ✅ **Complete file structure** (HTML, CSS, JS) ✅ **TELA design system** styling ✅ **XSWD Advanced integration** for robust wallet connectivity ✅ **Size optimization** (with compression guidance) ✅ **Responsive design** for all devices ✅ **Production-grade error handling** and loading states ✅ **Real DERO data** integration with fallback modes ✅ **Copy-paste ready** code with deployment instructions Template Structure Quick Start Workflow 1. Choose Your Template Pick the template that best matches your project needs: **For Most Applications:** - **Basic TELA App** - Complete starter with wallet integration and UI **XSWD Libraries (Choose One):** - **XSWD Advanced** - Full-featured, production-ready (recommended) - **XSWD Basic Core** - Lightweight for size-constrained apps 2. Copy Template Files Each template page provides complete, copy-paste ready code for all files. 3. Customize for Your Needs - Update application name and description - Modify colors and styling as needed - Add your specific functionality - Test locally with tela-cli serve local 4. Deploy to TELA Template Customization Guide Color Theme Customization Application Name Customization Adding Custom Features Best Practices for Templates **Template Development Guidelines** - **Keep it simple** - Templates should be easy to understand and modify - **Follow size limits** - All files must stay under 18KB - **Use proven patterns** - Based on working TELA applications - **Include error handling** - Graceful degradation for network issues - **Test thoroughly** - Verify templates work with real DERO data File Size Management Template Testing Workflow --- Next Steps 1. **Choose a Template** - Start with the basic app template 2. **Learn Best Practices** - Production development guide 3. **Customize Design** - Use design system components 4. **Deploy Your App** - Deploy using TELA-CLI Ready to Build Your TELA Application? These templates provide everything you need to start building immediately. Choose a template, customize it, and deploy to the DERO blockchain. Start with Basic App Get XSWD Library --- Related Pages **Available Templates:** - Basic TELA App - Complete starter template - XSWD Advanced - Official XSWD library - XSWD Basic Core - Lightweight XSWD - TELA API Template (Download) - Complete API library **Development Resources:** - First App Tutorial - From zero to deployed app - API Reference - Complete API documentation - JavaScript Guidelines - Proven code patterns **Deployment:** - TELA CLI Workflows - Production deployment - XSWD Protocol - Wallet integration - Size Optimization - File optimization",
       "lastUpdated": "2025-10-19"
     },
     {
@@ -5527,7 +5650,7 @@
         "Learning Resources",
         "Tutorial Summary"
       ],
-      "plainText": "Launch a TELA site (CLI) Prerequisites 1. TELA-CLI installed (from source) 2. DERO wallet Testnet or Mainnet 3. Basic text editor (VS Code recommended) TELA-CLI Commands Here are some essential commands to get you started: | Command | Description | |---------|-------------| | install-doc [file] | Deploy a TELA-DOC contract (prompts for file if not specified). | | install-index [name] | Deploy a TELA-INDEX contract (prompts for name if not specified). | | serve | Serve TELA content from a specific SCID. | | rate | Rate a TELA smart contract. | | clone | Clone TELA application files locally. | | endpoint | Connect to network (simulator, testnet, mainnet). | Step 1: Launch TELA-CLI **Option A: If installed globally:** **Option B: From source directory:** **With options (optional):** <ZoomableImage src=\"/assets/tutorials/tela-launch.png\" alt=\"TELA-CLI Launch\" width={800} height={450} /> Step 2: Select Network **Choose your deployment network:** Step 3: Wallet Connection Connect your wallet. Step 4: Clone the Template (Optional) TELA's immutable update system creates new versions with each change. When cloning, you can specify the exact TXID to ensure you get the correct version. If there has been no changes to the page you can paste the SCID only. After you make updates to your page you must specify both the SCID and TXID to clone the exact version you want. <ZoomableImage src=\"/assets/tutorials/tela-clone.png\" alt=\"TELA-CLI Clone\" width={800} height={450} /> Step 5: Modify Template Files The cloned files will be saved to: /datashards/clone/TELA-template/index.html. Edit index.html with your preferred editor: <ZoomableImage src=\"/assets/tutorials/tela-edit.png\" alt=\"TELA-CLI Code Editing\" width={800} height={450} /> Optional Create a dedicated directory for your files. Copy the index.html file from the datashards directory and paste it into your new directory. Step 6: Install Modified Document **File Path Tip:** You can also provide the file path directly: install-doc /path/to/your/index.html **Compression:** TELA automatically handles compression based on file size. Files are compressed if needed to meet blockchain size limits. <ZoomableImage src=\"/assets/tutorials/tela-install-doc.png\" alt=\"Install DOC Process\" width={800} height={450} /> Step 7: Create Index Contract **Quick Install:** You can also provide the name directly: install-index \"My App Name\" **MODs are Optional:** For your first app, skip MODs (press enter). Learn about TELA-MOD-1 for advanced features like variable storage and DERO deposits. <ZoomableImage src=\"/assets/tutorials/tela-install-index.png\" alt=\"Install Index Process\" width={800} height={450} /> Step 8: Serve Your TELA Site Server will start on localhost (default port 8082): **Access your app:** Open http://localhost:8082 in your browser! **Congratulations!** You've successfully deployed your first TELA application to the DERO blockchain! Step 9: Share Your Application (Optional) Share your app with others by providing the INDEX SCID: Final Result <ZoomableImage src=\"/assets/tutorials/tela-final.png\" alt=\"Final TELA Page\" width={800} height={450} /> --- Common Issues & Solutions Issue: \"No daemon connection\" **Solution:** Issue: \"Insufficient balance\" **Solution:** - **Simulator:** Provides free DERO automatically - **Testnet:** Use DERO testnet faucet - **Mainnet:** Ensure wallet has sufficient DERO for deployment Issue: \"File too large\" **Solution:** Issue: \"Cannot find wallet file\" **Solution:** --- Next Steps Enhance Your Application 1. **Add More Files:** 2. **Enable MODs:** - Variable Storage - Store app data - DERO Transfers - Accept payments - Transfer Ownership - Transfer your app 3. **Add XSWD Integration:** - Use XSWD Advanced library - Connect to DERO wallet from your app - Access blockchain data in real-time Learning Resources Advanced deployment workflows and automation Extend your app with modular functionality Complete troubleshooting guide Optimize files for blockchain deployment --- Tutorial Summary **What You Accomplished:** - ✅ Launched TELA-CLI and connected to network - ✅ Connected your DERO wallet - ✅ Deployed a TELA-DOC contract (your HTML file) - ✅ Created a TELA-INDEX contract (your application manifest) - ✅ Served your app locally and verified it works - ✅ Published your first decentralized web application on DERO blockchain! **Key Concepts Learned:** - 📋 **INDEX contracts** - Application manifests that reference DOC files - 📄 **DOC contracts** - Immutable code files stored on blockchain - 🔗 **SCIDs** - Smart Contract IDs for accessing deployed content - 🌐 **Networks** - Simulator (testing), Testnet, Mainnet (production) You're now ready to build more complex TELA applications! Check out the First App Tutorial for advanced features and patterns.",
+      "plainText": "Launch a TELA site (CLI) Prerequisites 1. TELA-CLI installed (from source) 2. DERO wallet Testnet or Mainnet 3. Basic text editor (VS Code recommended) TELA-CLI Commands Here are some essential commands to get you started: | Command | Description | |---------|-------------| | install-doc [file] | Deploy a TELA-DOC contract (prompts for file if not specified). | | install-index [name] | Deploy a TELA-INDEX contract (prompts for name if not specified). | | serve | Serve TELA content from a specific SCID. | | rate | Rate a TELA smart contract. | | clone | Clone TELA application files locally. | | endpoint | Connect to network (simulator, testnet, mainnet). | Step 1: Launch TELA-CLI **Option A: If installed globally:** **Option B: From source directory:** **With options (optional):** Step 2: Select Network **Choose your deployment network:** Step 3: Wallet Connection Connect your wallet. Step 4: Clone the Template (Optional) TELA's immutable update system creates new versions with each change. When cloning, you can specify the exact TXID to ensure you get the correct version. If there has been no changes to the page you can paste the SCID only. After you make updates to your page you must specify both the SCID and TXID to clone the exact version you want. Step 5: Modify Template Files The cloned files will be saved to: /datashards/clone/TELA-template/index.html. Edit index.html with your preferred editor: Optional Create a dedicated directory for your files. Copy the index.html file from the datashards directory and paste it into your new directory. Step 6: Install Modified Document **File Path Tip:** You can also provide the file path directly: install-doc /path/to/your/index.html **Compression:** TELA automatically handles compression based on file size. Files are compressed if needed to meet blockchain size limits. Step 7: Create Index Contract **Quick Install:** You can also provide the name directly: install-index \"My App Name\" **MODs are Optional:** For your first app, skip MODs (press enter). Learn about TELA-MOD-1 for advanced features like variable storage and DERO deposits. Step 8: Serve Your TELA Site Server will start on localhost (default port 8082): **Access your app:** Open http://localhost:8082 in your browser! **Congratulations!** You've successfully deployed your first TELA application to the DERO blockchain! Step 9: Share Your Application (Optional) Share your app with others by providing the INDEX SCID: Final Result --- Common Issues & Solutions Issue: \"No daemon connection\" **Solution:** Issue: \"Insufficient balance\" **Solution:** - **Simulator:** Provides free DERO automatically - **Testnet:** Use DERO testnet faucet - **Mainnet:** Ensure wallet has sufficient DERO for deployment Issue: \"File too large\" **Solution:** Issue: \"Cannot find wallet file\" **Solution:** --- Next Steps Enhance Your Application 1. **Add More Files:** 2. **Enable MODs:** - Variable Storage - Store app data - DERO Transfers - Accept payments - Transfer Ownership - Transfer your app 3. **Add XSWD Integration:** - Use XSWD Advanced library - Connect to DERO wallet from your app - Access blockchain data in real-time Learning Resources Advanced deployment workflows and automation Extend your app with modular functionality Complete troubleshooting guide Optimize files for blockchain deployment --- Tutorial Summary **What You Accomplished:** - ✅ Launched TELA-CLI and connected to network - ✅ Connected your DERO wallet - ✅ Deployed a TELA-DOC contract (your HTML file) - ✅ Created a TELA-INDEX contract (your application manifest) - ✅ Served your app locally and verified it works - ✅ Published your first decentralized web application on DERO blockchain! **Key Concepts Learned:** - 📋 **INDEX contracts** - Application manifests that reference DOC files - 📄 **DOC contracts** - Immutable code files stored on blockchain - 🔗 **SCIDs** - Smart Contract IDs for accessing deployed content - 🌐 **Networks** - Simulator (testing), Testnet, Mainnet (production) You're now ready to build more complex TELA applications! Check out the First App Tutorial for advanced features and patterns.",
       "lastUpdated": "2025-10-22"
     },
     {