TANIP-2: Multi-Tiered Reward Distribution to Broaden TAN Participation

Council Proposals TANIP
1

TANIP-2: Multi-Tiered Reward Distribution to Broaden TAN Participation

Abstract

This proposal introduces TANIP-2, a new reward distribution model for the Telcoin Application Network (TAN) that expands upon the volume-only approach of TANIP-1. It introduces a four-tier system for distributing a weekly reward pool of 3,205,127 TEL, aimed at increasing engagement, broadening eligibility, and reinforcing alignment with long-term ecosystem goals. Rewards are distributed across volume-based activity, base participation, referrals/staking, and gamified incentives.

Specification

Total Rewards: 3,205,127 TEL per week
Reward Cap: Lifetime rewards per wallet are capped by the total amount of TEL staked in the Telcoin App or other TAN Dapps, same as TANIP-1.

image
image860×237 9.81 KB

Motivation

While TANIP-1 succeeded in bootstrapping activity by rewarding users based on trading volume, it inadvertently created a narrow incentive path. Many users — including smaller participants, referrers, and long-term supporters — were excluded from meaningful rewards.

By implementing TANIP-2:

  • A wider range of user behaviors are recognized and rewarded.

  • Referrals and staking are reinforced as critical growth mechanisms.

  • Gamification introduces a fun layer to increase user engagement.

Rationale

The design of TANIP-2 is grounded in three key observations from the TANIP-1 era:

  1. Incentive Exclusivity: Users with low or irregular volume had minimal to no rewards, even if they were loyal or brought value in other ways.
  2. Overemphasis on Volume: Volume-based rewards encouraged wash trading and short-term extractive behavior, reducing reward efficiency and fairness.
  3. Staking Alignment: Many high-earning users were not meaningfully invested in the long-term success of the network via TEL staking.

By integrating multiple reward streams and enforcing the existing “Reward Cap = Staked TEL” model, TANIP-2 fosters a more sustainable, fair, and inclusive incentive structure.

Implementation

  • Off-Chain Logic: The existing backend reward system will be upgraded to distribute rewards across the four tiers, based on new logic and updated wallet activity criteria. It would still be airdropped weekly as per TANIP-1.

  • Development of Referral and Staking Details: Bonuses granted for successful referrals, and a tier-based bonus for long-term staking. Suggestion:

    • 50% of rewards distributed pro-rata based on successful referrals.

    • 50% of rewards distributed for long term staking Tiers (Tier 1 – 0-5 periods, Tier 2 – 5-10 periods, Tier 3 – 10-25 periods, etc.).

  • Development of Gamified Incentives: Review and include a recent TANIP for this specific aspect of TANIP-2.

Expected Outcomes

  • Higher User Retention: Broader eligibility encourages more users to remain active even with low volume.

  • Network Growth: Referrals are incentivized, expanding the TAN user base.

  • Reduced Exploitation: The cap mechanism discourages short-term gaming of the system.

Budget & Funding Source (same as TANIP-1)

  • Weekly Pool: 3,205,127 TEL

  • Annual Allocation: ~166.7M TEL

  • Funding Source: The TEL distributed under TANIP-2 will continue to be sourced from the existing TAN Council Safe, managed by the Telcoin Association and TAO.

No new minting or separate budget allocation required beyond what was provisioned for TANIP-1.

Precedent

TANIP-1 marked the launch of the first volume-based TEL rewards system, aligned with TAN protocol goals. It established:

  • Weekly app-based reward distribution

  • Wallet activity scoring via backend analytics

  • Rewards capped by staked TEL

TANIP-2 is a natural evolution of TANIP-1 — preserving its foundation while expanding and optimizing rewards to reflect a wider range of behaviors and stakeholders.

This proposal is meant as a suggestion for improvements to the current TANIP-1, and any details of TANIP-2 are subject to change based on the TAN Council and greater Telcoin Community feedback.

7 Likes
2

Excellent proposal @Andrew_Pinch!

I think with this, bluelights companion proposal, and my marketing proposal, we’re set to revamp the rewards system in a very positive way.

5 Likes
3

Great proposal!

This puts some much-needed safeguards in place for wash trading and incentivizes new users into the ecosystem.

4 Likes
4

Awesome progression, TANIP2 sounds even better, look forward to discussing in the meeting, no doubt on the gamified side, there could be unclaimed TEL, but thats covered in my proposal anyway.

4 Likes
5

Great proposal. The only thing I would mention is to shift the rewards split. I would reduce activity from 65 to 55 and increase referalls and staking from 15 to 25%

3 Likes
6

Thank you for the proposal Andrew, It’s great to see so much thought going into how to improve our current processes!

I had a few questions regarding the rationale:

  1. Incentive Exclusivity: you mention user being ‘loyal’ or ‘bringing value in other ways’. Do you have specific examples of these, so we can define them and measure them?
  2. Overemphasis on Volume: What is meant by ‘efficiency’ and ‘fairness’? Is this the idea that rewards end up ‘with the right people’ so to say? I believe remittance users would push out ‘wash traders’ under the current regime, once full remittance pipelines are in place (mostly dependent on stablecoins and bank access).
  3. Staking alignment: Doesn’t the reward cap ensure high earning users are meaningfully invested in the long term success of the network due to the increasing amount of TEL they are proving ownership of?

What kind of metrics will we use to define a ‘successful referral’?

I was also wondering about the implementation logic, specifically trying to narrow down details around linking on chain metrics to distributions. What will be the relationship between tiers and distributions? Would there be some kind of formula? In that case what would be the advantage of discretising the data?

Looking forward to exploring further!

1 Like
7

Hi Leo,

Thanks for the questions.

1 - Incentives - Bringing other values (other then volume) would be referring more users to the app, or staking more TEL within the app, etc.

2 - Speaking to other “values” above, I think we can have other metrics for value other then just volume. Therefore if someone doesn’t have a lot of trading volume on the app, but is also pushing more people to use the app, it would be beneficial as well. I know they’ll earn from their fees, but would help with word of mouth marketing IMO.

3 - You could have some people game the system for a period of time, earn their TEL to the max staked, then just unstaked and market sell what they’ve earned as a profit. Doesn’t really incentivize long term staking IMO. This situation would really only apply when 2 people use each others code and just wash trade until its not profitable then leave the ecosystem entirely… don’t want to promote that type of activity.

A successful referral would be someone who signs up to the app, and has at least 1 trade with fees within the app, thus being eligible for TANIP1 rewards.

Many of the ideas here are meant to spark a more detailed conversation amongst the TAN Council and greater Telcoin Community. This proposal was really meant to look at how we can improve TANIP1, while giving the TAN Council the lead on what changes feel necessary.

Remember everything in my proposal is a suggestion, the over arching theme was to break the rewards up into different “value” groups to help entice usage of the app, and future apps developed on the network.

8

I’ve put together some thoughts here to try and narrow down a spec for the ideas introduced above. I’ll go through each aspect and provide my thoughts on how these can be implemented.

Suggested TANIP distribution proportions from the proposal:

image
image860×237 9.81 KB

Reward tier specifications

Base participation

Should be easy to implement, probably using `fetchUserFeeTransfers()` from `StakerIncentivesCalculator.ts`

Get each address which made a trade through Telcoin app, divide the proposed issuance (480,769 TEL) by the number of addresses and distribute that amount to each

Ie:

BPIAddress= BPItotaln

Where:

BPIAddress is the Base Participation Issuance for a single user wallet (address)

BPItotal Is the total to be distributed for base participation (suggested 480,769 TEL/ week)

n is the number of wallets (addresses) which meet the minimum activity threshold.

The minimum activity threshold can be set to e.g. 1 trade in the period. This will lower barriers to entry and create a simple, incentive for users to ‘check in’ at least once a week to the app.

Referral & staking bonus

The TANIP2 proposal breaks this down into two categories:
“Bonuses granted for successful referrals, and a tier-based bonus for long-term staking. Suggestion:

  • 50% of rewards distributed pro-rata based on successful referrals.

  • 50% of rewards distributed for long term staking Tiers (Tier 1 – 0-5 periods, Tier 2 – 5-10 periods, Tier 3 – 10-25 periods, etc.).“

I’d like to take these one at a time here.

Referral Bonus

“A successful referral would be someone who signs up to the app, and has at least 1 trade with fees within the app, thus being eligible for TANIP1 rewards.” – should this be a staker who has performed a trade?

If we go with that, this could be done by:

  1. Cross referencing a list of stakers with a list of users who traded this week (Likely using `fetchUserFeeTransfers()`) and have not traded through Telcoin app before (This feels RPC call intensive).

  2. For all addresses that meet the above criteria, find their referrer’s address.

  3. Divide TEL/ week by number of referrers (like in ‘Base Participation’) to get Referral and Staking Bonus Issuance per wallet

  4. Transfer this amount to each wallet

Number of RPC calls could be greatly reduced if initial stake and first trade had to happen in the same period to be eligible.

Staking Bonus

Still unsure about implementing this but wanted to put all my thoughts down for consideration and further discussion.

The TANIP2 proposal mentions Tiering addresses based on the length over which they have been staking and then giving a bonus to long term stakers.

From our last TAN Council call, SteveO brought the analogy of this being more like poker tables (If I remember correctly, hopefully not butchering it) and addresses compete against each other based on what tier (based on staking date) they are in. At the time I assumed equal distribution for each tier. I also assumed the addresses earning the most at the moment are older addresses (At least have been around since near the beginning of TANIP1 issuance). There are a few things to unpack here, I think.

  1. Staking age: Should be the age of the first stake an address makes. Should this be calculated based on when the address first staked in raw terms or relative to TANIP1? Ie should an address that staked long ago have much higher staking age than an address that staked at the start of TANIP1 (raw), or should they both have the same age? From the TANIP2 doc, age is denominated in periods, which suggests the non-raw (same age) version.

  2. Tier distribution: Should this be an equal amount of TEL/week for each tier? I think that would be a good place to start. In this case though, and assuming the highest earning wallets are ‘older’ ones (link to above point), their rewards will be reduced by this tiering, and so no longer acts as a ‘bonus’. This would, however, mean that new stakers won’t be competing with the top earners, so this becomes more accessible. Which way round do we want this and why?

  3. Tier boundaries: How do we determine the tiers and how do we make this future proof? Do we need tiers at all or should we just have a formula dependent on stake age?

To determine which option is best here I’ll consider them in turn and what I think the knock on effects of the different options will be.

Staking Age

I don’t think this really makes a difference but starting everyone at period 0 (non raw) should be cheaper to compute (fewer blocks to search).

Tier Distribution

I think equal weighting across tiers makes sense as a starting point and this will limit the earnings of the ‘top end’ of earners (Assuming they are some of the older wallets, but I believe they have been participating a while). Older wallets have had more time to compound their earnings, and the data has shown that these wallets are dominating earnings, while new user numbers are weak. This would both reduce the earnings of the top earners and incentivise newer users. This does open the door for people to buy, stake and wash with large amounts of TEL, but maybe that’s a risk worth taking? Offering bonuses for long term stakers feels like it would push distribution further in the direction it’s already been moving which I don’t think we want to do.

Tier Boundaries

There are a few options here, some may be pointless but wanted to include them anyway just for completeness and in case they spark some further discussion.

TANIP2 distributes these rewards as a ‘bonus’ which sounds separate to the TANIP1 mechanisms. We could just have a pot which we split equally between the users in a given tier each week and I don’t think that would be difficult to implement

Upon discussion in the last TAN Council meeting though, it sounded like SteveO was talking about getting this baked into TANIP1, and that we could split incentives based on the tiers – ie tier 1 Users who staked in periods 0-5) would ‘compete’ for the pro rata share of incentives allocated to them, and not against older wallets (which could well be doing much more volume).

Either way, we need to determine where the boundaries are, and I think we have a few options:

  1. Hard coded tiers: This is as laid out in TANIP2, for example: Tier 1 – 0-5 periods, Tier 2 – 5-10 periods, Tier 3 – 10-25 periods, etc. This brings a lot of variables to the table and makes the tiers more ‘coarse’ as we go on, which will probably result in more wallets getting grouped together down the line, eventually tending to a situation like the one we currently have.

  2. Quartiles (All wallets): Using quartiles as an example, but could be deciles, percentages etc. Consider the staking age of all staked wallets and divide into quartiles. Youngest 25% of wallets (tier 1) compete amongst each other, 25% to 50% by age (tier 2) compete etc. etc. This is more dynamic and feels easier to adjust.

  3. Quartiles (Participating wallets): As above, but instead of considering all staked wallets, only consider the wallets that traded in the current period. Might give a more accurate representation of current usage, but realistically probably won’t make too much difference.

  4. Include wallet age variable in volume weighting calculation: A slightly different approach that doesn’t really involve tiers, but we can include the age of each wallet as a parameter in the volume weighting calculation. Currently the pro rata share of rewards (before applying cap rules) is calculated purely on user fees, ie:

issuancei= issuancetotal* feesifeestotal

Where issuancei is the issuance user i receives, issuancetotal is the total weekly TANIP1 issuance (Currently 3,205,127 TEL per week), feesi is the fees paid by user i in the period and feestotal is the total amount of fees paid by all TANIP1 participants.

We could adjust this formula to include a wallet age dependent term. Whereas in the current case, address weighting, w, is based purely on user fees, ie:

wi=feesi

We can use:

wi=feesi*g(ai)

Where g is a function of wallet age, a.

We can then determine a function that fits our needs. The first that springs to mind, in light of the idea that ‘older’ wallets are currently ‘too well incentivised’ relative to new wallets, would be to use some kind of exponential decay curve, which would take the form:

gai=A*e-kai

Where A and k are parameters we can choose. To keep it simple we can set A to 1, so a fresh wallet will receive the same amount of rewards under this regime as they would under the current TANIP1 implementation. The set of curves would then look something like this:

1600×1200 95.2 KB

Where the constant k determines how aggressively fees reduce with wallet age.

An exponential curve is just an example, but we could use any curve we want here (Could also increase over wallet age if we want).

Gamified Incentives

To be discussed further with Bluelights

Notes on Implementation

Whatever we do, I think we should act slowly and focus on one change at a time. We want to retain as clear a path between inputs and outputs as possible (Of course there are other sources of randomness e.g. prices etc.) but we should work to reduce the amount and rate at which we change things so we have the best chance of drawing clear data driven conclusions. This document is just a summary of my thoughts and is intended to continue the discussion. If there are bits that seem overly complex that’s no problem at all, and they likely are – I just wanted to outline as many potential solutions as possible really.

4 Likes
9

Thanks leo - this is a really good (and technical) read on some options we can use to move the program towards a better distribution model.