How wallet-native signing works in DeFi derivatives

What wallet-native signing actually means

On a centralized exchange, your account is a row in a database. You authenticate with an email and password. The exchange holds your funds in a pooled omnibus wallet. When you place an order, you're sending an HTTP request to their server and trusting them to honor it, settle it correctly, and not freeze your withdrawal.

Wallet-native signing is structurally different. Your Ethereum wallet holds a private key. That key signs a cryptographic message authorizing a specific action. The signature proves you approved exactly what was signed — nothing more, nothing less. No one can forge it without your key.

In DeFi derivatives, this means your orders are authorized by your private key before they reach any matching engine. The protocol receives a signed message, verifies the signature, and processes the order. It doesn't need to trust your identity. The math handles that.

That's the core distinction between a CEX login and a wallet-native workflow. One relies on the exchange's authentication layer. The other relies on cryptographic proof.

EIP-712: the standard behind readable signing prompts

Early Ethereum wallets asked users to sign raw hexadecimal data. You'd see a string like 0x3d602d80600a3d3981f3... and be expected to approve it. Almost no one could verify what they were actually authorizing. This was the blind signing problem.

EIP-712 was introduced to fix it. The standard defines a format for typed structured data signing, so wallets can display a human-readable breakdown of exactly what a signature authorizes.

Typed structured data

EIP-712 requires every signable message to conform to a defined schema. The schema specifies field names, types, and values. An order might define fields like asset, isBuy, limitPx, sz, reduceOnly, and nonce. When you sign, your wallet reads the schema and renders each field with its label and value.

The signing prompt is not a blob of hex. It's a structured form that mirrors what you actually approved.

Domain separation

EIP-712 includes a domain separator — a hash encoding the application name, version, and chain ID. This prevents a signature created for one protocol from being replayed on a different protocol or network. A signature you generate for Hyperliquid on mainnet cannot be submitted elsewhere or replayed on testnet.

Without domain separation, a malicious site could capture a valid signature and submit it somewhere you never intended. The domain separator closes that window.

Human-readable prompts

Because the schema is defined and the domain is explicit, a compliant wallet like MetaMask or Rabby renders the signing request as a readable breakdown. You see the protocol name, each field, and its value. You can verify the asset, direction, price, and size before you sign.

This is what makes wallet-native signing auditable at the point of execution. You're not trusting a UI to describe what you're doing. You're reading the actual payload your key will authorize.

How Hyperliquid uses EIP-712 for order signing

Hyperliquid's order book runs on its own L1, but the authorization layer uses EIP-712. When you place an order, the parameters are encoded as a typed structured data payload and presented to your wallet for signing. Your wallet signs the payload. The signed message goes to Hyperliquid's matching engine, which verifies the signature before processing the order.

Hyperliquid never needs your private key. It receives a signed message and verifies it against your public address. Valid signature, correct nonce — the order is accepted.

Nonces and replay attack prevention

Hyperliquid uses nonces to prevent replay attacks. A nonce is a number that can only be used once per address. Each signed order includes one. Once that nonce is consumed by a successful submission, the same signed message cannot be resubmitted.

Without nonces, an attacker who captured a valid signed order could resubmit it later — potentially re-executing a trade you already completed or cancelled. Nonces close that window. The Hyperliquid documentation covers the nonce mechanics in detail for anyone building on the protocol directly.

API wallets and agent addresses

Hyperliquid supports API wallets, sometimes called agent wallets — separate Ethereum addresses you authorize to sign orders on behalf of your main wallet. The authorization is itself a signed EIP-712 message from your main wallet, granting the agent address specific permissions.

This matters for automation. Instead of exposing your main wallet's private key to a bot or strategy layer, you generate a separate key pair, authorize it as an agent, and let the automation sign with that key. Your main key stays offline.

Agent wallets have scoped permissions. They can place and cancel orders. They cannot withdraw funds to arbitrary addresses. That separation between signing authority and withdrawal authority is a meaningful risk boundary.

What the signing prompt actually shows you before a trade executes

When you submit an order through a wallet-native interface built on Hyperliquid, your wallet surfaces a signing request before anything executes. The exact rendering depends on your wallet software, but a compliant EIP-712 implementation will show you something structured like this:

• Protocol/domain: the application name and chain context
• Asset: the market you're trading — ETH, BTC, and so on
• Direction: buy or sell
• Limit price: the price boundary for the order
• Size: the position size in the base asset
• Reduce only: whether the order can only reduce an existing position
• Nonce: the sequence number for replay protection

You review these fields before you sign. If the price or size doesn't match what you entered in the UI, you reject the signature. Nothing executes until you approve.

That's the core security property here. The approval step is explicit and readable. There's no background call submitting an order without your knowledge. The signing prompt is the gate.

Delegated signing: what it is and when to use it

Requiring a manual wallet approval for every order is practical for discretionary trading. For automated strategies, it's a bottleneck. A strategy that needs to respond to market conditions in milliseconds can't wait for a MetaMask popup.

Delegated signing solves this. You generate a separate key pair, authorize that address as an agent on Hyperliquid by signing a delegation message from your main wallet, and let your automation layer sign orders with the agent key. The agent key can live in memory or a secure enclave, accessible to your automation without exposing your main key.

The delegation itself is a one-time EIP-712 signed message from your main wallet. It specifies which address you're authorizing and what it can do. Hyperliquid's matching engine then recognizes that agent address as authorized to act on your behalf.

A few things worth understanding about agent wallets:

• The agent can place and cancel orders. It cannot initiate withdrawals to external addresses.
• If the agent key is compromised, an attacker can trade your account but cannot drain your collateral to an arbitrary wallet without your main key.
• You can revoke agent authorization at any time with another signed message from your main wallet.

This architecture lets you separate hot signing keys from cold custody keys. Your main wallet — which controls withdrawals — stays offline. Your agent wallet — which controls order flow — runs in your automation stack.

How Stacked Markets surfaces the signing mechanic

Stacked Markets is a non-custodial trading terminal built on top of Hyperliquid's on-chain CLOB. It holds none of your collateral, pools nothing, and routes your orders through Hyperliquid's matching engine. Every order requires an explicit wallet approval before it executes.

The interface is built around the signing workflow, not bolted onto it. When you submit an order, a plain-language signing prompt surfaces before execution. That prompt reflects the actual EIP-712 payload your wallet will sign — asset, direction, price, size. You approve or reject. Nothing moves without your signature.

Orders route as IOC-style slippage-bounded limit orders, not fake market orders. The price boundary in the signing prompt is the actual limit on your execution. You're not signing a market order that can fill at any price. You're signing a limit with an explicit price floor or ceiling, and Hyperliquid's CLOB handles the matching.

The terminal also supports delegated signing for traders running automated workflows. You link a signer address to your main wallet, and the terminal signs orders on your behalf without requiring a manual approval for each trade. The delegation follows the same EIP-712 pattern described above. Your main wallet authorizes the signer. The signer handles order flow. Withdrawals stay gated by your main key.

Stacked Markets holds nothing at any point. Hyperliquid handles matching, margin, and settlement. Your PnL and funding are verifiable on-chain.

Automation and copy-trading features are planned but not yet live. The testnet is available at testnet.stackedmarkets.com for traders who want to work through the signing workflow before mainnet.

Honest risks you should understand

Wallet-native signing is more secure than handing custody to an exchange. It is not risk-free.

Blind signing risk. Not every interface implements EIP-712 correctly. Some will present a raw hash and ask you to sign it. If you can't read what you're signing, you're trusting the interface completely. Before approving anything, confirm your wallet is rendering structured fields — not a raw hex string. If you see only a hash, reject it.

Key loss. Your private key is the only credential that matters. Lose it without a backup and your funds are gone. No support team can recover them. Seed phrase storage and key management are entirely your responsibility.

Phishing and domain spoofing. A malicious site can mimic a legitimate interface and present a signing prompt that looks correct but encodes different parameters. Always verify the domain in your browser before connecting your wallet. Check that the domain separator in the signing prompt matches the protocol you intend to use.

Agent key compromise. If you use delegated signing and your agent key is exposed, an attacker can trade your account. They can't withdraw to an arbitrary address, but they can open and close positions and generate real losses. Keep agent keys in secure environments and rotate them if you suspect exposure.

Smart contract and protocol risk. Hyperliquid's L1 and matching engine carry their own risk profile. Protocol bugs, oracle failures, and liquidation mechanics can all affect your positions in ways unrelated to your signing setup. On-chain settlement means your PnL is verifiable — but it also means losses are final.

UI data freshness. Signing a prompt that reflects stale data is a real execution risk. If the price shown in the UI is stale, the limit in your signed order may not reflect current market conditions. Stacked Markets surfaces freshness and connection-state indicators to flag this, but you should always verify the data you're acting on is current before signing.

FAQs

What is wallet-native signing in DeFi derivatives?
Your private key signs a cryptographic message that authorizes each trade. The protocol verifies the signature before processing any order. You never hand custody of your funds to the exchange, and nothing executes without an explicit approval from your key.

What is EIP-712 and why does it matter for traders?
EIP-712 is an Ethereum standard for typed structured data signing. It lets wallets display a human-readable breakdown of what a signature authorizes — asset, direction, price, size — instead of a raw hex string. The approval step becomes something you can actually verify before confirming.

How does Hyperliquid prevent replay attacks on signed orders?
Through nonces. Each signed order includes a nonce that can only be consumed once per address. Once a signed message is processed, the same message cannot be resubmitted. An attacker who captures a valid signed order can't replay it.

What is a delegated signer or API wallet, and when should I use one?
A delegated signer is a separate Ethereum address you authorize to sign orders on behalf of your main wallet. It's useful when running automated strategies that need to sign orders without a manual approval for each trade. The agent can place and cancel orders but cannot initiate withdrawals to external addresses. Your main key, which controls withdrawals, stays offline.

Can a malicious site steal my funds if I sign a phishing prompt?
A phishing site can present a signing prompt that encodes different parameters than what it displays. If you sign it, you authorize whatever the payload actually says. Verify the domain before connecting your wallet, confirm your wallet is rendering structured EIP-712 fields rather than a raw hash, and reject any prompt you can't fully read.

What does Stacked Markets hold when I trade through it?
Nothing. Stacked Markets is a non-custodial terminal. Your collateral stays in your wallet. Orders route through Hyperliquid's on-chain CLOB, and Hyperliquid handles matching, margin, and settlement. Stacked Markets has no access to your funds at any point.

Is wallet-native signing slower than CEX order entry?
For manual trading, the signing step adds a few seconds per order. With delegated signing, your agent key signs orders programmatically without a manual approval popup, which removes that latency for automated workflows. For discretionary trading, the added step is the explicit price you pay for verifiable authorization.

Conclusion

Wallet-native signing is not a UX feature. It's the mechanism that puts authorization back in your hands. EIP-712 makes that authorization readable. Nonces make it non-replayable. Agent wallets make it compatible with automation without exposing your main key.

Understanding how the signing layer works means you can audit what you approve, recognize when something looks wrong, and structure your key setup to match your actual risk tolerance.

If you want to work through this mechanic in a live environment before committing real capital, the testnet is at testnet.stackedmarkets.com.