Design decisions and war stories are one thing. At some point, you have to measure the system and report what you find — including the parts that don’t flatter it. This post covers the three questions I think any serious evaluation of a system like this has to answer honestly: how fast is it, how secure is it, and whether the decentralization is real or just a marketing claim.
Throughput and Latency
Under a sustained stress test, 200 concurrently funded accounts submitted transactions continuously for 180 seconds. CCRMS sustained 26.2 transactions per second. Single-chain inclusion latency was consistently around 6 seconds, aligning with the test parachain’s roughly 6-second block time. Block weight utilization stayed low even under load: at 300 transactions per block, only about 12.9 percent of computational weight and 2.2 percent of proof-size weight were consumed, suggesting a theoretical single-parachain ceiling around 283 TPS.
I want to put that 26.2 TPS figure in honest context, because on its own it sounds unimpressive. This is consistent with published survey data on Nominated Proof-of-Stake networks without additional Layer-2 acceleration. Polkadot’s actual scaling strategy is horizontal: with a hundred parachains each running at a similar rate, you’re looking at aggregate capacity in the thousands of TPS, before even counting the Elastic Scaling features that let a single parachain use multiple cores. And practically speaking, rights-management transactions — subscribing, renewing, transferring ownership — are inherently low-frequency events. A subscriber renews a license once per billing cycle, not continuously. At 26.2 TPS, CCRMS could theoretically serve roughly 2.3 million transactions a day, which comfortably exceeds the addressable user base of most independent creator platforms.
Cross-chain latency was already covered in the previous post: 3 to 5 blocks on the CCRMS chain itself, translating to roughly 100 seconds of wall-clock time once you account for the relay-chain hop, on a pre-Polkadot-2.0 toolchain. That’s an upper bound in the test environment, not a production forecast.
Storage Efficiency
Storage growth was perfectly linear, which matters more than it sounds like it should. A content registration costs 191 bytes on-chain; an active subscription costs 112 bytes; a view pack costs 111 bytes; an ownership record costs just 36 bytes. The fiftieth item registered cost exactly the same as the first, confirming constant-time storage-map complexity rather than some hidden growth curve. Extrapolated to a hypothetical production scale of one million content items and ten million subscribers, the total on-chain state comes to approximately 1.3 gigabytes — comfortably within range for commodity parachain node hardware.
Reliability
Reliability was tested by monitoring baseline block production, forcibly killing the collator process, and measuring recovery. Mean time to recovery was roughly 15 to 20 seconds, with full state integrity preserved through the crash and restart, and post-recovery block production statistically indistinguishable from the pre-crash baseline. Baseline uptime in this configuration was 90 percent, reflecting a single-collator test topology rather than a production deployment; production networks run multiple collators so that one node’s downtime doesn’t appear as network downtime.
Security
I ran a thorough audit: static analysis, a manual review of all seventeen extrinsics, and targeted unit tests focused on authorization gaps and edge cases. That process surfaced eight findings. Two were genuine vulnerabilities, and both were fixed.
One was the authorization gap I described in the last post: a cross-chain ownership-transfer call that didn’t verify the caller actually held the identity it claimed to be transferring from. The other was a view-pack overwrite bug in which a repurchase could clobber an existing balance instead of adding to it. Three findings were accepted design properties rather than bugs — allowing zero-price content registration, for instance, is a legitimate use case, not an oversight. The remaining three were positive findings: confirmed full state persistence across crashes and that block production behavior didn’t degrade after recovery.
Zero critical or high-severity vulnerabilities remained unresolved by the end of the audit. I’d rather report eight findings and two real fixes than claim a clean audit that nobody actually stress-tested, because the second kind of claim isn’t worth anything.
Decentralization
This deserves the most scrutiny, because “decentralized” is used as a marketing term far more often than it’s measured. I used the Herfindahl-Hirschman Index (HHI) — the same concentration metric antitrust regulators use to evaluate market power — applied to validator stake distribution.
Polkadot’s mainnet, with roughly 300 validators holding near-equal stake, has an HHI of about 33. For context, the US Department of Justice defines anything below 1,500 as “unconcentrated.” Ethereum’s Proof-of-Stake network, despite having roughly 900,000 individual validators, has an HHI of about 1,200 to 2,000 once you account for stake concentration among a handful of large staking providers. Solana lands around 200 to 500, reflecting a more top-heavy stake distribution among its roughly 1,900 validators. A centralized platform — a single entity holding all authority — sits at 10,000, the maximum possible concentration.
Polkadot’s Nakamoto coefficient, roughly how many entities you’d need to collude to compromise the network, is about 80 to 100, compared to about 5 to 7 for Ethereum and exactly 1 for any centralized DRM system. By this measure, a CCRMS deployment on Polkadot would match or exceed the decentralization properties of the alternatives it’s most often compared against — and it’s not a qualitative claim. It’s a number, calculated the same way regulators calculate market concentration anywhere else.
The Honest Overall Picture
CCRMS is roughly 270 times slower in throughput and 67,000 times slower in raw operation latency than a bare-bones centralized Express.js and SQLite baseline I built specifically for comparison. That sounds damning until you remember what the centralized baseline doesn’t give you: no single point of failure, cross-chain portability, cryptographically provable rights state, and censorship resistance. None of those properties show up in a raw latency number, but they’re exactly what a creator needs from a rights-management system — as opposed to what a high-frequency trading system needs.
The trade-off is real and steep, but for the specific use case this was built for — low-frequency, high-stakes rights transactions — it’s the right trade to make.
In the next post, I’ll cover the last and in some ways most important question in the series: whether that trade-off actually translates into more money for creators, and the honest, conditional answer the data gave me.
This is Part 6 of the CCRMS series. The full series walks through the architecture, engineering decisions, and honest results of building a cross-chain content rights system on Polkadot.
