Introduction
The RDX Works development team is considering the possibility of extending the Radix Network’s native Pool component to include not just today’s fungible Pool Unit tokens, but NFT-based Pool Unit tokens for use cases not well served by the fungible kind.
There are certainly clear use cases for NFT-based Pool Units, but it’s important that the design be as flexible as possible, while still providing the user-level guarantees that are the ultimate purpose of native components and resources.
The RDX Works development team wishes to gather feedback on the use cases and needs where NFT-based Pool Units might be used to inform that design. Your feedback on your real use cases is highly desired!
The Purpose of Native Resources
One of the big goals of Radix is giving users more confidence when they use DeFi and Crypto, and a major aspect of that is confidence in the assets they hold. On other smart contract networks, users often are confused (or even scammed) by the assets they hold because they have no guarantees at all about what a given token is, how it can behave, or what it can be used for.
Radix’s resource-based asset system nicely answers the first two questions – what a given token is, and how it can behave. All Radix resources have a clear and objective definition that a wallet can directly read, including whether it is fungible or non-fungible, and who (or what) is able to authorize minting, burning, withdrawing, depositing, recalling, or freezing it. This already allows the Radix Wallet to more clearly display, classify, and explain the behavior of any asset the user holds.
But it is also useful for resources to provide an objective definition of what they can be used for – at least in cases where there is a common pattern of usage that can be explained and understood by the user.
This is the purpose of various native resources that are included in the Radix Network, which are created by an associated native component (defined by a native blueprint package built into the network). Most prominently, this includes Liquid Stake Unit tokens and Stake Claim NFTs (created by a native Validator component), and Pool Unit tokens (created by a native Pool component).
The advantage of having these native, built-in resource and component definitions is that the Radix Wallet – and any other application – can fully rely on the purpose and meaning of these resources. This means they can be safely categorized and displayed uniquely, and reliable guarantees can be made to the user about what they mean.
The goal is not, however, to create 1000 native resource types for 1000 individual use cases. The intention is to add native components and resources only when two criteria are met:
- When the asset and component definition is general enough to cross over between many application types
- When it is possible to give users useful meaning for the asset in a way that is objectively guaranteed
When these two things are true, the value is high in creating a native implementation, and updating the Radix Wallet and other tools to understand and interact with it. These native implementations can meaningfully make the user experience more clear and safe for many applications they may interact with.
The Desire for an NFT-based Pool Unit
Pool Units fundamentally exist to represent redeemable value from the Pool it is issued by. With today’s fungible Pool Units, that redeemable value is a completely fungible share of a combined pool of assets. Every contribution is the same: it is a percentage of the pool, and the Pool Unit that is returned represents that percentage. This is quite flexible because it says nothing about what the pool may be used for by the application – only that a given quantity of Pool Units represents a certain percentage of whatever is in there.
However, this model doesn’t work when different contributions are not the same. In this case, an NFT is a natural fit because it can represent whatever was unique about a particular contribution. Those unique parameters can be written into the non-fungible data on the NFT (or perhaps stored in a hashmap against the NFT ID within the Pool) and used to determine things like when it can be redeemed and for what underlying value.
So the question is this: Is there a form of NFT-based Pool Unit that can meet the two criteria described above?
Can the implementation be made to enable a wide range of applications that desire it?
Can it provide strong guarantees about the meaning or value of the Pool Unit NFT?
What Does an NFT-based Pool Unit Mean?
This is more complicated than it might seem. A simple form of NFT-based Pool might simply take whatever quantity of fungible Pool Units it would normally mint and instead write that number into the non-fungible data of a Pool Unit NFT. When turned in to the Pool to be redeemed, it would return the proportional share of the Pool assets, just as today. Logic could even be included to enable partial redemption (resulting in re-issuing a new NFT indicating a smaller share).
Then each application using an NFT-based Pool might write whatever other unique data it wants to the Pool Unit NFT before providing it to the user.
However, remember that the reason we’re using the NFT in the first place is that the unique data written to it matters to its meaning. That data might determine a variety of things, like:
- A specific time after which the NFT can be redeemed for its pool value
- A changing redeemable value based on time
- An association with a specific redeemable value for just that user, not a shared pool
- A specific “position” with complex application-specific calculated value
If the goal is to provide strong guarantees to users about the meaning and value of the asset, then these details change that meaning and value to its holder.
That means that the Radix Wallet should have access to objective guarantees about that meaning and value, if it is to show it to the user. If those guarantees can’t be provided, then the reason for having a native implementation rapidly vanishes.
Call for Feedback
Today’s fungible pool unit token may always be redeemed for its proportional value from the pool. But if an application is using unique NFTs that each determine specifics like when it can be redeemed, and for how much value, what objective guarantees can be actually provided to the user? Can such guarantees be provided without implementing 100 different Pool variations for specific use cases? Is there a lowest common denominator? Or is the best that can be done to show the user “here’s the data written to this NFT, but only the dApp can tell you what it means?”
Answering those questions is why the RDX Works development team needs your feedback.
It is important to understand the real use cases where NFT-based Pools might be used, and specifically what the NFT represents in those use cases. With that, perhaps a common denominator can be found that is both flexible and helpful to users. The team has already gathered some input on this from the community, but a more complete view is desired.
Respond to the Call
To respond, please fill out this brief survey form before Jan. 22. Please do take a few moments if you have or are building a dApp using pools, so your needs are heard!
If you’ve got additional feedback and thoughts, head over to the Discord forum topic we’ve opened for this call for feedback.
