> ## 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. # Signing > Cryptographic signing across EVM, Solana, Bitcoin, Morpheum-native hybrid (ECDSA_MLDSA44), and quantum risk—key management and agent workflows **Signing** is how agents, wallets, and protocols **authorize** actions: transfers, contract calls, API payments, and identity proofs. Different stacks use different curves, encodings, and replay rules. This page ties together **EVM**, **Solana**, **Bitcoin**, **Morpheum-native** signing (including **hybrid** classical plus post-quantum schemes where the stack defines them), and **quantum-related** risks at a conceptual level—enough to orient engineers and operators without replacing chain-specific specs. *** ## EVM signing Ethereum-compatible chains overwhelmingly use **ECDSA on secp256k1**. A private key signs a **32-byte hash**; the canonical user-facing flow often goes through **EIP-191** personal message signing or **EIP-712** typed structured data, so users see structured intent instead of opaque hex. **Practical notes** * **Transactions**: Legacy and typed transactions (EIP-1559, blobs, etc.) serialize fields, hash with the chain’s rules, then sign; **chain ID** is part of replay protection. * **Smart accounts / abstraction**: ERC-4337 and ERC-7710-style flows may delegate execution while still anchoring authorization in signatures or **session keys**—verification semantics differ from EOAs but still reduce to agreed cryptographic checks on-chain. * **Token approvals**: **Permit** (EIP-2612), **Permit2**, and **EIP-3009** “transfer with authorization” patterns move signing off the critical path for some UX and agent flows while preserving spend limits and deadlines. For Morpheum products that touch **stablecoins**, **x402**, or **HTTP-quoted payments**, EVM signing is often the layer that turns a server’s payment quote into an **authorizing signature** verifiable by a facilitator or contract. For a deeper walkthrough of **message hashing (EIP-191, EIP-712)**, **ECDSA on secp256k1**, and **lifecycle** from signed intent to chain effect, see [Ethereum (EVM) signatures](/signing/ethereum-signature). *** ## Solana signing Solana uses **Ed25519** for account keys. **Transactions** are a compact binary format: message (recent blockhash, account keys, instructions) plus **one signature per required signer**. Programs specify which accounts must sign; **partial signing** and **multisig** patterns are first-class in the tooling. **Practical notes** * **Message construction** matters: byte order, account ordering, and instruction data must match what verifiers expect—SDKs assemble this; agents should use audited libraries rather than hand-rolling bytes. * **Fee payers** can be separate from instruction signers (sponsorship), which is relevant for **gasless** or **relayed** agent flows when policy allows. Where Morpheum integrates **Solana** rails (e.g. low-latency settlement), signing is **Ed25519-over-transaction-message**, not secp256k1—wallet and KMS integrations must be chain-aware. For message construction, **fee payer** vs **signer** roles, **Ed25519** over the transaction blob, and **lifecycle** through broadcast and confirmation, see [Solana signatures](/signing/solana-signature). *** ## Bitcoin signing Bitcoin signing is **ECDSA (and in modern wallets often Schnorr for Taproot)** on **secp256k1**, but the object being signed is not “an Ethereum transaction”—it is a **sighash** derived from the specific **input**, **prevout**, **script**, and **sighash type** (e.g. `SIGHASH_ALL`). **SegWit** and **Taproot** change serialization and witness layout; **multisig** and **PSBT** (Partially Signed Bitcoin Transactions) standardize how multiple parties pass around unsigned or partially signed data. **Practical notes** * **UTXO discipline**: Each spend is explicit; agents managing Bitcoin need **UTXO selection** and **fee estimation**, not just a nonce. * **Address types** (legacy, SegWit, Taproot) affect script and verification paths; signing must match the wallet’s policy. For **cross-chain** or **multi-asset** agents, Bitcoin signing is a distinct skill from EVM: same curve in many cases, **different** message formats and lifecycle. For **sighash** construction, **SegWit** and **Taproot** (ECDSA vs BIP340 Schnorr), **PSBT**, and the **UTXO**-centric signing lifecycle, see [Bitcoin signatures](/signing/bitcoin-signature). *** ## Morpheum signing **Morpheum-native** signing refers to how Morpheum’s stack—**agent runtimes**, **gateways**, **wallets**, and **policy**—ties cryptographic authorization to **product flows**: paid APIs (e.g. **x402**), **agent identity**, and **execution** on supported networks. The platform also defines **Morpheum-specific** verification paths, including a **hybrid** **`ECDSA_MLDSA44`** construction that pairs **ECDSA on secp256k1** with **ML-DSA-44** (NIST FIPS 204) for classical compatibility and **post-quantum** resilience—details, address formats, and verification rules live on the dedicated page below. **Conceptual pillars** * **Network-aware**: The same agent may need **EVM**-style signatures for one rail and **Solana**-style for another; configuration and key material should reflect that split. * **Native vs rail**: **Chain-facing** work may use standard **EVM / Solana / Bitcoin** signing; **Morpheum-native** flows may use the hybrid scheme and Morpheum **address** semantics where the product requires it. * **Policy-bound**: Signing should be gated by **allowlists**, **spend caps**, **time bounds**, and **human-in-the-loop** rules where the deployment requires it—not only by “who holds the key.” * **Operational clarity**: Separate **cold / warm / hot** key roles, **audit trails** of what was signed, and integration with **MCP** or **HTTP** surfaces so operators can reason about failures. Exact wire formats and endpoints evolve with releases; treat this section as **architecture**, not a substitute for the latest **API** and **wallet** documentation. For **`ECDSA_MLDSA44`**, Morpheum **addresses**, verification, delegation, and the **layered model** (chain crypto vs orchestration) with **x402** and **agent wallet** ties, see [Morpheum signatures](/signing/morpheum-signature). *** ## Quantum threat **Cryptographically relevant quantum computers**, if realized at scale, would threaten widely deployed **public-key** schemes used in Web3 (**ECDSA**, **Schnorr**, **Ed25519**, **ECDH** on elliptic curves). **Post-quantum cryptography (PQC)**, **hybrid** deployments, and **algorithm agility** are the long-term answer; **signing keys** and **agents** that must stay trustworthy for years need explicit planning. For a structured risk overview, **what to track** (NIST PQC, vendor roadmaps, on-chain governance), and **limits of this documentation**, see [Quantum threat to signatures](/signing/quantum-threat). *** ## See also **Signing guides** (same order as the sidebar) * [Ethereum (EVM) signatures](/signing/ethereum-signature) — EIP-191, EIP-712, transactions, and lifecycle * [Solana signatures](/signing/solana-signature) — Ed25519, transaction messages, fee payer, and confirmation * [Bitcoin signatures](/signing/bitcoin-signature) — sighash, SegWit, Taproot, PSBT, UTXO lifecycle * [Morpheum signatures](/signing/morpheum-signature) — `ECDSA_MLDSA44` hybrid, addresses, and product integration * [Quantum threat to signatures](/signing/quantum-threat) — PQC, Shor/Grover context, and operational tracking **Related product docs** * [Morpheum x402](/x402) — HTTP-native payments and signing in payment headers * [MCP](/mcp) — tooling surfaces that may trigger signed actions * [Agent wallet](/agent-wallet) — wallet patterns for agents