Marmo Privacy
Whitepaper

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.

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 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:

• 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-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.
• 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, nonce, callData, accountGasLimits, gasFees, and the 130-byte threshold signature. Gas is paid from the smart account's ETH balance.

4.2 The 2-of-3 Threshold Scheme

Marmo 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. 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.

This approach is simpler to audit than threshold signature schemes that require aggregation rounds, gas-efficient (two ECDSA recovers), and fully independent — shards never meet, each signs the same hash separately.

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. On the Telegram mini app, it is stored in localStorage. Shard A signs first, locally, without any network request. 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. 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 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. 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. Shard C's primary role is recovery: if a user loses Shard A, Shard C combined with Shard B allows fund recovery. This eliminates the seed phrase entirely.

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.

function validateUserOp(
    PackedUserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 missingAccountFunds
) external returns (uint256 validationData) {
    if (msg.sender != address(entryPoint)) revert NotEntryPoint();
    // recover sig1 and sig2 from 130-byte signature
    // count matches against owners[3]
    return validCount >= 2 ? 0 : 1;
}

The contract has no upgradeability mechanism. An upgradeable proxy introduces an admin key that is itself a single point of failure. Marmo wallets are immutable by design.

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, allowing users to receive funds before the contract is deployed. createAccount is idempotent: if the account already exists, it returns it without reverting.

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)

Sending: The sender generates a random ephemeral keypair, computes a shared secret via ECDH with the recipient's view key, and derives a one-time address from the spend key. The ephemeral public key is published via an on-chain Announcement event.

Detecting: The receiver scans Announcement events, computes the shared secret using their view private key, and checks if the derived address matches. If it matches, the receiver can spend using spendPriv + hash(sharedSecret).

Every payment to a Marmo wallet lands at a unique, unlinkable one-time address. An observer cannot link multiple payments to the same recipient.

5. Security Model

5.1 Threat Analysis

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 on outbound transactions. Outbound privacy requires privacy pools (see Roadmap).
• Marmo does not protect against network-level surveillance (IP address correlation). A VPN or Tor is recommended for high threat models.
• The smart contract has not yet been formally audited. An audit is scheduled for Q3 2026.

6. Privacy Model

A standard on-chain multisig 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:

• Invisible signing structure — transactions look like standard ERC-4337 user operations. The 2-of-3 nature is in the contract bytecode, not in transaction calldata.
• Unlinkable receive addresses — stealth addresses mean no two inbound payments share a visible on-chain connection to the same wallet.
• Blind co-signing — the co-signer sees only the UserOp hash, not the decoded transaction content.

Outbound privacy is planned via integration with screened privacy pools — smart contracts that accept deposits and issue zero-knowledge proofs of compliance, allowing withdrawals to clean addresses without mixing with sanctioned funds.

7. Comparison to Existing Solutions

7.1 vs. MetaMask

MetaMask 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 2023 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 targets teams and DAOs, not individuals. Its on-chain structure reveals the full signer set publicly. It has no built-in privacy layer or stealth address support. Marmo delivers Safe-grade security in a consumer product with default privacy.

7.4 vs. MPC Wallets

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 depend on key recovery protocols that vary by provider. Marmo's co-signer is open-source and self-hostable. The on-chain enforcement means the contract itself is the source of truth.

7.5 vs. Privacy Mixers

Tornado Cash and Railgun break transaction linkability by pooling funds. These protocols are effective but have become heavily scrutinised by regulators, and using them signals privacy-seeking behaviour. Marmo's approach is proactive: 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 under the MIT licence:

• 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
• ECDSA and secp256k1 — FIPS 186-5, NIST