WalletConnect Plugins


Just had a great discussion with Yu Pan from Origin Protocol and we talked through their own implementation for mobile-to-desktop communication between their Dapp and Mobile Wallet.

Both WalletConnect and Origin Bridges are way similar than we originally thought as there was a misunderstanding of the use of OrbitDB being part of their remote communication.

Origin uses OrbitDB as mean of communication for direct messaging within their marketplace platform. Their Bridge Server implementation works similarly to WalletConnect using a centralized database to relay messages between the Dapp and the Wallet.

What we ended up discussing further was that Origin’s Bridge Server actually has an extra layer of transaction verification which verifies the transaction requests using their smart contract ABI which also allow them to push more customizable push notifications.

This of course is a significant difference to WalletConnect’s implementation where we only relay encrypted payloads through the Bridge therefore only allowing us to push generic notifications on mobile.

Origin’s wallet also verifies the transactions as well but their user-friendly approach with a more trusted Bridge setup provides more user-friendly and contextual push notifications.

Which brings us to the Bridge Plugins proposal. Is there room to allow WalletConnect Bridges to be expandable through plugins that would allow an implementation similar to Origin Protocol where you could verify transaction requests and customize push notifications.

My proposal is that we would provide the flexibility for Dapps to run their own trusted Bridges with extra functionality that would allow them to provide more customizable user experiences.

This would be an opt-in system that wouldn’t require other Bridges to implement. The first request to the Bridge when requesting a new sessionId could provides a set of plugins that could be used on top of the WalletConnect connection.

This could be an array of endpoints with a provided schema to trigger extra features that the trusted Bridge would provide, as for example Customizable Push Notification could receive transaction data to be parsed and verified against the Dapp’s smart contract ABI to push more specific push notifications.

Let me know what you guys think of this proposal. All feedback is welcome!


So after a very thorough discussion with Michael Sena from uPort, we expanded on the topic of collaborating and merging efforts with uPort Connect. I learned about 3Box which is an awesome project also using OrbitDB to store both private and public information which they are currently using for their attestations for uPort Identity.

The key differences between WalletConnect and uPort Connect are firstly, the Dapp registration on-chain which currently is not supported on WalletConnect but soon to be part of the specification using a similar implementation with @alexander.mangel Address Metadata Registry

Secondly, WalletConnect only supports Web3 methods (‘eth_accounts’, ‘eth_sendTransaction’, ‘eth_sendRawTransaction’, ‘eth_signTypedData’, ‘eth_sign’) yet uPort has extra functionality for relaying attestions to be signed and published using 3Box.

This would make a second use-case for building a more modular system with WalletConnect to support external plugins to expand the communcation range. My main concern, would be if this would provide some friction to the user experience to have prior knowledge of the Wallet support for these extra features from their wallet provider. Contrary the Bridge server plugins, this would actually affect the range of supported wallets that actually are WalletConnect-enabled.

Maybe it could be solved with extra handshake step to verify the wallet support for these features but I’m concerned this would hurt the user experience for WalletConnect users that were promised full compatibility with all Dapps and Wallets using the standard.

I would love to see if something like EIP-1024 encrypt/decrypt web3 methods could help with these features in order to provide full compatibility with uPort Connect existing implementation.