Pursuit of Privacy: AMA Salvium
INTERVIEW · AMA · 21 August 2024
Pursuit of Privacy: AMA Salvium
This AMA was hosted by Mr Kwibs from the Pursuit of Privacy Telegram community, with answers from Scylark, Jethro Toll and SomeRandomCryptoGuy of the Salvium team. Reformatted for readability; the dialogue is preserved as faithfully as possible.
Connect with Salvium
- Website: salvium.io
- Discord: discord.com/invite/P3rrAjkyYs
- Telegram: t.me/salviumcommunity
The AMA
Q1 — To start the AMA, can you tell us the story behind the Salvium project, and what it aims to achieve?
Scylark (Salvium): Thanks — firstly, it’s good to be here. 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’. He highlighted the trade-offs between privacy, scalability and functionality and laid out a proposal using dual outputs to enable payment channels and a lightning-network style L2.
While working through ideas, 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. Fulmo became too limiting a name, and Salvium was born.
Q2 — Can you tell us about each team member’s background?
Scylark (Salvium): 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 fully doxxed and their careers are known. Dweab started as a software engineer and mathematician then went into high-level corporate roles. Neac has been a software engineer for over 30 years and is also an accomplished mathematician and cryptographer. Beyond these two, there is a wider team with skills in economics, finance, DevOps, technical and creative.
Q3 — You have chosen to lock 12% of max supply in a contract with gradual release over 24 months. Why this setup over a block tax, premine, or community donations?
Scylark: 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 pre-launch development. By releasing 650,000 SAL per month, we have a stable funding source to deliver on our roadmap. Community donations or ongoing developer fees either lacked financial stability or posed potential conflicts of interest. The 24-month lock-up 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 this. This model allows us to focus on development without short-term market pressures.
Q4 — Isn’t allocating funding over 24 months risky given current market conditions? What are your plans after those 24 months?
Scylark: 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. Transparency with our community is crucial.
Q5 — How are Confidential Transactions implemented in Salvium, and how do they differ from Monero or Zcash?
Scylark: Salvium’s Confidential Transactions (CTs) are the same as Monero’s, with the exception that Salvium provides uniformly random commitment masks for all consumed outputs (Monero does this only for some), reducing the potential for information leakage.
Q6 — How will staking rewards (currently 20% of block rewards) evolve as DeFi features come online?
Scylark: The current 20% share of block rewards for stakers will remain in place as we begin rolling out DeFi features. As DeFi applications grow and generate revenue, we’ll gradually transition from block-reward staking to a gas/fee distribution model. We’ll be transparent about any changes and seek community input. A governance model is planned but still to be defined by the community and network participants.
Q7 — Can you detail the cryptographic process behind anonymous refundable transactions, and how they integrate with stealth addresses and ring signatures?
Scylark: Our approach builds upon the ‘Return Address Scheme’ originally proposed by Knacc for Monero in 2019, adapted for Salvium’s regulatory compliance goals. We developed the mathematical proof in early 2024, and CypherStack audited it just before mainnet launch. When Alice sends a transaction to Bob, she includes an encrypted ‘return address’ (F_ab), encrypted using a Diffie-Hellman shared secret so 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. The method preserves privacy by using stealth addresses and ring signatures, maintaining unlinkability and anonymity. The refund amount is verified using Pedersen commitments and range proofs.
Q8 — How is the ‘view key’ mechanism for exchange compliance technically implemented?
Scylark: The view-key mechanism is currently being developed. 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. Even with a view key, the observer cannot link transactions to external identities or connected addresses. Security measures include revocable keys, access logs, and selective disclosure where users choose which transactions or time periods to share. Third-party audits are planned before full deployment.
Q9 — How are Asynchronous Transactions (AT) secured against double-spending and conflicts?
Scylark: ATs are secured through the same cryptographic primitives as standard transactions: ring signatures and Pedersen commitments. Each AT is linked to a unique ‘input context’ derived from its inputs, ensuring it cannot be reused. The AT process involves a ‘burn’ transaction to lock funds and a ‘mint’ transaction to unlock them. Our modified PoW consensus includes additional validation rules. If multiple mints attempt to claim the same burn, the first-seen rule applies, with timing constraints to prevent long-term pending transactions.
Q10 — What concrete DeFi use cases benefit most from Asynchronous Transactions?
Scylark: ATs enable complex DeFi operations: time-locked contracts (vesting), decentralized lending (collateralized loans with automatic release), conditional payments (escrow until goods delivered), yield farming (locking stakes and minting rewards over time), and Layer-2 solutions (faster, cheaper transactions off the main chain with on-chain settlement). They separate fund-locking from final transfer, enabling sophisticated financial instruments within a privacy-focused framework.
Q11 — How are Transactional Imbalances (TI) created, managed and resolved? What are the privacy implications?
Scylark: TIs in Salvium allow inputs to exceed outputs, creating imbalances managed by the protocol_tx mechanism. They enable advanced features like staking and asset conversion, impossible in traditional systems where inputs must equal outputs plus fees. While the imbalance amount is visible, transaction details remain protected through ring signatures and RingCT. TIs link initial transactions with their resolution, potentially aiding timing analysis — mitigated by one-time addresses and delaying yield resolutions.
Q12 — The privacy-coin landscape is already crowded. Why is Salvium essential?
Scylark: Salvium addresses several key challenges in the privacy-coin sector. We balance strong programmable privacy with regulatory compliance, opening the door for privacy coins in regulated markets. Our introduction of Transactional Imbalances and Asynchronous Transactions enables complex DeFi operations, with the potential for simple porting of EVM dApps and tokens in the future — each becoming private once on the Salvium chain. Salvium is essential for demonstrating that privacy, functionality and compliance can coexist.
Q13 — Can you tell us about the genesis of ‘Protocol_Tx’?
Scylark: Protocol_Tx was the trigger mentioned at the start of this AMA — the moment it was built as a secondary ‘coin base’-style transaction to deliver yield was the moment we understood the true power of Asynchronous Transactions and Transactional Imbalance, which are the building blocks of protocol_tx.
Q14 — Anything else you would like to add about Salvium?
Scylark: Salvium is not just another privacy coin; it represents a forward-thinking approach to cryptocurrency. We’re addressing both current challenges and anticipating future needs in the privacy coin sector. Our work on combining privacy, compliance, DeFi integration and scalability positions Salvium uniquely in the ecosystem, with the potential to set new standards for what privacy-focused cryptocurrencies can achieve.
Community questions
What major difficulties did the team face while developing the project and how did you overcome them? — Johan Quintero
Scylark: I think our biggest challenge was finding a new way to solve the problem of yield. Since the amount of yield was known to be variable, we had to separate the staking from the payout. That led to the development of protocol_tx, and to the idea of TIs in particular.
How many team members do you have? Do they have enough crypto and non-crypto experience? — Harper
SomeRandomCryptoGuy: We have 2 ‘proper’ devs, with more than 40 years combined experience of cryptography software development between them. We have a good team around us, supporting the dev effort with everything from DevOps to marketing.
Is the view-key system inherited from Monero? Full view keys or only incoming? Also, the return-address compliance feature can’t guarantee the embedded address has spend authority. — Reuben (FIRO)
SomeRandomCryptoGuy: The current view-key system is indeed inherited from Monero — incoming view keys only. We’re looking to address this with a future update, and have been keeping an eye on aspects of FCMP as a possible solution. On return addresses: you are correct — we have not finished the work to close the loop for spend authority. We have identified that as part of the work needed for compliance. We also note that our implementation of Knacc’s proposal is incomplete, because we have limited to 2-out TXs for launch. This is a work in progress.
Thanks to Scylark, Jethro Toll and SomeRandomCryptoGuy for taking the time to participate. We will be following this project closely.
Stay in the loop
Crypto Lowcap is an independent media outlet covering privacy, decentralization and low-cap innovation since 2016. We never accept paid coverage — our analyses are our own.
Follow Rowenta on X · Follow The Dowser on X
Liked this piece? Share it, challenge it, or send us the next project we should investigate.
