How solDM Works
Architecture overview
High-level flow
Sender encrypts message client-side
Ciphertext is stored off-chain (attachment/message blob), referenced by a pointer
Minimal messaging state (pointers + commitments/indices) is anchored on Solana
State is zk-compressed via Light Protocol for scalability
Receiver fetches ciphertext and decrypts locally
Dialect notifies the receiver of new message events (optionally)
Design goal: no central inbox server and no plaintext anywhere outside the endpoints.
What’s on-chain vs off-chain
On-chain
Minimal message state needed for ordering, discovery, and verifiability
Ciphertext pointers (never plaintext)
zk-compressed state updates (via Light Protocol)
Off-chain
Ciphertext blobs (message bodies / attachments) stored on a content layer (currently IPFS in prototype; roadmap includes more decentralized user-paid options)
Identity and verification
solDM is wallet-native. Your “username” can be:
a Solana address
a .sol name (SNS) Optional verification layers can be added using attestations (SAS/Civic-style hooks) to reduce impersonation.
Spam resistance and message requests
solDM supports “message requests” so inbox owners can control inbound:
Default messaging is low-cost (gas + a small protocol fee)
High-profile inboxes can set an optional custom attention fee for new requests
Recipients can optionally receive a share of the fee (monetize time, prioritize serious inbound)
Last updated