Hello ₿itcoin,

Thanks for your kind words! Regarding a release page, the code provided in the repository is an investor preview and while it's functional it is missing certain features and is incomplete thus I don't really feel comfortable making a release.

If you or anyone else is interested in building/testing it, here's how to get started:

• Set up Bitcoin, Litecoin, Monero and Ethereum nodes (don't have to be full nodes)
• Modify the connection constants in cryptoManager folder (look for variables like btchost at the top of the file)
• Open cmd in the main directory and type in go build

I'd recommend reviewing the code thoroughly before deployment though, crypto projects demand proper due diligence.

As for an audit, I'd absolutely welcome community review! If anyone wants to take a look, I'd be very grateful for the feedback.

Thank you for reading,
Alison Bobert

Hello nonlogs and Vod,


The code does not store or collect any PII including ip addresses, which you can verify on github, the data shown in the message is the only data that is stored and it is stored strictly for troubleshooting and providing support.

I suppose the phrase "anonymised" implies that PII is stored and then removed in the logs, that isn't the case no info about the user is stored or collected as , again, you can verify in the source code itself.

As for the data itself it does expire 60 minutes after transaction is completed.

Thank you for reading,
Alison Bobert

Hello joniboini,


The code on GitHub is actually the MVP (Minimum Viable Product) I showed to investors, while it is fully functional, it's incomplete. Unfortunately I can't host a live demo anymore as the servers were run by my former sponsor.

On the subject of development approaches, I mostly do backend development, as I am not that skilled at frontend design and usually just offload that to another developer. My recommendation is that you focus more on the backend, as, in my view, it is more important.

As for comparisons with other implementations, I developed this solution from scratch, so I cannot speak to its similarities with other opensource exchange templates(if there are any available). However, if you're interested in creating similar applications, I would strongly recommend using Go. You're welcome to use my template as a reference for your own projects.

If you have any other questions, I'm open to talk.

Thank you for reading,
Alison Bobert

Hello Vod,

I'd be happy to elaborate on my ideas,


While it is true that cryptocurrencies, like other mediums of exchange such as cash, can be misused by bad actors which strongly condemn. However, I don't believe that state surveillance is the appropriate solution. As Benjamin Franklin said, "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety". I believe that this principle aligns with fundamental value of bitcoin. In my view, the threat posed by excessive state surveillance far outweighs that of bad actors.

Regarding legality, while this approach may not comply with regulations in certain jurisdictions, it remains compliant in others. I do not advocate breaking the law, and a potential compromise could be making a good faith efforts to geo-block restricted regions. Nevertheless, I remain committed to upholding the core value of financial privacy and will not implement kyc capability.


The data in question looks like this I redacted addresses and transaction ids:
"[<DATEANDTIME>] [ERROR] Order failed with error: insufficient funds, main.ExchangeSession{OrderID:"b0a06943af3df054", Status:"EXCHANGING", FromCurrency:(*cryptoManager.LtcHandler)(0xc0002aa000), ToCurrency:(*cryptoManager.EthHandler)(0xc000134a20), FromCurrencySign:"LTC", ToCurrencySign:"ETH", FromCurrencyID:2, ToCurrencyID:4, FeeRate:1, SendAmount:0.0013312683123676756, ReceiveAmount:0.035, ToAddress:"<REDACTED>", FromAddress:"<REDACTED>", RefundAddress:"<REDACTED>", ToTransactions:[]cryptoManager.CryptoTransaction{}, FromTransaction:cryptoManager.CryptoTransaction{Txid:"<REDACTED>", Confirmations:1, Amount:0.35, Explorers:[]*cryptoManager.CryptoTransactionExplorer{(*cryptoManager.CryptoTransactionExplorer)(0x7ff7f819b180)}}, ToConfirmations:12, FromConfirmations:1, ExchangeRate:<REDACTED>, ErrorMessage:"", ExpirationTime:<REDACTED>, CollectionTime:-1}"

As shown, when an error occurs, the system logs the relevant transaction state, including the error and technical details, without exposing personally identifiable information (such as IP addresses). This allows for effective debugging while maintaining user privacy.


The Go programming language was created with the idea of powering backends of web application in mind since the very beginning and thus it has a robust standard library that minimises the need for external dependencies when building web backends. While I have no objection to using well-maintained libraries where necessary, many codebases (particularly in Node.js) exhibit excessive dependency bloat, for example importing entire frameworks just to use a single function.

Though both Go and Node.js are secure by design, each additional import increases the potential attack surface. Therefore, it’s considered good security practice to keep dependencies to a minimum. This doesn’t mean reinventing the wheel, but rather being deliberate about dependencies.

Thank you for reading,
Alison Bobert

Hello, I'm Alison Bobert.

For many years, I've been actively involved in the cryptocurrency space and remain dedicated to Satoshi Nakamoto's original vision, which includes ideas like decentralisation, privacy, inflation resistance, and autonomy from banks and the governments, unlike many institutions today (e.g., the ETH Foundation) that prioritise compliance and centralisation above all.

I've stayed away from custodial wallets and centralised exchanges, following the tenet, "Not your keys, not your coins". Rather, I have used self-hosted full nodes like Monero and Bitcoin Core. However, clients occasionally prefer paying in other cryptocurrencies (e.g., Ethereum, Litecoin, or USDT), requiring me to convert them to Bitcoin.

For years, I used exch(.cx/.net), a platform that aligned with my values, prioritising privacy, low fees, no KYC, and no arbitrary freezes. Unfortunately exch is no longer available, and as centralised exchanges increasingly impose restrictive policies, high fees, and fractional reserve scams. This left a gap in the market for a truly privacy-focused exchange.

To address this, I began developing a new privacy-focused exchange. Initially, I secured a sponsor, but due to legal complications on their end, the funding fell through. Without the necessary resources, I was forced to halt development. Rather than let the project disappear, I’ve decided to release the entire source code (frontend and backend) publicly.

Project Overview

This codebase is a fully functional prototype originally intended for investor review. While it lacks some planned features (e.g., distributed architecture, DDoS protection, and persistent storage), it serves as a solid foundation.

Privacy-First Design

This exchange was built from the ground up to respect user privacy at every level. Unlike mainstream platforms, it deliberately avoids JavaScript, cookies, and any form of tracking. It doesn't log users ip, headers or tls fingerprints and of course it doesn't have a capability to freeze funds for any reason.

Technical Details

The backend is written entirely in Go, providing cross-platform support (though currently only tested on Windows).It maintains a minimal amount of imports to reduce potential attack surfaces while implementing advanced form parsing for additional security. Price data is retrieved via CoinMarketCap's WebSocket API. The system requires users to run their own full nodes for each supported cryptocurrency - following the essential "don't trust, verify" principle. In my setup, Bitcoin, Litecoin, and Monero nodes ran on one server, while the Ethereum node (using Lighthouse + Geth) ran on another.  The architecture leverages Go interfaces, making it easy to add support for additional cryptocurrencies without modifying core design. All operations, including refund processing, are fully automated and utilise anonymised data for troubleshooting. Notably, except for price feeds from CoinMarketCap, all functionality is handled locally through node interactions without relying on third-party services.

Code

https://github.com/AlisonBobert/AlisonsCryptoExchange

Thank you for reading,
Alison Bobert