white-paper

Version 1.9

Tea Network White Paper: From dApp to OP Stack Layer 2

• Max Howell

• Timothy Lewis

Abstract

A system in which open-source developers could receive rewards commensurate with their contributions would enhance the sustainability and integrity of the software supply chain. A decentralized protocol secured by reputation and incentives could accomplish this by facilitating value accrual back to the developers that maintain open-source codebases as a public utility, thus promoting future innovation and growth within the open-source ecosystem. Package maintainers will register their projects with a registry powered by a Byzantine fault-tolerant blockchain. The tea Protocol’s unique “Proof of Contribution” algorithm will determine each project’s contribution and impact to the system’s utility and health. Registered projects will receive rewards from the tea Protocol commensurate with their contribution, be secured through staking, benefit from a reputation system that spans projects and contributors, and have the option to allow communities to govern their regions of the open-source ecosystem, independent of external agendas. The tea Protocol will incentivize the maintenance of open-source by allowing network participants who registered their projects and comply with the rules of the network to receive rewards and contribute to their reputation and their projects. If security or development issues are found, developers can make claims supported by evidence against the package, and slashing may occur. Members of the open-source community can review packages for quality issues, and the protocol can respond to these reviews by enacting proportional slashing events.

Disclaimer

The information set out in this white paper is of a preliminary nature. Consequently, neither the authors nor any of their respective affiliates assume any responsibility that the information set out herein is final or correct and each of the foregoing disclaims, to the fullest extent permitted by applicable law, any and all liability whether arising in tort, contract or otherwise in respect of this white paper. Neither this white paper nor anything contained herein shall form the basis of or be relied on in connection with or act as an inducement to enter into any contract or commitment whatsoever.

Nothing in this white paper constitutes an offer to sell or a solicitation to purchase any tokens discussed herein. In any event, were this white paper to be deemed to be such an offer or solicitation, no such offer or solicitation is intended or conveyed by this white paper in any jurisdiction where it is unlawful to do so, where such an offer or solicitation would require a license or registration, or where such an offer or solicitation is subject to restrictions. In particular, any tokens discussed herein have not been, and, as of the date of issuance of this white paper, are not intended to be, registered under the securities or similar laws of any jurisdiction, whether or not such jurisdiction considers such tokens to be a security or similar instrument and may not be offered or sold in any jurisdiction where to do so would constitute a violation of the relevant laws of such jurisdiction. Do not purchase any tokens unless you’re prepared to lose the entire purchase price. It is a high-risk purchase and you are unlikely to be protected if something goes wrong.

Introduction and Context

The tea Protocol was originally introduced as a decentralized application (dApp) aimed at rewarding open-source software (OSS) developers for their contributions. It operates by integrating with major package managers (e.g. Homebrew, npm, pkgx) and uses blockchain-based tokens (TEA) to remunerate maintainers and contributors. At its core is the Proof of Contribution algorithm that quantifies each project’s impact (teaRank) and distributes rewards accordingly. In the initial implementation, the tea Protocol was built as a smart contract system on an existing Ethereum Layer 2 (Base, Coinbase’s Optimistic Rollup), effectively functioning on the application layer of another network.

Rationale for Evolving to a Layer 2: As usage grew and the limitations of operating purely as a dApp became apparent, the tea team decided to transition the protocol into its own Layer 2 network on Ethereum. By leveraging the OP Stack (Optimism’s modular rollup framework), Tea Network can achieve significantly higher throughput and lower transaction costs while inheriting Ethereum’s robust security. Optimistic rollups like those built on the OP Stack can offer 10x–100x scalability improvements by moving execution off-chain and posting minimal data on-chain. Unlike sidechains, these rollups derive their security directly from Ethereum by publishing transaction data back to L1, meaning the new Tea Layer 2 (“Tea Network”) retains Ethereum-grade security guarantees.

Benefits of Layer 2 Migration: By becoming an OP Stack-based Layer 2, the Tea Network gains:

• Scalability: The network can process many more transactions per second than Ethereum mainnet, bundling them into rollup blocks. This reduces congestion and gas fees for users. For example, Arbitrum (an Optimistic Rollup) at times surpassed Ethereum in daily transaction volume (~1.1M vs. ~1.08M) while maintaining much lower fees, demonstrating the capacity of L2s to handle mass usage.

• Efficiency: Users of Tea Network will enjoy faster confirmation times and cheaper interactions when staking to projects, claiming rewards, or executing governance votes. Batch submission of transactions to L1 and compression techniques drastically cut the per-transaction gas cost.

• Security: Tea Network’s security model is anchored to Ethereum. The rollup is “optimistic,” assuming transactions are valid and using Ethereum as the arbiter in case of fraud. This means as long as there is at least one honest validator watching the Tea Network, any invalid state can be challenged and corrected on Ethereum. In effect, a single honest participant is sufficient to uphold security because the rollup relies on Ethereum’s consensus to settle disputes. This is a stronger security assumption than a standalone sidechain or appchain.

In summary, evolving into a dedicated Layer 2 allows the Tea Protocol to scale to meet global OSS adoption, reduce user friction (through lower fees and faster UX), and integrate deeper into Ethereum’s ecosystem – all while maintaining trustlessness and decentralization. The following sections detail the technical architecture of this new Tea Network, its core components, tokenomics, and the implications for security, governance, and future growth.

Technical Architecture

Overview of the OP Stack: The Tea Network is built on the OP Stack, Optimism’s open-source development stack for creating new Layer 2 rollup chains. The OP Stack provides a standardized set of components (execution client, consensus/rollup node, communication contracts, etc.) maintained by the Optimism Collective, making it easier to launch a new chain that is compatible with other Optimism-based chains. It is designed as a public good, allowing projects like Tea to avoid reinventing core L2 infrastructure and instead leverage a battle-tested framework. In essence, the OP Stack powers Tea Network in the same way it powers Optimism Mainnet, meaning Tea’s L2 chain benefits from features such as EVM equivalence, modularity, and future interoperability within Optimism’s envisioned “Superchain” of interconnected L2s.

OP Stack Infrastructure: The Tea Network’s architecture mirrors that of an Optimistic Rollup:

• Execution Layer: A modified go-ethereum (Geth) client (forked for Tea) runs the Ethereum Virtual Machine (EVM) for the Tea Network. This execution engine is almost fully EVM-equivalent (thanks to Optimism’s Bedrock upgrade), allowing smart contracts from Ethereum to be deployed on Tea with minimal changes. The key customization in Tea’s execution layer is the inclusion of a GPG address precompile (discussed below). Aside from that, the transaction format, gas mechanics, and opcode set align with Ethereum, simplifying development and enabling use of standard Ethereum tooling on Tea Network.

• Consensus / Rollup Layer: Tea Network does not run a separate proof-of-stake or proof-of-work consensus. Instead, it relies on Ethereum’s consensus (proof-of-stake) for security. Transactions on Tea are sequenced by a designated sequencer node (initially run by Tea), which packages L2 transactions into batches (blocks) and periodically submits a transaction containing these batches to the Ethereum mainnet. In Optimism’s design, a single sequencer handles block production to provide instant confirmations and state updates on L2 . Tea inherits this approach: the sequencer offers users fast transaction inclusion on Tea Network and then posts the batched data to Ethereum.

• Data Availability: Each Tea Network L2 block’s data is published on Ethereum, ensuring the L2 state can be reconstructed by anyone independently. In the current implementation, batched transactions are posted to Ethereum as call data. As Ethereum’s roadmap evolves, Tea Network stands to benefit from upgrades like EIP-4844 (Proto-Danksharding) which enables L2s to post data in cheap blob space. Under Optimism’s Bedrock architecture, L2 blocks can be submitted to a special L1 contract or address (e.g. 0xff..0010) using blobs, making data availability secure and cost-efficient . Tea will integrate these capabilities as they become available, further driving down costs.

• Fraud Detection: The Tea Network is an Optimistic rollup, meaning it assumes L2 transactions are valid but allows fraud proofs to be submitted within a challenge window. An off-chain fault proof agent (sometimes called a verifier) monitors the L2 state updates Tea posts to L1. If an invalid state root or transaction is detected, a fault proof (formerly “fraud proof”) can be submitted to Ethereum to challenge it. Optimism currently sets a 7-day challenge period on mainnet , and Tea Network will use a similar window. During this time, funds withdrawn to L1 are locked, and finality is deferred until the window elapses. If a fraud proof succeeds, the invalid batch is rejected and Tea’s L1 published state is rolled back to the last valid point. This mechanism drastically differs from a simple dApp: in the dApp model, security relies solely on the correctness of smart contract code on a single chain, whereas Tea’s L2 design adds a layer of recourse – Ethereum itself – to correct any malicious or invalid L2 behavior. As noted, even a single honest validator or observer is enough to secure the rollup by submitting proofs of fraud.

GPG Address Precompile: A standout feature of Tea’s technical architecture is the introduction of a precompiled contract for GPG (GNU Privacy Guard) key operations. Precompiles are built-in contracts at fixed addresses that perform complex computations more efficiently than regular smart contract code. Tea Network adds a new precompile at address 0x696 (an address chosen for the GPG feature) which verifies digital signatures made using GPG/PGP public keys. In practical terms, this GPG precompile takes as input a message hash, a GPG public key, and a signature, and returns a boolean indicating whether the signature is valid for that message and public key. This functionality is integrated at the protocol level, allowing smart contracts on Tea to leverage proven and widely-adopted PGP cryptography standards for authentication and identity verification, as well as giving developers access to new tools to build on-chain.

The role of the GPG precompile in the Tea Network is transformative: it bridges the world of PGP identity and Ethereum identity. Developers and users can register a GPG public key and effectively use that key to control a smart contract wallet on Tea. The Tea Network’s custom GPGRewardWallet (a smart contract wallet implementation) is designed to utilize this precompile. Each GPGRewardWallet contract is deployed deterministically for a given GPG key (using a create2 factory), and contains the GPG key’s identifier in its bytecode. This wallet can then verify instructions signed off-chain with the corresponding GPG private key. For example, a developer can sign a transaction or an authorization message with their GPG key, and the GPGRewardWallet on Tea will confirm its validity via the precompile before executing the intended action .

Why GPG? PGP/GPG has long been used by developers for code signing, secure communications, and identity (e.g., signing Git commits and verifying software releases). By supporting GPG at the chain level, Tea Network taps into an existing Web of Trust. Developers may use their well-established GPG identities to interact with the blockchain, effectively linking their open-source contributions to on-chain actions in a verifiable way. This enhances security (since GPG private keys are usually kept offline or on hardware devices and are difficult to forge) and also user experience for developers, who can reuse familiar tools. The Ethereum community has discussed the idea of leveraging PGP on-chain to build decentralized identity services or keyservers. Tea Network’s implementation is a concrete step in that direction: it enables a cryptographic identity layer where actions on Tea can be tied to a real-world persona’s key (if they so choose), boosting trust in the provenance of contributions and votes without relying on centralized platforms, in a fully opt-in manner.

Account Abstraction and EIP-7702: Another technical enhancement in the Tea Network is its forward-looking support for account abstraction features. Account abstraction refers to allowing smart contract wallets to mimic externally owned accounts (EOAs) or otherwise letting users define custom verification logic for transactions. Ethereum’s recent EIP-7702 is highly relevant – it introduces a new transaction type enabling EOAs to temporarily execute smart contract code (essentially assigning them smart contract capabilities for a single transaction). In other words, EIP-7702 aims to let normal accounts enjoy the flexibility of contract accounts, paving the way for features like sponsored transactions, multi-sig approvals, or alternative signature schemes natively. Tea Network’s architecture, with the GPGRewardWallet and precompile, is aligned with this vision. By having contract-based accounts that can be controlled by arbitrary signature schemes (GPG or ECDSA), Tea is embracing account abstraction at Layer 2. Moreover, when EIP-7702 (and related proposals like ERC-4337) roll out on Ethereum, Tea’s design will be ready to integrate or support those capabilities. For instance, if Ethereum L1 allows EOAs to delegate to a “smart contract wallet template” for a transaction, Tea Network users could similarly benefit from unified account abstractions between L1 and L2. In summary, Tea Network bakes in account abstraction through its GPGRewardWallet system and is built to be forward-compatible with Ethereum’s AA roadmap, such as EIP-7702 which enables EOAs to use smart-contract features in a trust-minimized way .

Enhancements Over the Original dApp: Compared to the original tea dApp deployment, the new Layer 2 architecture introduces notable improvements:

• Scalability: In the dApp model, every user action (staking TEA, registering a project, claiming a reward) was an Ethereum transaction (on Base or mainnet), competing with all other network traffic. Now, those actions occur on Tea’s own chain with abundant capacity, then settle to L1 in aggregated form. This means far greater throughput and negligible marginal cost per action, removing bottlenecks for adoption.

• Transaction Efficiency: Tea Network transactions consume gas on the L2, which is orders of magnitude cheaper than L1 gas. Users can interact with the protocol with minimal fees (fractions of cents), whereas previously certain complex interactions on Ethereum could be prohibitively expensive during peak congestion. We can see a real-world analogue in Arbitrum: on a day when both Arbitrum and Ethereum processed ~1 million transactions, Arbitrum users paid only ~2.3% of the fees that Ethereum users did – illustrating the cost savings a rollup achieves by batching and offloading work.

• Security Model: The shift to a rollup introduces the security backstop of Ethereum’s validation. In the prior implementation, security relied on the correctness of tea’s smart contracts and the security of the host chain (Base/Ethereum). In the new model, even if a bug or exploit were to occur in Tea’s Layer 2 logic, Ethereum’s fraud proof mechanism provides a chance to challenge and undo malicious transactions, significantly mitigating worst-case scenarios. The requirement that a single honest actor can prevent fraud is a powerful guarantee not present in a standalone dApp environment.

• Extensibility: As a full-fledged chain, Tea Network can incorporate Ethereum Improvement Proposals (EIPs) at the protocol level. The Geth fork can be upgraded with new precompiles, opcodes, or gas adjustments as needed for Tea’s use cases, without waiting on all of Ethereum. This flexibility was not available when Tea was just a contract. For example, Tea implemented the GPG precompile directly, something that would be impossible to achieve via a normal smart contract on mainnet.

• Interoperability: Through the OP Stack, Tea Network can natively interoperate with other Layer 2 networks in the Optimism ecosystem. Future plans for the Optimism Superchain mean multiple L2s will communicate trustlessly. As Tea joins that ecosystem, it could allow cross-chain messaging between Tea and chains like Optimism or Base (e.g., recognizing reputation or assets across chains), broadening the reach of the tea Protocol beyond a single chain.

In conclusion, the Tea Network’s technical architecture is a robust Layer 2 rollup design that combines the strengths of Optimism’s OP Stack (scalability and Ethereum alignment) with Tea’s unique innovations (GPG identity precompile and advanced account abstraction features). This foundation sets the stage for the specialized components of the Tea Network described next.

Tea Network Components

This section delves into the major components of the Tea Network’s Layer 2 architecture and how they work together to support the protocol’s mission.

Layer 2 Core Components:

• Sequencer and Nodes: The Tea Network initially utilizes a single sequencer model (common in early rollups) to produce blocks. The sequencer node receives L2 transactions (from users or dApps on Tea), orders and executes them using the Tea execution engine, then submits the resulting transaction data and state root to Ethereum. Community full nodes can run the same software to independently verify blocks. The sequencer provides rapid confirmations (often within ~2 seconds per block, as in Optimism’s network) so users experience near-instant transaction finality on L2. In the future, the sequencer role can be decentralized – multiple validators or block producers might compete or rotate via a consensus mechanism, potentially using TEA staking (as discussed in the Tokenomics section) to secure block production. This evolution would make Tea Network permissionless at the block production level, akin to a decentralized validator set.

• Bridge Contracts: Bridging between Ethereum (Layer 1) and the Tea Network (Layer 2) is handled by a set of contracts largely inherited from Optimism’s design. On Ethereum, the L1StandardBridge contract holds custody of tokens (like TEA or ETH) that are deposited into L2, and the L1CrossDomainMessenger passes arbitrary messages to the L2. Corresponding contracts on Tea Network (L2 side) release tokens to users and deliver messages to contracts based on L1 inputs. When a user deposits assets, the flow is: user sends tokens to the L1 StandardBridge -> event is read by the Tea sequencer -> equivalent tokens are minted or released to the user’s address on Tea L2 . This typically completes within one Tea block, meaning deposits finalize on L2 within minutes of the L1 transaction. Conversely, withdrawals initiate an L2 transaction (locking tokens on Tea and informing L1 of intent), then require the challenge period to pass. After that, the user can execute a finalize step on L1 to unlock the tokens from the L1 bridge contract . The standard bridge design provides trust-minimized connectivity between Tea and Ethereum; no third-party custodians are needed – security is guaranteed by the rollup fault proof proof-of-fraud mechanism and Ethereum itself.

• GPG Address Precompile & GPG Reward Wallet: The GPG address precompile (at address 0x696 on Tea Network) is a low-level component, but its presence has ripple effects throughout the stack. This precompile is essentially a native PGP signature verification engine. It takes four inputs: a 32-byte message digest, an 8-byte key ID, a binary-encoded public key, and a signature. Internally, it performs the cryptographic checks (RSA or ECC based on the PGP key type, parsing the signature structure, etc.) and returns true/false for validity . The precompile is optimized in native code, making these operations far cheaper than if implemented in Solidity. Built atop this is the GPGRewardWallet system – a smart contract wallet factory (GPGRewardWalletDeployer) and implementation that leverages the precompile. Each GPGRewardWallet contract is a minimal proxy that holds a specific GPG key’s ID in its code (for identification). The factory uses a create2 scheme to ensure a unique deterministic address for any given GPG key (so a particular key always maps to the same contract address). When a user wants to activate their GPG identity on Tea, they deploy a GPGRewardWallet via the factory, providing their public key. The result is a wallet contract that the user can control by presenting valid signatures from their GPG private key. The wallet contract also supports adding traditional EOA addresses as authorized signers (which themselves can be gated by requiring a GPG signature to add). This design means a developer could, for example, use their hardware GPG key to sign an AddSigner message that authorizes their MetaMask wallet address; thereafter, they can transact on Tea with either their GPG key or that Ethereum key, offering both convenience and security.

Use Cases of GPG Identities: With this GPGRewardWallet mechanism, Tea Network introduces new possibilities for secure user identity and verification:

• Verified Developer Identities: OSS maintainers often sign software releases or git commits with GPG. Tea can allow maintainers to link those same keys to on-chain actions. For instance, a maintainer could register their project on the Tea Network by signing the registration transaction with the same GPG key they use for their code. Users of the protocol (or automated systems) could verify on-chain that the person performing an action is indeed the owner of the PGP key associated with a popular open-source project, creating an authenticated link between version-control signatures (off-chain) and Tea (on-chain).

• Decentralized Key Infrastructure: Over time, the Tea Network could become a decentralized key directory. With appropriate smart contracts, users might publish their GPG public keys on-chain (signed by the key itself or attested by others), turning the Tea Network into a decentralized PGP keyserver. This aligns with the Ethereum community’s motivation to improve key discovery and trust without centralized servers. In Tea’s context, an on-chain registry of GPG keys tied to Ethereum addresses and perhaps DID profiles could emerge, enhancing both security and reputation tracking.

• Privacy-Preserving Login: Users could use their GPG keys as an alternative login method to dApps on Tea, as opposed to Metamask signatures. Since GPG keys can be kept completely offline (airgapped) and only produce a signature when needed, users might prefer this for certain interactions. (Additionally, because the GPG signature verification is done in a precompile, no one sees the actual public key on-chain unless needed – potentially allowing selective disclosure of identity.)

• Project Registry and Package Manager Integration: While not a “layer 2 infrastructure” component per se, a key on-chain component of the Tea Network is the decentralized project registry inherited from the original protocol design. This registry is a smart contract (or set of contracts) on Tea that tracks all onboarded OSS projects, their metadata, maintainer addresses, and staking/reputation status. It is the on-chain source of truth for which packages are participating in the tea Protocol and their current scores (teaRank) or reputation. In the L2 context, this registry can be much more feature-rich than on L1 due to lower cost: it can store more detailed metadata, maintain complex structures of dependencies, and be updated frequently as project metrics change, all without prohibitive gas cost. This registry is complemented by off-chain package manager hooks – for example, integrations or plugins for npm, Homebrew, etc., that query Tea Network’s registry to fetch info (like “is this package verified or highly ranked on Tea?”). Thus, the Tea Network’s blockchain acts as a back-end for package managers, providing an immutable ledger of package trust and contribution data .

• On Tea L2, one can imagine the registry being augmented with NFT representations of packages or contributor profiles, decentralized storage links for documentation, and more, since performing these operations is now feasible at scale. The Storage System for package data mentioned in the original white paper (perhaps involving IPFS or Arweave for storing tarballs, etc.) would also interface with Tea L2 for integrity checks. Content-addressed hashes of OSS releases could be logged on-chain to ensure immutability and traceability of the supply chain, with Tea’s consensus anchoring them periodically to Ethereum for ultimate security. This is a significant expansion beyond the original dApp, moving toward a decentralized package registry that the white paper envisioned – now implementable on a performant L2.

• Cross-Chain Communication: The Tea Network, by virtue of being an Ethereum rollup, can also serve as a hub for cross-chain activity related to OSS incentives. Using the Optimism/OP Stack standard message passing, Tea can communicate with other chains. For instance, a smart contract on Ethereum or another L2 could send a message to Tea (via the Optimism-style CrossDomainMessenger) to trigger an action – such as updating a project’s score after a certain on-chain event. Likewise, Tea can output messages that are read by L1 or others (once the output is finalized on Ethereum). This enables scenarios like bounties or rewards that originate on Ethereum mainnet but are distributed on Tea, or conversely using Ethereum mainnet as an archive or backup for critical Tea data. Being part of the OP Stack ecosystem means down the line, Tea Network could participate in shared sequencing or bridging with networks like Base and Optimism, increasing reliability and potentially even atomic transactions across them (the Superchain concept). From a component standpoint, this means Tea’s node software includes a cross-domain message inbox and outbox, tracking L1->L2 and L2->L1 messages. The security of these is, again, rooted in Ethereum – messages from L1 to Tea are trusted after a few confirmations on Ethereum, while messages from Tea to L1 are subject to the challenge period (they only execute on L1 after Tea’s state is finalized).

In summary, the Tea Network comprises the blockchain core (sequencer, nodes, bridge contracts) and unique protocol-specific modules (GPG identity system, OSS registry). Together, these components create a Layer 2 platform tailored for the open-source ecosystem. The chain’s capabilities are generalized (anyone can deploy arbitrary smart contracts on Tea as on any EVM chain), but its value-added services (like the GPGRewardWallet and package registry) make it especially powerful for applications involving developer identities, software distribution, and decentralized trust for software. Bridging ensures Ethereum remains the settlement layer, anchoring Tea’s state and connecting Tea to the broader crypto economy. With the technical underpinnings described, we now turn to how the economic design (tokenomics) undergirds and incentivizes this new network.

Tokenomics and Incentives

The transition to a Layer 2 network entails a significant evolution of TEA tokenomics to support both the original OSS reward model and the new infrastructure and security needs of the chain. This section compares the new token economic design with the original dApp model, highlighting changes in token utility, distribution, and incentives for various participants (developers, users, and validators).

TEA as the Native Layer 2 Token: In the original protocol, TEA was an ERC-20 token that users staked on projects and earned as rewards. Gas fees for interactions were paid in ETH (or the native token of the host chain, e.g. ETH on Base). With Tea Network becoming its own chain, TEA is now the native currency of the Layer 2. This means that transaction fees (gas) on the Tea Network are paid in TEA. The TEA token thus acquires a fundamental utility in the network’s operation: every transfer, contract execution, or stake operation on Tea requires TEA for gas. According to the team’s token overview, TEA is required to register and support software projects and pay gas fees for transfers and protocol activity . This marks a new demand driver for the token; as usage of the chain grows, developers and users must hold a balance of TEA to fuel their transactions. It aligns the token’s value with network utilization (similar to how ETH is valuable partly because it’s needed for gas on Ethereum).

Staking and Support Mechanisms: The original model of “staking your tea” to support OSS projects remains central. Users can lock TEA tokens on the Tea Network’s smart contracts to endorse particular open-source projects. By doing so, they signal trust and share in the project’s future reward flow (the protocol would distribute TEA rewards to both maintainers and those who staked on them, proportional to teaRank and stake contributions). This mechanism continues on Tea L2, but with improvements in efficiency. Staking to a project is just an L2 contract call (cheaper and faster than L1). Projects can have many micro-stakes added or removed dynamically without incurring high gas, enabling more granular and frequent support from the community. Additionally, staking is used in new ways:

• Vulnerability Bounties: Tea Network implements an on-chain vulnerability reporting and bounty system. Ethical hackers or users who find bugs in registered OSS packages can report them through the protocol. To prevent spam and low-quality reports, reporters must put up a stake of TEA as a bond. Vulnerability reporters must stake TEA to submit a report and earn bounties . If the report is valid (confirmed by maintainers or adjudicators), they get a TEA reward (and their stake back, possibly with a bonus); if not, their stake might be slashed or forfeited. This use of TEA for security incentives encourages the community to actively police package quality and security, a crucial aspect of securing the software supply chain.

• Node/Validator Staking: Although the initial rollout of Tea Network will have a centralized sequencer, the roadmap likely includes decentralizing validators. In an Optimistic Rollup, validators (entities submitting state roots to L1 and potentially challenging fraud) might be required to put up a bond in TEA to participate. This is analogous to the concept of a fault prover bond – to submit a fault proof, one may need to bond some amount that gets slashed if the proof is invalid. Moreover, if and when multiple sequencers are allowed (perhaps via a round-robin or auction mechanism like some rollups plan), those sequencers could be chosen or weighted based on TEA stake (similar to a Proof-of-Stake system). The TEA token thus could play a role in Sybil-resistance and economic security of L2 consensus. For example, if Tea implements a sequencer set, bidders would burn or lock TEA for the right to produce blocks for a period. While details are to be determined, the Layer 2 setup opens the door for TEA to secure the network itself, beyond securing just the application logic.

Reward Distribution and Token Emission: The core purpose of TEA remains to reward open-source contributions. Tea Network will continue to calculate rewards for projects (using the off-chain metrics and on-chain stakes) and distribute TEA tokens periodically to those projects and their supporters. In the original model, these rewards might come from a token inflation or a treasury. On Tea L2, this process can be more transparent and community-governed. The protocol can charge fees or take a small percentage of staking rewards to fund a protocol treasury (a DAO fund in TEA). Indeed, the tokenomics are designed such that fees from various OSS activities on the network accrue back to TEA token holders engaged with the network . Concretely, this could mean:

• A portion of transaction fees on the network are funneled into a treasury or reward pool (rather than all being burned or given to miners as on Ethereum). This pool then redistributes tokens to active contributors in OSS.

• When new projects onboard, they might pay a listing fee in TEA (to prevent spam). Those TEA could be redistributed as rewards.

• If a project’s package is widely downloaded or depended upon, the protocol might levy a tiny TEA fee from dependent projects (as per the value flow envisioned in Proof of Contribution). These fees go into the reward algorithm, ultimately paying out to maintainers. Because we are in a full blockchain environment, implementing such micro-fees and recursive distribution is more tractable.

The TEA token may have an inflation schedule to continuously incentivize participation. For example, an annual issuance allocated to maintainers and stakers (similar to how some PoS networks or mining networks issue new coins to reward participants). This must be balanced against the desire for token value stability. Governance (see next sections) will likely oversee any inflation parameters or use of treasury tokens.

Comparison with Original Model: In the original tea protocol, TEA’s utility was focused on governance and staking in the context of OSS rewards. As a dApp, it did not need to facilitate gas or infrastructure. Now, TEA has a broader utility set:

• Gas Token: Perhaps the biggest change – TEA is consumed for gas on every transaction on Tea Network . This creates a direct link between network activity and token demand (similar to ETH for Ethereum, or MATIC for Polygon, etc.), which did not exist previously.

• Incentive Alignment: TEA is still staked to signal support for projects, but the feedback loop is stronger. Stakers potentially earn a portion of not just inflationary rewards but also fee revenue from the network. The documentation suggests that a portion of fees from OSS activities will accrue back to engaged TEA holders . This implies if you stake and actively participate, you might receive dividends or yield in TEA drawn from network usage. Originally, rewards came from new issuance or an overall pool – now it could be partially funded by actual usage fees, making the model more sustainable.

• Governance Power: Previously, holding TEA allowed one to participate in governance votes about protocol parameters. This remains, but with the network upgrade, governance might extend to chain-level decisions (like upgrading the rollup software, managing the sequencer, etc.). The value of governance rights may thus increase. The TEA token’s role in governance is discussed in detail in the Governance section, but tokenomics-wise: TEA is an ERC-20 on Ethereum mainnet (for broad accessibility and distribution) but effectively functions as the native coin on Tea L2. Bridging ensures that the same token can move between L1 and L2 – users may hold TEA on Ethereum (for custody or trading) and then bridge it to Tea L2 when they want to use it for gas or staking.

Staking Mechanisms, Validator Incentives, and User Benefits:

• Staking & Slashing: Various protocol roles will involve staking TEA. Project maintainers might be required to stake a small amount of TEA when registering a project (to discourage low-quality submissions and slash if the project turns malicious). Validators (if permissionless) will stake TEA and be slashed for malicious behavior (like submitting invalid state roots that get proven fraudulent). Community reviewers who stake on a project’s quality are effectively putting skin in the game and can be slashed if they vouched for a project that then is found to be malicious (creating a disincentive for blindly staking on every project, and an incentive to do due diligence). These slashing conditions secure the network and the integrity of the OSS registry.

• Validator/Sequencer Incentives: In the near term, the Tea Association or core team runs the sequencer and can be subsidized by a portion of L2 gas fees. In the long term, if multiple sequencers are run, they will need incentives to participate honestly. One model is sequencer auctions where candidates bid TEA for the right to produce blocks (the highest bidder gets to be sequencer for a fixed interval, and their bid is burned or given to the treasury – this mechanism, used by networks like SUAVE proposals, could be considered). Another is round-robin with slashing: each validator takes turns proposing blocks but must stake TEA and gets slashed if they attempt to censor or post invalid state. They would earn the gas fees from the blocks they produce, making it profitable to behave correctly. Because Tea’s throughput and usage could be high (given many OSS transactions), the fees themselves could be a significant incentive.

• User Benefits: Regular users (developers, project supporters, etc.) benefit from the new tokenomics in several ways:

• Lower Fees: Paying gas in TEA on the Tea Network will generally be much cheaper than paying ETH on mainnet for equivalent actions. Users can support more projects or make smaller contributions that wouldn’t have been economical before. Essentially, their TEA goes farther on L2.

• Earn by Participating: Users can earn TEA rewards by actively using the network – e.g. by staking to projects that do well, by reporting bugs, by curating packages, or simply by providing liquidity if there are DEXs on Tea. The tokenomics could include liquidity mining or usage mining programs (for instance, early users of the Tea Network could get bonus TEA rewards or NFT badges).

• Alignment with OSS success: Since TEA value is tied to network success and network success is tied to OSS adoption, users holding TEA essentially hold a stake in the growth of the open-source ecosystem’s reward system. This could galvanize a community of token holders who advocate for more projects to join Tea, more developers to accept TEA, etc., driving a positive feedback loop.

To illustrate the token flow, consider an example: A developer publishes a new library and registers on Tea, staking some TEA. Over time, the library becomes widely used; the Proof of Contribution algorithm assigns it a high teaRank, and it starts earning TEA from the protocol’s reward pool (funded by maybe both inflation and a cut of fees from other projects using the library). Those TEA rewards are split between the maintainers of that project, delivered on Tea L2. The maintainer might bridge some rewards to Ethereum to cash out via a DEX or use some to engage with other projects on the tea Network. Meanwhile, all interactions (staking, reward claims, etc.) incurred small TEA gas fees, some of which went into the treasury. At quarter’s end, a certain amount of TEA in the treasury is distributed to incentivize new OSS communities, to active voters or burned to benefit all holders (governance decides). In this cycle, every action involves TEA: as gas, as stake, as reward, as governance power. This comprehensive integration of the token into the system’s functionality is a hallmark of the new tokenomics.

In comparison, originally TEA acted more like a pure governance and reward token. Now it is multi-dimensional: gas, governance, staking, and utility token. This should strengthen the token’s value proposition and incentive alignment. It means all stakeholders – maintainers, backers, validators, and regular users – have roles to play and incentives to hold and use TEA.

The tokenomics design also learns from other major Layer 2 implementations:

• Optimism (OP token): Optimism introduced the OP token for governance and funding public goods, but notably not as a gas token (Optimism still uses ETH for gas) . Tea diverges here by using TEA for gas, which more closely resembles chains like BNB Chain or Avalanche. However, Tea can still adopt Optimism’s idea of an ecosystem fund – a portion of TEA (from initial allocation or ongoing fees) could be allocated to a grants program to fund open-source tooling (which directly aligns with Tea’s mission of supporting OSS).

• Arbitrum (ARB token): Arbitrum’s ARB is purely a governance token for the Arbitrum DAO and does not have a role in gas or validation. Tea’s TEA token stands to be more utilitarian. But Tea can emulate Arbitrum by establishing a DAO treasury and Security Council. Arbitrum set aside a large treasury controlled by its DAO for protocol upgrades and ecosystem support . Tea could do similarly, meaning token holders control funds to, say, incentivize certain package ecosystems or sponsor hackathons. Additionally, Tea might implement a Security Council (multisig of trusted community members elected by TEA holders) that can act quickly to patch security issues or halt the protocol in an extreme emergency, with later ratification by a vote (Arbitrum DAO has such a council for fast intervention ). If so, council members could receive a TEA stipend for their duties.

In conclusion, the Tea Network’s tokenomics reinforce its technical architecture: TEA is the lifeblood of the new Layer 2. It provides economic security and incentives at the chain level (through gas and potential validator staking) and continues to drive the unique value proposition of the tea Protocol (through staking to OSS projects, distributing rewards, and enabling governance). These changes are designed to ensure a sustainable, self-reinforcing ecosystem where contributors are rewarded, token holders have a say in the protocol’s direction, and the network remains secure and useful long-term. The next section will explore the application layer and use cases unlocked by this new Layer 2 design, showing how these technical and economic pieces come together in practice.

Use Cases and Application Layer

Migrating to an OP Stack Layer 2 significantly broadens the horizon of what can be built and supported on the Tea Network. Beyond simply replicating the original protocol’s features on a faster chain, the new architecture enables expanded use cases and richer applications that were previously impractical. In this section, we explore the new and enhanced use cases facilitated by Tea’s Layer 2, and how they demonstrate the network’s utility beyond the initial dApp’s functionality.

1. Scalable OSS Rewards and Interactions: The primary use case – rewarding open-source contributions – is supercharged on the Tea Network. In the dApp version, users could stake to projects and earn rewards, but high gas fees limited how often and how many projects a typical user might support. Now on Tea L2, a user can stake small amounts of TEA to dozens of libraries, upvote or review projects, and claim micro-rewards frequently, since each action costs pennies or less in gas. This granularity means Tea can capture a far more detailed graph of contributions and endorsements. Maintainers can update their project info, publish releases, or send thank-you NFT badges to contributors via on-chain transactions without worrying about cost. This creates a much more interactive and engaging platform for OSS, akin to a social network of code, but secured on-chain. The result is a richer dataset for Proof of Contribution and an always up-to-date reputation system for developers and packages. Essentially, the core use case of tea – incentivizing and analyzing OSS usage – can now operate in real-time at scale.

2. Real-Time Incentivized Testnets and Developer Sandboxes: The Tea Network itself can host incentivized campaigns to bootstrap activity. In fact, the team launched the Assam testnet as an “incentivized testnet” showcasing some of these possibilities. Participants in Assam were encouraged to build and play on the network: deploying smart contracts, sharing test tokens, and even playing classic blockchain games . This was not directly related to OSS rewards, but it served to stress-test the network and reward ecosystem engagement. The testnet environment introduced gamified tasks – for example, rewards for top token holders, top token distributors (to encourage transactions), and top smart contracts by activity . These kinds of campaigns demonstrate Tea Network’s flexibility as a general-purpose blockchain platform. They also help attract a community of Web3 enthusiasts and developers, beyond just open-source maintainers. By hosting such applications (like nostalgic games or trading competitions) in parallel, Tea Network gains activity and attention that ultimately spills over to the core OSS mission (some of those engaged users can be funneled into contributing to or using the OSS reward features).

3. Decentralized Package Infrastructure: One of the envisioned real-world applications is a decentralized package registry and package manager integration. On Tea Network, every package (project) registered can be represented on-chain with a unique ID. Using Tea’s open APIs or subgraph, a package manager (like a decentralized version of npm or Homebrew) can query the blockchain to resolve package information. This opens use cases such as:

• Verified Downloads: A user installing a package could automatically check Tea Network to see if the package is verified, what its teaRank is, and whether any vulnerability reports are pending for it. If something is amiss (say the package was flagged on Tea with a vulnerability and slashed), the package manager could warn the user or fetch an earlier safe version. This brings blockchain-backed security to everyday software installation.

• Automatic Rewards Distribution: When a company or individual wants to financially support the open-source projects their software depends on, they could use Tea Network as the rails. For example, a company could allocate a budget of TEA and have a script that scans their dependency tree, then automatically stakes TEA to those dependencies’ addresses on Tea Network proportional to usage. This process could even be implemented as a smart contract or DAO on Tea, taking corporate donations and streaming them to OSS maintainers trustlessly. Because Tea can handle many micro-transactions cheaply, even a large graph of dependencies with tiny allocations is feasible.

• Persistent Developer Profiles: Developers can have on-chain profiles (perhaps tied to their GPG identity or an ENS name) listing all their projects and contributions. This can serve as a portable resume. When applying for a job or a grant, a developer could point to their Tea Network profile, which shows verifiable data: number of projects maintained, total TEA earned through Proof of Contribution, endorsements from other devs (if others stake on them or leave on-chain reviews), etc. This is a use case bridging professional networking and blockchain.

• Donations and Patronage: Tea Network can facilitate direct donations to projects. The Donating to OSS Projects flow (advertised in the tea docs) becomes straightforward – a donor can send TEA (or even other bridged tokens) to a project’s address on Tea, which could trigger a contract that stakes it or distributes it among maintainers. Unlike traditional platforms, this can be non-custodial and automated. Donors could also receive NFT badges or a reputational score on Tea for supporting many projects, creating an on-chain record of patronage.

4. Expanded Gaming and Experimental Apps: Outside the strict OSS scope, the Tea Network’s low fees and Ethereum compatibility make it suitable for various dApps. The Assam testnet already hinted at gaming by running classics like Satoshi Dice and Fomo3D . On mainnet, one can imagine hackathons where developers deploy innovative dApps on Tea to demonstrate the network’s capability. Some possible applications:

• DAO Governance Tools: Tea Network’s governance features (with GPG integration) could be offered as a service to other communities. For example, an open-source project community could run their elections or votes on Tea Network using TEA or a project-specific token. Since Tea has account abstraction, one could set up voting where participants sign votes with GPG keys (proving one-person-one-vote if keys are verified identities), adding integrity to DAO votes. The low cost ensures even DAOs with many voters can operate cheaply.

• Micropayments and Tipping: With TEA as currency and negligible fees, Tea Network could support tipping systems for content creators or developers. A browser extension could allow anyone to tip a GitHub repository author with TEA via the Tea Network, sending a small amount (like $0.10 in TEA) for a helpful answer or useful code snippet. Ethereum mainnet micropayments are not practical, but on Tea they are. Such tipping could integrate with existing platforms (via oracles or APIs) or through native web3 platforms.

• Education and Quests: To onboard more developers, Tea can host interactive quests – smart contract puzzles, testnet challenges (like “find an exploit in a deliberately insecure contract for a reward”), or coding challenges where solving them triggers on-chain validation and reward distribution. This leverages Tea’s cheap transactions for rapid iteration and feedback. It also ties into open-source by encouraging learning and improvement in smart contract security and development.

5. Use Cases Leveraging Account Abstraction (AA): Because Tea Network supports advanced AA, some novel applications become possible:

• Meta-transactions and Sponsorship: A dApp on Tea could pay gas on behalf of users (by using contract wallets and paymaster mechanisms). For example, an OSS maintainer could ensure that new contributors don’t need to buy TEA to submit their first contribution. The maintainer can sponsor those transactions by funding a paymaster that covers gas for any transaction involving their project contract, making onboarding seamless. This is enabled by account abstraction where a contract (the paymaster) can handle gas logic. EIP-4337 style user operations could be implemented on Tea for an even smoother user experience.

• Multi-Key Authentication: Using Tea’s GPGRewardWallet, apps can require dual signatures for critical actions (one with the user’s Ethereum key and one with their GPG key). An example use case is managing high-value treasury moves in a project: the maintainer could configure that any treasury withdrawal from the project’s funds requires confirmation with their GPG key (likely stored offline) in addition to their regular on-chain key. This significantly reduces risk of hacks (an attacker would need to compromise both keys). It’s a two-factor auth scheme natively on-chain.

• Login with Ethereum/GPG: Outside the blockchain itself, Tea’s AA could integrate with web2. For instance, “Login with tea Network” could be an OAuth-like service where, instead of a password, a user signs a message with their GPG or Ethereum key and a Tea Network service verifies it via the precompile and logs them in. Since GPG keys can attach to an email, this can provide an identity that web2 services accept (with the blockchain acting as the verifier of the signature). It’s like a decentralized single sign-on. This use case intersects with decentralized identity (DID) systems and could make Tea Network a player in the self-sovereign identity space.

6. Real-World Impact and Adoption Scenarios: Ultimately, the Tea Network’s expanded functionality aims to make open-source development more sustainable and integrated with the blockchain ecosystem. Real-world applications envisioned include:

• Enterprise Open-Source Support: Large enterprises using open-source could interact with Tea Network to automate their compliance and support. For example, an enterprise DevOps system might query Tea to ensure none of the open-source components they use are marked as insecure (leveraging Tea’s registry and vulnerability reports) – essentially a decentralized “security feed”. If a new zero-day in a library is reported on Tea, an enterprise could be alerted immediately on-chain rather than via slower traditional channels.

• Government and Institutional Funding: Governments or NGOs that grant funds to open-source projects can do so through Tea Network, for transparency and impact tracking. A grant can be disbursed in TEA with conditions encoded in a smart contract (e.g., milestones that trigger payouts). The public can see the grant’s distribution and the outcomes (did the project improve its rank? did it attract more stakers?), providing accountability. This can encourage more funding sources to go on-chain where results are measurable via Tea’s metrics.

• Marketplace for OSS Services: Tea Network could host a marketplace where developers offer services (like support contracts, custom feature development) and get paid in TEA or other tokens. By having their reputation and prior contributions visible on-chain, it’s easier for customers to choose credible developers. Smart contracts could escrow payments and release upon completion, leveraging the network’s trust mechanisms.

In summary, moving to Layer 2 not only accelerates the existing tea Protocol workflows but also opens entirely new avenues. The Tea Network can serve as a multi-purpose platform centered on open-source: part decentralized app store, part social network for developers, part identity system, and part DeFi-like economy for software collaboration. It retains all general capabilities of an EVM chain, meaning it can host DeFi, NFT, and gaming dApps as well – which can enrich the ecosystem and draw more users who might then engage with the OSS aspects. The key differentiation is that all these uses benefit from or feed into the open-source mission, either by bringing more activity (hence fees and attention) or by directly integrating with the OSS reward system.

The original dApp scratched the surface of financially empowering developers. The new Tea Network, with its broader use cases, aims to create a vibrant, self-sustaining environment where open-source technology and blockchain technology co-evolve. In the next section, we turn to how such an ecosystem is governed, as decentralized governance will be crucial to guide the Tea Network’s growth and maintain alignment with community interests.

Governance Model

With the Tea Network’s transition to a Layer 2, governance becomes a multi-faceted domain encompassing both the on-chain protocol governance (deciding rules of the reward mechanism, token parameters, etc.) and the network governance (upgrades to the chain, sequencer configuration, etc.). A robust decentralized governance model is critical to ensure that no single entity controls the network’s evolution and that the community of TEA token holders, OSS developers, and users have a voice. This section outlines the updated governance framework, its mechanisms, and how it draws from best practices in Ethereum and other DAO ecosystems.

Decentralized Decision-Making: In the spirit of open-source collaboration, the Tea Network embraces decentralized governance via a DAO (Decentralized Autonomous Organization). TEA token holders are the core stakeholders of the DAO. By staking or locking their TEA for governance (to prevent transient speculation from influencing votes), holders can propose and vote on changes to the protocol. This aligns with the original use of TEA for governance of the OSS reward parameters , but now extends to governing the Layer 2 network itself. For example, decisions that the Tea DAO would handle include:

• Upgrading the Tea Network protocol (e.g., adopting a new version of the OP Stack, adding a new precompile or EVM extension, changing sequencer decentralization parameters).

• Adjusting economic parameters (inflation rate of TEA, reward distribution formulas, fee allocation between treasury vs. sequencer vs. stakers).

• Managing the community treasury (funding grants for development tools, sponsoring security audits, or even funding public goods in the broader Ethereum ecosystem in line with Tea’s mission).

• Onboarding new package manager integrations or partnerships (for instance, deciding to officially support a new language’s package ecosystem which might require some on-chain schema or oracles).

• Any changes to the rules around staking, slashing, and rewards that directly impact the OSS contributors.

The governance process will likely involve a proposal stage (where ideas are discussed, perhaps off-chain on forums or Commonwealth/Discord), followed by an on-chain vote using TEA. The voting power is typically proportional to the amount of TEA locked in governance by a user (similar to the token-weighted voting model used by many DAOs) . To ensure broad participation and prevent whales from unilaterally controlling outcomes, the Tea DAO might implement delegation – token holders can delegate their voting power to representatives or experts in the community who actively participate in governance debates . This has precedent in many DAOs and helps create a meritocratic layer of governance (where delegates build reputation by voting wisely and communicating with the community).

Governance Structure – Inspiration from Optimism and Arbitrum: Tea’s governance model takes cues from established L2 governance structures while tailoring them to the OSS context:

• Optimism’s Two-House Governance: Optimism introduced an innovative two-chamber governance: a Token House (OP token holders) and a Citizens’ House (non-transferrable “citizen” NFTs for public goods governance) . The Token House governs technical and economic decisions, while the Citizens’ House allocates retroactive public goods funding. Tea Network could adopt a similar bicameral approach. The Tea Token House (TEA holders) would make decisions about protocol upgrades, tokenomics, etc. Meanwhile, a Contributor House could be formed – comprised not of token balance but by reputation or contribution scores (or perhaps elected OSS community leaders). This Contributor House might have veto power or advisory power on decisions that directly impact OSS developers, ensuring that governance doesn’t skew solely to token-weighted interests if those ever diverge from the interests of active developers. For example, if TEA holders (some could be pure investors) proposed to divert all rewards to token staking instead of maintainers, a Contributor House representing developers could push back. This structure draws on the idea that tokenholders are one constituency, but not the only stakeholders . Balancing economic incentives with the ethos of OSS is important; a two-house model could help avoid governance capture by purely economic actors.

• Arbitrum’s On-Chain DAO: Arbitrum launched a fully on-chain DAO where ARB token holders vote on proposals (AIPs) that can directly execute on-chain if passed . They have a Constitution and a Security Council for emergencies . Tea Network can mirror a lot of this: having a Tea Improvement Proposal (TIP) system for formal changes, an on-chain voting portal, and a community-elected Security Council. The Security Council, perhaps 5-7 reputable community members or multi-sig holders, would have the mandate to act quickly in case of critical issues – for instance, if a severe bug is found being exploited, the Council could, via a special governance mechanism, pause the sequencer or upgrade the contract to fix it, subject to later review by the broader DAO. This is similar to Arbitrum’s council which can bypass the normal proposal timeframes to secure the network . The existence of this body is an acknowledgment that on-chain voting can be slow or ill-suited to emergency response, so a safeguard exists. Council members would be periodically elected by TEA holders (say every 6 months) , ensuring accountability.

• Treasury and Public Goods: Both Optimism and Arbitrum put emphasis on funding public goods – Optimism with its RetroPGF (Retroactive Public Goods Funding) and Arbitrum with a large token allocation to a DAO treasury for development. Tea Network, given its focus on OSS (a public good), will likely allocate a substantial portion of TEA (either from genesis or ongoing fees) to a tea Treasury controlled by the DAO. Governance will decide how to spend this treasury. Obvious uses are funding improvements to the Tea protocol itself (grants for building better tooling, documentation, perhaps even funding developers to integrate Tea with more package managers), and rewarding contributions that don’t directly earn token rewards otherwise (for instance, someone who evangelizes and brings 100 new projects onto Tea might get a special grant). The governance model should incorporate a transparent process for treasury proposals and disbursements, taking inspiration from how Ethereum’s DAOs (like Uniswap’s or others) manage grant programs.

Participation and Inclusivity: To make governance accessible to both technical architects and non-technical stakeholders (such as open-source advocates who may not be blockchain experts), the Tea Network will invest in off-chain tools and processes:

• A governance forum where proposals are presented in understandable terms, with pros/cons, and ample time for discussion. In these discussions, both technical details (perhaps provided by core devs or technical working groups) and broader implications (provided by community members, possibly with OSS background) are hashed out.

• Voting interfaces that are user-friendly, possibly integrated into the Tea dApp, so that even maintainers who only casually use crypto can cast votes with a few clicks (for example, signing a vote transaction via their GPGWallet or MetaMask).

• Education and transparency are key. All proposals can be tracked on-chain, and results are visible. The governance smart contracts would likely be an upgraded version of OpenZeppelin’s Governor contracts or Compound’s governance, customized for layer 2 deployment. These contracts ensure on-chain tallying of votes and execution of proposals that pass.

DAO Integrations: The Tea Network DAO doesn’t exist in isolation. It can integrate with the wider DAO ecosystem:

• It could use Snapshot (off-chain voting) for low-stakes signaling and use on-chain voting for binding decisions, to save gas and complexity.

• It might partner with platforms like Tally or Boardroom which provide dashboards for DAO analytics, so anyone can see voting turnout, proposal history, and delegate performance.

• Given the technical nature of some decisions, Tea DAO might form working groups or subcommittees. For instance, a “Protocol Upgrade Group” of volunteer experts can draft technical proposals (like adopting EIP-4844 when Ethereum is ready) and present them to the DAO. A “Community Committee” might vet community grant applications and make recommendations.

• Cross-DAO collaboration: Tea’s mission overlaps with public goods funding. The Tea DAO could coordinate with entities like Gitcoin, Optimism’s Collective, or Ethereum’s community funds. For example, Tea might co-sponsor Gitcoin rounds for OSS devs, paying in TEA. Conversely, if Optimism’s Citizens’ House is funding public goods, the Tea Network’s success in rewarding OSS could be seen as a model – potentially Optimism’s governance might even direct funds to Tea’s treasury to amplify OSS funding (speculative, but shows how integration could occur). Having a governance model that is open and respected can invite such collaboration.

Governance of Layer 2 Upgrades: One important aspect is how upgrades to the L2 (which might be technically executed by the team initially) become governed. Optimistic rollups generally have an upgrade mechanism often controlled by a multisig during beta, then intended to be handed to a governance contract. Tea will likely follow a path: at launch, the core team or foundation manages upgrades for security and speed, but with a clear plan to decentralize. The governance model should include:

• A timeline or milestones for decentralization: e.g., “After 6 months or after X mainnet transactions, the upgrade multisig will add community members or be replaced by the DAO entirely.”

• When the DAO takes over, an on-chain Timelock contract can be used such that any protocol upgrade (contracts on L1 or critical config in the sequencer) must be queued via a governance timelock for, say, 7 days. This gives time for the community to react if a malicious proposal somehow passed or was implemented incorrectly.

• Emergency brake: Possibly the Security Council or some quorum of core devs can delay an upgrade if it’s known to be harmful, even if the DAO passed it – but this is a contentious area and ideally avoided by thorough review during the governance process.

Leveraging OSS Community Governance Practices: Many open-source communities have governance processes (though usually informal or off-chain). Tea Network can incorporate those to make OSS folks comfortable:

• Use familiar norms like RFCs (Request for Comments) that mirror how Python or Rust communities propose changes. A TIP (Tea Improvement Proposal) could be formatted like an RFC, with rationale, backward compatibility analysis, etc., making it legible to developers.

• Encourage maintainers of top OSS projects on Tea to become delegates or hold special advisory roles. This way, decisions always consider the view of actual OSS maintainers.

Ensuring a Healthy Governance Ecosystem: Drawing from academic research on decentralized governance, a few principles are observed:

• Governance Minimization: Don’t put every trivial thing to a vote. The Optimism governance principles mention keeping on-chain governance to the minimum necessary . Tea should similarly automate what it can and only govern what humans need to decide (e.g., algorithmic distribution of rewards is not voted on each round – the formula might be set by governance and then it runs).

• Transparency and Accountability: Every governance decision should be recorded and outcomes measured. For instance, if the DAO funds a certain initiative, track its success (did it bring X new developers? Y new projects?). This can feed into retroactive rewards for governance participants if their decisions lead to positive outcomes (though this is experimental).

• Inclusive Governance: Unlike some DeFi projects where governance is dominated by a few large funds, Tea’s community includes many developers who might not be “whales.” It’s crucial to avoid plutocracy. Techniques like quadratic voting (favoring wider distribution of tokens) or adding non-financial weight (like giving active contributors a slight extra boost in voting weight via soulbound tokens) could be considered to ensure governance is not just by the rich but by the active. For example, someone who maintained a project that achieved top 10 teaRank could be given a “Reputation NFT” that confers additional voting weight in certain decisions related to OSS incentives, balancing out pure token weight. This idea aligns with governance research that suggests incorporating reputation or identity to mitigate the weaknesses of token voting.

In practice, the Tea Network governance will likely evolve iteratively. Early on, more off-chain discussion and foundation guidance; later, more on-chain formalism and community control . By learning from Ethereum’s own governance (which is off-chain but rough consensus driven) and on-chain DAOs, Tea aims to create a governance model that stands the test of time, maintaining security (no abrupt risky changes), adaptability (can upgrade as tech and needs change), and community trust.

DAO Governance Comparisons:

• The Arbitrum DAO is fully on-chain and one of the largest live DAOs, demonstrating that thousands of token holders can coordinate to govern a live L2 . It also showed some challenges (like initial controversies around how the foundation handled its first proposals). Tea’s governance will need to be extra transparent and communicative to avoid misunderstandings. Regular community calls, published minutes, and even votes on testnet (to practice) could help.

• The Optimism Collective’s approach acknowledges that purely token-based systems have pitfalls (like short-termism or governance attacks) . By having multiple incentive-aligned groups (token holders, reputation holders), they aim for more robust decisions. Tea might not replicate the Citizens’ House exactly, but the concept of multi-faceted governance is valuable.

In summary, the updated governance model for Tea Network is one where TEA token holders via a DAO hold ultimate power over protocol directions, tempered by the input of the OSS community and safeguarded by special mechanisms for emergencies. It is a decentralized, transparent system that draws on the knowledge of Ethereum’s own governance experiments and the structures of leading Layer 2s. Over time, as the network grows, this governance will ensure Tea Network remains community-driven and aligned with its mission to empower developers, thereby preventing centralization of control or deviation from the values of open-source.

Having covered governance, we next consider how the network addresses security and privacy concerns, and meets regulatory challenges, to ensure long-term viability and trust.

Security, Privacy, and Regulatory Considerations

Operating a new Layer 2 blockchain with a bespoke feature set (like Tea Network) requires careful attention to security and privacy, as well as awareness of the evolving regulatory landscape. This section discusses how the migration to Layer 2 improves security, what privacy features or implications arise (especially with GPG-based identity), and the regulatory considerations relevant to Tea Network.

Security Enhancements from the New Architecture:

• Inherited Security from Ethereum: As highlighted earlier, Tea Network benefits from Ethereum’s battle-tested security. All L2 state transitions are eventually anchored on Ethereum, meaning an attacker would need to beat Ethereum’s consensus (highly improbable) or sneak through a fraudulent state without anyone noticing (also unlikely given decentralized scrutiny) to “hack” the L2’s ledger. This is a major improvement over being a standalone sidechain or even a dApp (where a vulnerability in the contract could be fatal). In essence, Ethereum is the security backbone. The optimistic rollup design ensures that if an invalid transaction were included on Tea, it can be challenged within 7 days and removed . Thus, user funds on Tea have strong safety guarantees – they can always withdraw back to Ethereum after the challenge period, assuming at least one honest watcher exists .

• One-Honest-Validator Assumption: Unlike a normal blockchain where you might need >50% honest miners/validators, Tea’s security relies on the “one honest validator” model . This dramatically lowers the threshold for security. In practice, many parties (the Tea team, major token holders, independent observers, perhaps even Ethereum validators running verification nodes) will be monitoring Tea Network’s submissions to Ethereum. Any discrepancy would be quickly broadcast and a fraud proof submitted . This ensures the network state cannot be maliciously altered without detection. It also means users can feel confident using Tea Network with faster “soft” finality – although the challenge window is 1 week for finality, in practice fraudulent states would be reported within minutes and users would be alerted by community channels to stop trusting new L2 transactions until resolved .

• Audits and Formal Verification: The Tea Network will undergo rigorous security audits, both of the custom smart contracts (bridges, GPGWallet, registry, etc.) and of the modified Geth client (especially the GPG precompile implementation). By building on the OP Stack, Tea can also inherit the security audits and improvements from Optimism’s codebase. Optimism’s code, including the Bedrock release, has been audited and tested by the community. Additionally, key components like the fraud proof system and cross-domain messaging have been scrutinized . Tea’s custom addition – the GPG precompile – will be isolated and carefully tested (including fuzzing with various PGP inputs). The complexity of PGP parsing suggests the team must be cautious; any bug there could be an exploit vector. However, by implementing it in Go at the client level, they can use mature PGP libraries and avoid the limitations of EVM code.

• Smart Contract Security: For Tea’s on-chain contracts (like the OSS registry and staking contracts), established security patterns are followed. For instance, the staking logic might use time locks on withdrawals to prevent sudden exits, and the reward distribution might be governed by a well-tested algorithm. Where feasible, the contracts might use upgradable proxies at the start (under multi-sig control) to allow quick fixes if bugs are found, transitioning to fully immutable/governance-controlled once confidence is high. Community members skilled in security (possibly those who participate in the vulnerability bounty program) will no doubt review these as well. The bug bounty program itself is part of security: by incentivizing white-hat hackers to find vulnerabilities in the protocol and even in popular OSS packages, Tea Network creates a virtuous cycle of improving security for the ecosystem.

• Sequencer Trust and Censorship Resistance: In the initial phase with a centralized sequencer, users do have to trust the sequencer for liveness (it could theoretically stop or censor transactions). To mitigate this, the Tea Network will likely have a policy or SLA for the sequencer (e.g., run by the foundation with high uptime). If the sequencer misbehaves, users can always withdraw via L1 directly after the timeout. On the roadmap is decentralizing this sequencer, which will eliminate single-party censorship risk. Even with one sequencer, however, it cannot steal funds due to the fraud proof mechanism. The worst it can do is delay inclusion of some transactions. The Tea Network could also explore integrating with emerging decentralized sequencer networks that some projects (like Astria or Espresso) are developing, to hand off block production to a third-party decentralized layer in the future.

• MEV and Fairness: Miner Extractable Value (MEV) is a concern on any blockchain – sequencers could reorder transactions for profit. Optimism addresses this by having a private sequencer mempool . Tea can adopt the same: the sequencer does not expose a public mempool to prevent external frontrunning bots. Additionally, Tea could implement soft commitment to ordering (like using some fairness protocol or at least a first-come-first-serve policy with timestamps). As the network evolves, if multiple sequencers exist, an auction or rotation might inadvertently introduce MEV opportunities; governance could consider mechanisms like MEV smoothing or ordering constraints to ensure fairness and that MEV is captured for the community’s benefit (e.g., redirected to treasury).

• Infrastructure Security: Running an L2 also involves node security, RPC endpoints, etc. The Tea team will likely partner with infrastructure providers (Alchemy, Infura, etc.) to provide robust public RPCs for users, and encourage folks to run their own nodes. The GPG feature might require some custom RPC (to create and sign transactions in a user-friendly way), but overall, standard Ethereum clients can be pointed to Tea’s chain ID and RPC to validate the chain.

Privacy Considerations and Improvements:

• PGP-Based Identity and Privacy: At first glance, tying PGP identities to blockchain accounts could decrease anonymity. If a developer chooses to link their real-world identity (often an email or name attached to a GPG key) with their Tea Network address, they are making an intentional trade-off of privacy for reputation. Tea Network does not force this; it’s an opt-in feature. Many users may still use pseudonymous Ethereum accounts to interact. However, those who do link a GPG key might reveal personal information (like their email if someone looks up the key on public keyservers). The Tea Network should educate users: you can use a fresh GPG key (perhaps attested by others) if you want the security benefits without doxing yourself. In fact, Tea could collaborate with projects like Ethereum Name Service (ENS) or Gitcoin Passport to provide pseudo-anonymous but verified identities (e.g., an ENS name that has a proof of GitHub account control can serve similarly without exposing email).

• Privacy of Transactions: Out of the box, optimistic rollups inherit the transparent nature of Ethereum – all transactions and balances on Tea L2 are public. For many OSS use cases, this is acceptable or even desired (public transparency of contributions and funding). However, there may be scenarios where privacy is beneficial (say a company wants to support a project anonymously, or a developer doesn’t want their income known). Tea Network could explore integration with privacy solutions:

• Integrating a Layer 2 mixer contract for TEA (similar to Tornado Cash, but on L2 where fees are low, enabling even micro mixing). This would let users obscure the link between their deposit and withdrawal, if they value privacy.

• Supporting account abstraction privacy – e.g., via stealth addresses or one-time meta-transactions. If EIP-4337 style bundlers are used, a user could have the option to send a transaction through a relayer that hides their address (though the relayer would see it). Research in this area (like Umbra protocol for stealth payments) could be brought into Tea’s AA wallets.

• Zero-knowledge proofs: In the future, Tea might incorporate ZK-proof features for certain data. For example, a contributor could prove off-chain that they made a certain number of contributions (using a ZK proof from Git commits or so) and get a reward without revealing which exact commits were theirs. While speculative, this could allow recognition of work while preserving pseudonymity. The Tea Network’s modular nature (especially if it ever explores zk-rollup or hybrid models) could facilitate such advanced privacy-preserving reward mechanisms.

• GPG Encryption: GPG isn’t just about signatures; it’s about encryption too. An intriguing possibility: the Tea Network could allow storing encrypted data on-chain that only a certain key can decrypt. For instance, a vulnerability report could be posted encrypted with the maintainer’s public key, so only they can read it (ensuring responsible disclosure). The precompile currently is for verification, not decryption (and decryption on-chain would be impractical, even with private keys, which remain in the custody of the key holder), but enabling a workflow of publishing encrypted data with on-chain pointers could be part of the DApp design (with off-chain tools). This uses PGP for confidentiality in conjunction with the blockchain for integrity and timestamping.

• Personal Data and Compliance: The Tea Network largely deals with public code and pseudonymous identities, so it sidesteps many personal data issues (like GDPR) that a social network might face. However, if real identities are linked (e.g., an email in a GPG cert), one could argue that it becomes personal data. The Tea Network should likely advise users not to publish unnecessary personal info on-chain. In terms of privacy improvements, one could say Tea improves privacy relative to traditional funding models – OSS devs currently often rely on Patreon or GitHub Sponsors, where their earnings are known to those platforms and possibly governments. On Tea, a maintainer could receive funds to a pseudo-anonymous address with only a known alias. This is a double-edged sword: it gives maintainers financial privacy and autonomy, but also raises regulatory eyebrows perhaps (if large sums flow without KYC).

Regulatory and Compliance Challenges:

Blockchain projects must navigate a complex regulatory environment:

• Token Classification: The TEA token powers the network and is used for governance and utility. There is a risk regulators could view it as a security, especially in jurisdictions like the US, if it’s sold to raise funds or promises profit from others’ efforts. The team likely positioned TEA with a strong utility narrative (needed for gas, staking for network usage) to argue it is not an investment contract but a consumptive token. The governance decentralization also supports the case that it’s more like a governance token (which some regulators may still consider in security territory, but at least it’s decentralized). Tea’s focus on rewarding work (Proof of Contribution) also frames TEA as a work reward/token, somewhat analogous to mining rewards, which historically were less scrutinized than ICO tokens.

• Compliance (AML/KYC): As a permissionless network, Tea cannot KYC every user or force AML checks on P2P transactions. However, if the foundation or company behind Tea works with enterprise or government funding, they may need to consider compliance solutions. For example, an enterprise using Tea treasury might want to ensure funds don’t go to sanctioned individuals. This could be handled off-chain (they choose which project to fund, presumably not one in a sanctioned region) or through analytics (monitoring addresses). The Tea Network could integrate with on-chain compliance services or encourage maintainers to identify themselves (optionally) if they want to attract corporate sponsors who need to report where money went.

• IP and Content Regulations: The Tea Network’s on-chain registry might include links to software or metadata. There is a chance that someone could upload illegal content pointers (though actual code binaries likely stay off-chain). Governance and possibly automated filters would need to handle this (e.g., if someone registers a project on Tea that is actually malware or illegal, the community might vote to delist it and maybe slash the submitter). Being on a blockchain, content can’t be easily removed, but pointers or flags can be managed.

• Operating a Layer 2: There might be legal questions about the entity running the sequencer. For instance, could a sequencer be seen as a money transmitter or operating a payment system? Generally, validators/sequencers in a decentralized network haven’t been classed as money transmitters because they do not take custody of user funds (they just order transactions). In Tea’s case, initially the foundation runs the sequencer, but funds are locked in smart contracts; the sequencer cannot misappropriate them due to the fraud proofs. Still, the foundation might seek legal advice to be sure operating the L2 is not considered a custodial activity. Over time, decentralizing this role also spreads out any regulatory risk.

• Open-Source Software Legalities: One regulatory aspect aligned with Tea’s purpose is ensuring compliance with open-source licenses. Tea’s protocol possibly could be used to track licenses (e.g., you could imagine an enhancement where the registry notes a project’s license and if it’s copyleft, ensure that derivatives also register or something). While not a direct legal compliance issue, it’s a space where Tea might provide tooling (maybe an idea: a smart contract that can escrow funds until license compliance is verified? Probably outside scope, but interesting for future).

• Taxation: Contributors earning TEA might wonder about tax implications. In many jurisdictions, getting tokens as reward is income (taxable). Tea Network could, as part of its off-chain services, provide users with data on their earnings to help with reporting. Perhaps a simple integration that shows fiat values at time of reward. While the network can’t handle taxes, being mindful of user needs (like documentation) improves compliance and user trust.

Security and Compliance Balance: There is sometimes tension between privacy and compliance. Tea’s approach likely will be to maximize user privacy and autonomy (since developers may value that) but also provide options or features that allow voluntary compliance. For example, a project maintainer who wants to be transparent for funding purposes can verify their identity and perhaps get a badge “KYCed” or “Verified” that corporate donors might require. This could be done via a third-party (like OpenZeppelin’s Stamp or Gitcoin Passport) that issues an attestation on-chain about an identity. This way, those who need regulatory reassurance have it, while others can remain pseudonymous.

Additionally, by distributing decision-making via the DAO, Tea reduces centralized liability – it’s the community that governs, not an identified company making all decisions, which in theory decentralizes regulatory targets. However, the initial team will still be influential and likely a steward in early days, so they will comply with laws in jurisdictions they operate (e.g., if the foundation is in a certain country, they might geoblock sanctioned countries on their front-end, even though the protocol itself is accessible – a common compromise many projects do).

In terms of security assurances to users, Tea Network will publish a comprehensive security model (likely in this white paper or docs), which we’ve covered:

• Emphasize that users always retain the ability to withdraw to L1 (though with a delay) – so they should feel safer putting value into Tea.

• Recommend best practices like waiting for a block to be submitted to L1 before considering a large transaction final, if in doubt.

• Possibly provide a tool or dashboard to monitor the status of L1 submissions and the challenge window countdown for peace of mind on large withdrawals.

The Tea Network can also engage third-party monitors (like independent orgs or hackerspaces) to audit in real-time. For instance, Trust, but verify: an independent service could run a full Tea node and tweet an alert if an invalid state is detected. Over time, as more users run nodes, this becomes decentralized.

Summing up Security & Privacy: The Layer 2 architecture significantly strengthens security by leveraging Ethereum and by enabling new cryptographic authentication (GPG). The Tea Network’s design acknowledges that security is not just about code – it’s about processes (governance to respond to issues), incentives (bug bounties), and user empowerment (giving tools to manage their keys safely, e.g., contract wallets with social recovery perhaps). Privacy is improved in some senses (financial sovereignty for devs) but introduces new considerations (linking real identities). Tea provides optionality so users can choose their comfort level.

By addressing regulatory considerations proactively (decentralizing control, emphasizing the network’s public-good nature, and perhaps engaging with regulators through industry bodies), Tea Network aims to operate in compliance without sacrificing the permissionless nature that makes it valuable. This careful balance of security, privacy, and compliance will help ensure the Tea Network can grow widely and be seen as a legitimate, trustworthy backbone for the open-source ecosystem.

Performance, Scalability, and Trade-offs

In transitioning to an OP Stack-based Layer 2, the Tea Network achieves significant gains in performance and scalability. However, these come with certain trade-offs and design decisions. In this section, we detail the expected performance improvements (with any available benchmarks), the scaling characteristics of the Tea Network, and the trade-offs made between scalability, security, and decentralization.

Performance Benchmarks and Improvements:

• Transactions Per Second (TPS): While exact TPS will depend on the complexity of transactions (gas used) and the hardware the sequencer runs, we can estimate based on Optimism’s benchmarks. Optimism and Arbitrum can handle on the order of hundreds of transactions per second under ideal conditions, compared to Ethereum’s ~15 TPS limit . For Tea Network, many transactions will be relatively light (stakes, votes, simple transfers), so the TPS could be quite high. A realistic number might be 200–500 TPS of typical Tea interactions, which is a massive improvement over the dApp where everything was bottlenecked by L1 throughput.

• Latency: Block time on Tea Network is configurable; Optimism’s is currently around 2 seconds. Tea could similarly target 2–4 second block times. This means that from the user’s perspective, an action like staking TEA to a project or claiming a reward would finalize on L2 within a few seconds, as opposed to waiting 12-15 seconds (one Ethereum block) or longer if congested. Faster confirmation improves user experience dramatically – it feels more like using a Web2 application.

• Cost per Transaction: One of the most tangible improvements. On Ethereum mainnet, complex interactions (like multi-step staking) could cost dollars in gas. On Tea L2, the cost is a small fraction of that. For example, Optimism reports that its fees are typically 1/50th to 1/100th of L1 for simple transactions. Tea’s transactions, posted as calldata or blobs, benefit from those same savings . If Ethereum later enables data sharding, the costs drop even more. This means a user might pay, say, $0.05 in TEA for an operation that on L1 cost $5. Lower costs not only make existing operations cheaper but also enable new things (micro-distributions of rewards, continuous updates) that were infeasible when every on-chain update had a high price.

• Throughput under load: The Tea Network can process bursts of activity without the spiky gas price behavior of Ethereum L1. For instance, if a very popular OSS project suddenly gets a huge token stake from thousands of supporters (say after a big announcement), the flurry of transactions will be handled in batches on L2. Users might see slightly slower inclusion if it exceeds immediate throughput, but the sequencer can include them in subsequent blocks rapidly. The gas price on L2 might increase if the sequencer is congested, but since the block space is much larger, this should be a gentler effect. Additionally, the sequencer can adjust block size (within constraints of what’s efficient to post to L1) to accommodate more transactions in one batch if needed. There is a cost trade-off (bigger batches cost more on L1), but if many users are sharing that cost, it remains economical.

• Benchmark Comparison: We can refer to known stats: Arbitrum One, for example, has achieved over 2 million transactions in a day at peak , which averages ~23 TPS sustained, but it wasn’t near its technical limit. Base (Coinbase’s L2) reportedly hit over 4 million daily transactions at one point , surpassing both Ethereum and other L2s. These numbers suggest that OP Stack chains can handle surges and large daily volumes. Tea Network aims for similar or better performance. If Tea were to handle all npm downloads as on-chain events (just a hypothetical huge load), it would likely need further scaling (L3s or sharding), but for now it can handle the foreseeable scale of direct user interactions in OSS funding, which are likely thousands to tens of thousands of transactions per day in early growth, scaling to maybe hundreds of thousands with widespread adoption – well within OP Stack capacity.

• State Growth and Storage: With many transactions, the state (accounts, contracts, storage) will grow. Tea must manage this to keep nodes runnable. Luckily, Optimism’s design and Ethereum’s upcoming improvements (like Verkle trees) are focusing on state efficiency. Since Tea deals with lots of small accounts (many users staking, many projects), the state could grow in number of accounts. However, storage per account is small (balance, maybe a few records of stakes). Regular state rent or pruning might not be needed early, but this is something to monitor. If needed, Tea governance could implement measures like inactivity cleanup (e.g., if a project is unmaintained and has zero stake for a year, archive its state to a cheaper storage). These are long-term considerations to keep performance optimal.

Scalability Path:

• Layer 2 and Beyond (Layer 3?): If Tea Network becomes extremely popular, one can imagine deploying Layer 3 instances for certain purposes. Optimism’s vision of a Superchain and even “Hyperchains” suggests that one rollup can sit atop another for specific use cases. Tea could spawn a L3 specifically for handling, say, continuous integration data or large-scale testing logs, while settling summaries to Tea L2. This is speculative, but the OP Stack’s modular nature could allow Tea to be both a rollup and a host for smaller rollups. For now, Tea L2 is sufficient, but it’s good to know the architecture can scale out if needed without overwhelming a single chain’s capacity.

• Horizontal Scaling via Superchain: When the Superchain matures, Tea Network might interoperate with other chains such that load can be balanced or shared. For example, if some part of Tea’s functionality (like a DeFi app for TEA tokens) works better on another chain, cross-chain calls can happen. Or multiple sequencers in a Superchain alliance could share sequencing duty across chains. This is forward-looking, but essentially, Tea’s scalability is not capped by its own chain – it’s part of an ecosystem that is scaling collectively.

• EIP-4844 and Data Scaling: We’ve mentioned EIP-4844 (Proto-Danksharding). Once that is live on Ethereum (expected 2024), Tea Network will move from posting L2 data as call data to posting in ephemeral blobs. This will cut fees by an order of magnitude for L2 data and increase throughput (because Ethereum will accept more blob data per block than it would call data). This directly boosts Tea’s capacity to scale user activity without higher costs. It’s basically a scaling bonus that Tea gets by virtue of being an L2 and staying up-to-date with Ethereum improvements .

Trade-offs:

No system is without trade-offs. Key trade-offs in Tea’s design include:

• Decentralization vs. Performance: Initially, Tea opts for performance (single sequencer, centralized control) to deliver a smooth user experience. The trade-off is some centralization: users have to trust the sequencer not to censor and the team to not push bad upgrades. However, this is mitigated by the security model (they can’t steal funds) and is slated to be temporary until governance and possibly multiple sequencers take over. This is a conscious trade: a fully decentralized L2 from day one could be slower to adapt and harder to coordinate. By starting with a semi-centralized model, Tea can iterate quickly and ensure the system runs well, then gradually remove trust assumptions. This is the same approach Optimism and Arbitrum took (both began centralized and are decentralizing over time).

• Optimistic Rollup Assumption (vs. ZK Rollup): Tea chose to use an optimistic rollup (fraud proofs) rather than a zero-knowledge rollup (validity proofs). The trade-off here is finality time vs. compatibility. Optimistic rollups like Tea’s are fully EVM-compatible and can leverage Ethereum’s existing tools easily, but they have the 7-day withdrawal period for security . ZK rollups have near-instant finality (no challenge period needed if proofs are valid) and potentially even better throughput, but EVM-compatible ZK rollups are still emerging and are more complex. Tea’s choice means that users withdrawing assets must wait or use liquidity providers to fast-exit (likely some third-party service can offer instant liquidity against a fee for those who can’t wait). It also means the protocol deals with the slight risk and inconvenience of fraud challenges. The benefit is that Tea could launch sooner and with full Ethereum compatibility. In the future, should ZK tech mature, Tea could consider migrating or incorporating ZK proofs (maybe to verify parts of the state like the correctness of reward calculations). But that’s a big undertaking; for now, optimistic was the pragmatic choice.

• Data Availability vs. Cost: Tea, like all rollups, currently posts all transaction data to Ethereum for availability. This ensures the strong security but comes at a cost (L1 gas fees for that data). There’s a trade-off possibility: Validium or Alt-DA – not chosen here, but to note, some L2s consider not posting all data on-chain to save cost, at the expense of requiring trust for availability. Tea has not chosen that; it stays a true rollup with data on-chain (especially since trusting a third-party for data would undermine the trustless OSS reward principle). So Tea pays higher cost for better security. With Ethereum scaling (like data shards), this trade-off will become easier as data on-chain gets cheaper.

• State Size vs. History Accessibility: To keep performance high for node runners, Tea might not indefinitely keep every historical transaction accessible in a fully synced node (similar to how Ethereum clients prune history or how Arbitrum compresses it). The full data is always in Ethereum logs, but an L2 node might prune older blocks. This trade-off between node efficiency and history can be managed by relying on services (like The Graph or archive nodes) for those who need history, while standard nodes keep state small for fast syncing. The OP Stack already supports different modes (full vs. archive). This is a minor trade-off, but relevant for developers: if you query a Tea node for a 2-year-old event, it might require an archive node or reconstruct from L1.

• Complexity of Novel Features: The GPG precompile and account abstraction add complexity not present in a vanilla rollup. This is a trade-off: more functionality vs. potential new attack surface or performance overhead. For instance, verifying a GPG signature is more expensive in CPU terms than an ECDSA signature (which is baked into Ethereum already). If overused, could the GPG precompile slow block processing? The team likely benchmarked this; modern CPUs can verify many RSA or Ed25519 signatures per second, so unless every transaction uses a huge key, it should be fine. The trade-off was deemed worth it to get the identity functionality. But the team will monitor performance – if, say, GPG verification becomes a bottleneck, they might restrict how often it can be called in one block (like a gas cost tuning) or encourage batching of operations. It’s a conscious trade: adding that feature gives up some simplicity and raw speed, but provides a feature critical to Tea’s goals.

• Economic Trade-offs: On tokenomics side, there’s a security trade-off: using TEA as gas vs. ETH as gas. Most L2s like Optimism/Arbitrum use ETH, meaning if ETH’s price is stable, security is inherited directly by economic value. Tea uses TEA for gas, which could be more volatile and initially less valuable than ETH. If TEA were ever to become too cheap, spamming the network might be easier (though there are still capacity limits). The team will calibrate gas price (which can be pegged in terms of TEA vs. cost to post on L1) to prevent that. Also, by requiring fees to be at least the L1 cost share, it inherently can’t be cheaper to spam than the cost on Ethereum. So, the trade-off of using the project’s own token for gas is gaining token utility but losing the direct link to ETH’s security budget. This is mitigated as described and by the fact that TEA will presumably correlate with network usage – if usage (and thus potential spam) rises, demand for TEA rises, possibly increasing its price and making spam expensive in fiat terms.

Summary of Improvements vs Original Implementation:

• Throughput: from tens of tx/day (dApp limited by user willingness to pay fees) to potentially millions of tx/day.

• User Cost: from dollars per interaction to cents or less.

• Speed: from minutes (if waiting multiple block confirmations on L1) to seconds on L2.

• Development Agility: from being constrained by Ethereum upgrades to being able to implement custom features (like GPG, new EIPs) on Tea’s own schedule.

• Scaling Ceiling: previously bounded by Ethereum’s throughput, now bounded by a much higher threshold, and extensible via L3 or cross-chain if needed.

Trade-offs Recap (Performance vs Security/Decentralization):

Tea Network carefully balances these:

• It accepts the 7-day finality lag to get EVM compatibility (optimistic rollup).

• It temporarily accepts centralization to get a workable network quickly, planning to remove that centralization in stages.

• It adds new features at the cost of complexity, but ones that align with its mission (account abstraction with GPG).

• It relies on Ethereum for ultimate security, meaning it cannot go beyond Ethereum’s base layer limits in some aspects (e.g., if Ethereum is congested, posting batches might get delayed or costlier; but Ethereum upgrades will alleviate that).

Users and developers should be aware of these trade-offs. For most, the benefits (vastly lower fees, faster UX) will far outweigh the downsides (waiting a week to withdraw, which can be handled via third-party bridges if urgent, or slight centralization in beta). The design choices were made to ensure the Tea Network can scale to support a global community of developers and millions of micro-transactions, all while maintaining the integrity and security that users expect from an Ethereum-aligned chain.

Conclusion and Strategic Vision

The evolution of the Tea Network from a dApp to an OP Stack-based Layer 2 marks a pivotal step toward fulfilling the project’s mission: to create a sustainable, incentive-aligned ecosystem for open-source software development. In this concluding section, we summarize the key improvements introduced by the Layer 2 transition, outline the long-term vision for the Tea Network, and present a roadmap for future development and expansion.

Key Improvements of Transitioning to Layer 2:

• Scalability & Cost Efficiency: By moving to an Ethereum rollup, Tea Network achieves scalability on par with leading L2s, enabling high-volume usage at minimal cost. This directly addresses the pain points developers faced using the L1 dApp (high fees, limited throughput). Now, casual users can engage with the protocol (vote, tip, stake) without economic second thoughts, and large communities can use Tea for everyday coordination. The improved cost efficiency means more of the value stays with developers rather than being burned in fees, aligning with Tea’s goal to maximize rewards to OSS contributors .

• Enhanced Security Model: The new architecture leverages Ethereum’s security guarantees and introduces cryptographic identity verification (GPG precompile) that was not possible in the original implementation. Security is now multi-layered – Ethereum secures the ledger, and PGP keys secure individual user actions, greatly reducing the risk of malicious activity either at the network level or user account level. The one-honest-validator security model provides strong assurances even under adverse conditions .

• Richer Functionality (Account Abstraction): The integration of EIP-7702 concepts and account abstraction mechanisms mean the Tea Network can offer a modern user experience and flexible account management. The GPGWallet and the ability for EOAs to act like smart contract accounts for a transaction set Tea apart as a network innovating at the identity and UX layer. This will likely attract developers who want to build novel solutions (like custom login flows or multi-sig setups) on Tea, knowing the platform supports those natively.

• Ecosystem Growth Potential: Running as an independent network gives Tea the freedom to nurture its own ecosystem of dApps and integrations. While the original tea Protocol was just one application, Tea Network can host many complementary applications—funding platforms, DAO governance tools, analytics dashboards for package health, marketplaces for services, etc. The migration thus transforms Tea from a single protocol into a platform for OSS-centric web3 activity. Comparisons can be drawn to how Base or Optimism are now home to many projects; we anticipate Tea Network will become the chain of choice for open-source communities, with network effects taking hold as more projects and users join.

Long-Term Vision:

Looking ahead, the Tea Network aims to become the definitive blockchain hub for open-source software value exchange and reputation. In this vision:

• Every meaningful open-source project, from a popular JavaScript library to a critical C library, would be registered on Tea Network, accruing a reputation score and financial support appropriate to its adoption through the protocol. The Tea Network would act as a global ledger of open-source contributions, where developers’ work is immutably recorded and rewarded. This could evolve into a new kind of professional profile for developers – a decentralized, verified record of one’s impact on software.

• Tea Network’s governance will be largely in the hands of the community of developers and users, functioning as a digital cooperative or commons. Over time, as the network decentralizes, we envision a scenario where major decisions are made through broad consensus, and the network can even upgrade itself (through on-chain governance) to adapt to future needs of OSS or technology changes. This self-governing aspect ensures longevity; Tea can outlive its founders and become an institution of the open-source world, somewhat analogous to how Linux Foundation stewards Linux, but in a decentralized manner.

• Integration with Web2 and Web3 ecosystems: The Tea Network will strive to blur the line between Web2 package ecosystems and Web3. For example, imagine package managers like npm or pip showing, in real-time, data from Tea: “this package is ranked #5 on Tea, has X TEA staked, last security audit 2 weeks ago, etc.” Moreover, web3 projects might preferentially use libraries that are Tea-verified for security (creating a sort of quality seal). Conversely, Tea might leverage web3 identity solutions (like SIWE – Sign-in with Ethereum, or Gitcoin Passport badges) to enrich its identity and trust system. The vision is an integrated loop: Web2 devs get introduced to web3 via Tea (to collect their rewards or stake on projects), and Web3 users get assurance about software via Tea’s data.

• Global and Inclusive Participation: The Tea Network aims to be globally accessible. Many talented developers around the world contribute to OSS but have trouble getting financial support due to geographical or political barriers. Because Tea uses cryptocurrency and is decentralized, it can enable a global flow of value to contributors regardless of location. The long-term vision includes making the protocol easy to use even in regions with limited internet or hostile financial systems. Perhaps mobile-friendly light clients, multi-language support in interfaces, and educational efforts (teaching devs about crypto wallets, etc.) will be part of the journey to truly democratize open-source funding.

• Catalyst for Open-Source Sustainability: If successful, the Tea Network could significantly change how open-source is funded. Instead of relying on donations or big companies’ benevolence, it creates a market-like mechanism where usage and dependency translate into tangible rewards . In the long run, this could encourage more people to work on open-source (knowing there’s an automated way to get rewarded) and improve software supply chain security (since well-maintained projects are incentivized). It aligns profit motive with community benefit in a novel way. The vision includes academic and industry recognition of Tea’s model, perhaps inspiring similar models in other creative domains (imagine something like Tea for scientific research or for open data – Tea itself may not do that, but it could be a template).

Future Roadmap:

While exact timelines are subject to change, the development roadmap for Tea Network likely includes:

• Mainnet Launch of Tea L2 (Phase 1): Following the incentivized testnets (Base ITN, Assam, Sepolia), the next step is the official mainnet launch of the Tea Network L2 (often code-named after another tea variety, perhaps). This includes deploying the bridge on Ethereum mainnet, launching the sequencer, and allowing users to bridge in their TEA tokens from Ethereum. In this phase, the core tea Protocol features (project registration, staking, rewards distribution) go live on L2.

• Audit and Security Refinement: Early mainnet months will be closely observed. Bug bounty programs will continue to run. The team might impose conservative limits (like rate limits or lower cap on how much can be staked per project initially) as a safety measure, raising them as confidence grows.

• Feature Completion (Phase 2): Some features might roll out shortly after mainnet:

• The GPGWallet might be released after initial mainnet if it wasn’t ready on day 1 (ensuring wallets and tooling support it). Developer tools for using GPG keys (browser plugins or CLI tools) will be delivered so that it’s not just a backend feature but something devs actively use.

• Account abstraction via ERC-4337 (UserOps) – if the team chooses to incorporate this – could be deployed to allow gassless meta transactions or smart contract wallets beyond GPGWallet. EIP-4337 compatibility would align Tea with broader Ethereum improvements in user experience.

• Integration of EIP-4844 once Ethereum enables it (this could be a huge update for fee reduction).

• Launch of Tea Explorer and Analytics – a custom block explorer highlighting not just raw transactions but protocol-level info (like showing project pages, ranks, etc.) would be on the roadmap to make the data accessible.

• Ecosystem Development (Phase 3): Encourage third-party development on Tea:

• Grants or hackathons to build things like: a decentralized front-end for browsing projects, analytical dashboards (which projects are growing fastest, etc.), cross-chain bridges specifically for TEA to various L2s or sidechains, integration plugins for GitHub or GitLab (e.g., a bot that comments on a pull request with a link to tip the contributor on Tea Network).

• Work with major package managers to integrate Tea. For example, getting a mention or a badge on npm package pages linking to Tea Network data. This might require plugins or a bit of central cooperation, but even a browser extension could overlay Tea data on such pages as a start.

• Possibly partner with existing funding platforms (OpenCollective, GitHub Sponsors) to see if they can use Tea as the backend or complementary platform (e.g., OpenCollective could mirror contributions on Tea or payout via TEA).

• Decentralization & Governance (Phase 4): As the network stabilizes, focus on handing over control:

• Set up the on-chain governance contracts, start holding votes on significant parameters or treasury allocations. This also includes launching the TEA token airdrop/distribution widely if not already (to ensure broad community ownership).

• Gradually decentralize the sequencer: either by opening it up to whitelisted community-run sequencers or adopting a protocol for multiple sequencers. Possibly implement the fault prover mechanism for anyone to submit fraud proofs permissionlessly (initially it might have been limited to whitelisted addresses to avoid spam proofs; later open it fully as Arbitrum has done, albeit Arbitrum still has a whitelist currently ).

• Expand the Security Council or similar multi-sig to include elected community members (if early on it was just core team members).

• Interoperability (Phase 5): Once part of the Optimism Superchain (if Tea opts into that ecosystem formally), work on interoperability:

• Enable shared sequencing or fast message passing between Tea and other OP Stack chains. For instance, allow a smart contract on Optimism or Base to directly query Tea for a project’s teaRank. This could lead to cross-chain applications (like a DeFi protocol on Optimism giving better terms to projects with high teaRank by reading from Tea).

• Potentially explore a ZK-proof-of-contribution: This is speculative, but as ZK tech improves, Tea might implement zk-SNARKs to prove some statements (like proving a user has a certain reputation without revealing who they are). This would be cutting-edge and not necessary for functionality, but could enhance privacy and even allow interesting use cases like anonymous contributors still getting fair rewards (by proving work done without identity).

• Global Outreach and Adoption (Phase 6): Non-technical but crucial: drive adoption in the global OSS community. This might involve:

• Working with open-source foundations (Apache, Eclipse, etc.) to onboard their projects to Tea.

• Outreach in emerging markets where devs could significantly benefit from earning in TEA.

• Ensuring legal and accounting frameworks exist for organizations to interact with Tea (like companies writing off TEA donations as expenses).

• Possibly integration with academia (imagine university open-source projects using Tea for students to get token rewards – bridging educational incentives with real-world ones).

To conclude, the transition to a Layer 2 has positioned the Tea Network as a scalable, secure, and feature-rich infrastructure ready to support a new paradigm for open-source development. It combines the strengths of Ethereum’s Layer 2 innovations (like Optimism’s OP Stack, EIP-4844, account abstraction) with a clear focus on solving real problems in the OSS world (developer incentives and software supply chain security). The white paper has outlined how each component – from the GPG address precompile to the tokenomics – serves the overarching goals of the network.

The journey ahead will involve executing on the vision, onboarding a vibrant community, and continuously improving the technology in tandem with Ethereum’s evolution. With the solid foundation laid out in this document, the Tea Network aspires to become the definitive reference and platform where open-source code meets open finance. Just as the introduction of Git revolutionized collaboration in code, we anticipate that the Tea Network can revolutionize collaboration in value – ensuring that those who create the tools powering the digital world are fairly recognized and rewarded.

References and Comparative Implementations: Throughout this paper, we have referenced the designs of major Layer 2 networks like Optimism, Arbitrum, and Base, which provided valuable insights into scalability and governance best practices. We have cited relevant Ethereum Improvement Proposals (such as EIP-7702 for account abstraction ) and research on rollup security models to justify our architectural choices. These references underline that Tea Network is built on the cutting edge of blockchain technology, while also tailoring it in innovative ways for the open-source domain. The appended citations serve as a resource for those who wish to delve deeper into the technical or academic background of our design decisions.

In closing, the Tea Network’s transition to Layer 2 is not an end but the beginning of a new chapter. Armed with an authoritative architecture and a passionate community of developers, it is poised to scale new heights. The success of this endeavor could mean a future where open-source developers around the globe can sustainably build and maintain the software that everyone relies on, powered by a decentralized network that truly values their contributions.

Tea Network Whitepaper (Expanded)

Technical Architecture – OP Stack Implementation

Tea Network’s protocol is deployed on an Optimism Stack (OP Stack) based Layer-2 blockchain. This architecture leverages Ethereum (Layer-1) for security and uses an Optimistic Rollup chain for Tea’s core operations. By building on the OP Stack, Tea gains high throughput and low-cost transactions while inheriting Ethereum’s security guarantees . In practice, the Tea Network functions as an application-specific rollup chain: Tea’s decentralized registry, staking mechanisms, and reward contracts run on a dedicated OP Stack chain, with state checkpoints and fraud proofs anchored to Ethereum. This design aligns Tea with the Optimism Superchain vision, where multiple L2 chains share a common development stack and interoperability standards .

In Tea’s OP Stack architecture, the Execution Layer (an EVM-equivalent client) processes Tea transactions and smart contracts (project registrations, treasuries, staking, etc.), while the Consensus Layer (the rollup client) orders transactions and submits batched proofs to Ethereum. A set of privileged L2 roles – notably a Sequencer, Batcher, and Proposer – initially operated by the Tea network maintainers, manage block production and state submission to L1 . Over time, these roles will decentralize to community-run nodes to increase trustlessness. User interactions (like project staking or bounty payouts) occur on the Tea L2 chain with near-instant finality, and periodic state roots are posted to Ethereum for security. If an invalid state is detected, the Optimistic Rollup fraud-proof system allows challengers to dispute it, ensuring Tea’s L2 remains honest.

Bridge mechanisms connect Tea’s L2 with Ethereum and other chains. An L1–L2 Token Bridge enables TEA tokens and other assets to move between Ethereum mainnet and the Tea network. This means participants can stake on Tea’s chain or receive rewards there, and later withdraw assets back to Ethereum via the standard Optimistic bridging process (with a challenge period for security). The OP Stack’s modular design also makes Tea’s chain inherently interoperable with other OP-based chains. As a result, Tea Network can eventually become part of the wider Optimism Superchain, allowing seamless interactions and shared liquidity with other Layer-2 networks. This interoperability and reliance on battle-tested Ethereum tech ensure the Tea Protocol’s infrastructure is robust and future-proof.

Overall, using an OP Stack L2 gives Tea Network a reliable, Ethereum-aligned foundation. It preserves an immutable ledger of open-source contributions and rewards, with Ethereum finality, while enabling the custom logic (like Proof of Contribution and Tea-specific governance) to run efficiently at Layer-2. The architecture can evolve as Optimism’s stack matures – for instance, integrating upgrades like fault proofs or off-chain data availability – without compromising compatibility. In summary, Tea’s OP Stack implementation provides the scalability, security, and composability required to support a global ecosystem of open-source developers and their tokenized communities on the Tea Network.

Application Layer – Brew.fun Launchpad for Open-Source Projects

Brew.fun is Tea Network’s decentralized launchpad platform designed to help open-source projects create and distribute their own tokens, using the reputational metric teaRank as a gatekeeper. In the Tea protocol, each registered project is assigned a dynamic score called teaRank based on its contribution to the open-source ecosystem. Brew.fun leverages this by allowing only repositories with sufficiently high teaRank (i.e. well-regarded, impactful projects) to conduct token launches on the platform. This eligibility criterion ensures that the launchpad hosts verified open-source projects with proven value, aligning tokenization with genuine software merit.

On Brew.fun, a project’s token launch follows a bonding curve mechanism to determine token price and distribution. During the launch phase, supporters can purchase the project’s tokens directly through a smart contract that implements a bonding curve. As more tokens are bought, the price automatically increases along the curve, preventing sudden large purchases from unfairly seizing supply. This approach creates a fair price discovery process and continuous token liquidity, as the bonding curve contract itself acts as an automated market maker . The launch concludes once a predefined point on the bonding curve is reached – for example, when a target raise amount or token supply threshold is met. At that moment, the bonding curve sale is considered complete (the project has “reached its bonding curve” target).

Figure: A simple linear bonding curve example – token price increases as supply is bought. Brew.fun utilizes bonding curve mechanics to ensure fair token distribution and liquidity from the moment of launch .

Reaching the bonding curve target triggers Brew.fun’s automatic liquidity provisioning for the new token. Brew.fun is integrated with Velocitea, Tea Network’s on-chain exchange powered by Velodrome’s technology. Velodrome Finance is a next-generation AMM (automated market maker) known as the central liquidity hub of the Optimism network . Using a customized instance (nicknamed “Velocitea”), Brew.fun takes the funds raised and the remaining token supply and creates liquidity pools on the exchange immediately when the sale ends. In practice, Brew.fun contributes a portion of the raise (often in TEA or ETH stablecoins) and an equivalent value of the project’s new tokens into a liquidity pool on Velocitea. This automatic LP provisioning means that from day one, the project’s token has a market with deep initial liquidity, allowing supporters to trade the token with minimal slippage.

By acting as an on-chain market maker for supported projects, Brew.fun ensures a stable launch for community value tokens. Projects don’t need to worry about arranging exchange listings or liquidity – Brew.fun’s protocol smartly handles it, mitigating volatility and guarding against the extreme price swings often seen in new token launches. Brew.fun, through Velocitea (built on Velodrome’s proven AMM model), continuously supports the market for the token post-launch, facilitating healthy price discovery and trading activity. The new project token can also benefit from Velodrome’s liquidity incentive model (veVELO gauges), potentially attracting more liquidity providers over time.

The vision for Brew.fun is to onboard both well-known and emerging open-source projects – as long as they have high teaRank and a committed community – and assist them in building sustainable token economies. “Sustainable” in this context means that the token isn’t merely a speculative asset, but is integrated into the project’s growth (for example, used for governance or to reward contributors). Brew.fun provides tooling for project maintainers to design their tokenomics (such as setting aside a portion of tokens for future contributor rewards or treasury) and to equip their supporters. This includes features like vesting schedules for team tokens, community airdrops via the Tea protocol, and integration with Tea’s package registry (linking token holder governance with the project’s open-source package governance).

By prominently positioning Brew.fun in the Application Layer of the Tea ecosystem, the Tea Network expands beyond core protocol rewards into the realm of community-driven tokenization. Brew.fun serves as a bridge between the reputation earned via Tea’s Proof of Contribution and real economic opportunities for projects: once a maintainer has proven their project’s value (high teaRank), they can leverage Brew.fun to rally community funding and involvement through a token launch. This synergy ensures that financial value flows to projects that truly contribute to open-source, aligning incentives across developers, contributors, and users. Brew.fun’s launchpad ultimately strengthens the Tea Network by bringing in new participants, fostering project communities around tokens, and demonstrating a tangible pathway for open-source maintainers to be rewarded and supported by their user base.

GitHub Integration – Bountea Bounties and GPG Wallets

The Tea Network’s reward mechanisms extend into developer workflows via Bountea, a GitHub add-on that integrates Tea wallets for frictionless bounty payouts on code contributions. Bountea is designed to fund open-source development tasks (issues, bug fixes, feature implementations) by linking GitHub’s issue tracking with Tea’s value transfer capabilities. It provides a streamlined workflow for bounties: anyone can attach a TEA token reward to a GitHub issue or pull request, and when a developer resolves the task, the reward is automatically distributed through the Tea Network.

How Bountea Works: Open-source projects first register for the Bountea program by installing the Tea GitHub add-on in their repository and configuring a Tea payout address (which can be the project’s Tea treasury or maintainer’s wallet). Once enabled, project maintainers or community members can create bounties on any GitHub Issue by specifying an amount of TEA (or a project-specific token launched via Brew.fun) as a reward. This bounty offer is recorded on-chain or in a linked off-chain service escrowed by the Tea Network. Contributors discover these bounties while browsing issues – Bountea marks eligible issues with a badge indicating the reward.

A developer who wants to claim the bounty will work on the issue and submit a Pull Request with the fix or feature. Crucially, Bountea uses GPG signature verification on commits to link contributors to their wallet identities. When the developer commits code, they sign their commits using their GPG key, which GitHub marks as a verified signature . The Tea GitHub add-on maps this GPG public key to the contributor’s Tea wallet (Bountea provides developers a tool to generate a Tea wallet linked to their GPG key – essentially a smart contract wallet controlled by that GPG identity ). This means that the act of signing the commit with GPG not only verifies authorship but also proves control of a corresponding Tea wallet.

Once the Pull Request is reviewed and merged by the maintainers, Bountea’s backend detects the merge event and the associated GPG signatures. The bounty reward is then automatically transferred: 85% of the bounty amount goes to the contributor’s Tea wallet, and 15% is routed to the project’s Tea treasury (or maintainer’s address) as a reward for maintaining the project and facilitating the contribution. This 85/15 split strikes a balance between incentivizing individual contributors and sustaining the overall project. By awarding 15% to maintainers, Bountea acknowledges the project’s ongoing stewardship – funds that can be used for further development or to reward other contributors.

Many usage scenarios are supported without requiring extensive upfront setup. For instance, even if a project hasn’t formally registered with Bountea, a third-party (like an enthusiastic user) can still post a bounty on an issue of that project. In such cases, the Tea Network will escrow the offered tokens and hold the maintainer’s portion until the project opts into the system or a grace period elapses. This ensures funding can flow to any OSS project organically – developers can start fixing issues and earning bounties, motivating project owners to join Tea to claim their share and formally support their contributors. It lowers the barrier for projects to receive outside help, since anyone can propose a financial reward for solving a problem they care about.

Bountea Workflow (Task Funding and Payout):

1. Bounty Creation: A sponsor (project maintainer or community member) creates a bounty by commenting on a GitHub issue (e.g. /bounty 100 TEA) or via the Bountea UI, specifying the reward amount. The bounty details are recorded and the funds (100 TEA in this example) are locked in the Tea Network’s bounty contract. The issue is labeled with the bounty offer for visibility.

2. Contributor Claims and Resolves: A developer picks up the issue, signals intent (assigning themselves or commenting), and begins work. They write code to fix the issue. When ready, they open a Pull Request referencing the issue. The commits in the PR are GPG-signed by the developer, which GitHub shows as “Verified” . The add-on matches the GPG key to the developer’s Tea wallet (if the developer hasn’t linked one yet, Bountea guides them to generate a GPG-linked wallet). This step implicitly “claims” the bounty in the sense that the network knows which contributor will receive it upon completion.

3. Review and Merge: Maintainers review the Pull Request. If the contribution meets the requirements, the PR is approved and merged into the codebase, thereby resolving the issue. When the issue is closed (or the PR merged), the Bountea smart contract is triggered to release the funds.

4. Reward Distribution: Upon merge, the bounty payout is executed. The contributor automatically receives 85% of the reward (e.g. 85 TEA) directly to their GPG-linked Tea wallet. The remaining 15% (15 TEA) is sent to the project’s Tea treasury or maintainer’s wallet as configured. If the project has multiple maintainers, that 15% can later be split according to their own arrangements or governed by the project’s DAO. All transactions are on-chain, providing transparency – anyone can see that a given GitHub user (via their public key) received a reward for a specific contribution.

5. Fallbacks and Unclaimed Bounties: If a bounty is not resolved within a certain time or if the project maintainers reject the contribution, the bounty poster can retract the funds or extend the deadline. If a project was not registered and a bounty was completed, the contributor still gets 85%. The 15% maintainer portion is held. Later, if the project maintainer joins Tea and claims it (proving ownership of the repo, possibly via a commit signature or repo verification), they receive those accrued maintainer rewards. Otherwise, after a long period, unclaimed maintainer portions might be recycled back to the bounty fund or DAO treasury to fund other public goods.

The Bountea system introduces a robust task-based funding workflow directly into developers’ existing tool (GitHub), turning issues into actionable, incentivized tasks. By using GitHub’s verified commit signatures as an identity layer, it avoids the need for contributors to switch contexts or create new accounts – their GitHub identity is their Tea Network identity (a concept enabled by cryptographic signatures). This secure linkage is made possible by GPG keys, which provide a cryptographic proof of authorship. Since the Tea Network can trust a GPG signature as confirmation that a specific GitHub user (and thus a specific Tea wallet) made a contribution, value transfer can be automated with confidence and without manual intervention.

Bountea not only provides a way for developers to earn immediate rewards for specific work but also creates an economy around open issues, encouraging faster problem resolution. Maintainers benefit by seeing their project improve and by receiving a fraction of each bounty, aligning incentives so that they welcome outside contributions. In cases of security fixes or critical bugs, external entities (companies relying on the project, for instance) could post sizable bounties, knowing the Tea Network will handle fair payout distribution once fixed.

By integrating Bountea into the Tea Network’s application layer, Tea extends its core philosophy (“rewarding open-source contributions”) into day-to-day development practice. It complements the base protocol’s automatic token rewards (from Proof of Contribution) with user-directed rewards for targeted tasks. This dual approach covers both broad, ongoing project value (via teaRank rewards) and granular, one-off improvements (via bounties). The result is a more complete ecosystem of incentives: maintainers earn through protocol rewards and bounty facilitation, while developers anywhere in the world can get paid in tokens for solving issues, all without leaving the familiar GitHub environment. Bountea transforms GitHub into a gateway for value transfer, empowering open-source developers to sustain their work through a decentralized, permissionless bounty marketplace.

Staking and Reward Distribution Mechanisms

One of Tea’s fundamental innovations is how it distributes rewards across the dependency graph of open-source projects, ensuring every contributor in the chain of software gets their fair share. In the Tea Network, token rewards flow from top-level projects down through all their dependencies, guided by the teaRank algorithm and staking by supporters. The overall mechanism works as follows:

• Project Registration & Treasury: When a package maintainer registers an open-source project on the Tea Network, the protocol creates a unique on-chain treasury contract for that project . This treasury will receive that project’s allocated rewards over time. Upon successful registration, if the project’s teaRank exceeds a governance-defined threshold, the project becomes eligible for Proof of Contribution (PoC) rewards . The protocol begins distributing TEA tokens to the project’s treasury on a regular schedule, proportional to its teaRank and usage in the ecosystem.

• Supporter Staking: Open-source project supporters (who may be end users, companies, or fans of the software) can stake their TEA tokens on projects they believe in. Staking is a way to vouch for a project’s quality and security – supporters “lock” TEA in the project’s contract, which yields them influence and a share of rewards. Every staked token yields a non-transferrable governance token (stTEA) for the supporter, representing voting power in Tea’s governance (and potentially in project-specific governance if applicable). Project supporters are incentivized because a portion of the Tea protocol’s emissions is allocated to stakers of projects, and by staking on a project, they receive a cut of that project’s reward flow.

• Reward Cascades Through Dependencies: When a project (say a popular framework) receives TEA token rewards, it doesn’t keep all of it. Tea’s protocol uses the dependency graph to cascade rewards to the libraries and modules that project depends on. For example, if project A depends on library B and C, then B and C will receive a portion of A’s reward (in addition to their own direct rewards) commensurate with their impact (teaRank relationship) in A’s functionality. Those in turn pass a share down to their dependencies, and so on recursively . This creates a flow of value from the top of the dependency tree to the very bottom. Foundational projects that underlie many others accumulate rewards from all downstream usages. In essence, Tea’s token distribution algorithm ensures that all components of a software stack are rewarded for their contribution, not just the application at the top .

• Steeping and Dynamic Adjustment: The process of distributing rewards down the dependency graph is sometimes referred to as “steeping” (an analogy to tea brewing). The algorithm dynamically adjusts how much each dependency gets based on factors like how critical the dependency is and how many other alternatives exist. If a dependency becomes outdated or replaced, its teaRank (and thus its reward share) will decay, and rewards will re-route to the new preferred dependencies. Supporters can also reallocate their staked tokens if projects fall out of favor. This dynamic system means reward distribution continually reflects the current state of the ecosystem’s usage and trust.

• Treasury Utilization: Each project treasury receiving rewards can be managed by the maintainers. Maintainers are required to stake a portion of their project’s rewards back into the project as a signal of their commitment to its health. This increases their project’s security stake (and gives them more governance weight via stTEA) and aligns their interests with the network. Treasuries can also be used to pay for project needs: maintainers might use some funds to sponsor Bountea bounties for their project, fund development tools, or hold tokens for future staking rewards. If maintainers abandon a project, governance can vote to halt its rewards and potentially transfer the treasury to a new maintainer (or the project’s fork), to ensure continuity.

The outcome of these mechanisms is a more sustainable and fair reward system for open-source. Instead of only high-profile projects getting funding, even a small utility library maintained by a lone developer can earn continuous rewards if it is widely used (because larger projects channel a portion of value to it). This addresses the “tragedy of the commons” in software dependencies, where critical low-level components are often overlooked. Tea’s staking model also introduces accountability: supporters who stake on a project are financially invested in its security and quality, and tea tasters (expert reviewers) stake and risk their tokens to validate a project’s releases . If a project turns malicious or low-quality, those stakeholders lose reputation or funds, creating strong disincentives for bad actors.

From a token flow perspective, the Tea protocol draws from a reserved pool of TEA (the Ecosystem & Governance allocation, which was about 21.851.4% of the supply ) to continuously emit rewards to projects and their supporters over time. The distribution curve is predefined and will span decades, gradually releasing tokens as the open-source ecosystem grows . This means early on, rewards per project might be small, but as more projects onboard and overall contributions increase, the system can scale up the incentives while adhering to the long-term emission schedule.

In summary, Tea Network’s staking and reward distribution mechanism ensures value flows to where value was created in the software supply chain. By combining algorithmic reward allocation, community staking, and dynamic adjustments, Tea creates a self-sustaining cycle: valuable projects attract supporters and rewards, which enables further development and security for those projects, which in turn benefits all dependents and the broader community. It’s a holistic approach to funding open-source, treating the ecosystem as an interconnected graph rather than isolated silos.

Governance Structure and Voting Process

Tea Network is governed as a decentralized protocol, with decisions influenced by those who contribute value and stake their tokens. The governance structure centers on the TEA token and its derivative, stTEA. When participants stake TEA, they receive stTEA (staked TEA) at a 1:1 ratio. stTEA cannot be transferred or traded; it represents one’s voting power in Tea’s governance system. In addition, the protocol may factor in a user’s reputation (built from contributions, successful reviews as a tea taster, etc.) to weight votes, so that active, proven contributors carry more influence .

Governance of Tea is conducted through a proposal and voting process, often likened to a DAO (Decentralized Autonomous Organization). Active contributors who hold stTEA can propose changes to the protocol’s parameters, upgrades, or other governance actions . For example, proposals might include adjusting the teaRank threshold for project rewards, changing the bonding curve parameters on Brew.fun, allocating treasury funds for grants, or electing community members to specific roles. Each proposal typically requires a certain minimum support (e.g., a proposer must have X stTEA or a group of supporters) to be formally submitted, ensuring the system isn’t spammed with low-quality proposals.

Once a proposal is submitted, it enters a voting period where all stTEA holders can vote for or against (or abstain). Votes are weighted by the amount of stTEA (and potentially modulated by reputation scores to encourage merit-based governance). The Tea governance smart contracts tally votes and determine the outcome based on predefined rules – for instance, a simple majority of votes cast, with a quorum requirement (minimum percentage of total supply voting) for validity. Because Tea’s community includes different stakeholders (maintainers, supporters, tasters, advisors), this on-chain voting ensures every faction with a stake has a say in the protocol’s evolution proportional to their contribution and investment in the system.

If a proposal passes, the changes are enacted. Many governance decisions are automated via smart contracts: for example, a vote to change a system parameter (like reward emission rate or bounty split ratio) can trigger the contract to update that parameter. More complex decisions, such as upgrading the Tea core protocol, might go through a timelock contract after a successful vote, giving a window for review or potential veto if a vulnerability is discovered. In all cases, transparency is paramount – proposals and votes are recorded on-chain, and discussion typically occurs in public forums (such as Tea’s community governance forums or Discord) before and during the voting period.

The governance structure starts relatively simple – the core Tea team might bootstrap it with an initial set of parameters and the community voting mainly on non-critical issues – and progressively decentralizes as the network matures. Early on, certain “guardrails” exist: some protocol parameters are not immediately subject to governance to avoid attacks or instability . For example, security-critical settings or emergency shutoff mechanisms might be under a multi-sig control or require a higher governance threshold. Over time, as the community grows and proves capable, these controls are handed over to full on-chain governance (a process sometimes called a “progressive decentralization”). The aim is to balance stability with open governance: the system gradually opens up more decision-making to token holders as confidence in the governance process solidifies.

Governance voting flow typically works like this (illustrative diagram of process): A community member drafts a proposal -> other members discuss and signal support (off-chain) -> the proposal is formally submitted on-chain (if it meets submission criteria) -> stTEA holders vote during an open window (e.g., 7 days) -> after voting, if quorum and majority are met, the proposal is queued for execution -> after any timelock, the proposal’s changes execute on-chain, updating the protocol. If the proposal fails (insufficient votes or voted down), it is dropped and has no effect.

The Tea Network’s governance also oversees the DAO Treasury (which accumulates fees or undistributed tokens). For instance, the 21.8% “Ecosystem & Governance” token allocation , which is used for rewards and community initiatives, is effectively managed by governance. The community could vote to use some treasury tokens for grants to important open-source projects, to fund hackathons, or to provide additional liquidity to Velocitea if needed. They can also vote on protocol upgrades – as Tea evolves, technical improvements or even migrations to new technology (say, integrating a ZK-rollup for faster finality in the future) would be subject to governance approval.

Tea’s governance model is designed to be inclusive of all contributors: package maintainers, through their staked rewards, have a voice; project supporters who stake on projects have a voice; tea tasters building reputation have a voice; and early backers and advisors (holding tokens) also participate. This mix ensures no single group monopolizes control. The weighting by stake and reputation aims to prevent purely monetary whales from overruling the expert community, while still requiring that voters have skin in the game (you must stake value to influence decisions).

In conclusion, the governance of Tea Network is a critical component that keeps the protocol adaptable and community-driven. By enabling token holders and contributors to propose and vote on changes, Tea ensures that the system can evolve in response to the community’s needs and the ever-changing landscape of open-source software. This on-chain governance, combined with the economic incentives and safeguards (like slashing for malicious actions, and rewarding positive contributions), creates a resilient structure. It puts the future of the open-source funding protocol in the hands of those who use and contribute to it, fulfilling the decentralized ethos at the heart of Tea Network.

Acknowledgments

This white paper would not exist without the support and dedication of many teaophiles. The authors would like to acknowledge Jacob Heider, Jadid Khan, Josh Kruger, and Shane Molidor for their contribution to the tokenomics, Sanchit Ram for his contribution to the teaRank algorithm, and the many discrete individuals who volunteered their time to provide feedback on the contents of this document.

Glossary of Terms

Term	Definition
Slashing	The action of penalizing stakers in response to behavior contrary to the protocol rules.
Staking	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.
stTEA	Non-transferrable “staked TEA” token or “stTEA” received by network participants for each token staked at a 1:1 ratio. stTEA can be utilised to participate in the governance of the tea Protocol
teaRank	Dynamic impact score assigned to each project by the protocol’s “Proof of Contribution” algorithm.

References

1. https://creativecommons.org/licenses/by-sa/4.0/

2. https://archive.org/details/historyofmodernc00ceru

3. https://nvd.nist.gov/vuln/detail/CVE-2021-44228

4. https://www.reuters.com/article/usa-cyber-vulnerability-idCNL1N2SY2PA

5. https://twitter.com/yazicivo/status/1469349956880408583

6. https://www.thestack.technology/core-js-maintainer-denis-pusharev-license-broke-angry/

7. https://www.w3.org/TR/did-core/

8. https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/

9. https://www.theregister.com/2016/03/23/npm_left_pad_chaos/

10. https://fossa.com/blog/npm-packages-colors-faker-corrupted/

11. https://www.lunasec.io/docs/blog/node-ipc-protestware/

12. https://github.com/dominictarr/event-stream/issues/116

13. https://blog.npmjs.org/post/163723642530/crossenv-malware-on-thenpm-registry.html

14. https://www.zdnet.com/article/open-source-software-how-many-bugs-are-hidden-there-on-purpose/

15. https://threatpost.com/backdoor-found-in-utility-for-linux/147581/

16. https://www.fbi.gov/news/stories/phantom-secure-takedown-031618

17. https://www.europol.europa.eu/media-press/newsroom/news/800-criminalsarrested-in-biggest-ever-law-enforcement-operation-against-encryptedcommunication

18. https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502

19. https://www.npmjs.com/package/lodash

20. https://www.npmjs.com/package/chalk

21. https://www.npmjs.com/package/log4js/

22. https://www.bleepingcomputer.com/news/security/npm-ecosystem-at-risk-from-manifest-confusion-attacks/

23. https://medium.com/intrinsic-blog/compromised-npm-package-eventstream-d47d08605502

24. https://semver.org/

25. https://arxiv.org/abs/1207.2617

26. https://research.web3.foundation/Polkadot/overview/token-economics