The Web3Wallet SDK release history documents every versioned change to the wallet-side libraries that implement the WalletConnect v2 protocol. These SDKs—maintained for Kotlin (Android), Swift (iOS), and Flutter (cross-platform)—are the primary integration surface for mobile wallet teams. Each release may alter how wallets handle session proposals, manage pairing URIs, process push notifications, or respond to dapp JSON-RPC requests. Tracking this history is essential for QA engineers validating compatibility against the latest dapp-side expectations and for operations teams planning upgrade cycles.

Web3Wallet SDK (Wallet Side) Release History
Introduction
A chronological catalog of wallet-side SDK releases for Kotlin, Swift, and Flutter, tracking changes to session proposal handling, push notification support, and pairing logic.
Wallet-side releases are distinct from the Sign Client and Core protocol libraries. While the @walletconnect/sign-client package defines the protocol state machine, the Web3Wallet SDKs translate that logic into platform-native APIs, lifecycle management, and UI hooks. A breaking change in a Kotlin or Swift release may require wallet developers to refactor their session approval flows, update their notification handling, or migrate to new pairing interfaces—even if the underlying protocol version remains unchanged. The release notes captured here surface those operational impacts, including dependency bumps, deprecated methods, and new feature flags.
Mobile wallet teams should monitor this release history alongside the Web3Modal SDK changelog and the Push Protocol client releases. A dapp using the latest Web3Modal may send session proposals that only wallets on a minimum Web3Wallet SDK version can handle correctly. Similarly, push notification delivery guarantees depend on alignment between the wallet-side Push SDK and the relay infrastructure. Chainscore Labs provides integration testing and compatibility validation for wallet teams that need to certify their builds against the latest dapp-side requirements before production deployment.
Release Snapshot
A technical summary of recent wallet-side SDK releases, highlighting changes that affect session management, push notifications, and pairing logic for mobile wallet developers.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Session Proposals | New API methods for handling session proposals with optional namespaces and scoped CAIP-2 chain identifiers | Kotlin, Swift, and Flutter wallet developers | Update session proposal handler logic to parse and validate new namespace structures |
Push Notifications | Changes to push notification payload format and subscription management lifecycle | Mobile wallet teams on Android and iOS | Review notification handling code for compatibility with updated payload schemas and error codes |
Pairing Logic | Modifications to pairing URI parsing and validation to align with latest relay protocol requirements | Wallet SDK integrators | Test pairing flows against the current relay URL and verify URI format compliance |
Dependency Bumps | Minimum OS and language version requirements updated for Kotlin, Swift, and Flutter packages | Mobile CI/CD and QA engineers | Verify build pipelines against new minimum SDK versions and update test device matrices |
Error Handling | New JSON-RPC error codes introduced for session expiry and invalid proposal states | QA engineers and integration test developers | Add test cases for new error codes to ensure graceful degradation in wallet UI |
Background Execution | Changes to Android and iOS background task handling for long-lived session state synchronization | Mobile wallet infrastructure teams | Validate background process behavior under OS-level restrictions to prevent session timeouts |
Deprecation Notices | Deprecated methods from previous major version flagged for removal in upcoming releases | All wallet-side integrators | Audit codebase for deprecated method usage and plan migration to replacement APIs |
Technical Mechanism and Change Categories
A technical breakdown of the operational change categories tracked across Kotlin, Swift, and Flutter wallet SDK releases, defining the integration surface that mobile wallet teams must monitor.
The Web3Wallet SDK release history for wallet-side implementations tracks operational changes across three primary mobile targets: Kotlin (Android), Swift (iOS), and Flutter (cross-platform). Each release modifies the integration surface that wallet developers use to handle session proposals, manage pairing lifecycles, respond to dapp JSON-RPC requests, and deliver push notifications. These SDKs implement the WalletConnect v2 protocol stack, including the sign and push specifications, and are the primary runtime dependency for mobile wallets that accept connections from dapps using Web3Modal or direct Sign Client integrations. A release may alter how a wallet processes a session_proposal, validates CAIP-2 chain identifiers, or serializes a session object for persistence—each of which directly affects compatibility with the dapp ecosystem.
Change categories in this release history fall into four operational domains. Session lifecycle changes modify how wallets approve, upgrade, extend, or expire sessions, including breaking changes to the Session.Proposal or Session data models. Pairing and URI handling changes affect the parsing of WalletConnect URIs, the pairing proposal flow, and the underlying relay connection establishment—critical for wallets that support deep linking or QR code scanning. Push notification changes alter the subscription model, notification payload structure, or platform-specific delivery mechanisms on Android and iOS, directly impacting a wallet's ability to deliver dapp notifications reliably in background states. Dependency and API surface changes include Kotlin/Swift language version bumps, coroutine or async/await migration requirements, and transitive dependency updates that may force coordinated upgrades across a wallet's broader codebase.
Mobile wallet teams should treat each SDK release as a potential compatibility boundary. A dapp built against the latest @walletconnect/sign-client may send a session proposal that an older wallet-side SDK cannot deserialize, leading to silent rejection or crash behavior. Chainscore Labs provides integration testing and compatibility validation for wallet teams, ensuring that session upgrade flows, push notification delivery, and pairing logic remain robust against the latest dapp-side expectations. For teams managing multiple wallet builds across Kotlin, Swift, and Flutter, a structured release monitoring practice—mapping each SDK version to its protocol feature support and breaking change list—is the minimum operational requirement to avoid user-facing connection failures.
Affected Systems and Teams
Mobile Wallet Developers
Kotlin, Swift, and Flutter SDK releases directly alter the API surface for session proposal handling, push notification registration, and pairing URI parsing. A minor version bump can introduce new required parameters in Session.Proposal or change the threading model for network calls.
Action items:
- Pin SDK versions in CI and never rely on floating patch versions.
- Test session upgrade flows (e.g., from v2.0 to v2.1 session permissions) against the latest dapp-side expectations.
- Verify push notification delivery on both Android and iOS after each SDK update, as background process behavior often changes.
- Monitor the deprecation schedule for Kotlin coroutine API changes and Swift async/await migration requirements.
Chainscore can perform integration testing across dapp scenarios to validate that session lifecycle, pairing, and push notifications remain reliable after SDK updates.
Implementation Impact Areas
Each Web3Wallet SDK release introduces changes that require specific actions from mobile wallet development, QA, and operations teams to maintain compatibility and adopt new features.
Push Notification Payload and Lifecycle Changes
Releases frequently modify the push notification protocol, including subscription management, notification payload formats, and delivery guarantees. Mobile wallet teams must update their notification service handlers and background processing logic to align with new payload structures. Test notification delivery across Android and iOS under various app states (foreground, background, killed) to prevent silent failures in production.
Pairing URI and Deep Link Handling
Changes to pairing URI formats or deep link handling logic can break the initial connection flow between a dapp and wallet. QA teams must regression-test the full pairing flow—from QR code scan or deep link tap to session establishment—on every SDK update. Pay close attention to URI parsing, fallback mechanisms, and error states when the wallet is not yet installed.
Kotlin, Swift, and Flutter API Breaking Changes
Each platform-specific SDK (Kotlin, Swift, Flutter) may introduce breaking API changes, method deprecations, or new required parameters. Engineering teams should diff the changelog against their integration layer and plan migration sprints before adopting the new version. Delaying updates risks accumulating technical debt and missing critical security patches in transitive dependencies.
Dependency and Minimum OS Version Bumps
New SDK releases may bump minimum Android API levels, iOS deployment targets, or Flutter SDK versions. Operations leads must verify that the updated requirements align with their supported device matrix before rolling out. Premature adoption can fragment the user base; delayed adoption can block access to dapps requiring newer protocol features.
Compatibility and Upgrade Risk Matrix
Assess the operational and integration impact of changes across Kotlin, Swift, and Flutter wallet SDK releases. This matrix helps mobile wallet teams identify breaking changes, new feature requirements, and validation steps needed to maintain compatibility with dapp expectations.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Session Proposal Handling | New required fields or validation logic in session proposal payloads may be introduced. Older SDKs may reject valid proposals or accept malformed ones. | Mobile wallet developers (Android, iOS, Flutter) | Review release notes for changes to proposal schema. Update UI to display new required metadata. Run integration tests against latest dapp-side SDK. |
Push Notification Support | Push protocol client updates may change subscription management, notification payload format, or delivery acknowledgment requirements. | Mobile wallet teams, SREs managing notification infrastructure | Verify push notification delivery and wake-up behavior on target OS versions. Test background message handling and user opt-in flows against updated server expectations. |
Pairing Lifecycle Logic | Changes to pairing URI format, expiry handling, or reconnection logic can break session establishment or restoration. | Wallet SDK integrators, QA engineers | Test pairing across different transport modes (QR, deep link). Validate session restoration after app restart and network interruption. Confirm backward compatibility with dapps on older Sign Client versions. |
Dependency Upgrades | Bumps to minimum Kotlin, Swift, or Flutter versions, or changes to transitive networking and crypto libraries. | Mobile build engineers, DevOps teams | Audit dependency tree for conflicts with existing app dependencies. Verify compilation against current CI toolchain. Test on minimum supported OS versions declared by the SDK. |
API Deprecation and Removal | Deprecated methods or classes from previous SDK versions may be removed, causing compile-time or runtime failures. | Mobile wallet developers | Scan changelog for deprecation notices. Refactor custom integration code to use replacement APIs. Run full regression suite before deploying updated SDK. |
Session Upgrade Flows | New session upgrade protocol versions may require wallet-side logic to handle upgrade requests from dapps. | Wallet developers, product teams | Implement UI for user consent on session permission changes. Test upgrade flows with dapps using latest Sign Client. Verify session state consistency after upgrade. |
Relay Protocol Compatibility | Changes to WebSocket relay URL, message serialization, or keep-alive behavior may affect connection stability. | Infrastructure teams, SREs | Verify relay URL configuration is updatable without app release. Monitor connection success rate and latency after SDK update. Test failover behavior if relay endpoint is unreachable. |
Release Integration Checklist
A structured checklist for mobile wallet engineering teams to validate a new Web3Wallet SDK release before deploying to production. Each item identifies a critical integration surface, explains the operational risk, and defines the signal that confirms readiness.
What to check: Verify that the new SDK version correctly parses all required and optional session proposal fields (namespaces, required methods, events) and that any custom auto-approve or session rejection logic in the wallet application still functions as expected.
Why it matters: A regression in session proposal parsing can cause the wallet to silently reject all connection attempts or, conversely, auto-approve sessions without proper user consent, creating a security vulnerability.
Readiness signal: A test suite that simulates session proposals from dapps using different WalletConnect v2.0 clients (e.g., Web3Modal, Sign Client) passes without errors. Manual testing confirms the user sees the correct dapp metadata and requested permissions before approval.
Official Resources and Canonical Sources
Use these sources to verify Web3Wallet SDK wallet-side release behavior before planning mobile wallet upgrades. Teams should compare docs, tagged releases, and protocol specs because SDK package names and branding may change over time.
Release Review and Compatibility Evidence
For each Web3Wallet SDK release, keep an internal evidence record linking the official docs, tagged source release, dependency changes, test results, and production rollout decision. Wallet operators should track whether a release changes session persistence, pairing expiry, push notification registration, supported methods, supported chains, or error handling. Chainscore Labs can help teams convert these canonical sources into an upgrade readiness checklist, regression suite, and dapp compatibility matrix for Android, iOS, and Flutter wallet deployments.
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.
Frequently Asked Questions
Common questions from mobile wallet teams managing Web3Wallet SDK releases across Kotlin, Swift, and Flutter. Answers focus on operational impact, upgrade planning, and compatibility validation.
Do not adopt immediately for production builds. Validate against your integration test suite first.
What to check:
- Breaking changes: Review the release notes for API signature changes, removed methods, or new required parameters in session proposal handling.
- Dependency bumps: Confirm the new SDK version does not force an upgrade to a Kotlin, Swift, or Flutter version your team has not yet qualified.
- Pairing regression: Test pairing URI generation and QR scanning flows against the latest dapp-side Web3Modal release to confirm no handshake failures.
- Push notification payload: If the release touches push handling, verify notification delivery and deep-link behavior on both Android and iOS background states.
Why it matters: A breaking change in session proposal parsing can silently reject dapp connection attempts, causing user-facing failures that are hard to debug in production.
Readiness signal: All existing integration tests pass against the new SDK version, and a manual session upgrade flow (v1 to v2 proposal) completes without error.
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.”
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.
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.


