WalletConnect Sign requests are transported over the WalletConnect Network, which relays all the messages exchanged by the clients in the ecosystem. First, clients exchange keys with the Diffie-Hellman protocol to provide end-to-end encryption. Later, symmetrically encrypted messages are sent together with matching MAC(Message Authentication Code) to grant message authenticity and data integrity.

If you are not familiar with those concepts, you can think of MACs as seals on envelopes. You trust the letter in the envelope has not been modified until the seal is broken or doesn’t match the sender. The image below should give you a grasp of what a Diffie-Hellman key exchange is:

Swift Client

In a standard WalletConnect Sign communication, you can distinguish two different types of clients:

1. The proposer client which generates the pairing URI and usually presents it in the form of a QR code. This client will propose a session — usually a dapp.

2. The responder client which scans the QR code or opens the deep link and approves the pairing and sessions — usually a wallet.

The Swift WalletConnect Sign SDK can be consumed by native dapps, wallets, and proxy applications.

Let’s configure WalletConnect Sign instance:

let metadata = AppMetadata(name: <String>,
description: <String>,
url: <String>,
icons: <[String]>)Sign.configure(Sign.Config(metadata: <AppMetadata>, projectId: <String>))

1. metadata — describes your application and will define pairing appearance in a web browser.

2. projectId- is a parameter used to access the WalletConnect Network. Go to walletconnect.com to generate one.

3. socketConnectionType — .automatic by default. Your client’s web socket connection will be controlled automatically by the SDK, but if you want to have control over the socket connection, you can set it to .manual

After the client is configured, you can access it by `Sign.instance`. Signs instance exposes Combine publishers so you can set one or multiple subscribers to it. Publishers will call the receive(subscription:) method on all subscribers to inform your app of incoming events.

Pair the clients

You probably started wondering what a pairing is. So, this is a particular type of object that allows you to keep encrypted communication between a web browser and a wallet. You will use it to establish sessions for further communication between dapps and your wallet. That means that users don’t have to scan QR codes over and over again. Instead, they will initiate new sessions with just a single button tap. If you had an experience with WalletConnect v1.0, I am sure you feel this is an enormous UX improvement.

Ok, so we already have our Sign instance configures, and we know what a pairing is. So let’s establish one. First, you need a pairing URI, which the dapp can generate and display as a QR code. It contains necessary information required to initialize communication like the proposer’s public key or topic by which your client will know where to publish and subscribe for events of your interest.

once you have a pairing URI, you can call:

try await Sign.instance.pair(uri: uri)

Under the hood, clients settle the pairing that will live for 30 days by default and will expire after on both peers. Keep in mind that even though pairing has an important role, you do not necessarily need to list active pairings to the wallet user, as they will be more interested in sessions.

Establish a Session

Optimistically after clients settle the pairing, the dapp will propose a session with Proposal Namespaces. A session proposal is a handshake sent by a dapp, and its purpose is to define session rules. The handshake procedure is described by CAIP-25. Session.Proposal object conveys a set of required ProposalNamespaces that contains required blockchains, methods, and events. Dapp requests with methods and wallet will emit events defined in namespaces.

The user will either approve the session proposal (with session namespaces) or reject it.

Note that accounts included in the namespace body should follow CAIP10 specifications and be prefixed with a chain identifier. You can find more on blockchain identifiers in CAIP2.

in order to receive a proposal, subscribe on:

public var sessionProposalPublisher: AnyPublisher< Session.Proposal, Never>

Sign.instance.sessionProposalPublisher
   .receive(on: DispatchQueue.main)
   .sink { [weak self] sessionProposal in
   // present proposal to the user
}.store(in: &publishers)

Present proposal to the user, and when the user approves dapp’s proposal, call approve function :

Sign.instance.approve(proposalId: proposal_id, namespaces: [String: SessionNamespace])

A secure communication channel for sending payloads between wallets and dapps is provided by sessions. In WalletConnect Sign v2.0 protocol there is a significant improvement in session management. Each Session has a defined expiry date whose primary purpose is to eliminate scenarios where one of the clients is not communicating the session deletion, and its peer keeps the Session alive. By default, sessions will live for a week and then expire. But if you consider it should stay alive as the user is actively utilizing it, you can call extend function that will extend a session to the next seven days.

try await Sign.instance.extend(topic: session.topic)

Talk to your peer

We already have a pairing and a session so we can begin communicating with our peer. WalletConnect Sign protocol has a special method for doing this: wc_sessionRequest. Dapp will use it to request the wallet for transactions or messages to sign.

Requests will be delivered by the following publisher.

Sign.instance.sessionRequestPublisher
   .receive(on: DispatchQueue.main)
   .sink { [weak self] sessionRequest in
   // present session request to the user
}.store(in: &publishers)

and one can simply respond for a request with either result or an error:

let result = sign(request: sessionRequest) // implement your signing methodlet response = JSONRPCResponse<AnyCodable>(id: sessionRequest.id, result: result)Sign.instance.respond(topic: sessionRequest.topic, response: .response(response))

There are a lot of JSON RPC methods used by the Ethereum community already, and there is more to be introduced not only to Ethereum but to other blockchains as well. We wanted the WalletConnect Sign protocol to be chain agnostic and allow wallet holders to sign transactions for any chain, but we also wanted WalletConnect to stay flexible for future methods that can either be proposed by the community or be just your project’s specific method. In order to allow it in the WalletConnect Sign v. 2.0 protocol, we’ve introduced an AnyCodable type. You can wrap any type in it and send it over the network. When the request or response is received, the expected type can be easily derived from parameters or a result:

sessionRequest.params.get([EthereumTransaction].self)

What’s next?

It is important to mention that our SDK is still in its beta phase, but I am sure it is the right time to begin integration with your project. To learn more about the protocol, check out our documentation, GitHub, and join our discord server to be a part of our community. You may also like to try our example apps that are part of our repo.

We are happy to announce today that we have raised a 11M Series A funding round co-led by USV and 1kx to scale wallet interoperability and develop a generalized messaging layer. This is followed by a 1.25M Seed funding round also led by 1kx early last year that helped us build our founding team.

WalletConnect started in 2018 with the mission of connecting as many wallets to Ethereum applications as possible. Since then we’ve integrated with over 100 wallets and more than 200 applications including Twitter, which has since added support for NFT authenticated profile pictures.

More importantly, our traffic has been exploding in the last two years and demand is accelerating beyond Ethereum. This is why our v2.0 remote signer protocol, currently in beta, is delivering much-awaited multi-chain support for Cosmos, Polkadot, Solana, etc.

Web3 isn’t complete without the three pillars of decentralized infrastructure: blockchain, messaging and storage. We are now taking WalletConnect to the next stage by focusing on becoming the decentralized Web3 messaging layer.

To achieve this goal we are going to be introducing two new protocols for Wallets to be interoperable with Web3 applications.

• First, we are building a direct messaging protocol that will allow WalletConnect wallets to message each other.

• Second, we are currently researching a push notification protocol to allow apps to notify users of both off-chain and on-chain events.

All of these protocols are backed by the WalletConnect messaging layer that we are actively scaling and improving which is also optimized to share bandwidth for wallet users even with the most resource constrained mobile devices

Our mission continues to expand the interoperability of the Web3 space by providing the best tooling and infrastructure for Wallets to deliver outstanding user experience.

This multi-protocol messaging network is being developed as we speak and with the support of this Series A funding round we can expand our resources to bring it to reality for millions of developers building apps and wallets in Web3.

We would love to thank our investors USV, 1kx, Semantic, A Capital, Coinbase Ventures, Buckley Ventures, Zerion, Alex Svanevik, Eric Conner, Vadim Koleoshkin, Arjun Bhuptani, Joel Thorstensson, Matias Woloski, Scott Moore, Spencer Yang, Han Hua, Jin Chung, Mike Demarais, Christian Baroni, Bruno Barbieri, Alexander Salnikov, Viktor Bunin, Mara Schmiedt, Wayne Chang, Gregory Rocco, Anna Rose, Ajit Tripathi and Alex Harley for supporting our mission to improve interoperability in Web3 with WalletConnect.

If you would like to join our team to participate in our mission, check out what job postings we have available here.

The WalletConnect ecosystem has grown so rapidly in the last year that we have struggled to keep up with every new integration. Our open-source app registry continues to accumulate more and more submissions but we don’t have enough bandwidth to review all of them.

Introducing the new App Registry submission available on WalletConnect Cloud!

Our new submission form for the WalletConnect Cloud Registry can be easily accessed from your WalletConnect Cloud account, instead of submitting a Github issue on our repository which can take months to review. We now have a much faster process to review submissions that are included into our Registry API.

On your dashboard you will be able to track draft, pending, rejected and approved submissions. Another benefit of the cloud registry is that authors can easily update their listing. Need to update a deep link? No problem!

If you would like to edit or claim an existing registry item, email us at support@walletconnect.com to help migrate the listing to your account.

Additionally we have outlined clear guidelines for registry submissions that will be used for our review process so make sure to read them here before submitting.

Our new App Registry will serve the homepage listing of Dapps and Wallets that support WalletConnect protocol just like before and also serve the SDK Modal used for mobile linking currently present on Dapps.

The Registry API will still be served through the same endpoints and they will be backwards-compatible so no changes are required if you are fetching the latest registry file.

We are planning to extend features for our App Registry now that it has been incorporated into WalletConnect Cloud. In the future, you will be able to assign projectIds in your account to registry submissions.

Go to walletconnect.com and try out our new submission form.

It’s beginning to look a lot like Christmas so we have prepared a special gift for our community. We have released the first v2.0 Beta for both Swift and Kotlin SDKs supporting iOS and Android platforms, respectively.

In July we announced new WalletConnect v2.0 protocol and released our first beta for Javascript SDK. Later in October, we released WalletConnect Cloud where projects can register themselves to get a projectId to access our new infrastructure for v2.0 protocol. Around that time we also teased on Twitter that Swift and Kotlin SDKs had been able to connect with the JavasScript SDK for the first time and this week we finally announce that the mobile SDKs are now ready for Beta testing.

It’s been an outstanding journey for the whole WalletConnect team coordinating client development for the new protocol across three different platforms and we made sure that we provided the best developer experience across the board. You can now test WalletConnect v2.0 protocol for Browser, Desktop and React-Native apps with the Javascript SDK, for iOS apps with Swift SDK and for Android apps with Kotlin SDK.

These new SDKs implement the full protocol and are interoperable between each other as per the WalletConnect v2.0 specification described on our documentation. We are inviting all projects to integrate with these new mobile SDKs and provide us as much feedback as possible so that we can push v2.0 adoption even forward.

We have prepared beginner guides for both Swift and Kotlin SDKs to get you started integrating WalletConnect v2.0 protocol in your wallet:

Swift: https://medium.com/walletconnect/beginner-guide-to-walletconnect-v2-0-for-swift-developers-4534b0975218

Kotlin: https://medium.com/walletconnect/beginner-guide-to-walletconnect-v2-0-for-android-developers-fd0fd3d9ec5f

If you haven’t registered on WalletConnect Cloud go to walletconnect.com to get your projectId today. WalletConnect v2.0 is ready today! 📲

If you follow WalletConnect or me on Twitter, you would’ve seen plenty of teasers on different features and properties of the v2.0 protocol. In this article we will break down every single one of them and the key differences from the previous v1.0 protocol.

The user experience will remain exactly the same yet the new protocol will break interoperability but for very good reasons. Here are the main features of WalletConnect v2.0 protocol introduces:

• Chain Agnostic Interface

• Multi-Chain Support

• Pairing & Session Separation

• JSON-RPC Permissions

• Improved Session Management

• Decentralized Message Relaying

Chain Agnostic Interface

An often discussed, requested and misunderstood topic has been WalletConnect’s support for multiple blockchains. WalletConnect is first and foremost an encrypted communication protocol that only cares about two parties coming to agreement over a session.

However when v1.0 was released it made the assumption that both parties were communicating about any EVM-compatible chain thanks to chainId specified by EIP-155 standard but this meant that other blockchains like Cosmos and Polkadot would be incompatible given that their chains are not identifiable by the same standard.

Hence came the initiative back in 2019 to start CAIPs (Chain Agnostic Improvement Proposals) to provide a common ground for multi-chain applications. These standardize interfaces across different blockchain ecosystems which may not share tooling and infrastructure. CAIPs were developed together with projects on Ethereum, Cosmos, Polkadot, Solana, Near, Filecoin, etc.

Thanks to these newly defined standards that we developed in CAIPs WalletConnect v2.0 was able to expand its support very easily to be chain agnostic. Below you can find some examples of how accounts are specified for different chains.

# Ethereum mainnet
eip155:1:0xab16a96d359ec26a11e2c2b3d8f8b8942d5bfcdb
​
# Bitcoin mainnet
bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6
​
# Cosmos Hub
cosmos:cosmoshub-4:cosmos1t2uflqwqe0fsj0shcfkrvpukewcw40yjj6hdc0
​
# Kusama network
polkadot:b0a8d493285c2df73290dfb7e61f870f:5hmuyxw9xdgbpptgypokw4thfyoe3ryenebr381z9iaegmfy

Multi-Chain Support

Another drawback of v1.0 is that, just like other current tooling in this space, support for an application to connect to multiple chains simultaneously was missing. It has become normalized that a connection between an app and a wallet assumes a single active chain.

Simultaneous chain connections were long considered on CAIPs discussions prior to WalletConnect v2.0 development which is defined both by the account addresses to be suffixed by the chain identifier and also by the JSON-RPC standard to invoke requests with a target chain.

Thus, this new feature would enable a future where apps can interface with wallets on multiple chains without requiring any synchronization to switch context either automatically by the wallet or the user themselves.

Pairing & Session Separation

Sometimes you need to push forward imperfect solutions to then iterate on problems that your earlier self wasn’t able to predict, for example, a major bottleneck was that WalletConnect v1.0 required a user to scan a QR Code or use a deep link every time they wanted to connect to a new application from their wallet.

Fortunately this is not the case with the v2.0 protocol where pairing and session have been decoupled. The app using the WalletConnect protocol will cache previously paired wallets which it can use to send new session proposals without pairing all over again. This relationship of a pairing will of course not be shared between wallets but it can be shared between applications in the same browser through an iframe.

The most important consideration for the development of this feature was that the pairing is essentially a relationship between clients while sessions are a relationship between app and wallet. Understanding the platform where the client is run is what will constrain the re-use of pairings to propose new sessions between two clients.

JSON-RPC Permissions

The first challenge created by introducing chain agnostic interfaces were the incompatibilities between apps and wallets regarding the JSON-RPC API methods being used in a session. While it solved v1.0 protocol’s assumption that both were using the Ethereum JSON-RPC API it meant they also needed to communicate the API being used. Therefore in v2.0 protocol you are required to specify the JSON-RPC methods upfront when proposing a session. Since the issue being tackled was API compatibility, it was very easy to describe which methods are to be used before session settlement thus it would also need to be approved by the wallet when connecting to an app.

JSON-RPC permissions basically serve two purposes, before and after session settlement. Before session settlement, they describe the API requirements of the app in order for the session to proceed without any errors. That way, the wallet is able to parse if it will be able to support all methods, but also if it approves the use of these methods by the app. After session settlement, the clients will be able to filter out any JSON-RPC requests used on either side which are incompatible with the described set of methods for the session.

A great example of this feature in today’s Ethereum applications supporting WalletConnect is when an experimental method like signing typed data (eth_signTypedData) is required by the app but unsupported by the wallet. In this context, these permissions provide an amazing mechanism to detect support without requiring maintenance of a registry for which wallets support new API methods.

Improved Session Management

Session management has probably been one of the most overlooked aspects of the v1.0 protocol and I personally find to be the biggest game changer for the v2.0 protocol. While it may not be as attractive as multi-chain support for many developers the underlying management of the sessions on the client will be dramatically improved in two areas: explicit expiries and request history.

Explicit expiries simply means that session proposals include a Time to Live (TTL) which is by default set to one week but can be changed as the expiry is calculated on the wallet side after settlement which is then communicated back to the app. This eliminates the current scenario where either apps or wallets manage sessions indefinitely due to one of the parties not communicating its termination. Additionally a mechanism to ping is also included to evaluate if the peer client is currently online or not. While WalletConnect does not require parties to be online for the whole duration of the session, it’s useful for apps to understand whether the wallet is immediately available to sign a request.

Request history is probably the only feature which was never asked before because the v1.0 delegated this responsibility to the server. For v2.0 protocol all clients will have a record of all the JSON-RPC requests made during a session and also which ones have already been responded. This enables a client to protect itself from receiving duplicate requests and track pending requests that need to be responded.

Decentralized Message Relaying

Perhaps unknown by many but v1.0 protocol was initially designed to be used on the Whisper network. However it was more important at the time that the protocol was adopted by as many applications possible so it was implemented that messages are relayed through a centralized server that mimics a pub-sub architecture like Whisper. Three years later, with Whisper did not survive the test of time but a replacement protocol emerged called Waku. So now that WalletConnect is much better positioned to adopt a decentralized message relay network as its primary transport for messages.

WalletConnect v2.0 uses Waku 2.0 by default to relay messages in a decentralized manner which removes the previous requirement of two clients being connected to the same server. In fact, WalletConnect 2.0 does not even require clients to be connected to a server at all since Waku 2.0 is built on top of libp2p, and therefore it can relay messages client-side like a browser and propagate them through the network to reach the peer client.

That being said we are still going to provide public proxy servers to the Waku network to ensure a smooth transition for developers to adopt v2.0 and also to guarantee the lowest latency and uptime possible perserving this way the same user experience under different network conditions.

What’s next for WalletConnect 2.0?

Currently we are publishing all open-source code for Javascript clients compatible for browsers, node.js and react-native and we have started to onboard multiple projects to beta testing it in production.

The development of Swift and Kotlin clients for the iOS and Android platforms is currently in Alpha stage and we expect to make available stable Beta releases for projects to integrate by January 2022.

Currently we already published a provider for Ethereum and will subsequently release providers for other blockchains starting with Cosmos and Polkadot then followed by Solana and Near.

Our goal will always be to provide the best developer experience, so that applications can offer the best user experience in blockchain. There will be releasing more SDKs in the future and offer more infrastructure services that allow apps to integrate seamlessly with wallets.

Want to learn more?

Check out our documentation and join our Discord to be part of our community.

We have a new website, a new domain, and a brand-new infrastructure, including a developer dashboard with WalletConnect Cloud for our new v2.0 protocol. You can register an api key for free today.

Three months ago, we announced our new v2.0 protocol, which brings to life numerous new features and improvements that many projects have been requesting. Most importantly, v2.0 is designed to be both chain-agnostic and support multi-chain to embrace the latest development with blockchain application and wallets.

WalletConnect v2.0 is the result of almost three years of production use of our protocol to connect hundreds of applications and wallets together in the most universal and interoperable way possible.

To this date, beta testers have already gotten access to our Javascript SDK and reported great feedback, allowing us to improve even further before making the first stable release. Both Swift and Kotlin SDKs are getting very close to their first alpha releases and will be ready in the upcoming weeks for wallets to support it on both iOS and Android.

To provide the best service with the highest reliability and performance, we are launching our WalletConnect Cloud. Any developer or project can easily register an account to generate api keys to use our new infrastructure.

WalletConnect Cloud aggregates years of experience running infrastructure for WalletConnect to ensure that apps can guarantee the best service even during the most demanding peak times.

WalletConnect v2.0, just like the previous version, can run on self-hosted infrastructure and does not require projects to run on our Cloud. In addition, since the new protocol uses Waku decentralized messaging, we can relay messaging between self-hosted and cloud-hosted servers.

We introduced api keys to ensure we can provide the best service possible, but the service stays free as it did for the previous version. Soon, we will be rolling out new features, products, and services for our Cloud services that will allow developers to focus on building the best wallets and dapps possible.

WalletConnect’s goal is to provide the best suite of tools for Web3 development. With our new .com domain and website, we will focus on improving both the developer and user experience for blockchain.

WalletConnect v1.0 infrastructure will still be available until v2.0 surpasses it in adoption. When this happens, we will start a 6-month sunset for the v1.0 infrastructure.

Today, we invite everyone to register with WalletConnect Cloud and start reading the documentation for our v2.0 protocol. Then, follow our blog posts for more technical deep-dives into how v2.0 protocol works.

Visit walletconnect.com and register today!