Bloodstone × Blurt Partnership Proposal

The Trifecta: Securing Decentralized Storage & Mining Together

Version 1.0 · July 2026 ---

Executive Summary

This proposal outlines a symbiotic partnership between the Blurt and Bloodstone communities that creates a decentralized storage and mining trifecta — combining Blurt's DPoS witness network with Bloodstone's Proof-of-Work mining and mesh storage layers.

The partnership delivers:

- Blurt : Decentralized storage for blurt.blog user content, new revenue streams for witnesses, enhanced utility for the BLURT ecosystem - Bloodstone : Bootstrapped storage network, distributed mining power, geographic node diversity, real-world adoption for the STONE token - Both : A resilient, multi-tenant data mesh that serves as a foundation for Web3 content storage

---

1. The Vision

┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ THE TRIFECTA ARCHITECTURE │ │ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ BLURT DPoS │───▶│ BLOODSTONE │───▶│ BLURT MESH │ │ │ │ WITNESS │ │ MINER │ │ COORDINATOR │ │ │ │ NETWORK │ │ PoW │ │ & STORAGE │ │ │ │ │ │ │ │ │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────────┘ │ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │ MUTUAL BENEFITS │ │ │ │ │ │ │ │ • Blurt witnesses earn STONE rewards │ │ │ │ • Bloodstone gains storage nodes + miners │ │ │ │ • Blurt users get decentralized storage │ │ │ │ • STONE token gains utility & adoption │ │ │ │ • Both communities grow together │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────┘ │ │ │ └────────────────────…

---

2. Technical Architecture

2.1 Modular Node Types

Node Type Components Resources Primary Role ----------- ----------- ----------- -------------- Full Node Witness + Miner + Coordinator + Storage Moderate to high Maximum participation Witness-Miner Witness + Miner + Coordinator Moderate PoW support without storage Storage-Only Coordinator + Storage High storage, moderate compute Data availability Witness-Only Witness only Minimal Consensus only

┌──────────────────────────────────────────────────────────────────────────┐ │ NODE DEPLOYMENT OPTIONS │ ├──────────────────────────────────────────────────────────────────────────┤ │ │ │ FULL NODE STORAGE-ONLY NODE │ │ ┌────────────────────────┐ ┌────────────────────────────┐ │ │ │ Blurt Witness │ │ Blurt Coordinator │ │ │ │ Bloodstone Miner │ │ Bloodstone Storage │ │ │ │ Blurt Coordinator │ │ Disk: Large capacity │ │ │ │…

2.2 Content Addressing & Storage Flow

—- 2.3 Two-Tier Storage System

┌─────────────────────────────────────────────────────────────────────────┐ │ BLURT DATA MESH STORAGE │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ PUBLIC STORAGE TIER │ │ │ │ │ │ │ │ • Blurt.blog content blog posts, images, public media │ │ │ │ • Content-addressed via CID │ │ │ │ • Pinned by Blurt witness nodes │ │ │ │ • Admin can block/unpin content legal compliance │ │ │ │ • Free to users paid by Blurt core team initially │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ PRIVATE STORAGE TIER Planned Phase 2 │ │ │ │ │ │ │ │ • User-owned encryption keys │ │ │ │ • User controls deletion admin cannot access │ │ │ │ • Paid with STONE tokens │ │ │ │ • Can be hosted on any provider Bloodstone, IPFS, S3, etc. │ │ │ │ • Sharing via secure tokens │ │ │ └───…

---

3. Content Moderation Framework

3.1 Moderation Principles

Principle Implementation User Control Users can delete their own content Platform Responsibility Admin can block public content legal/compliance Due Process Appeals process for blocked content Privacy Private tier content is encrypted admin cannot view Transparency All moderation actions are logged & auditable

3.2 Moderation Workflow

┌──────────────────────────────────────────────────────────────────────────┐ │ MODERATION FLOW │ │ │ │ ┌──────────┐ │ │ │ Report │──▶ Review queue │ │ └──────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ Review Decision │ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ │ │ Allow │ │ Block │ │ Refer to Legal │ │ │ │ │ │ no action │ │ unpin CID │ │ DMCA/court │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ Block Implementation │ │ │ │ │ │ │ │ 1. Admin submits block request with reason │ │ │ │ 2. CID added to blocklist │ │ │ │ 3. All witnesses unpin the CID │ │ │ │ 4. Future pins of CID rejected │ │ │ │ 5. Block logged & notified to user │ │ │ └────…

3.3 Blocklist Management

---

4. Phased Implementation Roadmap

Phase 4: Foundation

Milestone Deliverables Technical PoC Working Blurt coordinator + Bloodstone storage integration Blurt witnesses run full hybrid nodes or storage only nodes. Security Audit - AI audit of coordination layer

Phase 1 Launch Public tier storage live for blurt.blog Initial Content Migrate blog images/media to mesh storage

┌──────────────────────────────────────────────────────────────────────────┐ │ PHASE 1: FOUNDATION │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ Blurt Core Team covers storage costs initially │ │ │ │ │ │ │ │ • Witness nodes running storage │ │ │ │ • Public content only blog images, media │ │ │ │ • Basic moderation blocklist │ │ │ │ • SHA-256 content addressing │ │ │ └──────────────────────────────────────────────…

Phase 2: Hybrid Storage

Milestone Deliverables Private Tier Alpha User-owned encryption, private stores Storage Plans Free + paid tiers in STONE tokens Sharing Feature Secure content sharing between users

Phase 2 Launch Private tier open to public Witness Incentives STONE rewards for storage witnesses

Full Hybrid Both public + private tiers operational

┌──────────────────────────────────────────────────────────────────────────┐ │ PHASE 2: HYBRID STORAGE │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ User-purchased private storage │ │ │ │ │ │ │ │ • Multiple storage tiers available │ │ │ │ • STONE token payment integration │ │ │ │ • Witnesses earn STONE from storage fees │ │ │ │ • Blurt core team gradually reduces subsidy │ │ │ └──────────────────────────────────────────�…

Phase 3: Full Decentralization

Milestone Deliverables Community witness governance for storage parameters Witness Incentives Full STONE/BLURT dual rewards Phase 3 Launch Self-sustaining storage network Tenant Onboarding Other communities join the mesh

┌──────────────────────────────────────────────────────────────────────────┐ │ PHASE 3: FULL DECENTRALIZATION │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ Self-sustaining storage economy │ │ │ │ │ │ │ │ • Storage fees cover network costs │ │ │ │ • DAO governance for moderation/parameter changes │ │ │ │ • Multiple tenants on the mesh │ │ │ │ • No core team subsidy needed │ │ │ └──────────────────────────────────────────�…

---

5. Incentive Structure

5.1 Rewards Distribution

┌──────────────────────────────────────────────────────────────────────────┐ │ STORAGE REVENUE FLOW │ │ │ │ User pays STONE for storage │ │ │ │ │ ▼ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ 60% ──▶ Storage Node Operators │ │ │ │ All nodes storing chunks: witnesses + non-witness │ │ │ │ │ │ │ │ 30% ──▶ Bloodstone Network │ │ │ │ Sharding protocol, mesh maintenance, node discovery │ │ │ │ │ │ │ │ 10% ──▶ Blurt DAO │ │ │ │ Coordinator, moderation, tenant features │ │ �…

5.2 Node Operator Incentives

Role Reward Type From Storage node operator STONE Storage fees 60% split Bloodstone miner STONE Mining rewards Blurt witness BLURT + STONE Consensus + storage fees Independent node STONE Storage fees

All storage node operators are compensated based on:

· Data stored GB · Bandwidth served GB · Uptime / reliability

5.3 Storage Tiers Conceptual

Tier Features Payment Free Public storage, limited capacity Free subsidized Paid Tiers Private storage, encryption, sharing STONE tokens

Specific pricing to be determined by the parties in the partnership agreement.

---

6. Technical Specifications

6.1 System Requirements

Component Minimum Recommended CPU 2 cores 4+ cores RAM 4GB 8GB+ Storage 100GB SSD 500GB+ SSD/HDD Network 100 Mbps 1 Gbps OS Ubuntu 20.04+ Ubuntu 22.04+ Docker 20.10+ 24.0+

6.2 Docker Deployment

yaml docker-compose.blurt-bloodstone.yaml version: '3.8'

services: blurt-witness: image: blurt/witness:latest container name: blurt-witness cpus: 2.0 mem limit: 4g restart: unless-stopped ports: - "8090:8090" - "8080:8080" volumes: - ./blurt-data:/data

bloodstone-miner: image: bloodstone/miner:latest container name: bloodstone-miner cpus: 1.0 mem limit: 1g cpu shares: 256 Low priority restart: unless-stopped environment: - MINER THREADS=2 - MINER PRIORITY=idle volumes: - ./miner-data:/data

blurt-coordinator: image: blurt/mesh-coordinator:latest container name: blurt-coordinator cpus: 1.0 mem limit: 1g restart: unless-stopped ports: - "8893:8893" environment: - BLOODSTONE API= - TENANT ID=blurt - DB URL=postgresql://... Blurt's manifest DB volumes: - ./coordinator-data:/data

bloodstone-storage: image: bloodstone/storage-node:latest container name: bloodstone-storage cpus: 2.0 mem limit: 8g restart: unless-stopped environment: - STORAGE LIMIT=500GB - PIN BLURT CONTENT=true volumes: - ./storage-data:/data Large disk required ports: - "8892:8892"

6.3 API Endpoints

Endpoint Method Description /api/mesh/upload POST Upload public content /api/mesh/private/upload POST Upload private content encrypted /api/mesh/content/ cid GET Retrieve content /api/mesh/delete/ cid DELETE User-delete content /api/mesh/share/ cid / user POST Share private content /api/admin/block/ cid POST Admin block takedown /api/admin/unblock/ cid POST Admin unblock /api/user/upgrade/ plan POST Upgrade storage plan /api/user/storage GET Get storage usage

---

7. Security & Trust

7.1 Key Separations

Key/Permission Controlled By Purpose Blurt Witness Key Blurt witness operator Consensus participation Bloodstone Creator Key Bloodstone admin Infrastructure changes not applicable to Blurt Blurt Mesh Coordinator Key Blurt core team Blurt-specific mesh operations User Encryption Key Individual user Private content encryption Admin Moderation Key Blurt blog moderators Content takedown only

7.2 Security Model

┌──────────────────────────────────────────────────────────────────────────┐ │ SECURITY BOUNDARIES │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ BLURT TRUST ZONE │ │ │ │ │ │ │ │ • Blurt witnesses consensus │ │ │ │ • Blurt coordinator manifest mapping │ │ │ │ • User encryption keys private tier │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ │ │ │ │ Chunk API Content-addressed │ │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ BLOODSTONE TRUST ZONE │ │ │ │ │ │ │ │ • Storage nodes chunk storage │ │ │ │ • Miners PoW │ │ │ │ • Network layer │ │ │ └────────────────────────────────────────────────────────────────┘ │ │ │ │ ❌ No trust dependency: Blurt does not need to trust Bloodstone │ │ ✅ Content verification: SHA-256 ensures data integrity │ │ ✅ Decentralized: Multiple storage nodes prevent censo…

---

8. Governance & Decision Making

8.1 Shared Governance Model

Decision Type Decision Maker Process Storage parameter changes Blurt witness consensus Content moderation Blurt blog admin Internal process Node software updates Bloodstone core Open source contributions Pricing changes Blurt Core Team + Bloodstone Joint proposal Partnership continuation Both communities Renewal vote

8.2 Dispute Resolution

┌──────────────────────────────────────────────────────────────────────────┐ │ DISPUTE RESOLUTION PROCESS │ │ │ │ ┌──────────┐ │ │ │ Dispute │──▶ Technical committee review │ │ └──────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ Resolution Paths │ │ │ │ │ │ │ │ ┌────────────────────┐ ┌─────────────────────────────────┐ │ │ │ │ │ Resolved at tech │───▶│ Implementation │ │ │ │ │ │ committee level │ │ │ │ │ │ │ └────────────────────┘ └─────────────────────────────────┘ │ │ │ │ │ │ │ │ ┌────────────────────┐ ┌─────────────────────────────────┐ │ │ │ │ │ Escalated to witnesses │───▶│ Community vote │ │ │ │ │ │ level │ │ │ │ │ │ │ └────────────────────┘ └─────────────────────────────────┘ │ │ │ │ │ │ │ │ ┌────────────────────┐ ┌─────────────────────────────────┐ │ │ │ │ │ Arbitration last │───▶│ Binding decision │ │ │ │ │ │ resort │ │ │ │ │ │ │ └───…

—-

9. Legal & Compliance

9.1 Partnership Summary

Clause Detail Term Initial partnership term to be agreed Termination Notice period to be agreed, data portability required Data Ownership Blurt users own their content Content Moderation Blurt blog admin retains rights to block content Code Licensing Open source MIT/Apache 2.0 Liability Each party responsible for their own operations Data Portability Blurt can migrate content to other storage providers

9.2 Data Portability

┌──────────────────────────────────────────────────────────────────────────┐ │ DATA PORTABILITY PROTOCOL │ │ │ │ ┌────────────────────────────────────────────────────────────────┐ │ │ │ If partnership ends: │ │ │ │ │ │ │ │ 1. Blurt coordinator has all manifest data │ │ │ │ 2. Chunks can be: │ │ │ │ a. Left on Bloodstone continued service │ │ │ │ b. Migrated to other storage providers │ │ │ │ c. Archived locally │ │ │ │ │ │ │ │ 3. No data locked in: Blurt controls the manifest layer │ │ │ └───────────…

---

10. Community Benefits Summary

10.1 For Blurt Community

Benefit Description Decentralized Storage No reliance on centralized cloud providers Content Persistence Censorship-resistant public storage New Revenue Witnesses earn STONE from storage & mining Enhanced Utility BLURT token used for storage fees User Control Users own their content and encryption keys Privacy Private tier with user-controlled encryption

10.2 For Bloodstone Community

Benefit Description Network Growth Blurt witnesses add storage nodes & miners Real Adoption Blurt.blog uses STONE for storage Geographic Diversity Blurt's global witness network Use Case Validation Proof that mesh storage works Community Expansion Blurt users become Bloodstone users Token Utility STONE has practical use storage payments

10.3 Mutual Benefits

Benefit Description Decentralization Shared infrastructure, no single point of failure Resilience Content distributed across multiple networks Innovation Cross-pollination of ideas & code Ecosystem Stronger Web3 ecosystem together

---

11. Next Steps

Immediate Actions

Action Owner Core team alignment Blurt + Bloodstone leads Technical PoC kickoff Both dev teams

Technical Development

Milestone Owner Blurt coordinator implementation Blurt dev Bloodstone storage integration Bloodstone dev Security audit 3rd party:AI Testnet deployment Both teams

Launch

Milestone Owner Mainnet deployment Both teams Blurt.blog integration Blurt dev Public announcement Both communities

---

12. Conclusion

This partnership creates a win-win-win scenario:

1. Blurt gets decentralized storage, new revenue for witnesses, and enhanced token utility 2. Bloodstone gets network growth, real adoption, and use case validation 3. Users get secure, private, and censorship-resistant storage for their content

The trifecta architecture Witness + Miner + Storage ensures that Blurt's decentralized infrastructure is leveraged to bootstrap Bloodstone's network, while Bloodstone's storage capability solves Blurt's infrastructure needs.

Together, we build a more resilient Web3 ecosystem.

---

Glossary

Term Definition CID Content Identifier SHA-256 hash BSM1 Bloodstone Mesh anchor transaction DPoS Delegated Proof of Stake Blurt consensus PoW Proof of Work Bloodstone mining Mesh Decentralized storage network Coordinator Asset → chunk mapping service

---

Proposed by: Blurt Core Team Date: July 2026

Status: RFC - Request for Comment

---

This proposal is open for community discussion. Please submit feedback on this post.

—-

Quantum Hardening Considerations

Quantum Hardening: Is It Required in Phase 1?

Short answer: No. Phase 1 can safely use SHA-256/SHA-256d. The quantum threat timeline gives us a comfortable window, and the architecture is designed for easy upgrades.

Let me break this down:

---

Understanding the Quantum Threat to Hashes

The Reality of Grover's Algorithm

The quantum threat to hash functions comes from Grover's algorithm, which provides a quadratic speedup for brute-force search. For SHA-256, this effectively reduces its security from 256 bits to 128 bits.

Algorithm Classical Security Post-Quantum Security Threat Vector SHA-256 256 bits 128 bits Grover's algorithm ECDSA 128 bits Broken Shor's algorithm

Critical distinction: Grover only halves security, it doesn't break the function. SHA-256 post-quantum still provides 128-bit security — equivalent to AES-128, which is considered secure against quantum attacks.

The Real Problem is Public Key Cryptography

The existential quantum threat is Shor's algorithm, which breaks ECDSA and RSA entirely. The hash functions SHA-256 are far more resilient — simply doubling the hash size SHA-512 provides 256-bit post-quantum security.

"Quantum computing can not get a significant exponential advantage in brute-force searching and collision-finding problems. Therefore, the hash functions are considered to be quantum-secure to exponential speedup."

---

The Quantum Timeline

When is a Quantum Computer a Real Threat?

Milestone Status RSA-1024 break Requires 6-11 million physical qubits RSA-2048 break Requires 8-22 million physical qubits Current state-of-the-art 1,180 physical qubits 2020s IBM roadmap 4,000-qubit computer by 2025 still 1,000x short

The Conservative Deadline

NIST and the NSA mandate completion of quantum-resistant cryptography migration by 2035. This gives us 10 years to upgrade.

"The United States must prioritize the transition of cryptographic systems to quantum-resistant cryptography, with the goal of mitigating as much of the quantum risk as is feasible by 2035." — NSM-10

NIST selected the final PQC standards in 2024 CRYSTALS-Kyber, CRYSTALS-Dilithium, FALCON, SPHINCS+ . These are now standardizing.

---

Why SHA-256 Is Fine for Phase 1

1. 128-Bit Security Is Still Strong

Grover reduces SHA-256 from 256 to 128 bits. 128-bit security is considered quantum-resistant under NIST's definition:

NIST Security Level I: "At least as hard to break as AES128 exhaustive key search "

AES-128 is considered secure against both classical and quantum attacks.

2. SHA-256d Already Has Good Properties

SHA-256d SHA-256 SHA-256 x was designed specifically to prevent length-extension attacks. This design choice from Tahoe-LAFS 2006 and Bitcoin makes it a solid choice.

3. The Migration Path Is Simple

From Phase 1, the migration path is clear:

Doubling the hash size is enough for quantum resistance against Grover:

· SHA-256 128-bit post-quantum → SHA-512 256-bit post-quantum

4. The Real Quantum Threat Isn't Hashes

The critical quantum vulnerability in blockchain architectures is digital signatures ECDSA , not hashing. The file integrity use case content-addressed storage has a much lower risk profile than transaction signing.

---

Upgrading the Mesh Architecture

What Would Hardening Phase 1 Look Like?

Is This Required in Phase 1?

No. Here's why:

Factor Assessment Threat timeline 10+ years before practical quantum threat Hash resilience SHA-256 remains 128-bit quantum-secure Real risk ECDSA signatures are the priority, not hashing Migration path Simple hash size upgrade when needed Compatibility SHA-256 ensures broad client support

---

Recommended Approach

Phase 1 Current

· Use SHA-256/SHA-256d for content addressing · Document the upgrade path · Monitor quantum computing developments

Phase 2 2-3 years

· Evaluate upgrading to SHA-512 or SHA3-256 · NIST PQC standards will be finalized and tooling mature

Phase 3 5+ years

· Consider NIST PQC algorithms: · CRYSTALS-Dilithium for signatures · SPHINCS+ as hash-based fallback · SHA3-256 for hashing

Recommended Architecture Note

Some modern blockchain architectures are already incorporating post-quantum primitives like Arion hashing and constant-time BLS12-381. While not required in Phase 1, designing with upgradability in mind is the right approach.

---

Summary

Question Answer Is hardening required in Phase 1? No — SHA-256 provides 128-bit quantum resistance When should we upgrade? Phase 2-3 2-5 years What's the upgrade path? SHA-256 → SHA-512 → NIST PQC SHA3-256, etc. What's the real priority? ECDSA signatures, not hashing Is SHA-256d safe? Yes — it's designed to prevent length-extension attacks

Recommendation: Proceed with SHA-256/SHA-256d in Phase 1 with clear documentation of the quantum upgrade path for future phases. This keeps the architecture simple, compatible, and focused on solving immediate needs.