Expert on Shelby Protocol architecture, erasure coding, placement groups, read/write procedures, Clay Codes, chunking, storage providers, RPC servers, and decentralized storage system design on Aptos blockchain. Triggers on keywords Shelby Protocol, erasure coding, Clay Codes, placement groups, Shelby architecture, storage provider, blob storage, chunking, Shelby whitepaper.
Provide expert guidance on Shelby Protocol's architecture, design principles, erasure coding mechanisms, data durability, read/write procedures, and system components for developers building on or integrating with the decentralized storage network.
Auto-invoke when users ask about:
Core protocol documentation in:
.claude/skills/blockchain/aptos/docs_shelby/
Key files:
protocol.md - Protocol introduction and key componentsprotocol_architecture_overview.md - Comprehensive architectureprotocol_architecture_rpcs.md - RPC server operationsprotocol_architecture_storage-providers.md - Storage provider mechanicsprotocol_architecture_smart-contracts.md - Smart contract layerprotocol_architecture_token-economics.md - Economic modelprotocol_architecture_networks.md - Network topologyprotocol_architecture_white-paper.md - Academic foundationAptos Smart Contract
Storage Provider (SP) Servers
Shelby RPC Servers
Private Network (DoubleZero Fiber)
User (Public Internet)
↓
Shelby RPC Server (Public + Private Network)
↓ (Private Fiber Network)
Storage Provider Servers (16 per placement group)
↓
Aptos L1 Blockchain (accessible by all)
Namespace:
0x123.../user/defined/path/file.extBlob Names:
/Canonical Directory Layout:
Input:
.
├── bar
└── foo
├── baz
└── buzz
Uploaded as:
<account>/<prefix>/bar
<account>/<prefix>/foo/baz
<account>/<prefix>/foo/buzz
Important: You can create both <account>/foo as a blob AND <account>/foo/bar, but this violates canonical structure.
Chunkset Basics:
Erasure Coding Scheme: Clay Codes
Why Clay Codes?
Recovery Methods:
Reference: Clay Codes Paper
Purpose:
How It Works:
Benefits:
Reference: Ceph RADOS Paper
Step-by-Step Process:
RPC Selection
Session Establishment
Read Request
Cache Check (Optional)
Chunk Location Query
Chunk Retrieval
Data Validation & Assembly
Incremental Payment
Step-by-Step Process:
RPC Selection
Local Erasure Coding
Metadata Transaction
Data Transmission
RPC Verification
Chunk Distribution
Storage Provider Acknowledgment
Finalization Transaction
Blob Available
APT (Aptos Tokens):
ShelbyUSD:
Why paid reads?
Micropayment Channels:
Storage Commitments:
Purpose:
How It Works:
Benefits:
Dedicated Bandwidth:
Efficient Recovery:
Optimized for Read-Heavy Workloads:
Placement Groups:
Erasure Coding:
High Transaction Throughput:
Resource-Efficient Execution:
Team Expertise:
Engineering Foundation:
Ideal Workloads:
Key Requirements Met:
Optimized For:
Not Optimized For:
Architecture Questions:
Technical Deep-Dive:
Design Decisions:
Use Case Evaluation:
# Architecture questions
Read docs_shelby/protocol_architecture_overview.md
# Erasure coding details
Grep "erasure|clay|chunking" docs_shelby/ --output-mode content
# Economic model
Read docs_shelby/protocol_architecture_token-economics.md
# Specific components
Read docs_shelby/protocol_architecture_rpcs.md
Read docs_shelby/protocol_architecture_storage-providers.md
Structure:
Data Flow:
Client → RPC Server → Storage Providers (16)
↓
Aptos Smart Contract
Chunking:
10MB Blob → Erasure Code → 16 Chunks (10 data + 6 parity)
→ Distributed to Placement Group
Data Durability:
Performance:
Decentralization:
Economic Alignment:
User: "How does Shelby ensure my data won't be lost?"
Response:
1. Explain erasure coding (10 data + 6 parity chunks)
2. Describe placement group distribution (16 storage providers)
3. Detail auditing system (cryptographic proofs)
4. Discuss economic incentives (rewards for honest storage)
5. Quantify durability (can lose 6 of 16 chunks)
6. Reference: Clay Codes paper, protocol_architecture_overview.md
After answering, suggest: