On August 20th, the Salvium devs joined the Pursuit of Privacy community for an AMA. Thanks for hosting—it was a great discussion!
In this AMA, we explore Salvium’s origins, its Confidential Transactions, staking model, and key innovations like Asynchronous Transactions (AT) and Transactional Imbalances (TI). We also discuss the team’s funding strategy and how Salvium aims to position itself as a leader in the privacy coin space.
1. To start the AMA, can you tell us the story behind the Salvium project, and what it aims to achieve?
Salvium was originally called Fulmo as a nod to Monero (meaning ‘coin’), Fulmo means ‘lightning’ in Esperanto. The original concept was inspired by a presentation by Pedro Moreno-Sánchez at MoneroKon 2019 on “Dual Outputs: Enabling Payment-Channel Networks in Monero”. You can find it on YouTube. He highlighted the trade-offs between privacy, scalability, and functionality in cryptocurrencies and laid out a proposal using dual outputs to enable payment channels, and a lightning network style layer 2.
While working through various ideas to use this extended capability set, and considering what things like conditional payments would enable, a prototype was built for a yield payment system that paid out asynchronously. Only at that point did it become clear that if you can send a transaction at one point in time, and have it do ‘stuff’ at some point in the future, then return it securely and privately—you’ve just built a system capable of running code on the blockchain.
So Fulmo became too limiting a name, and Salvium was born.
2. Can you tell us about each team member’s background? Have you worked on other projects before?
While we haven’t focused on individual identities, we’re not anonymous. But we are also not seeking exposure. The lead developers are known in the space as Dweab and Neac and are responsible for creating the coloured coin technology used in projects like Haven Protocol. Both are also fully doxxed, and their careers are known. Dweab started as a software engineer and mathematician and then went into high-level corporate roles. Neac has been a software engineer for over 30 years and is also a very accomplished and capable mathematician and cryptographer.
Beyond these two individuals, there is a wider team of contributors that have a broad range of skills, including economics, finance, DevOps, technical, and creative.
3. You have chosen to have the project funds (12% of max supply) locked in a contract with gradual release over 24 months. Why did you choose this setup over other funding options, such as a block tax, premine, or community donations?
We chose a 9% premine with a 24-month gradual release because it provides both transparency and financial stability. Another 3% was allocated to early contributors and the founding team, compensating them for nearly a year of development and costs before launch.
By releasing 650,000 SAL per month, we have a stable funding source to deliver on our roadmap. We considered alternatives like community donations or ongoing developer fees, but those options either lacked financial stability or posed potential conflicts of interest. The 24-month lock-up also shows our commitment to the project’s long-term vision. In August 2024, we locked one month of unused payments for another two years to demonstrate our long-term commitment. This model allows us to focus on development without short-term market pressures.
4. People rarely discuss the choices of tokenomics and project financing (rewards/premine) over a timeline. Don’t you think your choice to allocate Salvium’s project funding with a token release over 24 months is risky given the current market conditions? It seems like a short-term bet where a bull market within the next two years is necessary to ensure your funding for the subsequent years. The timing of sales must be very well chosen to avoid running out of funding for future developments (after the first two years). What are your thoughts on this?
The 24-month release was designed to meet Salvium’s initial funding needs while aligning with the community’s interests. We’re aware of the market risks, but we aren’t relying on a bull market. Our strategy includes prudent financial management, a flexible development pace that can adapt to SAL’s value, and the potential for locking additional unused SAL tokens for future use. This is to build real value and generate trust and ongoing interest. Transparency with our community is crucial throughout this process.
5. The Knowledge Base section of your website mentions that Salvium uses ‘Confidential Transactions’ to mask transaction amounts. Can you explain in detail the cryptographic mechanism used to implement these confidential transactions, and how it differs from implementations in other blockchains like Monero or Zcash? Additionally, how do you manage the verification of transaction integrity without revealing the amounts?
Salvium’s Confidential Transactions (CTs) are the same as Monero’s, with the exception that Salvium also provides uniformly random commitment masks for all consumed outputs, as opposed to some consumed outputs as Monero does, creating a reduction in the potential for information leakage.
6. Staking on Salvium is based on periods of approximately 30 days (21,600 blocks) with a yield of 20% of block rewards during the initial phase of the project. How does the Salvium protocol plan to adjust these staking rewards during the transition to a fee-based DeFi model, while maintaining sufficient incentives for participants?
Maintaining network security and participant incentives is a priority. The current 20% share of block rewards for stakers will remain in place as we begin rolling out DeFi features in the future. As DeFi applications grow and generate revenue, we’ll gradually transition from block reward-based staking to a gas/fee distribution model. This transition will be carefully managed, ensuring that stakers continue to receive attractive rewards.
We’ll be transparent about any changes and seek community input to strike the right balance, ensuring the economic model remains sustainable as we expand DeFi capabilities.
7. Salvium introduces anonymous refundable transactions as a compliance feature. Can you detail the cryptographic process that allows for an anonymous refund of a transaction while ensuring the exact amount is returned to the correct sender? How does this mechanism integrate with other privacy features of Salvium, such as Stealth Addresses and Ring Signatures?
Our approach builds upon the “Return Address Scheme” originally proposed by Knacc for Monero in 2019, adapting and extending it to meet the specific needs of Salvium’s regulatory compliance goals. We developed the mathematical proof for this in early 2024, and CypherStack audited it just before the launch of Salvium’s mainnet.
Salvium’s refundable transactions are an optional feature that integrates privacy with regulatory compliance. When Alice sends a transaction to Bob, she includes an encrypted “return address” (F_ab) in the transaction, which Bob can later use if a refund is needed. This return address is encrypted using a Diffie-Hellman shared secret, ensuring only Bob can decrypt it. If a refund is required, Bob can use this information to create a new transaction without knowing Alice’s actual address. This method preserves privacy by using stealth addresses and ring signatures, maintaining unlinkability and anonymity while enabling refunds. The refund amount is verified using Pedersen commitments and range proofs, ensuring the integrity of the transaction.
8. In the Knowledge Base section, it is mentioned that exchanges require the ability to monitor transactions in authorized wallets via a ‘viewkey’ mechanism. Can you explain how this ‘view key’ mechanism is technically implemented in the Salvium protocol, and how it ensures both user privacy and regulatory compliance? What security measures are in place to prevent the abuse of these ‘view keys’ by ‘authorized entities’?
The view key mechanism is currently being developed. It is being designed as an optional feature to balance privacy with compliance. Salvium will use a dual-key system: a ‘view-balance key’ (k_vb) and a ‘master key’ (k_m). The view-balance key allows authorized entities, like exchanges, to monitor transaction history and balances without the ability to spend funds. The master key remains necessary for spending and preserving security. Even with a view key, the observer cannot link transactions to external identities or connected addresses, ensuring privacy. Security measures include revocable keys, access logs, and selective disclosure, where users can choose which transactions or time periods to share. This system is
