Two different logics can be applied when using TPs to distribute other Organizational Tokens, one is a fixed logic while the other is dynamic. In a Fixed Pool logic, tokens are like slices of a pie — no matter how big or small your effort, you get your fair share based on how much others contributed too. In a Dynamic Pool logic, tokens are more like fruit on a tree — the more ripe your contribution, the more fruit you pick, up to a seasonal limit. One is about equity among peers, the other about individual alignment with potential.

• Org decides in advance the total amount of $ORG to be distributed (e.g. 500).

• Each participant receives a proportional share based on their TPs.

• Total TPs: 10,000

• Individual_A TPs: 2,000
→ Individual_A receives (2,000 / 10,000) × 500 = 100 $ORG

• Predictable for treasury planning.

• Guarantees full distribution of intended amount.

• Easy to explain: everyone gets a slice of a known pie.

• May inadvertently dilute standout contributions (e.g. a high performer gets the same % even in a low-performing group).

• Can’t reward absolute contribution strength — only relative.

• This is a zero-sum game: your gain is someone else’s loss.

• Participants are incentivized to maximize their own share relative to others, possibly leading to:
Strategic downvoting (if trust input is peer-based)
Over-claiming contribution
Reduced incentive to collaborate, since you’re competing over a fixed pie

• Can foster scarcity mindset or subtle competition

• May lead to contribution inflation or social gaming

• Doesn’t reward collective effort — only individual rank

• When total budget must be strictly fixed

• When trust input is externally calibrated (not peer-rated)

• In mature orgs with clear performance baselines and trust in fairness

• Org sets a monthly expectation (e.g. 500 $ORG) and holds a reserve (e.g. 600 $ORG).

• The actual amount distributed is proportional to absolute TPs earned, not a fixed pool.

• A higher-performing round triggers more tokens to be distributed — up to the reserve cap.

• Baseline expectation: everyone earns 3 stars → 10,000 TPs → ≈500 $ORG

• This month:
Individual_A earns 4 stars = 2,200 TPs
Total group earns 10,200 TPs
Individual_A gets (2,200 / 10,200) × 600 = 129.41 $ORG, but since the cap is 600, they get 110 $ORG and total outflow is 510 $ORG

• Rewards absolute contribution level, not just relative standing.

• Encourages high performance — tokens "follow" effort.

• Unused buffer can roll over or signal under-engagement.

• Treasury outflows are less predictable (though capped).

• Harder to message to contributors and finance teams.

• Risk of creating a perceived “performance-pressure” dynamic unless clearly communicated.

• This creates a positive-sum game (up to the cap): if everyone contributes more, everyone can receive more.

• Encourages collaboration and group uplift, since increased collective effort leads to higher shared rewards.

• Reduces the incentive to game peers, since you're not directly taking from someone else's slice.

• Rewards intrinsic motivation and absolute contribution

• Encourages team alignment, especially if the group knows the budget cap and can aim to collectively “unlock” it

• Makes overperformance feel meaningful and visible

• If cap is too low, it can dampen motivation (“why try harder if I won’t get more?”)

• If cap is too high, it can lead to budget creep

• Needs careful storytelling to avoid “gamified performance pressure”

• In creative or mission-driven teams where collaboration is key

• When trust signals are based on peer appreciation or mutual recognition

• In DAOs where budget flexibility is acceptable and participatory incentives are core