MaryJaneCoin

1. Introduction

1.1 The Problem

Existing privacy coins face a liquidity problem. Monero, Zcash, and similar projects trade on centralized exchanges that increasingly delist privacy tokens under regulatory pressure. Decentralized exchange liquidity on Ethereum or Solana is limited because privacy features exist only on the native chain — the wrapped tokens on DEXes carry none of the privacy guarantees.

Meanwhile, Solana's pump.fun has become the dominant launchpad for new tokens, providing instant liquidity, community formation, and price discovery. But pump.fun tokens are fully transparent SPL tokens with zero privacy.

1.2 The Solution

MaryJaneCoin bridges these two worlds:

1. Launch on pump.fun — instant Solana DEX liquidity, meme-driven community building, standard SPL token trading
2. Bridge to mainchain — holders bridge their SPL tokens 1:1 to the native MARYJ chain where mandatory stealth addresses, ring mixing, and pool separation provide real, consensus-enforced privacy
3. Bridge back — when users want to trade, they bridge back to Solana for DEX liquidity

The privacy chain doesn't need exchange listings. Solana IS the exchange. The bridge IS the on-ramp.

1.3 Design Philosophy

• Privacy by default, not by choice. After activation heights, all transactions must use stealth addresses and ring mixing. There is no "transparent mode" for spending.
• Transparent staking, private spending. Proof-of-Stake requires publicly verifiable stake weights. MaryJaneCoin solves the PoS-privacy conflict by separating the UTXO set into transparent (staking) and shielded (spending) pools.
• Zero inflation. The entire supply exists at genesis. No block rewards, no inflation, no dilution. The chain runs on transaction fees alone.
• Layered activation. Privacy features activate progressively at fixed block heights, giving the network time to stabilize between each enforcement layer.

3. Economic Model

3.1 Zero-Inflation Design

MaryJaneCoin deliberately breaks from the standard cryptocurrency model of ongoing issuance. Block 1 mints the entire 1 billion MARYJ supply. All subsequent blocks — whether Proof-of-Work or Proof-of-Stake — generate zero new coins:

// main.cpp:1131 — PoW reward
int64_t GetProofOfWorkReward(int64_t nFees, int nHeight)
{
    int64_t nSubsidy = 0;
    if (nHeight == 1)
        nSubsidy = 1000000000 * COIN;  // Entire supply at block 1
    return nSubsidy + nFees;
}

// main.cpp:1148 — PoS reward
int64_t GetProofOfStakeReward(...)
{
    int64_t nSubsidy = 0;  // Zero inflation forever
    return nSubsidy + nFees;
}

Staking nodes are incentivized by transaction fees (minimum 0.420 MARYJ per transaction). As chain usage grows, fee revenue grows proportionally. There is mild deflationary pressure as fees are collected from the circulating supply.

3.2 The Pump.fun Bridge Model

The economic architecture is designed around the Solana bridge:

1. A 1 billion MARYJ SPL token launches on pump.fun (Solana)
2. The mainchain premines exactly 1 billion MARYJ at block 1
3. The entire premine sits in a bridge escrow wallet
4. The bridge provides 1:1 atomic swaps between SPL and native MARYJ
5. Users buy MARYJ on Solana DEXes and bridge to mainchain for privacy
6. Users bridge back to Solana for trading

The escrow wallet stakes its holdings to produce blocks and secure the network, but earns zero rewards — it simply keeps the chain alive. As users bridge coins to the mainchain, the escrow balance decreases and user balances increase, distributing both the supply and the staking power.

3.3 UTXO Escrow Architecture

The bridge escrow distributes the 1 billion premine into graduated UTXO tiers for efficient order filling:

This allows the bridge to fill orders of any size using best-fit UTXO selection without excessive transaction splitting.

4.1 Phase 0: Dandelion++ Transaction Relay (Active from Genesis)

Purpose

Prevent network observers from determining which node originated a transaction.

Problem

In standard Bitcoin-style relay, a node broadcasts new transactions to all peers simultaneously. A well-connected observer can use timing analysis to identify the originating IP address with high accuracy.

Solution

Dandelion++ (BIP 156) introduces a two-phase relay:

1. Stem Phase: The transaction is forwarded along a random single-path "stem" — each node selects 2 stem peers per 10-minute epoch and forwards stem transactions to exactly one of them.
2. Fluff Phase: At each hop, there is a 10% probability of transitioning to "fluff" — normal broadcast to all peers. After 10 hops or 30 seconds (whichever comes first), fluff is forced.

Result

An observer sees the transaction "appear" from a random node in the stem, not the originator. Combined with Tor proxy support (configurable via proxy=127.0.0.1:9050), the originating IP is fully hidden.

4.3 Phase 2: Mandatory Ring Mixing (Block 1,500)

Purpose

Prevent amount-based transaction graph analysis.

Problem

Even with stealth addresses hiding the recipient, an observer can trace payments by matching amounts. "Someone sent exactly 420 MARYJ, and this stealth output received exactly 420 MARYJ — probably the same transaction."

Solution

Every spending transaction must contain at least 3 outputs of equal denomination. The wallet automatically creates a self-mix (CoinJoin churn) that splits payments into equal-value outputs sent to multiple fresh addresses. Only one output is the real payment — the others return to the sender's wallet.

Denominations

The wallet selects the largest denomination that produces at least 3 equal outputs from the payment amount.

Consensus Enforcement (after block 1,500)

Every spending transaction (excluding coinbase, coinstake, and peg-out) must contain at least RING_MIXING_MIN_EQUAL_OUTPUTS = 3 outputs of the same value (excluding zero-value OP_RETURN markers). Blocks violating this are rejected with DoS(100).

// Count outputs by denomination (excluding OP_RETURN)
std::map<int64_t, int> mapOutputCounts;
for (const CTxOut& out : tx.vout) {
    if (out.nValue > 0)
        mapOutputCounts[out.nValue]++;
}
int nMaxEqual = max_element(mapOutputCounts)->second;
if (nMaxEqual < RING_MIXING_MIN_EQUAL_OUTPUTS)
    return DoS(100, error("Ring mixing violation"));

RPC Commands

# Mix a specific amount into equal-denomination outputs
$ MaryJaneCoind coinjoin 5000
{
    "txid": "abc123...",
    "inputs": 2,
    "outputs": 5,
    "denomination": 1000.00000000,
    "total_mixed": 5000.00000000,
    "fee": 0.42000000
}

# Auto-mix the optimal amount from wallet balance
$ MaryJaneCoind coinjoinauto
{
    "txid": "def456...",
    "inputs": 1,
    "outputs": 20,
    "denomination": 1000.00000000,
    "total_mixed": 20000.00000000,
    "fee": 0.42000000
}

# Check available denominations and capacity
$ MaryJaneCoind coinjoininfo
{
    "balance": 802343759.84,
    "min_outputs": 3,
    "max_outputs": 20,
    "denominations": [
        {"amount": 1000.00, "outputs": 20, "usable": true},
        {"amount": 100.00,  "outputs": 20, "usable": true},
        {"amount": 10.00,   "outputs": 20, "usable": true},
        {"amount": 1.00,    "outputs": 20, "usable": true}
    ]
}

On-Chain Transaction Structure (after ring mixing)

An observer sees three outputs of exactly 1,000 MARYJ going to three different one-time stealth addresses. They cannot determine which is the real payment and which are self-churn. Combined with stealth addresses, both the recipient identity AND the payment amount are obscured.

5. Network Privacy: Tor Integration

All staking nodes support routing P2P traffic through the Tor anonymity network via the inherited Bitcoin -proxy= flag:

proxy=127.0.0.1:9050
onlynet=ipv4

With Tor enabled, the node's real IP address is hidden from all peers. Combined with Dandelion++ relay, an observer cannot determine:

1. Which IP originated a transaction (Tor hides the node)
2. Which node broadcast it first (Dandelion++ randomizes the relay path)

The seed nodes remain non-Tor for discoverability, but all staking nodes (which hold funds) operate behind Tor.

7. Proof-of-Stake Consensus

7.1 Stake Kernel

MaryJaneCoin uses a HyperStake-derived PoS kernel. The stake hash is computed as:

hash = SHA256d(nStakeModifier + blockFrom.nTime + txPrev.offset +
               txPrev.nTime + txPrev.vout.n + nTimeTx)

The hash must satisfy:

hash < bnTargetPerCoinDay × nCoinDayWeight

Where nCoinDayWeight = nValueIn × nTimeWeight / COIN / 86400 — a function of the UTXO's value and age. Larger and older UTXOs have proportionally better chances of finding a valid stake.

7.2 Zero-Reward Staking

MaryJaneCoin's 0% inflation model required a modification to the standard staking code. The original codebase rejected stake blocks with zero rewards:

// Original (broken for zero-inflation chains):
if (nReward <= 0) return false;

// Fixed:
if (nReward < 0) return false;

This allows the chain to produce valid Proof-of-Stake blocks even when there are no pending transaction fees, ensuring the network never stalls due to an empty mempool.

7.3 Staking Parameters

8.1 BIP47 Reusable Payment Codes (Active from Genesis)

Purpose

Enable ongoing private payment relationships without repeated address exchange.

Problem

Standard stealth addresses require the sender to know the recipient's stealth address for each payment. If Alice wants to receive regular payments from Bob, she must share her stealth address through a secure channel. BIP47 solves this with a one-time notification transaction that establishes a permanent shared secret.

How It Works

1. Alice generates a reusable payment code — a single string she can publish publicly:

$ MaryJaneCoind getpaymentcode
{
    "payment_code": "PM8TJJvP5XPvcn4oy75XBydTpZrZxtKSYBqRtj7WuVywEYaWJmWcnpPyCi2AZVhbtZudqu4Go2fGQeFdeyRFtqtwkjRkmFPPWFDkLYvtpGPBeipi8nG4",
    "notification_address": "MPNLrBVBYYWKpSNdKJ3ABipZEUC8aDvsYZ",
    "scan_pubkey": "0209683bcb222d6f8f8d0c9d13432a...",
    "spend_pubkey": "0328c613cd05ba604e049acfc5cdf1..."
}

2. Bob sends a notification transaction to Alice's notification address. This one-time TX carries Bob's payment code (blinded with an ECDH shared secret) in an OP_RETURN output:

$ MaryJaneCoind sendtonotify "PM8TJJvP5XPvcn4oy75XBydTpZrZxtKSYBqRtj7WuVywEYaWJmWcnpPyCi2AZVhbtZudqu4Go2fGQeFdeyRFtqtwkjRkmFPPWFDkLYvtpGPBeipi8nG4"
{
    "txid": "abc123...",
    "notification_address": "MPNLrBVBYYWKpSNdKJ3ABipZEUC8aDvsYZ",
    "status": "notification_sent"
}

3. Alice scans the blockchain for notification TXs sent to her notification address:

$ MaryJaneCoind scannotifications
2  # Found 2 inbound payment code notifications

4. Now Bob can generate unlimited unique stealth addresses for Alice using the shared secret, without any further interaction:

$ MaryJaneCoind deriveaddress "PM8TJJvP5XP..." 0
{"index": 0, "address": "MQx7k9f...", "pubkey": "02a1b2c3..."}

$ MaryJaneCoind deriveaddress "PM8TJJvP5XP..." 1
{"index": 1, "address": "MRy8l0g...", "pubkey": "03d4e5f6..."}

5. List all payment channel relationships:

$ MaryJaneCoind listpaymentcodes
[
    {
        "payment_code": "PM8TJKx...",
        "label": "Bob",
        "notification_sent": true,
        "notification_received": true,
        "next_send_index": 3,
        "next_recv_index": 1
    }
]

Notification Blinding Protocol

The notification TX must not reveal Alice's payment code to observers. The 80-byte payment code payload is XOR-blinded with a mask derived from ECDH(sender_scan_privkey, receiver_scan_pubkey). Only Alice can unblind it using her scan private key. The blinded payload is carried in an OP_RETURN output.

Key Properties

• Alice publishes her payment code once (on a website, social media, or QR code)
• Anyone can establish a channel with a single notification TX
• After notification, unlimited stealth payments flow without interaction
• Each payment goes to a unique one-time address (same DKSAP as Phase 1 stealth)
• The notification TX itself reveals only the notification address, not the payment code relationship

10. Future Development

10.1 Confidential Transactions (Phase 3)

Infrastructure stubs exist for Pedersen commitments and Bulletproof range proofs. When libsecp256k1-zkp is integrated, transaction amounts will be cryptographically hidden while still provably valid (inputs = outputs). This is the primary remaining privacy gap — currently amounts are visible even though recipients and payment graphs are obscured.

10.2 MWEB Extension Blocks

The long-term vision is Mimblewimble Extension Blocks (MWEB), as shipped by Litecoin in 2022. MWEB provides a parallel chain where all data — amounts, addresses, and transaction graph — is hidden. Coins move between the main chain and MWEB via peg-in/peg-out transactions.

10.3 PayJoin

When two parties are both sending transactions, they combine inputs into a single transaction. An observer cannot determine who paid whom, breaking the "common input ownership" heuristic used by chain analysis firms.