🧭 Monero Ecosystem updated by Mondetta monero.eco 🟢 Added: monero.observer stasher.news kashilo.com xmrpay.link 🔴 Removed: MoneroBlock FerrySwap Metronero Sidekick Exolix /Exchanges /Market ↔️ Connected: Cake - Trezor 🔀 Merged: GUI, CLI -> Official 📎 Links added/updated: Each Category -> External link OrangeFrens -> Events page 🎨 Logos/Icons updated: Many ⚡ Site optimized: 14x

Code is ready. Target fork Monday 5 Oct 2026; binaries expected within a day. jeffro256 proposed a 10 MB initial penalty-free zone to skip warm-up and resume prior spam volumes; leftover bugs should match the earlier raise to 625K. libera.monerologs.net/monero… 1/2

Hot-cold is merged. jberman is rebasing FCMP++/Carrot on master for beta v3 (rollback for existing beta users, higher min penalty zone, minor beta PRs; possible Rust lib regression with kayabanerve). RandomX v2 PR github.com/monero-project/mo… discussed; not a beta-v3 blocker. 1/2

jberman said the remaining v3 blocker is hot/cold wallet work, which is in progress. jeffro256 said major changes from jberman’s review are done; only renamings remain. jberman: It's just hot/cold wallet stuff now, we're working on it

🎉 P2Pool is 5 years old today! The first Monero block found by P2Pool was 2437679 on August 29, 2021. Celebrate by mining on P2Pool and finding more blocks ⛏️ v5.0 is coming with FCMP++/Carrot support + 0-fee transactions for P2Pool miners. Beta in September (FCMP++ stressnet).

MAGIC Grants recently had @trailofbits, a leading cybersecurity and research firm, audit certain cryptography for Monero's forthcoming FCMP++ upgrade. This upgrade will substantially increase the privacy of Monero transactions. Read more: magicgrants.org/2026/08/17/M…

Thanks to @cakewallet we're organising a meetup in Kraków 🇵🇱 this Friday! Join us for bowling 🎳, pool 🎱 and a chat about Monero 🧡 Meetup is taking place in Forum - the chosen venue for MoneroKon 7 Sign ups: OrangeFren.com/event/101 Meetup.com/cake-wallet-meetu…

jberman reported that the Rust FFI PR has been merged into upstream master and that the next item on the FCMP++ integration list is monero-project/monero #10360, the final PR from the Phase 1 audit. For Phases 2 and 3 he preferred continuing internal reviews and merges, with audits to follow once the code is fully in (or Phase 2 audited after its code lands). jeffro256 updated the planner at html-preview.github.io/?url=…. The largest remaining Carrot-side blocker is the LGPL licensing of mx25519 (github.com/monero-project/mo…). Discussion focused on LGPL section 6 compliance (providing a link to the release tag commit), possible monero-site changes, CoC compatibility, effects on downstream wallets and hardware-wallet integrations, the existence of at least one other LGPL dependency (polyseed), and the feasibility of a permissive reimplementation. tevador declined to relicense and stated that the practical restrictions are mild (primarily adding the license text to the release archive). Views ranged from accepting LGPL in order to move forward quickly to concerns about added complexity, technical debt and downstream burden. No consensus was reached; the licensing discussion was left open and suggested for the No Wallet Left Behind agenda or further GitHub comment. On the audit side, the Least Authority helioselene review is near completion while quotes are still needed for the remaining research-task audits. jberman: The Rust FFI PR was merged into upstream master (hooray), next on the FCMP++ integration list is: github.com/monero-project/mo… jberman: That is the final PR from the Phase 1 FCMP++ integration audit jeffro256: I have updated the planner here: html-preview.github.io/?url=… jeffro256: OOps that's already linked jberman: For Phases 2 & 3, right now I'm thinking it would be best to just keep going reviewing on our end and merging code, and once all code is in we audit then (perhaps we get Phase 2 audited once all that code is in). I think that would be most efficient jeffro256: Biggest blocker on the Carrot side seems to be licensing around mx25519: github.com/monero-project/mo…. tevador has mx25519 licensed under LGPL, which has some restrictive terms. jberman: No major update at the moment on the final Research Task audits. The Least Authority helioselene audit is very close to the finish line jeffro256: There's some discussion around how exactly Monero will comply with the terms in section 6 of LGPL v3: github.com/monero-project/mo…. IDK if anyone has something to throw in here, because it doesn't seem to be going anywhere quickly... jberman: And we still need quotes for divisors impl audit rd. 2 + fcmp-plus-plus lib audit jpk68: jeffro256: It does seem like this would complicate things a fair bit, which would be quite inconvenient. Adopting LGPL dependencies, I mean jpk68: The amount of complexity surrounding this upgrade is already pretty extreme jpk68: Downstream users of Monero code would also be affected by this (i.e. wallet applications) tevador: The "restriction" of LGPL § 6 would imply we would need to provide a link to the tag commit the release was built from. Which is hardly a restriction. jpk68: tevador: You mentioned that you didn't want to relicense your code after companies made proprietary forks of RandomX code. tevador: Example: github.com/monero-project/mo… jeffro256: Yeah, that does involve some changes to monero-site, though. jpk68: I'm wondering how the same concern applies to general cryptography code, rather than PoW vtnerd: the primary objective of the lgpl is to force changes to mx25519 to be made public … ? jpk68: Yes, but how is that practically relevant here? I can see how it is for RandomX tevador: The exactly same thing applies to a Curve25519 library. If someone makes optimizations, we want to be able to upstream them. vtnerd: I guess a wallet could be made faster in secret, similar to the issue in randomX slowbeardigger: In xmrpay-carrot I already use a BSD-3 Rust implementation based on curve25519-dalek that matches the upstream CARROT vectors. slowbeardigger: It only covers the receiver side CARROT operation for now, not the full mx25519 API. slowbeardigger: would a permissively licensed rust implementation be useful, or does Monero specifically need C/C++? vtnerd: c/c++ is more useful to the project I think, but opinions may differ tevador: I'm pretty sure mx25519 is faster than curve25519-dalek tevador: But both are usable for a wallet implementation jeffro256: Espeially after considering Rust FFI jeffro256: *Especially slowbeardigger: hmmmm slowbeardigger: what about a small portable BSD-3 C/C++ implementation be useful as a starting point if it matches the full unclamped API and existing vectors, or would optimized amd64/arm64 backends be required from the start? slowbeardigger: just wondering if I can be of any help vtnerd: this is assuming we are rejecting lgpl for some reason, it doesn’t seem to be a clear consensus on that jeffro256: If you can get a portable implementation as fast as the amd64x version, I'd be impressed tevador: A portable permissively licensed implementation could be made quite easily from the ref10 public domain code. But it's quite slow. vtnerd: every wallet is open source already, if Im not mistaken tevador: LGPL is open source. slowbeardigger: jeffro256: I’ll try my best vtnerd: I meant a wallet trying to use mx25519 but closed source somehow. I’m just not seeing any reason to worry about lgpl but maybe Im missing something tobtoht: LGPL § 6 is not the only restriction and its restrictions would apply to all downstream projects, not just Monero. tobtoht: LGPL is incompatible with the CoC: "All contributions to the project source code ("patches") MUST use the same license as the project." jpk68: This is my point, we have already had enough trouble trying to get, for example, hardware wallet companies to integrate Monero jpk68: Making licensing matters more complicated is shooting ourselves in the foot slowbeardigger: I’m not assuming LGPL will be rejected. I’ll treat this as a small benchmark experiment first, compare it against the portable and amd64x implementations, and only suggest it if the result is actually useful… slowbeardigger: I’ll start working on it tevador: The CoC is clearly meant for other cases, like someone submitting a random patch under GPL. tevador: AFAIK we already have at least one LGPL dependency jpk68: Also, the LGPL wouldn't prevent proprietary freeloading, since they could link dynamically jpk68: IIRC the only "copyleft" library we use currently is ZeroMQ, which is MPL jpk68: That's somewhat less restrictive compared to LGPL tobtoht: "The CoC is clearly meant for other cases" Also, the LGPL wouldn't prevent proprietary freeloading, since they could link dynamically jeffro256: It would prevent modifying mx25519 itself, and not publishing the modifications, which is the point rucknium: More discussion on this issue? jeffro256: Ideally, we should figure this out soon, because it is a blocker for Carrot and Polyseed support rucknium: Can the licensing discussion be moved to No Wallet Left Behind meetings or should it stay here for next week? Or moved back to GitHub? jberman: tevador: do you see yourself budging on this issue and relicensing? tobtoht: I will honor a vote jeffro256: tobtoht: Since we have maintainers and approval processes, it is always at our discretition to block the changes that are superfulously adding non-permissive licensing for their own sake. I don't believe that Polyseed and mx25519 are those cases. jeffro256: We will need to do some infra work on the monero-site side to support LGPL license terms. Is someone willing to make those changes? Also, we need to implement a license command or something along those lines correct? jeffro256: To display the license body from the object code jeffro256: rucknium: If the relevant people will join NWLB on Monday, then it could be moved there jberman: my opinion on this is whatever moves this forward as fast as possible, I don't have a strong opinion on the license discussion itself jberman: I think we should move on and if tevador wants to add to above tevador can tevador: jeffro256: AFAIK we could just add the license file(s) to the release archive. tevador: I have already explained why I'm not going to relicense. jberman: ok, if tevador isn't going to relicense then I think let's just find a way to move forward with that tobtoht: My personal opinion is that we should not burden every downstream ecosystem project with a restrictive license. jberman: I think that's a fine opinion but we're stuck at an impasse here and I think it's best we move forward with it tevador: The "restrictions" of LGPL are quite mild, even for closed-source projects that use the library. UkoeHB: I am also against restrictive licenses both on principle and pragmatically (how much time wasted already on this? MIT gets no such drama). Is it possible an LGPL fork will just patent any changes they make, rendering the whole endeavor meaningless? jeffro256: What exactly is the burden for downstream eco? That they must point to the Monero source ? Does that resolve section 6 since our repo would point to mx25519? tevador: AFAIK there was no issue until tobtoht started to dispute the license. jpk68: I don't want to be annoying and keep insisting on not having permissive licenses (at the expense of delaying things), but I feel like it's not a great idea to keep making non-ideal decisions, causing later technical debt, for the sake of finishing things faster jeffro256: TBF looking over license terms is exactly what we need to avoid licensing issues ... jpk68: At some point, one has to wonder how many concessions we're willing to make (Rust, LGPL, etc.) just to jam things through quicker jberman: in this case I don't think there is much room for significant issues either way and both sides raise fine points jberman: yes yes just to jam things through quicker than the 2 and a half years this has taken rucknium: Given tevador 's statements, isn't a clean-room reimplementation of mx25519 the only way to avoid the LGPL in the Monero codebase? Anyone want to do that? If no, there seems to be only one option. jpk68: jberman: Rewriting FCMP++ code in C/C++ would probably take longer than using the Rust library, no? jberman: absolutely not tevador: AFAICS the only change that would need to be made is to add the (L)GPL text to the release tarball. The rest is already solved. jberman: sorry, absolutely yes* sech1: Any code rewrite will require another code audit jeffro256: tevador: Does does downstream have to do this if they use Monero as a library, instead of downloading releases? jpk68: My point is simply that we shouldn't keep making compromises which will incur future technical debt under the excuse of saving time. In other words, I agree with tobtoht here rucknium: IMHO, this issue should go on No Wallet Left Behind's agenda next week. tevador: jeffro: It depends if they use the part that links to mx25519, then they have to also include the license file. libera.monerologs.net/monero…

Self-Custody Best Practices, Cake Wallet, and Monero with Seth for Privacy nitter.net/i/broadcasts/1XxyggWnR…

Cuprate 0.1.0-preview: Kesterite is released! You can now connect your wallets to Cuprate nodes to sync and broadcast transactions. See our detailed blog post on the performance improvements of Cuprate over monerod in wallet syncing. (Please read it) cuprate.org/blog/release-cup…

Serai has published the latest version of our implementation of Tendermint! We've also written a blog post discussing how the Serai network architects its consensus, how we actually achieve consensus, and all of the design considerations made for our implementation of Tendermint.

The MAGIC Monero Fund is 43% towards its goal to further improve Monero's automated testing (fuzzing) harnesses for increased security! Learn more ⬇️ teddit.net/r/Monero/comments…

How Emanuele Scala’s Bulletproofs Research Could Make Monero Transactions Smaller, Faster & More Private nitter.net/i/broadcasts/1dKrPPBBa…

jberman reported continuing FCMP++ PR upstreaming (next PR approved), stressnet double-spend fixes, and plans to solicit a secondary audit of the Rust FCMP++ circuit/gadget code. Trail of Bits finished phase 1 (report pending review). jeffro256 proposed removing phases 2/3 as blockers for the initial HF code merge and binary release so those audits can run in the post-merge window, with a contingency to delay activation if needed. This would shorten the overall timeline under cautious optimism. HW-wallet support is not required for the core HF (non-HW interfaces complete; Ledger exploring a CCS). Code-freeze discussion favored 2–3 months of bug-fix-only merges before activation, prioritizing consensus/p2p over a full feature freeze. VRP scope was noted as overly broad. No hard objections; ToB report and a Gantt chart expected before next meeting. RandomX v2 daemon PR is ready and should fit. jberman: Unfortunately won't be 100% available for today's meeting, my update: continuing upstream FCMP++ integration PR's (the next PR was approved today) and squashing the rare stressnet wallet double spend errors (with rucknium's help, who's running the latest set of fixes for the error / observed issues while debugging) jberman: On FCMP++ research tasks: we're looking to solicit quotes on a secondary audit of the circuit and gadget impl in the Rust FCMP++ lib and possibly more code as well, next step is drafting a proposal and reaching out to firms jberman: No additional material change to report from last week on other FCMP++ items from my end beyond above jeffro256: So ToB is done with auditing phase 1. I don't know if j-berman has release the report publicly yet, I think that he wanted to do a pass on it before releasing it. Justin and I want to propose something to move the timeline up: remove phase 2 and 3 audits as a dependency for HF activation and binary release UkoeHB: Is hw wallet support mandatory for hf? Cause those are going to take a while. jeffro256: This doesn't mean that phase 2 and phase 3 audits wouldn't happen, but they would happen during the 6-month conventional/mandatory waiting period instead. jeffro256: No, at least not in the core repo. That's my opinion UkoeHB: Ok seems reasonable rucknium: Are there big technical challenges for HW wallet support, e.g. need to fit big objects on limited wallet RAM? jeffro256: The interfaces for HW devices on the non-HW side are done. Ledger is interested in making a CCS proposal to fund R&D on their side. jeffro256: rucknium: I've talked to Kayaba a bit about this a while ago, and IIRC most parts of the SA/L signing can be "streamed" like they are now with CLSAGs. But it does complicate the signing as compared to simply having all the needed parts in-memory rucknium: "remove phase 2 and 3 audits as a dependency for HF activation" has confusing wording, IMHO. rucknium: "HF activation" means the date that the HF occurs, to me. jeffro256: By "HF activation", I meant "HF activation code merge", sorry rbrunner: What happens if after that a critical problem surfaces that is not correctable within time, as a worst case scenario? rbrunner: Or, can we "take back" the HF? rucknium: Here's a 2020 paper on HW wallets for Monero moneroresearch.info/119 Klinec, D., & Matyas, V. 2020, "Privacy-Friendly Monero Transaction Signing on a Hardware Wallet." Paper presented at ICT Systems Security and Privacy Protection. rbrunner: (As a result of the on-going audits and reviews) jeffro256: rbrunner: Then the date gets pushed back 6 - N months, and people have to re-download binaries, where N is the "remaining time" between problem finding and previous HF activation date rucknium: Last HF, the announced date was moved at least once. I don't think any HF binaries were released and then withdrawn. jeffro256: rbrunner: We can "take back" the HF before it happens if users/companies stay up-to-date on releases rucknium: Anyone who downloads the binaries and neglects to update will be stuck on a bad fork. rbrunner: Yes, as the possibly worst outcome, however unlikely jeffro256: Note that this is something that can happen anyways without audits, with such large update, and we should prepare for it regardless of auditing rucknium: That's a similar outcome for people who just never update and a HF happens. rbrunner: Right. rbrunner: Seems to me the community of Monero users must be pretty "forking aware" now rucknium: If only we could get Linux package managers to also be forking aware jeffro256: Phase 1 has gone well so far, and j-berman and I are somewhat confident that further finding by future audits would likely be mitigatable without causing a HF relative to the current state of the codebase, but it's absolutely possible. rucknium: Could you describe phases 2 and 3 for us, jeffro256? jeffro256: I'm extremely confident that phase 2 and phase 3 could complete within the 6-month convential waiting period. With these assumptions in mind, if we were to take a cautious optimism approach, we could merge the HF activation code before phase 2 and 3 audits complete, and shave months off the timline. jeffro256: Then we have a contingency plan in case the audit feedback requires a HF relevant to previous release rucknium: You say "the 6-month conventional waiting period" as if a 6-month waiting period has ever happened before :D jeffro256: Phases 2 and 3 are defined in this document: github.com/seraphis-migratio… tevador: There should generally be at least a 2-3 month code freeze before the HF, if possible. articmine: rucknium: Sometimes I prefer they are not. I have had issues with Bitcoin and Linux package managers articmine: Never with Monero jeffro256: tevador before HF activation, correct? tevador: Yes, before the fork activation date. jeffro256: I think that that is certainly possible with the planned scopes of phase 2 and phase 3 jeffro256: I'm working on a Gannt chart today because the timing and dependencies is getting hard to describe in words jeffro256: But I wanted to toss the idea of not blocking the first HF-activated release with phase 2 and phase 3 and get feedback on that rbrunner: maybe "HF enabled release" or "HF ready release" ... slstmd: What was the exact definition of code freeze again? vtnerd: presumably there would be a branch at the very least rucknium: I went back and looked. The previous HF binary was released less than a month before the HF activation date: github.com/monero-project/mo… rucknium: I don't mean to say that it's a good precedent to follow. But "conventional" 6-month period is probably not the right word. jeffro256: lol fair rbrunner: I think that was always "the idea" :) jeffro256: I was under the assumption that that was the target for previous HFs rbrunner: That collided sooner or later with harsh cold reality vtnerd: we should’ve created the branch earlier than the 1 mo, and “froze” changes, but I don’t recall now tevador: Code freeze means only bug fixes can be merged... but this rule has not always been followed. rbrunner: I think it's still a good idea, and maybe *this* time, swapping almost the whole technology stack, we should pull that through rucknium: The 2022 HF delay was about multisig IIRC rbrunner: And also with coin exploits popping up left and right ... rucknium: Do we need more time to discuss this, in this meeting? We can give people time to think. I hope the Trail of Bits piece can be published by next meeting, to provide more info. rucknium: Will there be a bounty on exploits against the the frozen code before the HF is activated? rbrunner: Something that goes beyond the usually offered bounties would be a first, as far as I know tevador: The Monero VRP states that "code in all branches; including the master branch and any release branch" are in scope rucknium: The VRP scope is wide. Maybe something special isn't necessary: rucknium: > This Vulnerability Response Process and subsequent bounty reward apply to the following: rucknium: > Code implementation as seen in the Monero Project GitHub repositories rucknium: > This includes code in all branches; including the master branch and any release branch rucknium: > Written research from the Monero Research Lab which dictates said code implementation rucknium: github.com/monero-project/me… rucknium: But the potential reward isn't defined well. jeffro256: tevador: Maybe we should reduce the scope to *current release branches... jeffro256: I don't care if there's a vuln in v0.12.0.0 that got fixed 5 years ago tevador: Yes, that scope seems overly broad rucknium: More on this agenda item? articmine: jeffro256: Does this include anything that is pre release, or in testing for release etc. jeffro256: Does anyone currently object to not blocking the first release with phase 2 and phase 3 audits ? articmine: I understand the case of clearly obsolete code selsta: fwiw it has never been an issue that someone argued about old release branches, but yes the wording should be updated jeffro256: If it's still in a PR, I think it shouldn't be in-scope for payouts. If it's pre-release, it will probably be in master. If it's a planned release, it will show up in a current release branch rbrunner: Right now looks like a calculated risk worth taking to me. articmine: Fair enough, I just feel we should be careful and precise with the language. rucknium: jeffro256: I would prefer to have the Trail of Bits piece published before making a call on that, but I won't "object" to it. jeffro256: That's fair, AFAIK it should be release before next MRL meeting jeffro256: *released selsta: I agree with jeffro's proposal, as long as it's timed up so that all audits complete in time before the HF activates, with a small buffer articmine: selsta: I agree tevador: "small buffer" should be at least 1 month rucknium: How soon, from today, is the expected HF code freeze, i.e. when would the 6-month clock start ticking? jeffro256: I'll also release my Gannt chart that I'm working, so we can have something more concrete than a collection of English chat logs to describe the timeline tobtoht: Are we still branching v0.19 from master to test Guix and other changes in master? jeffro256: rucknium: tevador were you talking about a pre-first-HF-enabled release code freeze, or a pre-HF-activation code freeze? selsta: tobtoht: I would say yes selsta: Polyseed looks more or less ready jeffro256: We should do that ASAP IMO tevador: I think the code freeze should generally precede the first release binaries jeffro256: Would that be a code freeze on consensus and node related code. For example, would multisig support / HW support / wallet knowledge proofs / other wallet-specific features be under this code freeze? selsta: what's the status from stressnet for txrelay v2? ready for v0.19? tevador: jeffro256: That's debatable, but generally you want to freeze all features before the release and focus on bug fixes vtnerd: yeah theres lws RPC changes for example that someone has to slog through (review) rucknium: selsta: I think we should get at least a week of more testing with the latest proposed fix of the double-spend issue, IMHO. jeffro256: tevador If we freeze all features, that would push back the HF activation by several months for features that could be developed in parallel IMO selsta: I have always disliked an overly strict code freeze jeffro256: I think that that kind of a freeze is simply too broad jeffro256: I would agree that p2p and consensus features should be frozen for some period of time before release tevador: non-consensus changes can go into .1 anyways jeffro256: I think that basic sending / receiving / syncing wallet features should be frozen before the first release too tevador: What is the expected timeline for the HF? Can RandomX v2 stil make it? jeffro256: But, respectfully, waiting for Trezor and Ledger to activate FCMP++ would be a mistake jeffro256: They don't move very fast rucknium: Isn't RandomX v2 already ready? sech1? tevador: It's ready but not on the daemon side AFAIK? rbrunner: That's also what I dimmly remember selsta: there is a PR for it on daemon side, jeffro wrote it selsta: RandomX v2 wallet related code is not developed yet but that doesn't require HF rucknium: Do any HW wallet manufacturers move fast? Could there at least be one sure to be ready for the HF? jeffro256: tevador: The expected timeline for the HF is what I'm trying to decide. RandomX v2 should be able to make it. I have this PR: github.com/monero-project/mo…. I need to add back the tx count and update the flow charts in the documentation, if we are to keep it jeffro256: But besides that, the consensus changes are done jeffro256: I plan to integrate DoS-resistant header-only sync after #10038 is merged, but that shouldn't be a blocker to the FCMP++ release tevador: Thanks, I missed that PR jeffro256: rucknium: I'm trying my damndest jeffro256: It would probably help to have a bunch of people bug them, IDK rucknium: jeffro256: I know you are. Thanks. But would users have an alternative in time for the HF? selsta: realistically Ledger/Trezor will use LLMs to implement FCMP++ so I assume it won't take too long rucknium: oh no gingeropolous: i ponder if we should add things to make the codebase llm friendly rucknium: Maybe their revenue isn't great right now. rbrunner: Many, many comments help. Something we are proudly famous for :) rucknium: rbrunner: Is that sarcasm from you? rbrunner: Yes, of course ... rucknium: I think we should move the agenda along. Feel free to discuss this agenda item after the meeting. rbrunner: Well, not the comment bit. They do support the work of LLMs greatly, from the little I know so far sech1: RandomX v2 is ready and released, XMRig version with v2 support is also released. Monero doesn't have v2 support yet. libera.monerologs.net/monero…