Cowrie Research

signer-intent-truth-security-object

14 min read

Signer Intent Truth as a Single Security Object

  • Name: signer intent truth as a single security object
  • Category: signer-workflow reference / custody-authenticity checklist / transaction-representation design note / multisig-operations safety reference
  • Summary: Healthy signer workflows do not ask humans to trust a browser summary, custody dashboard, or notification rail by convention. They force one security object to stay intact from operator review through policy checks, device display, collected signatures, and onchain execution: the same target, same operation type, same calldata or hash, same value semantics, and same privileged effect description. The recurring review mistake this note tries to stop is flattening three different promotions into one vague the multisig signed it moment: some represented transaction object exists on a review surface, that represented object really is the canonical signer-intent object the devices and signatures are authorizing, and that accepted intent still deserves this much live privileged authority right now. This note exists to keep the positive design target explicit instead of making readers reconstruct what correct signer approval should have meant only by inverting blind-sign incidents like WazirX, Radiant, and Bybit.
  • Why this note exists:
    • Many multisig and custody failures do not begin with keys were stolen; they begin earlier, when humans reviewed one transaction object while signatures actually authorized another.
    • The practical question is usually not did the signatures verify? but what exact machine-readable thing did the signers believe they were approving?
    • The useful design move is to make that answer testable across the whole workflow: UI render, policy evaluation, device confirmation, proposal storage, collected signatures, and final execution should all refer to one stable intent object.
    • This note is adjacent to Execution-envelope identity pinning, but the focus here is higher in the stack: not delayed onchain privileged execution after approval, but the human and operator workflow that produces the approval in the first place.

Three signer-intent promotions healthy custody systems should keep separate

  1. A represented transaction object exists on a review surface

    • A browser, custody dashboard, notification rail, mobile signer client, or proposal record shows operators some transaction-shaped object.
    • This is only the representation question: there is some payload description humans are being asked to review.

  2. That represented object really is the canonical signer-intent object

    • The rendered summary, exact payload hash, target, call primitive, calldata, value semantics, nonce, and any privileged subcall shape all have to stay aligned strongly enough that the review surface, device, proposal store, and signatures are still talking about the same thing.
    • This is the signer-intent question: the thing humans thought they were authorizing is the thing the machinery is actually authorizing.

  3. That accepted intent still deserves this much live privileged authority right now

    • Even a correctly represented intent object should not automatically retain full root-control power forever, across stale proposal queues, durable approvals, degraded review environments, or routine treasury lanes that should never have carried upgrade or ownership semantics in the first place.
    • This is the authority-budget question: why is this authenticated signer-intent object still allowed to do this much damage here and now?

Healthy signer systems keep those promotions distinct instead of collapsing them into enough signers approved it.

The five joints a healthy signer workflow should keep fused

  1. Rendered transaction meaning
    • The signer-facing interface must describe the real transaction object, not a lossy summary or a different benign-looking cousin.
    • A token transfer summary is not enough if the actual payload is a delegatecall, owner change, module install, or implementation rewrite.
    • This is the joint that breaks in blind-sign-payload-substitution.
  2. Exact signing payload
    • The system must know the exact hash, target, operation, calldata, value, and nonce being approved.
    • This proposal is only a safe approval object if the stored proposal and the signed payload are provably the same thing.
  3. Device-visible confirmation
    • Hardware-wallet screens, MPC ceremonies, or signing endpoints need to expose enough of the real transaction envelope that signers can distinguish routine transfers from root-key actions.
    • If the trusted device can only show an opaque hash or a misleading subset, the workflow has already pushed too much authenticity burden back onto the web interface.
  4. Policy, simulation, and coordination layer
    • Whitelists, approval policies, transaction decoding, proposal APIs, and simulation services all belong inside the custody boundary once operators rely on them to decide whether a transaction is safe.
    • A policy engine that validates the UI’s interpretation instead of the exact payload is not a second line of defense; it is the same broken line repeated.
  5. Executed privileged effect
    • The transaction that lands onchain must still be the one the humans and policy stack authenticated.
    • If collected signatures later authorize a different target, different operation type, or a control-plane side effect hidden behind the same surface, signer intent and machine authority have already split apart.

What sound design looks like

  • Signer-intent authority stays staged instead of collapsing into one approval event
    • Healthy systems keep represented object exists, represented object really is canonical signer intent, and that accepted intent still deserves this much live authority as separate promotions with explicit checks and expiry at each step.
    • The fastest way to hide signer-workflow failure is to narrate all three promotions as one the multisig signed it fact.
  • One reviewed object, one signed object, one executed object
    • The safest workflow makes humans, devices, policy engines, and the chain all talk about one machine-verifiable transaction envelope.
    • If the browser describes one effect while the signature service stores another hash, the security object is already broken before anything hits the chain.
  • High-risk semantics should be explicit, not inferred
    • Flows should clearly distinguish plain asset movement from delegatecall, implementation change, owner rotation, module enablement, bridge release, or other root-control actions.
    • Looks like a transfer is not good enough when one flag or one target swap changes the whole blast radius.
  • Policy engines should validate raw transaction truth
    • Whitelists, simulation approvals, and custody policies should bind to exact target, call primitive, selector set, payload hash, and whichever freshness or lane constraints decide whether this signer-intent object should still retain ordinary authority.
    • They should not trust a human-readable rendering that could have been generated from compromised metadata or a compromised front end.
  • Signer devices should be treated as limited but authoritative
    • If a device cannot display enough semantics for a transaction type, that transaction type is not safe to approve through a one-screen blind sign and trust the browser ceremony.
    • The right response is usually a stronger out-of-band review path, not a softer procedural warning.
  • Coordination infrastructure is part of custody truth
    • Proposal storage, decoding services, notification rails, browser delivery, Safe-style client gateways, and managed-custody dashboards are not harmless convenience layers once signers rely on them.
    • Healthy systems monitor, minimize, and constrain those surfaces like key-adjacent infrastructure.

Healthy architectural shapes

1. Hash-pinned multisig proposals

  • The proposal record shown to signers should be cryptographically and operationally bound to the exact transaction hash being signed.
  • Coordination services should reject mismatched proposals, mismatched confirmations, and any attempt to attach signatures to a materially different object than the one originally reviewed.
  • The positive test is simple: if the UI summary changes, the signed object must necessarily change too, and vice versa.

2. Split review channels for high-blast-radius actions

  • High-risk actions should require at least one independent verification path outside the browser session or dashboard that assembled the transaction.
  • That can mean raw calldata review on a second device, pre-approved action manifests, independent simulation, or explicit secondary human review of the exact operation type and target.
  • The point is not ceremonial complexity for its own sake; it is preventing one compromised representation layer from owning the whole custody truth.

3. Policy engines that understand privileged shape

  • Healthy custody systems distinguish approved destination transfer from approved delegatecall to a contract that can rewrite wallet logic.
  • Policies should fail closed on unexpected operation types, unexpected privileged selectors, implementation-slot mutations, owner changes, module installs, and other control-plane semantics.
  • A whitelist that approves only addresses but not operation shape is not pinning the real security object.

4. Narrow, hardened signing surfaces

  • The thinner and more immutable the review-and-sign path is, the less room there is for payload substitution.
  • Browser bundles, decoder dependencies, transaction-summary metadata, and proposal APIs should be treated like release-critical custody infrastructure, not ordinary product surfaces.
  • The cleanest design often uses minimal signing UI, stable code-delivery paths, and aggressively monitored changes around privileged signing ceremonies.

5. Role separation between routine treasury movement and root control

  • The same daily-use signing flow should not quietly carry wallet-upgrade, owner-rotation, or protocol-admin authority unless that distinction is unmistakable everywhere.
  • When routine asset movement and root-control operations share the same ceremony, attackers only need one representation-layer compromise to turn operational trust into catastrophic control transfer, or one stale but once-correct intent object to keep more authority than it deserves.

Design questions worth asking first

  • What exact machine-readable transaction object did the signers believe they approved?
  • What proves that the represented object on the review surface is still the canonical signer-intent object the device, proposal store, and collected signatures are actually authorizing?
  • Even if that object is canonical, why does it still deserve this much live authority under this lane, this freshness state, this signer environment, and this proposal lifetime?
  • Does the proposal service, UI, policy engine, and device confirmation all refer to that same object?
  • Can a supposedly routine transfer path still authorize delegatecall, implementation swap, owner change, or another control-plane side effect?
  • Which layers can rewrite or reinterpret transaction meaning after human review but before signatures execute?
  • If the device can only show a hash or partial fields, what independent process proves the browser’s interpretation was correct?
  • Are coordination and decoding services monitored and constrained like custody infrastructure, or treated like ordinary product middleware?

Red flags that usually mean signer intent is being authenticated by folklore

  • The signers reviewed it in the dashboard with no statement about the exact hash or payload bound to that review.
  • The address was whitelisted even though the approved path could still use delegatecall, module install, or another privileged call shape.
  • The hardware wallet displayed the transaction when the device could not meaningfully distinguish benign transfer semantics from a control-plane action.
  • The policy engine approved it even though the policy evaluated decoded or UI-level metadata instead of raw transaction truth.
  • The proposal looked right in Safe or another dashboard while the actual signed hash was never independently verified.
  • The interface is canonical used as if brand familiarity proved payload integrity.

Failure-prevention checklist

  • Review three separate promotions every time: a represented transaction object exists, that represented object is really the canonical signer-intent object, and that authenticated intent still deserves this much live authority. Healthy systems prove all three instead of assuming one implies the next.
  • Bind the reviewed proposal, device-visible approval object, collected signatures, and execution payload to one exact machine-verifiable envelope or hash. If the UI can describe one object while signatures attach to another, the ceremony is already unsafe.
  • Fail closed on privileged shape inside routine treasury or operations flows: unexpected delegatecall, module install, owner change, implementation rewrite, unusual nonce semantics, or batched subcalls should stop approval automatically rather than rely on operator memory.
  • Require a second verification channel for high-blast-radius actions or for any transaction type the signing device cannot render meaningfully. Raw calldata review, exact hash confirmation, independently delivered manifests, or separate simulation all work better than trust the browser one more time.
  • Make proposal coordinators, decoding services, browser bundles, notification rails, mobile clients, and signer endpoints part of release-critical custody infrastructure. They need hardened delivery, change control, monitoring, and rollback plans, not ordinary product assumptions.
  • Bind policy engines and whitelists to the exact target, call primitive, calldata, value semantics, and nonce object being signed. Destination-only or summary-only policy checks are not pinning signer intent.
  • Expire, cancel, or force fresh review on queued proposals, stored approvals, and durable-nonce-style workflows so a captured approval object cannot stay live indefinitely.
  • Separate routine asset-movement ceremonies from root-control ceremonies in both workflow and authority scope. If the same daily path can also mutate wallet logic or protocol admin state, one representation-layer compromise inherits catastrophic blast radius and one stale but once-legitimate approval object can outlive the trust context that created it.
  • Preserve proposal ids, signed hashes, browser-delivery artifacts, decoder outputs, and device-visible evidence by default so representation-layer incidents can be reconstructed quickly instead of turning into attribution fog.

Audit prompts

  • What exact machine-readable object does each signer review, and what proves that the same object is later stored, countersigned, and executed?
  • Which layer can still mutate transaction meaning after human review: browser bundle, proposal API, decoder, signer endpoint, notification rail, mobile client, or simulation service?
  • Which dangerous semantics remain too opaque on the signing device: delegatecall, module install, implementation change, owner transfer, batched subcalls, or unusual nonce handling?
  • Do policies and whitelists validate the exact target × operation × calldata × value × nonce envelope, or only a decoded summary and destination address?
  • Can a supposedly routine transfer path still authorize a control-plane action if the UI, metadata, or decoder is compromised?
  • What happens to partially collected approvals after retries, wallet glitches, suspicious signing failures, or signer-device reconnects?
  • Which services above the onchain wallet are already part of custody truth for this workflow, and are they monitored and changed with the same rigor as key-adjacent infrastructure?

Lessons that should already be standard

  • Represented transaction exists, represented transaction is the canonical signed intent, and that intent still deserves live authority are different properties.
  • A multisig threshold is not the same thing as signer-intent integrity. Real signatures over the wrong transaction are still a custody failure.
  • Whitelisted recipient, simulation passed, and dashboard looked normal are weak assurances unless they are all bound to the exact payload that the device signs and the chain executes.
  • Blind-signing should narrow what a ceremony is allowed to authorize. If the device cannot express privileged shape, the system needs a stronger second channel or a smaller action set.
  • Proposal stores, decoders, browser bundles, notification rails, and signer endpoints are part of the custody boundary once humans rely on them to know what they are signing.
  • Durable approvals are stored explosives. If a workflow keeps them live for later execution, cancellation, expiry, and anomaly-triggered re-review have to be equally real.
  • Familiar branding is not an authenticity proof. It was shown in Safe or it came through the custody dashboard is only meaningful if the represented transaction stayed identical to the signed and executed one.

Where this note helps most

  • Start here when the sharper question is what should healthy human approval and machine authorization have kept bound together?
  • Drop into blind-sign-payload-substitution when the concrete failure is that signers were shown one transaction but validly signed another.
  • Pair with Execution-envelope identity pinning when the next question is how delayed or privileged onchain execution should keep target, code identity, call primitive, and payload pinned after approval is already collected.
  • Pair with operator-boundary-opacity when the deeper problem is that the real trust boundary lived in a smaller operator stack above the nominal signer set.
  • Pair with signer-quorum-compromise when the core question is simply who really controlled enough approvals?, whether through deception, key theft, or hidden centralization.

Internal linkages

Control surface

Graph View

Backlinks