Haveno Roadmaps Arti & Decentralized Marketplace – Amid Monero Governance Debates

Arti Integration Boosts Efficiency and Resilience for Haveno.com

Haveno, the Monero-centric decentralized exchange (DEX), has recently made significant technical strides by embedding Tor network connectivity directly into its platform. In a new update, the Haveno team integrated a TCP tunnel that allows the app to route traffic through Tor onion services using Arti, the Rust implementation of Tor. This means Haveno can run its own Tor client internally rather than relying on external Tor software or proxies. The immediate benefit for users is enhanced privacy and ease of use, no separate Tor app (like Orbot) is required for mobile or desktop, as Haveno now automatically anonymizes all network traffic through Tor . By eliminating the need for a third-party Tor process, Haveno’s built-in Arti integration strengthens the robustness and decentralization of the exchange’s peer-to-peer network. User connections are concealed behind .onion addresses, protecting IP information and making the network more resistant to censorship or DDoS disruption. Overall, this “Tor-by-default” approach reinforces Haveno’s mission of a private, censorship-resistant trading platform, allowing Monero traders to interact without revealing their identities or relying on centralized infrastructure .

The technical work on the Tor tunnel, detailed in Haveno’s documentation, emphasizes a self-contained design. Haveno’s Rust-based daemon now leverages the arti-client library to establish anonymous connections programmatically . In practice, Haveno launches a localhost TCP listener that forwards any protocol (such as gRPC API calls or HTTP requests) to a specified Tor v3 onion address via the embedded Arti Tor client . This design allows Haveno nodes (including future mobile clients) to communicate over the Tor network seamlessly, without users configuring external SOCKS proxies. The result is a more private and user-friendly experience: Haveno can automatically route orders and communication through Tor circuits, shielding participants’ locations while simplifying setup. Developers note that using Arti’s high-level APIs made the implementation straightforward, Arti handles the heavy lifting of Tor circuits and provides a Tor-encrypted stream that behaves like a normal TCP connection . By using Tor onion services for all peer-to-peer communication, Haveno not only protects traders’ metadata but also inherits Tor’s decentralization benefits, as there is no central server and all nodes are reachable only through their onion addresses. This integration is a major privacy upgrade for Haveno’s network and showcases Monero’s continued emphasis on anonymity in its ecosystem tools.

Roadmap: Haveno Expands into a Decentralized Marketplace

Beyond cryptocurrency trades, the Haveno project is charting a course to evolve into a broader decentralized marketplace. According to a recently published implementation plan, the developers aim to adapt Haveno’s architecture (originally designed for Monero-for-fiat trades) to support peer-to-peer buying and selling of physical and digital goods . The vision is to leverage Haveno’s existing strengths, a peer-to-peer, Tor-based network with non-custodial escrow and arbitration, and extend them to general e-commerce. In practice, this means users could list items like electronics, clothing, or services on Haveno, and trade them for Monero, all without centralized platforms. The plan outlines adding new gRPC API endpoints and data structures (e.g. Product, Order, ShippingMethod schemas) to facilitate creating listings and handling orders, while preserving Haveno’s core exchange functionality.

Trustless P2P Trading with Haveno. Haveno’s platform uses a 2-of-3 multisignature escrow (buyer, seller, arbitrator) to secure every trade, enabling private peer-to-peer transactions with Monero . This same trustless framework is slated to underpin Haveno’s expansion into a decentralized marketplace for goods, ensuring payments and deposits remain escrowed on-chain and only release with mutual agreement or arbitrator intervention .

A key element of the marketplace roadmap is that Haveno will remain fully decentralized and privacy-preserving in how it hosts listings. Just as currency trade offers in Haveno are distributed across nodes (and only exist while a user’s node is online), product listings would propagate through the P2P network rather than reside on any central server . Every seller’s node will locally hold their listings and share them with peers over Haveno’s Tor network, making the marketplace inherently censorship-resistant . All communication, whether it’s browsing a catalog, initiating a purchase, or messaging about a trade, would tunnel through Tor, exactly as current Haveno trade messages do, thus preserving user anonymity in the marketplace context . The development team plans to reuse Haveno’s seed nodes and peer discovery mechanisms to advertise marketplace listings, meaning no new infrastructure is needed beyond the existing Monero-based P2P network . By following Haveno’s proven design patterns (ephemeral offers, Tor-only connections, client-side data storage), the marketplace functionality can be added as a modular extension that doesn’t disrupt Haveno’s core trading operations .

Critically, Haveno’s multisignature escrow and arbitration model will carry over to the marketplace to ensure trustless transactions for goods. When buyers place orders, the plan is to lock the payment (in XMR) along with both buyer’s and seller’s security deposits into a 2-of-3 multisig escrow on the Monero blockchain . This is analogous to how Haveno secures currency trades, and it means even in a marketplace deal, no third party ever directly holds the funds, they remain in an on-chain escrow that requires two signatures (for example, buyer & seller on successful delivery, or one party and an arbitrator if there’s a dispute) . An independent arbitrator can be invoked if there’s an issue (e.g. item not delivered or not as described), using the same dispute resolution workflow Haveno already employs for trading . Only minor tweaks (such as additional dispute reasons specific to merchandise) might be added, but the fundamental process, an arbitrator helping decide how to finalize the escrow, remains the same . By repurposing its existing infrastructure in this way, Haveno aims to provide the Monero community with a decentralized, private marketplace akin to a crypto-powered online bazaar, while maintaining the security assurances (escrow and arbitration) that users expect. The implementation plan suggests this marketplace extension will be optional and configurable, preserving the ability to run Haveno purely as a currency exchange if desired. However, if successful, it could transform Haveno into a multi-purpose platform for private trade, not just for currency, but for anything of value, all backed by Monero’s ethos of decentralization and privacy.

More Community Concerns: Contributions, Censorship, and Core Team Controversies

While Haveno’s technical progress is promising, it has unfolded against a backdrop of growing community concerns about Monero’s development ecosystem. In recent months, debates have erupted over how new contributors and projects are treated within the Monero community’s governance structure. One flashpoint has been the Haveno project itself and the saga of a developer known as “kewbit” who worked on Haveno’s cross-platform (including mobile) application. Kewbit’s involvement with Haveno became contentious when he parted ways with the official Monero CCS (Community Crowdfunding System) funding process amid mutual accusations of bad faith. The Monero Core Team ultimately terminated funding for Kewbit’s Haveno work in late 2024, alleging that he violated the terms by seeking payment before fully delivering code . Kewbit, on the other hand, claims he completed the required milestone and was unfairly denied the payout. In public posts, he has accused Monero’s leadership of effectively scamming him, asserting that he fulfilled his end of the proposal, but the Core arbitrarily refused payment and shut down his CCS proposal. This dispute led Kewbit to fork the Haveno code and continue development outside of the official CCS framework, effectively creating a splinter Haveno team independent of Monero’s Core Team oversight.

The Kewbit episode highlights a broader sentiment among some community members that new or independent contributors are being marginalized. There are claims that developers who aren’t part of the long-established group face undue skepticism or even censorship on Monero’s platforms. For instance, Kewbit alleges that certain Core Team members (notably a figure known as luigi1111) have abused their influence to sideline his contributions. In one fiery post, he argued that the “rules are […] favoured towards the […] scams Luigi1111 pulls off to claim CCS and bounty funds fraudulently even when work is completed,” referring to his Haveno milestone as an example . He further charged that luigi1111 personally withheld funding despite Kewbit making the code publicly available, and suggested this was done to protect competing internal projects. (Notably, Luigi1111 has been a prominent Monero contributor who helps administer the CCS escrow; community discussions indicate he was involved in denying Kewbit’s payout due to process violations.) Kewbit’s frustration boiled over into serious accusations, he claimed that Luigi1111 “stole 2000 XMR from the General Fund” in the past, and even alleged that Monero’s former lead maintainer Riccardo “fluffypony” Spagni “decided to petition disband [the] core [team]” as a result of that incident. These allegations are unverified, but they have fuelled heated discussions about transparency and accountability of the Core Team.

Beyond the Kewbit case, allegations of censorship and gatekeeping have surfaced in Monero community channels. Some users complain that critical posts on the r/Monero subreddit or Monero chat rooms are removed or discouraged if they question the core developers or promote unendorsed projects. For example, when an alternate Haveno network (“Haveno-Aloha”) emerged, it was met with open hostility from some community moderators and members loyal to the officially supported Haveno instance. In a Reddit thread warning users away from this splinter network, one long-time Monero community member explicitly stated they trust arbitrators with “contacts to the main Monero devs” far more than “unknown” newcomers . The same commenter noted that if a Haveno network’s operators aren’t recognizable names (like known Monero developers or moderators), then “this is not it,” essentially dismissing the outsiders . Such attitudes underscore a perception that insiders are given preference, while outsiders face distrust. While prudence is certainly warranted with new platforms, the combative tone, branding the alternate Haveno team as “shady hotheads” in that discussion, has raised concerns about Monero’s openness to new contributors. Some fear that promising contributions could be stifled if they conflict with the interests or views of the Core Team and its close associates. The core developers and moderators, for their part, defend their actions as necessary due diligence, for instance, noting that Kewbit had not delivered code by deadlines and that unknown Haveno networks might pose security risks . Nonetheless, the schism has prompted a segment of the Monero community to question whether the current governance and moderation approach, concentrated among a small core, is serving the project’s inclusive, decentralized ideals.

Weighing Governance and Funding Reforms for Monero’s Future

All of these tensions have led to an uncomfortable question: Would Monero benefit from rethinking how its development is governed, funded, and moderated? Monero has always prided itself on decentralization, yet its development model relies on a Core Team (historically seven members) that holds significant sway over decisions, repositories, and community funds. The recent controversies have sparked calls to consider reforms, ranging from increased transparency and community oversight to more radical changes like disbanding the Core Team in its current form. Even Riccardo “fluffypony” Spagni, who was Monero’s lead maintainer for years, has flirted with such ideas. According to Kewbit’s account, fluffypony at one point advocated disbanding the Core Team entirely following internal disputes over missing funds. While that drastic step has not occurred, its mere suggestion by a Monero figurehead underscores the depth of concern about governance issues.

One proposal floated in the community is to transition Monero’s funding and decision-making to a more community-directed model. Monero’s Community Crowdfunding System is already a grassroots funding mechanism, but final approvals and fund disbursement involve Core Team members as escrow managers and gatekeepers. Critics suggest that a more decentralized funding board or smart-contract-based treasury (a sort of DAO for Monero development) could reduce potential conflicts of interest. This could go hand-in-hand with a broader governance refresh, for example, expanding who has commit access or oversight on Monero’s code repositories, setting term limits or rotation for core positions, and formally separating funding oversight from the developers who request funds. Advocates argue that such changes might encourage a healthier influx of new contributors, who would feel their proposals are judged on merit rather than on internal politics.

On the other hand, Monero’s defenders caution that its existing structure has delivered results: Monero has had numerous successful upgrades and a robust ecosystem growth under the Core Team’s stewardship. They worry that disbanding the core group or loosening coordination could introduce chaos or security risks to such a complex project. The Core Team members are long-term contributors who have earned trust, and completely open governance in a pseudonymous community can be challenging to manage.

Ultimately, the Monero community faces a classic decentralized-project dilemma: how to balance strong leadership and quality control with openness and community empowerment. The Haveno case, both its technical achievements and the social rift around it, has brought this issue to the forefront. As Haveno progresses (with Tor integration, a marketplace on the horizon, and even competing network instances), it serves as both a boon to Monero’s utility and a mirror reflecting Monero’s internal dynamics. It remains to be seen whether Monero will make governance adjustments in response to these recent events. What is clear is that many in the community are now openly discussing these matters. By raising tough questions about funding fairness, contributor treatment, and the role of the Core Team, the Monero ecosystem may well find better ways to organize itself, ensuring that the project’s ethos of decentralization and inclusivity is upheld not just in code, but in the community culture as well. The coming months (and Monero’s next developer meetings) will likely reveal whether any concrete governance changes are on the table. In the meantime, Monero users and observers will be watching closely, hopeful that the project can turn these controversies into constructive improvements and keep Monero’s development both innovative and equitable for all involved.