Have been trying to find time to build this for a while, but didn’t have the time so sharing rough details here. If anyone wants to pick it up, can offer more help.
I call it Aguamenti because it attempts to conjure liquidity for Grin.
Introduction
Privacy-preserving cryptocurrencies like Grin and Monero face liquidity issues as traditional routes such as centralized, regulated exchanges do not support these currencies. Decentralized exchanges are a step in the right direction, but have their own challenges with their order book and privacy models. This proposal suggests a different set of trade-offs for making the link between privacy and short-term liquidity until there are more viable MPC models that preserve long-term privacy.
Aguamenti tries to combine elements that already work well enough (but not perfectly) to facilitate simple, useful, decentralized and privacy-friendly peer-to-peer liquidity. A combination of the Bitcoin blockchain and Tor hidden services are used by liquidity providing peers (LPs) and trade-seeking peers for discovery and communications. Quotes are generated by the CFMM[1] (Constant Function Market Maker) algorithms of the LPs for atomic swaps between supported currency pairs.
LPs will load their wallet with a 50/50 balance per market value for two supported currencies (the 50/50 ratio can be adjusted with more advanced CFMMs). A CFMM will then provide theoretically unlimited liquidity to a counterparty for any transaction. However, there may be other peers with a more favorable rate generated by their own CFMM due to a combination of CFMM balance weight, ratio, current balance and trade size.
Peers looking for swaps will scan the Bitcoin blockchain for specifically encoded transaction data containing Tor addresses of peers offering liquidity. The peers will then communicate to their counterparties providing liquidity via API through Tor at these addresses to agree quotes and complete the interactive cycles required for atomic swaps without trust.
Details
Protocol Transactions
Aguamenti can be decentralized and resilient using the Bitcoin blockchain for discovery and peer reputation. Without it, a centralized server or complex DHT network would likely be required for peers to discover each other to perform an exchange.
Some believe that the Bitcoin network should not be used to store information beyond what is needed to transfer Bitcoin. For this reason, we must do our best to politely and efficiently use the network by consuming only prunable and usable data.
LPs only need to send a single Bitcoin transaction with the minimum dust-free value to be included in the discovery. Peers will initially select LPs in a randomized donation weighted order while searching for quotes. Developers can hard-code a bitcoin address in the client that they can spend and use as a “protocol address”. LPs will send transactions with associated outputs to this address to compete for discovery by peers looking for liquidity for trades. Alternatively, the protocol address could be a known burn address, but that would create unusable UTXOs that inflate the Bitcoin network. In the future maybe taproot could be leveraged to make this even more efficient.
Example LP discovery registration protocol transaction snippet:
OP_RETURN [2 bytes: LP_REGISTER_ID][64 bytes: LP_ED25519_PUBKEY]
The above would be included as part of an output in a transaction also spending value to the “protocol address” by a peer LP that wishes to announce to other peers that they are offering liquidity for swaps. Peer clients seeking liquidity to make a swap would scan the Bitcoin blockchain for the OP_RETURN and IDentifier bytes associated with the “protocol address” to understand the latest network state.
Tor Hidden Services
Tor is used for all p2p communications:
- Privacy preservation properties for all peers when all p2p communications are limited to API on Tor Hidden Services
- Simpler p2p UX communications with peer liquidity providers: no need to worry about dynamic IP addresses and firewall puncture
- ED25519 public keys used for a peer’s Tor address can also be used to manage reputation
- Supports robust and private peer-to-peer interactivity required for the creation of atomic swaps
For places where Tor is blocked, in the future, protocol transactions could be extended to support the exchange of private and unblocked Tor bridges in exchange for BTC.
Atomic Swaps
Providing liquidity with atomic swaps prevents counterparties from stealing funds (although there are still risks like wasted time that can be mitigated to some extent with a reputation model).
It is already possible to do atomic swaps with the ideal initial supported currencies, Bitcoin, Grin, and Monero, so there shouldn’t be much or no new research needed here, just implementation details.
With a combination of the LP discovery method via the Bitcoin network, a p2p communication channel via Tor and programmatic pricing via CFMMs, these atomic swaps can be more robust, private and simpler compared to other models proposed for atomic swap ecosystems.
Constant Function Market Makers (CFMMs)
CFMMs[1] are a fairly straightforward idea that provide programmatic liquidity using an algorithm to keep the liquidity pool value balanced, with a % fee earned on each trade by the LP. This does not require a persistent pricing oracle or frequent manual rebalancing by the LP as the value is established in the pair when the LP fills its pool with a pair containing a 50/50 equivalent value.
In Aguamenti, each LP manages its own CFMM pool instead of all LPs locking their funds in the same pool (as in uniswap), which results in:
- No custody loss for LPs (LPs retain custody of their funds at all times until a swap is successfully executed)
- Reduced attack surface (instead of hacking a contract / multisig with $billions, the attacker must attack each LP individually)
- Resilience (a failed LP will not crash the ecosystem)
This tradeoff comes at a cost of having a worse slippage for a single transaction compared to a large pool containing all of the LP funds. This could be mitigated by a ceremony allowing LPs to pool their assets into collaborative but distributed pools. However, our goal is to provide reasonable peer-to-peer liquidity, not to be a bank.
Arbitrage
In addition to arbitrage between LPs within Aguamenti, peers who have access to outside ecosystems to exchange coins like centralized exchanges, uniswap, etc. can arbitrage the price with risk factors such as the complexity of bridges, custodial smart contracts and KYC.
Depending on the pair, LPs generally don’t have to closely follow market prices once they have filled their pool to the 50/50 value ratio and activated their CFMM. The CFMM will adjust quoted rates and arbitraging peers will pay a fee to LPs in an attempt to profit by trading at favorable rates with LPs to profit from a rate elsewhere (including other LPs).
Improvements: Invoice Agreements, Fraud Proofs, Reputation
Aguamenti’s resiliency can be improved with invoice agreements for swap details. These could be communicated and signed by the liquidity providing peer’s published ed25519 key and their counterparty’s ed25519 key before either party pushes anything to a blockchain. This ensures that if a counterparty fails to complete its portoin of the agreed swap, there is an potential for reputational recourse to attempt to offset opportunity cost of the liquidity that has not been used.
A “fraud proof” could then be generated with a combination of the signed invoice agreement and relevant blockchain data/proofs of payment. This proof could then be hashed and the hash can be included in a special encoded bitcoin transaction. Peers could use a gossip network and be incentivized with micropayments to provide the hashed data in order to verify the proof by other peers in the future. If an LP has too many valid fraud proofs, clients may automatically blacklist them.
Example possible fraud proof protocol transaction snippet:
OP_RETURN [2 bytes: LP_FRAUDPROOF_ID][32 bytes: SHA256(LP_ED25519_PUBKEY)][32 bytes: SHA256(PROOF)]
where PROOF is obtainable through the p2p gossip network.
Implementation
The implementation can be relatively simple:
- Wallet RPC wrapper for grin-wallet, bitcoin, monero (or optionally add light client support with GCS[2])
- Atomic swap helper methods for wallets
- Methods to build, scan and interpret
protocol transactionson Bitcoin blockchain - RPC APIs for offering/accepting quotes and executing swaps (with optional invoice agreements/fraud proofs)
- CFMM implementation(s) can be extended to support multiple assets and weights other than 50/50
- Tor integration to handle communication via RPC APIs served over Tor hidden services by LPs
- Add support for internal LP arbitrage and external centralized exchange API arbitrage
Ideally, there could be a single simple client used both by peers looking for swaps and peers providing liquidity to encourage more peers to offer liquidity, even if it is a small amount.
In the future, wallets can become native to the client to avoid the need for large full nodes for mobile users, for example. Golomb-coded sets[2] as used in bitcoin BIPs 157/158 could be used by Grin and Monero to provide light peer clients without the weaker verification and privacy associated with traditional bloom filtering light clients and trusted providers.
Final Thoughts
This model is imperfect but could help bootstrap privacy coin liquidity until truly private and secure MPC models are in production.
[1] https://web.stanford.edu/~guillean/papers/constant_function_amms.pdf
[2] bips/bip-0158.mediawiki at master · bitcoin/bips · GitHub