Monero Tech Meeting Summary — #183 (Aug 31) & #184 (Sep 7, 2026)
Overview

The Monero Tech meetings are weekly Monday gatherings chaired by rbrunner7 in the #no-wallet-left-behind channel (bridged IRC-Libera/Matrix). The project is currently in a heavy preparation phase for the v0.19 release, while the FCMP++/CARROT hardfork work continues on a parallel track. #183 was a two-week catch-up (the Aug 24 meeting was canceled due to a Matrix server outage), while #184 was relatively brief — about 14 minutes of formal agenda.

Meeting #183 — Monday, Aug 31, 2026

1. Developer Status Reports:

• brunner7 — Still deep in the seemingly never-ending Polyseed PR (#10765) review cycle. Has received extensive contributions and reviews from many people but is trying to figure out how to walk "the last few meters" to merge-readiness. Needs a rebase, and is waiting for tevador's Polyseed re-licensing to land first so the submodule can be updated.
• sneedlewoods_xmr — Received lots of reviews across his PR batch (#9464, #10232, #10233, #10819 — the wallet-rpc extended status work). Was committing almost daily working through AI review comments.jpk68 — Worked on review comments, submitted a few PRs, updated AUR packages for Cuprate, did hardware wallet testing for sneedlewoods, and attempted to replace GNU Readline with linenoise in epee (monerod's networking layer).
• jberman — Worked mostly on Serai the prior week, with no significant update on FCMP++. Was catching back up on FCMP++ things.tobtoht — Announced a major infrastructure change: replacing Guix with Stagex for release builds, and glibc with musl + mimalloc allocator. Benchmarks show greatly reduced memory usage for beta-stressnet sync and better performance on checkpointed syncs. PR: #10223.

2. DangerousFreedom1984 — MoneroInflation Checker for FCMP++

rbrunner7 highlighted a significant milestone: DangerousFreedom1984 shared a detailed report that day with a first working version of the MoneroInflation checker updated for FCMP++. The tool is designed to verify no inflationary bugs exist in the new FCMP++ transaction format. The repo is at github.com/DangerousFreedom1984/monero_inflation_checker and a Reddit post was also made about it. This is important because FCMP++ fundamentally changes how transaction outputs are committed, so the old inflation checker needed a full rewrite.

3. monero-oxide Ecosystem Discussion

A lively discussion broke out when ravfx asked whether it's OK to start making a new wallet using monero-oxide instead of wallet2. Key takeaways:

• boog900 confirmed monero-oxide has been audited.
• jpk68 pointed to monero-wallet-util (github.com/monero-oxide/monero-wallet-util) as the more appropriate starting point — a few projects are already adopting it.
• jberman said they'd use monero-oxide over wallet2 if presented with the choice today, but cautioned: "gonna be quite a few things to need to work through though that wallet2 handles out of the box" — specifically wallet state management, reorg handling, encrypted wallet file storage, and a whole lot more.
• boog900 agreed: "monero-oxide is not the same level of wallet lib as wallet2."jbabb (Cypherstack) clarified the monero-oxide family: monero-oxide is the blockchain implementation, monero-wallet is wallet core on top, monero-wallet-utils adds more wallet tools — but there's still a big gap to wallet2's feature set.
• DataHoarder revealed they're making a Go port of similar wallet tooling manually (from scratch, not AI-generated), which prompted a sub-conversation about AI-generated code in the codebase.
• On wallet file format portability: rbrunner7 wondered whether a new standardized wallet file format will emerge from the monero-oxide ecosystem, or whether seed-based recovery across apps will remain the norm. jpk68 suggested a new standard using an actual KDF rather than the current approach.

4. Tor Control Protocol — jpk68's Reassessment

jpk68 raised a significant second-guessing of his own CCS proposal to integrate the Tor Control protocol into monerod. His reasoning for now doubting the value:

1. The protocol is being phased out in favor of a new JSON-based standard that ships with Arti (Tor's newer Rust implementation). Tor Control is only supported in the legacy C implementation, which will itself be deprecated in a few years.
2. Writing it in C++ with existing machinery (no new dependencies) was possible, but it would add startup flags and configuration surface area.
3. The main benefit — ephemeral hidden services so users don't have to manually set them up — was seen as marginal.
   
   Reactions from the room:

• rucknium was lukewarm: "I didn't see a great need to add Tor Control," and quipped "More knobs to twist so YouTubers have more things to fill their videos?"
• jbabb noted that having monerod more aware of Tor connection state (e.g., a killswitch for TX broadcast when Tor drops) would be valuable, but acknowledged the daemon can't run purely over Tor while syncing.
• vtnerd (arriving late) noted that Tor SOCKS generally "does the right thing" — generating a new circuit per SOCKS connection — and that even Tor Browser doesn't use the control connection.
• rbrunner7 suggested jpk68 open a GitHub issue to get broader feedback beyond those present, and noted that when FCMP++/CARROT work crystallizes further, there will be plenty of other things needing attention.
Outcome: The Tor Control integration seems unlikely to proceed in its current form, with jpk68 himself unconvinced and community sentiment tepid.

5. Polyseed PR Path to Merge

rbrunner7 drilled into the specifics of getting Polyseed PR #10765 over the line:

• Needs a rebase (conflicts from the steady stream of merges).
• Waiting on tevador's Polyseed re-licensing PR to land (this would resolve the copyleft license incompatibility that prevents Polyseed from being an optional/non-optional dependency).
• jpk68 had promised to go through AI review findings and submit what passes a smell test, but hadn't gotten to it yet (no major surprises expected).
• sneedlewoods wanted to do a final review but had been consumed by their own PRs — offered to prioritize it.
• jpk68 apologized and said he'd get to it soon.

6. Guix → Stagex Migration

vtnerd arrived late, asking tobtoht directly: "Are we dropping Guix for Stagex?" tobtoht confirmed: "That is the plan. No more pain." vtnerd noted he'd keep his "crazy box" for Stagex builds, having gone through the pain of learning Guix as an OS.

Meeting #184 — Monday, Sep 7, 2026

1. Developer Status Reports
   • rbrunner7 — Still on the Polyseed PR review grind ("the seemingly never-ending Polyseed PR review :)").
   • jpk68 — Played with multisig support in the GUI, made fixes, reviewed PRs, general testing.
   • sneedlewoods_xmr — Finally addressed most AI review comments on the wallet-RPC PRs. Thanked selsta, thomasbuilds, and xmrack for legit and helpful AI-assisted reviews. Three remaining items:
2. Multisig issues discovered during testing — needs to verify they're resolved
3. Hardware wallet issues reported by jpk68
4. rbrunner7's suggestion to go "full extendedStatus" on the wallet-RPC PR — has a WIP branch for this, kept separate from the original PR in case it doesn't work out
   • selsta — Focused on v0.18.5.3, which keeps getting delayed by new issues and reports. Noted that at some point a hard cut needs to be made. (2/4)
   • jberman — Worked on hot/cold wallet review and upstream review.
   • jeffro256 — Deep in reviews (his own PRs and others).
5. v0.19 Release Strategy
   A critical discussion point: when is "the next release"?

• rbrunner7 asked whether the next release would still be 0.18 or the all-new v0.19 branched from master.
• selsta confirmed: v0.19. That's why he's trying to include as much as possible now — this is the last window before the branch cut.
• syntheticbird advised making the cut: "if you drop v0.19 people are going to be more reactive to upcoming minor releases. So imho you should go with making a cut."
• rbrunner7 observed that there are also many small PRs improving things left and right, which is nice but means more work to get them in before the cut.
• jberman's serialization changes (with vtnerd) were identified as the key thing selsta wants included.

3. Sync Testing Coordination for v0.19
A coordination thread emerged around testing the serialization PRs together:

• PRs to test collectively: #11168 (jeffro256), #11204, #11206, and #11235
• #11168 affects v1 transactions in slightly different ways (mixed/pre-RingCT amount indices lookup), so a sync from scratch is the ideal test — mainnet, testnet, and stagenet.
• jberman offered to do a sync from scratch, but noted it needs PR #11204 on master first.
• sneedlewoods_xmr offered to do a full testnet sync of all three PRs together.
• selsta thought it might be better to wait until everything is merged, then do one comprehensive sync test.

4. Liquid Hack Discussion
rbrunner7 shared a gist (1440000bytes) that came up in the MRL lounge about the Liquid hack — approximately 3,400 BTC stolen, with ~598.5 BTC (15%) still outstanding. The exploiters returned most of it on Sep 7 at block 965,950.

Key observations: • selsta: "this Liquid hack looks avoidable and they are lucky the hacker only kept 10%." • rbrunner7: "From the discussion in the MRL lounge I got that it seems half the network was running a basically not-yet-released version of the daemon, and that one was vulnerable. Pretty wild." This was noted as a cautionary tale about running unreleased software in production, and sparked some side discussion about software supply chain risk. 5. Polyseed Progress • rbrunner7 continues to push forward; sneedlewoods noted he'd ideally do another AI review run if anyone wants one. • The "extendedStatus" enhancement for the wallet-RPC PR (going beyond the current scope) was endorsed by rbrunner7 as "a lot of work, but a win."Key observations:
• selsta: "this Liquid hack looks avoidable and they are lucky the hacker only kept 10%."
• rbrunner7: "From the discussion in the MRL lounge I got that it seems half the network was running a basically not-yet-released version of the daemon, and that one was vulnerable. Pretty wild."
This was noted as a cautionary tale about running unreleased software in production, and sparked some side discussion about software supply chain risk.
5. Polyseed Progress
• rbrunner7 continues to push forward; sneedlewoods noted he'd ideally do another AI review run if anyone wants one.
• The "extendedStatus" enhancement for the wallet-RPC PR (going beyond the current scope) was endorsed by rbrunner7 as "a lot of work, but a win."

Cross-Cutting Themes

1. v0.19 Release Train — The dominant concern across both meetings. selsta is the release manager and is trying to land as many PRs as possible, but faces pressure from the team to cut scope and ship. Serialization changes from jberman/vtnerd are the key blocker. The Guix→Stagex migration is foundational infrastructure that should make future releases less painful.
2. FCMP++ / CARROT — Progress continues but in a lower gear. jberman was working on Serai last week rather than FCMP++. tobtoht is hopeful about another batch of FCMP++ PRs merging. DangerousFreedom1984's inflation checker milestone was a bright spot. The FCMP++ beta stressnet v3 is awaited but not yet launched.
3. Polyseed PR — A long-running effort that's close but not quite there. Blocked on tevador's re-licensing and needs final review bandwidth. The license compatibility question is a project-level concern (copyleft code in Monero's permissive core).
4. Review Bottleneck — Multiple developers cited being overwhelmed by reviews. sneedlewoods noted that when they started the wallet API work, weeks would pass without needing to rebase; now there are conflicts every week from the high PR velocity. tobtoht noted PR volume is 4x higher than last year, and over 100x higher than Jan-Mar 2022.
5. Bus Factor Concern — rbrunner7 raised whether Luigi's limited merge activity creates a bus factor issue. tobtoht confirmed Luigi only merges things he can't (like CoC changes). The monero-project org's membership isn't public, which jpk68 flagged as a transparency issue, though rbrunner7 noted it probably doesn't practically matter.

Next MeetingMonero Tech Meeting #185 is scheduled for Monday, Sep 14, 2026, 18:00 UTC in #no-wallet-left-behind.