Salvium Protocol AMA With Our Crypto Talk

There’s a pattern you start to notice in crypto after a while. Every few months, a new project shows up claiming it has “fixed” something fundamental. Faster than Bitcoin, cheaper than Ethereum, more private than Monero. Most of the time, it is just positioning. So instead of taking that at face value, we decided to do something different this time.

We sat down with the team behind Salvium and asked them the questions that actually matter. Not the surface-level pitch, but the uncomfortable ones. Why build something new instead of contributing to Monero? What exactly are you doing differently? And where does this fit in a world that is clearly becoming more hostile toward privacy coins? What came out of that conversation was not what you would typically expect from a project trying to compete with Monero….

Q1) Some people may describe Salvium as an “evolved” version of Monero. What specific limitations in Monero’s current design pushed you to build something new instead of just contributing improvements back to the Monero project itself?

“It was a combination of factors, really. Monero had decided not to pursue a proposal by knacc to implement a “return address scheme” back in 2019, but Dweab and I saw the advantages of such a mechanism as a core for new functionality such as staking and anonymised return transactions.

At the time, regulatory frameworks were already being considered by many regions (US, EU, UK), and as Dweab and I read more and more about the proposed legislation, it became clear that the future of privacy coins was not the absolute that was being sought by the likes of Monero, but more of a pragmatic approach (such as that taken by the fiat banking system). Bitcoin is far too public, in our estimation. Monero, on the other hand, is too private.

So we built a middle path – compliant privacy. The man across the road knows nothing about your wallet balance just because he knows your address…but you can share the information with the regulatory authorities if they come knocking.”

Q2) Monero is already seen as the gold standard for privacy. In simple terms, what does Salvium actually do better or differently today – and why would someone who already uses Monero consider switching?

“Ok, so we have staking, and we have return payments. We delivered Carrot (a Monero innovation) to a mainnet before Monero did, which is mostly because we have agility on our side. Carrot was instrumental in underpinning SPARC – a set of cryptographically secure functions (namely “anonymous return payments” and “spend authority proofs”) that give Salvium the demonstrable ability to support the requirements of the MiCA and AML (anti money laundering) regulations when being listed on a regulated exchange.

Now we have Salvium Assets, too. User-defined tokens that can utilize the Salvium chain as a means of supporting immutable transactions for RWAs, NFTs, etc. We’re only just beginning to scratch the surface of how these tokens can be used – it’s very exciting to see entire ecosystems evolving with Salvium as the engine that drives them.

We also have a formal legal opinion that states Salvium can be listed safely by MiCAR licensed exchanges. That’s HUGE – when other privacy coins (including Monero) are being delisted by all of the major exchanges, it’s leaving a vacuum in the market that Dweab and I foresaw. Salvium is perfectly placed to exploit that vacuum.

Moving forward, things are about to change significantly. There’s an open secret about what’s coming in the next year or so for Salvium – ERC20 bridged assets. This will give people the ability to move their publicly-visible ERC20 tokens through a bridge and into the Salvium chain. Transactions will gain exactly the same level of privacy as all other Salvium transactions, and retain the advantage of full compatibility with the financial regulations.

Looking further ahead, there will be smart contract + DeFi functionality coming to Salvium. I can’t speak too much about this, for obvious reasons, but the future is looking really bright for the project.

We’re not content to deliver nice-to-have tweaks to Monero any more. We’re shooting for the stars.”

Q3) You’ve introduced things like T-CLSAG signatures, an evolution of Monero’s original CLSAG design. How would this actually improve privacy or usability compared to what Monero uses today – and what practical difference would a user notice?

“T-CLSAG was born of necessity. Whilst Monero have been biding their time on delivering Carrot, and waiting until it could be deployed alongside FCMP++ (which is a massive boost to privacy), we needed to maintain forward momentum, and we needed to deploy Carrot so that SPARC could exist.

In terms of what a user might notice – hopefully absolutely nothing! It’s designed as a drop-in replacement for CLSAG, to facilitate Carrot addressing scheme (something CLSAG cannot do, because Carrot addresses are designed around dual-scalar rather than single-scalar private keys).”

Q4) Salvium still relies on core pieces like Stealth Addresses, Ring Signatures and RingCT. How do you make sure that adding features like native staking or refunds doesn’t accidentally compromise the strong privacy guarantees Monero is known for?

“That’s a good question. In order to answer properly, you need to understand a little about the technical side of what Salvium is. At the core of most of the Salvium-specific functionality is the “return address scheme” that knacc devised nearly 7 years ago.

We’ve built a lot on top of the core idea that was presented then – a means of creating a private return onetime address through which funds can be sent without knowing the wallet address of an individual.

It works a bit like this: Alice sends a payment in a transaction to Bob. In the transaction, Alice also encodes information that only Bob can read, and which Bob can use to generate a one-time “return payment” back to Alice. Through some clever zero-knowledge magic, Alice will receive the funds sent to her using this process.

That’s been built into Salvium since the genesis block. Except, it’s had to evolve somewhat. First, Alice was able to modify her wallet to ensure that funds were actually NOT sent to her wallet, but to a 3rd-party wallet (let’s call it Charlie’s wallet). This would have facilitated money laundering, and because Salvium (like Monero) relies on stealth addresses, nobody would have been any the wiser. So Salvium One’s SPARC functionality introduced a “Spend Authority Proof”, which proved (in zero knowledge) that Alice knows the private spend keys to the wallet that the funds are returned to (i.e. it’s her wallet, for all intents and purposes).

Return payments triggered by Bob are great – they solve one of the cornerstones required by MiCA. But to implement staking and yield, the mechanism needed a little tweaking. Our other key innovation was “protocol_tx” – a second coinbase transaction included in every block, that could utilize a variation of the return payment mechanism to return generated coinbase amounts to users anonymously without having a wallet address itself.

So now you see how the core functionality of Salvium works. In order to ensure that we didn’t compromise the privacy afforded us by Monero, we’ve done 3 things:
a. built on top of the underpinnings that Monero provided, rather than replacing them,
b. consulted with Monero devs along the way, and
c. had the math and the code of each Salvium innovation audited to ensure that the security and privacy of the project was not degraded by our enhancements

Moving forward, this pattern of consultation, audit and security reviews will of course continue. As new Monero improvements are made, we’ll look to incorporate them as well (one notable example is FCMP++, although we’re actively developing a competitive solution in the form of an ongoing internal project called “Lettuce”.

We’re looking at reducing proof sizes and verification times over FCMP++ by reducing the anonymity set sizes through a process called sharding. Oh, and Lettuce has a defined upgrade path to full quantum resistance – the entire Lettuce architecture was designed from the ground up to allow migration from EC to PQ cryptography without breaking anything…)”

Q5) A big part of your selling pitch is making a privacy coin that can still get listed on regulated exchanges under MiCA. How do features like Exchange Mode, view keys, CARROT addressing, and SPARC make that possible without turning Salvium into something that’s effectively traceable?

“MiCA regulations don’t, for the most part, actually apply to Salvium – they apply to the exchanges who might list Salvium. The two key areas that we have had to solve are:
a. anti money laundering (which SPARC has solved by proving that the funds returned by an exchange are indeed being returned to the control of the individual that sent them) and
b. The ability to provide (upon request by an authorised party) visibility of your full transaction history (ingoing and outgoing) – this is why Salvium adopted Carrot as the addressing scheme from Salvium One onward (specifically, because Carrot provides output view keys that allow you to see spent as well as received outputs)

Exchange mode is an extension to the wallet, which allows automatic locking of incoming payments. This is to guarantee that the funds don’t end up in the same “pool” of money as approved payments by automatic sweeping systems that are often employed by exchanges. It allows funds to be shielded and then later returned to the sender directly (rather than just sending the correct amount).

But all of these innovations have been built without compromising things like stealth addresses. So there’s no traceability beyond that which is provided by Monero already.”

Q6) You’ve mentioned “programmable privacy” and selective disclosure. In plain English, how does a normal user decide when to keep things fully private vs. when to share info – and who ultimately controls that choice?

“Oh the user always has the choice, because they’re the only ones that know their private keys. Moving forward, we anticipate that some of the regulated exchanges will make a move towards requiring their customers to provide a private view key as part of their KYC information. But at present, this isn’t strictly required by MiCA regulations (or indeed any other regulatory schemes we are aware of).

If a regulated exchange is approached by the regulatory authority, it is anticipated that the exchange would then ask the user for the private view key for their wallet. It is ultimately up to the user to choose whether to provide that or not, and accept the consequences accordingly.

Salvium can only provide the tools to make it acceptable for a regulated exchange to offer Salvium. We can’t disclose secret information about users or their wallets, because we simply don’t have it – that’s a guarantee that we can offer because we’re built on top of Monero.”

Q7) Monero doesn’t have native staking. How does Salvium introduce staking and yield on a Proof-of-Work chain while keeping everything private and secure? Can you walk us through a simple example of how a user would stake and earn yield?

“It comes back to the core principle of “protocol_tx” – a second coinbase transaction in every block. So, as of April 2026, a proportion of the block reward for each block is “burnt” by Salvium (in other words, coins that were meant to be issued by the miner_tx in the block were held back). These coins contribute to the “yield pot” that is tracked continuously by all nodes, and is immutably recorded on the blockchain.

When a user submits a “STAKE” transaction, they also burn some of their Salvium coins, and that amount is tracked in the blockchain against their return address and the height at which the transaction is mined.

Every block, the blockchain is checked to see if there are any STAKE transactions that have reached maturity (i.e. their mining height was 21,601 blocks before the tip of the chain). If they have, then an entry is created in the next block’s “protocol_tx” transaction, which calculates the proportion of the total locked coins for each of those blocks that the user had burnt, and multiplies that proportion by the number of coins added to the “yield pot” for each of those blocks, and sums the results into a single total to be paid as “yield” to the user. It adds the original “STAKE” amount, and mints the correct number of coins to repay the user.

To understand the math, let’s work through a toy example. Let’s say that Alice submitted a STAKE of 100 SAL1 coins at height 100,000. Let’s pretend for a moment that nobody else has submitted any STAKE transactions between Alice’s submission and when it matures.

Let’s assume that the “yield pot” receives 25 SAL1 per block (in practice, the amount is always reducing very slowly, because the block reward is also reducing). In this instance, Alice is going to receive her original burnt coins (100 SAL1), plus the entire yield pot (25 * 21,600 = 540,000 SAL1), so a total of 540,100 SAL1.

If Bob had submitted a STAKE transaction of 100 SAL1 exactly 10,800 blocks after Alice, then Alice would “lose” 50% of the yield pot for the last 10,800 blocks, meaning Alice would receive 405,100 SAL1 (because Bob would have received 12.5 * 10,800 = 135,000 SAL1 from the yield pot during the period where his and Alice’s STAKE transactions overlapped).

Whilst the math can get really messy on paper when you have 100 different people staking 100 different amounts at slightly different times, the process works flawlessly.”

Q8) You use new concepts like Transactional Imbalances and Asynchronous Transactions to enable yield and future DeFi. What problems are these solving that Monero can’t – and what new use cases do they unlock? E.g private stablecoins or lending.

“Transactional Imbalances” is the technical term for our ability to burn coins in a user-submitted transaction, and is fundamental in our BURN, STAKE, AUDIT, and CREATE_TOKEN functionality. “Asynchronous Transactions” is the technical term for our ability to hold coins from a user-submitted transaction, and then reissue in a later transaction. This is most clearly seen in STAKE, of course, where the blockchain “keeps hold” of user funds for a predetermined period of time.

Looking ahead to Salvium Two, both functions will be key to developing things like smart contracts (which will be able to hold user funds for lending purposes, for example). They’ll also be critical in the upcoming ERC20 bridging technology.”

Q9) Refundable payments sound super practical. Can you walk through a real-world example of how a user or business would use that – and why this isn’t something Monero users already have?

“Exchanges are an existing example of how return (i.e. “refundable”) payments are useful. If an exchange receives funds to a particular subaddress, historically they’d just credit the balance and carry on. But with MiCA, that is simply not allowed because of the potential for money laundering. Salvium allows an exchange to comply with the AML regulations in many territories by locking those funds and allowing them to be uniquely identified and returned to the original owner.

Moving forward, return payments become way more useful. Imagine a smart contract that lends deposited funds, and pays “interest” periodically. The return address scheme in Salvium One can be used to make only a single payment of the full amount (minus the return TX fee)… but Salvium Two will improve upon that by implementing an “anonymous return payment channel”, which will allow any number of payments, and of any value, to be made back to the original owner… without ever having to disclose their wallet address.

Monero simply doesn’t have this functionality. It doesn’t have a proving scheme for addressing AML issues, and it doesn’t have a mechanism for returning payments without disclosing the wallet address of the originator.”

Q10) You’ve made some significant changes to the emission model – significantly increasing block rewards and extending the supply curve. What was the core reasoning behind that shift, and how do you see it translating into stronger liquidity and broader adoption compared to Monero over time?

“Mostly, the idea was to flatten the curve to lengthen the viable POW window, and to prevent too much early concentration of funds. Some of the changes we made were as a consequence of us needing to fund the project, and working out ways to try and make it all as equitable as possible in not only the short term but the lifetime of the project. A 2 year roadmap that we’ve nearly managed to stick to, despite some setbacks along the way! We also had to try and work out how long we needed the block rewards to support staking, before fees from other mechanisms (such as smart contracts) were able to take over.

I think that, when the world sees not only what we have already delivered but also what we’re working on right now and where we’re aiming to be in the medium term, our choices will be vindicated.”

Q11) Private smart contracts and full DeFi are on the roadmap. What’s a realistic timeline for things like a private DEX, lending, or stablecoins – and how do you plan to keep those contracts private when most chains leak data during execution?

“I wouldn’t like to say exactly when we’re going to deliver Salvium Two (which will contain the private smart contract functionality), but we’re aiming to deliver within the next 12 months. Certainly the adoption of the “Milestones” approach to delivering Salvium Two is already paying dividends – we are approximately ⅓ of the way through Milestone 2 now.

As for how we’re going to keep smart contracts private, well that’s a bit of a trade secret! The key is to have the transactions that trigger contract execution to be as fungible as possible. By using stealth addresses for smart contracts, combined with encrypted payload that is essentially replaced with random noise in “normal” transactions, should make analysis extremely difficult, if not impossible. That, combined with the massive increase in anonymity provided by FCMP++ (and Lettuce), means that all interactions with smart contracts should be fully hidden.”

Q12) Privacy coins often run into scalability and blockchain bloat issues over time. How is Salvium planning to stay fast and affordable as usage grows, especially once DeFi features come into play?

“Good question. We’re looking at layer-2 solutions that will allow Salvium to scale more effectively. You can already see we’re taking (small) steps in that direction with the introduction of ROLLUP transactions in Milestone 1. At present, they’re designed to just pay SAL1 transaction fees for transfers of non-SAL1 assets… but they’re designed to scale to provide preauthorisation on layer-1, so things like L2 reconciliation and settlement and finality are in the future for ROLLUP.

There’s a much bigger issue coming in the next couple of years – quantum resistance. The requirement for QR is undeniable, and solutions are going to appear soon enough. But what is perhaps glossed over somewhat is the significant increase in TX sizes that will be triggered by the post-quantum era. That’s part of why we are already looking at ways to mitigate the size of PQ transactions in Lettuce (which in its EC prototype was already producing smaller proofs than FCMP++). That, and ROLLUP transactions, and emerging cryptographic advances, should all play a part in keeping the chain fast and affordable.”