Thanks to @Gavin, @brentstone, @adrian and others for feedback on early versions of this post – their feedback, of course, does not necessarily consistute an endorsement.
The objective of this post is to investigate the following question:
What would it mean for Namada to be a composable privacy layer for the multichain ecosystem?
As context, the concept of “composable privacy layer” was first outlined here by @adrian on Twitter.
Product Proposition: Composable Privacy Layer
Let’s investigate this product proposition.
The basic idea is to bring privacy – as a service-like component – to existing applications in the crypto ecosystem in a way which:
- requires them to make as few changes as possible, while
- providing as much extra privacy as possible, and
- without making too many UX tradeoffs.
There are real tensions between these goals, and balancing them optimally in the long term will require more sophisticated architectural refactors (such as a switch from EVM-like or SVM-like state architectures to state architectures more like the Anoma Resource Machine). In the short-term, however, this document takes a more pragmatic approach: if we can offer existing users of existing applications (who generally have no privacy) at least some, in a way which requires little change in the logic of those existing applications and little change in user flows or habits, this would be appealing in the short term, and in the long term the underlying architectures can be slowly migrated.
What does this require, in general? I think we can describe this kind of privacy-as-a-service integration in terms of three components:
- The shielded component, involving shielded state and associated application logic, provided by Namada.
- The transparent component, involving transparent state and associated application logic, provided by the existing application.
- The connective tissue which connects the shielded component and the transparent component in a way that makes sense in terms of a holistic application experience and product proposition to users.
To concretize this, let’s consider an example. Applying this taxonomy to Osmosis shielded swaps:
- The shielded component is MASP state, specifically representations of IBC tokens which are being swapped.
- The transparent component is the Osmosis transparent token representations and swap logic.
- The connective tissue consists of the IBC logic on Namada, the IBC logic on Osmosis, and the cross-chain swap contract (originally authored by the Osmosis team, and updated/fixed by us) which lives in CosmWASM on Osmosis.
Together, these combine to form an overall product where users can hold assets in the MASP on Namada, swap them on Osmosis when they need them to + reshield the outputs again in one single action, and receive a gestalt product with (a) pretty good privacy, provided by Namada and (b) the full swap expressivity and liquidity, provided by Osmosis.
This set of primitives alone is sufficient to enable a wide variety of user flows. For example:
- A user who simply wants to pay someone else could (a) hold assets long-term in the MASP, (b) swap them when necessary, and (c) send the outputs onwards (instead of sending them back to the user’s own account, either to the desired recipient’s address on Namada, on Osmosis, or elsewhere in the interchain ecosystem.
- A user who wants to receive payments on Namada could simply share their Namada address, and other users with assets elsewhere could send to that address in order to pay the user (with an IBC transfer and shielding on Namada). This requires wallet support (by whoever is paying), but it doesn’t require that the payer uses or is aware of Namada in any way, they just need to copy the znam address.
This basic pattern – MASP on Namada + application logic on the other end (Osmosis swaps in this case) + connective tissue (bridge, IBC in this case, and contract on the other end) – can already be generalized to many applications: any interaction pattern of the form:
- Start with asset A in the MASP.
- Unshield A and send it across the bridge to the other side.
- Take an action on the other side (e.g. swap, borrow, LP, etc.).
- Take the outputs of that action (e.g. swap outputs, borrowed assets, LP tokens, etc.)
- Send those outputs back to Namada, and shield them in the MASP.
will work, and requires only two main components of technical infrastructure: a bridging protocol between Namada and the application, and a bit of logic on the other side to aggregate action outputs and send them back to Namada.
This basic infrastructure does have some limitations:
- For the user to get pretty good privacy, their assets must be held on Namada most of the time (basically whenever they are not taking an action). Some users might not want to do this due to consensus risk, protocol risk, or other reasons.
- The user must bridge twice to perform each action – once from Namada before the action, and once back to Namada after the action. This carries some costs (in transaction fees and latency). Actions can be bundled, amortizing these costs, but only when the user knows in advance all the actions which they wish to perform at once.
- The MASP is not programmable, so no complex logic can be enforced Namada-side – any other application state must be representable with simple tokens.
What can be done about these limitations?
- 1 & 2 are related – both essentially relate to a separate consensus and protocol – and could be potentially alleviated by development of some “Namada outpost” logic (deployable as contracts on other chains) which supports shielding functionality (e.g. the MASP/CC, but as a contract), such that users would not need to (immediately) move assets to and from Namada all of the time. In order to provide pretty good privacy, we do still want a unified shielded set, but periodically moving some assets between Namada and these outpost contracts should be sufficient to achieve that (since then a third-party observer won’t know whether particular assets unshielded from an output originally came from that outpost, from Namada, from another outpost, etc., same as if only Namada’s MASP were used). This doesn’t eliminate protocol risk, but it reduces it quite a bit (especially with rate limits etc.), and it eliminates the double-bridging latency and costs almost completely (bridging to and from Namada must still happen periodically, but these costs can be amortized).
- Addressing 3 would require either (a) development of a fully programmable privacy-preserving state architecture (such as the Anoma Resource Machine) or (b) development of a more-programmable circuit system (which would still be customized to some set of application use-cases). It’s not entirely clear to me, however, that more programmability is really necessary for this product proposition. Nearly all application interactions start and end with some tokens held in a user’s wallet, and the most important kind of privacy to provide will typically be privacy at the start and the end. Privacy for the application interactions themselves would be a further improvement, for sure, but this is already starting to move away from the product proposition because it would require quite a bit of work from the application developers. I do think it is worth investigating specific applications and seeing if some slightly more general privacy options would be interesting or not (e.g. Ferveo could also be a pluggable “temporary privacy” component).
Another major UX challenge worth noting here is wallet support. At the moment, Namada requires a separate browser extension and separate wallet (e.g. Namadillo). This creates a lot of friction which would be greatly alleviated if we could at least support existing Ethereum and/or Cosmos wallet tooling. Some kind of integration will still be necessary to generate ZKPs, proper transaction formats, etc. but this should be less of a lift.
A note: there is a question about “outpost cryptoeconomics”, in that usage of outposts would not (by default) lead to any fee revenue for Namada. I think that it’s generally more important to aim for maximum product success and not worry too much about the fees, but one easy option would be to add a configurable “tip” to be used with the outposts (e.g. when swapping) of 0.05%/0.1% or so, enabled in interfaces by default but configurable by users if they want. In practice this seems to work alright (e.g. Metamask swap fees), many users would probably be fine with it.
Executed successfully, this product proposition would allow the vast majority of crypto applications today to be able to provide their users composable privacy with Namada, without requiring any changes to their application logic, and with at most some integration requirements on web/app frontends and browser extensions.
Cryptoeconomic Components
In addition to the basic product offering, Namada has cryptoeconomic components, the current set of which can be classified in three major buckets:
- Proof-of-stake, intended to provide security for the Namada chain (which secures assets in the MASP),
- Shielded set rewards, intended to reward users for contributing to shared privacy, and allow Namada’s MASP to provide as much privacy as possible to its users, and
- Public goods funding, intended to fund infrastructure related to Namada’s core product and the shielded / privacy ecosystem more broadly.
How might these cryptoeconomic components evolve to best support this vision of a composable privacy layer, and which other cryptoeconomic components might be needed, if any? Let’s start by analyzing generalizations of the current uses in turn:
- With shielded actions, Namada outposts, etc., the basic security which Namada needs to provide doesn’t change in kind, since any other chains involved have their own consensus and security mechanisms (which we take to be out-of-scope – it is up to users whether to trust those or not). How much security is required for the Namada chain itself depends on the level of shielded deposits within the MASP, IBC rate limits, etc. – but adjustments there can be enacted via simple parameter changes, Namada always has the ability to control its own inflows and outflows. Perhaps other kinds of security could be worth investigating, such as an insurance fund for losses incurred due to protocol or other risks – but this is a mostly orthogonal design problem that we will leave out of the scope of this high-level roadmap.
- Shielded set rewards as is (with only parameter changes) should work just fine for rewarding assets on the Namada chain. If Namada outposts are deployed where people can also hold shielded notes, it may make sense to send some shielded set rewards there as well. It may also be worth investigating how to enable other chains and assets to fund shielded set rewards (using non-NAM assets).
- Public goods funding is already pretty flexible, in the sense that recipients simply need to be able to receive NAM on Namada. Generalization to sending other assets (e.g. from the foreign reserve) and sending assets to other chains (over IBC and/or bridges) should be straightforward – conceptually, we might say that Namada outposts build in PGF disbursement facilities – and operationally, Namada outposts should also be able to support miniature foreign reserves at the outpost from fees/donations/etc. (where transfers between the Namada chain and the outpost can be done periodically). The scope of what public goods should be funded should be aligned with this product proposition. Otherwise, probably the main major improvement worth investigating is cross-chain partnerships, which will be discussed separately below.
Possible future mechanisms
In addition to extending shielded set rewards and public goods funding to holistically support the composable privacy layer direction, Namada could investigate new potential mechanisms. Here I will briefly list a few. More research needs to be done here (mostly market research) to determine what to prioritize (or not) and in which order.
Shielded asset management
Namada could offer a shielded asset management service, where users hold funds in the MASP and receive rewards in the MASP, for strategies managed in the clear. This is quite synergistic with the “composable privacy layer” direction, as both benefit from as many bridges and outposts as possible. See here for more details.
Namada shielded bonds
Namada could sell “shielded bonds” in order to raise funds for investment into the network. See here. Many different configurations are possible.
Cross-chain partnerships
Namada could pursue cross-chain partnerships of various forms, such as mutually controlled protocol-owned liquidity, joint public goods funding of public goods of interest, joint services integrations (e.g. payment for Nym VPN with Namada’s MASP), or similar. It could be worth investigating a software stack like Valence for these kinds of approaches.
PGF mechanism experiments
Namada could experiment with different PGF mechanisms. Examples include:
- Donor Drops (context)
- LLM-augmented distribution (e.g. Deep Funding)
- Prize-based PGF, where Namada governance commits a prize amount up front to the first team to satisfy a particular milestone (roughly inspired by the Ansari X Prize).
What do you think of this product proposition? Let’s brainstorm! 