Should wallets refuse blind signing by default?

I self-custody because I want signing authority to remain mine, but too often that means approving opaque calldata and hoping the interface is honest. Wallets should provide a standardized, human-readable preview for every permission or ownership transfer: what action is authorized, which contract or recipient is involved, what assets are affected, how long it lasts, and whether the permission is actually revocable. EIP-712 helps make structured messages readable, but it cannot guarantee the contract’s real intent; ERC-20 allowances, for example, do not inherently expire.

The catch is alert fatigue. A wall of technical warnings trains people to click through, while simulators and centralized metadata services add privacy, availability, and trust dependencies. Unknowns should be labeled plainly rather than disguised as certainty. Would you trust a wallet that refused “blind signing” by default? Concrete interface ideas and counterarguments welcome.

I support refusing blind signing for ordinary users, but not pretending a preview is a security proof. Simulation can miss context, and ABI decoding only tells us what the data resembles. The UI should separate decoded facts, simulated effects, and unknowns with different visual treatment.

The useful design may be progressive disclosure: a one-screen consent summary first, then expandable contract details. “Unlimited,” “no expiry,” and “cannot verify revocation” deserve prominent labels. Dumping every function name into the first screen is how people learn to ignore the whole thing.

There is also a liveness problem. If the wallet depends on a remote simulator, signing becomes partly dependent on that service being reachable and correct. A local fallback could show raw decoded fields, but the fallback must clearly say it is not an intent interpretation.

Small terminology point: “revocable” is not a property wallets can infer from a generic permission label. It depends on the contract and permission type. For ERC-20 approvals, replacing an allowance is not the same as a universal revoke mechanism, and the base standard does not require expiry.

Mandatory friction loses if it makes routine actions feel like airport security. I’d reserve a hard stop for unlimited allowances, unknown contracts, and permissions without a visible end condition. Familiar, low-risk patterns could get a concise confirmation with a details link.

A contract can be upgraded, call another contract, or interpret a signature through proxy logic. So “what this contract can do” needs a boundary: immediate call effects versus capabilities reachable under conditions. The preview should state which layer it actually analyzed.

I would prefer signed, locally cached metadata with an explicit provenance trail. Central registries are convenient, but a wallet should remain useful when the registry disappears or changes its description. Unknown metadata is better than silently substituting a plausible name.

I’m not convinced refusing blind signing by default is always user-protective. Advanced users may knowingly sign formats the wallet cannot decode, and forcing a second device or workflow can push them toward less reputable software. Make the override deliberate, logged, and difficult to trigger accidentally.

Support teams would need a stable vocabulary. “Can revoke” could mean the owner has a direct cancel function, can overwrite an allowance, or must rely on a separate tool. Those are operationally different outcomes and should not share one green checkmark.

An interface proposal: show “You are granting X to Y until Z,” with “Z: none” in plain language. Then show the exact method and chain underneath. That handles the consent question without requiring everyone to understand calldata, while still giving developers something inspectable.

The default should be no unexplained authority, not necessarily no signing. If the wallet cannot establish the recipient, scope, duration, or revocation status, it should say so in large type and make the user consciously choose the opaque path.

Clear-signing proposals are useful directionally, but a draft format is not a universal wallet rule. I’d be wary of treating adoption of a standard as evidence that intent has been verified. The honest label may be the most important part of the interface.