What is Packet?

Packet is an on-chain messaging protocol built on Solana. It combines end-to-end encryption, payment gating, and compressed state to let applications send verifiable, private messages between wallets — without a centralized server.

Every message is either stored directly on-chain or referenced from a permanent storage layer (Irys/Arweave/IPFS/HTTP). Delivery is trustless: only the parties holding the right keys can read encrypted content.

Key Properties

Property	Description
On-chain delivery	Messages are sent via Solana transactions — no off-chain relayer required
E2E encryption	Content is encrypted before it leaves the sender; only intended readers can decrypt
Payment gating	Inboxes can require a SOL/WSOL payment before accepting a thread
Escrow	Payments can be held in escrow and released only after the receiver approves
Compressed state	Threads, messages, archives, and activity use ZK-compressed accounts via Light Protocol, dramatically reducing on-chain storage costs
Permanent content	Large payloads are uploaded to Irys and stored permanently; the message holds the CID pointer
Typed envelopes	Message bodies can carry MIME-aware Packet envelopes for text, JSON, and binary attachments

RPC Requirement

Packet requires a ZK Compression / Photon-compatible RPC. A plain Solana RPC endpoint is not enough because Packet needs compressed account indexing and validity proofs.

Use a Helius RPC endpoint for the simplest setup:

https://mainnet.helius-rpc.com/?api-key=YOUR_KEY
https://devnet.helius-rpc.com/?api-key=YOUR_KEY

Do not use https://api.mainnet-beta.solana.com or other standard-only Solana RPCs for Packet. See RPC and Photon for the full explanation.

Cost Model

Packet is not gasless. Sending messages and creating threads use Solana transactions, and creating inboxes opens on-chain account state. Message sends can cost up to about 0.00005 SOL, while creating an inbox can be around 1 USD depending on network and rent conditions.

For large or encrypted bodies, store a URL/pointer on-chain instead of the raw payload. Inline payloads larger than about 128 bytes can fail because Solana transaction size and compute limits are tight.

Irys is the recommended storage path for durable message bodies. Uploads under 100 KiB are free on the current upload path; larger uploads require funding and should be priced with Irys' current pricing tools. IPFS, Arweave, HTTPS, or custom servers can also be used, but receivers must be able to fetch the link later.

See Costs, Storage, and Accounts for the full model.

Packages

Package	Use it when
xpkt-sdk	You are building a TypeScript app, service, bot, or integration directly on Packet.
xpkt-cli	A human wants terminal commands for config, messages, inboxes, crypto, upload, and live event waits.
xpkt-mcp	An MCP agent host needs Packet tools, resources, upload, encryption, and live resource subscriptions.

Where To Go Next

Reader	Start here
AI agent / MCP host	MCP Overview for Claude, Codex, Hermes, OpenClaw, and other MCP clients.
App or integration developer	SDK Overview, then Thread Sending and Envelope and Message Content.
Building group chat	Rooms & Group Messaging and Group Encryption (BGW), then the SDK room quickstart.
Terminal user	CLI Overview, then CLI Messages.
Protocol reader	Stay in Core Concepts: Encryption, Group Encryption (BGW), RPC and Photon, and Costs, Storage, and Accounts.

Protocol Objects

Inbox

An Inbox is an on-chain account owned by a wallet. It acts as a directory of threads and can enforce a payment rule: any new thread must include a minimum SOL payment to be accepted. A wallet can have multiple inboxes, each with its own rules and metadata.

Thread

A Thread is the conversation container between two wallets. It is created by the sender and permanently links the sender and receiver. Once open, both parties can send messages by appending to the thread. Threads hold an optional escrow balance if the inbox has escrow enabled.

Message

A Message is a single entry in a thread. It carries a type (text, url, ipfs, irys, or arweave) and a content field. User-facing payloads can be wrapped in a Packet envelope so readers can distinguish text, JSON, and binary parts by MIME type. For large payloads, the content is uploaded and the message stores the pointer. Messages can be encrypted before being written to the chain.

User & Key Accounts

A User account holds a wallet's display name and metadata URI. A Key account holds a wallet's registered public encryption key, making it possible for senders to encrypt messages to that wallet without a direct exchange.

Data Flow

Sender                        Packet Program              Receiver
  |                                  |                        |
  |-- create thread (+ payment) ---> |                        |
  |                                  |--- store thread -----> |
  |-- send message (encrypted) ----> |                        |
  |                                  |--- emit event -------> |
  |                                  |                        |-- decrypt & read

1. The sender calls createThread, optionally including a payment if the receiver's inbox requires one.
2. The program stores the thread account on-chain and emits a MessageSent event.
3. The receiver's app detects the event via WebSocket or polls the inbox.
4. The receiver decrypts the message using their private key.

Next Steps

• Encryption — how E2E encryption works and how keys are derived
• RPC and Photon — why Packet needs a ZK Compression/Photon-compatible RPC
• Costs, Storage, and Accounts — fees, upload limits, pointers, account types, and key-mode notes
• Threads & Inboxes — thread lifecycle and inbox configuration
• Payments & Escrow — payment rules and escrow mechanics