Signing Intents

Every signature the SDK produces is pre-authorized by a signing intent: a single-use record that pins the signature to one exact payload, on one specific key, for your organization. The SDK mints it for you. There is no callback to write, no endpoint to call, and no token to pass. This page explains what happens under the hood so you can reason about the security model.

​

What an intent binds

Right before each signing round, the SDK declares to WalletSuite exactly what is about to be signed. The intent binds two things:

• The key. The keyId of the wallet doing the signing.
• The payload. A hash of the exact bytes to be signed. One intent authorizes one payload and nothing else.

WalletSuite records the intent and returns a single-use release token that unlocks the signing service’s share for that one payload. The SDK uses the token immediately and discards it. A stolen token cannot sign a different transaction, and a used or expired one cannot sign at all.

​

What it enforces

Because the signature is pinned to a declared payload on a named key, the intent gives you three guarantees on every signature, with no work on your side:

• Replay protection. The release token is single-use and short-lived, so the same authorization can never sign twice.
• Key binding. The intent is tied to the wallet’s keyId, so a payload can only be signed by the key it was declared against.
• Audit. Every signature leaves a durable record of what was signed, against which key, and when.

​

Policy evaluation

Before WalletSuite mints the release token, it evaluates the intent against your organization’s policy. Two layers run in order. Chain entitlement is always on: the intent’s chain must sit inside the caller’s entitled chain set. Org allowlist rules are opt-in and deny-by-default once armed: each active rule matches on chain, operation type, contract address, method selector, an optional destination pin, and an optional per-transaction amount cap in base units. Operations the classifier cannot type are denied. The release token is minted only when the intent clears policy. A denied intent is recorded and never receives a release token, so it cannot be signed. There is no separate call to make. The decision runs inline when the SDK declares the intent. Every signing intent carries its policy decision: a policyDecisionId, the decision reason, and the matched rule when one admitted it. Allowed and denied intents alike trace back to one evaluation in the signing-intents ledger. See Policy Gates for the rule model and Policy Decisions for the decision record on every intent.

​

Nothing to implement

You configure the SDK with the signing service URL and your API key, then call a sign* method with the transfer parameters. That is the whole surface. The SDK resolves the WalletSuite authorization endpoint from the signing service URL, mints the intent, and completes the signature in a single call. EIP-7702 signing runs two rounds with distinct payloads, so the SDK mints one intent per round automatically. You never see or handle intent ids or release tokens.

​

Next steps