CIP-0104 Traffic Based App Reward Calculation
Hi,
We are trying to figure out the numbers calculated for the traffic based app rewards CIP-0104.
Wondering if someone can help verifying our findings is true and correct?
All the numbers below are configuration and inference on DevNet, since Mainnet is still in marker era
[Test Party]
outersunset::1220a14ca128063b8dc9d1ebb0bd22633be9f2168500f4dbc1ecaeb1855b14e5acf8
appRewardCouponThreshold: $0.5 (USD) - estimate as 4.6 CC
[Issuance Module]
In the OpenMiningRound, we can scrape these numbers
amuletToIssuePerYear: 20,000,000,000
appRewardPercentage: 0.4
tickDuration: 600 s (10 min)
We infer the CC per round using this math:
Pool = amuletToIssuePerYear × (tickDuration ÷ year) × appRewardPercentage
= 20e9 × (600 ÷ 31,536,000) × 0.4
= 380,518 CC issued this round × 0.4
≈ 152,200 CC/round
The 152,200 CC is the actual ceiling of the pool that every apps get slice of
[Transaction Per Round]
The numbers vary per round, we picked the round we tested on Devnet, also assuming to use the default activityWeight
trafficPrice: 60.0000000000
amuletPrice: 0.1090650 USD/CC
activityWeight: 1.0
[DevNet Test]
We posted transactions during round 55670’s open window, we figure out the final round calculation can be seen in this transaction
We extract the payload to get totalFeaturedAppRewardCoupons = 144596.6514459665
Our per-party reward is materialized as a single RewardCouponV2 that shows as inputAppRewardAmount = 11534.8831804497 in this transaction link
Our app then got the full CC from RewardCouponV2 with the exact CC amount on this link
[Question]
- Since the total feature app reward coupon is within the ceiling (144k < 152k), there is no dilution in the math so every feature app get their full reward on that round
If there are more app activities that bring the total coupon > 152k, there will be a dilution in which each app will get less CC reward, is this correct?
The 152k pool is fixed on the round, unless there are changes
- The App Reward Coupon Threshold is per-coupon gate at $0.5, which in CC varies per round with
amuletPrice($0.5 ÷ amuletPrice).
The gate compares our total round reward in CC — our total traffic converted to CC (× traffic_price × issuancePerFeaturedAppRewardCoupon × activityWeight) — against that threshold.
So we’re safe from burning as long as our converted reward clears it, not the raw traffic. Since it’s checked after issuancePerFeaturedAppRewardCoupon, a diluted round makes the same traffic easier to fall below the gate. Is that right?
