Marmo Privacy — Whitepaper Version 1.0 | June 2026 --- Abstract Marmo Privacy is a non-custodial, threshold-signature smart wallet built on Base. It splits a user's signing authority across three independent shards — a device key, a blind co-signer, and a passkey — requiring any two to authorise a spend. No single shard can move funds. Every payment routes through stealth addresses, making receipts unlinkable by default. Marmo combines ERC-4337 account abstraction, 2-of-3 threshold signatures, and ERC-5564 stealth addresses into a single, self-custodial product that delivers security comparable to hardware wallets, at zero additional hardware cost, with privacy that on-chain multisigs cannot offer. --- 1. Introduction 1.1 The Problem With Wallets Today Cryptocurrency wallets present users with an unacceptable trade-off. Software wallets are convenient but store private keys in memory accessible to malware. Hardware wallets are secure but cost $150 or more, arrive by post, and are locked to a single vendor's firmware. Custodial exchanges eliminate the trade-off by eliminating ownership — you hold an IOU, not the asset itself. Privacy is absent from all three options. Every on-chain transaction links sender and receiver permanently. Multi-party computation (MPC) wallets distribute key shares but route all signing requests through a central server that learns your entire transaction history. What users need is a wallet that is: - Secure against single points of failure - Accessible without specialised hardware - Private by cryptographic guarantee, not policy 1.2 What Marmo Does Marmo Privacy solves all three problems simultaneously on Base. It uses a 2-of-3 threshold scheme where the three shards live on: (A) a device you already own, (B) a non-custodial co-signer that signs blind, and (C) a passkey in your device's secure enclave. Transactions are submitted as ERC-4337 user operations, validated on-chain by a smart contract that enforces the 2-of-3 quorum. Every receive address is derived via ERC-5564 stealth address generation, making inbound payments unlinkable. --- 2. Problem Statement 2.1 Hot Wallets: Convenient but Vulnerable Browser extension wallets and mobile wallets keep private keys in software memory. A single piece of malware, a malicious browser extension, or a phishing site can extract the key and drain the wallet instantly. According to Chainalysis, over $3.8 billion was stolen from crypto wallets in 2023 alone, the vast majority from hot wallet exploits. The root cause is architectural: a single private key is a single point of failure. 2.2 Hardware Wallets: Secure but Inaccessible Dedicated hardware wallets solve the single-key problem by storing the key in a tamper-resistant secure element. However, they cost $80-$250, must be physically present for every transaction, require vendor trust for firmware, and offer no recovery path if the device is lost without the seed phrase. Seed phrases introduce their own failure mode: a 12-word phrase written on paper is a single point of failure that burns, floods, or gets found. Hardware wallets also do nothing for privacy; every transaction is as visible on-chain as any other. 2.3 MPC Wallets: Distributed but Not Sovereign Multi-party computation wallets (Coinbase Smart Wallet, ZenGo, Fireblocks) split key material across multiple parties, eliminating the seed phrase. However, the co-signing server is almost always operated by the same company, meaning the user is trusting a commercial entity not to collude, not to be breached, and not to go offline. The server also learns your IP address and signing patterns for every transaction. This is not self-custody; it is delegated custody with extra steps. 2.4 On-Chain Privacy: A Missing Layer Public blockchains are transparent by design. Every address, every transaction, every balance is visible to anyone with an internet connection. Using the same address repeatedly makes it trivial to profile a user's financial activity. Existing privacy solutions (Tornado Cash, Railgun) are post-hoc mixers that must be explicitly opted into, are increasingly regulated, and leave obvious on-chain fingerprints that signal privacy-seeking behaviour. Privacy should be the default, not an opt-in exception. --- 3. Solution Overview Marmo combines three distinct technologies into a cohesive wallet product: 1. ERC-4337 smart accounts — the wallet is a smart contract on Base, not an externally owned account. The validation logic lives on-chain and is enforced by the EntryPoint contract. 2. 2-of-3 threshold signatures — signing authority is split across three shards. Any two can produce a valid signature; no single one can. The shards are placed on independent devices and services so that compromising any one reveals nothing about the others. 3. ERC-5564 stealth addresses — every inbound payment generates a unique one-time address. Senders compute the address from a public meta-address; only the wallet owner can detect and claim it. Inflows are unlinkable by default. --- 4. Technical Architecture 4.1 Account Abstraction (ERC-4337) ERC-4337 is an Ethereum standard for smart contract wallets that avoids changes to the consensus layer. Users submit "user operations" (UserOps) to a permissionless mempool. A Bundler picks up UserOps and submits them to the EntryPoint contract (`0x0000000071727De22E5E9d8BAf0edAc6f37da032`), which calls `validateUserOp` on each account contract before executing the operation. Marmo uses EntryPoint v0.7, deployed on Base mainnet. The packed UserOperation format includes: - `sender` — the smart account address - `nonce` — replay protection, managed by EntryPoint - `callData` — the encoded function call (execute or executeBatch) - `accountGasLimits` — packed verification and call gas limits - `gasFees` — packed maxPriorityFeePerGas and maxFeePerGas - `signature` — the concatenated 2-of-3 threshold signature (130 bytes) Gas is paid from the smart account's ETH balance. Paymasters can sponsor gas, enabling gasless UX for supported tokens in future iterations. 4.2 The 2-of-3 Threshold Scheme Marmo does not use Shamir Secret Sharing or threshold signature schemes that require an aggregation round. Instead, it uses a direct multi-signature approach: each shard is an independent secp256k1 private key, and the smart contract verifies that exactly two of the three registered owner addresses co-signed a given UserOp hash. This approach is: - Simpler to audit — the on-chain logic is 85 lines of Solidity - Gas-efficient — no aggregation proof, just two ECDSA recovers - Independent — shards never meet; each signs the same hash independently The signature field is 130 bytes: two concatenated 65-byte ECDSA signatures. The contract recovers both signers and counts how many match the three registered owners. A count of 2 or more returns `validationData = 0` (valid). Fewer returns 1 (invalid). A duplicate signer (same key used twice) reverts. 4.3 Shard A — The Device Key Shard A is a secp256k1 private key generated on and stored within the user's device. On the desktop app, it is stored in the OS keychain (macOS Keychain, Windows Credential Store, Linux Secret Service). On the Telegram mini app, it is stored in the browser's localStorage. Shard A signs first, locally, without any network request. It is the key that establishes "you are here, on this device." Stealing Shard A without Shard B or C is useless: the smart contract rejects single-shard signatures. 4.4 Shard B — The Co-Signer Shard B is held by the Marmo co-signer server (`api.usemarmo.xyz`). The server is non-custodial in the following precise sense: it holds one secp256k1 private key per wallet, but a stolen Shard B alone cannot spend funds. The server must be presented with the UserOp hash and the wallet's API key before it will co-sign. The co-signer signs blind: it receives the 32-byte UserOp hash and returns a signature. It does not decode the callData, does not know the recipient or amount, and does not profile transactions beyond rate-limiting. In future versions, zero-knowledge proofs will allow the co-signer to verify spend policies without learning transaction content. The co-signer is open-source. Users who do not trust the Marmo server can run their own. 4.5 Shard C — The Recovery Key Shard C is a passkey stored in the user's device secure enclave via WebAuthn. It is never transmitted across the network. On iOS and macOS, it is backed by the Secure Enclave chip and synced via iCloud Keychain. On Android, it lives in the Trusted Execution Environment. Shard C's primary role is recovery: if a user loses Shard A (device lost or wiped), Shard C combined with Shard B allows fund recovery without Shard A. This eliminates the seed phrase entirely. There is no 12-word sequence to memorise, write down, or lose. 4.6 Smart Contract Design 4.6.1 MarmoAccount `MarmoAccount` implements `IAccount` (ERC-4337). Its state is minimal: an immutable reference to the EntryPoint and an array of three owner addresses. The validation logic: ```solidity function validateUserOp( PackedUserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds ) external returns (uint256 validationData) { if (msg.sender != address(entryPoint)) revert NotEntryPoint(); if (missingAccountFunds > 0) { (bool ok,) = payable(address(entryPoint)).call{value: missingAccountFunds}(""); if (!ok) revert PrefundFailed(); } bytes memory sig = userOp.signature; if (sig.length != 130) revert InvalidSignatureLength(); bytes32 ethHash = MessageHashUtils.toEthSignedMessageHash(userOpHash); // ... split sig into sig1 and sig2, recover signers, count matches return validCount >= 2 ? 0 : 1; } ``` `execute` and `executeBatch` are guarded by `NotEntryPoint`, ensuring only the EntryPoint can call them after validation. The contract has no upgradeability mechanism. This is intentional: an upgradeable proxy introduces an admin key that is itself a single point of failure. Marmo wallets are immutable by design. If a user needs to rotate keys (for example, after a shard compromise), they create a new account and sweep funds. 4.6.2 MarmoAccountFactory `MarmoAccountFactory` deploys `MarmoAccount` instances using CREATE2 for deterministic addressing. The factory's `predictAddress(owners, salt)` function computes the counterfactual address before deployment. This is important for UX: users can receive funds to their wallet address before the contract is deployed, because the address is known in advance. `createAccount` is idempotent: if the predicted address already has code (account already deployed), it returns the existing account without reverting. This prevents front-running attacks and double-deploy errors. 4.7 Stealth Addresses (ERC-5564) ERC-5564 defines a standard for stealth address generation and detection on EVM chains. Marmo implements the secp256k1 ECDH scheme (scheme ID 1). Each Marmo wallet has a stealth meta-address: a 66-byte public value composed of two compressed secp256k1 public keys: ``` meta-address = 0x || spendPub (33 bytes) || viewPub (33 bytes) ``` The spend and view private keys are generated locally and never leave the device. Sending to a stealth address: 1. Sender generates a random ephemeral keypair `(r, R)`. 2. Sender computes the shared secret `S = r * viewPub`. 3. Sender derives the one-time address `P = spendPub + hash(S) * G`. 4. Sender publishes `R` on-chain via the ERC-5564 `Announcement` event. Detecting incoming payments: 1. Receiver scans `Announcement` events for each `R`. 2. Computes `S = viewPriv * R` (same shared secret by ECDH). 3. Checks if `spendPub + hash(S) * G` matches the announced address. 4. If it matches, the receiver can spend using `spendPriv + hash(S)`. This scheme means every payment to a Marmo wallet goes to a unique, unlinkable one-time address. An observer watching the blockchain cannot link multiple payments to the same recipient. 4.8 The Base Network Marmo is deployed exclusively on Base, Coinbase's Ethereum Layer 2. Base was chosen for: - Low fees — transaction costs are typically below $0.01, making stealth address mechanics economically viable - EVM equivalence — all Ethereum tooling works natively - Liquidity — USDC is native on Base (Circle's CCTP), with deep Uniswap V3 liquidity - Institutional backing — Coinbase's infrastructure provides reliable RPC and block production --- 5. Security Model 5.1 Threat Analysis | Threat | Marmo Response | |---|---| | Malware steals Shard A | Useless without Shard B or C. One shard cannot spend. | | Co-signer server breached | Attacker has Shard B. Cannot spend without Shard A or C. | | Passkey device stolen | Attacker has Shard C. Cannot spend without Shard A or B. | | Network MITM intercepts co-sign request | Co-signer verifies API key; signature is over UserOp hash, not interceptable. | | Marmo company disappears | Co-signer is open-source. Users can run their own or use recovery via A+C. | | On-chain analysis of wallet | Stealth addresses make inflows unlinkable. ERC-4337 makes account structure indistinguishable from a normal EOA on-chain. | | Two shards simultaneously compromised | Funds at risk. Users should keep Shard C on a separate device from Shard A. | 5.2 What Marmo Protects Against - Single-device theft or compromise - Remote malware and phishing attacks - Co-signer server breach - Seed phrase loss (no seed phrase exists) - On-chain payment linkability 5.3 Limitations - Marmo does not protect against simultaneous compromise of two shards by the same adversary. - Marmo does not anonymise the sender's address when initiating an outbound transaction. Outbound privacy requires additional tooling (privacy pools, pending in roadmap). - Marmo does not protect against network-level surveillance (IP address correlation). A VPN or Tor is recommended for users with high threat models. - The smart contract has not yet been formally audited. A third-party audit is scheduled before the platform reaches production scale (see Roadmap). --- 6. Privacy Model 6.1 On-Chain Privacy A standard on-chain multisig (Safe / Gnosis) announces its structure publicly. The contract address is linkable to all signers via deployment transaction, and every transaction shows the multisig as sender. Marmo's approach is different in three ways: 1. Invisible signing structure — the 2-of-3 nature of the account is visible in the contract bytecode but does not appear in transaction calldata. Transactions look like standard ERC-4337 user operations. 2. Unlinkable receive addresses — stealth addresses mean no two inbound payments share a visible on-chain connection to the same wallet. 3. Blind co-signing — the co-signer sees only the UserOp hash, not the decoded transaction content. 6.2 Future Privacy Layers Outbound privacy is planned via integration with screened privacy pools. These are smart contracts that accept deposits and issue zero-knowledge proofs of compliance, allowing withdrawals to clean addresses without mixing with sanctioned funds. Unlike Tornado Cash (which mixed all funds indiscriminately), screened privacy pools can demonstrate that funds passed through the pool are not connected to illicit activity. --- 7. Comparison to Existing Solutions | Feature | Marmo | MetaMask | Ledger | Safe (Gnosis) | MPC Wallets | Tornado Cash | |---|---|---|---|---|---|---| | No seed phrase | Yes | No | No | No | Yes | N/A | | Non-custodial | Yes | Yes | Yes | Yes | Partial | Yes | | No extra hardware | Yes | Yes | No | Yes | Yes | Yes | | Multi-factor security | Yes (2-of-3) | No | No | Yes (M-of-N) | Yes | No | | Stealth addresses | Yes | No | No | No | No | N/A | | Blind co-signer | Yes | N/A | N/A | N/A | No | N/A | | Open source | Yes | Yes | Partial | Yes | Partial | Yes | | On-chain enforcement | Yes (ERC-4337) | No | No | Yes | No | Yes | | Recovery without seed | Yes | No | No | Yes | Yes | N/A | | Mobile / Telegram | Yes | Yes | No | Limited | Yes | No | 7.1 vs. MetaMask MetaMask is the most widely used software wallet. It stores a single private key derived from a seed phrase in browser storage. A compromised browser compromises the wallet entirely. MetaMask has no multi-factor protection, no privacy features, and no recovery path that does not depend on the seed phrase. 7.2 vs. Ledger Hardware Wallets Ledger provides strong key isolation via its secure element. However, it requires purchasing dedicated hardware, is unavailable when the device is not present, and depends on Ledger's proprietary firmware. Ledger's 2020 customer data breach and the controversial Connect Kit incident demonstrated that trust in a hardware vendor carries its own risks. Marmo achieves comparable security using hardware the user already owns. 7.3 vs. Safe (Gnosis) Safe is the leading on-chain multisig and the closest architectural relative to Marmo. Safe supports M-of-N signing and is battle-tested with billions in TVL. The key differences: Safe is a product for teams and DAOs, not individual users. Its UX is complex. Its on-chain structure reveals the full signer set. It has no built-in privacy layer or stealth address support. Marmo targets individual users who need Safe-grade security in a consumer product, with default privacy. 7.4 vs. MPC Wallets (Coinbase, ZenGo) MPC wallets eliminate seed phrases and provide multi-party security but route all signing through a company-operated server. The server learns signing patterns and transaction frequency. If the company shuts down, users are dependent on key recovery protocols that vary by provider. Marmo's co-signer is open-source and can be self-hosted. The on-chain enforcement means the contract itself is the source of truth, not a company's servers. 7.5 vs. Privacy Mixers Tornado Cash and Railgun break transaction linkability by pooling funds and issuing cryptographic receipts. These protocols are effective but have become heavily scrutinised by regulators. Using them signals privacy-seeking behaviour and has resulted in wallet addresses being blacklisted by centralised exchanges. Marmo's approach to privacy is proactive rather than reactive: stealth addresses prevent linkability before it is created, without requiring any on-chain mixing transaction. --- 8. Open Source and Audits All Marmo components are open source: - Smart contracts: `github.com/UseMarmo/marmo/tree/main/contract` - Co-signer server: `github.com/UseMarmo/marmo/tree/main/src` - Desktop app: `github.com/UseMarmo/marmo/tree/main/desktop` - Telegram mini app: `github.com/UseMarmo/marmo/tree/main/telegram` - Base SDK: `npmjs.com/package/@usemarmo/base-sdk` A formal third-party audit of the smart contracts is planned for Q3 2026. The contract code is intentionally minimal (under 130 lines across both contracts) to reduce audit surface area. --- 9. Conclusion Marmo Privacy demonstrates that the trade-offs users have accepted in crypto self-custody are not fundamental. Security, accessibility, and privacy can coexist in a single product. By combining ERC-4337 account abstraction with a 2-of-3 threshold signature scheme and ERC-5564 stealth addresses, Marmo delivers hardware-grade security at zero hardware cost, with on-chain privacy as the default. The threat model is simple: any one shard stolen is worthless. Any two shards together can recover the wallet. No seed phrase to lose, no vendor to trust, no mixer to touch. --- References - ERC-4337: Account Abstraction Using Alt Mempool — Vitalik Buterin et al., 2021 - ERC-5564: Stealth Addresses — Toni Wahrstatter et al., 2022 - EntryPoint v0.7 — eth-infinitism, 2024 (`0x0000000071727De22E5E9d8BAf0edAc6f37da032`) - "Blockchain Privacy and Regulatory Compliance" — Chainalysis, 2023 - "Smart Contract Wallets: Security Considerations" — OpenZeppelin, 2024 - ECDSA and secp256k1 — FIPS 186-5, NIST --- Marmo Privacy | usemarmo.xyz | contact@usemarmo.xyz Version 1.0 — June 2026