BUIP 215: Nexa Wallet SDK
Submitted by: vgrunner
Sponsor: griffith
Motivation
Nexa currently lacks an easy way to to seamlessly implement basic wallet features in utilities in a web/client-side application architecture without requiring app developers to reimplement wallet functionality themselves in every app. This creates a friction point for developers building applications on Nexa who currently face these challenges when integrating wallet functionalities into their projects.
To make developing dApps on Nexa a lot easier, an SDK should be created to reduce the amount of work developers need to get started deploying their ideas on Nexa.
Additionally, as Nexa continues to grow, there is a demand to improve for seamless and scaleable solutions that align with modern, web3 application architectures.
Objectives
This BUIP proposes that a wallet SDK be built on top of the libnexa-ts library to allow for easier development of Nexa web3 applications that require functions relating to a wallet. This SDK would have an API for wallet and network management, including signing transactions, dApp connecting accounts, utxos management, signing/verifying messages, convenient interaction with rostrum and nexa network, and other wallet and network utilities.
Expected Impact
- Reduce barriers to using a Nexa wallet and wallet utilities in Web3 applications on Nexa
- Speed up development time for Nexa web3 tools and services
- Encourage adoption of Nexa as a blockchain for other web3 projects by reducing technical friction
4 Likes
I’d like to shed a bit more light on the motivation for this BUIP and why this is a piece that’s currently missing.
Developers coming from ETH-like ecosystems are used to working with libraries that handle almost everything — from network/protocol interactions to dApp communication and wallet management — so they can focus on building their apps without worrying about low-level details.
For example, in the EVM world, libraries like ethers.js are widely adopted and used for nearly all web3 development. Most developers don’t need to understand what’s happening behind the scenes because the library abstracts it all away.
While libnexa-ts is a great start, it currently focuses on core/protocol utilities. This is useful for certain apps that don’t require network or wallet management, but we’ve repeatedly seen the same questions and issues come up, and developers end up re-implementing the same basic functionality from scratch (or just copy paste from otoplo wallet).
The goal of a Nexa Wallet SDK would be to build on top of libnexa-ts, libnexa-wasm, and electrum-cash (for Rostrum integration), to provide a complete solution that manages everything — from network interaction to wallet management, and also seamless dApp ↔ wallet communication.
Libnexa-kotlin is a good example of what such an SDK could look like for Kotlin/Java, but developers coming from the ETH space and looking to build frontend apps (or onboard Nexa to their existing apps) need JavaScript/TypeScript tools to integrate these capabilities easily.
I believe this SDK will lower the entry barrier for new developers, speed up development, and ensure consistency and security across Nexa-based apps.
4 Likes
I’m 100% in favour of this BUIP.
This would be a huge step to have this kind of feature to develop ecosystem on Nexa !
Wallets management is really a hard task to implement for me.
Could be great to have a lib that could easily manipulate basics wallet operations.
BEGIN NEXA MESSAGE
BUIP215 vote = YES
BEGIN NEXA SIGNATURE
IM+WIXEUMyIB6LlfTZqBWr2t6svhOeiwzn0ETh4paclZFEOnHR30wx1693G+3771TshxuFIMjftnF2XGU5sUNpU=
END NEXA SIGNATURE
Its unclear to me whether this is intended to be a client side, browser based wallet, or a server side wallet.
I think that client side browser wallets are more insecure than mobile or desktop wallets and we should not encourage them. Instead, we should encourage tight interaction with existing mobile or desktop wallets via TDPP and extensions to the TDPP protocol (if needed).
If its a server side wallet, we already have 2 or maybe 3 choices: Wally enterprise (libnexakotlin) which is running behind niftyart and the faucets, and the full node wallet which runs behind a lot of exchanges.
Building an enterprise class wallet is a lot of work and maintenance. I don’t think that it makes sense to redo all this work just so that the project is all in the same language and running in the same process. I don’t think this BUIP really addresses WHY we need a js wallet. We desperately need to move forward with NEW features, not implement the same stuff repeatedly in multiple languages.
So Instead I think that we should create an XML-RPC or similar interface to Wally Enterprise, launch it as a separate process and have a thin library in js/ts to access it.
Unfortunately I should have checked the BUIPs earlier and opened a discussion to more fully understand the plan before voting time. But I’m going to vote no to this now with the idea that we could explore the options and if it really does make sense to build an enterprise-quality wallet in javascript then we can open another BUIP in the next go around, or actually, since this BUIP doesn’t suggest a budget, just add it to the dev todo list.
This BUIP is not about building a wallet. It about building a wallet SDK that handles network interactions, management, and wallet to app communications. It is primarily intended for the dApp side of development.
If we use the pixel wars game by ImGettingHolds as an example. On testnet it is free but on mainnet a user must pay via a nexa transaction to colour a pixel. To build his game he had to implement all of the wallet related logic himself or copy it from otoplo. This wallet SDK would handle wallet stuff for him. such as the network interaction and dApp ↔ wallet communication for him allowing him to spend that time working on the game logic rather than the nexa logic.