Transactions
Primary, compatibility, history and supporting transaction methods.
Status and scope
Proposed target SDK catalog combining the existing generic transaction design with every verified current transaction method. The detailed primary send contract remains sendTransaction and ethSendTransaction; getSendTransactionStatus remains the supporting chain-detail read.
The target excludes ERC-4337 account creation, EIP-7702 delegation, paymasters, user operations, session-key delegation and smart-contract wallet deployment. Ordinary EOA signing, sending, policy evaluation and off-chain approval remain in scope. Solana native separate-fee-payer sponsorship is allowed under an exact fee quote, expiry, sponsor signature and treasury limit. EVM gas funding is a separate pre-fund/reimburse transfer, never same-transaction sponsorship.
Primary business methods#
| Method | Meaningful input | Result or effect |
|---|---|---|
signTransaction |
requestId, wallet/signer, exact network, unsigned transaction bytes/structure, actor and approval when required |
signed bytes and signer identity; never broadcast |
sendTransaction |
requestId, wallet, network, high-level transaction, bounded fee authorization, actor and approval when required |
one durable sign-and-submit operation |
getSendTransactionStatus |
send-status ID returned by a send operation | read-only submission/inclusion/execution/finality detail |
watchWallet |
wallet/network/consumer and event-kind scope | signed incoming-deposit and outgoing-transfer lifecycle notifications |
verifyWebhook |
exact raw bytes plus signature/timestamp/key/version metadata | server-verified event envelope; no finality claim |
sendTransaction remains the new generic native/token transfer entry point for Ethereum, BNB Smart Chain, Solana and TRON adapters only when each adapter has accepted implementation evidence. An EVM contract call uses an explicit evmCall transaction variant. The method never claims a universal raw structure for unrelated chain families.
Compatibility and source-parity methods#
| Method | Role | Boundary |
|---|---|---|
ethSendTransaction |
EVM compatibility alias | validates Ethereum/BNB scope and maps once to the generic evmCall form; cannot bypass approval, policy, fee or request identity |
solSendTransaction |
dedicated Solana compatibility helper | accepts only a supported Solana transaction action and returns the same durable operation semantics |
listEthTransactionHistory |
EVM address/network history read | bounded, paginated source history; not wallet-operation recovery |
listSolTransactionHistory |
Solana address/network history read | bounded, paginated source history; not wallet-operation recovery |
No generic update/delete transaction method exists or is proposed. Once signed or submitted, correction follows the network, operation and append-only event contracts; history is never edited to manufacture a different outcome. Incoming deposit events adapt current Streams contracts; outgoing transfer lifecycle requires its own proposed event source and is not claimed as current Streams behavior.
The verified server helper pollTransactionStatus repeatedly calls the status read until a terminal source state or timeout. It is supporting convenience, not a primary application workflow. The own SDK should await within the caller's deadline when practical and use getOperation(requestId) after timeout/restart. It must not force user-written polling or treat polling timeout as transaction failure.
State separation#
| Layer | What it proves | What it does not prove |
|---|---|---|
| Approval | authorized actors agreed to exact transaction material | signing, submission or chain success |
| Operation | backend signing/submission action and durable result | inclusion, execution or finality unless explicitly evidenced |
| Chain status | observed broadcast/inclusion/execution/finality boundary | user authority or safe creation of replacement signed material |
| History | bounded network-source records for an address | complete application accounting or operation idempotency |
| Signed event | authentic sender/integrity, tenant/wallet/event binding and stated lifecycle observation | chain execution/finality, authority or exactly-once delivery |
A transaction hash or Solana signature is a network identity, not proof of successful execution or finality. Unavailable history is not an empty wallet and missing status is not a failed send.
Replay, expiry and replacement#
Same requestId and same immutable transaction material converges on one logical operation; changed wallet, network, recipient, asset, amount, call data or fee bounds conflicts. After transport loss, callers recover the same operation. The SDK may retransmit only the exact same still-valid signed identity when the adapter contract proves it safe.
An expired recent blockhash, nonce conflict or replacement rule cannot silently cause rebuilding and signing new bytes. The adapter first reconciles the original identity. Any new signed material requires a separately defined and freshly authorized operation transition. No timeout, approval or history result authorizes blind rebroadcast or a second payout.
Runtime and security#
TypeScript browser and React may initiate only under scoped identity and action-bound, mode-appropriate authority. Embedded wallets require owner grants/approval. Server wallets require the named service identity, policies, transaction limits and configured approvers; end-user login never grants treasury authority. Python/Go server location does not waive the applicable authority. Server credentials, signing secrets and webhook verification secrets never enter browser configuration.
| TypeScript browser | TypeScript server | React adapter | Python server | Go server |
|---|---|---|---|---|
| Proposed scoped sign/send/history target | Proposed target | Calls the TypeScript core in a client component; no transaction hook is implied | Proposed server target | Proposed server target |
const operation = await sdk.sendTransaction({ requestId, walletId, network, transaction });
const history = await sdk.listEthTransactionHistory({ organizationId, address, cursor });
operation = await sdk.send_transaction(SendTransactionInput(
request_id=request_id,
wallet_id=wallet_id,
network=network,
transaction=transaction,
))
history = await sdk.list_eth_transaction_history(ListEthTransactionHistoryInput(
organization_id=organization_id,
address=address,
cursor=cursor,
))
operation, err := sdk.SendTransaction(ctx, &SendTransactionInput{
RequestID: requestID,
WalletID: walletID,
Network: network,
Transaction: transaction,
})
if err != nil { return err }
history, err := sdk.ListEthTransactionHistory(ctx, &ListEthTransactionHistoryInput{
OrganizationID: organizationID,
Address: address,
Cursor: cursor,
})
Acceptance#
- Positive: send/status/history and signed deposit/transfer events are discoverable with distinct evidence roles.
- Positive: signing never broadcasts; send, status and history preserve the evidence they can actually establish.
- Negative: no smart-wallet/delegation capability is implied; wrong network/mode, changed material, exceeded fee/treasury bound or denied approval cannot sign or submit; timeout cannot create a replacement transaction; event signature is not finality.
See sendTransaction and ethSendTransaction, getSendTransactionStatus, signTransaction, Approvals, and getOperation.