From March 1 to March 14, 2026, the team pushed a mix of practical fixes and steady progress across the ecosystem. Some changes are the kind users will notice right away, like cleaner explorer behavior and updated wallet tooling. Others are quieter but just as important, like tightening spec details to prevent compatibility issues and improving how keys are handled inside VotePeer.
Here’s the rundown, grouped by project.
Specification
- There was a clarification/update in TDPP allowing QR codes to carry data encoded in the base64url format rather than hex. This will allow our QR codes to carry more complex transactions (or the same transactions be carried in smaller, easier to scan, QR codes). This is important because QR codes are limited to under 4KB.
Votepeer / Libvotepeer
-
A new library was created called libvotepeer and the original votepeer deep and middle logic (ring signatures, etc) was moved into this library and ported to Nexa multiplatform from its original BCH Android code base. This initial port will need more work.
-
The Firebase endpoint used to list participating elections was updated. In practical terms, it means the app pulls election lists from the right place and is less likely to break if the old endpoint changes.
-
Early groundwork for macOS and iOS builds was merged. It’s not “done,” but it’s a real step toward supporting more platforms. Desktop (macOS/linux) is done.
-
Key handling was refactored from an “IdentityRepository” approach to a “WalletRepository” approach, which reduces how often private keys get passed around internally. That’s both safer and easier to maintain.
Explorer
-
The explorer now avoids calling the Exbitron API when it doesn’t make sense, like when there’s no token ticker or when you’re on testnet. That cuts down on useless requests and avoids confusing errors.
-
The Exbitron API URL was updated to the latest version so the integration stays compatible going forward.
Nexa core
- Tailstorm work included fixes around parallel validation. In simple terms, this helps the node behave more reliably when it’s validating things at the same time, which matters for stability when the node is under load.
Wally wallet
-
A set of “real world testing” fixes landed that make the app feel smoother and less confusing. Things like removing duplicate internal code, showing a proper message when there’s no transaction history (instead of leaving users staring at nothing), and improving the send flow so the unlock step opens automatically when it’s needed.
-
Handling for a “special transaction” that the user rejects was tightened up. Instead of the app ending up in a weird state, it now returns a clear error response. In practice, this makes cancellations feel clean and predictable.
-
iOS build requirements were updated to stay aligned with Apple’s upcoming App Store submission rules. This is basically future proofing so the app doesn’t get blocked later because it’s using an outdated SDK setup.
-
We were forced to remove the “shopping” section from Android. Reading their TOS it is probably acceptable to have it, but we should have called it “links”. But it is hard to get someone within play to actually give an appeal more than a moment of attention.