Envelopes
The envelope packages encrypted data so another BitPlan reader can open it. It provides framing and public decryption parameters; encryption protects the plan inside it. Anything that can read a 1Sat Ordinal and talk to a BRC-100 wallet can implement the format.
Where it lives
Content type is application/x-bitplan. Cleartext MAP on chain is three fields: { "app": "bitplan", "type": "plan", "enc": "1" }. Titles, descriptions, and git provenance stay inside the ciphertext.
Versioning
The first publish inscribes a 1-satoshi output. Later publishes spend that satoshi back to you with a new envelope. The origin (genesis outpoint) is the draft's identity. Only the wallet holding the coin can publish the next version.
Binary layout
Multi-byte integers are little-endian. A reader must reject anything whose magic is not BPLN, whose version it does not implement, whose header size overruns the buffer, or that carries no ciphertext.
| Field | Size | Value |
|---|---|---|
| magic | 4 bytes | ASCII BPLN |
| version | 1 byte | 0x02 |
| header size | 4 bytes | uint32-LE length of the header JSON |
| header | varies | UTF-8 JSON |
| ciphertext | rest | document ciphertext followed by one wrapped key per reader |
Content key
The SDK encrypts the plan once with a fresh random 32-byte document key and AES-256-GCM. The wallet encrypts that key for each reader. A plan with no invited readers has one slot, the publisher's. The header names the fixed [2, "bitplan"] protocol and keyID. The keyID is a public derivation label, not key material.
Security properties
AES-GCM provides confidentiality and tamper detection. The wallet will fail on the wrong protocol, keyID, counterparty, or ciphertext. The payload includes a SHA-256 commitment to its canonical header. It detects changes made without the document key. The envelope does not prove authorship by itself; the ordinal's origin and transaction chain do that.