# Abstract — SolMail V2 ## **What is SolMail?** **SolMail** is a **wallet-native, censorship-resistant, and end-to-end encrypted communication protocol** built on the **Solana blockchain**. It transforms email — the most universal identity and messaging system in the world — into a **Web3-native primitive**, where every user’s **wallet is their inbox**, their **identity is an asset**, and their **email becomes a passport** across decentralized applications. With SolMail: * **Your wallet is now an inbox** → Your Solmail wallet can receive messages, invoices, or crypto assets. * **Identities are assets** → Usernames like `name@sol.mail` and domains like `dao.mail` are NFTs, ownable, tradable, and programmable. * **Messages are programmable** → Beyond text, messages can carry payments, NFTs, contracts, signatures, or DAO proposals. * **Privacy is the default** → End-to-end encryption, metadata minimization, and on-chain proofs replace surveillance-driven email models. * **Universal Web3 Login** → SolMail IDs act as a **single sign-on (SSO) credential** for the Solana ecosystem, enabling users to access dApps and platforms securely with one wallet and one identity. **Why SolMail?** Legacy email is centralized, surveilled, and fragile: * Mailboxes are rented from providers (Gmail, Outlook), not owned by users. * Sender authentication is patchy, enabling **phishing, spam, and impersonation**. * Payments, contracts, and workflows are fragmented across external systems. **SolMail solves these gaps by design:** * **Interoperability** → Handles, domains, wallets, and Solana Name Service all resolve to a single, verifiable communication standard. * **Censorship Resistance** → The protocol has no gatekeepers; rules are enforced by math and governance, not corporations. * **Communication + Settlement** → Messaging, payments, and signatures converge in the inbox. * **Identity Sovereignty** → Every identity is cryptographically secured and tradable. * **Universal Web3 Access** → Users can log in to multiple Solana dApps with their SolMail ID, consolidating identity and wallet management into a single secure layer #### Mission SolMail’s mission is to onboard the next million users to **sovereign communication and identity** on Solana by: * Making **email-style onboarding** simple and familiar for new users. * Embedding **financial and organizational primitives** (payments, contracts, governance) directly into messaging. * Acting as a **universal login and identity service** for Web3 users across Solana platforms. * Ensuring **trustless, censorship-resistant coordination** for individuals, DAOs, enterprises, creators, and NGOs. #### Principles * Privacy by Default — End-to-end encryption, client-side storage, and cryptographic sender verification ensure no central authority can surveil or censor. * Ownership by Design — Identities, messages, and namespaces are assets you own, not licenses from intermediaries. * No Gatekeepers — The protocol is open, permissionless, and censorship-resistant. Anyone can send to a wallet, even without an account. * Security Over Hype — Technical integrity is prioritized over marketing narratives; claims are grounded in code and on-chain proofs. # Background & Problem Definition #### Email's Legacy Email remains the **most universal communication protocol** in the world, but its foundations are outdated and fragile: * **Centralized Hosting** → Mailboxes are controlled by corporations like Google or Microsoft, creating choke points for censorship, surveillance, and lock-in. * **Surveillance by Default** → Metadata and even message content are harvested for profiling, ads, and government requests. * **Weak Authentication** → Legacy standards like SPF, DKIM, and DMARC are optional and inconsistent, leaving users vulnerable to impersonation and spoofing. * **Spam & Phishing Epidemic** → Billions of spam emails cost the world billions in fraud, scams, and lost productivity. 👉 Despite being universal, **email is neither private, nor secure, nor owned by its users**. #### Identity Fragmentation in Web3 Web3 today suffers from **disconnected identity silos**: * **Wallets** → hold assets and sign transactions, but cannot natively communicate. * **Domains** (e.g., `.sol`, ENS, `.com`) → provide names, but lack universal communication or trust guarantees. * **Email** → remains separate from both, forcing users to juggle multiple accounts, identifiers, and credentials. This creates **friction and value leakage**: * A DAO might use Discord, a domain, and multiple wallets to coordinate. * An enterprise juggles Google Workspace for communication, plus a wallet for treasury, plus custom tools for contracts. * An individual may have multiple wallet addresses, a `.sol` name, and several emails — but no unified identity. 👉 There is **no standard, verifiable identity + communication system** that bridges Web3 and the familiar email metaphor. #### Missing Primitives in Legacy Systems Legacy email and identity systems are fundamentally **incapable of serving Web3’s needs**. They lack: * **On-Chain Provenance** → No cryptographic proof of who actually sent a message. Reputation is off-chain and easily faked. * **Programmable Settlement** → Payments, contracts, and invoices are disconnected from communication, forcing users into risky off-platform links. * **Immutable Audit Trails** → No tamper-proof history of communication or agreements. * **Sovereignty** → Identities are rented from providers, not owned by users. 👉 Web3 requires **communication as a native primitive**, secured by private keys and enforced on-chain. #### Requirements for Web3 Communication For communication and identity to be **native to Web3**, SolMail establishes four non-negotiable requirements: 1. **Cryptographic Identity** → Usernames, inboxes, and domains must be secured by private keys, not rented accounts. 2. **End-to-End Encryption (E2EE) by Default** → Messages and attachments are encrypted client-side; only sender and receiver can access them. 3. **Composability** → Communication must seamlessly integrate with DeFi, NFTs, DAOs, payments, and decentralized storage. 4. **Final Settlement** → Messages, invoices, and agreements must **settle on-chain**, with the same security guarantees as asset transfers. # System Overview #### Architecture in One Page SolMail is structured into four composable layers, each independently upgradable yet cryptographically bound on Solana: * Identity Layer — Unified naming and ownership. Users can send/receive using wallet addresses, Solana Name Service (.sol), .mail domains (alice.mail), or familiar email-style handles (). Usernames are NFTs, tradable and transferable, secured on-chain. * Messaging Layer — Wallet-native inbox with end-to-end encryption (ElGamal), client-side encrypted attachments via decentralized storage (e.g., Irys), and immutable audit trails. Messages double as programmable objects that can carry tokens, NFTs, invoices, or contracts. * Economic Layer — $MAIL token powers premium features, spam deterrence (burn-to-send economics), and marketplace dynamics on mail.fun (identity auctions, newsletters, creator subscriptions). Integrated Solana Pay ensures low-fee, instant settlement for invoices and commerce. * Governance Layer — MailDAO governs protocol upgrades, treasury allocation, spam-prevention economics, and ecosystem integrations. Governance is transparent, on-chain, and community-led.
#### User Model * Universal Access: Every Solana wallet is a potential inbox — you can send a message to any wallet, even if the receiver has not yet created a mailbox. * Optional Mailbox: Users can opt-in to claim a SolMail identity () or .mail domain, but this is not required to receive communication. * Pseudonymous or Verified: SolMail supports dual modes of identity. Users may remain pseudonymous, or cryptographically bind their handle to real-world credentials. The choice is deliberate, user-controlled, and privacy-maximalist. #### 3.3 Interoperability (Interop) * .mail Domains: Fully on-chain NFT domains (e.g., alice.mail, org.mail). Function as independent namespaces, tradable and ownable assets. * Handles: Familiar, email-style usernames linked to SolMail accounts. Usable with or without a .mail domain. * mail.fun Marketplace: Hub for identity trading, creator subscriptions, newsletters, and merchant verification. Bids, auctions, and identity monetization happen here. * Optional Linkage: Users may link alice.mail → for convenience and routing, but both remain sovereign identifiers. # Identity Layer Identity is the foundation of any communication system. In Web2, this role is played by email addresses — identifiers issued and controlled by centralized providers. They appear simple and familiar, yet their ownership is fragile: users cannot freely trade them, move them across providers, or cryptographically prove authorship. In Web3, identity must be sovereign, transferable, verifiable, and censorship-resistant. SolMail introduces a dual identity model — handles and .mail domains — designed for user flexibility, organizational control, and long-term resilience. #### (Handle) The handle is the most user-friendly entry point into SolMail. It mirrors the familiar format of email addresses while mapping directly to a wallet on Solana. For a new user, this is critical: they can communicate without learning complex key strings, ENS-style domains, or new conventions. * Every handle is represented as a non-fungible token (NFT), which confers true ownership and portability. A user may trade or lease their handle in secondary markets, an impossibility with Gmail or Outlook identifiers. * Unlike Web2 addresses, the binding between handle and wallet is enforced by Solana’s state machine, not a centralized registrar. This ensures that even if SolMail ceases to exist, the handle continues to be resolvable on-chain. * Users are free to operate pseudonymously (a random handle bound to a wallet) or with identity verification (linking a handle to a verified entity). This flexibility acknowledges the dual needs of privacy and legitimacy. By design, the handle is optional: any wallet can receive SolMail messages, even if no handle is claimed. This keeps the system open, permissionless, and inclusive. #### .**mail Domains (NFT)** The second component of the identity layer is the .mail domain namespace. Domains like alice.mail, dao.mail, or org.mail are minted as on-chain NFTs. They function as sovereign namespaces, comparable to DNS domains but enforced entirely by smart contracts. * Ownership and tradability: A .mail domain is an asset — transferable, saleable, leasable — under the full control of its holder. * Organizational use: DAOs, companies, or collectives can claim domains such as dao.mail and subdivide them into role-based or departmental inboxes (finance.dao.mail, support.dao.mail). * Programmability: Unlike DNS, which requires middleware for payments or governance, .mail domains inherit Solana’s programmability. This allows automated subscriptions, role changes, and cross-app resolution without intermediaries. The .mail namespace creates a parallel identity plane: one that is organization-first, asset-driven, and composable with Web3 primitives. #### Separation & Optional Linkage A defining principle of SolMail is that handles and domains are independent. * A user may operate only with a handle (), only with a domain (alice.mail), or both. * If desired, they can link the two, mapping alice.mail to for human-readable routing and branding. This separation avoids the namespace monopolization problem that plagues DNS and ENS. No actor can corner both the address and the domain space. It also protects users: losing a domain does not revoke their handle, and vice versa. #### Resolution & Discovery Behind the UX simplicity lies a deterministic resolution system: * Mappings: Handles ↔ Wallets ↔ Domains ↔ Solana Name Service (.sol) identifiers. * Caching rules: Clients can store verified resolutions for performance while relying on cryptographic proofs for integrity. * Universal messaging: Anyone can send to a wallet using any of its identities. Whether the sender knows 0x…, , or alice.mail, the system ensures that messages reach the same target. This makes SolMail both backward-compatible with wallets and forward-compatible with traditional email metaphors. It creates a bridge for adoption while remaining trustless. #### Reserved Names Policy Identity systems must grapple with impersonation and brand squatting. SolMail addresses this through a transparent, governance-driven release process: * Sunrise Period: Institutions, verified brands, and ecosystem partners may pre-claim names to prevent phishing vectors. * Claims and Disputes: A structured, on-chain process allows legitimate rights holders to contest names. * Community Oversight: All rules are enforced by MailDAO, ensuring no centralized authority decides unilaterally. Unlike Web2 registries, this process is open, auditable, and amendable by governance vote. \\ # Messaging Layer If the Identity Layer establishes who you are, the Messaging Layer defines how you communicate. Traditional email is a patchwork: plaintext origins, later bolted-on TLS, clunky MIME attachments, and endless spam countermeasures. It is interoperable, but brittle, surveilled, and inherently insecure. SolMail rethinks messaging as a wallet-native, end-to-end encrypted (E2EE), censorship-resistant protocol that integrates financial primitives, not ads or intermediaries. #### Design Principles 1. Wallet as Inbox: Every Solana wallet can receive messages without requiring extra setup. Users may later opt into a full SolMail mailbox for enhanced UX, but the baseline is universal addressability. 2. E2EE by Default: Encryption is non-optional. Messages are encrypted client-side using ElGamal, attachments with AES-256, and signed with Ed25519. This prevents providers, relayers, or infrastructure nodes from inspecting contents. 3. On-Chain Metadata: Unlike Web2 email headers (easily forged), SolMail enforces cryptographic provenance. Sender, timestamp, and integrity checks are immutably anchored on-chain. 4. Programmability: A message isn’t just text. It may carry tokens, NFTs, invoices, or signed approvals — all verifiable and executable without leaving the inbox
#### Message Format Solmail uses a format inspired by RFC 5322/2045, with a modified structure for decentralized and encrypted messaging. The message layout is divided as follows, where all fields except the version are encrypted, stored in a decentralized network as hashes, and referenced in the Mail’s account buffer. **Header** Header Includes * Version * Encrypted recipient wallet info * Identity proof (handle/domain, tagged as origin) **Body** * Encrypted payload (can be plain text, structured JSON, or command instructions). **Attachments:** * Contains hash mappings for attachments. * Each hash points to a file stored in a chosen decentralized storage provider. **Plugins:** * Each plugin defines its own identifier keys. * Plugin data is structured in JSON and consumed by compatible client-side plugins for rendering. **Audit Trail:** Every message is anchored on the Solana ledger, providing an immutable log while keeping message content private. **Versioning Paradigm:** Unlike semantic versioning, Solmail uses client-based mapping for the major version * 1 = Web client * 2 = Mobile client * 3 = DApp client * Minor and patch versions indicate iterations. #### Inbox = Wallet (Email-as-a-Wallet) The central innovation of SolMail is EaaW (Email-as-a-Wallet). In practice: * A DAO treasurer sends a payroll message → attached token transfers execute with one tap inside the inbox. * A freelancer receives an invoice → the recipient pays instantly via Solana Pay, directly from the message thread. * A DAO circulates a governance proposal → members sign approvals or multi-sig requests within the same thread. The inbox ceases to be a passive communication channel and becomes an active financial and organizational command center. #### Attachments and Storage Attachments are often the weakest link in email security. SolMail addresses this by: * Distributed Storage: Files are uploaded to decentralized storage (e.g., Irys). * Client-Side Encryption: Only recipients hold keys, ensuring no relay or node can leak sensitive files. * Verifiable Integrity: Every attachment is hashed, signed, and logged on-chain, preventing tampering or “man-in-the-middle” substitution. Thus, an attached contract or invoice is as tamper-proof as the blockchain itself. #### Notifications and Real-Time Sync Modern users expect more than just inbox refreshes. SolMail integrates: * Wallet-Native Alerts: Notifications flow directly to Phantom, Solflare, or any Solana wallet. * Push Infrastructure: Mobile apps receive encrypted push notifications without exposing message content. * Battery-Aware Sync: Background updates minimize device resource usage — essential for Solana Mobile and future Seeker integrations. \\ # Email-as-a-Wallet (EaaW) The inbox has always been humanity’s primary digital interface for coordination — contracts, invoices, payments, confirmations, negotiations. Yet, in Web2 email, these flows terminate in links: “Pay here,” “Sign there,” “Confirm in another portal.” Trust is offloaded to centralized servers, UX is fragmented, and the audit trail is easily lost. SolMail introduces Email-as-a-Wallet (EaaW), where messages are not just text, but programmable, executable objects. Every SolMail message can carry assets, trigger verifiable actions, and settle value — all cryptographically signed, all inside the conversation thread. This collapses the gap between identity, communication, and financial execution, turning the inbox into a sovereign financial surface. #### In-Message Assets: The Inbox as a Ledger In Web2 email, an “attachment” is a PDF or photo. In SolMail, attachments extend to tokens, NFTs, DAO membership proofs, and other cryptographic assets. A parent can send their child SOL as “lunch money” directly in a message. A DAO treasury manager can distribute governance tokens through a signed proposal thread. This works because the inbox itself is backed by the wallet: * Every message is cryptographically tied to a wallet address. * Asset actions (send/receive/transfer) appear inline, visually continuous with the message body. * The entire conversation becomes a ledger of stateful interactions, providing an immutable audit trail that communication and value transfer occurred together. This reimagines the inbox as a dual ledger — one of words, one of assets. #### Invoices & Receipts: Native Financial Communication One of the most broken patterns in email today is billing. Invoices are PDFs or HTML tables, payments are links, and reconciliation is manual. Fraud and phishing thrive because users are trained to “click and pay” without cryptographic guarantees. In SolMail, invoices are first-class citizens: * Solana Pay schemas provide a structured, machine-readable standard. * A freelancer sends an invoice; the recipient sees an inline “Pay Invoice” button, with the transaction previewed and simulated. * Upon settlement, a signed receipt is written to the chain, permanently provable. * Disputes are handled by appending counter-claims to the same immutable thread, rather than via opaque email forwarding. The result: SolMail threads become living contracts — invoices, receipts, and counter-claims coexisting as verifiable records, resistant to tampering and fraud. Safe Execution: Hardening the Inbox Merging messaging and settlement introduces new risks: phishing, malicious requests, user error. SolMail counters these risks with safety patterns at the protocol level: * Transaction previews: Before signing, the user sees a human-readable breakdown (“You will send 2.5 SOL to dao.sol”). * Simulation environment: Transactions are dry-run against Solana state, ensuring that outcomes (e.g., token transfers, program calls) are predictable. * Spending limits: Users can configure daily/weekly caps, per-sender thresholds, or require multi-sig approval for high-value actions. * Verified sender cryptography: Messages from known wallets or .mail domains carry strong verification signals, reducing spoofing and phishing vectors. Here, the inbox is not a security weak point, but a hardened, wallet-native environment with built-in guardrails. #### Trading Utility (Not Speculation): Inbox as Market Interface Trading inside communication platforms is usually marketed as “engagement.” SolMail treats trading differently: not as speculation, but as a utility layer that enables action in context. * A DAO discussing treasury rebalancing can view live token prices inline. * A project issuing an invoice in USDC can allow the payer to swap SOL → USDC at best available routing through Jupiter directly in the invoice thread. * A subscriber to a creator newsletter can convert tokens at point of subscription, without leaving the inbox. Trading is invisible infrastructure — present when needed, abstracted away otherwise. This positioning aligns SolMail not with “trading apps,” but with financial primitives embedded into communication flows. #### The Paradigm Shift: Communication as Execution With EaaW, SolMail redefines what “email” means: * A conversation is no longer just talk — it is action. * The inbox is not just a mailbox — it is a sovereign interface for ownership. * Identity, messaging, and settlement collapse into one plane of interaction. In the same way that early email replaced fax machines by merging text + attachment, SolMail’s EaaW replaces portals, links, and middlemen by merging communication + cryptographic settlement. \ \\ # Notifications & Channels The value of a messaging system is defined not only by its ability to store and send messages but also by how effectively it keeps users aware of critical events in real time. SolMail introduces a decentralized notifications and broadcast architecture designed for Web3’s scale and needs: cryptographic trust, token-gated participation, and efficient delivery across mobile and desktop environments. #### Real-Time Alerts * Wallet-Native Alerts: SolMail integrates directly with Solana-native wallets such as Phantom, Solflare, and Solana Mobile’s Seeker. Notifications are not siloed to the application — they surface in the wallet, ensuring every transaction, invoice, or signed document is anchored in the same identity context. * Push Integration: Beyond wallet pop-ups, SolMail provides OS-level push notifications through iOS and Android apps. This guarantees user awareness even when the app is not actively running. * Background Sync: The protocol employs lightweight background jobs that sync messages and pending transactions without consuming unnecessary bandwidth. Sync intervals are optimized to maintain low latency while preserving device battery life. * Battery-Aware Logic: Energy efficiency is critical for mobile-first adoption. SolMail leverages event-driven notifications (on-chain triggers + off-chain relays) to minimize constant polling, ensuring a high-performance experience that does not drain user devices. #### Channels Channels expand SolMail beyond one-to-one messaging into community-wide communication primitives tailored for DAOs, projects, and enterprises. * Broadcast Lists: DAOs, DeFi protocols, or NFT projects can maintain broadcast lists — pushing announcements, governance updates, or airdrop alerts directly into members’ inboxes. * Token-Gated Access: Subscribing to a channel may require holding a DAO’s governance token, an NFT pass, or a .mail identity. This creates natural economic filters that reduce spam while ensuring authentic membership. * Moderator Roles: Channels are multi-admin by design. Roles include creators, moderators, and auditors, allowing distributed teams to manage communications securely. * Rate Controls: To prevent abuse, SolMail enforces rate limits and message quotas, which can be dynamically adjusted by token-weighted governance or MailDAO. For instance, a DAO might limit channel messages to one per day unless voted otherwise. #### Subscriptions Channels and newsletters integrate a billing and subscription layer powered by Solana Pay and $MAIL. * Billing Models: Subscriptions can be priced in SOL, USDC, or $MAIL, enabling flexible monetization and stable treasury management. Tiered pricing allows projects to differentiate between free, premium, and token-gated content. * Tier-Downgrade Rules: If a subscriber fails to renew, access gracefully downgrades to the free tier without abrupt lockouts, ensuring continuity while protecting creators. * Failover & Retry Policies: To counter on-chain settlement failures (e.g., insufficient gas or missed renewal), SolMail implements retry mechanisms with backoff strategies. Users are notified of failures, and subscriptions can auto-retry with pre-authorized allowances. #### Why It Matters Notifications and channels are the heartbeat of a communication system. Without them, messages risk being invisible; with them, SolMail transforms into a living, real-time protocol that can support DAOs, creators, and enterprises alike. Channels ensure communities can scale, while token-gated subscriptions align incentives and guarantee sustainability. # Newsletters & Publishing (Censorship-Resistant) In SolMail, newsletters and publishing are re-imagined as on-chain, verifiable broadcasts. Instead of depending on centralized providers like Substack, Mailchimp, or Medium — which are vulnerable to takedowns, censorship, and surveillance — creators, DAOs, and NGOs can use SolMail to publish directly from their own sovereign namespace. The result is trustless publishing with built-in monetization and cryptographic proof of authorship. #### Author Identity Every newsletter issue in SolMail carries a cryptographically verifiable author identity. Authors can publish from a .mail domain (e.g., yourdao.mail) or from their identity handle (). Each issue is anchored to an immutable on-chain index, ensuring that publications cannot be edited or silently deleted once released. * Ownership by Design: The publishing address is a wallet; the content is hashed and timestamped. * Immutable Index: Readers can verify authenticity and chronology, preventing “revisionism” or stealth censorship. * Multiple Authors: Organizations can configure multi-sig authoring, so only quorum-approved issues are broadcast. This model transforms publishing into a sovereign act — the sender’s identity is a verifiable cryptographic entity, not a server-admin-approved email address. #### Payments & Tiers Publishing is natively integrated with SolMail’s programmable economics, allowing creators and communities to monetize their content without intermediaries. * On-Chain Subscriptions: Readers subscribe directly using SOL, USDC, or $MAIL. * Tiers & Unlockables: Publishers can define subscription levels (free, premium, enterprise) with tiered content access. * NFT Passes: Subscriptions can be represented as NFTs, enabling resale, gifting, or DAO-based collective subscriptions. * Anti-Spam Gating: Payment or staking requirements make spam newsletters economically infeasible. This ensures creators retain 100% of their subscriber revenue and readers enjoy censorship-resistant access to the content they support. #### Verifiability All published newsletters carry cryptographic proofs: * Content Hashes: Each issue is hashed and registered on-chain, enabling integrity checks. * Timestamps: Blockchain timestamps provide immutable ordering of issues. * Public Proofs: Any reader can verify authenticity using SolMail’s verification tools. * Reader Privacy: Subscriptions are optional to disclose — users can read without exposing wallet contents through privacy-preserving proofs. The result is a publishing platform that provides the same ease of use as email newsletters, but with cryptographic assurances and censorship resistance. #### DAO/NGO Funding Publishing in SolMail is not just about communication — it is also a funding and transparency mechanism for DAOs, NGOs, and activist organizations. * Direct Cause Funding: Each issue can embed a donation or payment link (SOL/USDC/$MAIL). * Transparent Treasury Routing: Subscriptions or donations can be routed directly to a DAO treasury, visible on-chain. * In-Publication Transparency: Readers see both the message and the financial routing, creating radical accountability. This makes SolMail an ideal platform for mission-driven organizations: DAOs issuing governance updates, NGOs running transparent fundraising campaigns, or grassroots movements publishing censorship-resistant dispatches. \\ # Mobile (Solana Seeker + MWA) 1 SolMail is built with the understanding that mobile is the primary interface for the next wave of Web3 adoption. The majority of users worldwide will experience Solana not through a desktop wallet or browser extension but through their phone. Solana’s Seeker device and the Mobile Wallet Adapter (MWA) standard give us the primitives to deliver a secure, seamless, and offline-capable experience. Mobile support in SolMail is not a “nice-to-have” but a core architectural pillar — one that ensures keys remain safe, UX feels native, and communication never stops. #### Keys & UX — Secure Mobile Identity * Seed Vault Integration\ On Solana Mobile Seeker, keys are protected by Seed Vault, a hardware-backed secure enclave that never exposes the raw private key material. SolMail leverages this to guarantee that even high-value email-as-transactions, document signatures, or DAO votes are approved at hardware level. * Biometric Approvals\ SolMail integrates with device biometrics (Face ID, fingerprint, secure PIN) to approve actions — making transaction confirmation as simple as opening your inbox. This ensures a familiar and fast UX without weakening cryptographic security. * Mobile Wallet Adapter (MWA)\ SolMail uses MWA for interoperability with Phantom, Solflare, Backpack, and other mobile wallets. This means users don’t need to import their keys or compromise custody — they can authorize SolMail directly from their existing wallet, preserving sovereignty. * UX Principle: “Your inbox is your wallet.” Each email-like message can contain money, NFTs, signatures, or instructions — but from a user’s perspective, it looks like checking mail, not coding transactions. #### Gas Abstraction — Invisible Settlement Layer * Fee Sponsors & Relayers\ Messages that require Solana transactions (e.g., sending tokens, signing invoices) can be meta-transactions sponsored by relayers or the protocol. This allows users to send/receive without always holding SOL. * Meta-Transaction Patterns\ SolMail adopts the separation of signers pattern: the user signs intent, while a relayer wraps and submits the transaction. This maintains user control but removes UX friction. * Dynamic Fee Management\ Enterprises or DAOs can sponsor fees for their subscribers, newsletters, or team members. Subscriptions, invoices, or bounties can be billed in USDC or $MAIL, while fee accounting happens transparently in the background. * Outcome: On mobile, using SolMail feels gasless, with advanced patterns hidden from end-users but fully verifiable on-chain. One of the biggest friction points in Web3 is transaction fees and the cognitive overhead of paying them. SolMail introduces gas abstraction on mobile: #### Offline-First — Communication That Doesn’t Break Mobile users operate under constraints: poor connectivity, battery sensitivity, or limited background permissions. SolMail addresses this with an offline-first design: * Local Queue for Actions\ If a user signs an invoice, sends a message, or attaches tokens while offline, SolMail queues the encrypted payload locally. Once connectivity resumes, the protocol broadcasts and finalizes the transaction. * Background Decrypt\ Encrypted emails and attachments can be fetched, decrypted, and cached locally for offline reading. This ensures that even in low-network regions, SolMail functions like a normal inbox. * Secure Notifications\ Push notifications are signed and privacy-aware. Instead of leaking message metadata to centralized servers, SolMail delivers short, signed event alerts (e.g., “You received a payment request”) without exposing full contents until the app decrypts locally. * Battery-Aware Logic\ Background sync is adaptive — low-power modes fetch only headers and proofs, while full sync waits for charging/wifi. This makes SolMail usable in real-world mobile conditions, not just ideal labs. #### Summary SolMail’s mobile design turns the phone into a censorship-resistant Web3 communication hub: * Keys never leave secure enclaves. * Gas fees disappear behind abstraction. * Offline-first logic ensures messages never stall. Together, this enables billions of mobile-native users to join Solana’s ecosystem without even realizing they crossed a frontier. \\ # Document Signing (SolSign) Trust in agreements today is mediated by centralized SaaS platforms like DocuSign or Adobe Sign. While these services are convenient, they rely on closed databases, proprietary formats, and a “trust-us” audit trail. A signature is as good as the company’s servers and uptime. Revocations, disputes, and version history remain subject to corporate control, not cryptographic guarantees. SolMail introduces SolSign: a protocol-native signing layer that makes agreements cryptographic, verifiable, and composable with the same inbox-first UX. Just as SolMail merges messaging and settlement into one surface, SolSign merges communication and formal attestation. **Architecture**
#### Use Case: Signing as a First-Class Primitive SolSign enables the Web3-native equivalent of DocuSign, but with far stronger guarantees: * Approvals & Agreements: Any PDF, plain text contract, or structured payload can be attached and circulated within a SolMail thread for signature. * Multi-Signature Workflows: DAO constitutions, treasury disbursements, or corporate resolutions can require multiple signers in ordered or parallel workflows. * Role-Based Controls: Enterprises can enforce signature rules tied to organizational roles (e.g., CFO must co-sign invoices over $50k). In short: every SolMail thread can become a contract space, with cryptographic enforcement and programmable logic. #### Content Hashing: Canonical Proof of What Was Signed The problem with Web2 signing is ambiguity: what exactly was signed? Was the PDF altered before or after? SolSign enforces canonicalization: * Every document is hashed into a SHA-256 digest, ensuring content immutability. * Hashes are timestamped on-chain to create an independent proof of existence and sequence. * Signer sets are explicitly bound to the digest, ensuring that signatures apply only to the unaltered version. This guarantees that what is signed today is exactly what is provable tomorrow, in any jurisdiction or dispute. #### Attestations: Beyond a Scribble on a File SolSign treats signatures as on-chain attestations, not merely “images pasted on PDFs.” * Ed25519 signatures ensure cryptographic binding between signer identity and content. * On-chain attestations create a permanent, timestamped record of who signed and when. * Revocation mechanisms allow signers to invalidate their own attestations with proper key proof. * Versioning support enables iterative drafts, with hash-linked lineage from draft → signed version → amended version. * Immutable audit trails allow any observer to verify the integrity of the process without trusting a vendor’s database. The result: signatures are not just marks on a file, but provable facts embedded into the ledger of communication. #### Enterprise Hooks: From Compliance to Longevity Enterprises and DAOs require more than signatures; they require governance, retention, and auditability. SolSign extends signing into an enterprise-grade primitive: * Legal Hold Policies: Organizations can cryptographically lock documents from deletion once under investigation. * Retention Rules: Signed agreements can be automatically retained for 7, 10, or more years, with cryptographic proofs of continuity. * Exportable Proofs: Signatures and hashes can be exported in verifiable bundles, enabling use in legal proceedings or migration across systems. * Audit Trails: Every action — draft creation, signature, revocation, amendment — is logged immutably, providing compliance-ready evidence for regulators and courts. These features make SolSign suitable for both grassroots DAOs and global enterprises, serving as the DocuSign of Solana, but without the gatekeepers or single points of failure. # Mail.fun **Mail.fun** is the decentralized marketplace layer of the SolMail ecosystem. It enables users to **buy, sell, trade, and link Web3 usernames** (such as `alice@sol.mail`) as NFTs on Solana. Mail.fun transforms usernames into **programmable digital assets**, turning identity into an economy. Mail.fun extends SolMail’s identity layer by: * Allowing **username ownership and transfer** via NFT standards. * Creating a **marketplace for usernames**, newsletters, and creator subscriptions. * Enabling **identity-linked assets**, where a username can be directly bound to a SolMail inbox, wallet, or dApp login. #### Background & Problem In traditional Web2 ecosystems: * Email IDs and usernames are **owned by centralized providers** (Google, Twitter, etc.). * Transfers of identity (usernames, domains) are **restricted** and often non-permissible. * No secondary market exists for **digital identity assets**. Mail.fun solves this by leveraging Solana’s **NFT and DeFi infrastructure**, making usernames **fully user-owned, tradable, and composable**. #### Core Features **Username NFTs** * Each SolMail username (e.g., `alice@sol.mail`) is minted as an **NFT on Solana**. * Ownership of the NFT = control over the username. * NFT metadata links the username to: * SolMail inbox * Wallet address * Profile details **Marketplace** * Built-in auction system for trading usernames. * Users can: * List usernames for fixed price or auction. * Bid and purchase desired usernames. * Bundle usernames with SolMail accounts for premium valuation. **Linking & Identity** * Multiple usernames can be linked to a **single SolMail inbox**. * Supports **aliasing** for traders, creators, or businesses. * Marketplace supports **“identity bundles”** (e.g., a set of related usernames). #### Architecture Overview **Components** 1. **Frontend (Web App / dApp)** * React-based interface for browsing, bidding, and linking usernames. 2. **Backend / Indexer** * Off-chain service for querying NFT ownership, auction status, and historical trades. 3. **Smart Contracts** * **Registry Program**: Maintains mapping of usernames → NFTs → inboxes. * **Marketplace Program**: Handles listing, bidding, auctions, and transfers. * **Treasury Program**: Collects trading fees (in $MAIL or $SOL). 4. **Storage** * Metadata stored on Arweave for persistence and immutability. #### Example Flow Alice wants to buy `cryptoalpha@sol.mail` * Alice visits Mail.fun marketplace. * Sees `cryptoalpha@sol.mail` is available. * Places a bid in $MAIL/ $Sol. * Auction closes → Alice wins. * `cryptoalpha@sol.mail` NFT is transferred to Alice’s wallet. * Alice links the username to her SolMail inbox. \\ # SolMail Rewards The **Reward Panel** is the gamified engagement layer of SolMail. It incentivizes users to onboard, trade, refer friends, and interact within the SolMail ecosystem by granting **XP (Experience Points)** and **MAIL tokens**. Rewards create a loop of engagement: * Users perform actions → earn XP → unlock milestones → receive boosts and token rewards. * XP translates into progress toward tiers that grant multipliers for future earnings. #### Core Components #### XP System * **XP (Experience Points)** are the universal score in SolMail. * Users earn XP by completing actions such as: * Onboarding (creating wallet, sending first email). * Trading activity. * Referrals. * Completing quests or campaigns. * XP is **non-transferable** but directly contributes to: * **Milestone achievements**. * **Reward multiplier boosts**. * **Eligibility for MAIL token and other airdrops**. #### Milestones & Tiers * Milestones are **achievement-based levels** unlocked by reaching certain XP thresholds. * Each milestone has a **name, XP requirement, and reward boost rate**. #### Referrals * Referrals are a core driver of SolMail adoption. * Each user receives a **unique referral link/code**. * When a referred user signs up: * Referrer earns **XP tokens**. * Referral is recorded under “My Friends” tab. # $MAIL ### **Enhancing platform functionality** **Customization and upgrades** Users can burn $mail tokens to unlock additional functionalities within the SolMail platform. This could include aesthetic customizations like themes, or functional upgrades such as additional security features. The act of burning $mail for enhancements serves a dual purpose: it rewards active platform engagement and simultaneously supports the currency's value by reducing its overall supply. **Plugin integration** The future of SolMail includes potential integrations with other decentralized platforms. Should such partnerships materialize, $mail would enable users to access additional plugins or features. For example, integrating a chat function from a decentralized CHAT platform into SolMail might require burning a certain amount of $mail, thus seamlessly expanding the platform's capabilities while maintaining a user-driven ecosystem. **MailDrop: A novel way to share** **Token gifting via email:**\ \ One of the innovative uses of $mail is the ability to perform a "MailDrop," a feature that allows users to send $mail tokens as gifts directly through email. To initiate a MailDrop, a user must burn a minimum of 1000 $mail. This feature not only adds a unique layer of interaction within the SolMail ecosystem but also encourages the circulation and utility of $mail tokens, enhancing their intrinsic value and appeal. The MailDrop function embodies the spirit of community and generosity inherent to the blockchain world, enabling users to surprise friends or colleagues with token gifts that carry real value and utility within the SolMail ecosystem. **NFT Integration** Transform your email background into a digital canvas, showcasing stunning artworks from emerging and established artists in the NFT space. Each background NFT represents a unique piece, adding an element of exclusivity and personal expression to your digital correspondence. **Signature NFT** Elevate your email signature with artistic flair. Signature NFTs allow for creative signatures that go beyond text, including animated graphics or artist signatures, making every email you send a statement of your personal style and interests. ### Governance and the MailDAO The future introduction of MailDAO represents a significant step towards decentralizing governance and ensuring that $mail holders have a voice in the platform's development and decision-making processes. This approach aligns with the broader ethos of blockchain and DeFi projects, prioritizing transparency, community input, and shared ownership. The commitment to transition the development wallet to the DAO ensures that no tokens will be sold or major decisions made without the consensus of $mail holders. This mechanism is designed to align the interests of the developers with those of the community, fostering a sense of mutual investment in the platform's success and integrity.