signTypedData
Sign structured typed data bound to its exact domain and payload.
Status
Proposed target SDK behavior for implementation. It is not an available SDK or cryptographic-support claim.
Business action#
Sign structured data for a supported network/domain so an integrator can authorize a protocol action or permission without constructing signing bytes itself.
Proposed call#
signTypedData(
input: SignTypedDataInput,
options?: CallOptions,
): Promise<Operation<SignTypedDataResult>>
TypeScript uses requestId, walletId or the documented signer field, network, typedDataVersion, domain, types, value, actor, and optional authorization. The version and domain enums serialize to stable documented strings.
async def sign_typed_data(
input: SignTypedDataInput,
*,
options: CallOptions | None = None,
) -> Operation[SignTypedDataResult]: ...
Python uses request_id, wallet_id and typed_data_version; enum members carry the same wire values. Exact integer members inside typed data use arbitrary-precision int and the shared canonical codec.
SignTypedData(
ctx context.Context,
input *SignTypedDataInput,
) (*Operation[SignTypedDataResult], error)
Go uses RequestID, WalletID and TypedDataVersion; enum values are named string constants. The binding deep-copies mutable maps, slices, byte data and big.Int values before retaining immutable operation material.
Required input: requestId, wallet/signer, network, typed-data version, domain, type definitions, value, actor and authorization when required. The implementation must reject duplicate or ambiguous fields and unsupported versions.
Result and operation behavior#
Success returns signature, signer, typed-data version and canonical payload identity. Domain separation, canonical encoding, hashing, algorithm selection and custody transport stay internal but require interoperable fixtures across bindings.
The request ID binds immutable domain, types, value, signer, 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 through getOperation.
Authorization and effects#
Pre-existing grants may complete the call; 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 typed-data signature implies no submission or broader authority.
Acceptance#
- Positive: an independent verifier reconstructs the same canonical payload and validates the requested signature.
- Negative: changed domain, chain, type, value, signer, version or request material cannot reuse authorization; malformed/ambiguous data creates no signature.
See getOperation.