signTransaction
Produce a signature over exact transaction material without broadcasting.
Status
Proposed target SDK behavior for implementation. It is not an available SDK, cryptographic implementation, or network-support claim.
Business action#
Authorize and sign one exact transaction without broadcasting it.
Proposed call#
signTransaction(
input: SignTransactionInput,
options?: CallOptions,
): Promise<Operation<SignTransactionResult>>
The TypeScript DTO uses requestId, walletId or the documented authorized address field, network, transactionFormat, unsignedTransaction, actor, and optional authorization. Exact quantity members are bigint in the SDK model and canonical decimal strings on the wire.
async def sign_transaction(
input: SignTransactionInput,
*,
options: CallOptions | None = None,
) -> Operation[SignTransactionResult]: ...
Python uses request_id, wallet_id, transaction_format and unsigned_transaction; exact quantities are arbitrary-precision int values encoded by the shared decimal codec.
SignTransaction(
ctx context.Context,
input *SignTransactionInput,
) (*Operation[SignTransactionResult], error)
Go uses RequestID, WalletID, TransactionFormat and UnsignedTransaction; exact quantities use copied big.Int values and serialize as canonical decimal strings. Cancellation after SDK dispatch requires recovery through GetOperation, even when backend acceptance was not observed.
Required input: requestId, wallet ID/address, explicit network/format, serialized unsigned transaction, actor and mode-appropriate owner/service authorization. Amounts and fees preserve exact integer precision.
Result and operation behavior#
Success returns signed transaction bytes, encoding, network and signed-payload identity. It is not a broadcast receipt, execution result or finality proof.
The SDK binds the request ID to immutable signer, network, transaction bytes and required authority context. Authorization responses bind to that record and are accumulated separately. Same-ID/same-material replay returns the same operation result; changed material conflicts. An uncertain outcome is recovered with getOperation(requestId) and is never resolved by signing again under a new identity.
Authorization and effects#
When grants are insufficient, the SDK uses the mode-appropriate handler once or returns requiresAction; it cannot do both. Embedded mode uses owner authority. Server mode uses service identity, policy/limits and approvers; end-user login cannot authorize it. Signing/custody mechanics stay internal and no result exposes raw material.
Success produces executable signed bytes but does not broadcast. Rejection or conflict produces no signature.
Acceptance#
- Positive: the returned signature verifies against the requested wallet and exact decoded transaction.
- Negative: wrong owner, wallet, policy, network, payload, expiry or reused request ID with changed material cannot sign; signing alone cannot submit funds.
See signMessage, signTypedData, and getOperation.