# TEA Project Intro TEA Project is a decentralized cloud computing platform that hosts rich, decentralized applications known as [TApps](https://github.com/tearust/teaproject/blob/master/docs/_1_ecosystem/_5_tapps/README.md). These are completely decentralized running in miners' nodes or between peer-to-peer clients. By offering highly-scalable and decentralized apps, TEA Project combines the best of both blockchain and cloud computing. Going through the links below in order will give you a good overview of the TEA Project, what we're trying to accomplish, and how we're going about it. * [TEA Project's Litepaper](/_1_ecosystem/1_litepaper) gives an overview of the TEA Project and how it's going about solving the problems inherent with decentralized compute. TEA's roots of trust combine to form TEA's decentralized compute platform. Those interested in more technical details can [read the following article](/_1_ecosystem/4_tea-technical-details) as well as more on our [dev docs site](https://dev.teaproject.org). * [Example applications](/_1_ecosystem/2_example-tea-in-use) that shows how TEA ecosystem participants interact with each other and the underlying architecture including token incentives. For more information on how participants are rewarded, see the following [article on profitability](/_1_ecosystem/7_profitability). * The TEA Project has two system level tokens: [TEA](https://github.com/tearust/teaproject/blob/master/docs/_1_ecosystem/_3_token/tea-tokens/README.md), a utility token used for gas on the network, and [CML](https://github.com/tearust/teaproject/blob/master/docs/_1_ecosystem/_3_token/cml-tokens/README.md), an NFT that functions as a mining license. More info is available in our [tokens section](https://github.com/tearust/teaproject/blob/master/docs/_1_ecosystem/_3_token/README.md). Besides these system tokens, users can create their own token using [Bonding Curves](https://github.com/systems-explained/awesome-bonding). The creators can use these token to pay in their [TApps](https://github.com/tearust/teaproject/blob/master/docs/_1_ecosystem/_5_tapps/README.md) or as an investment tool. * Follow our [User's manual](/_2_user_manual) to start. {% hint style="info" %} Quick links: * [Developer's documents](https://dev.teaproject.org) * [Become a TEA miner](/_4_mining) * [User's manual](/_2_user_manual) * [Investment in TEA](/_3_token/cml-tokens) {% endhint %} # Litepaper ## How TEA Project Solves a Central Web3 Problem Web3 architecture is a dramatic departure from what most devs are used to from web2. Unfortunately, the lack of viable web3 development frameworks has been a bottleneck for widespread deployment of decentralized apps. That's where the TEA Project comes in. Just as Ruby on Rails ushered in the web 2.0 era by allowing full-scale internet applications to be built rapidly, the TEA Project aims to provide a similar development framework for web3 that allows developers to quickly get their dApps up and running. {% hint style="info" %} Please read [use cases](/_1_ecosystem/2_example-tea-in-use) to see how TEA Project helps Peer-to-peer WebRTC video conferencing apps and Realtime multiplayer games to be profit on Web3. {% endhint %} The current Web3 landscape sees many developers cobbling together hybrid dApps because the blockchain layer is too slow for running rich dApps. The TEA Project doesn't focus on smart contracts as they have two major limitations: 1. They're limited in the type of algorithms they can execute. 2. They require consensus. The TEA Project isn't limited by use of smart contracts as part of its execution layer for dApps. Smart contracts make sense in areas such as DeFi, but they can't possibly be the basis of rich dApps that rival the speed and functionality of current centralized cloud computing applications. ## TEA Project's Decentralized State Machine The extent of the TEA Project's decentralization is atomized and evident at the level of its apps. The TEA Project enables app developers to create cloud-speed decentralized apps that rely on distributed nodes instead of centralized servers for hosting. Each of these apps has all 3-tiers decentralized: * The front-end resources (javascript, html, css) are loaded from IPFS. * The server tier is provided by the decentralized node network of hosting miners. * The database tier is kept by decentralized state maintainer nodes. The complete decentralization of TEA network apps is in stark contrast to the centralized cloud apps of web2 as well as the hybrid ETH dApps that are currently prevalent. Because blockchains like Ethereum are only able to provide rudimentary server and database functions, Ethereum dApps will often use cloud hosting to fill the gap. The need to move away from centralized hosting is another reason why the TEA Project uses a non-traditional consensus not based on blockchain. This allows TEA's compute layer to have its own state and also allows cooperation between the two layers as we don't need to rely on Eth's state machine for compute power, database services, or consensus. ## TEA Doesn't "Block" Any decentralized system will need a way to reach consensus, a process that has unfortunately been fraught with compromises. The blockchain trilemma states that a blockchain can have two of **scalability**, **security**, or **decentralization** but not all three. The TEA Project is able to create a near-cloud speed compute infrastructure by avoiding the use of blocks for consensus. * TEA uses three roots of trust: time, trusted hardware, and blockchain. But TEA's compute layer has its own state machine separate from the underlying blockchain it runs on top of. Because of this, we say that TEA doesn't "block" and uses a scalable non-traditional consensus on its compute layer to pave the way for high-speed dApps. * TEA currently uses Ethereum as its main layer-1 blockchain but it can also run on top of other smart contract-capable blockchains. Because of this, we say that the TEA Project is "portable." We should also note that when we say TEA doesn't "block," there's also another meaning to the word in addition to TEA not using blocks to reach consensus. In the TEA Project's decentralized system, no one (not even TEA Project) can block anyone from using one of our network's apps (called TApps). TEA Project's TApps are requested by end-users who use any available node to run the TApp. The TApp's CID is all that's needed and no one can block them from running the TApp. We say that TApps are unstoppable, meaning that no one can block them. ## TEA's 3 Roots of Trust The TEA Project's uses three roots of trust to build its compute platform: ### 1. Blockchain Traditional blockchains use two roots of trust: **consensus** and **cryptography**. But their reliance on consensus makes it impossible for these blockchains to scale and meet the needs of rich applications. The TEA Project uses the Ethereum blockchain as one of its roots of trust. The main use of the layer-1 blockchain is to enforce token incentives to ensure good behavior among node runners. ### 2. Trusted Hardware TEA's second root of trust comes from the miners' hardware security modules (HSM) that generate PoT data. Peer-to-peer remote attestation is performed on the compute nodes' trust data in order to reach consensus on the trustworthiness of the nodes. TEA doesn't use consensus to verify the result of the dApp's code, but the execution environment where the code runs. ### 3. Time TEA’s state machine orders transactions using timestamps and a Proof of Time algorithm which utilizes atomic clocks from GPS satellites. The Proof of Time consensus rule ensures that all nodes sort their transactions by the timestamps, which are trustable as governed by the HSM that protect each reporting node's hardware. Because of this consensus logic, geographically distributed nodes will all reach the same state regarding the ordering of transactions. Using trusted time to order transactions allows TEA to run dApps that rival the speeds of traditional cloud computing. TEA is an ideal platform for any app requiring data security and privacy while remaining censorship-resistant. ## Decentralized Compute Using TEA's Roots of Trust One of the enduring problems of decentralized systems is how to circumvent the slow processing speeds inherent with consensus. The TEA Project avoids slower forms of consensus through the use of three roots of trust described earlier: blockchain, trusted hardware, and time. These three roots of trust are used to create two separate consensus algorithms: * **Proof of Trust**: TEA’s compute layer consensus verifies the trust data from the onboard hardware security modules (HSM) of its compute nodes, with the resulting status written to the Ethereum blockchain. A central TEA premise is that if the execution environment can be trusted, then the execution result can be trusted as well. * **Proof of Time**: The TEA Project’s state machine runs a separate consensus based on time. TEA uses the timestamps as reported by the compute nodes’ atomic clocks (from GPS) units to order transactions on its state machine. The consensus rule is that all nodes sort the transactions by the timestamps, which are trustable as governed by the HSM that protect each reporting node's hardware. Because of this consensus logic, geographically disparate nodes will all reach the same state regarding the ordering of transactions. It could be said that these two new consensus mechanisms are the TEA Project's main innovations that unlock a decentralized cloud-speed network for apps that require data security and censorship-resistance. By combining blockchain with IPFS, GPS and trusted hardware, the TEA Project can meet the needs of large-scale, high-frequency apps while ensuring permission-less decentralization and data privacy protection. ## The TEA Token Economy To ensure a healthy token economy that incentivizes behavior supporting the TEA ecosystem, the TEA Project has developed three main types of tokens: 1. The **TEA** utility token. 2. The **CML** NFT that comes with mining privileges. 3. Bonding curve tokens ### 1. The TEA Utility Token Our first token, [TEA](/_3_token/tea-tokens), is a utility token with a supply of 100 million tokens (hard cap / no inflation) pre-allocated in the genesis block. TEA is also given as a reward to miners for running public services (e.g. remote attestation) on the TEA network. TEA has a variety of uses on the platform: * TEA pays for gas when performing any transaction on the network (paid to miners who run the nodes). * TEA is paid by consumers when using a TApp. * TEA can be used to purchase bonding curve tokens (explained below). The 100 million tokens minted at genesis will be allocated with different vesting schedules as follows: ![100M-allocation](https://user-images.githubusercontent.com/86096370/188247420-183894d8-1b03-4d6f-a275-dea62be519c5.png) ### 2. The CML NFT with Mining Privileges Camellia [(CML)](/_3_token/cml-tokens) is a non-fungible token (NFT) that's used by TEA miners to activate their mining machines. The CML tokens essentially act as both an ID mechanism for their mining nodes as well as an access key that allows them to mine on the TEA network. To run a node on the TEA platform, miners must associate a special NFT with their machine that acts as a mining license. The CML that is associated with a mining machine tracks that machine's features (e.g. ram and presence of graphics card) as well as behavior (e.g. uptime). This information on each CML ID is stored in the ERC-721 token’s metadata. In a scenario where the miner wishes to upgrade their hardware, moving the CML to their new machine also transfers its metadata such as its trust score. There are two different types of mining privileges on the TEA Project platform: 1. A hosting node which is activated by a CML (Camellia) NFT. This allows a miner to host TApps on the platform. 2. A state maintainer seat license that allows a user to run a state machine node. Let's take a look at each of these in turn. ### 2.1 CML NFTs A CML is an NFT with a life cycle determined randomly via algorithm. CML, also known as Camellia, has some unique properties and uses on the TEA Project platform. * A TEA mining node can only be activated by associating a CML NFT with it. Each CML has a lifespan associated with it (approximately 2 years). Like its Camellia name suggests, every CML has a life span that mimics organic plants - it grows from a seed, matures into a fully productive tree, and eventually dies. Each mining machine's characteristics (its hardware capabilities) will be recorded within the CML NFT. * Investors can buy shares in a mining nodes to earn a percentage of that node's mining rewards. This is done through a CML token which will be described below. * Miners buy new Camellia seeds through open bidding. The DAO issues new CML NFTs in accordance to how much demand for hosting there is in the TEA ecosystem. * CML mining nodes earn TEA from the gas paid by end-users to use their hosting nodes to run TApps. * CML nodes can also earn remote attestation rewards in TEA as compensation for performing this public service. ### 2.2 State Maintainer Seats A state maintainer seat license allows a node operator to function as a state machine node. Because of the importance of the state machine, the TEA Project team and select invitees will only be allowed to run state machine nodes for approximately the first 2 years after mainnet launches. The supply of these seat licenses will be determined by a DAO vote and they have a complex token economy described as follows: * TApps will pay state maintainer nodes as part of using the state machine. This is known as the **Memory Tax**. * The Memory Tax is the sole source of income for state maintainer nodes and is shared among all node operators. * Every state maintainer will pay a state maintainer tax known as a **Harberger Tax**. The TEA Project has elected to adopt a Harberger Tax given that state maintainer licenses are a public good. * The Harberger Tax paid by each state maintainer is a set percentage (voted on by the DAO) of the seat's self-valuated price. Each seat owner can set their own price for what they think their state maintainer license is worth. Anyone in the community can purchase any of these seats by bidding 1T higher than the self-valuation price. * Harberger Taxes go to pay remote attestation rewards earned by CML node operators. Any excess funds are also distributed to the CML node operators as a surplus reward for their mining services. ### 3. Bonding Curve Tokens The TEA Project uses bonding curves throughout its tokenomics design for the following types of token entities: 1. TApp tokens 2. CML hosting node tokens These bonding curve tokens have built-in liquidity to enter and exit positions, providing security for investors. In the bonding curve below, the price increases as more tokens are bought. Investors buy at the red line and sell at the blue line where there will always be liquidity at each level along the bonding curve. ![5 TEA-Project-Bonding-Curve](https://user-images.githubusercontent.com/86096370/188735110-b522f614-5eda-4b08-b62d-901ec13b70c2.png) Stated simply, when either a TApp or CML node is used, its bonding curve token holders will benefit be receiving dividend payments and an increase in their bonding curve token's value. ## TEA Ecosystem Development The TEA ecosystem is an interdependent network that includes various participants. The TEA Project incentivizes each participants through a carefully designed token economy. Each participant is incentivized to act in their best interest, thereby helping strengthen the entire TEA Project ecosystem. * **Miners**: They own/rent hardware mining machines, purchase CML (NFT, similar to software license), provide computing services and get rewarded with TEA. Read more in [basic concepts for miners](/_4_mining). * **Developers**: They use the TEA framework to develop TApps that run on mining machines and provide services to earn revenue. The revenue is distributed to investors and miners according to setting of the bonding curve. You can read more about [basic concepts for developers](/_5_tapps/developers). * **Investors**: Users with TEA funds can invest in mining machines and especially TApps (through their bonding curve tokens) in order to get ROI. For example, each TApp will have its own TApp token that investors can purchase as if investing in a stock. Each TApp token represents a share in the TApp and gives the holder dividends in the form of more TApp tokens issued to its holders whenever someone uses the TApp. As these tokens are issued on a bonding curve, the earliest TApp token investors will enjoy the largest amount of price appreciation. Investors can learn more about investing in [entity tokens](/_3_token/bonding-curve-tokens/tapp-token-supply-and-demand). * **Community leaders** have special roles in TEA ecosystem. Many TApps are designed for them to gain a profit by hosting a venue such as game room or class room. Hosts can create their own bonding curve tokens that will be used in their game rooms or class rooms. * **End-users**: Concurrently attracting developers to the platform, the TEA Project will actively market emerging TApps to consumers. We envision the TEA Project as an ideal ecosystem for existing cloud apps looking to migrate and benefit from decentralization and data privacy. We look forward to the types of decentralized apps that will flourish on the TEA Project network. We also aim to play an active part in welcoming consumers looking to transition from the centralized web 2.0 world to the TEA Project and web3. # TEA Project Example Use Cases ## Peer to peer WebRTC apps with payment channel WebRTC is widely used in video conferencing apps similar to Zoom. A true **peer-to-peer** application doesn't require a server end. All code is running on the client/browser of both ends. In ideal cases, direct network connection between both ends transfer video/audio data without any middle man in between. This type of apps, usually called P2P apps, is a typical Web3 application because the natural decentralized topology and censorship resilience. However, due to the lack of a central server, financial transactions between involved parties become a pickle. Traditional blockchain can technically solve this issue but at very high cost. TEA Project has a built-in payment channel feature similar to BTC's layer-2 [lightning network](https://lightning.network/) algorithm. Both parties can setup a payment channel before a video conference call, then exchange payment information during the call. When the call is over, a settlement will be completed. Only very few TEA transactions are needed and at a very low cost. If we consider blockchain as layer-1, the TEA project as the layer-2 on blockchain, we may call the payment channel as layer-3. [TEA Party](/_2_user_manual/_8_tea-party) is the example app to demonstrate this feature. TEA Party allows a host(who create a video chat room, such as a teacher in classroom), get **paid per minute** by the guests(who are invited by the host via a shared URL link, such as students). There is no central server between host and guests. No matter how long the video chat does, there will be only two (or maybe three) payment transactions sent to the TEA Project network at the beginning and ending. Every minute (depending on cost structure set by the host) both host and guests exchange signed payment confirmation messages through the peer to peer network directly. The payment channel algorithm protect both sides from irresponsible behavior or incidentally network disconnection. TEA Party's payment can be bi-directional. That means either guests pay the host (e.g., the host is a online school teacher), or the host pay the guests(e.g., the host is making a commercial presentation). WebRTC is not limited to video/audio signal, all online collaborative applications can be done the same way. There are a lot of WebRTC based peer-to-peer applications online already. But why we did not feel they are popular? One major reason is hard to get profitable without having a running centralized server to collect money. With the help of TEA Project, most of them can be migrated to TEA Project platform benefiting from the tokenomics. ## Realtime games with token incentive Realtime multiplayers games (e.g., the first and most famous Agar.io) are popular because of their simplicity, convenience, and low cost. They even have a name for this type of games - they are called "IO games". Most of these games follow the Web2 era business model: In-app-Ads. Why do not we apply Blockchain era's **Play-to-earn** model to these already popular games? One of the biggest challenges is that blockchains or even advanced layer-2 solutions can hardly handle constant game state change in realtime, at least when under a reasonable cost constraint. Another naive idea is to convert those realtime multiplayers game to peer-to-peer game, so that one of peers acts as "host" that run the so-called-server code while other peers join as guest peers. This idea can partially solve the blockchain cost problem by submitting a combined transaction at much less frequency. However, when there is real financial incentive, trust of the host peer would become a new challenge. It is too easy for the host to cheat other players for profit, and other players would never know. TEA Project has a perfect solution on this. The so-called server logic runs in the hardware enclave inside TEA Project host nodes. All TEA Projects mining nodes will use Remote Attestation to guarantee the game logic to be alter free. TEA Project's built-in tokenomics can also integrate in **bonding curve** and **lightning network** features to the game at no additional cost. Migrating existing IO games to TEA Project is nothing but rewriting into WebAssembly on the server side. Because of the billing system, the game developers no longer concern about setting up server in the cloud or paying for the rent. The new Web3 style tokenomics allow miners to charge gas fee from players directly. {% hint style="info" %} #### How does it work? Let's consider a TEA-enhanced Agar.io game (referred to as TeaAgar), see how developer, miners and players work in this new ecosystem. 1. the game developer compiles the server logic into WebAssembly then upload to Developer's portal. 2. Alice is an experienced Agar player and also a community influencer. She creates a bonding curve token called "Alice wonderland" in TAppStore. This token will be used as the currency in the the game room she is going to create in next step. 3. Alice goes to the TeaAgar TApp page and create a new TeaAgar room called "Alice's Agar Room". She shares the invitation link to her community. 4. Bob is Alice's community follower. He click the link and enter Alice's Agar Room. Assuming he already has some TEA token. If not, he will need to earn some TEA first. He needs to buy some Alice Wonderland token which will be used in this game room. Buying this token will increase the token price and total value. 5. Bob and other players play Agar.io in this game room. Every points they earn in the game are actually a Alice Wonderland token. They can see the token balance increase or decrease in real time. 6. Based on the game logic design, the developer can get a cut from all game assets transfer or time-based / activity-based charge. 7. The miner machine which run the WebAssembly code charge gas fee from players directly. That means Bob and other players will pay gas fee in TEA to the miners who provide the server(TEA nodes) they are connecting to. 8. When Bob decide to leave the game, he can withdraw the Alice Wonderland token he earned in the game. He can either sell those token to TEA or other stable coin(e.g. FDUSD), or simply keep the token as is if he prefer to see the token price increase in the future. During this new tokenomics design, game developers do not need to rent and setup a server, neither do the miners. Players pay TEA as gas for consuming miner's server computing resources. Players earn (or maybe lose) game token while enjoying the game. Game developers earn profit from game activity, it could be transaction based or time-based, it is just regular game logic. There is no reason for developers to inject in-app-Ads to make a living. {% endhint %} ## CBDC cross-border payment and exchange {% embed url="" %} ## Confidential computing The TEA Project aims to disrupt the world of cloud computing by enabling decentralized apps to run on the blockchain at cloud computing speeds. As we no longer have the cloud servers of web 2.0, we must incentivize miners to provide the underlying infrastructure. IPFS is the actual storage infrastructure for storing both encrypted app and client data, which miners will host within their protected enclaves when their node is selected for a task. Let's examine the economic incentives for a hypothetical Tensorflow image recognition TApp running on the TEA network: * The **developer** uploads their Tensorflow image recognition analysis TApp to IPFS. * A **photographer** uploads their pictures to IPFS. * A **researcher** wants to use the **developer's** TApp with the **photographer's** pictures. * A random **miner** is selected to host the Tensorflow TApp and the pictures within the protected enclave of their mining machine. ![Confidential computing sample](https://user-images.githubusercontent.com/86096370/219790724-db85a7c6-5c59-42b9-9550-7c00f63aa69a.png) In economic terms, the **researcher** pays to use the TApp. The payment flows through the **miner** who provided the node to perform the secure and private calculation, the **photographer** who is paid for the use of their pictures, and the **developer** who is paid for the usage of their code. Every transaction enriches a wide variety of participants in the TEA ecosystem and helps sustain and incentivize further usage. {% hint style="info" %} #### TEA's Paradox: No one has to trust anyone else Because the TEA Project is capable of providing the underlying trust, there's no longer any trust required between all four parties. The TEA Project is able to provide all participants with a decentralized computation network that is both secure and private. In practical terms, that means the developer who wrote the code cannot breach the photographer's image. And the miner who is randomly selected to host it in their enclave cannot access either the photographer's data or the developer's code. And the researcher is only able to receive the result of the app's calculation and isn't able to access the photographer's data outside of the enclave. The security and privacy that the TEA Project's decentralized computing network is able to provide has wide range of emerging use cases like residential IoT data and patient health records. {% endhint %} # TEA Project's Technical Principles {% embed url="" %} ## Two principles: TEA = Trusted Execution and Attestation 1. **Trusted Execution** comes from protected enclaves where app logic can run while being protected by hardware security modules. All TEA Project TApps run inside of these protected enclaves. Neither the app developer nor the miners have any control over the apps nor can they extract any data from the running enclaves. 2. **Trusted Attestation** refers to the process whereby the network nodes run reports on each other to ensure mining hardware running on the TEA network hasn't been tampered with. Once trusted status is attained, these nodes can run on TEA's compute layer at cloud computing speeds without worrying about traditional consensus. ## Transaction Consensus Using Time We say that the TEA Project has three roots of trust: hardware, blockchain, and time. We've already seen how hardware security modules and blockchain can create a trustable computing environment through remote attestation and trusted enclaves. This provides a scalable and trustable application execution tier for TApps, but we also need a data tier to track TApp state changes and transaction accounting. The TEA Project has two state categories: ### 1. A strong-consistency state machine based on Proof of Time The first state category, based on Proof of Time, is for transactions requiring strong consistency, such as those involving funds and accounting. Leveraging timestamps from time stamps from navigation satellites monitored by hardware attestation, our strong-consistency state machine achieves continuous state updates with minimal synchronization cost. Its crucial task is ensuring the consistency of transaction sequence across all replicas, relying on accurate time from the atomic clock of GPS satellites. The reported time is acknowledged under the supervision of trusted HSMs (e.g., hardware with TPM chips) and serves as the basis for transaction timestamps used to order the transactions. To ensure most nodes synchronize to a consistent state, the TEA Project’s state machine requires a short waiting queue due to network latency. As time is stable on our planet, each node can achieve strong consistency using our time-based consensus, trusting the timestamps of the transactions. {% hint style="info" %} At the time of this document is written, the only supported trusted hardware is [Amazon Nitro](https://aws.amazon.com/ec2/nitro/). More supported hardware types will be added in the future. {% endhint %} ### 2. An eventually consistent CRDT database built on OrbitDB that can be used ad hoc by TApps The other state category is a CRDT database that allows for short-term inconsistencies in the business logic of TApps. The TEA Project utilizes OrbitDB databases built on top of IPFS for these transactions. CRDT stands for Conflict-Free Replicated Data Type, enabling conflict-free mergers between different replications before achieving network-wide consistency. Most TApps can tolerate short-term inconsistencies to achieve decentralization and efficiency. A classic example of a traditional cloud app dealing with this issue gracefully is Google Docs when it smoothly merges edits from multiple simultaneous users. Using time as a source of truth enables the TEA Project to synchronize the state between all its state machine nodes without resolving complicated consensus problem. This state machine also includes an embedded **SQL instance,** allowing more complex apps requiring a database to be built on the TEA platform. {% hint style="info" %} The embedded SQL database used in TEA Project is [GlueSQL](https://github.com/gluesql/gluesql) {% endhint %} ## TEA Application (TApp) architecture TEA Project supports multiple types of Web3 applications ### Three tiers application architecture The TEA Project aims to become an ideal onboarding point for developers looking to deploy to the decentralized web. As an infrastructure provider for Web3, we designed our ecosystem to look familiar to developers who will appreciate the straightforward 3-tier architecture that’s similar to cloud computing. * The **front-end tier** for TEA decentralized applications utilizes IPFS to host its assets. The TEA Project is agnostic towards the front-end the developer wishes to use (JavaScript, HTML, CSS, etc.). * The **server tier** manages dev code compiled to WASM, allowing developers to use their existing programming languages and set WASM as the output target. * The **database tier** is managed according to the developer's needs - NoSQL data is sent to IPFS as governed by CML hosting nodes, while relationship data is stored in GlueSQL as governed by the state maintainer nodes. We aim to establish the TEA Project as the preferred development platform for developers entering the web3 space. We are confident that the simplicity of our tech stack will attract developers, eliminating the need to learn new languages or blockchain concepts. This allows them to leverage the advantages of decentralization and data privacy offered by Web3 while deploying within a 3-tier architecture they are already familiar with. ### Peer to peer application architecture Besides typical three-tier applications, peer-to-peer applications are popular in the Web3 world. These applications are designed to be fully self-contained, which means almost all logic runs inside the client as a so-called "protocol". Therefore, they involve very little or zero server-side support. TEA Project fully supports this type of new Web3-oriented application architecture. TEA Project has integrated the **payment channel** protocol, which is similar to BTC's **Lightning Network**. Use WebRTC-based [TEA Party](/_2_user_manual/_8_tea-party) as an example, the only two server-involved places the host peer or guests' peers are 1. signaling (peers discovery) 2. payment channel setup & settlement. All the video/audio data is transferred between the host peer and guests' peers directly. In case the TEA Party hosting node is accidentally down during the call, none of the peers will notice, and their payment won't be affected. ### Realtime collaborative application architecture Real-time collaborative applications are similar to the three-tier architecture but require socket connections between the server and peers so that all peers can receive real-time updates on the latest state. This type of application is most commonly seen as multiplayer games, collaborative document editing tools, etc. Because the state of the application is constantly updated and requires pushing updates to the client peers in real-time. Traditional three-tiers or blockchain can hardly handle. TEA Project has a specially designed protocol to deal with this situation: * The hosting node (where the app server logic runs) maintains a real-time, instantly updating state that syncs with all client peers in real-time. * The state machine nodes (which maintain the consensus of the ledger) sync state with hosting nodes periodically with a slight delay to compensate for proof-of-time consensus. Final settlement transactions are handled by the state machine after the slight delay. This is an acceptable compromise because final settlements won't occur in real-time; they usually happen when a user tops up (joins) or withdraws (leaves). {% hint style="info" %} This protocol is under development (Dec 2023). {% endhint %} ## WASM In the TEA Project, dApps run WebAssembly (Wasm) code within the hardware-protected enclaves of the compute nodes. The use of Wasm in TEA allows developers to utilize their preferred programming language, simplifying the deployment of apps to web3 through the TEA Project. Furthermore, developers familiar with the front-end / back-end / database tiers of cloud computing will recognize these components in the TEA Project. While TEA Project TApps adhere to the same three-tier architecture common in cloud computing (presentation tier, app tier, and database tier), they operate fully decentralized. Applications can achieve optimal performance on the TEA Project's compute layer because, from the app's perspective, it mirrors a standard three-tier cloud computing architecture. Developers do not require specialized knowledge of blockchain or consensus algorithms to benefit from decentralization and security within the TEA Project's 2-layer blockchain. They only need to set WebAssembly as their code compilation target while continuing to use their preferred programming languages. ## Relationship with blockchains Unlike typical Layer 2 solutions built on top of blockchains, TEA Project does not "roll-up" state to Layer 1. Instead, TEA Project stores its own state within the hardware enclaves between state machine nodes to enhance security and confidentiality. It doesn't bind to any specific blockchain as Layer 1 but relies on the blockchain to store trusted data and crucial financial transactions for security. Currently, Ethereum serves as the Layer 1 for TEA Project. TEA Project relies on Ethereum for the following purposes: * Top-up (deposit) or withdraw ERC20 assets to/from the Ethereum chain * TEA token is an ERC20 token, and CML is an ERC721 token, both residing on the Ethereum chain * Smart contracts are employed to enforce miners' compliance with SLA and security requirements Other blockchains, such as BTC, DOT, etc., are planned to be added as alternative Layer 1 solutions. # Profitability of TEA Ecosystem Participants There are multiple ways of achieving profitability in the TEA ecosystem. Being an investor in TApp or CML bonding curve tokens is one way to earn TEA value. But a more active way is to actually engage in the TEA ecosystem in one of the three following ways. ## Profitability Calculations for TEA Ecosystem Participants ### Become a Hosting Node Miner * Hosting node miners earn gas fees from end users utilizing TApps on their hosting nodes. * Initial support is provided through Universal Basic Income (UBI) from the DAO Reserve during the early stages. * Miners have the option to subscribe to a state update service, ensuring faster state machine updates, with an associated subscription fee. * Miners are responsible for the maintenance costs of their hosting node machines, typically requiring Amazon Nitro hardware. * To operate on the TEA network, miners must acquire CML seeds (NFTs) serving as licenses for their hosting nodes. Gas fees are measured through the TEA Project mini-runtime virtual machine's billing system, based on WebAssembly code execution. Comparable to Ethereum's ETH gas system but more cost-effective, miners earn higher profits as more users visit their hosting nodes, leading to increased code execution and gas fees. During periods of low user activity, UBI from the DAO Reserve subsidizes miners, helping cover hosting node maintenance costs. The state subscription fee is initially waived. When real-time state updates become available for hosting nodes, this fee will be implemented. This feature is especially relevant to applications like [real-time collaboration applications](/_1_ecosystem/2_example-tea-in-use#realtime-games-with-token-incentive). Hosting node revenue contributes to CML bonding curve tokens, with a percentage (theta %) directly benefiting the miner. This revenue-sharing design extends to CML bonding curve investors as dividends, establishing a symbiotic relationship. Investor support enhances the market cap of CMLs, improving their ranking and visibility, attracting more end user attention and traffic for miners. {% hint style="info" %} **Strategies** * **Early TEA Mining Opportunity**: Optimize profitability by joining TEA mining at the earliest opportunity. A reduced number of hosting miners correlates with higher Universal Basic Income (UBI). * **Strategic CML Bonding Curve Creation**: When establishing your CML bonding curve, allocate substantial funds during the initial funding phase, as prices are lower. A higher market cap secures a superior rank, enhancing competition and attracting more users and traffic. * **Cost-Effective Amazon Nitro Machine Selection**: Choose an Amazon Nitro machine with an ARM CPU for cost efficiency, as they generally offer lower prices compared to X86 CPUs. * **Monitoring Hosting Node Status**: Stay vigilant about the status of your hosting nodes. While they typically undergo automatic upgrades, manual restarts may be necessary to ensure synchronization with the latest version. An outdated hosting node risks suspension, resulting in income loss during downtimes. {% endhint %} ### Become a TApp developer * TApp developers are relieved of server costs as miners cover their own machine expenses. * Revenue for TApp developers is generated through in-app purchases made by end-users, determined by the payment logic design in your app. * When TApps initiate transactions with the state machine or store data in the global state, associated costs are borne by the TApp and paid to state maintainer nodes. This expense is calculated using the TEA Project mini-runtime billing system and a memory tax algorithm. * Each TApp functions as a bonding curve token, with generated revenue directly contributing to the bonding curve token, akin to the revenue model for hosting miners. {% hint style="info" %} ***Strategies*** Besides the general strategies mentioned earlier, there are some specific considerations for developers: * **Optimize Client-Side Logic**: Adhere to the "no-free-lunch" rule by handling application logic on the end user's client side (browser or mobile app) whenever possible. Logic executed on the client side incurs no charges. Conversely, if the logic is processed on the hosting node (server side), the end user is responsible for the associated gas fees. When sending transactions to the state machine or storing data in the state machine, your app incurs gas fees and memory taxes, emphasizing the importance of designing with overall user and cost efficiency in mind. * **Hierarchical Data Storage Approach**: Prioritize storing data first in the client, then in the hosting node, and finally in the state machine. Storing data in clients (browser or mobile app) has no associated cost, while storing data in the state machine incurs memory taxes. Hosting nodes can sometimes store data at a lower cost without synchronizing with the state machine, although this approach may be less secure. * **Protocol-Based Design Over Server Logic**: Consider designing protocols for business logic that can be executed between clients, eliminating the need to send transactions to the server or state machine. Payment channels like the Lightning Network exemplify this approach. * **Limited Server Access for Logs**: In the Web3 environment of the TEA Project, developers lack access to miners' machines, and the project is designed to prevent the disclosure of confidential runtime information from inside the enclave. Unlike the Web2 world, where developers commonly access server logs for debugging and monitoring, this is not feasible in TEA Project Web3. Developers must design their own logic for log outputs, ensuring the code is open for public review to avoid inadvertent disclosure of confidential data. Additionally, note that even miners can only access server logs generated outside the enclave. {% endhint %} ### Become a State Maintainer: Own Your SEAT The TEA Project relies on a minimum of three state machine nodes to uphold the system's state, often referred to as the ledger in the blockchain domain. #### Limited Number of State Machine Nodes To ensure efficient transaction processing, a finite number of state machine nodes are required at any given time. An excess of nodes may impede transaction speed. Managing a state machine demands specialized expertise beyond the capabilities of every miner. During the initial phase of the TEA Project, the core team will oversee all state machine nodes until the system achieves stability for public hosting. Meanwhile, community members can participate in the SEAT competition to share the state machine revenue. Each state machine node is associated with a SEAT, representing its financial status. The SEAT owner is entitled to all revenue generated by the node after covering its associated costs. #### Revenue Generation from State Machine Nodes Transactions submitted to the state machine incur a gas fee, dependent on their computation resource consumption. TApps storing data in the state are subject to a memory tax based on occupied data size and remaining free memory. Both gas fees and memory taxes are distributed evenly among active state machine nodes. {% hint style="info" %} The memory tax rate is not a flat rate; it varies based on the amount of remaining free memory. The less free memory available, the higher the tax rate applied. As more TApps utilize the limited state memory, the escalating cost serves as an incentive for TApp developers to optimize their memory usage. {% endhint %} #### Costs Associated with State Machine Nodes Running a state machine requires an Amazon Nitro machine, with rental fees paid in FDUSD to Amazon AWS. SEAT owners are responsible for covering these expenses during their ownership period. To ensure fairness among community members, a Harberger TAX, equivalent to 7% of a self-estimated price, is levied on each SEAT owner. This tax contributes to the DAO Reserve pool. ## SEAT Auction Individuals aspiring to own a SEAT can participate in the SEAT auction through the Harberger TApp. The highest bidder for a SEAT, determined by their self-estimated price, wins ownership during the next settlement window. Upon transfer of ownership, the new SEAT owner commences payment of AWS rental in FDUSD and the Harberger TAX, concurrently gaining access to revenue generated by the node. {% hint style="info" %} **Strategy** Owning a SEAT is a straightforward process, requiring no technical background. The primary adjustable element is the self-estimated price of the SEAT. * While offering a higher self-estimated price can safeguard your SEAT from competitors, it also results in a higher Harberger TAX. Remember, the Harberger TAX is fixed at 7% of your self-estimated price. * Regularly monitor your FDUSD balance, as the system's cron job transfers AWS rental FDUSD every few hours. If your balance is in overdraft, you will automatically lose the SEAT. Additionally, the SEAT's self-estimate price resets to 1 TEA. Notably, in this scenario, your SEAT will be forced to sell at the fixed price of 1 TEA, potentially lower than your initial purchase price. * Due to the Harberger TAX, owning a SEAT does not guarantee constant profitability. Intense competition for SEATs may drive up self-estimate prices to a level where the combined Harberger TAX and rental costs exceed revenue. In such cases, you have the option to lower your self-estimated price for someone else to take over or completely relinquish the SEAT. Surrendering your SEAT is equivalent to selling it at 1 TEA to the DAO Reserve account. * Regularly check the Harberger TApp; you might encounter excellent deals when someone inadvertently loses their SEAT due to overdraft, offering the SEAT at the minimal price of 1 TEA! {% endhint %} # User's manual ## Quick links: **System "out-of-box" TApps:** * [TEA Appstore-Account](/_2_user_manual/_1_tappstore_0_account) - The entry point to all other TApps, account page * [TEA Appstore-TApps list](/_2_user_manual/_1_tappstore_1_tapps) - The entry point to all other TApps. * [TEA Appstore-Investments](/_2_user_manual/_1_tappstore_2_investments) - The entry point to all bonding curve token investments. * [Harberger auction](/_2_user_manual/_2_harberger-auction) - Buy a **SEAT** share the revenue from state machines * [Seeds auction](/_2_user_manual/_3_seeds-auction) - Buy a CML Seed become a TEA hosting node miner * [TeaFluencer](/_2_user_manual/_4_teafluencer) - Earn some TEA credits by doing some task for KOLs * [Miner's portal](/_2_user_manual/_5_miners-portal) - Portal to TEA miners * [Developer's portal](/_2_user_manual/_6_developers-portal) - Portal to TEA application developers * [Leaderboard](/_2_user_manual/_7_leaderboard) - Join the TEA mining competition, see who wins the most **Community build "commercial" TApps** * [TEA Party](/_2_user_manual/_8_tea-party) - A zoom-like peer to peer video conferencing app that supports payment channel **Airdrop game** * [Togar3: the game for airdrop](/_2_user_manual/_9_togar3) ## TApplication on Web and Mobile TEA Applications, abbreviated as TApps, feature a user interface akin to conventional Web Apps. They can operate on both computer web browsers and the Metamask browser on mobile phones. While both the PC web and mobile web execute the same logic, the mobile version is customized to suit the smaller screen size. Consequently, you may need additional clicks for more details to be expanded. {% hint style="info" %} \*\* Running TApps with Metamask on Your Mobile Phone\*\* To run TApps on your smartphone, you must first install Metamask. While TApps can be loaded on a regular mobile web browser, the Metamask browser is currently the most stable option when your digital signature is required for login or payment. This stability is attributed to Metamask's built-in browser, where the TApp runs seamlessly, eliminating the need to switch to another mobile app for signature purposes. You are welcome to use any mobile browser to launch TApps, but if you encounter issues with Metamask signature, consider using the Metamask app instead. {% endhint %} ### UI size comparison Comparison of PC Web and Mobile UI ![Pasted image 20231212150437.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-0fe568a6e7009d7600f95e24b8b9e24a043712ba%2FPasted%20image%2020231212150437.png?alt=media) The PC Web interface (on the left) provides more detailed information compared to the mobile web interface (on the right). Users may need to click on a specific row to access additional detailed information. ### Metamask signature comparison On a PC, Metamask functions as a browser extension. When a TApp requires a user to sign a transaction, the Metamask extension will pop up. On mobile, the browser is a window within the Metamask app. To use a TApp, you must click the browser icon to switch to the browser window and then launch the TApp inside. When the TApp prompts the user to sign a transaction, Metamask will switch to the wallet window to complete the signing process. ![100](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-b650b07d98ace912ff1a7e1b512740e653ca20f5%2FPasted%20image%2020231212151010.png?alt=media) ## Entry point: Alpha is testnet, Beta is mainnet * is Alpha testnet entry point URL * is the mainnet entry point URL. {% hint style="info" %} **Why beta?** Beta.teaproject.org is **NOT** a testnet; it is the mainnet for the TEA Project. The usage of the domain name "beta" reflects the early stage of the TEA Project mainnet. The TEA Project core team is actively addressing bugs and implementing frequent improvements during this phase. Throughout this period, the TEA core team will manage all state machine nodes to facilitate fast and consistent upgrades. The profits generated by the state machine nodes are handled by SEAT owners, not the core team. We anticipate running under the "beta" domain for approximately 2 years. Once the system achieves stability and is deemed suitable for public use, the "beta" designation will be removed from the domain name. Regardless of its label as "beta" or "not a beta," it functions as the mainnet, and all tokens on Beta are indeed **real**. {% endhint %} {% tabs %} {% tab title="Phone" %} ![Pasted image 20231213101341.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-4ae19a6e1118a57c4c6b72eae952a46f746ff5f7%2FPasted%20image%2020231213101341.png?alt=media) {% endtab %} {% tab title="Web" %} ![Pasted image 20231213101502.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-32b04371d5c019ec8f8a95f8150770a2a3f5dfde%2FPasted%20image%2020231213101502.png?alt=media) {% endtab %} {% endtabs %} In the TEA Project, connecting to the Web 3 world requires selecting a **hosting node** as your designated **gateway**, distinguishing it from the conventional Web 2 approach. {% hint style="info" %} \*\* How can I select a hosting node? \*\*: Regardless of the hosting node you choose, you can expect nearly identical user experiences, as only those passing the **remote attestation** are featured on the list—ensuring security and reliability. However, each node may vary in performance and capability. Note the **market cap** column in the table, akin to the valuation of a publicly listed company (in this case, the node). Typically, nodes with superior performance garner higher profits, attracting more investors and thus achieving a higher market cap. The hosting list table is organized based on market cap rankings. If you have no specific preferences, opting for the top-ranked hosting nodes should suffice. Upon connecting to a hosting node, your gas fee becomes its revenue. The current billing model measures gas fees solely based on the consumption of executing code, irrespective of the hosting node. This model may evolve in the future to distribute workload based on available free memory or CPU usage. {% endhint %} Every row in this table represents a hosting node provided by a TEA miner. When you click and connect to a hosting node, you will be redirected to the TEA mini-runtime service running on that specific node. You may observe that the URL has changed in your browser's address bar. {% tabs %} {% tab title="Phone" %} ![Pasted image 20231213102240.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-33bc37027338acaaf56b4180af274cb88c4d24f9%2FPasted%20image%2020231213102240.png?alt=media) {% endtab %} {% tab title="Web" %} ![Pasted image 20231213102345.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-3ef1f5eb198c7c6d9dc5d7ced28706f97dec5b79%2FPasted%20image%2020231213102345.png?alt=media) {% endtab %} {% endtabs %} The IP address corresponds to the hosting node, while the lengthy hash in the screenshot, depicted as `mey32oBSYMPPjxYjeSCDwZsFM3m9SWodq25pLa9gy9cji`, is referred to as CID (Content ID) in the **IPFS** protocol. This CID represents the current hash of the **TAppStore** application's front-end code. It's important to note that this CID may change whenever the TAppStore undergoes an update. ## Common Login Features in Most TApps While each TApp has its unique characteristics, many share common features like login/logout. #### Before login {% tabs %} {% tab title="Phone" %} ![200](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-b829298fa828dbcdc88c33fe2fd73514ec581525%2FPasted%20image%2020231212175457.png?alt=media) If you are not logged in, the circled icon will appear as a login icon. The icon displayed on the header bar represents the current Metamask address/account connected to this page. To learn more about the Metamask connect feature, refer to [Metamask connect](/_2_user_manual/_b02_metamask-connect). {% endtab %} {% tab title="Web" %} If you are not logged in, you'll find the login button in the upper right corner. ![Pasted image 20231212180253.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-4f2ed611f2efa684b9d9e659a52ea650f7f40b88%2FPasted%20image%2020231212180253.png?alt=media) The address on the left is the currently connected address for this web page. For additional information about the Metamask connect feature, visit [Metamask connect](/_2_user_manual/_b02_metamask-connect). {% endtab %} {% endtabs %} #### Check auth list and sign Click on the login icon to review all necessary authentication steps. If you agree with all requested authorizations, proceed to sign this login transaction using Metamask's **sign** button. For more information about requested authorizations, refer to [TApp authorizations](/_2_user_manual/_b03_tapp-auth). {% tabs %} {% tab title="Phone" %} ![Pasted image 20231213095359.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-912c308080c64a4ce02b1f8364dcd297631e27eb%2FPasted%20image%2020231213095359.png?alt=media) **Note**: Alpha testnet has moved layer 1 to ETH **Sepolia** testnet from **Goerli** testnet. Beta mainnet uses ETH **mainnet**. Please double check your network selection. The screenshot was captured using Goerli testnet. {% endtab %} {% tab title="Web" %} ![Pasted image 20231212180550.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-188771b820742a01b4c4c9b4d90d8bff7de0b745%2FPasted%20image%2020231212180550.png?alt=media) ![Pasted image 20231213100458.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-4ba06a7f69509351d54b2f4da963ed6e2420a30a%2FPasted%20image%2020231213100458.png?alt=media) **Note**: Alpha testnet has moved layer 1 to ETH **Sepolia** testnet from **Goerli** testnet. Beta mainnet uses ETH **mainnet**. Please double check your network selection. The screenshot was captured using Goerli testnet. {% endtab %} {% endtabs %} #### After log in {% tabs %} {% tab title="Phone" %} Upon successful login, you will observe that the icon has changed to your wallet icon. ![200](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-0e021226155a361f8087c2547719570626a85949%2FPasted%20image%2020231212180106.png?alt=media) {% endtab %} {% tab title="Web" %} After successfully logging in, you will notice that the "login" button has changed to "log out." ![Pasted image 20231212210107.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-47b9e965cf478123c1d64f68c72a4664ee353431%2FPasted%20image%2020231212210107.png?alt=media) **Note**: The ERC20 address visible in the screenshot does not correspond to the actual TEA ERC20 address on the mainnet. The correct mainnet ERC20 address for the TEA token is **0x1d4Ab5E692C5E45Afe7646185a2d58A0E21cD3e9**. {% endtab %} {% endtabs %} ## Switching between tabs {% tabs %} {% tab title="Phone" %} Click the upper right corner menu button ![Pasted image 20231213121452.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-3590fb6600473e51071d5ec1a9a64cf160d1f3f6%2FPasted%20image%2020231213121452.png?alt=media) {% endtab %} {% tab title="Web" %} Switch between tab bar ![Pasted image 20231213121238.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-2d183993b11b99c4c65a9ff974fbfaf94279cdd5%2FPasted%20image%2020231213121238.png?alt=media) {% endtab %} {% endtabs %} # Tea AppStore - Account TAppStore serves as the gateway to all other apps within the TEA Project. Upon clicking the "Visit" button while selecting a hosting node, you are redirected to the TAppStore hosted on the chosen node. Within TAppStore, you can: * Transfer funds from Ethereum (layer1) to the TEA Project (layer2). * Move funds from TEA Project (layer2) to Ethereum (layer1). * Access and utilize various TApps available on the TEA Project platform. * Define spending limits for individual TApps. * Facilitate token transfers within the TEA Project ecosystem. * Engage in buying or selling activities related to bonding curve tokens for investment purposes. * Verify and unlock vesting TEA tokens if they are part of your holdings. * Retrieve information on your transaction history. * Export transaction details in JSON format for further analysis or record-keeping. * Review historical logs to track past activities and interactions. ## Account balances Upon logging into TAppStore, navigate to the "Account" tab located in the upper-right corner menu. For detailed information on login and logout procedures, refer to the [Login session of User's Manual](/_2_user_manual#common-login-features-in-most-tapps). ![Pasted image 20231213175051.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-ed4190477682e78d96c90fa30e1905867dc71430%2FPasted%20image%2020231213175051.png?alt=media) {% hint style="info" %} **Note**:The screenshot was captured during our alpha testnet phase. Please be aware that certain details may vary from the mainnet. * USDT has been replaced by FDUSD on the mainnet * The ERC20 address visible in the screenshot does not correspond to the actual TEA ERC20 address on the mainnet. The correct ERC20 address for the TEA token is **0x1d4Ab5E692C5E45Afe7646185a2d58A0E21cD3e9** {% endhint %} Within the **Account** page, you can review a list of current balances across different accounts. The displayed address (e.g., 0x4010...46c2 in the screenshot) corresponds to your current login address. **TEA balance (Chain):** Reflects your TEA balance on the Ethereum blockchain (layer1). These TEA tokens are ERC20 tokens usable in Ethereum but not directly within the TEA Project. Top-up to layer2 is necessary before utilizing them in TEA Project. By clicking the question mark, you can access the TEA token smart contract address on the Ethereum blockchain. Note: The screenshot depicts the Alpha testnet; the displayed address is not the actual TEA token smart contract on the mainnet. Avoid using the address shown in the screenshot to prevent potential loss of real tokens if not clear on this. **TEA balance:** Represents your layer2 TEA tokens, directly usable in all TApps running on the TEA Project platform. **TEA credit:** Denotes promotional credit that new users may receive from airdrops or market events. This credit can be used to pay gas fees during the bootstrap period. For more details about credit, refer to [Credit token](/_2_user_manual/_b01_credit-token). **TEA deposit:** Refers to the TEA deposit account, saving your mining deposit in TEA. This deposit is necessary when starting mining or owning a SEAT to cover harberger tax payments. **FDUSD deposit:** Indicates the FDUSD deposit account, storing your mining deposit in FDUSD. A FDUSD deposit is required only when you own a SEAT, and these funds are used to cover Amazon Nitro machine rental expenses. {% hint style="info" %} **State Sync and Delay:** The balance numbers displayed on the UI represent the actual figures from a few seconds ago. This slight delay occurs because the hosting node retrieves the latest ledger from the state machine every 10 seconds. On the PC Web page, you can observe the time indicating the update time, which may be up to 10 seconds behind your present time, as highlighted in the red block area in the screenshot below. Pasted image 20231213214123.png When you make any adjustments to your balance, there is a waiting period of up to 10 seconds before the changes reflect on the UI. However, for transactions involving the Ethereum blockchain, the delay could extend up to 15 minutes. If you initiate a withdrawal operation, kindly be patient and allow up to 10 to 15 minutes for the UI to update with the revised numbers. It will be finally appeared in the Chain wallet section, as illustrated in the screenshot above. **Note**:The screenshot was captured during our alpha testnet phase. Please be aware that USDT has been replace by FDUSD on the mainnet. {% endhint %} ## Transfer TEA You can transfer TEA token from your layer2 address to another layer2 address. If you want to transfer layer1 TEA token, you can use Metamask directly because it operates on Ethereum blockchain. ![Pasted image 20231216202517.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-fdf99ea0d19f23a344443fdf33be1ea779ed28a4%2FPasted%20image%2020231216202517.png?alt=media) {% hint style="info" %} **Understanding Layer1 and Layer2 in TEA Project:** The current iteration of TEA Project operates as layer2, built on the Ethereum blockchain as layer1. When you top up TEA tokens from Layer1 to Layer2, it essentially involves locking those TEA tokens in a **lock smart contract** on layer1, while an equivalent amount of TEA tokens is minted in your layer2 account. This approach offers substantial benefits, as tokens in layer2 can be processed more swiftly and at a lower cost. In the case of TEA Project, once your TEA tokens are transferred to layer2, you can leverage them to settle bills, cover gas fees, engage in gaming activities, invest in bonding curve tokens, and more—all at a significantly reduced cost and faster processing speed. Additionally, you retain the flexibility to withdraw these TEA tokens back to layer1 (Ethereum) at any time. {% endhint %} ## Transactions list Your recent transfer transactions are listed here: {% tabs %} {% tab title="Phone" %} ![Pasted image 20231216203622.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-5abc90140f7a7457f630bb86afad0ed6f11b0f60%2FPasted%20image%2020231216203622.png?alt=media) **Note**:The screenshot was captured during our alpha testnet phase. Please be aware that USDT has been replace by FDUSD on the mainnet. {% endtab %} {% tab title="Web" %} ![Pasted image 20231216202800.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-08f9bfef7e0be024d3c17d1ac0382a8b372a16a6%2FPasted%20image%2020231216202800.png?alt=media) **Note**:The screenshot was captured during our alpha testnet phase. Please be aware that USDT has been replace by FDUSD on the mainnet. {% endtab %} {% endtabs %} ## Export transaction detail to JSON text You can view and export the detail into JSON format {% tabs %} {% tab title="Phone" %} ![Pasted image 20231216203411.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-152e9039de663e399a33cbbf744554f4c00bdfb2%2FPasted%20image%2020231216203411.png?alt=media) {% endtab %} {% tab title="Web" %} ![Pasted image 20231216203135.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-b4c8bdda4dcdc6c2caf49441dfc81362a361c007%2FPasted%20image%2020231216203135.png?alt=media) ![Pasted image 20231216203150.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-76f8b0d9d68aef3816e63666d256cfd9d76cba98%2FPasted%20image%2020231216203150.png?alt=media) {% endtab %} {% endtabs %} In this example, the JSON text is: ``` { "txn_name": "transfer_tea", "address": "0x4010902c41b8e0bed8826c43fd309c70d36b46c2", "amount": "1000000000000000000", "tappIdB64": "0x9adc034a8c8447bba9b7f26902c900b858a187a6", "to": "0x03565F55F475f3E9601b448ca0c98e51Ed7a2e8E", "nonce": "15814803104851094826", "exec_ts": "1702787124932234478" } ``` This transaction is a "transfer\_tea" transaction. The sender "0x4010902c41b8e0bed8826c43fd309c70d36b46c2" transferred "1000000000000000000" (1 TEA = 1000000000000000000 Mocha, where Mocha is the smallest TEA unit) to "0x03565F55F475f3E9601b448ca0c98e51Ed7a2e8E". The nonce is a randomly generated number for security purposes. The transaction was executed at timestamp: "1702787124932234478" in UNIX time units. This JSON text can be used for verification of its existence using the "Query" explained below. ## Query transaction (in JSON format) You can provide the JSON text to anyone who wishes to confirm the existence of a transaction. This is particularly useful when transferring funds to a client. By sharing this JSON text, your client can verify that the transaction has indeed been executed within the TEA Project. When your client clicks the "Query Transaction" button and pastes the JSON text: ![Pasted image 20231216204126.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-3bb6b7627edb7b4ddb487afd0c593a435d061323%2FPasted%20image%2020231216204126.png?alt=media) A hash value is calculated from the JSON text, representing the unique identifier of the transaction: ![Pasted image 20231216204150.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-d7f01bd81f1b88422a6b6262df241e3326406ef2%2FPasted%20image%2020231216204150.png?alt=media) Your client has two options for verifying the transaction: * **Search from Memory:** Ideal for transactions executed within the last 30 minutes. This is the fastest and most cost-effective method for verification. * **Search from File:** Suitable for transactions executed more than 30 minutes ago. This search may be slower and more resource-intensive. ![Pasted image 20231216204537.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-765ab0a94b2db27dfd719d38a18ac083f865b8d8%2FPasted%20image%2020231216204537.png?alt=media) Upon obtaining the result, your client can confirm that the transaction you sent to them has indeed been executed. This verification process ensures transparency and reliability in the TEA Project transactions. ## Top up Top-up is an Ethereum (layer1) transaction that transfers your TEA or FDUSD (a ERC20 stable token) from your account to a TEA Project lock smart contract. After confirmation on the Ethereum chain, the TEA Project (layer2) will mint the equivalent amount of tokens into your layer2 account. Importantly, your layer1 and layer2 accounts share the same address. The duration of this operation varies, taking a few seconds to minutes depending on the congestion of the Ethereum blockchain. To complete this transaction, you'll need to sign it using Metamask. Once successfully executed, you'll observe your Chain wallet balance decrease (**first step**). Then, within approximately 10 seconds, your TApp Store wallet balance will increase(**second step**). Note that these two steps typically do not occur simultaneously, so there's no need for concern if you observe the first step without immediately seeing the second one. Just stay calm. ## Withdraw Withdrawal is the inverse of the Top-up operation, comprising two steps. Initially, the TEA Project (layer2) deducts the requested token amount, followed by the transfer of the same token quantity from the locked smart contract to your Ethereum (layer1) address. This operation will take even longer due to unpredictable Ethereum blockchain confirmation time. This process may take an extended duration (up to 15 minutes) to see the balance change in your Ethereum wallet, particularly due to the unpredictable confirmation time on the Ethereum blockchain. During the Withdrawal operation, as certain TEA miners cover the Ethereum gas fee for you, you will be obligated to pay this "Ethereum gas fee" to the miner. The exact amount is variable, contingent on the real-time exchange rate between TEA and ETH, calculated at the time of the transaction or queried from a preset value. ![Pasted image 20231216211554.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-7a96a4b05494cd479da2f2df92ee988f8f945c9c%2FPasted%20image%2020231216211554.png?alt=media) Upon confirming the value, it will be displayed before you proceed to "Confirm." ![Pasted image 20231216211743.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-dee205840b648c9440f0cccb44ede8247c4e521c%2FPasted%20image%2020231216211743.png?alt=media) In the provided screenshot, the value is 97 TEA, though this figure may differ during your withdrawal. Keep in mind that you are responsible for covering this fee. Following a successful Withdrawal, you can locate it in the Transaction list: ![Pasted image 20231216212036.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-b327e378cd60b16d76d10c613497cf3fb3aea9f4%2FPasted%20image%2020231216212036.png?alt=media) ## Log Log is a standalone tab which is not part of the **Account** tab. Whether triggered by your actions or automatic cron jobs, the majority of transactions associated with your account can be accessed in the Log tab. Whether triggered by your actions or automatic cron jobs, the majority of transactions associated with your account can be accessed in the Log tab. ![Pasted image 20231217153846.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-b28a608807553408512215cb7f54dd1f37b5ac33%2FPasted%20image%2020231217153846.png?alt=media) The logs are categorized by date (UTC). Due to space constraints on the hosting node, older logs may be removed to accommodate new ones. It is advisable to create your offline copy for reference. ## TEA Vesting Access to this tab is restricted to TEA Project Venture Capital Investors only. ![Pasted image 20231217153822.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-f726142a5c9e9727ceea1ebb09230113c4128355%2FPasted%20image%2020231217153822.png?alt=media) In accordance with your vesting schedule, a portion of your TEA tokens will be unlocked each month. To claim these tokens (TEA as ERC20)from the **Vesting smart contract** and transfer them to your own address, click the "unlock" option under the Release action. This process involves a layer1 (Ethereum) transaction, requiring you to sign the transaction using Metamask and cover the associated ETH gas fee for the Ethereum network. # Tea AppStore-TApps list ## List of TApps ![Pasted image 20231217155206.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-348069749a1fde227d39e0595a2a308e7bb23c2b%2FPasted%20image%2020231217155206.png?alt=media) Every [TApp](/_5_tapps) have an entry point in the TApps list. The **Token ID** corresponds to the [bonding curve token](/_3_token/bonding-curve-tokens) linked to this TApp. To invest in this TApp, you can acquire the TApp's bonding curve token through the [Investments tab](/_2_user_manual/_1_tappstore_2_investments). The **IPFS CID** column displays the CID (an IPFS concept for Content ID) representing the [hash](https://en.wikipedia.org/wiki/Hash_function) of this TApp's front-end code. While the concept of hash may seem complex for non-tech individuals, it's essential to understand this: If someone, like a hacker, stealthily modifies the code, the hash would markedly differ from the original. The hash serves as a means to verify that the code you are about to execute aligns with your expectations, offering a security measure against unauthorized alterations. ## Set spending limit To grasp the concept of a **Spending Limit**, please refer to the [TApps](/_5_tapps#tapps) section. If you attempt to launch a TApp before setting the spending limit, you will be prompted to establish one. Subsequently, you will need to return to the TApps list and relaunch the desired TApp. ![Pasted image 20231217155259.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-e1d5a9fa25c353a7d03bca47f058649fe0a9e923%2FPasted%20image%2020231217155259.png?alt=media) Exercise caution when setting the spending limit, ensuring it is a reasonable value. The spending limit serves to safeguard consumers from potential errors. Should a TApp attempt to exceed the spending limit you've set, the transaction will be rejected. There is one TApp for which you do not need to set a spending limit, and that is the TAppStore itself. ## Launching a TApp Once you have set an adequate spending limit for a TApp, click to launch it. For mobile users (Metamask browser), you may observe a "redirecting...." message between TAppStore and the TApp you are launching. This is normal; simply wait a few seconds, and the TApp will launch in your browser. Certain TApps are exclusively designed for web use. Attempting to launch them on a mobile device will result in an error message. Please utilize a computer to launch these specific TApps. ## Creating new TApp on Web The "Create new TApp" button enables you to generate a new bonding curve token using existing TApp templates. This feature is available only on computer web platforms. ![Pasted image 20231217145641.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-38a5b17883d0825a04a7e33f56a91dd0127d534d%2FPasted%20image%2020231217145641.png?alt=media) Complete the form to generate a new TApp along with its corresponding bonding curve token. Once submitted, this TApp will be included in the TApps list, and its associated bonding curve token will be featured in the **Investments** section, allowing others to invest in it. # Tea AppStore - Investments This tab serves as your all-in-one hub for overseeing your [bonding curve investments](/_3_token/bonding-curve-tokens). Effortlessly monitor, purchase, and sell your holdings, all within this user-friendly interface. ## Open investments tab {% tabs %} {% tab title="Phone" %} ![Pasted image 20231217152021.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-3451c1b7cdd6e8b258201dc6a534373f24a76971%2FPasted%20image%2020231217152021.png?alt=media) {% endtab %} {% tab title="Web" %} ![Pasted image 20231217152101.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-45c67754521c106351f1212b43b438466d91fca1%2FPasted%20image%2020231217152101.png?alt=media) {% endtab %} {% endtabs %} ## Buy / sell token ![Pasted image 20231217152326.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-1abbb895981ebe1064a4fd2098047cbe98b096df%2FPasted%20image%2020231217152326.png?alt=media) Begin by entering the quantity of tokens you intend to buy/sell, and the system will automatically calculate the corresponding amount of TEA tokens you will need to pay/receive. For a deeper understanding of bonding curves and their calculations, refer to [our wiki page on bonding curve calculation](https://github.com/tearust/teaproject/wiki/TApps-List#tapp-token-strategy) ![Pasted image 20231217152545.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-b9ddb3642cd447eec40a6979c51e6894c3e624cd%2FPasted%20image%2020231217152545.png?alt=media) In contrast to top-up/withdrawal operations that involve layer1 (Ethereum) and require time for confirmation, this transaction is conducted at layer2, providing swift execution in approximately 3 to 4 seconds. Note that, due to the delay in syncing up the hosting node state, you may observe changes in the account balance within the next 10 seconds. # Harberger auction In the ["Own Your SEAT" section of TEA Profitability document](/_1_ecosystem/7_profitability#become-a-state-maintainer-own-your-seat), we provided insights into generating profits through SEAT ownership. The SEAT auction process is facilitated through the application outlined in this guide. For a more comprehensive understanding of Harberger TAX and SEAT functionality, please refer to the [Harberger Auction section](/_5_tapps/tapps-core#harberger-auction). This article focuses exclusively on the user interface. ![Pasted image 20231217201119.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-7fe7d5672a359f92c5ba071b2da665c6ef1b1a6b%2FPasted%20image%2020231217201119.png?alt=media) The accompanying screenshot is sourced from the Alpha testnet, where currently only three SEATs are in operation. Please also be aware that USDT has been replace by FDUSD on the mainnet. ## Table columns * **ID:** The unique identifier assigned to the SEAT, starting from number 1. * **Owner:** The address of the current owner of this SEAT. * **Status:** Indicates whether the SEAT is currently active or pending (if someone is bidding). * **Self Estimated Price:** The price used to calculate Harberger tax. If this price is lower, someone else may pay a higher amount to acquire it. If the price is too high, the owner will need to pay a higher Harberger tax. * **Last Self Estimated Price:** If the SEAT's self-estimated price is changed, it will take effect after the next settlement period. This column shows the previous price. * **Last Price Change at:** Indicates when the SEAT's self-estimated price was last updated. * **Next Owner:** During a bidding process, the highest bidder on this SEAT will be displayed here. All settlements will be completed in the next settlement period. Before settlement, anyone can bid higher to take ownership. * **Sold Price:** The price at which the SEAT was last transferred. * **Sold At:** The timestamp of the last SEAT transfer. * **FDUSD Deposit:** All SEAT owners are required to maintain a FDUSD deposit for Amazon Nitro rental. Ensure timely top-ups; if the deposit runs out, the SEAT will be forced to be given up at a price of 1 TEA. * **TEA Deposit:** SEAT owners must maintain a TEA deposit for Harberger Tax. If the revenue can cover the Harberger Tax, no top-up is needed. However, if the revenue falls short, the owner should take note. If this deposit runs out, the SEAT will be forced to be given up at a price of 1 TEA. * **Miner Status:** Indicates the owner's mining status—active or offline. * **Action:** Detailed actions are described below. ## Action buttons Based on the screenshot, SEAT ID 1 and 3 are owned by others, hence only a "buy" button is available. However, SEAT ID 2 is owned by the current login user, revealing three additional action buttons for this user: * **Update Estimate Price:** Adjust the self-estimated price to outbid competitors with lower offers. You can also decrease the self-estimated price if the revenue is insufficient to cover the Harberger tax. * **Give Up SEAT Ownership:** Relinquishing ownership transfers the SEAT to the DAO Reserve immediately, halting FDUSD and SEAT deposit payments. * **Refill FDUSD Deposit:** Replenish the FDUSD deposit when the balance is low to maintain ownership of your SEAT. ## Next settlement period The settlement period lasts for 3 minutes within a 30-minute interval. Between two settlement periods, users can bid on SEATs or adjust their self-estimated prices. However, once the settlement period begins, no changes are permitted. The SEAT ownership is determined by the highest bidder during this period, and the payment and deposit transactions are transferred between the buyer and seller. ## Your SEAT is always on the market! In contrast to traditional markets where your assets are off-market by default, TEA Project's economic design keeps SEAT as a public asset. The SEAT remains continuously available for bidding, irrespective of its current owner. Anyone bidding at a higher offer can acquire it. To retain ownership and the associated revenue generated from the SEAT, the owner may need to self-estimate a higher price and pay a higher Harberger Tax. The Harberger Tax is directed to the DAO Reserve, benefiting all community members. # Seeds auction In the [Become a host node miner section of TEA Profitability document](/_1_ecosystem/7_profitability#become-a-hosting-node-miner), we provided insights into generating profits through hosting a node. The hosting node requires a CML seed to be planted for operation, and these CML seeds can be obtained through the [Seed Auction](/_5_tapps/tapps-core#seed-auction). ## Table columns ![Pasted image 20231217211414.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-2750a9226a999850344430c01782f22fd933f5e0%2FPasted%20image%2020231217211414.png?alt=media) * **Detail**: Click to view the properties of the CML NFT. * **CML Key**: The unique NFT ID (ERC721). * **Current Bid**: The present price of this seed. * **High Bidder**: The current leading bidder. * **End Time**: The auction concludes at this specified time. Any higher bid will extend this end time. If no higher bid is placed by this time, the current highest bidder secures ownership of the seed. * **Min Bid Price**: A new bid must surpass this minimum price. * **Status**: Designated as "New" if the seed is currently on bid, or "Sold" if the seed has been successfully sold. * **Sold At**: Indicates the time at which the seed was sold. * **Actions**: "Bid" to place a higher bid. After the **End Time**, the winner gains the option to "Claim" ownership. ## Rules During the bidding period, anyone can offer a bid higher than the **Min Bid Price** before the specified **End Time**. Each time a new higher bid is accepted, the **End Time** is extended by one hour. If no higher offer is placed before the **End Time**, the current highest bid prevails, securing ownership of the seed. # TEA Fluencer [TEAfluencer](/_5_tapps/teafluencer) Coming soon... # Miner's portal Please note this TApp has no mobile UI, you will need to use computer web browser to launch. Miners can oversee their machines and CMLs through this TApp. To commence mining, you'll require both a Machine ID and a CML. ## Machines The Machine ID serves as a unique identifier for the hardware engaged in mining. As of December 2023, TEA Project exclusively supports AWS Nitro hardware. As there is no means to extract the secured hardware ID from AWS Nitro, feel free to generate a random ID (a Hex string) for your machine, ensuring its uniqueness. ### Register machine id ![Pasted image 20231219114913.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-85fac2953762c9dd94c5a860fdfe1a1ceb7fee0b%2FPasted%20image%2020231219114913.png?alt=media) Ensure that the Machine ID consists of 64 hex characters preceded by the "0x" prefix. The total length should be 66 characters. ![Pasted image 20231219115012.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-357fd0a51845a80205ac44de2c0282b7270a2efc%2FPasted%20image%2020231219115012.png?alt=media) Once the new machine id is accepted, you can see your machine id in the list. ### Transfer machine You can be transferred to others. ![Pasted image 20231219115035.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-43cd322b7cbef2e5483832d8897591d69198cb5c%2FPasted%20image%2020231219115035.png?alt=media) ## Mining ### CMLs list Under "Mining" tab, you can find all your CMLs. ![Pasted image 20231219125553.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-eb0cf9eaf3c044657f9ac4080f76bdb8016939b8%2FPasted%20image%2020231219125553.png?alt=media) Click for more detail on your CML ![Pasted image 20231219125612.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-1cffad892658aa6e6cad378faba84154a7f7b3e2%2FPasted%20image%2020231219125612.png?alt=media) For more about CML NFT, please go to [CML mining token](/_3_token/cml-tokens) ### Actions There are three action buttons: * \*\* Plant\*\*: Plant this CML seed to an empty machine to start mining * **Unplant**: Stop mining, and remove the CML from the machine * **View miner's logs**: Review logs # Developer's portal This TApp lacks a mobile user interface; kindly utilize a computer web browser for access. The developer portal is tailored for developers to manage their applications and tokens. ![Pasted image 20231219130843.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-2f87ef81b0da46a09d5fbc9ab27d488a5885f64b%2FPasted%20image%2020231219130843.png?alt=media) Visit dev.teaproject.org to explore guidelines on developing TEA Applications. # Leader board Leaderboard will be retired when TEA Project mainnet (beta) launch. # TEA Party Coming soon... # Togar3 Game {% hint style="info" %} **Quick links**: * Alpha testnet TeaFlucner direct URL: * **To be launched** Beta mainnet TeaFluencer direct URL: [https://beta.teaproject.org/#/node/0/fluencer/go](/_2_user_manual/_9_togar3) Click **Enter game** button to the Togar3 game in Metamask {% endhint %} Togar3 stands for Tea Open agar.io for Web3. It is a web3 modified version of [agar.io game](https://en.wikipedia.org/wiki/Agar.io) based on [Ogar3](https://github.com/Faris90/Ogar3) open source project. {% embed url="" %} ## Togar3 as an Airdrop While Togar3 is a thrilling game experience, it also doubles as an innovative airdrop tool designed to distribute TEA tokens to our valued community members. Unlike traditional airdrops where token acquisition relies solely on chance, Togar3 offers a more engaging and interactive approach: * Forget passive drops: Instead of directly distributing TEA tokens, we airdrop "food" and "bots" within the game itself. Players then compete with each other and AI-controlled bots to collect this valuable in-game currency. * Food = value: Each piece of food functions as a "bonding-curve" token, (1 game token = 5000 food mass) meaning its value increases as more players acquire it. This creates a dynamic in-game economy where players can strategically collect and sell their food for TEA tokens on the TEA Project platform. * Unlock your TEA: Once you've accumulated TEA tokens, the possibilities are endless! Use them to cover gas fees, swap them for other ERC20 tokens on Uniswap, or explore the various utilities offered within the TEA ecosystem. With Togar3, airdrops become an exciting adventure, rewarding players for their skills and engagement within the game world. So, are you ready to join the fun and claim your share of the TEA bounty? Dive into Togar3 today! ## Tutorial ### Before you start Download Metamask: Togar3 is a TEA App, and all TEA Apps require Metamask to run. Follow the [instruction here](/_2_user_manual/_b02_metamask-connect) to install Metamask on your computer browser or iOS device (Android support coming soon!). Verify Metamask connection: Once you have Metamask installed, follow [look up account here](/_2_user_manual/_1_tappstore_0_account)d to verify it’s working correctly. If you are new to the TEA Project, read [TEA documents](https://docs.teaproject.org/_2_user_manual) to learn how to use TApps. The follow screenshot shows Togar3 loaded into Metamask on iPhone. [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-8213b827c18f8e1b36ea3c2130227dfe9302b920%2Fplay_togar3_in_metamask.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/play_togar3_in_metamask.png) ### Step 1: Land on the Tea Project Website Access the landing page: You likely learned about the Togar3 airdrop from a tweet. Follow the link to reach the landing page. Remember, this URL might change when Togar3 launches on the mainnet. Head to TeaFluencer: The landing page will guide you to the [TeaFluencer platform](https://alpha.teaproject.org/#/node/0/fluencer/go) * If you are testing in alpha testnet, the URL is * If you are playing in mainnet (beta), the URL is Please watch the short video below {% embed url="" %} ### Step 2: Complete the Game host's Task in TeaFluencer: * **Earn your food:** Watch the embedded video and complete the task (e.g., retweet a post) to earn 300 food(equv to 0.06 game token), the minimum requirement for the airdrop. You will need to login TeaFluencer app before run the task. [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-22c71aa002748a94442842d9ed6244be85bea3e8%2Fairdrop_alpha.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/airdrop_alpha.png) For detail of the task, and related game room, click anywhere in this row [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-8cf348244e03b56e2f0b5dc33f2e1ff1ca4675ea%2Fairdrop_alpha_detail.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/airdrop_alpha_detail.png) * **Retweet and Apply:** Click the "Visit" button to access the retweet task on Twitter. Use your Twitter account to retweet the specified post and copy the retweet URL. Paste the URL into the "Apply airdrop" section on the TeaFluencer page and confirm. [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-2869254dcfebc81bfdca1aae3c479d3124655213%2Fretweet_url_in_airdrop.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/retweet_url_in_airdrop.png) * **Enter the Game:** Once confirmed your work, [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-ff5e5f4331697ab364420ecb2c7a010f0bbb87fe%2Fenter_game_after_airdrop.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/enter_game_after_airdrop.png) click the "Enter game" button to launch the Togar3 game. ### Step 3: Play Togar3 and Claim Your Food **Airdrop notification:** Upon entering the game, you'll receive a notification confirming your successful airdrop and your 300 food balance. [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-e5290bcb515c80a020679ffacd69f21355f46d44%2Fairdrop_successful.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/airdrop_successful.png) * **Start playing:** Click "Join" to enter the game and begin your food-collecting adventure! * **How to play? What are the game rules?**, please continue [reading](#togar3-game-rules) ### Step4: Protect Your Food with Z-Transfer * **Save your progress:** While playing, press the "Z" key (on computers) or tap the "Transfer" button (on mobile) to transfer your collected mass to your game account. This ensures you don't lose everything if another player "eats" you. * **Check your balance:** Keep track of your progress by pressing "Esc" (on computers) or tapping the "Pause" button anytime during the game. [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-8e73974b1d8c53b81aa9daebb50a07b73af8c3f4%2Fgame_pause.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/game_pause.png) ### Step5: Unload Your Food and Claim Your TEA Tokens Remember, your game account is temporary storage. Once you leave the game, your saved mass automatically transfers to your TEA Project account, where you can claim your TEA tokens. That's it! You've successfully participated in the Togar3 airdrop and are well on your way to collecting valuable TEA tokens. Enjoy the game and explore the exciting possibilities of the TEA ecosystem! \*\*What am I gonna do with my game token? \*\*, please continue [reading](#sell-game-token-for-tea). ## Togar3 vs Ogar3 Comparing with web2 version Ogar, there are major improvements specificly designed for Web3 concepts: * Mass is money: Unlike Ogar3's score system, your mass in Togar3 represents real tokens with monetary value. * Solo play: While teaming isn't prevented, Togar3 focuses on individual competition. * Your Metamask address is your name. * Dynamic mass balance: Larger cells move faster but consume more food, losing the excess to the Food Bank. This bank generates new food when supplies dwindle. * Balanced entry fee: Players contribute 300 food (10 mass + 290 to the Food Bank) upon joining. Earning 290 mass breaks even, and the TeaFluencer airdrop covers this fee. * Z-transfer for safety: Press Z (or use the mobile transfer button) to save your mass to your bank account, protecting it even if you're eliminated. * Timed rounds and fresh starts: Each game session lasts 30 minutes per player, with a total round duration of 1 hour (subject to change). At the end, everyone keeps their earned tokens and a new round begins. ## Togar3 game rules and strategies ### Basic rules: **Dominate the Agar.io Food Chain** Agar.io is a brutal world where size reigns supreme. Imagine a microscopic food chain - the smaller you are, the more likely you become someone's lunch. But fear not, tiny morsel! With the right knowledge and cunning, you can climb the ranks and become the apex predator. **Know Your Enemies** * **Giants:** These lumbering behemoths pack a punch, but their slowness makes them sitting ducks. Avoid them unless you have a well-crafted plan (and maybe a few friends). * **Equals:** Locked in a stalemate? Size doesn't guarantee victory. Outsmart your opponent with clever maneuvering and strategic use of the arena. * **Viruses:** Spiky traps disguised as cells, viruses explode upon contact, sending large prey flying in bite-sized chunks. Use them wisely! **Size Matters** * **Growing Pains:** Bigger cells are like luxury yachts - powerful but slow. Remember, the bigger you are, the more energy you burn moving around. * **Tiny Terror:** Small cells are the nimble ninjas of Agar.io. They zip around effortlessly, consuming little energy, making them perfect for escapes and surprise attacks. **Master the Tools** * **Spike Launcher (W Key):** Feed mass to those spiky viruses. Once they reach a critical size, they explode, sending out deadly spikes. Lure larger enemies into these and watch them split into delicious snacks! * **Virus Hideout:** Smaller cells, rejoice! You can safely hide inside viruses, giving you a temporary shield from hungry giants. * **Cell Splitter (Space Key):** Feeling sluggish? Split your cell in two for a burst of speed, perfect for catching prey or escaping danger. Remember, though, smaller cells are easier to eat! **Remember** * **Don't Eat Viruses (if you're big):** It might seem tempting, but remember, viruses are like ticking time bombs for large cells. One bite and you'll be scattered across the map, predator turned prey. * **Split Strategically:** Splitting is a powerful tool, but use it wisely. Splitting for speed can help you catch smaller prey or escape danger, while splitting to consume can help you take down larger enemies. With these tips and a dash of practice, you'll be dominating the Togar3 food chain in no time! Remember, the key is to be adaptable, strategic, and maybe a little bit ruthless. So go forth, tiny cell, and conquer! **Some tips and strategies:** * **Maintain a Reasonable Size:** Growing too large can become costly in terms of movement. Sometimes, you might lose more mass than you can consume. Press Z to transfer excess mass to your game account to reduce size. This also enhances your movement speed, ensuring you retain some mass even after losing some. * **Split into Smaller Cells:** Splitting into smaller cells allows for faster movement and more efficient feeding, provided you feel safe. Consuming viruses causes your cell to divide, granting you additional mass (100 mass). * **Utilize Viruses for Protection:** Only larger cells are vulnerable to being split by viruses. If you're a smaller cell being pursued by a larger one, consider maneuvering near a virus to shield yourself from being consumed. **Time Limit for Each Round:** The Togar3 server undergoes a restart every few hours, signaling the start of a new round. Upon joining the game, you'll observe the remaining duration of the current round displayed in minutes. Additionally, every player is allotted a specific playtime limit, which can be monitored in the top left corner, indicating the remaining seconds. Failure to complete your round within the allocated time will prevent you from rejoining until the next server restart. Upon reaching the time limit, you'll be automatically logged out of the game. However, any remaining mass within your cells will be transferred to your game bank account, where it will be converted into "game tokens" for the TEA Project. These tokens can be redeemed and utilized in subsequent rounds. ## Sell game token for TEA You can utilize the [TAppStore Investment](/_2_user_manual/_1_tappstore_2_investments) platform to sell your game tokens to TEA. Subsequently, you can seamlessly swap these tokens for any other ERC20 token using the Uniswap protocol. [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-6237be839f19337d9d20cb216dc46dfe02d56947%2Fgame_token_in_investment.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/game_token_in_investment.png) ## Partial airdrop The price of the game token may soar to considerable heights, driven by sustained holding among players within the game. However, there's a ceiling on the airdrop distribution. Each airdrop is capped at a maximum of 1 TEA. Consequently, there's a possibility that players might receive less than 300 food (equivalent to 0.06 game tokens) during an airdrop if the token's value increases substantially. In such cases, players may opt to purchase additional game tokens from the [TAppStore investment page](/_2_user_manual/_1_tappstore_2_investments) or through exchanges with other players. ## Buy and load game token The game token follows the standard bonding curve model, and buying or selling these tokens is facilitated through the [TAppStore Investment Page](/_2_user_manual/_1_tappstore_2_investments). To utilize your game token within the game as food, you'll need to "load" it. The load button can be found on the TeaFluencer airdrop page. [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-22c71aa002748a94442842d9ed6244be85bea3e8%2Fairdrop_alpha.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/airdrop_alpha.png) Once you've loaded your tokens, switch to your Togar3 game. Within a few seconds, you'll receive a notification confirming the receipt of food. [![](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-e5290bcb515c80a020679ffacd69f21355f46d44%2Fairdrop_successful.png?alt=media)](https://github.com/tearust/teaproject/blob/master/docs/_2_user_manual/airdrop_successful.png) ## Understand game host The game host assumes a crucial role within the game ecosystem. In essence, the game room is owned and managed by the game host, who also creates the game token. Players receive airdrops by completing tasks designed by the game host. Furthermore, the game host deducts a percentage (Theta value) from every game token sold by players. The game host will undertake the following tasks: * Name a token (the remaining setup is automated). * Establish a game room (simply providing a name), utilizing the token created in the previous step as the game token. * Craft a tweet. Those who retweet this tweet will receive a minimum amount of the game token, enabling them to participate in the game and earn airdrops. * The TEA Project will regularly purchase the game token and compensate players who retweet. Additionally, the TEA Project will frequently distribute "food" and "bots" to the game, allowing human players to consume and increase their mass. * Human players exit the game with their accumulated mass, which is converted into game tokens and sold to the TEA Project as airdrop income. * The game host has the ability to buy and sell game tokens as well. These tokens operate on a bonding curve, with the price linked to the total supply. * The game host also earns a percentage from every token earned by players. # Credit token Coming soon. # Metamask connect Metamask necessitates that each account explicitly connects to a specific URL before authorizing the signing of messages. This precautionary measure is crucial in preventing web fraud. For instance, if a fraudulent website is created to mimic your banking system, Metamask will refrain from signing any transactions unless you consciously establish a connection with this deceptive URL. ## How TApp make Metamask connect safer? Each time you choose a different hosting node, the IP address segment of the URL will alter. Similarly, with every TApp upgrade or modification to the front-end code, the CID portion of the URL will change. Any such modifications result in the generation of a **new** URL. Consequently, it is imperative to explicitly reconnect in Metamask before utilizing the signing function. This design significantly bolsters the security of TApps beyond the standards set by typical Web 2 applications. For Web 2, in the event of a hacker compromising a server and tampering with the code, end users remain unaware of these changes as the URL remains unaltered. Nevertheless, any modification to the TApp code, resulting in a unique CID (essentially a hash of the code), triggers Metamask to no longer identify it as a "known" app. Consequently, users must undergo a new "connect" process to confirm their association with the updated application. ## How to connect? In Metamask, go to the account page and click "connect". ![Pasted image 20231212202946.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-b0b3b646239e4cef9e8432981729391343a44688%2FPasted%20image%2020231212202946.png?alt=media) If one of your accounts is not connected to a URL, Metamask may unexpectedly switch to another connected account. This less-than-ideal solution can occasionally lead to user confusion. Therefore, it is advisable to always verify that the displayed address in the UI precisely matches your intended login before proceeding. ![Pasted image 20231212213030.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-6ac362043520c46e4a6cfbea37aac9a0183bd513%2FPasted%20image%2020231212213030.png?alt=media) If the displayed address is not as expected, it is highly probable that your account has not been connected to this URL. # TApp authorizations When you login a TApp, a list of authorizations show what this TApp can do on behalf of you. Many TApps help you manage your assets or pay the bills. You do not need to sign to approve those transactions, given some of them may happen every few seconds. Once you reviewed the list and sign to login this TApp, the state machine will keep your authority active until you logout or session timeout. During this period, the TApp can send transactions on behalf of you. {% tabs %} {% tab title="Phone" %} ![Pasted image 20231213095359.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-912c308080c64a4ce02b1f8364dcd297631e27eb%2FPasted%20image%2020231213095359.png?alt=media) {% endtab %} {% tab title="Web" %} ![Pasted image 20231212180550.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-188771b820742a01b4c4c9b4d90d8bff7de0b745%2FPasted%20image%2020231212180550.png?alt=media) ![Pasted image 20231213100458.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-4ba06a7f69509351d54b2f4da963ed6e2420a30a%2FPasted%20image%2020231213100458.png?alt=media) {% endtab %} {% endtabs %} **TEA Project Guidelines for TApp Authorizations:** TEA Project operates as an open platform, allowing anyone to create a TApp. To safeguard end users from potential risks posed by unscrupulous developers, the TEA Project platform relies on login authorizations. It is crucial to review and comprehend the TApp's functionalities listed below before logging in. If any TApp appears to demand more permissions than necessary and makes you uncomfortable, refrain from logging in and express your concerns on our community forum to mitigate the risk of potential scams. ## **Permissions Overview:** ### 1. **Move:** The TApp can transfer layer2 TEA tokens from your account to others, with the total transfer amount not exceeding the predefined **spending limit** you set for this TApp. If you instruct this TApp to send funds to other accounts, ensure that this permission is checked. TAppStore needs the **move** feature to help you transfer fund to your friends. ### 2. **In-app Purchase:** Many TApps may require payment for certain features, adhering to the "no-free-lunch" principle in Web 3. Payments made are directed to the specific account associated with the TApp based on your usage. If you trust the app or developer, feel free to check this permission. TAppStore needs the **In-app Purchase** feature to help you pay for the usage. ### 3. **Manage Investment:** Some TApps facilitate investment management, enabling actions such as buying or selling bonding curve tokens. If you are familiar with and clear about these functionalities, you can check this permission. However, most TApps do not necessitate this feature. TAppStore needs the **Manage Investment** feature to allow you to buy / sell tokens. ### 4. **Withdraw:** Very few TApps request this feature, allowing the app to transfer your TEA tokens from TEA Project (layer2) to the Ethereum blockchain (layer1). Currently, TAppStore is the sole TApp requiring this feature. If you are unsure why an app needs this permission, it is advised not to check it. # Tokens The TEA Project's tokens are designed to incentivize behavior that rewards participants in the TEA ecosystem. We'll often discuss tokenomics when describing the various tokens in the TEA Project to help explain why we've designed the tokens the way that we did. {% hint style="info" %} The two main tokens of the TEA ecosystem are TEA and CML. {% endhint %} ### TEA Token **TEA** is a fungible ERC-20 token that's used as a utility token on the TEA platform. TEA is used to both pay gas fees as well as a payment token for using TApps. TEA has a 100M total supply and is not inflationary - no tokens will be minted beyond the initial genesis event. The pre-allocation of tokens follows a vesting schedule and will be allocated as follows: ![tea-token](https://user-images.githubusercontent.com/86096370/213342482-55b9be9b-2d01-44a2-a141-493d4b40e3a5.png) More information is available in our [TEA token section](/_3_token/tea-tokens) as well as our [tokens FAQ](/_3_token/faq-tokens). ### CML Token CML (Camellia) is an NFT token (ERC-721) that functions as a mining license on the TEA network. Miners plant a CML NFT into their mining machines to make it active on the TEA network. The supply of CML is determined via demand for computing resources on the network: more demand for computing resources would indicate a shortage of hosting nodes which would prompt the TEA DAO to issue more CML NFTs. More info on Camellia is available in our [CML token section](/_3_token/cml-tokens). ## Bonding Curve Tokens TEA token rewards for developers who deploy TApps and CML miners who run hosting nodes are paid out via bonding curve tokens. 1. An enduser pays a TApp usage fee and a gas fee to use a TApp. 2. The TApp usage fee goes to all of that TApp's bonding curve token holders. 3. The gas fee goes to all of the CML hosting node's bonding curve token holders. Note that there could be multiple CML nodes involved with running an enduser's transaction. In that case, the gas fee will be split among them according to how much their machines are utilized. These bonding curve token profits can be better visualized as the remaining profits after all ecosystem expenses are paid out: ![TEA\_Economy](https://user-images.githubusercontent.com/86096370/213603062-895dc8c3-f478-4d85-8e1e-5fb44832bd79.png) More info on TApp and CML miner tokens are available in our [bonding curve section](/_3_token/bonding-curve-tokens). # FAQ - Tokens The TEA token is an ERC20 token on the Ethereum network. TEA project is a layer-2 solution that will run above multiple blockchains (layer1) in the future though Ethereum will remain our primary layer-1 . ## Why is TEA considered a utility token? TEA tokens are a measure of how much computing resources are used for a computing task. For example, whn you click the "buy token" button in the TAppStore application, that sets off a series of computational tasks on many servers (we call them TEA nodes). These TEA nodes are run by our community members like you who we call miners. They need to get paid for providing such computing services for the enduser. TEA is the token we use to measure how much you need to pay them. This is similar to Ethereum's gas fee. ## What is COFFEE and why do community members earn it during the various Epochs? Prior to Epoch 12, the ERC20 toke COFFEE was 1:1 exchangeable to USD. That was because at that time it was a USD reward given to community testers. Beginning with Epoch 12, COFFEE is no longer exchangeable to USD. It's instead used to exchange to mainnet TEA when the mainnet launches. In other words, you can use the COFFEE you earn today to buy mainnet TEA tokens as if you were using USD. COFFEE is our community voting token used in the [Governance-Structure](/_z_faq/governance-structure). When the mainnet launches, every user's COFFEE will give them voting power towards deciding on governance issues. We have not decided on the name of the actual voting token that users can exchange their COFFEE towards. It may be called a "reputation" or "contribution" token. In order to get more mainnet TEA and higher voting power in DAO voting, a user should get as much COFFEE as possible during the Epochs. Once mainnet launches, then there will be other ways to earn this voting token not tied to COFFEE. ## Are the TEA and CML in the contest epochs real tokens? No, they're part of the simulation. CML and TEA during the competition should be thought of as "testnet CML" and "testnet TEA" which have no relation to mainnet CML or TEA. Even though these two coins are fictitious for the purposes of our mining contest, the testnet TEA that contestants earn during the contest will be exchanged for COFFEE during the epochs. The COFFEE can be exchanged for real TEA after the mainnet launches. ## TEA Project Tokenomics TEA Projects uses many new economic innovations in our tokenomics design. To name a few: 1. The use of a [Harberger tax](https://teaproject.medium.com/proposal-using-a-harberger-tax-in-the-global-state-machine-4323976f9b8) to allocate state maintainer seats. 2. [The bonding curve](/_3_token/bonding-curve-tokens) to control the price and supply of TApp and CML node tokens. 3. Because the TEA Project has no limit on block size, most TApps only incur a negligible gas fee from the enduser's perspective. More information on how our [gas fee is calculated](https://teaproject.medium.com/the-importance-of-the-tea-utility-token-ccf006f62ca9) can be found in our blog. # Bonding Curve Tokens A bonding curve is a mathematical concept used to describe the relationship between price and the supply of an asset. As supply in the bonding curve increases, the price also has a commensurate increase. The TEA Project features two types of investment tokens issued on bonding curves: * A TApp uses bonding curves to issue their [TApp tokens](/_3_token/bonding-curve-tokens/tapp-tokens). * A CML node will also issue separate [CML bonding curve tokens](/_3_token/bonding-curve-tokens/cml-mining-tokens). These are investable tokens that may be purchased from the **Investments** tab in the TEA browser wallet as explained further [here](/_3_token/bonding-curve-tokens/tapps-tokens-list). The bonding curve tokens have a [theta %](/_3_token/bonding-curve-tokens/bonding-curve-theta) associated with them as well as [supply & demand values](/_3_token/bonding-curve-tokens/tapp-token-supply-and-demand) that are determined by a curve. ![Bonding-Curve](https://user-images.githubusercontent.com/86096370/167538641-45c498a2-7ab1-428a-9ecd-b37a051bb9d2.png) # Bonding Curve Theta **Theta** is the percent of every token buy or consume event that's used to fund the development of the TApp. If **theta** is set at .2 (20%), then 1 - .20 = .8 is used to fund the sell side of the bonding curve (80%). The smaller the number for **theta**, the closer the buy and sell prices are on the bonding curve. For example, a **theta** value of .05 (5%) would mean the sell price is always at 95% of the buy price. But a small **theta** has drawbacks to the creator as they will get less of every buy and consume event. ## Theta as TApp / CML Creator Note that the TApp or CML creator receive the **theta** percentage of whatever funds enter into the bonding curve. When a user creating a TApp or CML token spends TEA for the initial funding, they'll receive **theta** % back in their wallet (e.g. if **theta** is 30% and the initial funding is quoted as 1000T, the user will receive 300T back in your wallet for a net cost of 700T. You will still need to have the entire quoted amount available in your wallet, and you'll receive the **theta** % back as part of the transaction. A large **theta** of, for example, .4 (40%) may seem like a good deal for the creator. They'll receive a large share of every bonding curve buy/consume event directly into their wallet. But a large **theta** makes it less attractive for token holders as they'll get proportionally less tokens as a dividend on buy and consume events. Additionally, the sell curve will always be below the buy price by 40%, resulting in a possible scenario where nobody wants to invest in the TApp's token. Such a large **theta** value will force investors to wait a long time to ever be profitable. ## Theta determines spread between a TApp / CML token's buy and sell price An investor buys at a TApp or CML token's buy price and sells at its sell price. An investor who buys 100T worth of a TApp (or CML) token with a theta of .2 (20%) has 80T go to fund the bonding curve and 20T going to the developer (or miner) Mathematically, the sell price is always (1 - theta) \* (buy price) anywhere along the bonding curve. # CML Miner Tokens Buying the bonding curve tokens of a hosting CML mining node is a way for users to earn a share of mining revenue without having to setup a mining machine. Each active hosting CML mining machine will have its own bonding curve token associated with it. Owning a miner's bonding curve token entitles the holder to earn a percentage of that miner's rewards in the form of token dividends. TEA token mining rewards come from public service rewards and from the gas fees paid by users to CML node operators when the TApp they use accesses these particular nodes. In addition to earning dividends, hosting CML token holders will also benefit from the price appreciation of the token itself. Mining stake tokens are issued on a bonding curve, which means that the price of the token increases as the supply increases. As TEA mining rewards are earned, the net percentage after the miner takes their share [(the theta %)](/_3_token/bonding-curve-tokens/bonding-curve-theta) is injected into the CML token's bonding curve. This results in an increase in the number of CML bonding curve tokens which are distributed proportionally as a dividend to existing staking token holders. # TApp Token Supply & Demand ## Bonding Curve Tokens One possible avenue for an enduser to increase the size of assets in their wallet is to become an investor of TApp or CML tokens. These tokens are issued on a bonding curve and increase in value the more people invest in them. Stated differently, price is correlated with supply. In addition to buys and sells of bonding curve tokens, consume actions will also influence the price of both TApp and CML tokens. 1. When an enduser pays to use a TApp, that payment goes as a consume action into the TApp's bonding curve token. Each holder receives a token dividend based on their holdings and the price increases as supply has increased. 2. When an enduser pays to use a CML host, that payment goes as a consume action into the CML's bonding curve token. Each holder receives a token dividend based on their holdings and the price increases as supply has increased. These consume actions are always net of the [bonding curve theta](/_3_token/bonding-curve-tokens/bonding-curve-theta) for both TApp and CML tokens. The bonding curve will be in constant changing as long as there are buy/sell events on the token as well as consume actions originating from the entity that the token represents. For example, every buy and consume event will make the price (and supply) increase by a bit. ## TApp Token Strategy Using your TEA to invest in the bonding curve of TApps is one way to participate in the growth of the TEA ecosystem as exemplified by its apps. If you invest in a popular TApp or often-used CML node, it'll make much more than just holding onto the TEA. As more people buy the TApp or CML token, then the the market cap of your bonding curve token will increase. This represents a gain in value for all token holders. Conversely, a net sell of TApp or CML bonding curve tokens will reduce the overall market cap as well as the actual price of the tokens. ## TApp Tokens in Wallet Expand on Consume Actions > Why do my tokens keep increasing in value even when no one has bought anymore? This is the magic of the bonding curve. The TEA project uses what's called an augmented bonding curve. It supports both "consume" and "expense" actions. Your token supply will increase when there are consume actions for the TApp and decrease when there are expense actions coming from the TApp. #### Consume Action When a consumer spends (pays for usage) of a TApp, the TEA they spend is paid into this TApp's operational account. Since the consumer has used the service in exchange for TEA, their transaction is completed. The TEA they spend on the TApp is used to buy its TApp token. These newly minted tokens will then be distributed to all token holders, and that is how your token balance increases. Because the person who paid to use the TApp has already received the service already, they won't receive any newly minted tokens for their transaction. Investors who own a TApp's token are stakeholders in that app. They're like stock holders own some percentage of the project and receive a dividend every time the TApp is used. # TApp and CML Tokens The Bonding curve tokens shows on [\_1\_TAppStore\_2\_Investments](/_2_user_manual/_1_tappstore_2_investments) are all of the TApps and CMLs on the platform. You will see the **TApp Name** and the **Ticker** symbol for the TApp. There are four other columns showing the price and supply of any particular token: ![Screen Shot 2021-08-31 at 5 03 45 PM](https://user-images.githubusercontent.com/86096370/131926213-62236847-6304-48d9-9a3a-2dc659f241df.png) ## Total supply > Total number of tokens currently circulating for the TApp. *Every TApp has an initial supply once the TApp starts on the platform. How come the supply keeps going up? And why does it sometimes go down?* Many actions can influence the supply of a TApp's token supply: * Anyone using the TApp executes a **consume** action that buys and mints tokens on the bonding curve. A portion of the funds goes to the developer while the amount used to fund the reserve, those tokens get distributed to existing token holders. * Anyone directly **buying** tokens on the bonding curve increases the token supply. * Anyone **selling** their tokens to the bonding curve causes that amount of tokens to be removed from the supply. The money comes directly from the reserve that funds the bonding curve. ## Buy price > Price at which you can buy the token from the bonding curve. *How is the price related to the token supply?* Starting in epoch 3, we use the basic bonding curve of ![](https://miro.medium.com/max/176/1*mKaQYJBvAdLHfjbKZHNBzQ.png) where **y** is the price and **x** is the supply. The constant **a** is 1 for the buying curve, 0.7 for the selling curve. The integral ![](https://miro.medium.com/max/174/1*o1np50lmOCanIu-5fcWZPw.png) is used to calculate the TEA amount for the funding pool and the reserve pool. ## Sell price > Price at which you can sell the token into the bonding curve. *The bonding curve doesn't need another party to buy when I want to sell my token. What exact mechanism is sending me TEA when I sell the TApp token?* Unlike traditional order book marketplaces, you don’t need a buyer when you sell your investment token. You’re actually selling it to the bonding curve. The selling price is based on the predefined rule that **the selling curve is 70% of the buying curve**. If you buy a token and sell it immediately you’ll lose 30%. The 30% goes to the TApps owners’ funding pool. ![](https://miro.medium.com/max/700/1*eqhPz8WnHke67DY3sU9P-w.png) ## Market cap > The current sell price multiplied by the number of tokens outstanding. The market cap for a bonding curve is calculated as **tokens outstanding** x **sell price of token**. This result gives you the exact amount of funds in total that are in the reserve of the bonding curve. # TApp Tokens Each TApp has a token associated with it that's issued along a bonding curve, and buying a TApp's token is just like staking to it. Using TEA to "stake" to a TApp is just like owning stock in a TApp. When a user stakes their TEA in a TApp in return for its TApp token, they can then earn financial benefits in a couple of ways: 1. The TApp token itself is issued along a bonding curve. As supply increases, the price increases with it. 2. As consumers use the TApp, a consume action injects TEA into a TApp, only some of which goes to the developer. The rest of the TEA is exchanged for the TApp's tokens and then distributed proportionally to the TApp token holders. TApp tokens play an important role in the TEA Project ecosystem as it helps developers bootstrap their projects by enticing investors and other interested users to purchase its TApp token in the hopes of price appreciation (with the developer getting a share of every purchase). ## Bonding curve mechanism When we say that TApp tokens are issued along a bonding curve, that gives a mathematical formula correlating the total TApp token supply and its price, e.g. **price = sqrt(supply)**. ![Bonding-Curve](https://user-images.githubusercontent.com/86096370/167538641-45c498a2-7ab1-428a-9ecd-b37a051bb9d2.png) You'll notice in the graph above that there are two curves which determine a buy and a sell price. The difference between these two curves comes from the value of **theta**, which is the percentage of every bonding curve augmentation (increase) that goes directly to the developer. Theta can be thought of as the amount of every token purchase or consume action that goes to the TApp developer. Someone who buys a TApp token and then immediately sells it will only get (1-theta) \* (TEA amount they used to purchase TApp tokens), which is exactly what the two curves are depicting. It's important to note that while the buy curve is hypothetically what one would pay if they were to purchase a TApp token, the sell curve shows you exactly how much TEA is underlying one TApp token at that supply level. This means that the TEA really is locked in the bonding curve, and selling TApp tokens into a bonding curve essentially releases the underlying TEA while burning the supply of the TApp token. The sell action will also lower the TApp token price along the bonding curve. Mathematically, the sell price is always (1 - theta) \* (buy price) anywhere along the bonding curve. ## Consume action Each time a TApp is used it initiates a consume action. The developer gets their share (**theta**) of the TEA entering the bonding curve, and the rest of the consume revenue is converted to TApp tokens and distributed proportionally to TApp token holders. This is considered the dividend reward for being a TApp token holder. Because consume actions introduce a new supply of TApp tokens minted along the bonding curve, this means that not only will TApp token holders earn dividends, their token values will also go up at the same time. ## Developers are paid from the bonding curve, not directly from consumers Although it might make sense to think that a developer gets paid when consumers use their TApp, that's not technically correct. The developers aren't technically paid until the TEA enters the TApp token bonding curve through either consumers using the TApp or investors purchasing its token. You can say that developers are rewarded for both the utility their app brings to consumers and for any bullishness in the eyes of investors. Developers always gets their **theta** percentage share anytime TEA tokens enter the bonding curve. Let's take a look at the two scenarios where money enters the bonding curve: #### 1. If an investor purchases TApp tokens, * theta (%) of the purchase amount goes to the developer. * the rest of the TEA goes to mint TApp tokens which go to the wallet of the user who purchased the TApp token. #### 2. If a consumer uses the TApp, * theta (%) of the TEA the consumer uses goes to the developer. * The new tokens generated by this injection of TEA doesn't go to the consumer of the TApp - they already got the TApp's utility since that's what they paid for. But TEA is being injected into the bonding curve which creates new TApp tokens, and these tokens have to go somewhere. These newly minted TApp tokens are distributed proportionally as dividends to existing TApp token holders. # CML Tokens Unlike TEA tokens, CML (Camellia) is an NFT (non-fungible token) and also functions as a special software license. Each CML has a different lifecycle just as each tree is different in nature. After a miner purchases frozen CML, they must wait for it to defrost to mine with it. Once their CML is defrosted, the miner can plant the CML into a mining machine to start mining to harvest TEA tokens. ## Mechanics of utilizing CML tokens The primary use case for CML is to run a hosting node on the TEA network. Prospective miners should keep in mind the following aspects of CML tokens. * CML are purchased at auction using the [Seed Auction TApp](/_3_token/cml-tokens/marketplace-auctions). The total available supply of CML up for auction is dependent on demand for computing resources in the TEA network since CML hosting nodes provide TEA's compute infrastructure. As consumer demand for infrastructure exceeds supply, then more CML seeds will be made available for auction algorithmically by the TEA DAO. * CML is planted into machines to activate them as hosting nodes for the TEA Project. The process of getting a hosting node online is covered in our [mining section](https://github.com/tearust/teaproject/blob/master/docs/_3_token/_mining/README.md). * CML has a lifespan of approximately 2 years after which it dies. If a miner still wishes to host a node after their planted CML dies then they'll need to purchase a new CML seed. * If a miner wants to move their CML to a new machine, then they can follow the [CML migration guide](/_3_token/cml-tokens/cml-migration-transfer). ## Profitability of CML mining End users wishing to use TApps pay a gas fee to the CML miners who host the nodes. The revenue paid to CML miners does not go directly to their wallets. The revenue flow instead goes into a **CML miner token** that's unique to each CML miner. This token is issued on a [bonding curve](https://github.com/tearust/teaproject/blob/master/docs/_3_token/cml-tokens/_3_token/bonding-curve-tokens/README.md) where supply and price is correlated. Let's step through a real life example to see how this would play out. 1. An enduser access to **CML 11** and uses **TApp 1**. He pays both an app usage fee (paid to the TApp's bonding curve token) and a gas fee (paid to the bonding curve tokens of CML miners used during the process execution.) 2. Both **CML 11** and \*\*TApp 1 \*\* have bonding curve tokens associated with them named, respectively, **CML-11** and \**TApp\_1*. 3. The gas payment is paid in TEA proportionally to all **CML\_11** token holders based on the Bonding Curve rules. So does the app usage fee to the **TApp\_1** bonding curve and shared to all bonding curve users. 4. The TEA is injected into these two bonding curve tokens which creates an increased in the supply of both of the tokens. 5. Owners of **CML\_11** and **TApp\_1** tokens all get issued these surplus tokens. If they want to sell the token at this higher price, they will receive the capital gain. From the above chain of events, we can deduce that being a CML miner is profitable according to what percentage of their CML's bonding curve token they own. The larger percentage they own, they more they'll get of every gas transaction that uses their mining hardware for running tasks. # CML Transfers The **Migrate miner** button is used to move a CML tree to a new machine. This might be because there's been a change to the physical mining machine (hardware failure or perhaps a cloud provider is proving unreliable). The migration function allows the user to plant the CML tree into a different machine and continue mining. Note that before migrating, the mining machine with the CML to be transferred must be shut down first. The CML could also be unplanted first to avoid any offline penalties but this is up to the user to decide. Users can click on the CML ID in their wallet to show the CML detail screen. The following buttons near the top include: ![camellia\_options](https://user-images.githubusercontent.com/86096370/141043047-731de60f-3fca-4f28-9cd7-76733de77be7.png) The two buttons useful for migrating a CML are the following: * **Migrate miner** - Use this button to migrate your CML to a new machine (e.g. your old machine provider has unreliable uptime). The machine will have to be shut down first before this button becomes active. * **Shut down miner** - Shut down an active miner before beginning the migration process. ## The CML Migration Process After shutting down your mining CML, click **Migrate miner**. You'll be presented with this screen: ![Screen Shot 2021-11-10 at 7 53 42 PM](https://user-images.githubusercontent.com/86096370/141234158-35ee8e52-b8bb-4847-b95c-a067838e16d6.png) This is the same process you have to do when planting a CML. Run the script to get the **machine id** and **layer1 account** (Polkadot address), then click **Next step**. The dialog will require 3 items to be filled out besides the CML ID: ![Screen Shot 2021-11-09 at 3 23 49 PM](https://user-images.githubusercontent.com/86096370/141022713-6a11754d-e7c5-41b4-a513-7104c1253d98.png) * The **Machine ID** and **Polkadot wallet (SS88) address** are copied from the last step. * The **Miner IP** is from the new machine you are transferring to. Moving onto the final **Migrate** step, you'll have to copy the shell script command and run it on the terminal of your new mining machine. After the script has finished running (the terminal output finishes with a `docker start completed` message), click the **Migrate** button. ![Screenshot from 2021-11-10 20-02-59](https://user-images.githubusercontent.com/86096370/141237062-55f42031-3ba0-42df-9fff-9f3ab89cc754.png) And don't forget to start up your miner after you're done migrating. ## CML transfer for marketplace sales The owner of a CML is the only one who can commit a migrate transaction for it. If the CML is sold, only the new owner can trigger the migration event. The new owner runs the migrate command to bring their newly bought CML to their own machine. If the new buyer doesn't migrate the CML to their own hardware, the previous owner (seller) will continue earning revenue from this CML as long as they keep their machine running. So when the new owner issues a **Shut down miner** command, they're really stopping the CML from mining on the machine and not physically shutting down the mining hardware. # CML Seed Auctions Miners who wish to deploy a node on the TEA Project ecosystem will need to plant a Camellia (CML) NFT into their mining machines. These act as mining licenses for the mining nodes and record important metadata about the node's hardware, the Camellia's age, its credit history, and the machine's capabilities. Most miners will be interested in purchasing a hosting CML which will allow them to host TApps on the network. ## Every CML has a lifespan Every Camellia NFT has a life cycle: it’s born from a seed, grows into a tree, and then eventually dies over a span of approximately 2 years. The productivity of the CML will follow this timeline as well: it's not very productive in the beginning of its life. But as it grows up, it becomes more productive and generates larger amounts of revenue. When the Camellia gets older and starts approaching the 2 year mark, its productivity drops. Eventually, it will reach the end of its life cycle and die. Miners will then need to buy a new Camellia seed and plant it into their machine to start over from the very beginning. ## Determinants of CML supply There will be a cap of 10,000 CML during the first two years of the ecosystem. Any limits beyond that will be determined by a DAO governance vote. The supply of tokens released to be sold on the marketplace through auction is determined algorithmically by the DAO. If there are many idle miners on the network, then demand is relatively low and no new seeds will be released to the marketplace. Conversely, if there's no slack in the system and network miners are near their hosting capacity, then more CML seeds will be released for auction in an effort to bring more hosting nodes online to host TApps. ## CML seeds are purchased through an open auction CML is purchased through an open auction process where the DAO (or individual users) list their seeds for sale at their desired price. The TEA Application for CML seeds auction is [\_3\_Seeds Auction](/_2_user_manual/_3_seeds-auction) # TEA Tokens TEA tokens are the primary utility token for the TEA Project. TEA is used as gas on the TEA network and is necessary for signing transactions. TEA is also the currency that's exchanged by consumers in order to use TApps. TEA can be purchased on Ethereum's layer-1 and shuttled [between Layer1 & Layer2](/_3_token/tea-tokens/billing-system-between-layer1-layer2). The total supply of TEA tokens is 100 million. ## How to Obtain TEA Tokens #### Testnet The TEA Fluencer TApp can be used as a retweet faucet (through Twitter) to secure some testnet TEA to compete in the contest. #### Mainnet After mainnet has launched, users will be able to use decentralized exchanges on Ethereum to purchase TEA tokens. Liquidity on centralized exchanges have not yet been formalized. # Billing-system-between-layer1-layer2 *this is being reworked* To illustrate how the topup system works, let's imagine an enduser named Bob wants to play a TApp game. Bob has TEA tokens in his layer1 Ethereum wallet but needs to move those TEA tokens up to his layer2 wallet so they can be accessible by the game. Bob uses the **Topup** button in his TEA browser wallet account page to move 30T (out of 100T) up to layer2. Bob’s layer2 wallet now shows: **Total balance: 100T** > Deposit: 30T Available: 70T If Bob changes his mind before playing the game, he can exit the game and get his 30T deposit back which goes back to his layer2 account. If Bob spent 20T to play this game, the 20T would go to the **consumed account** and Bob’s layer2 wallet now shows: **Total balance: 80T** > Deposit: 10T Available: 70T The **consumed account** collects all the players’ consumed TEA for this game. Within a certain amount of time (e.g. 1 hour or 1 day), the consumed account will transfer all TEA in its account back to layer1 and distribute them into this game’s bonding curve. ### How does this process work in the backend? * In layer 1, Bob has both a layer1 account and a locked account. * In layer2, there are the following: * * A hidden system account * * Bob’s layer2 account * * The game’s deposit account * * The game's consumed account Please be aware that all layer2 accounts are for this game only. Therefore, each TApp has its own set of layer2 accounts. When Bob clicks TOP-UP, this is what happens in the backend: * His TEA goes into a locked account in layer1. * The hidden system account in layer2 is able to observe what’s going on those locked accounts. Once it sees 100T put into a locked account, the hidden system account will transfer 100T to Bob’s layer2 account. (Bob’s layer 1 and layer2 accounts share the same address). * When Bob clicks DEPOSIT in the game's interface, his 30T will be transferred to the deposit account. * * If Bob changes his mind and exits the game, 30T will be refunded to Bob's layer2 account. Bob may click WITHDRAW and all 100T will go to the hidden account and sent back to Bob’s layer1 account. * Any TEA Bob pays for playing the game will be transferred to the consumed account. Within a certain amount of time(e.g. one hour), the consumed account transfers all TEA collected to the TApp’s bonding curve on layer1. # Mining TEA Project uses the terms **mining** and **running a hosting node** interchangeably. The TEA network's [TApps](https://github.com/tearust/teaproject/blob/master/docs/_4_mining/_5_tapps/README.md) run on hosting nodes that are controlled by individual miners on the TEA ecosystem. Any particular TApp may use multiple hosting nodes in the process of carrying out the computing tasks required by a TApp. Interested miners can start hosting a node on the TEA network by [purchasing a CML NFT](/_3_token/cml-tokens/marketplace-auctions) and planting it into a compatible machine. Given that our machines require a hardware security module, GPS, and a publicly-accessible IP, [AWS Nitro](https://aws.amazon.com/ec2/nitro/) are the first machines that meet our requirement and are currently accessible to the public. During our previous testing epochs, miners were allowed to run simulated nodes using DigitalOcean droplets. But since Alpha release, digital ocean VM is **no longer allowed**. Miners are paid a gas fee by end-users who use the miners' machines when they wish to run a TApp. CML hosting nodes are chosen algorithmically based on many factors including uptime, computing power, and any special hardware that a particular TApp might use. In addition to gas fees, CML hosting miners are paid for a public service they perform called [remote attestation](/_4_mining/remote-attestation). More information on the CML hosting profitability is available in our [hosting profitability guide](/_4_mining/hosting_profitability) Besides hosting TApps, community members can also participate in [helping run TEA's state maintainer nodes](/_4_mining/state-maintainer-nodes). For further questions on mining, please [consult our mining FAQ](/_4_mining/faq-mining) or contact us [in our Telegram channel](https://t.me/teaprojectorg). ## Knowledges prerequisites * Create AWS account * Basic TEA operation on Web. Starting with alpha.teaproject.org. * Know basic operation on CML seed auction, Miner's portal. * Know how to check log in TAppStore ## Installation steps * Make sure you connect to ETH mainnet * Ask TEA dev team for at least 100 T as a startup fund * Go to **Seed auction tapp** to buy a CML seed. If there is no seed available, you will need to ask the TEA Dev Team or for the next day when new seems coming up * Contact TEA Dev Team, provide your own Metamask testing address, ask for a machine\_id * Follow the instruction at ## Verification on your work * You should see the CML seeds you owned in CML seeds auction tApp. * Go to Miner's portal app to verify your node is up running. * Go to alpha.teaproject.org, you should see your node besides the CML0. * If all above works as expected, your node is up running * After a few hours, check the account balance in TAppStore. If anything wrong, go to the TAppStore check logs ## Hosting node software updates, failed to do so will cause "offline" * When there is a new update on the Hosting node software, there will be an announcement in TEA telegram. * It is your responsibility to read the announcement and follow the instruction to update your nodes. Mostly just running a scripts similar to what you did when install at the first time * If you failed to do the update, after a few hours / days, your node will be removed from the "active list". The status should look like "offline" in alpha.teaproject.org. You may see this too in the Miner's Portal TApp. * If your node is "offline", users cannot access to your node and you will not earn income until it is updated and get "online" again. * There would be a delay between your finish the update of your node and your node appear "online". It may be half hour to one hour delay. * The CID of your node URL is actually the version. You can verify the CID in your node's URL to match the CID of CML0. CML0 is maintained by TEA Dev Team, it is always up to date. # FAQ - Mining ## How to get started as a miner? *Latest update in Jan, 2024* TEA Project mainnet soft launch in Jan, 2024. Please read [\_4\_mining/README](/_4_mining) and [Mining-With-AWS](/_4_mining/mining-with-aws) to understand how the mainnet TEA mining goes. ## Do I need a Raspberry Pi to mine? *Latest update in Jan, 2024* TEA Project mainnet soft launch in Jan, 2024. TEA mining exclusively supports AWS Nitro as the designated secure hardware. For detailed information, refer to [Mining-With-AWS](/_4_mining/mining-with-aws). ## What can I do with a CML? CML is an NFT of the TEA Project that serves as a mining license. When users choose your CML node to host a TApp they want to use, you'll earn revenue in the form of the gas fee the end-user pays to run the TApp on your node. Note that after planting into a mining machine, each CML will have a life span of approximately 2 weeks during the testnet epochs. This is an accelerated schedule specifically for the testnet as mainnet CML will have a lifespan of approximately 2 years. ## Why isn't my planted CML listed on beta.teaproject.org? There might be many reasons, but first make sure you followed all the instructions. One step that's sometimes missed is the "create entity" step after you plant your CML. If you don't create an entity, there's no way to pay you. Your entity is similar to a company owned by you that accepts your clients' payments. ## Why does my planted CML have a "pending" status? Your node is in pending status because other TEA nodes have tried and failed in contacting your node to verify its integrity. This process is called "remote attestation", or RA for short. There might be many reasons that cause it to fail. The most common reason is that your server ports are not open to the public internet. We have a [troubleshooting guide](/_4_mining/mining-required-open-ports) you can consult to help resolve this sort of issue. The solution may be simple or complicated. Some users mistakenly turn on Ubuntu Firewall (ufw), or it could be that your cloud service provider blocks all ports by default. Sometimes the fix is as simple as restarting the TEA docker services. But to find out you'll have to go step by step through the troubleshooting guide to diagnose the issue. ## How many CML will be launched on the mainnet? There will be an initial limit of 10k CML for the first two years after mainnet launch. The supply of CML will be controlled algorithmically by the DAO according to supply and demand after year 2. After the mainnet starts, the DAO will start to generate CML seeds and put them into the marketplace for auction. ## Do I need to do anything special to run RA? RA (remote attestation) is mandatory for all TEA nodes. Anytime you run an active TEA node, it will run RA automatically. Of course, you'll get paid by running such a public service. There's no way for an active node to stop doing RA. ## Is there another option besides running CML nodes? If you're not a technical person and don't how to navigate the linux command line, you can go to [Harberger TApp](/_2_user_manual/_2_harberger-auction) to "rent" a **state maintainer seat**. You'll earn your income because the state maintainer nodes do the state maintaining work for the public, and you'll be the owner at least temporarily for as long as you're the high bidder for the seat. ## Can you elaborate on what kinds of services I can provide to earn TEA? There are two kinds of services, public services and private services. Public services are paid by the DAO of the TEA Project. Those services benefit all members of our community, so we have to pay them from our DAO treasury or reserve account. The typical public service is RA (Remote Attestation). The RA is for public security, similar to security guards that protect commercial properties from crime. Since you cannot find a single payer for these kind of public services, the DAO will pay this fee. "Private services" are a different kind of service that mostly run TApps or functions for community members (the endusers). Endusers will access your TEA node and run some code on it. It consumes your computing resources and the endusers pay you for using your node. Some of the private services are paid by the TApp owners (developers) instead of the enduser. This is common when the Tapp developers have some kind of business model to earn indirectly from endusers, e.g. advertisements. As long as you provide some kind of service, someone (DAO, end user, or tapp developer) will ultimately pay you. ## How are computing resources measured? Similar to how Amazon calculates computing costs, we compute how much CPU instructions, memory usage, network traffic etc. are used during computational tasks. We've also learned from how Ethereum uses gas (such as using gas limits to prevent DDoS attacks) to provide safeguards in a decentralized compute environment. Generally speaking, the more complicated the task is that you run, the more you pay. If you don't have enough funds to pay at runtime, your task may be interrupted and dropped in the middle of execution. ## Can I move my CML license to a new machine? You can move your CML license using the [CML transfer option](https://github.com/tearust/teaproject/wiki/CML-Migration-\(Transfer\)). # Mining: Required Open Ports **Note**: most people will just need to [restart services](#restart-services) to fix their issue. Your CML node will require the following ports to be open in order to be an active host on the TEA network: * 4001 * 5001 * 5998 * 8000 * 8080 If you notice your node is not listed as active on the [active miner list](https://wallet.teaproject.org), then here are some steps to troubleshoot. ### Check That Required Ports Are Open You can check which ports are open on your machine using a tool like `nmap` (you may need to install it first): * `nmap localhost` Or `lsof`: * `lsof -i -P -n | grep LISTEN` Make sure that the required ports mentioned above are all open. If you need to check if a specific port is open, you can use the following command: `sudo netstat -plnt | grep 8000` The above checks on port 8000. ### Restart Services If your ports are not open, then you can restart the necessary services for your node by restarting Docker: ``` cd ~/delegator-resources docker-compose start ``` In general, you'd use `docker-compose down` to stop your Docker container and `docker-compose up -d` to start it Note that all necessary services will be down if you reboot your server so you'll need to restart services after every reboot. ### Check That Open Ports Are Reachable Even if you have the required ports open on your server they may not be reachable. We're going to use a public port checker to test if your server is reachable on port 8000. You can use any port checking service like * Enter your IP address and check port 8000. We choose port 8000 because even though the TEA Project's remote attestation process is conducted across multiple ports, usually if one port is unreachable then all of them are. So we just test port 8000. If you want to use an internal tool and have nmap installed, you can also check if your server is reachable using the following command: `nmap -p 8000 your_droplet_IP_address` The above command checks port 8000, and `your_droplet_IP_address` should be replaced with your droplet's actual IP address. If the service shows your server is unreachable then you should check if a firewall is active on your server. ### Checking for an Active Firewall Let's first rule out that DigitalOcean themselves have installed a firewall by checking that it isn't enabled. You can find this in your dashboard: ![Screenshot 2022-12-02 at 9 50 26 AM](https://user-images.githubusercontent.com/86096370/205355076-397c03c8-ef7a-4cd9-b0c1-4c666fb9beac.png) The next possibility is that you or the Ubuntu template you're using has installed a firewall. The most popular Ubuntu firewall is `ufw`. To check if it's installed, use the following command: `sudo ufw status` If it returns an `Active` status, then you have two choices: either stop ufw completely, or delete the rules that are blocking the necessary ports. ### Ufw Option 1: Stop the Service To stop the ufw firewall, issue the following command: `sudo ufw disable` ### Ufw Option 2: Delete Blocking Rules You can also delete any rules blocking the necessary ports through the following procedure. 1. First list the active rules along with line numbers: `sudo ufw status numbered` 2. You can delete any rules blocking a necessary port using the following command: `sudo ufw delete {line-#-of-rule}` where `{line-#-of-rule}` is replaced by the line number of the offending rule. For example, `sudo ufw delete 2` to delete the second rule. ### Checking Your Tweaks Note that some templates for Ubuntu will have different services installed depending on the version number. After each of the steps above, you should go back to the external port checker (such as ) and see if your changes have any effect. If the above steps don't solve the issue, we'd recommend opening a ticket with DigitalOcean and they can help further troubleshoot. ## Addendum: Ports Needed by Each Service ### IPFS * 4001 * 5001 * 8080 ### OrbitDB * Same as IPFS ### Adapter * 8000 ### Client * 5998 # Mining With AWS Nitro ## Create IAM Policy First you'll need to create a new IAM Policy to allow the use of the KMS key to only be used inside the enclave. Open the "IAM -> Policies" page, and then click the "Create Policy" button to load the create policy page. You'll next select the "JSON" tab and paste the following json configs: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey", "kms:GenerateRandom" ], "Resource": "arn:aws:kms:*:580177110170:key/f66b0a1b-28c7-49a1-82c8-70094dd7e45b" } ] } ``` After creatiing the policy you should see a new policy like this: ![图片](https://user-images.githubusercontent.com/3713930/227701234-367b10f5-7f96-4b4c-b8ed-bd2143b2b62c.png) For more information please read [the AWS docs](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html#cross-account-key-policy). ## Create Role Open the "IAM -> Roles" page and click the "Create role" button to create a new IAM role, then select the first box: ![图片](https://user-images.githubusercontent.com/3713930/227701503-3d264683-71b7-4f72-a317-02c50b29db72.png) In the second step you can input "key" as a word filter to make it easier to find and select the following two policies: * "AWSKeyManagementServicePowerUser" * The IAM policy we created earlier ![图片](https://user-images.githubusercontent.com/3713930/227701664-21289a5b-d6d8-4188-bdf9-a5db7b91d230.png) Finally, enter the new role name and remember it for future use. ## Prepare the security group Select the "EC2 -> Security Groups" page and choose a security group you want to modify (or create a new one). You'll need to add the following inbound rules: ![图片](https://user-images.githubusercontent.com/3713930/227702350-e21d191f-cd1e-49ec-90b9-1b40172775ce.png) These input ports will be filtered after the node is started. ## Create an EC2 instance With the preliminary steps out of the way, we can now setup our EC2 instance. First select the region you want your EC2 instance to be deployed to. ![图片](https://user-images.githubusercontent.com/3713930/227702512-8949e24c-c23f-478d-ad66-73246fe9d09e.png) In the above image you can see that the "Asia Pacific (Seoul)" region was chosen with the region code "ap-northeast-2". Please keep this region code in mind because this code will be used as the last parameter in the "install" and "start" scripts below. To ensure a successful instance launch, follow the setup instructions below： 1. Choose the "Amazon Linux" OS (DO NOT use the default "Amazon Linux 2023 AMI" option): ![图片](https://user-images.githubusercontent.com/3713930/231627468-46034243-0e71-4ffc-b663-b4ab5028235c.png) 2. Choose an instance type that supports nitro. We'll use the "c5a.xlarge": ![图片](https://user-images.githubusercontent.com/3713930/231720559-6664f7b3-9f25-4901-b0f4-6867ade67bea.png) 3. Use the security group we updated (created) earlier: ![图片](https://user-images.githubusercontent.com/3713930/227703076-21f6153f-3d7d-40ab-b902-1f073b8f9ea1.png) 4. (optional) It's better to increase the volume size from 8G to 30G: ![图片](https://user-images.githubusercontent.com/3713930/227703175-778599fa-5b13-4c66-974e-64eceb7995f8.png) 5. In the "Advanced details" tab, use the IAM role we created above: ![图片](https://user-images.githubusercontent.com/3713930/227703322-136398dc-28fb-48b2-b7c9-964ef45ba595.png) 6. In the "advanced details" tab set "Nitro Enclave" as enabled: ![图片](https://user-images.githubusercontent.com/3713930/227703431-d6763256-b3a3-4d08-a86a-42856cf824b7.png) After successfully launching the EC2 instance, you can access it via ssh and proceed with the next steps of the tutorial. ## Use EC2 instance to run a node ## Initial install First you'll need to prepare the TEA node dependencies which should take about 10 minutes. Please note that the following preparations need only be completed once before starting the node for the first time. Before running the next few scripts you should have a Machine\_ID registered to your ETH address. You can contact us [on Telegram](https://t.me/teaprojectorg) to get a Machine\_ID. Run the following command to start or update to the newest TEA software version: ``` bash -c "$(curl -H "Cache-Control: no-cache" -fsSL https://raw.githubusercontent.com/tearust/nitro-build/main/install.sh)" ``` Or using the following command without prompting (replace the Machine\_ID and wallet\_ID with your own values): ``` bash -c "$(curl -H "Cache-Control: no-cache" -fsSL https://raw.githubusercontent.com/tearust/nitro-build/main/install.sh)" "" "0x0000000000000000000000000000000000000000000000000000000000000000" "0xbd6D4f56b59e45ed25c52Eab7EFf2c626e083db9" "ap-northeast-2" ``` The above command uses the region code of `ap-northeast-2` but you should change this according to the region you use (i.e. an Oregon server will have a `us-west-2` region code). ## Start Make sure you're in. the working directory of the "nitro-build" folder created automatically in the preparation step. If not, then navigate to that folder: ``` cd ~/nitro-build ``` Then simply run the following script to start the node with parts both inside and outside the enclave using the same Machine\_ID and wallet\_address you used during the install process. For example, if `0x0000000000000000000000000000000000000000000000000000000000000000` was the Machine\_ID and `0xbd6D4f56b59e45ed25c52Eab7EFf2c626e083db9` was the wallet address: ``` ./start.sh "0x0000000000000000000000000000000000000000000000000000000000000000" "0xbd6D4f56b59e45ed25c52Eab7EFf2c626e083db9" "ap-northeast-2" ``` The above command uses the region code of `ap-northeast-2` but you should change this according to the region you used for your EC2 instance. ## Plant the CML You can now visit the Nitro TApp Store to purchase a CML and plant it inside your machine. 1. Go to the [Nitro TApp Store](http://54.180.82.194:8080/ipfs/QmPvqjPJ8wmc7KwFZY1y6vZLeRRhMF56yrmdMTe3NCeF2m) and click on the **TApps** tab. 2. If you don't have a CML, you can bid for one in the **Seed Auction** TApp. The CML seed will be available one hour after the last placed bid. 3. After you've claimed your CML, you can plant it into your AWS machine using the **Miner Portal**. During the planting process, select the same Machine\_ID that you used to setup your AWS node as well as your AWS node's IP address. You can find your node's IP address in your AWS console: ![Screenshot 2023-04-18 at 3 37 58 PM](https://user-images.githubusercontent.com/86096370/232939399-67ca0075-af8b-4cb6-852d-3891441b430c.png) 4. After you're done planting, your node is ready to host TApps. # Mining with own hardware is not available on the mainnet (Q1, 2024) As of Q1, 2024, TEA mining exclusively supports AWS Nitro as the designated secure hardware. For detailed information, refer to [Mining-With-AWS](/_4_mining/mining-with-aws). We welcome collaboration with hardware designers and manufacturers. Once new secure hardware becomes available, this document will be promptly updated. # Hosting Profitability Miners deploy their mining machines on the TEA network to earn profit. To start earning on the network, miners will need the following: * A AWS Nitro machine. The TEA Project runs on AWS Nitro at the time of mainnet launch * A CML NFT. Camellia (CML) NFTs are needed as a mining license to activate mining nodes. Miners interested in hosting TApps will purchase a B CML. These are purchased through CML auctions, an open process where winning bids are taken in TEA (which is burned) in exchange for CML. ## How miners determine the potential revenue? In the TEA Project, we use the terms "mining" and "running a node" interchangeably. There are three types of mining available: * State machine maintainer mining. Running a state maintainer node helps maintain the TEA Project's state machine. These miners pay a Harberger Tax for the privilege of running a state maintainer node and earns revenue from the memory tax paid by TApps. For more detail please go to [Harberger Auction TApp](/_2_user_manual/_2_harberger-auction) * CML TApp hosting mining. When a user says they want to mine on the TEA Project, they will probably be running a hosting node. # Remote Attestation Unlike other blockchain projects that waste lots of computing power in consensus competitions, the TEA project uses all of its computing power in useful tasks. The majority of them are commercial task which are, of course, paid by the clients benefitting from running them. A minority of them are public validation or DAO governance taks. These proportionally small number of tasks are not paid out by any specific client. Rather, they would have to be paid by the DAO as these are public services. Some of these tasks might include state machine maintenance or rewards for DAO governance, but the most important public service task is **remote attestation**. Remote attestation is the process whereby CML hosting nodes verify the integrity of other peer CML nodes. The remote attestation process relies on randomly selected peer nodes to perform the verification process. Once the candidate node passes remote attestation from its peers, it’s considered a trustable CML hosting node on the network. The trustability of each hosting node in the TEA network is crucial for our implementation of trusted decentralized cloud computing. All computational work including decryptions are processed inside the hardware TPM-protected secure modules within the hosting CML nodes. The TPM monitors the entire CML miner's hardware, and all critical security evidence is stored in TPM as proof of trust data (PoT). The PoT will be sent to the layer-1 blockchain (Ethereum) for remote attestation by other VRF selected “known good” CML hosting nodes. The consensus of whether any particular node is trustable is done at the blockchain layer. The clients only need to query the layer-1 blockchain to verify that the PoT is posted in a valid block so that they can trust the correctness of the computing result done within that CML hosting node. ## Remote Attestation - technical details TEA's philosophy is that if the compute environment can be trusted, then the computing result can be trusted. The TEA Project verifies the integrity of its layer-2 nodes by leveraging blockchain for consensus. Specifically, an Etherum smart contract specific to the layer-1 communicates with TEA’s layer-2 nodes. The smart contract relays the trustability of the nodes on layer-2 when the nodes perform remote attestation to prove their trustability to each other. Every CML node that performs computation inside of its TPM will return the result along with its PoT data. Because there's PoT data, everyone can verify its compute result and the process can be trusted by remote attestation. ![Screenshot 2023-02-01 at 9 53 06 AM](https://user-images.githubusercontent.com/86096370/216123643-64f94630-7b16-4809-8138-c957c3e74010.png) DApps running on TEA’s layer-2 can run full-stack, full-speed as the ubiquity of trustable nodes means TEA can use non-traditional consensus on its layer-2. The truth comes from the TPM and the blockchain. Any component that doesn’t match what’s claimed will be detected and the offending node will be forced offline. # State Maintainer Nodes TEA's state machine is collectively run by a special group of machines known as the **state maintainer nodes**. TApps can store their current state by paying a memory tax that's shared among the state maintainer node operators. This memory tax together with TApp state transaction fees and a state subscription fee that some CML nodes pay comprise the state maintainers' total revenue. ![TEA\_Economy](https://user-images.githubusercontent.com/86096370/213603062-895dc8c3-f478-4d85-8e1e-5fb44832bd79.png) Instead of CML, miners wishing to become state maintainers must secure licenses that are administered under a Harberger Tax. This taxation scheme is taken as a percentage of each state maintainer's self-assessed valuation. 1. State maintainer licenses are available through open bidding within the Harberger Auction TApp. 2. The state maintainer seat holders set a self-valuation of the worth of their seat license. 3. The Harberger Tax collected from these state maintainers is equal to a percentage of this self-valuation price which is set independently by each state maintainer. 4. This price is also the price which anyone can buy the seat away from the existing state maintainer seat holder. Any of the state maintainer seat licenses can be purchased away from the existing maintainers by bidding 1T higher than the self-valuation price listed in the Harberger Auction TApp. This presents a Harberger Tax dilemma for each seat holder: price it too low and the seat will be purchased away from them. Price it too high and they’ll have to pay a larger tax burden. More information on revenue and expenses is available in our core TApps article: [TApps-Core](/_5_tapps/tapps-core). # TApps TApps are rich decentralized applications that run on the TEA network. Due to the TEA Project's unique two layer architecture, TApps are able to run at cloud computing speeds while being hosted on distributed TEA mining nodes. TApps are coded in WebAssembly and securely interact with customer data in TPM-protected trusted enclaves. From the end-users perspective, two steps are needed before deploying any TApp for use: 1. A spending limit for the TApp must be set. This ensures that a TApp can't spend more than what you've allocated for that TApp. As money is spent in the TApp, the spending limit is reduced. In this way it functions like an allowance that can be spent, with the end-user able to bump it up at any time. 2. A node must be selected to run the TApp. Because of TEA's architecture, TApps are "hosted" in IPFS waiting for deployment. Because IPFS is just storage, the node that the end-user requests will download the compiled TApp binary from IPFS and execute in the node together with any data that the end-user provides. The list of available TApps is available through the [TAppStore](/_2_user_manual/_1_tappstore_1_tapps). Developers interested in coding and deploying their own TApps can reference the following resources: * [Developer methodology](/_5_tapps/developers) introduces some important concepts for developers new to developing for the TEA ecosystem. It also discusses the TEA tech stack, including WebAssembly and IPFS. * [Creating a TApp](/_5_tapps/tapps-creating-a-tapp) shows how to deploy a TApp to the TEA Project once it's been compiled to WebAssembly format. * [TEA-Billing](/_5_tapps/tea-billing) is the base document with information and related links for understanding TEA's billing system. You can learn more about other concepts involved with TApps by visiting the [TApps FAQ](/_5_tapps/faq-tapps). # Developers The TEA Project allows developers to earn from publishing their code either as standalone apps or as libraries. That means devs can simply publish an API without needing to develop a UI or budget for business development and marketing. Code doesn't have to be open sourced as is the current web2 model for ad-hoc libraries that are usually published to Github and may get some donations. ## Micropayments make it easier for devs to get paid TEA has an open tokenomics model where no one gets a free lunch. Any actions in the TEA network needs to be paid by someone, and nobody works for free. Miners get paid through every line of code that runs through their CPU/GPU/TPU, occupies RAM / hard disk space, or transfers data using their network. Developers get paid by every time their code is executed. Consumers need to pay for whatever service they receive. Those micropayments can be done at an extremely low cost. That is one of the major benefits of TEA's layer-2 solution. Compared with ETH, it's **almost** free, and extremely fast. ## Trust and security protect your profit You don't have to open-source your project if you're uploading it to the TEA Project. Your code can be close-sourced if you don't need to be audited for security reasons. You only need to send your code to the TEA Project where it will be sent to a node's trusted enclave. Your code will be compiled there and run inside the enclave. No one can steal your code, and the execution environment can always be trusted. Any miner can host your code and run it; there's no need to send your code to your clients to run or to maintain a server on your own. All these aspects of the business are handled by the TEA Project. ## Web3 applications are composed of all these smaller API-as-a-Service modules In web 2.0, you'll have to open-source your code as a library so that other developers can use it **for free or by donation** in their own project. The unfortunate fact is that open-source contributors earn much less than they possibly could by going the donation route. In the TEA Project, all these components are just API functions, running inside one or more mining machines. Applications don't **include** this code in its own binary, but directly **call** these APIs and are paid for its usage by the billing system. The code developer gets paid in TEA tokens from the billing system periodically. ## Pay by use is the new business model Just like today's internet is a large set of links to different webpages hosted on different servers, Web3 applications would also consist of a bunch of links to different API calls underneath the facade of the app. The full application could be composed by thousands of those smaller components that are written by different developers. They're all **linked** instead of **included (as in open-source libraries)**. Pay by use becomes the new business model. ## Developer links and more info * Our [dev docs](https://dev.teaproject.org) will be the main resource for developers. We also have a step by step [tutorial for building a TApp](https://dev.teaproject.org/020_tutorial). * [TEA app developers compile to WebAssembly](https://medium.com/@teaproject/tea-and-webassembly-89991a83bbd1) which allows devs to code in their preferred language before compiling to WASM. * Developers will also want to familiarize themselves with how the [bonding curve works](/_3_token/bonding-curve-tokens/tapp-token-supply-and-demand), in particular the [theta percentage](/_3_token/bonding-curve-tokens/bonding-curve-theta) that goes directly to developers. Open-source technologies used by the TEA Project include: * IPFS * Substrate * WebAssembly * Wasmer, Wasmtime * Parsec * NixOS * WolfTPM * Nats service * Technical framework language: 90% Rust, 5% GoLang, 5% JS. # FAQ - TApps ## What are TApps? Decentralized apps (dApps) are known as **TApps** in the TEA ecosystem. Each TApp has a token associated with it that's issued on a bonding curve, a mechanism that rewards its token holders as the supply of the TApp token increases. ## What types of apps can the TEA Project support, what languages etc? The apps that run in the TEA Project are called TApps. TApps are nothing but WebAssembly functions plus Javascript front end code with possibly some SQL scripts included. TApps don't impose any limits with regard to the programming language that developers can use. All major modern programing languages are currently supported by WebAssembly. TApps are not smart contracts, which means that developers don't need to learn Solidity or write "smart contracts". All they need is the same tools they used to write web and mobile apps, and even SQL is supported. ## Are TApps EVM Compatible? TApps are not based on smart contracts and therefore dvelopers don't need to build their apps with EVM-compatability in mind. If the developer needs to send a txn or listen to events from any EVM, it can still do so using the existing EVM API from Infura. TEA Project itself has built-in EVM API but it's not currently open to public use. If developers want to topup / withdraw an ERC20 token from / to ETH or any other EVM blockchain, they can call the API directly without any additional code. This is how the TAppStore's **Topup** and **Withdraw** functions work. ## Can you run asynchronous code across multiple compute environments, or does code run and work locally only? A more detailed answer to this question can be found in the ["developer" section of Teaproject.org](https://teaproject.org/doc/#/doc_list/get_started.md). To give a quick answer, a developer will need to write two kinds of functions: 1. Functions that run in a host node similar to how web2 code runs in a web server 2. Functions that run in the state machine, similar to web2 code runs inside a database (stored procedures). Neither the developer or anyone else has control of where the code will run. This location is controlled by the consensus algorithm as well as a hardware random code generator. For state machine code, it will always be run in state machine maintainer nodes. This is an asyncronous process as far as reaching consensus between all state machine maintainer nodes. For the code to run in a host node, it will be run in whatever node the enduser select. Only the js code of the TApp runs in the enduser's local browser. ## Can developers direct TPM 2.0 to perform decryption or encryption during egress from a remote computer? Because of security reasons, developers are not allowed to contact the TPM chip directly. All decryption and encryption would be done with API provided by the Wasm runtime. So the answer is **no**, the TPM chip can't be directly accessed by developers. ## Specific TApps ### Leaderboard TApp The Leaderboard is a TApp that shows an updated list of how well contestants are doing based on their net asset value. Note that the leaderboard calculation doesn't take into consideration the value of your COFFEE vouchers (i.e. when you exchange some of your testnet TEA for COFFEE vouchers, you're asset value will go down). #### How do you get a net positive gain in the Leaderboard TApp? You can either sell something or earn by providing some services to others. This is how the real world works. Note that only the TEA you earned inside the TEA ecosystem is considered part of your "net gain". If you buy TEA token from outside the ecosystem, it's NOT considered part of your net gain. For example, if you buy 100 TEA tokens on Uniswap, that TEA isn't considered part of your net gain. If you topup those 100 TEA tokens and consume them all without earning any new assets, then your net gain is -100. It's the same with TEA Fluencer faucets, which would give you externally-generated tokens that aren't considered to be earned in the ecosystem. #### How comes my net gain in the Leaderboard is negative? A negative net gain basically means that you're spending more money than you're earning. Because our community members who run the TEA nodes provide the app hosting services to you, you pay them everytime you use the app. In other words, you pay others who provide app services through their running of host nodes. If you cannot earn money from others, your net gain will be negative. # Core TApps There are a core set of TApps that are maintained by the TEA Project team for the benefit of the TEA ecosystem. ## TApp Store When users launch a node from the [TEA browser wallet](https://wallet.teaproject.org), they'll open the TApp Store wallet. This is the main entrypoint for the TEA Project ecosystem, listing available TApps and investment tokens. This is also the primary account page where users can perform such functions as topup from layer1, withdraw to layer1, and transfer among layer2 wallets. There's no settable spending limit for the TApp Store and it has no investable token associated with it. ## Harberger Auction The Harberger Auction TApp allows endusers to bid on state maintainer seat licenses through an open auction process. Winners of these seat licenses set an adjustable self-valuation price on which they'll be taxed on (known as a Harberger Tax.) All seats are always auctionable even if they're already owned. An enduser simply has to bid 1T higher than the self-valuation price and they'll own the seat if they are the high bidder at the end of the next settlement period. The profitability of owning a state maintainer seat license can be calculated as follows: * **Revenue**: The memory tax paid by all TApp developers. This is the fee that devs pay to occupy state machine memory. * **Expenses**: (Self-valuation price) x (Daily Harberger Tax rate). Running a state maintainer node is profitable as long as the daily memory tax revenues is greater than the Harberger Tax that's paid out daily. ## Leaderboard The Leaderboard TApp is used to track how users are performing during the epoch. The primary measure is through the **net asset gain** column which takes into consideratin a contestant's starting assets when calculating how much economic gain they've achieved during the current epoch. The Leaderboard will be used by the TEA Project team to award prizes based on how well people do during the epoch. ## Miner Portal The Miner Portal TApp is used by miners to plant CML into their servers. To use the mining portal and startup a hosting node, a miner will need the following: * A server IP address. * A CML seed. * A Machine ID. Once a CML node is up and running, users may stop it by clicking the **Unplant** button next to the CML they want to stop. This is useful, for instance, when a node operator wants to change machines. Endusers can also use the Miner Portal to transfer Machine IDs to a different account (presumably another wallet address they own.) ## Seed Auction The Seed Auction TApp is used by prospective miners who need to secure a CML to run a hosting node. TEA miners (aka node runners) can bid on any open auction for a CML. Any bid on a CML starts a 2 hour countdown. * If no one else bids on the CML seed, then they'll be the winner of that seed. * At the completion of the auction, the high bidder must go back and claim the seed into their account. Once the CML seed is in a user's account, they can plant it into a mining machine by using the Miner Portal TApp. ## Email Wallet When a user transfers funds in layer2, they can send it either to an ETH address or an email address. If someone is sent a transfer through their email address, they'll get an email notification to claim their TEA tokens. The email wallet allows these users to login to TEA's layer2 without needing to setup a MetaMask wallet. They simply need to do the requested one-time passcode verification everytime they wish to login to their email wallet. ## TEA Fluencer When you're new to the TEA Project, we assume that you don't have any TEA tokens in your wallet. TEA tokens are the utility tokens used to pay gas fees on the TEA Project network, similar to how ETH works on the Ethereum network. By engaging in actions such as quoting and retweeting, you can earn a certain amount of testnet credit. This credit is designed to help you get started by covering gas fees whenever a transaction occurs on the TEA Project network. We have a separate article for more information [about TEA Fluencer](/_5_tapps/teafluencer). ## Deep Links The TEA Project has a built-in redirect service to reach some of our core TApps. The shortened URLs along with their redirects are as follows: ### Show Nodes from which to launch Leaderboard ### Launch Leaderboard using Node 0 ### Launch TAppStore using Node 0 # TApp Creation & Theta ## Parameters for Creating a TApp Whoever creates a TApp is the owner. The owner is able to decide the name, the initial tokens, and the theta % of every consume and and buy action that goes directly to the owner. There's an initial funding amount (in TEA tokens) that's required to issue the tokens and start a TApp. If for example the owner will take a theta of 10% as their bonding curve incentive, every consume or buy action on the token's bonding curve will net them 10% directly to their wallets. ## Theta Explained Theta is the percentage of every buy action of TApp's bonding curve token that goes directly to the TApp owner. This can be thought of as the payment that goes to the developer for endusers using their app. The theta % comes into play whenever there's a buy action on the TApp token's bonding curve. There are two possible buy action scenarios: 1. Someone buys the TApp's token. 2. Someone executes transactions on the TApp. Let's look at each buy action in depth and how the theta payment to the TApp owner (developer) gets triggered. ## 1. Buying a TApp token When someone buys 100T worth of a TApp's token that has a theta of 10% for example, * The buyer gets 90T worth of tokens. This amount is deposited into the TApp token's bonding curve. * The owner of the TApp gets their theta percentage of the token buy (10%), or 10T. ## 2. TApp usage When someone uses the TApp, the following actions happen: * The CML host providing their machine to host the TApp is paid a gas fee by the enduser. * The enduser pays the usage fee for the TApp. * The theta % of this fee goes directly to the TApp owner. * The remainder of the usage fee is used to buy the TApp's tokens on the bonding curve. * Whatever amount of TApp tokens the above process creates are distributed proportionally to the TApp's existing token holders. More information is available on [bonding curve theta](/_3_token/bonding-curve-tokens/bonding-curve-theta) as well as more information on [TApp token supply](/_3_token/bonding-curve-tokens/tapp-token-supply-and-demand). # TEA Billing ## TEA Project’s Billing System in Detail The TEA Project has two types of billing: charges to end-users who use the TApps and charges the billing to the TApp that uses TEA’s state machine. The description of the billing charges and the revenue destination is as follows. #### End-user Billing * Gas fee: End-user pays to the hosting miner(s). * TApp usage fee: End-user pays to the app. ![](https://cdn-images-1.medium.com/max/1200/1*46Xlfv85s3Z9BAFLcTpxuw.png) The gas fee technically goes to the accrued balance before hitting the bonding curves of all the CML miners who were utilized during the transaction. And the TApp usage fee goes to the accrued balance before being sent to the TApp’s bonding curve. If the accrued balance is positive, all of its TApp token holders receive token dividends at the next distribution. If the accrued balance is negative, then al TApp token holders will have their token amounts reduced according to the balance owned. #### TApp Billing The following two types of billing are charged to the TApp, specifically to the TApp’s bonding curve. * Txn fee: TApp pays to the state machine maintainers. * Memory tax: TApp pays to the state machine maintainers. This payment is based on computing resources consumed as well as state storage used. ![](https://cdn-images-1.medium.com/max/1200/1*wxNpLNZXyeVivToQOO3FGw.png) The above txn fee and memory tax are the fees paid by the TApp to use the state machine. These two payments go into a collection pool that are paid out at regular intervals to the state maintainers. * The unit of billing and frequency of billing are covered more in [TEA-Billing-Rate-Time](https://github.com/tearust/teaproject/blob/master/docs/_5_tapps/TEA-Billing-Rate-Time.md). # TEA Fluencer TApp When you're new to the TEA Project, we assume that you don't have any TEA tokens in your wallet. TEA tokens are the utility tokens used to pay gas fees on the TEA Project network, similar to how ETH works on the Ethereum network. By engaging in actions such as quoting and retweeting, you can earn a certain amount of testnet credit. This credit is designed to help you get started by covering gas fees whenever a transaction occurs on the TEA Project network. TeaFluencer also lets you participate in airdrops, like the Togar3 game airdrop. TFluencer stands for TEA Influencer, the KOLs of the TEA community. ## Rules for Credit: * Credit only covers gas fees on the TEA Project network. * Credit decreases by 10% daily. * Credit cannot be transferred or withdrawn. # Mainnet and test net (Epochs) ## Mainnet - Beta soft launch on Jan 1st, 2024 ### Website / entry point ### Beta Release is Equivalent to Mainnet, Not Testnet All tokens mined and utilized on [https://beta.teaproject.org](https://beta.teaproject.org/) hold real value. The nomenclature "Beta" is employed because the core team intends to frequently update versions within the initial year following the soft launch. Throughout this phase, the core team manages all state machine nodes to ensure swift responses during updates. Once the system attains sufficient stability, anticipated within one or two years, the "beta" label will be discarded in favor of a "hard" launch. If you are a miner operating a "hosting node," please be prepared for regular software updates during the beta period. It is crucial to adhere to provided instructions when notified of updates to prevent mandatory service suspensions. ### Alpha Release (Testnet) Can Be Ahead by One or Two Versions Compared to Beta Release (Mainnet) Similar to other Web3 projects, our testnet consistently runs the latest version ahead of its mainnet counterpart. It's common for users to observe new features being unlocked in the alpha version that may still be locked or non-existent in the mainnet, indicating that these features are undergoing testing. ### Emphasizing Learning and Practice on the Alpha Testnet Considering that all tokens hold real value in the Beta release (mainnet), individuals seeking to explore and experiment with features without incurring any actual financial loss are encouraged to utilize the testnet. It's important to note that any tokens earned on the testnet do not carry real-world value. ### Release notes (latest updates) Jan 1, 2024, Beta first launch ## Current testnet - Alpha release ### Website Plan to start testing by the end of Oct 2023. ### What is Alpha release Unlikely previous epochs, Alpha release runs the same code base as the to-be-released mainnet. It also runs on the same hardware platform as the to-be-released mainnet. Even after the mainnet launched, the alpha will be still running as a parallel testnet, like Sepolia testnet of Ethereum. Will there be a Beta release in the future? This is still under discussion. Tester miners of Alpha release are by invitation only. Regardless you are a new tester or existing testers from previous epochs, you will need to contact us to get invitation tokens to start testing. ### Alpha vs previous epochs comparison chart | Feature | Previous epochs | Alpha version | To-be-launched Mainnet(beta) | | -------------------------- | ----------------- | --------------- | ---------------------------- | | Layer 1 running on | Goerli testnet | Sepolia testnet | Ethereum mainnet | | Token has actual value | No | No | Yes | | Billing on CPU usage | Faked placeholder | Yes | Yes | | Billing on memory usage | Faked placeholder | Yes | Yes | | Nodes hardware requirement | Digital ocean Ok | AWS Nitro only | AWS Nitro only | | Real hardware trust | Faked placeholder | Yes | Yes | ### New features #### Mobile friendly UI Alpha release supports Mobile phone! To use the mobile version, you can install Metamask App to your iOS or Android devices. Use the embedded browser to open . The Metamask app will ask your approval to connect your current crypto account to the URL. ![Pasted image 20231113212252.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-6dd9f969bb759bfccb39408f5020a79d97e62650%2FPasted%20image%2020231113212252.png?alt=media) and ![Pasted image 20231113212511.png](https://73308480-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FmMwGZz977tHp9OWOehSW%2Fuploads%2Fgit-blob-6dd9f969bb759bfccb39408f5020a79d97e62650%2FPasted%20image%2020231113212511.png?alt=media) A few tips: * Make sure you connect ETH mainnet * Make sure you allow Metamask to connect your account to the URL when promoted * The Mobile UI is optimized to phone use case. That means a few features are removed from mobile UI due to limited screen size. You can access full featured TApps on computer web. * Metamask supports portait mode only. #### Payment channel support for P2P applications This is similar to Lightning network on BTC. Two users play together on P2P apps, they can setup a payment channel, then transfer fund in between without constantly submit transactions. No matter how many times or how much fund they transfer in between, there would be only two or three transactions submitted to the network during the whole life time of payment channel. The consensus is between the two users/Apps. TEA nodes won't be involved in judging but process based on the payment protocol. The protocol design protects the participants. For more detail on payment channel, please Google "lightning network". This is very useful to P2P application since no server can be used to make judgement. E.g. multiple players game without a server. or Podcast2, video casting paid by minutes etc. Because there is only very few transactions submitted to the network, the cost of transferring fund inside the payment channel is virtually zero. It is possible to set a very fine grained billing policy, such as 0.01 T per minute or 0.001T per kilo bytes. Compare with the traditional subscription model, this can be considered "pay as you go". A community built Zoom-like "TEA Party" application will be release right after Alpha. It uses the payment channel feature. Host can setup a billing policy when creating a video conference room that either the guests pay a small amount of tip to host per minute, or the host pay the guests by minutes. #### Referral program and new user voucher Alpha is very close to the main net. To simulating how the new user get on board the platform, a new user voucher and referral program are designed. Almost all transaction in TEA Project is NOT free. The users need to pay gas to do most of works. It would be a chicken egg problem for new users, since they have no TEA to start how could they make more TEA from the system? There are two ways to start. The new users can go to the TFluencer app to execute a retweet task to get one TEA as "Credit". The Credit is the same usage as TEA but it can only be used to pay gas fee. Credit also decay and finally recycled if not used before expired. Another way is to get referred by another existing TEA user. Once login from the referral link, both referrer and referee will receive "Credit" bonus. Furthermore, in the future, when the referee pay gas, the same amount of TEA will be bonus to the referrer. E.g. Alice refer Bob to join the TEA Project. The first time Bob login, both Alice and Bob receive 1 credit. In the future if Bob spend 100TEA to pay gas fee, Alice as referrer will also receive 100TEA as referral bonus. This referral program runs until the bonus pool drained out. There might be the third way from the marketing promotion air drop using TEA Party app. This has not determined yet. #### Top up / withdraw USDT to share state machine nodes cost for SEAT owners Owning a SEAT is one of the fastest way to earn TEA mining income. However you will also need to share to cost of running a state machine. In Alpha release, the cost is AWS Nitro machine rental fee. However own a SEAT will need to share the cost of AWS Nitro rental by paying USDT. To make this possible, top up and withdraw USDT is added as a new feature. There is no other feature open to USDT payment rather than sharing AWS Nitro cost. TEA is the only utility token used in TEA ecosystem. #### Hot upgrade For most minor system upgrades, when the new version of WebAssembly code releases, the upgrade happens gracefully as if it was a regular transaction. In most cases, the end user will not notice the upgrade happened. However, for some major upgrade a "warm" upgrade are required. That means all users will get a notice about the up coming upgrades. During the upgrade, all transactions would be on hold till upgrade is completed. ### Notes to test users Make sure you are still using **Goerli** testnet. This is NOT **Mainnet**. If you set your metamask connects to ETH Mainnet, you cannot join the Alpha release. ### Notes to test miners You used cheaper Digital ocean servers to run TEA Node in previous epochs because we want to lower down the test cost. **However, this is no longer the case**. From Alpha, we need to test in the same hardware environment as Mainnet. You **HAVE TO** run TEA nodes on AWS Nitro servers. ### Notes to the SEAT holder/investor Besides running a host nodes, owning a SEAT is also very good way to earn TEA from the state machines. There will be three state machine nodes running in Alpha, so three seats are available. In the Mainnet, who owns the SEAT will need to share the cost of AWS Nitro for the same state machine nodes the SEAT refers to. ## Historical Epochs (Obsolete) Each of the development stages of the TEA Project are referred to as **epochs**. Epochs 2 - 10 were on Polkadot's testnet, while Epochs 11 - 13 were on Ethereum's Goerli testnet. **Note: All historical epochs are no longer available online. You can only access the current epoch as mentioned above** * [Epoch 2](/_6_epochs/epoch-02) was the first epoch where contestants participated in the TEA mining contest. * [Epoch 3](https://teaproject.medium.com/the-tea-projects-epoch-3-mining-contest-e6246de64ee1) introduced the concept of COFFEE as CML coupons were no longer free. A more in-depth post detailing the changes from epoch 2 are available [here](/_6_epochs/epoch-03). * [Epoch 4](https://teaproject.medium.com/tea-project-whats-new-in-epoch-4-d0728418ea3a) introduced TApps (and their tokens) which could be created by contestants to earn a portion of its revenue. * [Epoch 5](/_6_epochs/epoch-05) introduced cloud computing-based mining to the TEA Project's mining contest. * [Epoch 6](/_6_epochs/epoch-06) did away with COFFEE as contestants now had to use their own crypto funds to purchase CML contest vouchers. A new type of social networking TApp called [TEA Party](https://github.com/tearust/teaproject/wiki/TApp:-TEA-Party) is also available to create. * [Epoch 7](/_6_epochs/epoch-07) introduces weekly redemptions for mainnet CML vouchers as we move beyond USDT rewards. * [Epoch 8](/_6_epochs/epoch-08) has the goal of making the block size smaller by reducing tipping frequency and moving more logic from layer-1 to layer-2 as we work to get our layer-1 as streamlined as possible as we look forward to becoming a parachain in the Dotsama ecosystem. * [Epoch 9](/_6_epochs/epoch-09) reintroduces COFFEE as a proxy for bridged-USD and improves its price stability to more tangible backing. Epoch 9 also sees an improved release of the TEA Party TApp that includes private messaging. We also have a new guide on how to earn as an investor instead of as a miner. * [Epoch 10](https://medium.com/@teaproject/epoch-10-users-guide-5bfa60142d14) introduces a new type of mining, the seat maintainer nodes, which are responsible for running TEA's state machine. There's also a new Investments tab in the TApp Store that shows all of the various investment entities available to users. * [Epoch 11](/_6_epochs/epoch-11) marks the TEA Project's move to the Ethereum blockchain as our layer-1. In addition, Epoch 11 refines are hosting model such that end-users are responsible for picking the hosting node to run TApps, not the TApp developers. * [Epoch 12](https://teaproject.medium.com/tea-projects-epoch-12-launch-1c1790621bba) is the official launch of TEA Project on Ethereum (Epoch 11 was more of a testing stage). Epoch 12 also re-introduces the TEA Fluencer app as the main entry point for new users seeking a faucet to join the contest. ## What are the TEA Project Epochs(Obsolete)? The TEA Project will be running on testnets through Epoch 14. The different testing phases are broken up into **epochs** with Epoch 11 marking our transition to Ethereum's Goerli testnet. Each epoch has its own contest associated with it where end-users compete to gain testnet TEA tokens which can be redeemed for mainnet TEA vouchers (COFFEE). # Epoch 2 ## Using the Mining Wallet - Preview 1 The mining wallet is accessible at [wallet.teaproject.org](https://wallet.teaproject.org/). Here is a video tutorial for using the wallet in the preview stage: A transcript of the video is [available here](https://teaproject.medium.com/video-guide-tea-project-mining-contest-4017465711e6). Below are the steps described in the video in more detail. ## Preparing Your Wallet First install the Polkadot{.js} extension and then create your wallet account. Then you'll be able to use the faucet to generate some TEA necessary for the gas to pay for your first transactions. ## Sign Up For CML Seed Coupons You 'll need the TEA Project's NFT known as Camellia (CML) to start mining on the TEA network. The investor registration form for our latest epoch is available as a Google Form to sign up for redeemable CML seed coupons. Testers will be able to see their CML coupons in their tea wallet when the new epoch starts. ## Steps to Start Generating TEA Yield ## Mining TEA The two ways to generate TEA are either to mine or to stake. To begin mining, you would plant a CML seed into a TEA mining machine to generate TEA tokens. These machines are all virtual for right now, merely simulated machines in place of real miners. Look for the little icon here in your CML seed's row to plant your seed into a miner: ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/demo-mining-plant.png) The miner ID & IP will accept anything at this stage (again, these are imaginary machines): ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/demo-mining-machine-details.png) ## Staking TEA Staking is a method of generating revenue without requiring the user to have a mining machine. Some people lack the knowledge, capital, or patience necessary to run a mining machine. Others may have TEA tokens but lack the CML NFT necessary to start up a mining machine. Users can stake either 1 CML or 1000T per staking slot. To start staking, select the "Mining Camellia" link in the header. Click on the **Stake** button for any miner you want to stake with: ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/demo-cml.png) You can either select one of your non-staked and defrosted CML for staking, or leave the CML unselected and the system will automatically take 1000T for your staked amount. The slot index is a slippage tolerance setting and can be safely ignored for now: ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/demo-staking.png) ## Genesis TEA Loans Contestants can use their frozen CML seeds as collateral for a Genesis Loan. A Genesis Loan is particularly useful for generating the TEA needed for the initial mining machine staking slot. Putting up your extra seeds as collateral will provide you with 500T in exchange for each CML seed. * **C CML seed** - 1500T * **B CML seed** - 3000T Borrowers would have to pay back the loan with interest in order to receive their seeds back (loan duration is currently set at 3 days). Users also have the option of rolling over their loan indefinitely while only having to pay interest. The Genesis TEA Loan has a variable interest rate given by the AMM curve. The rate is subject to change based on the remaining TEA in the liquidation pool of the Genesis Loan. This is calculated using the AMM curve. That means that the less TEA there is remaining in the liquidation pool, the higher the interest rate. This will be a flexible compound interest rate that is recalculated every 100 blocks. So no matter what the rate was when you took out the loan, the current interest rate you pay is whatever the rate is for the most recent 100-block recalculation. ![](https://miro.medium.com/max/4800/1*crJia3eJdLC9RiJ2SZ6a1A.png) ### Genesis TEA Loans can be paid off in full or just the interest to extend the loan Contestants can extend the loan as long as they pay the interest accrued by the end of the loan due date. ![](https://miro.medium.com/max/1400/1*CV3ljd137eILuVgCBJM3Xg.png) Contestants still have the option to pay off the loan entirely. Users can see how much Genesis TEA Loan debt they have outstanding in their wallet: ![](https://miro.medium.com/max/844/1*d36Y4N8kexW-B8zHiI-dEw.png) # Epoch 3 Epoch 3 introduces many changes in financial services governing the TEA token economy. ## Anyone can join at any time In epoch 2.1, only those who registered before the epoch started could join the contest. Now in epoch 3.0, anyone can join the contest at any time. The only advantage of registering upfront is that the registered users will be offered CML coupons at a fixed price (but not free as in epoch 2.1.) ## CML coupons are no longer free Those registering before the start of the contest can still apply for CML coupons. But the user needs to pay COFFEE when redeeming their coupons. The price will be as follows: * Type A: 2000 COFFEE * Type B: 1000 COFFEE * Type C: 500 COFFEE Users can only redeem all of their coupons **at once**. For example, you cannot redeem one type C seed while keeping your other CML coupons untouched. So when you fill in the registration form, make sure you're OK to pay that much COFFEE upfront for each type of seed. COFFEE can be borrowed by all contestants at an interest rate to be discussed below. ## All transfers are disabled You cannot transfer funds or coupons between different accounts. This is to prevent cheating and to disincentivize the use of multiple accounts. **All fund transfer transactions are listed on the blockchain. Anyone breaking the no-transfer rule will be disqualified and removed from the rewards list.** ## No initial funding (but unlimited Genesis Loans of COFFEE) ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/genesis-loans.png) You won't have any initial funding as you did during the epoch 2 mining contest. But you can now borrow COFFEE with no limitations. Whenever you need funds, you can borrow COFFEE, and then convert it to TEA at the prevailing exchange rate. But take note that this is a debt: COFFEE has a compound interest rate of 0.2% per 100 blocks (this number is subject to change.) If you don't manage your debt well while accumulating assets during this epoch, you might end up with a negative balance! ## COFFEE debt must be paid off for contestants to be qualified for the final rewards Everyone needs to pay off all of their COFFEE debt at the end of the epoch. Failure to do so results in disqualification for any contest rewards. Given that most people may rush to pay off COFFEE close to contest end, the exchange rate may be high at that point when many are attempting to get the necessary COFFEE for repayment. **It would be wise to consider paying off your COFFEE debt earlier than others.** ## COFFEE has both a credit and debt interest rate In epoch 2.0, there was no COFFEE debt. If you had COFFEE in your account balance, you could let it sit and earn compound interest. Now, since you can borrow COFFEE, there will be a debt interest rate as well. The debt side has the same compound interest rate as the credit side. The initial interest rate is set to 0.2% per 100 blocks. Compared to the 0.5% initial rate of epoch 2, this is much lower. But since it's a compound rate, the number could result in a climbing account balance over time for the amount borrowed. Please keep a cautious eye on your loan balance when borrowing COFFEE. ## COFFEE interest rate may be changed by the DAO The interest rate is not a constant number. The DAO may change the value during the contest. We plan to give advance notice of any interest rate changes in our telegram group. ## Be aware of compound interest The compound interest rate may look like just a tiny number at the beginning, but it may turn your balance into a scary number over time. Make sure you always keep your debt under control. ## The Genesis TEA Loan has a variable interest rate given by the AMM curve In epoch 3.0, you can still use your frozen CML seeds as collateral for a Genesis Loan. The interest rate for our first mining contest in epoch 2 was 0.1 % flat. Now, the rate will change based on the remaining TEA in the liquidation pool of the Genesis Loan. This rate is calculated using the AMM curve: the less TEA there is remaining in the liquidation pool, the higher the interest rate. The interest rate will be a flexible compound interest rate that is recalculated every 100 blocks. So no matter what the rate it was when you took out the loan, the current interest rate you pay is whatever the rate is for the most recent 100-block recalculation. ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/genesis-interest.png) ## Genesis TEA Loans can be paid off in full or just the interest to extend the loan In epoch 2.1, you couldn't pay just the interest due to extend your loan. Now you can extend a loan by paying the interest accrued by the end of the loan due date. ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/genesis-extend.png) You still have the option to pay off the loan entirely. You can see how much Genesis TEA Loan debt you have outstanding in your wallet: ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/genesis-debt.png) ## Topup is back During epoch 2, several contestants fell into trouble when their remaining TEA was too low to make any transactions. Although it's always best to avoid running out of gas on the way to the gas station, sometimes it still happens. To help those who've fallen below the approximately .0003 TEA balance necessary to make transactions, we've added back the **Topup** button. You can click the top up button to get 0.1 TEA. It won't make you rich, but it'll at least help you drive to the gas station! ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/genesis-top-up.png) ## Mining machines are no longer free. Contestants will use COFFEE to buy one Youll now not only need to pay the 1000 TEA stake (or 1 staked CML) to start mining, epoch 3 will also require paying COFFEE to buy a mining machine. From now on, this is what's needed to start a mining machine during epoch 3: * a defrosted CML seed to plant into the mining machine. * 1000 TEA or 1 CML (defrosted or not, doesn't matter) for the initial staking slot. * an amount in COFFEE to pay for the mining machine itself. The mining machine price in COFFEE depends on the type of CML seed that's being planted. We currently require any type A CML to pay 2000 COFFEE, any type B CML to pay 1000 COFFEE, and any type C CML to pay 500 COFFEE. The mining machine is not reusable. If you unplant a CML from a mining machine, that mining machine is also gone. ## Epoch 3 Bonding Curve Investment In epoch 2, there were two ways for miners to make TEA mining income: mining yourself or staking into another mining CML. In epoch 3, there are two new ways to make TEA income besides only mining and staking. * You can be an investor of a TApp by buying into its Bonding Curve. You invest in a project just like venture capitalists do. * You can host a TApp using your mining CML to earn a hosting fee. Just like Amazon charges you a cloud hosting fee, you're paid this fee when you are a miner providing the cloud infrastructure. For epoch 3, each TApp will represent a particular YouTube video. The winning video (the one with the most views) will receive a separate prize of $1500 to be distributed to its token holders. ## Invest in TApps In epoch 3, there's a new top-level TApps page. ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/invest-tapps.png) This page shows the existing TApps and buttons allowing you to either invest or host any particular TApps. To **invest** means you're a shareholder of this TApp, just like when you buy a company's stock. The difference is that you're buying from a smart contract called a **bonding curve**. You pay TEA to the bonding curve and receive a particular TApp token in return. For example, in the screenshot above, you'll have **DDF** and **TYB** tokens as your assets if you pay TEA to buy them. The AMM calculates the price of the token based on each token's bonding curve. Generally speaking, the earlier you invest, the lower the price. ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/bonding-curve.png) (in this image, n > 1, but we set n = 1/2 and m = 1 and 0.7) In epoch 3, we use the following basic bonding curve: ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/bonding-curve-formula.png) The **a** is 1 for the buy curve, 0.7 for the sell curve. The integral formula: ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/bonding-curve-formula-integral.png) is used to calculate the TEA amount for the funding and reserve pools. If the bonding curve is a new Defi concept to you, please google for more details. Simply put, if more tokens are sold (total supply increases), the higher the price of the token and the market cap. ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/tapps-list.png) ## Sell your investment Unlike traditional order book marketplaces, you don't need a buyer when you sell your investment token. You're actually selling it to the bonding curve. The sell price is based on the predefined the rule that **the sell curve is 70% of the buy curve**. If you buy a token and sell it immediately, you'll lose 30%. The 30% goes to the TApps owners' funding pool. ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/investment.png) ## Dividend (consumer usage) and expense(paying the hosting fee) The income and expense of the TApp will go directly to and from the bonding curve as well. The TApp here is a simple DAO that is managed by code and not by the app developers. The bonding curve will automatically calculate how to distribute revenue to shareholders or take tokens from a wallet to pay expenses. ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/consume-list.png) When a consumer pays to use this YTB TApp, the funds will be distributed based on the bonding curve's predefined logic. This also holds for the expenses, such as paying for hosting fees. The bonding curve is constantly changing. Every consume and expense event will cause the price to fluctuate. This is how a typical AMM (Automatic Market Maker) application works to attract venture capital. ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/log-details.png) Once you've invested in any TApps, you can see them on your Assets page under the **My investment in TApps** tab: ![](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/my-investment-tapps.png) # Epoch 4 Please read more about Epoch 4 here: # Epoch 5 Beginning in epoch 5, mining will become even more realistic as contestants will need to use cloud computers to run their mining machines. That means they’ll need to have command line experience firing up cloud instances on services like AWS and Digital Ocean. We want to make the mining contest as close to reality as possible. This means that miners in epoch 5 will have more technical hurdles to successfully mine as we prepare them for the technical requirements necessary to be a miner on the TEA network. ## Epoch 5 Consume Actions In epoch 5, the consume action automatically happens every 1000 blocks. The following amount of TApp tokens are purchased and distributed to hosters and TApp token investors according to the following formula: * YouTube TEA Fluencer TApp: 100T worth of tokens per view, max of 2500T per 1000 blocks. Minimum of 10T per 1000 blocks. # Epoch 6 Epoch 6 does away with **COFFEE** funding, requiring contestants to pay to purchase CML seeds. Epoch 4 added the ability of contestants to create their own TApps. Epoch 5 made it so that people must create their own mining machines. ## Epoch 6 rules * COFFEE Loans are no longer necessary for initial funds - TEA is the only currency. Contestants will purchase CML coupons redeemable for seeds using their own crypto and can use Genesis TEA loans to obtain TEA funds necessary for staking slots and interacting with TApps. * Mining involves [setting up actual mining hardware](/_4_mining/mining-with-own-hardware). * C CML seeds are not powerful enough to host TApps, but they can earn public service rewards by verifying B CML machines' availability. An added benefit of running a C CML miner is that there's no need for a public IP and there's therefore no need to rent a cloud server. A typical home computer with a residential internet connection is sufficient to mine with a Type C CML. * [PoS staking and mining](https://support.polkadot.network/support/solutions/articles/65000168057-how-do-i-stake-nominate-on-polkadot-) are possible in layer-1, the same as Polkadot. Miners wishing to earn through PoS can [use this url](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fwallet.teaproject.org%2Fwss1#/staking). * C CML can earn Availability Attestation (Obsolete) rewards by monitoring the availability of B CML. * All available YouTube IDs for TEA Fluencer TApp creation will be selectable via a popup in the TApp creation modal dialog. There are two constraints for anyone creating a TApp: **1)** there is a 100T non-refundable deposit for creating a TApp and **2)** the contestant has 24 hours to get the TApp hosted. If the TApp isn't hosted within 24 hours, the TApp is manually taken back from the user ready to be deployed by someone else and the user loses their 100T deposit. * There's a new TApp, the Tea Party app. Anyone can create a Tea Party app and become a host of a TEA table. The host can invite other contestants to join their table to chat. The contest rounds will tip based on how many messages are in your table. * Contestants can now transfer funds and CML coupons. * A negative balance is no longer possible because there's no COFFEE debt. * All contestants can share a portion of the $2000 total rewards. There is no longer a limit of only the top 20 finishers. * Besides our Telegram group, contestants can ask question in the Tea Party **help desk** TApp. Contestants can also post buy/sell messages there. ## Epoch 6 - CML prices The contest CML can now be purchased directly by contestants. Contestants can send BNB or BUSDT to the wallet listed on the registration form for the CML bundle they want. Further purchases can be done by contacting us at our [Telegram group](https://t.me/teaprojectorg). Note that these only exist for the epoch they were issued on and aren't the mainnet CML that will be issued later. The pricing is as follows: | CML seeds | Price | Discount from full price | | ----------------- | ----- | ------------------------ | | 2 B CML + 4 C CML | $50 | 28.6% | | 1 B CML + 2 C CML | $30 | 14.3% | | 1 B CML | $20 | - | | 2 C CML | $15 | - | # Epoch 7 ## Epoch 7 Intro Epoch 7 continues to require contestants to pay to purchase contest CML seeds. The contest seeds can be bought using the [purchase form](https://forms.gle/jeBkBn8wDj1np92eA). In Epoch 7: * Contestants will purchase contest CML coupons redeemable for seeds using their own crypto and can use Genesis TEA loans to obtain TEA funds necessary for staking slots and interacting with TApps. * Mining involves [setting up actual mining hardware](/_4_mining/mining-with-own-hardware). * C CML can earn Availability Attestation rewards(Obselete) by monitoring the availability of B CML. An added benefit of running a C CML miner is that there's no need for a public IP and there's therefore no need to rent a cloud server. A typical home computer with a residential internet connection is sufficient to mine with a Type C CML. * [PoS staking and mining](https://support.polkadot.network/support/solutions/articles/65000168057-how-do-i-stake-nominate-on-polkadot-) is also possible in layer-1, the same as Polkadot. Miners wishing to earn through PoS can [follow this link](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fwallet.teaproject.org%2Fwss1#/staking). * Contestants can use any YouTube video to create TEA Fluencer TApps. But only videos approved by Sudo will get tips: if your video doesn't get an approval from Sudo, your TApp won't receive any tips(i.e. revenue). * There are two constraints for anyone creating a TApp: **1)** there is a 100T non-refundable deposit for creating a TApp and **2)** the contestant has 24 hours to get the TApp hosted. If the TApp isn't hosted within 24 hours, the TApp is manually taken back from the user ready to be deployed by someone else and the user loses their 100T deposit. * Contestants can now transfer contest funds (contest TEA) and contest CML Coupons. * Epoch 7 is planned to run continuously until the team decides to stop. As updates happen during epoch 7, contestants should be able to see the notification on their **My CML** page. When updates occur, click to see the instructions. Follow the instructions to update your mining software. Ignoring the update notification and failing to update will result in your CML mining machine being forced offline after a grace period. * TEA Party won't be available in the beginning of epoch 7 but will be added later. * Epoch 7 won't give out USDT reward. Each week, contestants are eligible for being rewarded with mainnet CML coupons. ## Epoch 7 Reward Details ## What is the competition reward? Rewards for epoch 7 will be mainnet CML Coupons. Whoever owns these mainnet coupons can redeem them for real CML coupon when the mainnet starts. The exchange rate is as follows: * 1 mainnet coupon can be redeemed for 1 mainnet type C CML. * 2 mainnet coupons can be redeemed for 1 mainnet type B CML. * 4 mainnet coupons can be redeemed for 1 mainnet type A CML. Contestants will be redeeming these vouchers for mainnet CML NFTs that have the defrost schedule of "team", not "investor". ## What is the reward distribution schedule? Every week, 3 mainnet CML coupons will be rewarded to contest participants. All contestants share this reward. The number is subject to change based on the number of contestants and the total amount of TEA assets during the epoch. We'll start with 3 mainnet CML Coupons at the beginning of epoch 7. ## How is the buy-back rate calculated? At end of each week, a snapshot of the total assets is taken. A buy-back rate is calculated and posted to the telegram channel. ``` Buy-back rate = (total TEA assets in the contest at the time of the snapshot ) / (number of mainnet CML coupons) ``` For example, if at the end of the first week, there are 30000TEA in total assets (for all contestants), then the rate is 0.0001 mainnet CML coupon per asset value (measured in TEA) in any contestant's wallet. Anyone can transfer any amount of TEA to NPC address **5CcrQQwmkxpstBTg74RmET2kRSxNwRcMfMnPsmzZAWkQTZX8** and then [notify NPC](https://docs.google.com/forms/d/e/1FAIpQLSdLSD7JPA_9xF4qzYMM3gyUPqWJ_smiC3v28YQR0tq5Y07ZhA/viewform) to receive their reward. NPC will send the reward mainnet coupon to the **same** sender address. ## Rate expiration Whenever a new rate is posted, the old rate will immediately no longer be valid. The new rate will be the prevailing rate until a new buy-back rate is posted. ## Running out of the reward Every week, the total of the mainnet coupon is a fixed number. At the time of the snapshot, the total assets can convert all the reward (eg. 3 coupons at the beginning). But there is a chance that more TEA assets are generated during the following week, so there could be someone trying to redeem the mainnet coupon but all of the coupon for the present week has already run out. In this case, they cannot get a reward in the current week. Generally speaking, the buy-back rate is no longer valid after the reward coupons are completely exchanged for during the week. Contestants will have to wait until the new rate is set at the beginning of the next week. ## Remaining mainnet coupons roll over to the next week If not all the mainnet coupons are redeemed by the end of the week, the remaining coupons are rolled over to the next week. When the new week starts, these rolled-over CML mainnet coupons will be added to the 3 allotted for the new week. ## Do I need to exchange all my assets for the reward mainnet coupon? You can, but we do not recommend you do so. You will need enough funding to continue mining or investing. We wouldn't recommend exchanging all of your assets unless you decided to stop participating in the contest. Your assets will stay in your wallet and roll over to the next week. It will not expire unless some serious bugs cause us to have to stop the test net. If that happens, contestants will have time to exchange their assets for CML coupons if the epoch needs to be stopped prematurely. ## What can I do if I only have a fraction of the mainnet coupon? It is very common that you accuminate a number of coupons during multiple rewards. When you redeem the coupon to the real CML coupon when the mainnet starts, only the integer part can be used. That is because the CML is NFT that cannot be split. For example, if you have 5.352 mainnet coupons, you can redeem to any of the combination below * one A, one C * two B, one C * five C, * one B, four C * .... any other combination But the 0.352 won't be redeemed. You can sell it to someone who needs the 0.352 to make it up to an integer. Or you buy from others to bring your coupon up to 6. ## Where can I see the rewarded mainnet CML Coupons? The TEA Project will keep a track record of mainnet CML coupons earned by each account address (i.e. Polkdot wallet address) which [can be viewed here](https://docs.google.com/spreadsheets/d/1NifxSCNpPxS0FAwDa3BKtXUrkos29ZdAwGb-XPF6xLE/edit?usp=sharing). Please note that if you change your account address later, TEA Project won't be responsible for transfering your mainnet CML coupon to your new address. This process may be updated to be automatic later. But at this moment, we will start with the manual process. ## Epoch 7 - CML prices The contest CML can now be purchased directly by contestants using the [purchase form](https://forms.gle/jeBkBn8wDj1np92eA). Contestants can send BUSDT to the wallet listed on the registration form for the CML they want. Further purchases can be done by contacting us at our [Telegram group](https://t.me/teaprojectorg). Note that these only exist for the epoch they were issued on and aren't the mainnet CML that will be issued later. The pricing is as follows: * Type B: 20 USDT * Type C: 15 USDT ## Epoch 7 - TApp consume actions When consumers use a TApp this brings TEA into that TApp's token bonding curve. During testing epochs, we only have miners and TApps without consumers so we must try different schemes to simulate TApp usage. TApp demand brings TApp token payouts in the form of dividends to TApp developers, investors, and curators. The consume action payouts for epoch 7 TApps will be as follows: 1. **Referral TApps:** This is new for epoch 7. Each contestant will have their own TApp with a referral code tied to it. Anytime they entice someone else to join the TEA mining contest using their referral code, this will trigger a consume action in their TApp at a rate of $1 spend = 100T of consume action for every $1 their referral spends purchasing contest CML. Every time their referral uses the referral code the referral's TApp will benefit through a consume action. * Note that the contestant making the referral can sell the TApp token immediately to get the all the TEA out for their starting funds (instead of taking out a Genesis collateral loan). * Self-referrals are allowed, so every purchase of contest CML a contestant makes will create a consume action in their TApp. The purchaser's TApp should be created first before making the self-referral. If the user wants to get a self-referral for the first consume action into their referral TApp (i.e. the user is making their first CML coupon purchase after entering the contest), then the user should create their referral TApp first. They can then enter their the referral code into the Google Form to earn a self-referral, and the amount paid will be used as the basis of the consume action into their referral TApp token's bonding curve. 2. **TEA Fluencer TApps:** These will continue to be tie consume actions to YouTube video views, but they will be at a reduced rate in epoch 7. * The videos must relate to the TEA Project and must be approved by the Sudo account for tip outs to occur. * The consume action payouts for TEA Project-related YouTube videos will be as follows: 1T per view with a 25T cap that resets every 1000 blocks. There's no minimal tip amount for TEA Fluencer TApps in epoch 7 (i.e. if a particular video gets 0 views in a 1000 block period, then it won't receive any tip for those 1000 blocks). 3. **TEA Party TApps:** TBA. ## Rules are subject to change without notice TEA Project team has a right to change any of rules and the amount of rewards during epoch 7. # Epoch 8 Epoch 8 continues to require contestants to pay to purchase contest CML seeds. The contest seeds can be bought using the [purchase form](https://forms.gle/9McACwtEeyX4GXov6). ## Rules for Epoch 8 * The tipping rounds will happen every 1000 blocks instead of every 100 blocks as before. We’re reducing the tipping frequency for TApps to help speed up the sync time of new nodes onboarding onto the network. * Epoch 7 rules will still apply to epoch 8. # Epoch 9 Updated epoch 9 rules and block rewards schedule has been published to [our Medium](https://teaproject.medium.com/tea-project-epoch-9-rules-and-rewards-d863f74d9cd1). ## Epoch 9: Bringing Back COFFEE Starting in epoch 9 of TEA Project's testnet mining contest, contestants will no longer use USD to buy testnet CML seed vouchers directly. Instead, COFFEE will instead return to the contest as a proxy for USD. Users who want to join the mining competition will pay USD to get COFFEE for use in our testnet: [COFFEE purchase link](https://docs.google.com/forms/d/1Gkav7FKn554G6KBZ6zBfFsxUboq6LJoVy_0NXMccR_s/edit). The COFFEE can then be exchanged for testnet TEA, which is needed to interact with TApps and mine on the TEA Project platform. For example, COFFEE can be exchanged for testnet TEA to buy testnet CML from the marketplace. We've designed the tokens to offer a similar experience to what users will face once the mainnet launches: * A user's USD is the same now as it is when the TEA Project mainnet launches: some stablecoin funds you have on a different chain (i.e. USDT / BUSD on the BNB Chain or USDT / USDC on Ethereum). * COFFEE can be thought of as the stablecoin funds that have been successfully bridged over into the TEA Project ecosystem. This is currently a manual process that will be automated by bridges when the mainnet launches. * COFFEE can be used to purchase testnet TEA just as bridged-USD can be used to purchase mainnet TEA. * Testnet CML can only be purchased with testnet TEA (not COFFEE), similar to the mainnet where bridged-USD can't be directly used to purchase mainnet CML (users must exchange to TEA first). * Similarly, testnet TApp tokens can only be purchased with testnet TEA. ## Starting in Epoch 9, COFFEE is Backed by Stablecoin We previously used COFFEE as a stand-in for USD during mining competitions epochs 2 - 5. In these earlier contests, the COFFEE token wasn't backed by anything and given out as loans to contestants. COFFEE's price would dump early in the competition and TEA's price (relative to COFFEE) would skyrocket as potential miners would take out COFFEE loans and exchange it for testnet TEA. Our new epoch 9 design for the COFFEE economy offers better stability for the COFFEE price and more closely mimics the action of market participants once the mainnet launches. * Miners must use their USDT to purchase COFFEE (1:1 exchange rate). * Miners can also sell (testnet) CML or TEA back to COFFEE. They can then put in a form request to get their USD back. * Contestants can only withdraw COFFEE back to USD if there are funds in the initial pool. While the exchange ratio may dip, it will never exceed 1:1. After the exchange, the amount of COFFEE used in the transaction will be burned. * Testnet TEA will still be used to exchange for mainnet CML vouchers. ## Cashout Methods This new model is to test out the token economy when contestants are allowed to exchange their TEA and exit the competition for other assets, i.e. exchange game assets for real world assets. There are two assets contestants can cash out their TEA for: * Mainnet CML vouchers. * USDT through COFFEE using a [Google Form](https://docs.google.com/forms/d/1_wbqN42zFyFcAgz5beR4DtBwvK9bvUWvGHkFqOHNcVA/edit?ts=621ea253) (manual process). Note that the team will give out 3 mainnet coupons per week just like epoch 8 but we now have a hard cap of 6 mainnet CML vouchers outstanding at any one time. Contestants can exchange TEA for COFFEE and then cash out for USDT at anytime (as long as there's USDT still in the initial pool) using the Google Form linked above. The COFFEE / USDT exchange rate will fluctuate according to demand but the value of COFFEE will never exceed 1 USDT. ## Changes to TApps * TEA Party returns with private messaging and layer-1 notifications. * TEA Fluencer will remain in epoch 9 with a tighter cap on tipping. Also no existing YouTube videos will be approved, they must be new videos. * [Referral TApps](https://github.com/tearust/teaproject/blob/master/docs/_6_epochs/Epoch-7.md) will be removed ## Start Generating TEA Revenue Through Buying TApp Tokens We've now setup everything and it's time to generate some contest TEA revenue so we can start moving up the leaderboard. The easiest way to start in TEA's testnet is to buy a TApp's token. Every decentralized app in our ecosystem, called a TApp, has its own token associated with it. Buying a TApp's token is just like owning stock in a TApp and gives the owner some financial benefits: 1. Each time the TApp is used by someone, a consume action is initiated. The developer gets their share, and the rest of the consume revenue is converted to TApp tokens and distributed proportionally to TApp token holders. This is considered the dividend reward for being a TApp token holder. 2. A TApp token is minted according to a bonding curve: as the supply increases, so does the price. We know that consume actions introduce a new supply of TApp tokens minted along the bonding curve. So not only will TApp token holders earn dividends, their token values will also go up at the same time. ## Example of Investing in the TEA Party TApp Token A contestant in the mining competition will increase their leaderboard position by increasing their net asset value. One way to do this is to purchase TApp tokens and enjoy both dividends and price appreciation (as long as people keep buying the TApp token). Let's see how you'd go about investing in the TEA Party's TApp token. ## 1. First navigate to the TApp list. Using [the TEA browser wallet](https://wallet.teaproject.org), pick the TApp from the list whose tokens you want to invest in: ![1 Screen Shot 2022-04-20 at 8 11 19 PM](https://user-images.githubusercontent.com/86096370/164365341-0e40cae4-7c84-4b72-ad06-91ca3eee83ce.png) Note the price (in TEA) of the token's current price. The price you pay will be the **buy** price which will be above the sell price since tokens are issued along a bonding curve. Locate the **buy** button in the row of the TApp whose token you want to buy: ![2 Screen Shot 2022-04-20 at 8 12 27 PM](https://user-images.githubusercontent.com/86096370/164365347-ec98a50f-cf5f-408e-8809-57df66111749.png) ## 2. Decide how much of the TApp token you want to purchase. You'll need to exchange TEA for the TApp tokens you want to buy. If you have a certain amount of TEA you want to spend, input it in the TEA section and click the **convert back** button to see how much TEA that will buy you: ![3 Screen Shot 2022-04-20 at 8 14 25 PM](https://user-images.githubusercontent.com/86096370/164365351-d99a07f0-d2e7-40e1-9cf2-f1797cdb1516.png) Clicking the **next** button will initiate the transaction which you'll need to confirm in your wallet. ## 3. Keep track of your TApp tokens in the "My assets" section of your wallet. You can always check the amount and current price of the TApp tokens you have by clicking the **my investment in TApps** tab of your assets page: ![4 Screen Shot 2022-04-20 at 8 15 01 PM](https://user-images.githubusercontent.com/86096370/164365354-7605684e-eabb-42ea-96f1-df7f6e3a7d2f.png) ## 4. Keep Track of Your Position on the Leader Board The goal of these testnet competitions is to increase the total value of your assets. As competitors increase their asset value in contest TEA, they'll have two options to cash out their winnings. 1. Contest TEA can be exchanged for mainnet CML. CML is a valuable NFT that's used as a mining license on the platform. 2. The COFFEE:USDT exchange rate will always be 1:1. Contestants can therefore exchange their contest TEA back into COFFEE to be cashed out anytime at the same rate. The CML mainnet exchange happens every week and is announced in our [Telegram group](https://t.me/teaprojectorg). # Epoch 10 Epoch 10 is our last epoch that still uses our own substrate-based layer-1. * [Epoch 10 User Guide](https://medium.com/@teaproject/epoch-10-users-guide-5bfa60142d14) # Epoch 11 Epoch 11 marks our transition to Ethereum as our layer-1 blockchain. * [Epoch 11 User’s Guide](https://teaproject.medium.com/epoch-11-testers-guide-7657cd2ff7da) * [TEA Project’s Epoch 11 — Moving to Ethereum](https://teaproject.medium.com/tea-projects-epoch-11-moving-to-ethereum-fddcfeff4f7) * [Latest TEA Project Developments for Epoch 11](https://teaproject.medium.com/latest-tea-project-developments-for-epoch-11-ee3fa98381f3) # Epoch 12 * [Epoch 12 User’s Guide](https://teaproject.medium.com/tea-projects-epoch-12-launch-1c1790621bba) # FAQs ## When Will the Mainnet Be Live? The eventual launch date of the mainnet depends on the progress of the project. You can see from every epoch that the product is advancing rapidly. If everything goes well, we hope that the mainnet will go live in early 2023. However, this expectation may change at any time. ## How to invest in TEA Project? If you are an accredited investor (e.g. a VC), please contact us at to join our private sale. If you’re an individual, so far the best way is to join the various epoch competitions. Your earned testnet TEA tokens can be converted into COFFEE which can be converted into mainnet TEA. ## TEA Project Tokens * [TEA & CML tokens](/_3_token/faq-tokens) * [TApp & CML entity tokens](/_3_token/bonding-curve-tokens/tapp-token-supply-and-demand) ## TEA Project Structure * [Governance Structure](/_z_faq/governance-structure) * [Social Media](/_z_faq/tea-social-media) * [TEA Core Team](/_z_faq/the-tea-project-core-team) ## TEA Project Tech * [Technical FAQ](/_z_faq/faq-technical) * [TEA Security](/_z_faq/tea-security) ## Miscelaneous * [FAQ-Links](/_z_faq/faq-links) # FAQ - Links ## Helpful Blog Posts * [Two Minute Teaser](https://teaproject.medium.com/tea-project-2-minute-teaser-98d5744be4e3) * [TEA Project: Moving from Cloud Computing to Web3](https://teaproject.medium.com/tea-project-moving-from-cloud-computing-to-web3-9e0bb5443c92) * [TEA Project: Filling the gap between cloud apps and dApps](https://teaproject.medium.com/tea-project-filling-the-gap-between-cloud-apps-and-dapps-99ff7bb4b408) * [TEA vs Blockchain](https://medium.com/@teaproject/tea-vs-blockchain-ca31b2e438b3) * [TEA vs IPFS](https://medium.com/@teaproject/tea-vs-ipfs-f37202a33fc) * [TEA vs Trusted Computing](https://medium.com/@teaproject/tea-vs-trusted-computing-1224745f1664) * [Disaster prevention](/_z_faq/tea-security) * [How big is the market?](https://medium.com/@teaproject/tea-project-disrupting-cloud-computing-market-size-estimation-347b814688db) * [Who are the founders and core team members?](https://github.com/tearust/teaproject/wiki/The-TEA-Project-Core-Team) * [TEA Project outstanding features compared to other competitors](https://medium.com/@teaproject/tea-project-competitors-d62f53c05bcf) * [TEA and WebAssembly](https://medium.com/@teaproject/tea-and-webassembly-89991a83bbd1) * [Is TEA secure and reliable?](https://medium.com/@teaproject/tea-project-security-reliability-and-robustness-b43013b1740) * [Why Do TEA's dApps Show as "Not Secure" in the Browser?](https://teaproject.medium.com/how-tea-projects-use-of-http-in-web3-is-more-secure-than-https-in-web-2-0-d488265af3d2) * [What is TEA's governance structure?](https://github.com/tearust/teaproject/wiki/Governance-Structure) * [Why do you say the Internet is broken?](https://medium.com/@teaproject/fixing-a-broken-internet-728f9f0b6df3) * [How could TEA fix the Internet?](https://medium.com/@teaproject/how-tea-fixes-the-internet-a944dfe2db39) * [A long article on the TEA token economy - CML and TEA](https://medium.com/@teaproject/challenges-in-the-tea-token-economy-design-cf928a06679b) * [How will the business model support the token price?](https://medium.com/@teaproject/the-tea-token-model-how-does-the-business-support-value-price-ff5f8278e4fc) * [How TApps Benefit Everyone in the TEA Ecosystem (includes use cases)](https://medium.com/@teaproject/how-tea-project-tapps-benefit-everyone-7c3d59284205) # FAQ - Technical ## What makes the project different from its competitors? Compared to other blockchains, the TEA Project isn't really even technically a blockchain although also being decentralized. TEA Project reaches the same goal but through a different technical approach. And there are other well known blockchain projects that are like TEA Project in that they're not really blockchain at all: IPFS, Helium, and Dfinity. TEA Project is similar to these projects in that we're all trying to make a decentralized world, same as blockchains, but through different means. That is to say that TEA Project doesn't have blocks, and there's no chain. It's more reasonably called a "decentralized cloud" or "decentralized database". Because we don't rely on blockchain for consensus, the TEA Project can solve most of the problems that are intrinsic to blockchains: 1. Expensive 2. Slow 3. Hard to use, etc. To be fair, our solution does require trusted computing hardware and GPS satellite receivers. TEA Project is part of the decentralized cloud niche where there are further specializations. Some projects focus on decentralized storage, some focus on decentralized networking. TEA Project and very few others are focused on computing. Among those who also are focused on computing, TEA Project uses hardware security instead of the software algorithms that are typically used by our competitors like Dfinity. There are pros and cons of each solution which are explored more on our [Medium blog](https://teaproject.medium.com/where-does-the-trust-in-t-rust-come-from-f0b67117d238). TEA Project has more in common with traditional cloud computing or distributed databases than it does with a blockchain. Its difference from other cloud computing services (Amazon AWS, Google Cloud, MS Azure, Alicloud...) is its decentralization based on the TEA network of distributed nodes. For more information on how decentralized web3 apps differ from web2 apps, see the [following article](/_z_z_appendix/what_makes_a_web3_application). Another technical innovation is TEA's decentralized use of concepts introduced by [Google Spanner](https://teaproject.medium.com/proof-of-time-how-googles-truetime-can-be-used-in-the-blockchain-55f87b41cb3a). Timestamps are widely used in distributed databases such as Google Spanner. These are instrumental in many of Google's services (gmail, google doc, calendar etc.) in sorting asyncrynous data. The TEA Project is the first blockchain / decentralized cloud project to use such a technology using a decentralized and distributed compute network. For further information on how we've adapted Google Spanner concepts into the decentralized world of Web3, see our [in-depth Medium post](https://teaproject.medium.com/proof-of-time-how-googles-truetime-can-be-used-in-the-blockchain-55f87b41cb3a). ## TEA Project's Consensus Although TEA Project itself isn't technically built with blockchain, it uses blockchain as one of its [three roots of trust](https://teaproject.medium.com/tea-projects-sources-of-truth-blockchain-hardware-and-time-49663c9f575a) together with trusted computing hardware and GPS timestamps. TEA Project uses proof of time for consensus which doesn't have to wait for a new block to synchronize across all nodes. Because any node can append to the global transaction queue, there's technically no limit on how many transaction per any given period of time, e.g. unlimited TPS. There will be a network latency delay of course but other than that, all transactions must be processed immediately when the network latency buffer is due. TPS is mostly limited by state machine hardware capacity and network speed. ## Is there a "block explorer" for TEA's layer-2? TEA Project runs on top of Ethereum (our layer-1) and leverages it for token transactions as well as keeping the ledger of our trustable layer-2 nodes. But what about the TApps running on our layer-2 that are using our proof of time consensus (and not blockchain), is there a block explorer so that anybody can see all layer-2 transactions. There's not a block explorer by default in our layer-2. Consider the example of our TApp Store which by default acts as a black box to obfuscate transactions to keep them private. There's a log available for the network actions and core apps like the TApp Store, but these logs are cleared regularly. That means if user1 transfers funds to user2 who claims they never received them. After a certain amount of time, neither user would be able to confirm whether this layer2 transaction occurred after the logs are wiped. Layer-2 will feel like a black box when you're using some system level TApps (such as the TApp Store). These TApps are designed to have privacy protection built-in. It won't disclose any information to the public by default. But you can still see your own financial status on the UI, or even your historical data in the log page. But the TApp Store doesn't allow others to see your financial information. This is by design, because we're trying to protect our endusers' privacy. This end-to-end privacy is something that most blockchains find hard to achieve. Any TApp dev can make a block explorer for their own app. But this will only give users view access to data from this particular TApp. It won't be able to see private data stored in other TApps like the TApp Store. TEA Project runtime is the EVM-like architecture that hosts these TApps. Endusers cannot access the runtime directly, only developer who write their TApp code to access the APIs provided by the runtime. But you might not be able to access any particular TEA runtime feature depending on what the particular TApps you're using has implemented from the TEA runtime. # TEA Governance Structure * The TEA community is governed by a DAO management structure. * The TEA Project DAO encourages decentralized decision making through granting voting rights to locked T tokens. * All decisions are made by the DAO solely through voting. TEA and CML are not governance tokens. The following types of ecosystem participants who stake TEA earn votable reputation tokens: * Miners (state maintainers and CML miners who pay the state subscription fee). * TApp devs (who pay the memory tax). * Investors (who lock their TEA into either TApp or CML bonding curves). Note that CML miners who don't pay a state subscription fee will still earn voting privileges based on their own investment in their CML token. Each of the above class of users earn reputation tokens that they can use to vote (spend) on governance issues. More info is available here: # TEA Security ## DDoS Attack Although a DDoS is hard to avoid, TEA can reduce the benefits of DDoS attacks through anonymity and randomness. When the number of nodes in the entire network reaches a certain level (for example, TEA modules are attached to a large number of IPFS mining machines), then the DDoS damage is minimal. **If a great number of nodes are attacked and suddenly lose trust, how does the TEA network handle this attack? How long before the network is able to recover?** First of all, if an attack is initiated by an untrusted node, it will have little impact on the trusted nodes. Because trusted nodes only communicate with other trusted nodes, it will not accept any network communication from an untrusted node. If the attack is through DDoS, that means the router is under attacked and the machines can’t handle it. A DDoS attack is beyond the scope of blockchain protection, just like any server’s design cannot solve unexpected power outages. These kind of external attacks can only be solved through data center facilities and economic rewards/punishments. For a trusted node to be attacked successfully, there must be more than 2/3 of the nodes becoming bad actors at the same time. Any attack that doesn't reach this threshold will automatically be killed, and all assets of attackers will be confiscated. The remaining 2/3 who didn't participate in the attack would make a fortune as these miners token holdings would capture the forfeited assets of the attacking 1/3. Because TEA uses a CML licensing system that isn't free, it'll be very expensive to gather a large number of nodes to cause disarray on the network in a short period of time. It would take an attacker several years to lie in wait before they can finally control a majority of the nodes. Time becomes a huge cost for the attacker. In the mean time, they could've attacked many other blockchains several times over and made a good fortune. So it's not clear why they'd go through all the extra hoops to attack the TEA network. Due to the NFT properties of TEA’s CML, each CML is different. When the technology matures and the scale is large enough, the diversity of the technical stack will grow to the point that it's difficult for a single technical stack to occupy 1/3 of the nodes, nevermind 2/3. When the network is just beginning, it's relatively easy for one popular tech stack to reach or exceed 2/3 of the network nodes. Therefore, we will be very cautious in the initial stages of issuing CML. We will make sure that the interests are positively related to the project in order to obtain CML. This way, the probability of deliberate attacks will be much lower. Optimizing the mining rewards such that miners receive more revenue from normal work rather than attacking the system is another solution for preventing attacks. Once the benefit of helping the network is greater than doing evil, then there's much less possible incentive to do evil. Last not the least, because of the decentralization and zero-knowledge of the data, even if the attack succeeds, the benefits obtained are usually 0. You don’t want to take a huge risk to rob a homeless person who may be poorer than you. This theory is explained in the economic design of the white paper. The security of the TEA network is based 60% on the economic design of the project and 40% on computer technology. # TEA Social Media * [YouTube](https://www.youtube.com/channel/UChYmd52JIe0zTdIdXHLK7WQ) * [Twitter](https://twitter.com/teaprojectorg/) * [Instagram](https://www.instagram.com/teaprojectorg/) * [Reddit](https://www.reddit.com/user/teaprojectorg/) * [Medium blog](https://teaproject.medium.com) * [Telegram](https://t.me/teaprojectorg) * [Discord](https://discord.com/invite/MafFErSa) # The TEA Project Core Team ## Kevin G. Zhang The founder, [Kevin G Zhang](https://www.linkedin.com/in/kevingzhang/), graduated from Tsinghua University and currently lives in Silicon Valley, USA. In 2015, when he was the CTO of Silicon Valley startup iHealth Labs, he discovered a market need that couldn't be met. At that time, iHealth Labs already had a large number of patients' medical data. However, it was barely used due to the strict regulations protecting medical data and the inability of the internet infrastructure at that time to protect it in transit. That became the starting point for Kevin's idea of establishing a trusted computing environment to protect patient privacy data. In 2017, he entered the blockchain industry and determined that it was the best direction to solve the privacy requirements for such important data. He established ELK Insight LLC to continue his technical research. In 2018, he began work as an independent contractor for technical community development in the blockchain space. During this time, Kevin started to become disillusioned with the blockchain technology of the companies he was contracted to work for. Most importantly, he felt that they couldn't reach the trust necessary to safeguard critical data. His insistence on the use of trusted hardware to achieve distributed computing led him to leave his work as a contractor in 2019 and begin working on a solution to this problem. Kevin then began researching and developing the TEA Project, which he's continued to this day. ## Roy Yin Go-to-market leader [Roy Yin](https://www.linkedin.com/in/yinrui/) is a Web3 enthusiast and believes it will profoundly change today’s internet. He had developed global launch strategies for smart devices while he was in senior management roles at Xiaomi, Apple, and Blackberry. Including 1st Xiaomi smartphone launch in India/Indonesia/Brazil, 1st Blackberry smartphone launch in China, and Apple iPhone/iPad launches in APAC. Since 2017, Roy has started to lead a series of tech startups aiming to improve people’s everyday life, such as remote patient monitoring in the Healthcare sector, NLP (natural language processing) for languages in developing countries (e.g. Hindi/Bangladesh/Swahili/Arabic), and Web 3 infrastructure. ## George Pornaras Content marketer [George Pornaras](https://www.linkedin.com/in/george-po/) graduated from the University of Wisconsin, Madison. His past experience includes writing B2B content for cloud computing companies as well as tech startups. His most recent work experience prior to the TEA Project was working as a marketing consultant as part of a dual China-United States team at Luminus, a manufacturer of LED lights. ## Jacky Li Software engineer [Jacky Li](https://www.linkedin.com/in/jacky-li-4039747b/) graduated from the Dalian University of Technology. He has been working with Kevin for more than 10 years dating back to their time together at iHealth Labs. He was in the past a systems architect at HP. ## Raindust Mingzhi Yan Software engineer Mingzhi Yan graduated from Wuhan University. Prior to TEA Project, he was engaged in artificial intelligence and multi-party secure computing research and development at Yuncong Technology. ## Alsein Xiang Software engineer Alsein Xiang (pronounced as /ˈælseɪn ʃʌŋ/) graduated from the University Of Wollongong in Australia. He most recently worked for iVolution Capital as a system engineer optimizing their high-frequency trading infrastructure. Prior to that, Alsein engaged in Rust development as a member of the Lark Video Conference team at Bytedance. ## The TEA Project Has Full-Time & Part-Time Contributors All team members are working full time on the TEA Project. Since the TEA Project is an open source project, there are a large number of part-time and community developers as well as other roles participating. These people are not listed in the core team, however, their IDs can be found on Github. # Appendix # The Future and Innovation of Layer2 ## Existing Blockchains Use Layer2s for Scalability Ever since Blockchain was invented, many projects have tried improving the technology to make blockchain run faster and cheaper. To make blockchains more scalable, there are two primary innovation paths: * Increasing scalability through improving the consensus: PoW -> PoS and other Proof of Whatever. * Increasing scalability through off-chain computation, i.e. a layer2. ![\_1\_Scaling](https://user-images.githubusercontent.com/86096370/170151337-7ae0cff9-0327-46bd-8134-9463a796ae34.png) Improving consensus can only go so far as nodes inherently have to wait for each other to reach consensus while making allowances for Byzantine fault tolerance. That leaves layer2s as an area of focus for achieving scalability. Basically, a typical layer2 does the following: * Collects and batches txns from layer1. * Execute those txns off-chain in layer2. * Send the result back to layer1. * Layer1 runs some kind of verification, then accepts the result and updates the blockchain. The main problems with layer2 are that: * Each layer2 has to be tightly bundled with a specific layer1. * Verification is not cheap (e.g., ZKP). Possible resolver could be created either through inventing a new algorithm (unlikely) or hardware acceleration (ASIC). ## A New Type of Layer2 Although layer2s seem like a promising start towards scaling blockchain, there is still room for improvement. Let's imagine a new, improved layer2 that is: * Agnostic of any type of layer1. Many innovative layer2s are currently tied to specific blockchains giving them only niche applicability in context of the entire crypto ecosystem. * Able to run above and across all major blockchains. If this new layer2 could run across any blockchain, then we have also solved another thorny problem currently in crypto, that of bridging funds from one chain to another. * Able to verify results with minimal or even zero verification. Calls back to layer1 to verify the result are a bottleneck that incurs conventional consensus and its typical transaction fees. What if we could verify the result without involving layer1 at all? ![\_blockchain\_graph](https://user-images.githubusercontent.com/86096370/170151342-49421471-ba29-4843-85a9-1af33d955a81.png) ## We Trust the Result by Verifying the Environment One aspect of improving the layer2 experience is being able to verify the result of layer2 transactions while minimizing the involvement of layer1 during these verifications. It turns out that we can verify the result of layer2 transactions simply by verifying the environment in which the programming logic is run. For example, if I asked you to verify the correctness of 82986.862 x 916019.1128 = 76017551703.3, how would you go about doing it? Probably very few people would use pencil and paper to verify the result. You could counter that a multiplication problem, while tedious to verify, is technically doable by hand. So let's try something harder like verifying that the Ln(99999255) = 18.42. Well, most of us would just pick up our phone and use the calculator or some kind of app and key in the problem. If the result shows correctly, you'll likely be confident that you've verified it successfully. But hold on - how do you know the result of your calculator app was correct? Have you recalculated it manually? No, most likely you haven't. You're basically trusting the platform that Steve Jobs and his predecessors have built on the iPhone. Have you ever considered that this is blind trust? But it's not completely blind trust because most of us trust hardware like an iPhone because we trust the environment. As a side note, that's why Apple no longer offers support for jailbroken iPhones because they no longer have control over the environment and can no longer guarantee a trustable execution platform. Whether it's an iPhone or it's a CASIO calculator, they're all widely mass-produced and reliable computation environments. If users were to run the same calculation across different iPhones or calculators they would see the same result. Let's move one step further and assume the calculator app is another layer2 node. In what circumstances can you believe the result from this node without computing the result for yourself again? To ensure that this layer2 calculator node is trustable, we must ensure that: * The integrity of that node can be remotely verified, i.e. the node is in a trustable state from the perspective of any app that wants to run there. * There are several randomly selected nodes running the same task separately, and they all get the same result. ![\_Remote\_Node\_Attestation](https://user-images.githubusercontent.com/86096370/170151343-135f7428-e7b7-434f-80cb-a29ff5e60350.png) In this type of environment, can we trust the results? Well, a skeptic might say there are still some corner cases where: * All of the nodes get infected by some kind of virus but cannot be detected remotely, or * Somehow the nodes can collude together and send the user the same wrong answer. These are legitimate concerns, but if we can use technology to reduce the chances of this occurring to be negligible in real world conditions, this would still be tolerable for our layer2 mechanism. Car accidents happen all the time, yet we still drive, right? Now you can see, instead of verifying the result by recalculate, we just trust the process. The process means * The environment can be trusted (i.e. the calculation happens in a trusted environment, which can be a branded environment - Apple, Intel, Casio etc.) * The input code and data are correct (i.e. hash of the data and code are verified). * Multiple, randomly selected nodes (uncolludable) get the same result separately. ## Benefits of Switching to Verifying the Environment ### Verifying the Environment is Cost Effective As we just showed, verifying a brand of a calculator is much easier than recalculating manually using pencil and paper. Even adding on the cost of multiple brands of calculators to run the same formula, it's still much cheaper than recalculating manually. Now let's extend this "verify result by verifying the environment" methodology to our potential layer2 solution. Instead of verifying the rollup results from layer2, we just verify the integrity of the layer2 nodes and "blind" trust the result before putting it on the blockchain. This change will significantly reduce the cost and complexity of layer1 verifications. ### Layer1 Agnostic Let's take things one step further. If the verification of the integrity of layer2 nodes can be done agnostically relative to any type of layer1, then this layer2 could possibly run on any kind of layer1. For example, we can have the same layer2 solution running on top of Ethereum, Polkadot, Cosmos, BSC... as long as the layer1 supports basic Turing-complete smart contracts. This can make the layer2 solution blockchain agnostic, running above and across all major blockchains. ### General-purpose Computing Let's add one more major feature to this killer layer2 that we're building. Since this new layer2 is agnostic towards the underlying layer1, there's no limit on what kind of txns it can process. In our implementation, general-purpose computing would be available in this new layer2. In this case, we don't really care if the layer1 blockchain is Solidity-based EVM or Rust, Wasm, ink etc. That's totally irrelavent as our layer2 can run general-purpose functions which might be totally unrelated to the layer1 underneath. For example, you could run a Tensorflow task on layer2 without any problems, although we would never expect a Solidity smart contract to run Tensorflow. ### Cloud Computing as an Oracle Since we can run general-purpose computing, running a cloud computing oracle in layer2 won't be hard. As long as the environment can be trusted, we can have a distributed cloud-based SQL database running on the layer2. That means using SQL to write a smart contract is no longer a dream! ## How Do We Do This? Using (Controversial) Hardware Integrity Hardware integrity remote attestation has always been controversial. There will always be arguments between the pure cryptographic algorithm believers vs those who favor hardware trusted execution environments. The truth is there are always pros and cons with either approach. In my opinion, before we can find a perfect math solution, using hardware integrity remote attestation is always a cost-effective compromise solution. Long before blockchain, hardware integrity remote attestation has been in the IT industry for decades. All cybersecurity engineers know that trusted computing technologies have been used in every computer and most phones. That's how Microsoft and Apple know that your computer is jailbroken or hacked by a boot virus. How it works is that all the hardware that their OS's run on have a trusted computing secure chip called a TPM to record the hashes of your hardware before the OS is loaded. They report those hashes to Microsoft and Apple and validate it there, which in practice is a form of centralized remote attestation. In the blockchain world, we do this all decentralzied, so we just use other nodes as remote attestors. They're randomly selected by a VRF in the layer1 blockchain to reduce the chance of collusion. All those remote attestors make their own decision seperately and report their decision back to the layer1 blockchain. A simple voting procedure stored in a smart contract will determine if a testee is trusted or not. Besides trusted computing technology, TEE is also presently widely used in many companies: Intel SGX, ARM Trust zone. The only cons of TEE is that it's tightly bound to the CPU manufacturer which causes new kind of centralization. For example, Intel recently discontinued processors with SGX for the consumer market. If you were a project relying on Intel SGX, then Intel's decision meant that your CPU options for miners going forward just got much more expensive. ## Conclusion and Future of Layer2 We believe that the future of layer2 will be as a standalone general-purpose cloud computing oracle that runs on top of multiple blockchains. This would also mean that the majority of computing tasks could be better performed at a lower cost by moving them from layer1 to layer2. Because our new layer2 does not need any expensive ZKP when sending the result back to layer1, the overall cost is much lower. Since layer2 is verified trusted by layer1, there's no blockchain type of consensus needed, and the performance can match that of traditioanl cloud computing. In TEA Project, we benefit from the many advantages of hardware trust. We use the timestamp as directly received from GPS satelites to run a "Proof of Time" distributed state machine in our trusted layer2 nodes. This is similar to Google's Spanner database, but ours is fully decentralized. Therefore, TEA Project is a decentralized cloud computing platform that runs so-called TApps. TApps run like typical web apps or mobile apps, but there's no centralized application server or database server needed, as well as no domain name or Verisign certificates. They are unstoppable, unbreakable, and censorship free. # What Makes a Web3 Application Web3 apps mark a significant departure from the cloud-based internet apps that modern users are used to. Modern internet apps give users relative convenience in exchange for the utility they provide. The typical traits that internet apps share include the following: 1. They're hosted on central servers. Even if the server architecture is distributed it's still owned by centralized companies. 2. These internet apps are often free to use and if not totally free, have a generous free tier. 3. The service provider has control of any user data that's given up to use the service. In contrast, a Web3 app runs decentralized on a distributed architecture that nobody owns. An implication of this design is that a dApp can't be turned off by any centralized power. This means that a hosting miner can't censor any content in the dApp, they can only choose to stop hosting the entire dApp. And because no user data is given up to use a dApp, app usage is paid directly by the consumer in the world of Web3. Let's take a closer look at each of these differences and how the new Web3 dApps differ from traditional internet apps. ## Internet Apps = Pay With Your Data The implicit contract that internet apps have with its users is that they provide app services in exchange for access to your private data. Consider how many entities have access to your private data when you access a traditional web app. * Your ISP is likely using your browsing habits to better monetize their ad targeting. * The app itself has access to your private data while using the app. * A whole range of tracking beacons are busy below the surface refining your user profile that's useful to advertisers by watching what you do on the app. Since the collection of the data is free for the apps, they're economically incentivized to maximize the value of private user data as much as possible. This gives internet apps the power to potentially abuse private user data for profit. This includes the [ethically dubious practice](https://www.wsj.com/articles/t-mobile-hacker-who-stole-data-on-50-million-customers-their-security-is-awful-11629985105) of leaving customer data on minimally-secured servers in case it's valuable one day. We'll explore later how censorship is inextricable to both centralized server architectures and app companies collecting private user data. ## Web3: Users Have to Pay In Web3, there's no free lunch in that every app action has a computing cost associated with it that needs to be paid by the user interacting with the app. In contrast to traditional internet apps, Web3 dApps: * Use a crypto wallet to login. Your wallet address acts as your username in the Web3 ecosystem. Because many people aren't used to interacting with crypto wallets, this hurdle can make uptake among consumers more difficult for them. * There's no longer private data being monetized to subsidize free apps as in web 2.0. Instead, users must pay the compute cost directly in crypto to use the app. We couldn't say that this is a win in the Web3 column as logging in with a crypto wallet and having to pay for transactions yourself aren't great enticements to onboard new Web3 users. There are certainly usability benefits of internet apps that because of the current ease of use will never migrate over to Web3. Some users may not care that a trivial amount of their private data is being leaked back to a central corporation if they get a good benefit from an app. That's totally understandable, and each consumer has to make a cost-benefit analysis between privacy and the utility they get from free internet apps. In defense of Web3, crypto wallets are becoming easier to use. And even though Web3 users have to pay to use apps, the new paradigm opens up new avenues for users to [monetize their own private data](https://teaproject.medium.com/tea-project-allows-privacy-in-the-home-1ed42d6faac5). ## Internet Apps' Centralization = Censorship A server-based internet app has multiple layers of centralization that might not be immediately evident. To see how these might negatively impact a typical internet app, let's imagine a modest social media app has just had an influencer publish a controversial post on their platform. The amount of attention the post gets begins to flood the app with new users who are actively publishing their agreement or disapproval of the influencer's message. This triggers a few cascading events for this internet app that show the perils of centralization: * **1. Bandwidth**: The newfound traffic exceeds the plan they've paid for and their connections are throttled and many requests are re-routed back to the originating server. * **2. Infrastructure**: Their hosting provider doesn't know anything about the app's sudden virality and only see a huge spike in incoming connections. Afraid that all the traffic will negatively impact other customers on the same server, the host decides to take the social media app's website offline. * **3. Application**: The app is happy with all the new traffic until their website is taken offline. They quickly realize that this new influencer is causing more trouble than they're worth and they decide to boot them off the platform. The example above shows how any of the app's upstream infrastructure providers can pressue the app into censoring its users. And there's even more layers of centralization that can get an app disconnected from the internet: * **4. Registrar**: Domain names can sometimes be taken offline by filing (even spurious) [DMCA copyright complaints](https://teaproject.medium.com/if-safe-harbor-is-dismantled-will-centralization-increase-7e6bf9327f68). * **5. Security certificates**: Most often an app is adversely affected when they forget to renew their [SSL certificate](https://teaproject.medium.com/how-tea-projects-use-of-http-in-web3-is-more-secure-than-https-in-web-2-0-d488265af3d2). * **6. DNS**: Over time, DNS providers like Cloudflare have become more interested in gatekeeping our ability to view internet content. ## Web3: Decentralized Through and Through Everything mentioned in the above section about traditional internet app tech stack lists a whole roster of centralized infrastructure that's censorable. In contrast, Web3's core tenet of decentralization prevents any one player from taking an app down. By taking a look at the tech stack of a decentralized app and the infrastructure it runs on, we can quickly see the differences it has with internet cloud apps. We'll use the TEA Project to show how Web3's infrastructure is decentralized throughout its tech stack. Instead of centralized server(s) hosting an internet app, the TEA network's miners host TApps based solely on their own hosting profitability. The bandwidth and compute power for a dApp (called a TApp in the TEA Project) will always be there as long as miners find it profitable enough to host the TApp. Can user data be censored in a Web3 architecture like the TEA Project? Not from the hosting miners who don't know what's being run on their nodes. In the TEA Project, app code and user data stays encrypted in IPFS until they're decrypted within a miner's protected enclave for execution. And TEA Project TApps don't require a domain name or even a traditional host for the front-end as the IPFS CID for the TApp is loaded from the nearest miner's IP address. TEA Project TApps also feature a [traditional 3-tier architecture](https://teaproject.medium.com/the-tapps-3-tier-decentralized-tech-stack-43d2872f609b) that makes app development straightforward. Additionally, all database queries are sent to distributed and decentralized nodes instead of a central database server. Against the backdrop of centralized app stores, the TEA Project will have its own TApp store that will not censor any TApps from being offered there. Economic incentives ensure that miner nodes will only host TApps that are used by consumers and make the miner money.