THE PROTOCOL / TRANSPORT INDEPENDENCE
Built around the file.
Not the chain.
The content, its protection and its recovery contract form the center. Networks are ways to carry and retrieve that content.
THE COMMON CORE — TARGET ARCHITECTURE
Media → Encryption → Records → Recovery
Content protection · Authenticated reconstruction · Separate media and spending keys
Litecoin
Bitcoin
Other destinations
Transport-independent is the architectural direction. The documented reference format below currently uses a Bitcoin Taproot envelope.
A new destination
must earn its guarantees.
Adding a chain or storage system should not redefine the purpose of the protocol. But destinations differ: how they retain bytes, how they prove inclusion, what they cost, and who can refuse access.
Ethereum, Solana and other storage systems are possible future adapters, not claims of existing integrations. A cloud adapter could be useful for an extra copy; it would still carry that provider’s deletion and availability model.
Chain independence does not mean pretending all storage offers the same censorship resistance.
CURRENT REFERENCE / EXPERIMENT 2
Small enough to inspect.
Explicit enough to rebuild.
| Offset | Bytes | Field | Visibility |
|---|---|---|---|
| 0 | 4 | URMA2 version discriminator | Public |
| 4 | 32 | Random object ID | Public |
| 36 | 16 | Keyed discovery tag | Public |
| 52 | 4 + 4 | Chunk index and total count | Public |
| 60 | 32,808 | Original digest, length, chunk bytes and padding | Encrypted |
| 32,868 | 16 | Poly1305 authentication tag | Authentication |
XChaCha20-Poly1305 protects each chunk. HKDF-SHA256 derives separate content and discovery keys per object. The public header is authenticated as associated data.
Chunk relationships and a 32 KiB size bucket remain visible. The exact original length and file digest are encrypted. This is confidentiality, not traffic anonymity.