Wallet and signing library incident advisories for Sui cover a class of vulnerabilities that originate in the off-chain code responsible for constructing, signing, and serializing transactions before they are submitted to the network. These bugs are not in the Move VM or consensus layer, but in the TypeScript SDK, Rust SDK, hardware wallet firmware, or custom signing integrations that custodians, exchanges, and wallet providers build on top of them. The consequence is often a mismatch between what the user or application intended to authorize and what the validator set executes on-chain.
Protocols
Wallet and Signing Library Incident Advisories
Catalog of critical bugs in Sui SDKs and wallet integrations causing transaction malleability, incorrect signature generation, or blind-signing risks. Custodians and wallet builders audit their signing infrastructure against these advisories.
introduction
SIGNING INFRASTRUCTURE RISK
Introduction
Critical bugs in Sui SDKs and wallet integrations can cause transaction malleability, incorrect signature generation, and blind-signing vulnerabilities.
The Sui programmable transaction block model introduces a complex serialization format where a single user signature can authorize a graph of commands, including MoveCall, TransferObjects, and MakeMoveVec. A flaw in how an SDK constructs this TransactionData structure—or how a hardware wallet parses it for display—can lead to transaction malleability, where a third party modifies the transaction after signing, or blind-signing, where the signer approves an opaque blob without understanding its effects. Advisories in this category also track incorrect signature generation, such as using the wrong intent scope (TransactionData vs PersonalMessage) or mishandling the IntentMessage wrapper, which can break replay protection or cause signature verification failures.
For custodians and wallet builders, these advisories are operational triggers to audit their signing infrastructure against the specific flawed code paths. A single advisory may require patching SDK dependencies, updating hardware wallet apps, revising transaction simulation logic, or adding pre-signing checks that validate the TransactionKind against a known allowlist. Chainscore provides SDK integration reviews and signing flow audits that trace the full path from user intent to on-chain execution, identifying gaps in display, serialization, and authorization logic before they become incidents.
WALLET AND SIGNING LIBRARY INCIDENT ADVISORIES
Quick Facts
Operational impact summary for critical bugs in Sui SDKs, signing libraries, and wallet integrations that can cause transaction malleability, incorrect signature generation, or blind-signing vulnerabilities.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
TypeScript SDK signing | Incorrect transaction digest generation or signature payload construction | Wallet builders, dApp frontends, custodians using @mysten/sui.js | Audit signing flow against advisory; verify digest matches on-chain execution |
Rust SDK key management | Flawed key derivation, nonce reuse, or incorrect intent signing | Exchange deposit/withdrawal systems, validator operators, Rust-based infrastructure | Review key generation and signing logic; test against official test vectors |
Hardware wallet integration | Blind-signing of programmable transaction blocks or incorrect object display | Ledger/SafePal integrators, institutional custodians | Verify transaction decoding on device; ensure all Move call arguments are displayed |
zkLogin ephemeral key handling | Ephemeral key leakage, expiry bypass, or salt misuse enabling unauthorized access | Wallets supporting zkLogin, dApps using ephemeral signatures | Validate ephemeral key lifecycle; enforce strict expiry and single-use constraints |
Sponsored transaction gas logic | Griefing attacks on gas sponsors or bypass of sponsorship checks | High-throughput dApps, wallet providers offering gasless transactions | Review sponsor allowlist logic; implement rate limiting and maximum gas budgets |
Intent signing scope | Incorrect AppId or IntentScope leading to cross-context signature replay | All signing library integrators | Verify IntentScope is correctly set for each transaction type; test cross-context replay resistance |
Serialization and BCS encoding | Mismatch between client-side BCS serialization and Move bytecode expectations | Indexers, block explorers, exchange reconciliation systems | Validate BCS encoding against canonical Move struct layouts; test with edge-case types |
technical-context
SIGNING LIBRARY INCIDENT ADVISORIES
Technical Context and Root Cause Patterns
Analysis of recurring failure modes in Sui wallet and signing libraries that lead to transaction malleability, blind-signing, and unauthorized access.
Wallet and signing library incidents on Sui typically originate from a disconnect between the abstract TransactionKind builders in the TypeScript and Rust SDKs and the final Intent-scoped message that gets signed. When a library constructs a TransactionData object, it must deterministically serialize the BCS representation of the entire transaction, including the GasData, Expiration, and Sender. A bug in this serialization path—such as an incorrect struct ordering, a missing field, or a non-canonical integer encoding—can produce a byte sequence that differs from what the Move VM will later execute. The result is a valid signature over a transaction the signer did not intend to authorize, a classic transaction malleability vector that custodians and wallet builders must guard against.
A second class of vulnerability emerges in hardware wallet integrations and blind-signing flows. Sui's programmable transaction blocks allow a single user signature to authorize a complex, chained sequence of MoveCall and TransferObjects commands. If a wallet UI fails to decompose and display every command in the block—particularly nested MakeMoveVec or SplitCoins operations—the user may approve a transaction that drains objects from their account. This is not a protocol-layer bug but an integration flaw where the signing library correctly constructs the transaction but the presentation layer omits critical side effects. Advisories in this category often require wallet providers to update their transaction decoding logic and add explicit warnings for programmable transaction blocks that manipulate Coin or Balance types.
The Sui TypeScript SDK's programmable transaction builder and the Rust SDK's TransactionBuilder are the primary surfaces where these bugs manifest. When an advisory is published, integration teams should immediately diff the affected SDK version against the patched version, focusing on changes to BCS serialization, Intent message construction, and command decomposition logic. For custodians and exchanges, the operational impact extends beyond upgrading a library: they must re-verify that their offline signing infrastructure produces identical signatures to the Sui CLI reference implementation and that their transaction pre-screening logic correctly parses all commands in a programmable transaction block. Chainscore provides SDK integration reviews and signing flow audits that map these advisory patterns to a team's specific custody architecture.
WHO NEEDS TO ACT
Affected Actors and Systems
Wallet Providers
Custodial and non-custodial wallet stacks are the primary affected systems. Teams must audit their integration with the Sui TypeScript and Rust SDKs against the specific advisory.
Immediate actions:
- Verify the SDK version used in transaction construction and signing flows.
- Check for blind-signing vulnerabilities where the human-readable transaction summary does not match the signed payload.
- Audit ephemeral key management if using zkLogin.
Chainscore can:
- Audit your signing flow end-to-end, from UI rendering to SDK serialization.
- Verify that transaction digests are computed correctly before user approval.
- Review zkLogin salt and ephemeral key lifecycle management.
implementation-impact
SIGNING INFRASTRUCTURE AUDIT
Implementation and Integration Impact
Wallet and signing library incidents directly affect how transactions are constructed, signed, and verified. The following impact areas require immediate review by custodians, wallet builders, and dApp teams integrating Sui signing flows.
01
Transaction Malleability in SDKs
Bugs in the TypeScript or Rust SDK can cause a transaction's bytes to be altered after signing without invalidating the signature. This allows a relay or RPC node to change gas objects, transaction inputs, or programmable transaction block commands. Custodians must verify that their signing implementation uses the correct intent scope and serialization format. Chainscore audits SDK integration points to ensure the signed payload matches the intended execution.
02
Blind-Signing Vulnerabilities in Hardware Wallets
Hardware wallet integrations on Sui may display incomplete or misleading transaction summaries due to complex programmable transaction blocks or Move call parsing failures. Users can be tricked into approving asset transfers or contract upgrades they did not intend. Wallet teams should implement human-readable transaction decoding for all Move function calls and object transfers. Chainscore reviews hardware wallet firmware integration and transaction display logic for Sui-specific blind-signing risks.
03
zkLogin Ephemeral Key Management
zkLogin relies on ephemeral key pairs with a limited lifespan. Flaws in key generation, storage, or expiry enforcement can allow an attacker who compromises an old ephemeral key to replay or extend its validity. Wallet providers must ensure ephemeral keys are generated with sufficient entropy, stored securely, and invalidated precisely at the max epoch specified in the JWT. Chainscore assesses zkLogin key lifecycle management and session revocation logic.
04
Intent Scope and BCS Serialization Errors
Sui transactions are wrapped in an IntentMessage that scopes the signature to a specific intent (e.g., TransactionData). Incorrect BCS serialization or missing intent headers can lead to signature reuse across different contexts or chains. Integration engineers must validate that their signing stack correctly serializes the full IntentMessage envelope for every transaction type. Chainscore provides BCS serialization compliance reviews for custom signing implementations.
05
Sponsored Transaction Gas Logic Exploitation
When a sponsor pays gas for user transactions, bugs in the gas object selection or budget validation can allow griefing attacks where a malicious user crafts transactions that drain the sponsor's gas treasury. dApps and wallet providers offering sponsored transactions must implement strict gas budget limits and validate the transaction's gas object ownership before countersigning. Chainscore reviews gas sponsorship flows to prevent treasury exhaustion vectors.
06
Multi-Sig and Account Abstraction Signing Flows
Sui's native multi-sig and upcoming account abstraction features introduce complex signing flows where multiple parties or contract logic must authorize a transaction. Incorrect nonce management, signature aggregation, or threshold checks can permanently lock funds or allow unauthorized execution. Custodians and smart wallet teams must audit their multi-sig orchestration against Sui's exact transaction authorization model. Chainscore provides multi-sig and AA signing flow security audits.
SIGNING INFRASTRUCTURE INCIDENT IMPACT
Risk Matrix
Operational impact assessment for critical bugs in Sui SDKs, hardware wallet integrations, and signing libraries that affect transaction integrity.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Transaction Malleability | SDK bug allows transaction hash to be modified after signing without invalidating the signature | Custodians, exchanges, and wallets verifying on-chain transaction finality | Audit SDK version and signature verification logic against the canonical advisory |
Incorrect Signature Generation | Signing library produces signatures over an incorrect byte representation of the transaction payload | Wallet providers and dApps constructing programmable transaction blocks | Verify signature generation against the reference implementation for the specific SDK version |
Blind-Signing Vulnerability | Hardware wallet integration fails to decode and display the full Move call path, showing a generic or truncated prompt | Hardware wallet users and custodians using Sui ledger apps | Validate transaction decoding logic and enforce clear-signing policies for high-value Move functions |
Ephemeral Key Mismanagement | zkLogin SDK flaw allows ephemeral key reuse or insufficient entropy, enabling unauthorized transaction authorization | dApps and wallets integrating zkLogin authentication flows | Review ephemeral key generation, storage, and expiry logic against the latest zkLogin security guidance |
Sponsored Transaction Griefing | Gas sponsorship logic flaw allows an attacker to construct transactions that drain the sponsor's gas budget without executing | High-throughput dApps and wallet providers operating gas sponsorship programs | Implement sponsor-side transaction simulation and budget caps; review sponsorship implementation |
Dynamic Field Access Bypass | Signing library incorrectly serializes dynamic field access, causing the user to sign a different object path than intended | DeFi protocols and wallets interacting with complex object structures | Test signing flows against dynamic and nested object access patterns; verify canonical serialization |
Object ID Collision in Signing Payload | SDK version incorrectly resolves object IDs, leading to a signature over an object the user does not control | Custodians and multisig operators managing shared or wrapped objects | Cross-reference object ID resolution logic with the full node state; pin SDK versions after audit |
SIGNING INFRASTRUCTURE INCIDENT RESPONSE
Remediation and Verification Checklist
A structured checklist for custodians, wallet builders, and exchange security teams to verify that their signing infrastructure is not affected by a disclosed vulnerability in the Sui TypeScript SDK, Rust SDK, or hardware wallet integration. This process ensures transaction integrity and prevents exploitation of signature malleability or blind-signing flaws.
Confirm the exact version of the Sui TypeScript SDK (@mysten/sui.js) or Rust SDK (sui-sdk) used in your signing infrastructure.
- What to check: Compare your lockfile or dependency manifest against the vulnerable version range specified in the advisory.
- Why it matters: Signature malleability bugs are often introduced in specific minor versions. Running an unpatched version means transactions could be modified after signing without invalidating the signature.
- Readiness signal: The SDK version is updated to the patched release and all integration tests pass against a Sui testnet endpoint.
resource-links
SUI WALLET AND SIGNING LIBRARY INCIDENT ADVISORIES
Canonical Resources and Disclosures
Use these canonical sources to verify Sui SDK signing behavior, security disclosure status, release provenance, and wallet integration guidance before patching custody, wallet, bridge, or exchange infrastructure.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
SIGNING INCIDENT RESPONSE
Frequently Asked Questions
Operational questions for teams responding to a Sui wallet or signing library advisory. These answers help custodians, wallet builders, and exchange security teams assess exposure, validate remediation, and restore safe signing operations.
Start by mapping your dependency tree against the affected version ranges published in the advisory.
- Check SDK versions: Identify the exact
@mysten/sui.js(TypeScript) orsui-sdk(Rust) version your signing service uses. Compare against the vulnerable range. - Audit signing paths: Determine whether your integration calls the vulnerable function (e.g.,
signTransactionBlock,signPersonalMessage, or a specific intent-scoping helper). Not all callers of a buggy library are necessarily exposed. - Review key generation: If the bug involves non-deterministic key derivation or salt handling (as in some zkLogin advisories), verify whether affected ephemeral keys or salt values were generated during the vulnerable window.
- Inspect historical transactions: For transaction malleability bugs, replay suspect transactions against a patched node to check whether the signed digest matches the on-chain execution. Mismatches indicate potential exploitation.
Chainscore can perform a focused dependency audit and signing path review to confirm exposure scope.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.