This open-source program is probably the most widely used library on Algorand among programs developed by the community, providing benefits to almost everyone, regardless of whether they are developers or users. Even if someone is not an Algorand user, anyone active in the Web3 space likely understands the importance of WalletConnect. Without this library, each dApp project would need to implement wallet connections individually. This would likely cause development costs for each dApp to skyrocket. Moreover, beyond reducing development costs, this library is essential for the Algorand Foundation to promote that blockchain solutions can be easily developed on Algorand, and it also serves as a promotional asset.
This proposal concerns the maintenance of this public good, and it seems that the updates proposed for the period from June 1, 2024, to December 31, 2024, include the following (extracted and summarized from GitHub; please note that there may be inaccuracies):
v3.0.0-beta.8 – v3.0.0-rc.3
Migrated Pera Wallet provider to Pera Connect v2 (breaking change)
Added features: Magic provider, Custom provider, AVM provider
Network switching support, WalletConnect response handling improvements
Updated framework adapters, reactive algodClient support in Vue
v3.0.0
Complete library rewrite (monorepo, TypeScript)
Framework adapters for React, Vue, Solid.js
Network switching and developer tooling improvements
v3.1.0 – v3.2.1
Added reactive algodClient for SolidJS
Fixed Webpack issues and Next.js example
Stability improvements for WalletConnect and internal store
Added CONTRIBUTING.md, updated dependencies
v3.3.0 – v3.4.0
Added new network fnet, resetNetwork option in WalletManager
Fixed Vue app initialization issues
v3.5.0 – v3.7.2
Added logging feature to WalletManager
Added networks: voimain, aramidmain; Biatec Wallet support
WalletConnect v1 session management, removed circular imports, active network chain ID fix
v3.8.0 – v3.10.1
Mnemonic session restoration
WalletConnect backup limited to Defly and Pera
Added Liquid Auth provider
Webpack fallback for wallet dependencies
Fixed KMD empty password handling, added tests
Updated dependencies (pnpm, TypeScript, etc.)
v3.11.0 – v3.11.1
Custom password prompt for KMD/Mnemonic
Prevented WalletConnect v1 session data collisions
v4.0.0-beta.1 – v4.0.0-beta.3
Migrated to algosdk v3.0.0
Added network configuration builder, Defly Web extension wallet, Pera Discover browser auto-connect
It seems to me that xGov grants are precisely intended to cover the development of such public goods. Therefore, I suspect there are very few, if any, who would want to reject this proposal. I myself consider it a highly reasonable proposal.
Now, this leads to a discussion for the future: we need to think about how public goods can be made sustainable over the long term. The xGov program relies on the Algorand Foundation’s funding. The ALGO held by the Foundation is expected to be depleted around 2030. In other words, there is a very high likelihood that resource allocation to public goods through the xGov program will cease. By the time this happens, public goods must be financially self-sufficient, and I believe the xGov program should be designed to transition gradually toward that goal.
Of course, there are other possibilities for strengthening grant funding itself, such as the Algorand Foundation issuing new ALGO or alternatives beyond the supply cap, implementing mechanisms to collect usage fees from users directly for public goods, or having revenue-generating companies or projects within the Algorand ecosystem contribute resources.
The current Use-Wallet proposal is directly related to the maintenance of public goods within this discussion. I would like to have a discussion—including xGov voters and users without voting tickets—about how the costs should be covered through the xGov program, on what schedule, and whether this is appropriate.
