Not everything on a blockchain needs a transaction. Users can also sign a message: approving a token spend, authorising a trade or logging in. The signature is created off-chain, for free, and verified on-chain by a contract or off-chain by your backend. Done well, this makes applications faster, cheaper and gasless for users. Done badly, it is one of the most common ways users lose funds: they sign something they did not understand, or a signature is replayed where it should not be valid.
SemBricks builds signing flows for wallets, dapps and backends. In our USDC-denominated cross-chain trading app, for example, EIP-712 typed signatures are at the core of the trading execution layer.
Signing Solutions We Build
- EIP-712 typed signing: structured, human-readable signature requests instead of opaque hex strings.
- Permit signatures: token approvals with a signature (EIP-2612) instead of a separate transaction.
- Meta-transactions: users sign, a relayer submits and pays gas (ERC-2771).
- Gasless signing flows: complete user journeys without the user ever holding gas, combining signatures with relayers or paymasters.
- Multisig: collecting several signatures for one action, from treasury payments to contract upgrades.
- Blind signing prevention: showing users what they actually sign before they sign it.
Getting Signatures Right
- Replay protection: every signature is bound to a chain ID, a contract (the EIP-712 domain), a nonce and a deadline, so it cannot be reused elsewhere or later.
- Safe verification: using well-tested ECDSA libraries that reject malleable signatures, and supporting EIP-1271 so smart contract wallets can sign too.
- Clear intent: signature requests that wallets can display in plain terms, because users should never approve what they cannot read.
- Revocation: a way to cancel outstanding signatures, for example by increasing a nonce, when something goes wrong.
Frequently Asked Questions about Blockchain Signatures
Is signing a message free?
Yes, creating a signature costs nothing. Gas is only paid when someone submits a transaction that uses the signature, which can be the user, a relayer or a paymaster.
Why are permit signatures used in phishing?
Because one signature can authorise someone to spend your tokens, without any transaction showing up in the wallet first. That is why clear signing and phishing warnings matter, and why we design flows that show exactly what is approved.
Can smart contract wallets sign messages?
Yes, through EIP-1271: the contract wallet confirms on-chain whether a signature is valid for it. Applications must support this explicitly, otherwise users of smart accounts and multisigs are locked out.
Who owns the code?
Ownership of the source code is set out in the contract, and the code can be fully yours, including documentation and tests.
See also crypto wallet development and account abstraction.
Design Your Signing Flow
Tell us what your users need to sign and where it will be verified. We will design a flow that is smooth for users and safe against replay and phishing.
Book a free call about signing flows
Blind Signing Prevention: Clear Signing for Wallets and dApps
What is blind signing and how to prevent it: readable EIP-712 signatures, transaction simulation, approval warnings and clear signing in wallets and dApps.
EIP-712 Typed Data Signing: Explained and Implemented
What is EIP-712? Typed structured data signing explained: domain separator, typed hashes, permits and orders, replay risks, and how we implement it safely.
Meta-Transactions (ERC-2771): Gasless Calls via Relayers
Meta-transactions with ERC-2771: users sign, a relayer submits and pays gas. Trusted forwarders, relayer infrastructure and the security pitfalls to avoid.
Permit Signatures: EIP-2612 and Permit2 Explained
Permit signatures explained and implemented: EIP-2612 token permits and Uniswap's Permit2, gasless approvals in one transaction, token support and pitfalls.