# forward payments (from tea + my thoughts at the end)

**Leaf**
The smallest denomination of the tea token. A leaf corresponds to one one-hundred-millionth ($10^{-8}$) of a tea.
**Slashing**
The action of penalizing steepers or stakers in response to behavior contrary to the network rules.
**Staking**
The action of locking tea tokens to secure the proof-of-stake network upon which the tea system is built.
**Steeping**
The action of locking tea tokens to support your claim and receive rewards (or penalties) based on the consensus on the validity of your claim.
## GOVERNANCE
* all tea token holders can suggest and vote on changes
* weighted by token ownership and reputation
* to critical parameters, e.g.:
1. inflation
2. transaction fees
3. staking rewards
4. steeping rewards
5. optimum steeping ratio
## packages
* dependencies will constantly evolve
* leads to frequent changes in steeping ratio + rewards
* => dynamically monitor steeping ratio of packages
* => rebalance how package supporters stteep their tokens based on criteria
## transfer
* tranfer 0-100% of steeping reward stream to other devs
* package maintainer + partners decide alone

* steeping rewards can be configured to flow
* to single account controlled by (multi)sig
* auto-distributed across multiple accounts (static/dynamic ratios)
* to maintainers themselves
* to dependencies
* distribution is decided by maintainers (who contributed how)
* contributors
* e.g. DAO vs. multisig wallet with rules vs. config files
* automate reward distribution
* deploy more complex system to determine adequate rewards distribution
* based on external factors (e.g. member votes or time based distribution) ...based on continuous distribution
* successful completion of bounties, etc..
## forks
* are effective tool for devs to compete in functionality/perfurmance/security/attention
* FORKS MUST RECOGNIZE ORIGINAL EFFORTS

* declare forks (through future work or potential contributions)
* detect when package is submitted

* undeclared forks revealed by tea tasters => portion of steeped tokens
* being slashed
* => transferred to original package maintainer
* and/or sent to fork detectors
## feature proposal
* community proposes and votes on implementation
## feature: dependency types
* steeping rewards distribution algo to account criticality of each dep
* and contrib to value of packages that depend upon them
## feature: Usage-based Remuneration
* augmentation of reward algo
* influence usage based on external attested data about usage
* e.g. higher rewards for high usage pkgs
* but sill respecting "steeping ratio"
* maintainers can distribute steeping rewards acros deps based on transparent logic of choice (e.g. "hot code path?")
## seuring network
* scalability
* cost-effectiveness
* ESG (environmental,social,governance)
* third party extensibility
* proof of stake (STAKEHOLDERS)

proof-of-stake, node operators and network participants stake economic value in the form of the chain’s native token
=> to increase system security

node operators + participants receive rewards for successful block production
that comply with network rules
include accurate transaction infos
inactivity + malicious/incorrect acivity is penalized by destroying faction of staked tokens

A proof-of-stake system powered by the tea token will allow tea token holders
1. to contribute to the system’s security by staking tea
2. and support open-source developers by steeping tea

staking = using base interest rate
steeping = taking risk get more

We're fully aware economic factors may prevent some developers from staking or steeping tea; as such, staking and steeping will be available for as little as a leaf, the smallest denomination of tea representing one one-hundred-millionth ($10^{-8}$) of a tea.

staking tea => ensures secure system operation
=> so all network participants submit/access pkgs to review them
=> integrate them into apps
steeping tea => support goal of providing network participants
=> to support and use packages
=> meet quality and dependability requirements
==> formulated by tea community through their support/dissent per package

care will be taken when defining/implementing staking/steeping params
=> not to become parasitic

## publish package
=> receive NFT
NFT holder receive package rewards

package maintainers may transfer ownership of package to other package mainteiners
=> by transfering package NFT

**An important part of reputation building relies on the frequency and quantity of quality package submissions.**

blockchain protocol can give owner of many packages elevated rights
decided by chain governance

=> to prevent attack vectors, such as community members buying their reputation, the transfer of the maintainer NFT will not result in a transfer of reputation

Reputation must remain directly associated with a specific developer’s work and must not be transferable.

1. pulblish package version
2. okiad t stirage
3. steep tea tokens
=> receive reputation
=> large reputation gives them special governance role
* maybe accelerated rewards
* decide governance
*

## TOKEN CURATED REGISTRY

## outdated packages
tea package vs tea tasters
under-maintained outdated corrupt pkgs
=> clear indications not living up to community expecttations
=> not delivering trust and support impressed upn them

continued use of legacy package
or legacy version of multi-version langauges

packages remain outdated or corrpt for too long
indicate package maintainer review

**tea tasters**
reviews/claims can steer users to/away from packages

identify shitty packages to get tokens from the maintainers

The same can be said for package supporters and sponsors who staked their reputation on the work of delinquent package maintainers and received rewards for it,

but failed to identify the lack of maintenance or elected to continue to support the package regardless.

# Incentives & Penalties

a reward system built solely on the number of dependents would prevent innovators from disrupting these monopolies unless they are sufficiently funded by third parties or have already accumulated enough resources to self-fund

This approach would likely lead to a shrinking number of contributors, resulting in the polar opposite of what tea is about.

1. As a package steep approaches a governance-defined optimum steeping ratio, its steeping rewards ratio will decrease progressively.

2. When a package exceeds its optimum steeping ratio, the steeping rewards ratio will decrease sharply to de-incentivize package supporters and tea tasters from further steeping highly steeped packages

=> "soft cap"

==> This design could allow lesser steeped packages to become more attractive to both package supporters and tea tasters.

==> It may also incentivize experienced developers to build alternatives to highly-steeped packages, creating an opportunity for the tea community to balance supporting existing software and promoting innovation

S = total token supply

STEEPING RATIO:
The steeping ratio will be calculated using the circulating supply in its initial design
* community may alter this design to improve the system’s scalability further

X = steeping ratio across all packages
= total number of tokens steeped by pkg maintainers, users, supporters, sponsors & tasters
/ total supply

e.g. 0 < X = 1
usually X = 0.05 or something smallish

V = staking ratio
= total number of staked tokens by network participants to secure network

X_ideal = steeping ratio we would like each package to attain for fair distribution fo rewards across all packages + dependencies

X_ideal must be updated as new packages are added to decentralised registry

X_ideal uses "popularity bell curve" (at start of each reward cycle)

T = T(X) = annual steeping interest rate distributed to all members who steep to support open source devs
= steeping reward received per year by "steeper" for entire year

Y = Y(V) = annual staking interest rate distributed to all node operators and network participants who stake to secure network
= annual staking reward per member

O = annual inflation directed at network treasury (e.g. "community taxes")
= may vary as external factors affect token supply

T(X) incentive for people to steep a package
=> increase X for fewer rewards needed
Y(V) incentive for people to stake the network
=> increase V for fewer rewards to secure network

I = T + Y + O = total annual inflation

I = (S_t0 - S_t1) / S_t0

incentivize optional ratio between T and Y

T(X) = X * T(X)
T(X_ideal) = X_ideal + T(X_ideal)

-------------

# MY THOUGHTS

1. package mainteiners make packages
2. devs use packages if they like it
3. devs and end users might pay and reward maintainers
4. anyone can ring a bell on a security flaw
5. if dev doesn't fix it, fork it and maintain it and use new dependency
=> cuts away funds from dev

this is crap
all of tea is crap
and it's team is also crap
fuck this!
i have to rethink it all

-------------

### visualization
Tools that include simple visual and programmable access to the version and reputation of all dependencies within their packages. A clear understanding of which community members support each package and how many tea tokens they are steeping will contribute to the reputation of each package, just as how much a package maintainer is steeping their work communicates how much they stand behind their work.