> ## Documentation Index
> Fetch the complete documentation index at: https://docs.morpheum.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Morpheum signatures

> Conceptual guide to Morpheum’s hybrid classical + post-quantum signatures, addresses, verification, and how they fit identity and delegation

## Overview

Morpheum defines a **hybrid signature** built for two goals at once: **stay compatible with today’s Ethereum-style ecosystem**, and **add a post-quantum layer** so identities and authorizations remain meaningful as cryptography evolves.

This page explains **how to read the idea**—what the two halves do, how they combine, and what verifiers check. Exact wire layouts and deployment details change over time; treat this as the **conceptual map**, not a byte-level specification.

***

## What is the hybrid?

**ECDSA\_MLDSA44** is not one exotic math object. It is **two ordinary signatures**, both computed over the **same logical content** (the same fixed-size digest of what you intend to sign), then carried together as **one hybrid artifact**.

```mermaid theme={null}
flowchart TB
  subgraph inputs [What you start from]
    I[Intent: what is being authorized]
    I --> D[Single message digest — a fixed fingerprint of that intent]
  end

  subgraph classical [Classical half]
    D --> E[ECDSA on secp256k1]
    E --> C[Signature suited to Ethereum-style tooling and recovery]
  end

  subgraph pq [Post-quantum half]
    D --> M[ML-DSA-44 — NIST FIPS 204 family]
    M --> Q[Signature aimed at long-term resistance to quantum attacks on discrete log]
  end

  C --> H[Hybrid artifact]
  Q --> H
```

The classical piece is **small and familiar** to existing wallets and verifiers. The ML-DSA piece is **much larger**—that tradeoff is deliberate: you keep interoperability while adding a second, independent check rooted in **lattice assumptions** instead of elliptic-curve discrete log.

```mermaid theme={null}
flowchart LR
  subgraph compare [Two checks, one decision]
    direction TB
    A[Verifier recomputes the same digest]
    A --> B{Does the classical signature match?}
    A --> C{Does the post-quantum signature match?}
    B --> D{Both yes?}
    C --> D
    D -->|yes| OK[Hybrid accepted]
    D -->|no| NO[Rejected]
  end
```

This is **not** a fused or aggregated signature like some multi-party schemes. Each algorithm could be described on its own; the hybrid simply **requires both to succeed**.

***

## Why combine classical and post-quantum?

```mermaid theme={null}
mindmap
  root((Hybrid purpose))
    Today
      Existing wallets and patterns
      Familiar recovery and compatibility
    Tomorrow
      Mitigate quantum risk against ECDLP-based schemes
      Independent second factor at the signature level
    Ecosystem
      Morpheum-native identity slot alongside other chain families
      Delegation rules that respect which “family” a key belongs to
```

**Ethereum-oriented compatibility** — The ECDSA half lets familiar workflows (including recovery-style reasoning where applicable) remain part of the story.

**Quantum awareness** — Shor-class attacks threaten discrete-log cryptography; ML-DSA adds a **separate** security story based on structured lattices, standardized as **ML-DSA** under **NIST FIPS 204**.

**Identity and delegation context** — In Morpheum’s world, **only certain signature families** are treated as valid for particular on-chain or policy checks. Morpheum’s native scheme occupies its own lane alongside other recognized families—so **you cannot substitute** one family’s delegation for another’s when the rules say “this lane only.”

***

## Morpheum addresses

A Morpheum address is a **short, human-readable string** (Bech32m-style) that encodes a commitment derived from **both** public keys: the **compressed** classical key material and a **hash** of the post-quantum public material. Prefixes such as **`mr4m`** (with witness-style segments like **`mr4m1…`**) identify this family at a glance.

Conceptually:

```mermaid theme={null}
flowchart LR
  PKec[Classical public key — compact form]
  PKpq[Post-quantum public key — larger fixed layout]
  PKpq --> H[Hash of post-quantum key]
  PKec --> C[Commitment mixing both]
  H --> C
  C --> Addr[Bech32m Morpheum address]
```

Length varies with encoding, but the **idea** is: one address **binds** the two keys that the hybrid signature will later prove control of.

***

## How signing works (conceptually)

The signer holds **two private keys**—one for secp256k1, one for ML-DSA-44. For a given authorization:

1. The **intent** is reduced to **one digest** (for many apps this is the hash of a **typed structured message** in the Ethereum sense—same conceptual role as “what is uniquely being signed”).
2. That **same digest** is fed to **both** signing processes.
3. The **hybrid output** carries the classical signature, the post-quantum signature, and is accompanied by **both public keys** so anyone can verify without guessing keys.

```mermaid theme={null}
sequenceDiagram
  participant Intent as Intent to authorize
  participant Digest as Single digest of that intent
  participant Classical as Classical signer
  participant PQ as Post-quantum signer
  participant Bundle as What you publish

  Intent ->> Digest: Agree what is being signed
  Digest ->> Classical: Sign digest
  Digest ->> PQ: Sign same digest
  Classical ->> Bundle: Classical signature
  PQ ->> Bundle: ML-DSA signature
  Note over Bundle: Together with both public keys — verifiers run two checks
```

Policy, gateways, and human-in-the-loop rules still decide **whether** signing is allowed—cryptography only proves **who agreed** to the digest, not whether the action was wise or permitted by policy.

***

## How verification works (conceptually)

A verifier **never** treats the hybrid as a single opaque magic string. They:

1. **Obtain both public keys** from the published material.
2. **Recompute the digest** using the **same rules** the signer used (same intent, same domain, same serialization of the message).
3. **Check the classical signature** against the digest and the classical public key.
4. **Check the ML-DSA signature** against the digest and the post-quantum public key.
5. **Accept only if both succeed**—then apply **policy**: owner vs agent, chain family, delegation scope, and so on.

```mermaid theme={null}
flowchart TD
  Start[Published: hybrid + both public keys + context]
  Start --> R[Recompute digest from the same intent rules]
  R --> V1{Classical part valid?}
  R --> V2{Post-quantum part valid?}
  V1 -->|no| Fail[Invalid]
  V2 -->|no| Fail
  V1 -->|yes| Both{Both valid?}
  V2 -->|yes| Both
  Both -->|no| Fail
  Both -->|yes| Policy[Policy: delegation, chain type, scope]
  Policy --> Out[Accept or reject for this use case]
```

Delegation logic is **orthogonal** to the math: even a valid hybrid must still match **who may act** and **for which chain family** the approval was granted.

```mermaid theme={null}
flowchart LR
  subgraph lanes [Typical lanes for certain delegated-key checks]
    L1[Ethereum-family expectations]
    L2[BLS-family expectations]
    L3[Morpheum native — this hybrid]
  end
  Other[Other families] -.->|wrong lane| Blocked[Not interchangeable here]
```

***

## ML-DSA-44 in one glance

**ML-DSA** (Module Lattice Digital Signature Algorithm) is the name standardized in **[NIST FIPS 204](https://csrc.nist.gov/publications/detail/fips/204/final)** for what grew out of **CRYSTALS-Dilithium**. **ML-DSA-44** is the **smaller, faster** approved parameter set—often discussed as the successor to older “Dilithium2”-scale profiles in pre-standard writing.

| Idea                    | Plain language                                                                                                                             |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **What it rests on**    | Hard problems on **module lattices**, not ECDLP.                                                                                           |
| **Rough strength band** | **NIST Level 2** category for this parameter set—see FIPS 204 for precise statements.                                                      |
| **Why it is bulky**     | Keys and signatures are **much larger** than ECDSA; the hybrid keeps the small classical surface while adding PQ assurance.                |
| **In this hybrid**      | Same digest as the classical half; **two** verification outcomes must both be true—there is still **no** single merged signature equation. |

For **why** lattice-based signatures matter beside ECDSA in Web3 timelines, see [Quantum threat to signatures](/signing/quantum-threat).

***

## Where this mental model lands in the stack

```mermaid theme={null}
flowchart TB
  subgraph L1 [Message and digest layer]
    M[What exactly is being signed — domain, types, intent]
  end

  subgraph L2 [Cryptographic proof layer]
    H[Hybrid: classical + ML-DSA on one digest]
  end

  subgraph L3 [Rules and orchestration]
    P[Delegation, chain family, policy, gateways, agents]
  end

  M --> H
  H --> P
```

A signature can be **cryptographically valid** yet **correctly rejected** if the **network**, **domain**, or **policy** does not match—**fail closed** is the right mental default.

***

## Related reading

* [Signing overview](/signing) — how Morpheum sits beside EVM, Solana, and Bitcoin
* [Ethereum (EVM) signatures](/signing/ethereum-signature) — typed messages and the classical half
* [Quantum threat to signatures](/signing/quantum-threat) — PQC context
* [Morpheum x402](/x402) — HTTP-native flows where scheme and network still matter
* [Agent wallet](/agent-wallet) and [MWVM](/mwvm) — custody and execution context

***

## See also

* [MCP](/mcp) — surfaces that may trigger paid or signed actions