{"id":1233,"date":"2025-12-10T12:45:34","date_gmt":"2025-12-10T10:45:34","guid":{"rendered":"https:\/\/ackee.xyz\/blog\/?p=1233"},"modified":"2026-01-05T14:26:27","modified_gmt":"2026-01-05T12:26:27","slug":"signing-data-in-wake-raw-structured-and-hash-flows","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/signing-data-in-wake-raw-structured-and-hash-flows\/","title":{"rendered":"Signing Data in Wake: Raw, Structured, and Hash Flows"},"content":{"rendered":"

Why Signing Matters in Tests<\/h2>\n

Typed signatures drive permit flows, meta-transactions, and off-chain approvals. Being able to generate them inside tests lets you confirm your verification logic without wiring external wallets. Wake exposes a focused API on Account<\/code> that covers the three common cases: raw message signing (sign<\/code>), EIP-712 structured signing (sign_structured<\/code>), and low-level hash signing (sign_hash<\/code>). This guide distills the official Accounts and addresses<\/a> documentation into practical examples you can drop directly into your tests.<\/p>\n

Preparing an Account With a Private Key<\/h2>\n

Wake signs only when an account holds a private key. You can import or generate one in a single line:<\/p>\n

\nfrom wake.testing import Account\n\naccount = Account.from_mnemonic(" ".join(["test"] * 11 + ["junk"]))\n# Other options:\n# Account.from_key("0x" + "a" * 64)\n# Account.from_alias("alice")  # uses the alias from config\n# Account.new()                # fresh random key\n\n<\/code><\/pre>\n
The account is now ready for transactions and all three signing modes.<\/p>\n
Signing Raw Messages (EIP-191)<\/h2>\n
Use Account.sign<\/code> for human-readable bytes, such as when you need a personal_sign<\/code> style flow in a test:<\/p>\n
from wake.testing import Account\n\naccount = Account.from_mnemonic(" ".join(["test"] * 11 + ["junk"]))\nsignature = account.sign(b"Hello, world!")\n<\/code><\/pre>\n
Wake applies the EIP-191 prefix (version 0x45<\/code>) automatically so the signature matches standard wallet behavior. Use this mode for UX prompts or legacy flows that intentionally avoid typed data.<\/p>\n
Signing Structured Messages (EIP-712)<\/h2>\n
Typed data keeps approvals unambiguous. Wake mirrors the EIP-712 pipeline using dataclasses and an explicit domain:<\/p>\n
from dataclasses import dataclass\nfrom wake.testing import *\n\n\n@dataclass\nclass Transfer:\n    sender: Address\n    recipient: Address\n    amount: uint256\n\n\naccount = Account.from_mnemonic(" ".join(["test"] * 11 + ["junk"]))\nsignature = account.sign_structured(\n    Transfer(\n        sender=account.address,\n        recipient=Address(1),\n        amount=10,\n    ),\n    domain=Eip712Domain(\n        name="Test",\n        chainId=chain.chain_id,\n        verifyingContract=Address(0),  # set to your contract if needed\n    ),\n)\n<\/code><\/pre>\n
Wake builds the type string, hashes each field, and signs the EIP-712 digest. In protocol tests, pair this with a Solidity function such as hashTypedData<\/code> to confirm the contract computes the same digest before verifying the signature.<\/p>\n
Signing a Precomputed Hash<\/h2>\n
Use Account.sign_hash<\/code> only when an external API already gives you the digest. This method skips prefixes and signs the bytes as-is:<\/p>\n
from wake.testing import *\n\naccount = Account.from_mnemonic(" ".join(["test"] * 11 + ["junk"]))\nmessage_hash = keccak256(b"Hello, world!")\nsignature = account.sign_hash(message_hash)\n<\/code><\/pre>\n
Use this when you must match a known hash, such as a contract’s hashTypedData<\/code> output. If you do not control or understand the preimage, do not sign it.<\/p>\n
Hardening Tips for Signature Tests<\/h2>\n
    \n
  • Align domains: ensure name<\/code>, version<\/code>, chainId<\/code>, and verifyingContract<\/code> match exactly between Wake and contract code.<\/li>\n
  • Separate raw and typed flows: use sign<\/code> for prefixed personal messages, sign_structured<\/code> for typed data, and sign_hash<\/code> for deliberate edge cases.<\/li>\n
  • Label test actors: chain.accounts[i].label = "ALICE"<\/code> improves trace readability without affecting behavior.<\/li>\n
  • Capture traces on failure: wrap tests with @on_revert<\/code> and print e.tx.call_trace<\/code> when debugging signature-related reverts.<\/li>\n
  • Assert end-to-end: inside Solidity, recompute the digest and check that ecrecover<\/code> returns account.address<\/code> to catch encoding errors early.<\/li>\n<\/ul>\n
    A Simple Permit-Test Recipe<\/h3>\n
      \n
    1. Define the permit struct as a Wake dataclass mirroring the Solidity struct.<\/li>\n
    2. Build the domain using the contract\u2019s actual name, version, chain ID, and verifying address.<\/li>\n
    3. Generate the signature with sign_structured<\/code> and call the permit or verification function in your test.<\/li>\n
    4. Recompute the digest in Solidity and ensure ecrecover<\/code> yields your signer.<\/li>\n
    5. Add fuzzing for amounts and deadlines to confirm that hashing stays stable across inputs.<\/li>\n<\/ol>\n
      Conclusion<\/h2>\n
      \n
      Wake\u2019s signing helpers put a wallet-like interface inside your tests, so you can exercise permit flows and typed approvals without wiring external tools. Use sign_structured<\/code> for EIP-712 paths, keep sign<\/code> for legacy prompts, and treat sign_hash<\/code> as an intentional edge-case hook. The APIs stay one-liners, letting you focus on asserting contract behavior instead of wrestling with signature plumbing.<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
      Why Signing Matters in Tests Typed signatures drive permit flows, meta-transactions, and off-chain approvals. Being able to generate them inside tests lets you confirm your verification logic without wiring external wallets. Wake exposes a focused API on Account that covers the three common cases: raw message signing (sign), EIP-712 structured signing (sign_structured), and low-level hash signing (sign_hash). This guide distills the official…<\/p>\n","protected":false},"author":24,"featured_media":1102,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[61,10],"tags":[96,24,68,104],"class_list":["post-1233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education","category-ethereum","tag-educational","tag-ethereum","tag-solidity","tag-wake"],"aioseo_notices":[],"featured_image_src":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2025\/07\/Read-Only-Reentrancy-Attack-600x400.png","featured_image_src_square":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2025\/07\/Read-Only-Reentrancy-Attack-600x600.png","author_info":{"display_name":"Naoki Yoshida","author_link":"https:\/\/ackee.xyz\/blog\/author\/naoki-yoshida\/"},"_links":{"self":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/1233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/users\/24"}],"replies":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/comments?post=1233"}],"version-history":[{"count":0,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/1233\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media\/1102"}],"wp:attachment":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media?parent=1233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/categories?post=1233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/tags?post=1233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}