PlanB-Network · Rogzy-DB · Mar 23, 2026
diff --git a/courses/csv404/assets/en/001.webp b/courses/csv404/assets/en/001.webp
diff --git a/courses/csv404/assets/en/002.webp b/courses/csv404/assets/en/002.webp
diff --git a/courses/csv404/assets/en/003.webp b/courses/csv404/assets/en/003.webp
diff --git a/courses/csv404/assets/en/004.webp b/courses/csv404/assets/en/004.webp
diff --git a/courses/csv404/assets/en/005.webp b/courses/csv404/assets/en/005.webp
diff --git a/courses/csv404/assets/en/006.webp b/courses/csv404/assets/en/006.webp
diff --git a/courses/csv404/assets/en/007.webp b/courses/csv404/assets/en/007.webp
diff --git a/courses/csv404/assets/en/008.webp b/courses/csv404/assets/en/008.webp
diff --git a/courses/csv404/assets/en/009.webp b/courses/csv404/assets/en/009.webp
diff --git a/courses/csv404/assets/en/010.webp b/courses/csv404/assets/en/010.webp
diff --git a/courses/csv404/assets/en/011.webp b/courses/csv404/assets/en/011.webp
diff --git a/courses/csv404/assets/en/012.webp b/courses/csv404/assets/en/012.webp
diff --git a/courses/csv404/assets/en/013.webp b/courses/csv404/assets/en/013.webp
diff --git a/courses/csv404/assets/en/014.webp b/courses/csv404/assets/en/014.webp
diff --git a/courses/csv404/assets/en/015.webp b/courses/csv404/assets/en/015.webp
diff --git a/courses/csv404/assets/en/016.webp b/courses/csv404/assets/en/016.webp
diff --git a/courses/csv404/assets/en/017.webp b/courses/csv404/assets/en/017.webp
diff --git a/courses/csv404/assets/en/018.webp b/courses/csv404/assets/en/018.webp
diff --git a/courses/csv404/assets/en/019.webp b/courses/csv404/assets/en/019.webp
diff --git a/courses/csv404/assets/en/020.webp b/courses/csv404/assets/en/020.webp
diff --git a/courses/csv404/assets/en/021.webp b/courses/csv404/assets/en/021.webp
diff --git a/courses/csv404/assets/en/022.webp b/courses/csv404/assets/en/022.webp
diff --git a/courses/csv404/assets/en/023.webp b/courses/csv404/assets/en/023.webp
diff --git a/courses/csv404/assets/en/024.webp b/courses/csv404/assets/en/024.webp
diff --git a/courses/csv404/assets/en/025.webp b/courses/csv404/assets/en/025.webp
diff --git a/courses/csv404/course.yml b/courses/csv404/course.yml
@@ -155,67 +155,95 @@ tags:
   - technical-analysis
 
 videos:
+  # Part 2: Protocol Theory (5 videos)
+  - id: c8788ec8-780c-46ab-ac5c-9eb0dcd20590
+    youtube:
+      - en: XFqOxxOcRHs
+    peertube: []
   - id: f45eeea0-6583-498b-af6a-c148cbe0ed00
-    youtube: []
+    youtube:
+      - en: -yiTtO_p3Cw
     peertube:
       - en: fhfFF7SZJSdYqL4SdWYA8N
+  - id: 92add1f7-d1c7-4846-99e1-31d0b43fcc6e
+    youtube:
+      - en: a6Lxz1ycddg
+    peertube: []
   - id: aa81d3c5-27a6-46a2-9f7d-5097c2aa63ec
-    youtube: []
+    youtube:
+      - en: xtklaJHfKIY
     peertube:
       - en: rQuTfJjASzq34tsan7VxV2
   - id: 939fd065-61ec-42e0-9f19-543d7bb4f3fd
-    youtube: []
+    youtube:
+      - en: 8Qi7VOvKe5o
     peertube:
       - en: dpLSZpcyGEYk79ejXn2eft
+  # Part 3: Installation (4 videos)
   - id: 70e894f7-3759-48fc-9fcb-a3a1b33a3214
-    youtube: []
+    youtube:
+      - en: Z7KLo-pGBJA
     peertube:
       - en: mA2x1KboohWJmXUDJ9SQZf
   - id: 30cca1f1-d4c8-4d9b-88d0-d8e9e4f4986b
-    youtube: []
+    youtube:
+      - en: pYh-4EfdZaM
     peertube:
       - en: mcPAU6CfXJXLfXEcLxVMaG
   - id: c488fe53-5110-4e43-8b9c-7773d9969078
-    youtube: []
+    youtube:
+      - en: EaPZ3EbTWhE
     peertube:
       - en: eXQFEHkp4hEpdYnYnMvFZd
   - id: 42e7cc5c-18cf-47b0-9d42-879f14733cd5
-    youtube: []
+    youtube:
+      - en: o6U812eSE_Q
     peertube:
       - en: ocXrhEsZQa4oa5sCQsSPbZ
+  # Part 4: Asset Operations (6 videos)
   - id: 3bc078b4-183d-4970-b63e-66862a452566
-    youtube: []
+    youtube:
+      - en: FccI6j0mxuE
     peertube:
       - en: ityAbqrEZfPs93iawuDjoe
   - id: 89819d63-3011-4ac6-a1f7-66babd2134b8
-    youtube: []
+    youtube:
+      - en: IL4ojWyFPSk
     peertube:
       - en: cHgAkdbDVYk48cqXgcuxfj
   - id: 88cdc6ce-22f6-4ddd-90a3-da345a85eef1
-    youtube: []
+    youtube:
+      - en: o30AiqbsYhw
     peertube:
       - en: aTm6QdPxbyppfLeCjfbh85
   - id: db1c8655-eb0b-49a1-83e8-dc0b16a35582
-    youtube: []
+    youtube:
+      - en: UEaNXu8me24
     peertube:
       - en: 5vAeFUtoMWDQX8Qu7byGgh
   - id: a9a437a4-1664-4786-a4a8-6e78082abe59
-    youtube: []
+    youtube:
+      - en: qBTGxSHpyDo
     peertube:
       - en: v7pAUKB85wcMy6D57ueJjc
   - id: 03e4464a-7ce8-4fb1-889c-83f8a52ac315
-    youtube: []
+    youtube:
+      - en: hYUBA-AxrtE
     peertube:
       - en: jFzTjuZN22z35NNhNpcDHi
+  # Part 5: Advanced (3 videos)
   - id: df88fe13-4a2f-4251-82db-89ce07131947
-    youtube: []
+    youtube:
+      - en: 0nvkrWfxW3k
     peertube:
       - en: mQmPyo5Z1S832UWykk2hAm
   - id: 9b884ff3-fca1-4488-bdd9-bb1d27ed5af4
-    youtube: []
+    youtube:
+      - en: lopHP_nF0tE
     peertube:
       - en: mHZmJo6wBXojdbwU8dRnLV
   - id: 1694f29f-e009-4f0d-99d7-5cedb540c81a
-    youtube: []
+    youtube:
+      - en: m0BSUqNZT_U
     peertube:
       - en: vxWLYZxxNTBYAsR5V16Ahz
diff --git a/courses/csv404/cs.md b/courses/csv404/cs.md
diff --git a/courses/csv404/de.md b/courses/csv404/de.md
diff --git a/courses/csv404/en.md b/courses/csv404/en.md
diff --git a/courses/csv404/es.md b/courses/csv404/es.md
diff --git a/courses/csv404/et.md b/courses/csv404/et.md
diff --git a/courses/csv404/fa.md b/courses/csv404/fa.md
diff --git a/courses/csv404/fi.md b/courses/csv404/fi.md
diff --git a/courses/csv404/fr.md b/courses/csv404/fr.md
diff --git a/courses/csv404/hi.md b/courses/csv404/hi.md
diff --git a/courses/csv404/id.md b/courses/csv404/id.md
diff --git a/courses/csv404/it.md b/courses/csv404/it.md
diff --git a/courses/csv404/ja.md b/courses/csv404/ja.md
diff --git a/courses/csv404/ko.md b/courses/csv404/ko.md
diff --git a/courses/csv404/nb-NO.md b/courses/csv404/nb-NO.md
diff --git a/courses/csv404/nl.md b/courses/csv404/nl.md
diff --git a/courses/csv404/pl.md b/courses/csv404/pl.md
diff --git a/courses/csv404/pt.md b/courses/csv404/pt.md
diff --git a/courses/csv404/quizz/000/en.yml b/courses/csv404/quizz/000/en.yml
@@ -0,0 +1,12 @@
+question: What role do intermediate Lightning nodes play when routing a Taproot Assets payment?
+answer: They route ordinary satoshi payments without any awareness of the assets being transferred
+wrong_answers:
+  - They convert assets between different types at each hop along the route
+  - They validate the asset proofs before forwarding the payment to the next node
+  - They store asset metadata on behalf of the network for future verification
+explanation: >-
+  In the Taproot Assets Lightning architecture, only the edge nodes at the
+  endpoints of a payment deal with assets. All intermediate nodes along the
+  route simply forward standard satoshi-denominated Lightning payments, with
+  no knowledge that assets are involved at the endpoints.
+reviewed: false
diff --git a/courses/csv404/quizz/000/question.yml b/courses/csv404/quizz/000/question.yml
@@ -0,0 +1,7 @@
+id: 4826b645-0ff5-4449-976d-7668b433a575
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: easy
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/001/en.yml b/courses/csv404/quizz/001/en.yml
@@ -0,0 +1,12 @@
+question: What mechanism does the Taproot Assets Protocol use to embed asset data in Bitcoin transactions without revealing it publicly?
+answer: Client-side validation with cryptographic proofs that only holders can verify
+wrong_answers:
+  - OP_RETURN data fields that store encrypted asset information in each transaction
+  - Segregated witness extensions that carry asset metadata alongside signatures
+  - A sidechain anchoring mechanism that periodically commits asset state to Bitcoin
+explanation: >-
+  Taproot Assets uses client-side validation, meaning asset data is committed
+  to the blockchain via a taptweak but is only visible to parties who possess
+  the corresponding cryptographic proofs. To any external observer, the
+  transaction looks like an ordinary Taproot transaction.
+reviewed: false
diff --git a/courses/csv404/quizz/001/question.yml b/courses/csv404/quizz/001/question.yml
@@ -0,0 +1,7 @@
+id: 3fa5ac79-4989-4b6e-a21f-0b3637ac1c86
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: intermediate
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/002/en.yml b/courses/csv404/quizz/002/en.yml
@@ -0,0 +1,12 @@
+question: What data structure does TAPD use to organize and commit asset information?
+answer: Merkle Sum Sparse Merkle Trees (MS-SMT)
+wrong_answers:
+  - Patricia Merkle Tries adapted from Ethereum's state model
+  - Standard binary Merkle trees identical to those used in Bitcoin blocks
+  - Directed acyclic graphs stored in the transaction witness
+explanation: >-
+  TAPD constructs Merkle Sum Sparse Merkle Trees (MS-SMT) to store all asset
+  data. These specialized structures combine the properties of sparse Merkle
+  trees (which enable absence proofs) with Merkle sum trees (which provide
+  anti-inflation guarantees by propagating numeric values to the root).
+reviewed: false
diff --git a/courses/csv404/quizz/002/question.yml b/courses/csv404/quizz/002/question.yml
@@ -0,0 +1,7 @@
+id: 7681a5fc-af80-486a-98d4-d0a708ab6222
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: intermediate
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/003/en.yml b/courses/csv404/quizz/003/en.yml
@@ -0,0 +1,12 @@
+question: What consensus change does the Taproot Assets Protocol require to function on Bitcoin?
+answer: None — it is fully opt-in and requires no consensus changes
+wrong_answers:
+  - A soft fork to enable asset-aware transaction validation rules
+  - A new opcode dedicated to Merkle tree verification inside scripts
+  - An extension to the Taproot script versioning system for asset commitments
+explanation: >-
+  The Taproot Assets Protocol is designed to work entirely within Bitcoin's
+  existing consensus rules. It leverages the design space opened by the
+  Taproot upgrade (BIP 341) to embed asset data via the taptweak, without
+  requiring any additional protocol-level changes.
+reviewed: false
diff --git a/courses/csv404/quizz/003/question.yml b/courses/csv404/quizz/003/question.yml
@@ -0,0 +1,7 @@
+id: 741465a3-0832-4584-824f-09bba4be8360
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: intermediate
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/004/en.yml b/courses/csv404/quizz/004/en.yml
@@ -0,0 +1,13 @@
+question: When Alice sends 100 of her 1,000 beefbucks to Bob on-chain, how does the protocol handle the state change?
+answer: Two new Merkle trees are constructed — one where Alice holds 900 and one where Bob holds 100 — each committed to a separate transaction output
+wrong_answers:
+  - The existing Merkle tree is updated in place with the new balances for both parties
+  - A single new Merkle tree is created containing both balances as separate leaves in the same output
+  - The transaction creates an on-chain script that enforces the split and tracks future transfers
+explanation: >-
+  On-chain Taproot Assets transfers work by splitting the current Merkle tree
+  into two new trees reflecting the updated balances. Alice's asset-bearing
+  UTXO is consumed as an input, and the transaction creates at least two
+  outputs: one committing Alice's updated tree (900 beefbucks) and one
+  committing Bob's new tree (100 beefbucks).
+reviewed: false
diff --git a/courses/csv404/quizz/004/question.yml b/courses/csv404/quizz/004/question.yml
@@ -0,0 +1,7 @@
+id: 3e21f928-a9d9-47db-90d9-972e7fd7c18e
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: hard
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/005/en.yml b/courses/csv404/quizz/005/en.yml
@@ -0,0 +1,13 @@
+question: What is the function of an edge node in the Taproot Assets Lightning architecture?
+answer: It operates at the boundary between asset channels and satoshi channels, converting between them to enable cross-asset routing
+wrong_answers:
+  - It validates all asset transactions across the entire network before they are confirmed
+  - It stores the complete history of all Taproot Assets ever issued for network-wide verification
+  - It relays asset metadata between Lightning nodes that do not support the Taproot Assets Protocol
+explanation: >-
+  An edge node sits at the boundary of the Lightning Network where asset
+  channels meet regular satoshi channels. When a cross-asset payment is
+  initiated, the edge node converts the asset into satoshis (or vice versa),
+  allowing the payment to route through standard Lightning liquidity. A
+  second edge node on the other side performs the reverse conversion.
+reviewed: false
diff --git a/courses/csv404/quizz/005/question.yml b/courses/csv404/quizz/005/question.yml
@@ -0,0 +1,7 @@
+id: d96d89b7-45f9-4ad9-98b4-83afad25730e
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: hard
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/006/en.yml b/courses/csv404/quizz/006/en.yml
@@ -0,0 +1,13 @@
+question: How does TAPTweak commit asset data to the Bitcoin blockchain?
+answer: It adds the Merkle tree root hash to the Bitcoin script tree and embeds it in a Taproot address
+wrong_answers:
+  - It writes the full asset data directly into the witness field of the transaction
+  - It creates an OP_RETURN output containing a hash of the asset state
+  - It anchors the asset data to a separate sidechain block referenced in the transaction
+explanation: >-
+  TAPTweak takes the root hash of the collection of Merkle Sum Sparse Merkle
+  Trees, adds it to the Bitcoin script tree, and embeds it into a Bitcoin
+  address. The resulting on-chain transaction is indistinguishable from a
+  regular Taproot transaction, preserving privacy while cryptographically
+  committing the asset state.
+reviewed: false
diff --git a/courses/csv404/quizz/006/question.yml b/courses/csv404/quizz/006/question.yml
@@ -0,0 +1,7 @@
+id: 6fed5d09-6921-4d97-bf1c-a4918a686675
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: hard
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/007/en.yml b/courses/csv404/quizz/007/en.yml
@@ -0,0 +1,13 @@
+question: Why can a Taproot Assets minting transaction remain indistinguishable from a regular Taproot transaction on the blockchain?
+answer: The asset data is committed via the taptweak and is only visible to those possessing the cryptographic proofs
+wrong_answers:
+  - The asset data is encrypted with the minter's public key and stored in the witness
+  - Taproot Assets use a separate mempool that is not visible to standard Bitcoin nodes
+  - The minting data is stored entirely off-chain and never touches the Bitcoin blockchain
+explanation: >-
+  Because asset data is embedded via TAPTweak into the Taproot script tree,
+  the on-chain transaction carries no visible indication of asset activity.
+  Only parties who possess the corresponding cryptographic proofs can verify
+  that asset data was committed. This is the core property of client-side
+  validation — the blockchain enforces commitment without revealing content.
+reviewed: false
diff --git a/courses/csv404/quizz/007/question.yml b/courses/csv404/quizz/007/question.yml
@@ -0,0 +1,7 @@
+id: c023cc5d-b7ec-4f37-91ea-a280d4cc7568
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: hard
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/008/en.yml b/courses/csv404/quizz/008/en.yml
@@ -0,0 +1,14 @@
+question: In a cross-asset Lightning payment where Bob sends USD stablecoins and Elena receives euro stablecoins, what is the exact payment flow?
+answer: Bob's edge node converts USD to satoshis, the payment routes through standard Lightning channels, and Elena's edge node converts satoshis to euros
+wrong_answers:
+  - The payment is routed through asset-aware channels that natively support multi-currency conversion at each hop
+  - A central exchange node matches the USD and EUR orders before routing the payment through the network
+  - The USD stablecoins are burned at Bob's node and new EUR stablecoins are minted at Elena's node
+explanation: >-
+  Cross-asset Lightning payments rely on two edge nodes and the standard
+  Lightning Network in between. Bob's edge node accepts his USD stablecoins
+  and forwards the equivalent value as a satoshi Lightning payment. That
+  payment routes through ordinary channels until it reaches Elena's edge
+  node, which converts the received satoshis into euro stablecoins. The
+  intermediate network never touches the assets directly.
+reviewed: false
diff --git a/courses/csv404/quizz/008/question.yml b/courses/csv404/quizz/008/question.yml
@@ -0,0 +1,7 @@
+id: 8f3eea88-70b9-4e00-905a-a8d5fcdf5a2c
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: hard
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/009/en.yml b/courses/csv404/quizz/009/en.yml
@@ -0,0 +1,13 @@
+question: What distinguishes an internal Taproot Assets transaction from a standard on-chain transfer?
+answer: Assets move between leaves within the same set of Merkle trees rather than being split across separate transaction outputs
+wrong_answers:
+  - Internal transactions do not require an on-chain Bitcoin transaction to commit the state change
+  - Internal transactions bypass the proof verification system and rely solely on node trust
+  - Internal transactions can only move assets within a single Lightning channel
+explanation: >-
+  In an internal transaction, assets are reorganized between leaves within the
+  same set of Merkle trees, rather than being split into separate trees
+  committed to different outputs. However, an on-chain Bitcoin transaction is
+  still required to commit the updated Merkle root, ensuring that the state
+  change is anchored to the blockchain like any other Taproot Assets operation.
+reviewed: false
diff --git a/courses/csv404/quizz/009/question.yml b/courses/csv404/quizz/009/question.yml
@@ -0,0 +1,7 @@
+id: 899a011e-d279-4718-90da-99dd05c99608
+chapterId: 84aeb178-895e-4212-aba3-4c7a015d31e2
+difficulty: hard
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/010/en.yml b/courses/csv404/quizz/010/en.yml
@@ -0,0 +1,9 @@
+question: "What was the Taproot Assets Protocol (TAP) originally known as?"
+answer: "Taproot Asset Representation Overlay (Taro)"
+wrong_answers:
+  - "Taproot Asset Registration Overlay (Taro)"
+  - "Taproot Asset Routing Overlay (Taro)"
+  - "Taproot Asset Replication Overlay (Taro)"
+explanation: >-
+  TAP was originally called the Taproot Asset Representation Overlay, abbreviated as Taro. The protocol was later renamed to the Taproot Assets Protocol to better reflect its expanded scope. The key word is "Representation," indicating the protocol's role in representing arbitrary assets on Bitcoin's blockchain.
+reviewed: false
diff --git a/courses/csv404/quizz/010/question.yml b/courses/csv404/quizz/010/question.yml
@@ -0,0 +1,7 @@
+id: "e33ff402-2990-4ec8-aaa7-3481f2602a0d"
+chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16"
+difficulty: easy
+duration: 15
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/011/en.yml b/courses/csv404/quizz/011/en.yml
@@ -0,0 +1,9 @@
+question: "How many on-chain Taproot transactions are required to create multiple Taproot assets?"
+answer: "A single on-chain Taproot transaction, with no theoretical limit on the number of assets"
+wrong_answers:
+  - "One transaction per asset, each requiring a separate on-chain confirmation"
+  - "A minimum of two transactions: one for the asset metadata and one for the asset itself"
+  - "Multiple transactions batched together in a single Bitcoin block"
+explanation: >-
+  Creating one or many Taproot assets requires only a single on-chain Taproot transaction. There is no theoretical limit to the number of assets that can be produced within that one transaction. This efficiency is a key advantage of the protocol, as asset data is embedded within a regular Taproot transaction.
+reviewed: false
diff --git a/courses/csv404/quizz/011/question.yml b/courses/csv404/quizz/011/question.yml
@@ -0,0 +1,7 @@
+id: "54280131-79b0-47d9-875e-af105b0b3c4e"
+chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16"
+difficulty: intermediate
+duration: 30
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/012/en.yml b/courses/csv404/quizz/012/en.yml
@@ -0,0 +1,9 @@
+question: "Which three inputs are hashed together using SHA-256 to compute a Taproot Asset ID?"
+answer: "The genesis outpoint, the asset tag, and the asset metadata"
+wrong_answers:
+  - "The internal public key, the Merkle root, and the asset tag"
+  - "The transaction ID, the block hash, and the asset supply"
+  - "The genesis outpoint, the asset supply, and the issuer's public key"
+explanation: >-
+  The Asset ID is computed as sha256(genesis_outpoint || asset_tag || asset_meta). The genesis outpoint anchors the asset to its specific creation point on the Bitcoin blockchain, the asset tag provides the asset's name, and the asset meta contains any associated metadata. This formula ensures each asset has a deterministic and unique identifier tied to its on-chain origin.
+reviewed: false
diff --git a/courses/csv404/quizz/012/question.yml b/courses/csv404/quizz/012/question.yml
@@ -0,0 +1,7 @@
+id: "5dd40e99-c280-4c48-a815-173fc2e96898"
+chapterId: "b3c8d5f2-7e4a-4b9c-a6f1-5d9e2c3b8f16"
+difficulty: hard
+duration: 45
+author: plan-b-network
+tags: []
+original_language: en
diff --git a/courses/csv404/quizz/013/en.yml b/courses/csv404/quizz/013/en.yml
@@ -0,0 +1,9 @@
+question: "How does a Sparse Merkle Tree prove that an asset does not exist?"
+answer: "By showing that the leaf position determined by the SHA-256 digest of the asset data is empty"
+wrong_answers:
+  - "By providing a signed attestation from the asset issuer confirming the asset was never created"
+  - "By scanning every leaf in the tree and confirming the asset is absent from all positions"
+  - "By verifying that the Merkle root hash does not match any known asset commitment"
+explanation: >-
+  In a Sparse Merkle Tree, each object is stored at a leaf position determined by the SHA-256 digest of its data, creating a deterministic placement. To prove an asset does not exist, you simply demonstrate that the expected leaf position is empty (contains a null hash). This is far more efficient than scanning the entire tree, as the sparse nature means most leaves are empty by default.
+reviewed: false