Action to shield: an on-chain subscription to a dVPN node on Sentinel.
What’s the asset’s chain? Sentinel blockchain. It’s based on Cosmos SDK. Is it IBC enabled or has it a bridge? It’s IBC enabled.
Flow of the assets:
I see three viable options to perform this action since there’s decent liquidity on both OSMO/DVPN and ATOM/DVPN pairs on Osmosis DEX.
by retrofitting privacy to ATOM from a Cosmos address and seeding with ATOM a new Cosmos address.
Cosmos address (origin) → sends ATOM via IBC to → a Namada payment address within Namada’s MASP.
Namada shielded address → sends ATOM via IBC to → a new Cosmos address.
New Cosmos address → sends ATOM via IBC to → an Osmosis address.
Swap ATOM to DVPN on Osmosis DEX.
Osmosis address → sends DVPN via IBC to → a Sentinel address (destination).
Sentinel address makes an on-chain subscription to a dVPN node.
by retrofitting privacy to OSMO from an Osmosis address and seeding with OSMO a new Osmosis address.
Osmosis address (origin) → sends OSMO via IBC to → a Namada payment address within Namada’s MASP.
Namada shielded address → sends OSMO via IBC to → a new Osmosis address.
Swap OSMO to DVPN on Osmosis DEX.
New Osmosis address → sends DVPN via IBC to → a Sentinel address (destination).
Sentinel address makes an on-chain subscription to a dVPN node.
by retrofitting privacy to DVPN from a Sentinel address and seeding with DVPN a new Sentinel address.
Sentinel address (origin) → sends DVPN via IBC to → a Namada payment address within Namada’s MASP.
Namada shielded address → sends DVPN via IBC to → a new Sentinel address (destination).
New Sentinel address makes an on-chain subscription to a dVPN node.
Observations:
After the swap (on the first two options), an additional step could be added to send DVPN back to Namada’s MASP, to finally send them to a new Sentinel address and complete the action. Maybe it’s too much, so it’d be great to know what others think about it.
On the 3rd option, a substantial amount of DVPN tokens would be needed to sit at Namada’s MASP in order to “obfuscate” in-outs.
i haven’t much experience with the MASP yet, and we just started doing IBC transactions
i wonder what @bengtlofgren thinks–is there a good way to spec out something like this?
This is a great idea and definitely feasible. It’s definitely an important use case for people who want full-stack privacy when connected to the internet. I don’t know too much about the Sentinel implementation, but the idea sounds grand!
It shouldn’t need any additional implementation from the Namada side I believe
Thank you, Gavin! I wanted to read some feedback on this from the Sentinel community before replying. As @bengtlofgren pointed out above, it doesn’t require any specific implementation on Namada.
I have been involved on Sentinel in various ways since its first testnets around 2018–2019. As a curiosity, Sentinel was one of the early projects that adopted the Cosmos SDK and migrated from Ethereum to fully develop its use case. As it’s a privacy-focused project as well, I’m really happy that I found out a potential way to add an extra privacy layer through Namada shielded actions. These act as a catalyst to enhance privacy on external domains, so this idea came naturally to my mind once I began to understand them few months ago.
In a nutshell, most members of the Sentinel community liked the concept of “Shielded Subscriptions”, while others didn’t fully understand how these would work, but are curious about - I have tried to make it clear for them answering doubts, and will continue to do so. Regarding its implementation on dVPN apps based on Sentinel, I think it could take some time, because it’s up to their respective developers to prioritize it over other ongoing developments.
and the Sentinel testnet