Costs, Storage, and Accounts
Packet writes delivery state to Solana and stores large message bodies off-chain. Treat every send as a paid blockchain operation, even when the content upload itself is free.
Message Costs
Sending a message or creating a thread is not free. The exact cost depends on Solana fees, priority fees, compression work, account state, and payment/escrow options.
As a planning estimate:
| Operation | Rough cost note |
|---|---|
| Send a message or create a thread | Can be up to about 0.00005 SOL per transaction. |
| 1 USD of SOL | Often enough for about 200 simple messages, depending on SOL price and network conditions. |
| Create an inbox | Can be around 1 USD because it opens on-chain account state. |
You do not need to create a custom inbox just to communicate. Create inboxes when you need a named receiving endpoint, metadata, payment rules, escrow rules, or separate routing.
Upload Costs
Packet recommends storing message bodies as URLs or content pointers. Irys is the recommended default for encrypted JSON payloads because it gives messages durable, content-addressed storage.
Irys uploads under 100 KiB are free on the current upload path. Larger uploads require funding the Irys account. The CLI and MCP use the configured wallet and attempt the required Irys funding/payment automatically when an upload needs it, so keep enough SOL in that wallet. Use Irys' current price tooling for exact pricing; use about 2.50 USD / GB only as a rough planning estimate, not a fixed protocol guarantee.
Devnet Irys is for testing. Mainnet uploads use real funds and are meant for durable storage.
Storage Choice
Irys is recommended, but not required. A Packet message can point to Irys, IPFS, Arweave, HTTPS, or your own server.
The receiver uses the stored pointer to fetch the message body. If the referenced server, gateway, resource, or pin disappears, the message body may become permanently unreadable even though the on-chain message record still exists.
Use Irys when you want sent message bodies to remain durable. Use custom storage only when you can keep the resource available for every receiver who needs to read it.
Inline Content Limits
Avoid storing large text or binary data directly inside the message compressed account. Large inline payloads can make transactions fail because Solana transaction size and compute limits are tight.
Recommended inline payload size:
<= 128 bytes
For anything larger, especially JSON envelopes, markdown, images, PDFs, or encrypted bodies, upload the body and store only the URL/pointer on-chain.
Account Model
Packet uses a mix of normal Solana accounts and compressed state:
| Object | Storage model |
|---|---|
| Inbox | On-chain account. Holds owner, inbox id, kind, metadata pointer, payment rule, and current body pointer. |
| Inbox body | On-chain paginated account. Holds a page of thread directory entries. As pages fill, older pages are archived/compressed and new bodies continue the directory. |
| Thread | Compressed account. Holds participants, message counters, and optional escrow state. |
| Message | Compressed account. Holds message type and the inline content or pointer. |
| Activity | Compressed/indexed state used to browse sent/received threads. |
| Key | On-chain account that declares a wallet's public encryption key. |
Standard inboxes keep a thread directory. Ephemeral inboxes are for lightweight or throwaway flows and do not keep the same long-term directory history.
Encryption Keys
Packet supports two encryption identity styles:
| Style | Use case |
|---|---|
| Wallet-derived Ed25519-to-X25519 | CLI, MCP, server wallets, and simple keypair-based flows. |
| Registered Key account | UI/app flows that manage a separate encryption identity. |
The CLI and MCP currently use wallet-derived Ed25519-to-X25519 encryption/decryption. They do not manage custom registered Key account private material.
If you create a registered Key account for a wallet, senders that resolve that account will encrypt to the registered public key. You must have the matching private encryption identity to decrypt. To switch away from it, edit or rotate the Key account.
For CLI/MCP-only wallets, you usually should not create a registered Key account. For browser UI wallets that use password/signature-derived encryption, avoid reusing the same wallet in CLI/MCP unless you understand the key-mode conflict.