Skip to main content
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.

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

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

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

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

​
See also

Signing guides (same order as the sidebar) Related product docs
  • Morpheum x402 — HTTP-native payments and signing in payment headers
  • MCP — tooling surfaces that may trigger signed actions
  • Agent wallet — wallet patterns for agents