As Namada approaches its launch, it is important to select suitable assets for its shielded set to maximize privacy guarantees and ultimately try to boost user participation. This draft report aims to outline a data-driven strategy for asset selection, incentive mechanisms, and privacy considerations, all while trying to prioritize IBC-compatible, liquid-staked tokens.
This post includes a high-level framework, which uses a sample dataset applied to the framework for a single asset “A”. Images of our comprehensive, multi-asset findings are attached at the bottom of this post.
Objectives
-
Asset Selection: Identify IBC-compatible, liquid assets, particularly liquid-staked tokens, that are suitable for inclusion in Namada’s shielded set.
-
Incentive Calculation: Determine the appropriate amount of NAM token incentives required to attract users to deposit and maintain their assets in the shielded pools.
-
Privacy Guarantees: Calculate the minimum quantity of each asset required in the shielded pool to provide robust privacy guarantees.
Potential Methodology (Asset Selection Criteria)
The goal was to develop a multi-factor scoring algorithm. We found the following potential variables to best suit our analysis.
- Liquidity (LQ): Average daily trading volume
- Market Capitalization (MC): Total market value
- Number of Holders (NH): Estimated unique addresses holding the asset
- Alternative Yield Opportunities (AYO): Average APY available elsewhere
- Unbonding Period (UP): Time required to unstake/unbond
- Transaction Velocity (TV): Average transactions per day
- Time to Liquidity (TTL): Ease of depositing into Namada
- Asset’s Role in Ecosystem (ARE): Importance within the IBC ecosystem
- Integration Complexity (IC): Technical effort required
- Liquid Staking Status (LSS): Whether the asset is a liquid staked token
We then assigned weights to each variable. This stage is slightly more subjective; we knew we’d most likely want to prioritize speed and simplicity, so Liquidity (LQ) and Liquid Staking Status (LSS) have the heaviest weights (15 and 20%, respectively).
- Liquidity (LQ): 15%
- Market Capitalization (MC): 10%
- Number of Holders (NH): 10%
- Alternative Yield Opportunities (AYO): 10%
- Unbonding Period (UP): 5%
- Transaction Velocity (TV): 10%
- Time to Liquidity (TTL): 10%
- Asset’s Role in Ecosystem (ARE): 5%
- Integration Complexity (IC): 5%
- Liquid Staking Status (LSS): 20%
Next, we collected as much sample (asset specific) data as possible to analyze in our system. The data used was clean data from the web via block explorers and various chain analytics sites. This is where we included as many IBC assets (stTIA, JUNO, etc.) and their corresponding variable data (LQ, MC, NH, etc.).
We then normalized each variable on a scale from 0 to 1 and calculated the weighted scores for each asset. As an example below, we will use the test data from Asset “A” to show how we make those calculations.
Liquidity (LQ):
- Max LQ: $250M (A)
- Normalized LQ = Asset LQ / Max LQ
- Normalized LQ = $250M / $250M = 1
- Weighted LQ = 1 * 15% = 0.15
Market Capitalization (MC):
- Max MC: $3.5B (A)
- Normalized MC = Asset MC / Max MC
- Normalized MC = $3.5B / $3.5B = 1
- Weighted MC = 1 * 10% = 0.10
Number of Holders (NH):
- Max NH: 300,000 (A)
- Normalized NH = Asset NH / Max NH
- Normalized NH = 300,000 / 300,000 = 1
- Weighted NH = 1 * 10% = 0.10
Alternative Yield Opportunities (AYO):
- Normalized AYO = (Max AYO - Asset AYO) / (Max AYO - Min AYO)
- Max AYO: 50% (C)
- Min AYO: 10% (E)
- Normalized AYO = (50% - 20%) / (50% - 10%) = 0.75
- Weighted AYO = 0.75 * 10% = 0.075
Unbonding Period (UP):
- Normalized UP = (Max UP - Asset UP) / (Max UP - Min UP)
- Max UP: 21 (A, F, H)
- Min UP: 0 (Liquid Staked Tokens)
- Normalized UP = (21 - 21) / (21 - 0) = 0
- Weighted UP = 0 * 5% = 0
Transaction Velocity (TV):
- Max TV: 60,000 (A)
- Normalized TV = Asset TV / Max TV
- Normalized TV = 60,000 / 60,000 = 1
- Weighted TV = 1 * 10% = 0.10
Time to Liquidity (TTL):
High = 1, Medium = 0.5, Low = 0
- High = 1
- Weighted TTL = 1 * 10% = 0.10
Asset’s Role in Ecosystem (ARE): For this example assume A is ATOM
Core Hub = 1, DEX Leader = 0.75, Derivative = 0.5, Infrastructure = 0.5, DeFi Platform = 0.5
- Core Hub = 1
- Weighted ARE = 1 * 5% = 0.05
Integration Complexity (IC):
- Low = 1, Medium = 0.5, High = 0
- Low = 1
- Weighted IC = 1 * 5% = 0.05
Liquid Staking Status (LSS):
- Yes = 1, No = 0
- No = 0
- Weighted LSS = 0 * 20% = 0
In this example the total score for A would = the sum of the weights: 0.15 + 0.10 + 0.10 + 0.075 + 0 + 0.10 + 0.10 + 0.05 + 0.05 + 0 = 0.725
We then complete the above calculation for each asset to get the score rank.
Determining Incentives to Deposit and Stay
We now want to determine the appropriate quantity of NAM tokens needed to incentivize users to deposit and keep their assets in Namada’s shielded pools. In simple terms, we need to think through what the user gives up, and what they are willing to risk to participate in the shielded pool. For ease of calculation and consistency of variables, we will refer to the “what the user gives up” as Effective Alternative Yield (EAY), and “what they risk” as Risk Premium (RP).
The full equation:
Required Incentive Yield (RIY) = Effective Alternative Yield (EAY) + Risk Premium (RP)
or RIY = EAY + RP
- Required Incentive Yield (RIY): Incentive required to be attractive (somewhat of a hurdle)
- Effective Alternative Yield (EAY): Underlying staking yield minus liquid staking protocol fees
- Risk Premium (RP): Additional yield to compensate for platform risk, assumed at 5%
In practice the calculation looks like the following:
Underlying Staking Yields and Fees (Asset A):
-
Underlying Yield: 20%
-
Liquid Staking Fee: 0%
-
RP (A): 5%
- RIY = 20% + 5% = 25%
Now, we estimate the expected deposit volumes. We will use $8M for asset A as a very conservative assumption.
Next, we calculate the annual incentive amounts.
Annual Incentive = Deposit Volume × (RIY − EAY)
Where:
- Annual Incentive refers to the total incentive amount paid annually
- Deposit Volume is the amount of capital or deposit being considered (assumption)
- RIY is the Required Incentive Yield (which we know)
- EAY is the Effective Alternative Yield (which we know)
Annual Incentive = $8M * (25% - 20%) = $8M * 5% = $400,000
The total annual Namada Incentive budget would be (the above) equation + the sum of all other asset incentives. In practice incentives will most likely be paid out in some cadence (epoch).
Minimum Quantity for Privacy Guarantees (MVP)
Next, we need to calculate the minimum deposit (amount) requirements to maintain a comfortable or “strong” level of privacy. This took some external research, as we are by no means privacy experts, so please correct anything as you see fit.
Step 1: Set our Target k-Anonymity Level; k-anonymity is a property that ensures that any individual in a dataset cannot be distinguished from at least 𝑘 other individuals based on the information in the dataset.
Based on our search a reasonably high (entry) level of privacy has a target 𝑘 = 50. This means each record in the dataset is indistinguishable from at least 49 other records. A higher 𝑘 value generally implies stronger privacy protections, as it becomes harder to re-identify an individual. This target is commonly used in industries like healthcare to prevent re-identification of individuals from anonymized datasets, and could be suitable for private asset pools as well.
Step 2: Determine the Minimum Number of Transactions - We should aim for at least 50 transactions of similar amounts for each asset within the chosen time frame (e.g., one day).
Step 3: Now we can Calculate Minimum Pool Sizes with the following assumptions
- Asset
We are still using asset A in this example
- Average Transaction Size (ATS): Based on typical behavior
For asset “A” we can see from the blockchain data that 100 units is the Avg. tx size
Minimum Number of Transactions (MNT) × Average Transaction Size (ATS) = Minimum Pool Quantity (MPQ)
Ex. 50 transactions × 100 Avg units = 5,000 Total units
Based on our calculation we need a minimum of 5,000 “A” units if we average 50 transactions ~100 units in size per day to maintain target 𝑘 = 50 or greater.
Lastly, Step 4: Verify Against Expected Deposits - as an additional measure, we should double check that our Expected Deposit Volumes (EDV) meet or exceed the MPQ.
Asset “A”
- EDV
$8M (per our volume assumption) / $10 per A (current market price) ≈ 800,000 “A”
- MPQ: 5,000 “A”
Conclusion: Since our MPQ < EDV we can rest assured that our volume for asset A is likely sufficient for privacy.
Additional consideration - While the original approach was to derive privacy requirements based on the average number and size of transactions, we also considered the opposite perspective: what maximum USD value should the protocol guarantee can be transacted in a single transaction for each asset? To calculate this, we analyzed the average transaction size ($) and then estimated what might be considered a large transaction for each asset. For consistency, we applied a multiplier of 100x to liquid-staked tokens (given their typically lower transaction sizes) and 10x for all other assets. Using these variables, we calculated the minimum pool sizes, adding additional multipliers of 100x and 10x (for LST and others, respectively) as very conservative estimates.
A few resources we used if anyone is interested in diving deeper:
- Namada Blog: https://namada.net/blog
- Namada Specifications: https://specs.namada.net
- K-Anonymity in Privacy: https://en.wikipedia.org/wiki/K-anonymity
- K-Anonymity a Model for Protecting Privacy: https://www.worldscientific.com/doi/abs/10.1142/S0218488502001648
Multi-Asset Findings
