⛓️ Node Verification Deep Dive
How SMPT nodes reach consensus, anchor metadata, and secure the registry
12 active nodes
Monad Mainnet: 4 238 122 blocks
Last finalisation: 2.3s ago
1 syncing node
1. Node Role & Architecture
An SMPT verification node is a daemon that continuously:
- Pulls registry data from The MLC, SoundExchange, MusicBrainz, and participating PROs
- Normalises incoming JSON into the SMPT Unified Schema (SUS)
- Detects conflicting split/ownership data across sources
- Participates in weighted‑consensus rounds
- Anchors finalised mappings to the Monad blockchain
- Serves verified proofs via the public API
PRO 1
⇢
Ingest
⇢
Normalise
⇢
Conflict?
If conflict → trigger consensus round
2. The Verification Lifecycle of a Single ISRC
- Ingestion – Node fetches latest data for ISRC US‑RC1‑23‑00001 from ASCAP, BMI, SOCAN.
- Conflict detection – ASCAP shows 50/50 split (publisher/artist), BMI shows 60/40.
- Consensus round – All 12 nodes compute weighted votes (source reliability + external anchors).
- Finalisation – Median split 55/45 is accepted; mapping gap 5% flagged.
- Anchoring – Hash of final mapping stored on Monad (block 4 238 211).
3. Weighted Consensus Algorithm
Each node calculates a confidence score for each conflicting data point using:
Wᵢ = α·R(src) + β·A(external) + γ·N(rep)
α = 0.5, β = 0.3, γ = 0.2 (can be adjusted by governance)
Where:
- R(src) – historical accuracy of the source PRO (0‑100, maintained by nodes)
- A(external) – number of external anchors (e.g. label attestations, previous on‑chain records)
- N(rep) – reputation of the node that originally ingested that source (uptime, past correctness)
ASCAP vote: 50% (weight 0.8)
BMI vote: 60% (weight 0.7)
SOCAN vote: 55% (weight 0.5)
→ weighted median = 55%
4. Cryptographic Anchoring
After finalisation, the node constructs a leaf containing:
{
"isrc": "US-RC1-23-00001",
"iswc": "T‑071‑234‑567‑8",
"splits": [
{"party": "Sony/ATV", "share": 55.0, "role": "Publisher"},
{"party": "A. Writer", "share": 45.0, "role": "Composer"}
],
"prev_hash": "0x7e3a...f2c1",
"block_height": 4238211,
"timestamp": "2026‑03‑12T10:23:14Z"
}
The SHA‑384 hash of this object is submitted to Monad via a smart contract. Anyone can verify that a given mapping existed at a certain block using a Merkle proof.
5. Node Hardware & Requirements
CPU 4+ cores (ARM64 / x86_64)
RAM 16 GB minimum, 32 GB recommended
Storage 500 GB SSD (NVMe preferred)
Network 100 Mbps symmetric, low latency
Stake 10 000 SMPT tokens (testnet: free)
6. Running a Node (Quickstart)
git clone https://github.com/smptprotocol/node.git
cd node && make install
smptd init --monad-rpc https://rpc.monad.smpt.org
smptd start --pro-mlc --pro-soundexchange
# monitor logs: tail -f ~/.smptd/logs/verifier.log
Once synced, the node will automatically participate in consensus and can serve API queries.
7. API for Proof Verification
Anyone can verify a mapping by calling:
GET /v1/verify?hash=0x4fa3c82e1b7d...
Returns the full mapping plus on‑chain proof (block, tx, Merkle path).
8. Security & Slashing
Nodes that vote maliciously or serve incorrect proofs lose stake. Challenge audits are randomised every 24 hours. In 6 months of testnet, only 0.4% of votes were slashed.
