signMessage
Sign an exact message payload under wallet authority.
Status
Proposed target SDK behavior for implementation. It is not an available SDK or cryptographic-support claim.
Business action#
Sign a human-readable or protocol-defined message with an authorized wallet address to prove control or authorize an off-chain action.
Proposed call#
signMessage(
input: SignMessageInput,
options?: CallOptions,
): Promise<Operation<SignMessageResult>>
TypeScript uses requestId, walletId or the documented signer field, network, signingScheme, exact message bytes or text plus an explicit textEncoding, actor, and optional authorization.
async def sign_message(
input: SignMessageInput,
*,
options: CallOptions | None = None,
) -> Operation[SignMessageResult]: ...
Python uses request_id, wallet_id, signing_scheme and text_encoding. A typed input variant distinguishes bytes from text; the binding does not guess an encoding.
SignMessage(
ctx context.Context,
input *SignMessageInput,
) (*Operation[SignMessageResult], error)
Go uses RequestID, WalletID, SigningScheme and TextEncoding; the binding copies mutable message bytes before retaining operation material. Context cancellation after SDK dispatch requires GetOperation recovery, even when backend acceptance was not observed.
Required input: requestId, wallet/signer, exact network and signing scheme, message bytes or unambiguous text encoding, actor and authorization when required.
Result and operation behavior#
Success returns signature, encoding, signer, scheme and signed-message identity. Hashing, canonical framing, algorithm selection and custody transport remain internal but must be fixed by the implementation contract and cross-language vectors.
The request ID binds immutable message bytes, signer, scheme, actor and required authority context. Authorization responses bind to that record and are accumulated separately. Same-ID/same-material replay converges; changed material conflicts. Unknown outcome is recovered with getOperation(requestId) and never by silently signing altered content.
Authorization and effects#
Existing grants may complete the action. Otherwise the SDK uses the mode-appropriate embedded-owner or server-service handler once or returns requiresAction; it cannot do both. End-user login never grants server signing authority. Denial/expiry produces no signature, and a signature grants no later authority.
Acceptance#
- Positive: the result verifies for the requested signer and exact message under the declared scheme.
- Negative: encoding ambiguity, wrong network/signer, denial, expiry or changed material cannot sign; the SDK cannot reinterpret a message as a transaction.
See getOperation.