Luke
New Pivian
Proposal Details:
- Name: Luke (Q4 2026)
- Term: 3 Cycles
- Cycle Amount: 45,000 PIV
- Total Amount: 135,000 PIV
- Author: Luke
- Receiver: Luke
- Address: DRCftD2Xqmoud7x5EdhnBnMjof5qfE4rEn
- Created: 10-13-2026
- Status: Active
- Vote Hash: 15f0bdb0522f3396a0c2c1a344bbb01ec42be222f94997d6b2262485e76ead41
Role and Introduction
I'm Luke, a backend developer working across the PIVX ecosystem. Last quarter I moved the majority of my time back to PIVX Core and the wallet code that sits on top of it, while keeping the PIVX Labs platforms running. Most of that went into standing up and running the testnet6 network with Liquid, and into public PIVX infrastructure at computingcache.com/pivx (https://computingcache.com/pivx): explorers, a faucet, a public node API, and a hosted testnet wallet. This quarter continues that direction: move v6 forward by reviewing PIVX Core v6 PRs, keep reviewing MyPIVXWallet PRs, and keep Labs infrastructure healthy.
Q3 2026 Accomplishments:
PIVX Core and testnet6
- Worked with Liquid to stand up the testnet6 network: set up multiple servers running a large fleet of testnet nodes, and I'm maintaining a large part of that infrastructure on an ongoing basis. Liquid's Pivx-ansible playbooks (https://github.com/Liquid369/pivx-ansible) handle provisioning the nodes.
- Built out PIVX community infrastructure at computingcache.com/pivx (https://computingcache.com/pivx), all free, no account needed.
- Testnet explorer (https://computingcache.com/pivx/testnet/explorer/) for testnet6, so testers can check what their code actually broadcasts.
- Testnet faucet (https://computingcache.com/pivx/testnet/faucet/) that hands out tPIV with a per-address cooldown, so a script can't drain it. Its wallet stakes what it holds, so it refills itself.
- Mainnet explorer (https://computingcache.com/pivx/explorer/) with blocks, transactions, addresses, masternodes, governance, and analytics, built on Liquid's RustyBlox and indexing from my own full node. It uses the Blockbook v2 API, so existing wallets and scripts can switch to it by changing the host.
- Public node API on mainnet and testnet (/pivx/rpc/mainnet, /pivx/rpc/testnet) in the format MyPIVXWallet expects, rate limited and with no reachable wallet, for light wallets that don't run their own node.
- Rewards calculator (https://computingcache.com/pivx/calculator) showing what staking or a masternode pays on live network figures, plus an inflation calculator.
If the community would rather run any of this under another domain, I'm happy to do that. ComputingCache is just a domain I control, which makes it quick to push out updates and work with things while developing.
- Reviewed and approved PIVX#2982 (https://github.com/PIVX-Project/PIVX/pull/2982), which restarted testnet as testnet6 with a fresh genesis, a new spork key, and v6.0 activating at block 5000. Merged August 20.
- Reviewed PIVX#2984 (https://github.com/PIVX-Project/PIVX/pull/2984), which moves testnet chainlocks to a 20 member quorum so a single offline masternode can no longer kill a DKG session on the testnet fleet. Merged October 9.
- Worked through the open v6 PRs to get familiar enough with them to review properly, and worked with Liquid to confirm what order they should be merged in. This doesn't show up on GitHub, but it's the groundwork that lets reviews move more quickly this quarter.
MyPIVXWallet (MPW) reviews and fixes
- Reviewed and tested the MPW v3.0.0 release bump, MPW#627 (https://github.com/PIVX-Labs/MyPIVXWallet/pull/627), confirming the changelog matches what actually merged.
- Found and responsibly disclosed a security issue where seed phrases could be saved into browser autofill and form history on wallet import. Sent the fix as MPW#628 (https://github.com/PIVX-Labs/MyPIVXWallet/pull/628), which masks the secret input and disables autofill on wallet inputs.
- Did a full security review of the PIVX Name Service (PiNS) PR, MPW#630 (https://github.com/PIVX-Labs/MyPIVXWallet/pull/630), across two rounds. Confirmed the cryptographic proof checks hold up, then found a blocking bug: a malicious or compromised name indexer could run JavaScript inside the wallet through an error message, without ever touching the proof checks. Proved it end-to-end in a real browser, proved the fix closes it, and found five smaller issues alongside it. The author reworked the design in response, and my second round verified every fix.
Pivx-Wallet-Kit (the Rust/WASM engine under MPW and other PIVX wallets)
- Wallet-kit#1 (https://github.com/PIVX-Labs/pivx-wallet-kit/pull/1): Fixed a bug where the published npm package hung forever on every shielded send in the browser, and added a CI gate so it can't ship again.
- Wallet-kit#2 (https://github.com/PIVX-Labs/pivx-wallet-kit/pull/2): Made multi-recipient transparent and shielded sends, plus four pre-existing bugs found while building it (address validation, UTXO deduplication, block replay safety, shield memo length). 118 tests. Approved by Liquid.
- Wallet-kit#3 (https://github.com/PIVX-Labs/pivx-wallet-kit/pull/3): Cold staking support (delegate, withdraw, partial withdraw that keeps the rest staking, stake splitting) and crate-wide dust handling. 181 tests. Opened early because a user was waiting to test it.
- Verified all three on mainnet with real funds: eleven transactions, including a 1,000 PIV delegation split into two 500 PIV pieces and a partial withdrawal that kept the remainder staked.
- Reviewed Pivx-Agent-Kit (the AI agent wallet) for exposure to the same bugs. It's on an earlier Wallet-Kit version that predates four of the fixes, including address checksum validation, so moving it to the current version picks up all four with no code changes.
- Started backporting six more PIVX fixes found while building Multi-Wallet-Kit, below (shielded tree corruption from duplicate transactions, two input-validation hardening fixes, two fee calculation fixes, and a broken WASM doc build).
Continued maintenance
- PIVCards, Labs Oracle, and node systems kept online and maintained through the quarter, with issues handled as they came up.
- Handled PIVCards support tickets from users.
- Fixed a PIVCards bug where the whole site showed up as a blank white page on Safari on the iPhone 15. That version of Safari didn't support some of our frontend code, and there were no fallbacks in place, so the page failed to render at all. Added the fallbacks so it loads properly on that version of Safari.
Carried over from Q3, now live: MPW on the v6 testnet. Last quarter I committed to validating MPW against the v6 testnet. Between v6 not being far enough along for wallet testing to mean anything and time constraints, it got pushed back slightly into the start of Q4. The testnet wallet is now live:
- Testnet wallet (https://computingcache.com/pivx/testnet/wallet/): a hosted build of MyPIVXWallet pointed at testnet6, so anyone can try the wallet against v6 rules without building it. It runs on the testnet explorer and node API above, and it's testnet only: it can't switch to mainnet or touch real PIV.
- MPW couldn't run on testnet6 out of the box, which is expected, and getting it there surfaced four things to fix: shielded balances loading from leftover testnet5 data, shield sync starting at a mainnet block height on every network, an endless resync on a chain with no shielded transactions yet (so the first one could never be made), and history sync not working against RustyBlox explorers because of a paging difference from Blockbook. The hosted build carries fixes for all four, and they go upstream to MPW this quarter where they're needed.
- Tested end to end on testnet6: a new wallet funded from the faucet synced its history and shielded coins in about 10 seconds. That was the first shielded transaction on testnet6 made through MPW, and it confirmed the public node indexes shield data correctly.
- Running the explorers against MPW also showed two places where RustyBlox can match Blockbook more closely (testnet address formatting and paging). I'm going to reach out to Liquid and see if this is something we want to push upstream to make it more of a drop-in replacement for Blockbook.
Beyond the proposal
These weren't part of what the treasury funded. They're things I built on my own time and my own infrastructure, and I'm listing them because they add to the PIVX ecosystem.
- ComputingCache Game Hosting accepts PIVX. I built a game server hosting service (Minecraft, Terraria, Valheim, Vintage Story and more) at gamehosting.computingcache.com (https://gamehosting.computingcache.com), paid with self-custodial crypto through a self-hosted BTCPay Server. PIVX is a payment option at checkout alongside Bitcoin, with its own wallet connection and exchange-rate pricing. The service has just launched and is live and accepting paid orders.
- Multi Wallet Kit (https://github.com/Luke-Larsen/pivx-multi-wallet-kit). A multichain fork of Pivx-Wallet-Kit that adds Litecoin and Dogecoin to the same library and the same seed, with PIVX keeping its full feature set, including sapling shielding and cold staking. Litecoin supports paying modern bech32 and P2SH addresses, so it can pay exchanges. Building it meant a full security pass over the shared code, and that pass turned up issues in the original Pivx-Wallet-Kit: those are the six PIVX fixes now being backported upstream.
Q4 2026 Focus
1. Move v6 Core forward
- Keep testnet6, its node servers, and the computingcache.com/pivx services (explorers, faucet, testnet wallet, public node API) running, and work with Liquid on the issues the network turns up.
- Review, test, and help land open v6 PRs (my main focus for reviews this quarter.)
- Triage, reproduce, and fix bugs found on testnet.
2. MPW on the v6 testnet
- Finish testing the hosted testnet wallet against v6 rules: unshielding, shielded-to-shielded sends, cold staking, masternodes, and governance, and report or fix what breaks.
- Offer the four MPW fixes from the testnet build upstream where they're needed, and talk with Liquid about the RustyBlox changes.
- Keep the testnet wallet updated as v6 and MPW change.
3. Review Core, MPW, then other pull requests
Everyone working on PIVX is stretched for time and resources right now, and reviews are one of the places that shows. I'm putting considerably more of my time into reviews this quarter to help things move faster.
- Review incoming PRs with the same depth as PiNS: read the code, run it, and test it on testnet6 where it applies.
- Get my own open PRs (wallet-kit #1 to #3, MPW #628) through review and merged, and land the six wallet-kit backports.
- If time allows I would also like to look into and set up some systems to display and update everyone on development progress, this most likely means a restarting of the reporting system we had at Pivx Labs, but I have been taking
suggestions and plotting out some of the best ideas that make it easy for devs to do and is clear for users/masternode operators. This forum post discusses some points (https://forum.pivx.org/threads/roadmaps-core-updates-and-building-market-momentum.3031/).
I have also had conversations in telegram about this.
4. Maintain PIVX Labs infrastructure
PIVCards, Labs Oracle, node systems, and the supporting servers stay online, patched, and monitored, and PIVCards support tickets keep getting answered.
5. Respond to issues as they come up
Outages, provider changes, broken integrations, and user reports get handled when they happen, as they have every quarter.
Why this work is good for PIVX
This is a new section that I heard some people in the community wanted. I haven't done this before, and if anyone has suggestions about ways to clean this up or what is or isn't needed, I want to hear them.
What was done last quarter:
- Testnet6 infrastructure, explorer, and faucet. V6 can't ship until it's been run on a real network, and a test network is only useful if it's big enough to behave like the real one and easy for people to join. Running a large node fleet means v6 gets tested under realistic conditions like quorums, chainlocks, and nodes dropping out. The explorer and faucet mean anyone can join in and test without needing a developer to send them coins or check transactions for them.
- Mainnet explorer and public node. Light wallets like MPW don't run a node of their own, so they depend on someone else's. When only a handful of people run those services, one outage takes wallets down with it, and a few operators can see everyone's queries. Each independent explorer and node makes PIVX harder to knock over and less dependent on any single operator. Because the explorer uses the standard Blockbook API, wallets and services can use it as a drop-in backup with no code changes.
- Rewards calculator. It gives people a straight answer to "what does staking or running a masternode actually earn me?", which is one of the first questions a new holder asks and one of the main reasons to hold PIV.
- Testnet6 reviews and v6 PR groundwork. A clean testnet with a quorum that doesn't fall over when one node goes offline means testers spend their time finding real v6 bugs instead of fighting a broken test network. Knowing the open v6 PRs and agreeing on a merge order ahead of time means v6 lands in a sensible sequence instead of in conflicting pieces.
- MPW v3 review. MPW is how a lot of people hold PIV. A second set of eyes on each release lowers the chance of shipping something broken to them.
- Seed autofill fix. A seed phrase is the whole wallet. If a browser quietly saves it, anyone with access to that browser, or anything that syncs its form data, can take the funds. Closing that protects every MPW user who imports a wallet.
- PiNS review. Name services make PIV easier to send ("send to Luke.pivx" instead of a long address), which is good for adoption, but only if they can't be turned against the user. The bug I found would have let an outside server run code inside people's wallets. Catching it before merge means PIVX gets the feature without the risk.
- Wallet-kit fixes. The shielded send hang meant any app using the published package simply couldn't do private sends, which is one of PIVX's main features. Multi-recipient sends make PIVX cheaper and simpler for anyone paying several people at once, like pools, payroll, or exchanges.
- Cold staking in wallet-kit. Cold staking lets people stake without leaving their coins in a hot, always-online wallet. Bringing it to the shared wallet engine means more wallets can offer safe staking, which supports network security and gives holders a reason to keep PIV.
- Mainnet verification. Testing with real funds on the live network is what tells us the code actually works, not just that the tests pass.
- Agent-kit review. AI agents send payments with no human checking the address. Missing address validation there means a single wrong character can send funds to an address nobody controls. Finding that before agent payments see real use protects PIVX's reputation in a space it's trying to lead in.
- PIVCards support and device fixes. PIVCards is one of the most direct ways people turn PIV into something they can use day to day. When a user gets stuck, a quick answer is the difference between someone who keeps using PIV and someone who gives up on it. The Safari fix is a good example: to an affected iPhone user the site was simply a blank white page, with no error and no way to tell what was wrong. Most of them wouldn't report it, they'd just leave. Apple users are a big share of mobile users, so a bug like that quietly turns away a whole group of potential users until someone tracks it down.
- Hosted testnet wallet. Most people who would test v6 aren't going to build a wallet from source to do it. A wallet they can just open in a browser means far more people can try v6 and find problems before mainnet. Getting it running also fixed things that would otherwise have come up on the next testnet, or for anyone pointing MPW at a RustyBlox explorer.
Extra work outside the proposal
- Game hosting that takes PIV. A coin is only as useful as the places that take it. This is a real service selling a real product people already want, and PIV is a first-class way to pay for it. Every merchant like this gives holders something to spend PIV on and shows other merchants it can be done.
- Multi Wallet Kit. Most wallets and services don't want to support only one coin. A library that handles PIVX, Litecoin, and Dogecoin from one codebase makes it far easier for a multi-coin wallet, exchange tool, or payment service to include PIVX, because they no longer need a separate PIVX implementation to do it. PIVX keeps its full feature set there (shielding and cold staking), so PIVX isn't treated as a second-class coin. It has also already paid back into PIVX directly: the review work behind it found six bugs that are being fixed in the official PIVX wallet kit.
What's planned this quarter
- Moving v6 forward. v6 is the most important thing happening to the protocol, and it's mostly waiting on review right now, so more review time is the most direct way to speed it up. Every week it moves closer to mainnet is a week PIVX gets closer to the improvements it brings.
- MPW on v6 testnet. The protocol upgrade only works for users if their wallet works with it. A hosted testnet wallet means a tester only needs a browser, not a build environment. Testing MPW against v6 now, before mainnet, means problems are found by testers instead of by people with real money.
- Reviewing Core and MPW PRs. Outside contributors are a good sign for a project, but their code needs careful review before it touches people's funds. Fast, thorough review keeps contributors engaged and keeps the wallet and the network safe.
- Infrastructure and maintenance. Services that go down cost users and cost trust. Keeping PIVCards, the Oracle, and the nodes reliable is what lets the rest of the ecosystem build on them.
- Responding to issues. Problems will happen. Having someone who already knows these systems and can fix them quickly keeps a small issue from becoming a long outage.
Budget
45,000 PIV per cycle for 3 cycles, 135,000 PIV total.
This is the same amount as last quarter. As I said then, if the price recovers materially I'll adjust down in a future proposal rather than bank the difference.
Reporting
All the reviews and PRs above are public on GitHub and linked in this proposal, and the services are live at computingcache.com/pivx (https://computingcache.com/pivx) for anyone to try. I'm reachable in the usual channels for questions. I prefer Telegram/Discord for short and quick questions, as I don't check the forum as frequently, so a response there might take more time.
- Name: Luke (Q4 2026)
- Term: 3 Cycles
- Cycle Amount: 45,000 PIV
- Total Amount: 135,000 PIV
- Author: Luke
- Receiver: Luke
- Address: DRCftD2Xqmoud7x5EdhnBnMjof5qfE4rEn
- Created: 10-13-2026
- Status: Active
- Vote Hash: 15f0bdb0522f3396a0c2c1a344bbb01ec42be222f94997d6b2262485e76ead41
Role and Introduction
I'm Luke, a backend developer working across the PIVX ecosystem. Last quarter I moved the majority of my time back to PIVX Core and the wallet code that sits on top of it, while keeping the PIVX Labs platforms running. Most of that went into standing up and running the testnet6 network with Liquid, and into public PIVX infrastructure at computingcache.com/pivx (https://computingcache.com/pivx): explorers, a faucet, a public node API, and a hosted testnet wallet. This quarter continues that direction: move v6 forward by reviewing PIVX Core v6 PRs, keep reviewing MyPIVXWallet PRs, and keep Labs infrastructure healthy.
Q3 2026 Accomplishments:
PIVX Core and testnet6
- Worked with Liquid to stand up the testnet6 network: set up multiple servers running a large fleet of testnet nodes, and I'm maintaining a large part of that infrastructure on an ongoing basis. Liquid's Pivx-ansible playbooks (https://github.com/Liquid369/pivx-ansible) handle provisioning the nodes.
- Built out PIVX community infrastructure at computingcache.com/pivx (https://computingcache.com/pivx), all free, no account needed.
- Testnet explorer (https://computingcache.com/pivx/testnet/explorer/) for testnet6, so testers can check what their code actually broadcasts.
- Testnet faucet (https://computingcache.com/pivx/testnet/faucet/) that hands out tPIV with a per-address cooldown, so a script can't drain it. Its wallet stakes what it holds, so it refills itself.
- Mainnet explorer (https://computingcache.com/pivx/explorer/) with blocks, transactions, addresses, masternodes, governance, and analytics, built on Liquid's RustyBlox and indexing from my own full node. It uses the Blockbook v2 API, so existing wallets and scripts can switch to it by changing the host.
- Public node API on mainnet and testnet (/pivx/rpc/mainnet, /pivx/rpc/testnet) in the format MyPIVXWallet expects, rate limited and with no reachable wallet, for light wallets that don't run their own node.
- Rewards calculator (https://computingcache.com/pivx/calculator) showing what staking or a masternode pays on live network figures, plus an inflation calculator.
If the community would rather run any of this under another domain, I'm happy to do that. ComputingCache is just a domain I control, which makes it quick to push out updates and work with things while developing.
- Reviewed and approved PIVX#2982 (https://github.com/PIVX-Project/PIVX/pull/2982), which restarted testnet as testnet6 with a fresh genesis, a new spork key, and v6.0 activating at block 5000. Merged August 20.
- Reviewed PIVX#2984 (https://github.com/PIVX-Project/PIVX/pull/2984), which moves testnet chainlocks to a 20 member quorum so a single offline masternode can no longer kill a DKG session on the testnet fleet. Merged October 9.
- Worked through the open v6 PRs to get familiar enough with them to review properly, and worked with Liquid to confirm what order they should be merged in. This doesn't show up on GitHub, but it's the groundwork that lets reviews move more quickly this quarter.
MyPIVXWallet (MPW) reviews and fixes
- Reviewed and tested the MPW v3.0.0 release bump, MPW#627 (https://github.com/PIVX-Labs/MyPIVXWallet/pull/627), confirming the changelog matches what actually merged.
- Found and responsibly disclosed a security issue where seed phrases could be saved into browser autofill and form history on wallet import. Sent the fix as MPW#628 (https://github.com/PIVX-Labs/MyPIVXWallet/pull/628), which masks the secret input and disables autofill on wallet inputs.
- Did a full security review of the PIVX Name Service (PiNS) PR, MPW#630 (https://github.com/PIVX-Labs/MyPIVXWallet/pull/630), across two rounds. Confirmed the cryptographic proof checks hold up, then found a blocking bug: a malicious or compromised name indexer could run JavaScript inside the wallet through an error message, without ever touching the proof checks. Proved it end-to-end in a real browser, proved the fix closes it, and found five smaller issues alongside it. The author reworked the design in response, and my second round verified every fix.
Pivx-Wallet-Kit (the Rust/WASM engine under MPW and other PIVX wallets)
- Wallet-kit#1 (https://github.com/PIVX-Labs/pivx-wallet-kit/pull/1): Fixed a bug where the published npm package hung forever on every shielded send in the browser, and added a CI gate so it can't ship again.
- Wallet-kit#2 (https://github.com/PIVX-Labs/pivx-wallet-kit/pull/2): Made multi-recipient transparent and shielded sends, plus four pre-existing bugs found while building it (address validation, UTXO deduplication, block replay safety, shield memo length). 118 tests. Approved by Liquid.
- Wallet-kit#3 (https://github.com/PIVX-Labs/pivx-wallet-kit/pull/3): Cold staking support (delegate, withdraw, partial withdraw that keeps the rest staking, stake splitting) and crate-wide dust handling. 181 tests. Opened early because a user was waiting to test it.
- Verified all three on mainnet with real funds: eleven transactions, including a 1,000 PIV delegation split into two 500 PIV pieces and a partial withdrawal that kept the remainder staked.
- Reviewed Pivx-Agent-Kit (the AI agent wallet) for exposure to the same bugs. It's on an earlier Wallet-Kit version that predates four of the fixes, including address checksum validation, so moving it to the current version picks up all four with no code changes.
- Started backporting six more PIVX fixes found while building Multi-Wallet-Kit, below (shielded tree corruption from duplicate transactions, two input-validation hardening fixes, two fee calculation fixes, and a broken WASM doc build).
Continued maintenance
- PIVCards, Labs Oracle, and node systems kept online and maintained through the quarter, with issues handled as they came up.
- Handled PIVCards support tickets from users.
- Fixed a PIVCards bug where the whole site showed up as a blank white page on Safari on the iPhone 15. That version of Safari didn't support some of our frontend code, and there were no fallbacks in place, so the page failed to render at all. Added the fallbacks so it loads properly on that version of Safari.
Carried over from Q3, now live: MPW on the v6 testnet. Last quarter I committed to validating MPW against the v6 testnet. Between v6 not being far enough along for wallet testing to mean anything and time constraints, it got pushed back slightly into the start of Q4. The testnet wallet is now live:
- Testnet wallet (https://computingcache.com/pivx/testnet/wallet/): a hosted build of MyPIVXWallet pointed at testnet6, so anyone can try the wallet against v6 rules without building it. It runs on the testnet explorer and node API above, and it's testnet only: it can't switch to mainnet or touch real PIV.
- MPW couldn't run on testnet6 out of the box, which is expected, and getting it there surfaced four things to fix: shielded balances loading from leftover testnet5 data, shield sync starting at a mainnet block height on every network, an endless resync on a chain with no shielded transactions yet (so the first one could never be made), and history sync not working against RustyBlox explorers because of a paging difference from Blockbook. The hosted build carries fixes for all four, and they go upstream to MPW this quarter where they're needed.
- Tested end to end on testnet6: a new wallet funded from the faucet synced its history and shielded coins in about 10 seconds. That was the first shielded transaction on testnet6 made through MPW, and it confirmed the public node indexes shield data correctly.
- Running the explorers against MPW also showed two places where RustyBlox can match Blockbook more closely (testnet address formatting and paging). I'm going to reach out to Liquid and see if this is something we want to push upstream to make it more of a drop-in replacement for Blockbook.
Beyond the proposal
These weren't part of what the treasury funded. They're things I built on my own time and my own infrastructure, and I'm listing them because they add to the PIVX ecosystem.
- ComputingCache Game Hosting accepts PIVX. I built a game server hosting service (Minecraft, Terraria, Valheim, Vintage Story and more) at gamehosting.computingcache.com (https://gamehosting.computingcache.com), paid with self-custodial crypto through a self-hosted BTCPay Server. PIVX is a payment option at checkout alongside Bitcoin, with its own wallet connection and exchange-rate pricing. The service has just launched and is live and accepting paid orders.
- Multi Wallet Kit (https://github.com/Luke-Larsen/pivx-multi-wallet-kit). A multichain fork of Pivx-Wallet-Kit that adds Litecoin and Dogecoin to the same library and the same seed, with PIVX keeping its full feature set, including sapling shielding and cold staking. Litecoin supports paying modern bech32 and P2SH addresses, so it can pay exchanges. Building it meant a full security pass over the shared code, and that pass turned up issues in the original Pivx-Wallet-Kit: those are the six PIVX fixes now being backported upstream.
Q4 2026 Focus
1. Move v6 Core forward
- Keep testnet6, its node servers, and the computingcache.com/pivx services (explorers, faucet, testnet wallet, public node API) running, and work with Liquid on the issues the network turns up.
- Review, test, and help land open v6 PRs (my main focus for reviews this quarter.)
- Triage, reproduce, and fix bugs found on testnet.
2. MPW on the v6 testnet
- Finish testing the hosted testnet wallet against v6 rules: unshielding, shielded-to-shielded sends, cold staking, masternodes, and governance, and report or fix what breaks.
- Offer the four MPW fixes from the testnet build upstream where they're needed, and talk with Liquid about the RustyBlox changes.
- Keep the testnet wallet updated as v6 and MPW change.
3. Review Core, MPW, then other pull requests
Everyone working on PIVX is stretched for time and resources right now, and reviews are one of the places that shows. I'm putting considerably more of my time into reviews this quarter to help things move faster.
- Review incoming PRs with the same depth as PiNS: read the code, run it, and test it on testnet6 where it applies.
- Get my own open PRs (wallet-kit #1 to #3, MPW #628) through review and merged, and land the six wallet-kit backports.
- If time allows I would also like to look into and set up some systems to display and update everyone on development progress, this most likely means a restarting of the reporting system we had at Pivx Labs, but I have been taking
suggestions and plotting out some of the best ideas that make it easy for devs to do and is clear for users/masternode operators. This forum post discusses some points (https://forum.pivx.org/threads/roadmaps-core-updates-and-building-market-momentum.3031/).
I have also had conversations in telegram about this.
4. Maintain PIVX Labs infrastructure
PIVCards, Labs Oracle, node systems, and the supporting servers stay online, patched, and monitored, and PIVCards support tickets keep getting answered.
5. Respond to issues as they come up
Outages, provider changes, broken integrations, and user reports get handled when they happen, as they have every quarter.
Why this work is good for PIVX
This is a new section that I heard some people in the community wanted. I haven't done this before, and if anyone has suggestions about ways to clean this up or what is or isn't needed, I want to hear them.
What was done last quarter:
- Testnet6 infrastructure, explorer, and faucet. V6 can't ship until it's been run on a real network, and a test network is only useful if it's big enough to behave like the real one and easy for people to join. Running a large node fleet means v6 gets tested under realistic conditions like quorums, chainlocks, and nodes dropping out. The explorer and faucet mean anyone can join in and test without needing a developer to send them coins or check transactions for them.
- Mainnet explorer and public node. Light wallets like MPW don't run a node of their own, so they depend on someone else's. When only a handful of people run those services, one outage takes wallets down with it, and a few operators can see everyone's queries. Each independent explorer and node makes PIVX harder to knock over and less dependent on any single operator. Because the explorer uses the standard Blockbook API, wallets and services can use it as a drop-in backup with no code changes.
- Rewards calculator. It gives people a straight answer to "what does staking or running a masternode actually earn me?", which is one of the first questions a new holder asks and one of the main reasons to hold PIV.
- Testnet6 reviews and v6 PR groundwork. A clean testnet with a quorum that doesn't fall over when one node goes offline means testers spend their time finding real v6 bugs instead of fighting a broken test network. Knowing the open v6 PRs and agreeing on a merge order ahead of time means v6 lands in a sensible sequence instead of in conflicting pieces.
- MPW v3 review. MPW is how a lot of people hold PIV. A second set of eyes on each release lowers the chance of shipping something broken to them.
- Seed autofill fix. A seed phrase is the whole wallet. If a browser quietly saves it, anyone with access to that browser, or anything that syncs its form data, can take the funds. Closing that protects every MPW user who imports a wallet.
- PiNS review. Name services make PIV easier to send ("send to Luke.pivx" instead of a long address), which is good for adoption, but only if they can't be turned against the user. The bug I found would have let an outside server run code inside people's wallets. Catching it before merge means PIVX gets the feature without the risk.
- Wallet-kit fixes. The shielded send hang meant any app using the published package simply couldn't do private sends, which is one of PIVX's main features. Multi-recipient sends make PIVX cheaper and simpler for anyone paying several people at once, like pools, payroll, or exchanges.
- Cold staking in wallet-kit. Cold staking lets people stake without leaving their coins in a hot, always-online wallet. Bringing it to the shared wallet engine means more wallets can offer safe staking, which supports network security and gives holders a reason to keep PIV.
- Mainnet verification. Testing with real funds on the live network is what tells us the code actually works, not just that the tests pass.
- Agent-kit review. AI agents send payments with no human checking the address. Missing address validation there means a single wrong character can send funds to an address nobody controls. Finding that before agent payments see real use protects PIVX's reputation in a space it's trying to lead in.
- PIVCards support and device fixes. PIVCards is one of the most direct ways people turn PIV into something they can use day to day. When a user gets stuck, a quick answer is the difference between someone who keeps using PIV and someone who gives up on it. The Safari fix is a good example: to an affected iPhone user the site was simply a blank white page, with no error and no way to tell what was wrong. Most of them wouldn't report it, they'd just leave. Apple users are a big share of mobile users, so a bug like that quietly turns away a whole group of potential users until someone tracks it down.
- Hosted testnet wallet. Most people who would test v6 aren't going to build a wallet from source to do it. A wallet they can just open in a browser means far more people can try v6 and find problems before mainnet. Getting it running also fixed things that would otherwise have come up on the next testnet, or for anyone pointing MPW at a RustyBlox explorer.
Extra work outside the proposal
- Game hosting that takes PIV. A coin is only as useful as the places that take it. This is a real service selling a real product people already want, and PIV is a first-class way to pay for it. Every merchant like this gives holders something to spend PIV on and shows other merchants it can be done.
- Multi Wallet Kit. Most wallets and services don't want to support only one coin. A library that handles PIVX, Litecoin, and Dogecoin from one codebase makes it far easier for a multi-coin wallet, exchange tool, or payment service to include PIVX, because they no longer need a separate PIVX implementation to do it. PIVX keeps its full feature set there (shielding and cold staking), so PIVX isn't treated as a second-class coin. It has also already paid back into PIVX directly: the review work behind it found six bugs that are being fixed in the official PIVX wallet kit.
What's planned this quarter
- Moving v6 forward. v6 is the most important thing happening to the protocol, and it's mostly waiting on review right now, so more review time is the most direct way to speed it up. Every week it moves closer to mainnet is a week PIVX gets closer to the improvements it brings.
- MPW on v6 testnet. The protocol upgrade only works for users if their wallet works with it. A hosted testnet wallet means a tester only needs a browser, not a build environment. Testing MPW against v6 now, before mainnet, means problems are found by testers instead of by people with real money.
- Reviewing Core and MPW PRs. Outside contributors are a good sign for a project, but their code needs careful review before it touches people's funds. Fast, thorough review keeps contributors engaged and keeps the wallet and the network safe.
- Infrastructure and maintenance. Services that go down cost users and cost trust. Keeping PIVCards, the Oracle, and the nodes reliable is what lets the rest of the ecosystem build on them.
- Responding to issues. Problems will happen. Having someone who already knows these systems and can fix them quickly keeps a small issue from becoming a long outage.
Budget
45,000 PIV per cycle for 3 cycles, 135,000 PIV total.
This is the same amount as last quarter. As I said then, if the price recovers materially I'll adjust down in a future proposal rather than bank the difference.
Reporting
All the reviews and PRs above are public on GitHub and linked in this proposal, and the services are live at computingcache.com/pivx (https://computingcache.com/pivx) for anyone to try. I'm reachable in the usual channels for questions. I prefer Telegram/Discord for short and quick questions, as I don't check the forum as frequently, so a response there might take more time.
Last edited: