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.

​

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