App rewards

Hi team!

I wanted to ask how relevant the featured app rewards formula is
So if:
A = Your app transactions per month
B = Total network transactions month (40M per month, based on ~15 TPS avg.)
C = Monthly app rewards available (~516M CC)
D = Onchain conversion rate (see: canton.thetie.io/ )
Then (A ÷ B) × (C × D) = Your monthly app rewards (USD)

Since I am currently looking at the statistics and most apps are operating at a loss.

For example:
FTP-validator-1 - Featured App
83 249 TX total on 7 days
+3.53K reward on 7 days (+71.72K earned−68.19K burned)

SatsTerminal-main - Featured App
40 759 TX total on 7 days
+41.42K on 7 days (+150.34K earned−108.91K burned)

Could you help us understand why there is such a significant difference?

@dunebuggie @cocreature can you help me?

@Amanda could you please let me know who would be the best person to discuss this with?

Normally someone comes in and helps over time

Hey @karlo

Jatin This side, DevRel Manager, Canton Foundation.

Appreciate you understanding based on the numbers and forumla as this is exactly the kind of analysis that helps surface real gaps in how rewards are understood.

But that said,

The formula you’ve outlined is a mental model for rough estimation, but there are some nuances per our CIP 104 since actually it computes rewards that may explain what you’re seeing.

It has a key gap that CIP-0104 doesn’t reward transaction count, it rewards envelope traffic weight in kB.

So look, for every confirmation request, each app provider earns a per_app_traffic_weight calculated as:

(envelope_traffic_cost × total_confirmation_request_traffic)
/ (total_app_envelopes_traffic × num_app_confirmers)

This is summed across all envelopes for the round, then converted to CC. Transaction count as per what I know doesn’t appear anywhere in this formula.

This could explain your situation as SatsTerminal’s transactions could be generating significantly heavier envelope payloads, so they accumulate more traffic weight per transaction.

The burn difference follows the same logic. SatsTerminal could burn more absolute CC Maybe because its workflows are heavier.

As for apps “operating at a loss”, Will certainly work with @dunebuggie to take this feedback internally.

Afik post CIP-0104, Scan API endpoints will expose per-envelope traffic costs so apps will be able to observe and optimize their Daml view decompositions rather than flying blind.

Hope that helps clarify things!

looking into it now thank you Jatin