In my last step, I successfully ran the tutorial’s reward branch. Now I am going to setup a new project that use the existing tutorial code but with a new name.

Alternatively I could reuse the same tutorial-v1 folder, but this may cause potential problems if I forgetfully try to submit my changes to git. So it would be better to create a new folder for this new project.

I’ll copy the code to a new folder called `mytest`. In order to make sure the build.sh can copy the wasm file to the correct folder inside dev-runner, I make sure these 3 folders (mytest, totorial-v1, dev-runner) are at the same level.

I copy all files from tutorial-v1 to mytest: `cp -r tutorial-v1 mytest`.This command will create mytest folder as expected. Since this is a new project, I’ll need to remove the `.git` folder so that all git records that connect to the original tutorial-v1 will be removed.

cd mytest
rm -rf .git

Now this folder has nothing to do with tutorial-v1 git repo. If you want to use git to track changes, you can `git init` to create new git repo.

Simplify the folder name

I’ll simplify the folder name as a personal preference since I think the sample-actor name is too long. I’ll rename all the folders like so for the sake of convenience:

mv sample-actor actor
mv sample-txn-executor state-actor
mv sample-front-end front-end

Update manifest using new token_id actor_id

We haven’t modified any code yet, but if we build this project and try to deploy it as is it will fail. This is because its actor name and token_id haven’t been changed yet. They’re defined in the manifest.yaml file in both actors folders. We have to rename it to our own name, otherwise the system will consider this actor an updated version of tutorial-v1 instead of a new idea-vote application.

I rename the actor_id and owner_id, token_id, and token_id as the following for the manifest.yaml inside of the actor folder:

actor_id: idea-vote-actor
owner_id: com.developer
token_id: 1111111111111111111111111111111111111111

And for the manifest.yaml inside the state-actor folder:

actor_id: idea-vote-state-actor
owner_id: com.developer
token_id: 1111111111111111111111111111111111111111

actor_id

Of course, you can set up a totally different name for your actor_id. But usually we’ll call the actor running on a hosting node “something_actor”, and the actor running on a state maintainer node “something_state_actor”. These actor_ids are used to identify actors when deploying to the TEA Project so we try to make it meaningful so that everyone knows which TApp these actors are for.

owner_id

The owner_id should retain the existing name “com.developer”. This is technically considered a category instead of an owner_id. This is used to identify if this actor is a system actor (developed by the TEA core team) or a community application. Only the TEA core team can sign and update these system actors. This owner_id is reserved for future usage such as for partners or other special purposes. So again, leave it as is: “com.developer”.

token_id

If you’ll only be testing in your local simulator using”dev-runner”, you can set the token_id to anything as long as you don’t have other actors under development using the same token_id loaded into the same dev-runner. In my case, I set it to 1111…. because the previous tutorial-v1 set it to 00000…. If you are making some other TApp at the same time, feel free to set its token_id to 222222…. or whatever numbering system that’s easy for you to track.

However, if you’re ready to deploy your TApp to the TEA Project (testnet or mainnet), this token_id needs to be the **real** token_id you generated in the Developer Portal for your app. The detail of deployment is explaned in the tutorial under the deployment session. Failure to set the the correct token_id may cause:

• Deployment failure due to a duplicated token_id.
• An inability to receive payments from your users.
• An inability to topup to pay to support your TApp’s cost. If your TApp runs out of its balance, it will be removed from the TAppStore.

So please make sure you know that token_id is and set it correctly before deployment.

Generate your own key.pem as developer’s private key

You might ask how could the TEA Project mistakenly identify me as the owner of tutorial-v1? This all stems from the key.pem file which is considered to be the private key of the developer. This key.pem file SHOULD NOT be included in the github code repo. So why can we see it in the code base? Well, this is a trade off. Most new learners want to have a download-and-compile experience. If they downloaded code but it asked them to generate a key.pem before compile, some might get stuck or even walk away. So we keep this file in the code repo to allow anyone who downloads the code to get it setup and compiled, test run without block. However, when you’re going to make your own project, you NEED TO GENERATE YOUR OWN key.pem file. You can learn more about generating the key.pem file.

Since I’m not going to deploy the mytest project, I will keep the existing key.pem to minimize my work load.

FAQ: Where does the owner_id and actor_id or key.pem get checked?
Answer: When a new actor’s deployed to the TEA Project, the TAppStore will verify the owner_id with existing owner_id database. If you’re a returning customer, then the key.pem ile needs to be checked to ensure you’re the same returning developer. If you’re the same returning developer and you upload an actor with the same actor_id, this is considered to be an update of an existing actor. At this moment, we haven’t provided any upgrade or migration features yet. A new actor will be considered a new actor regardless if it’s the same actor_id.

Rename package names in Cargo.toml

In both the actor and state-actor folders, you’ll need to rename the package name. This is what the compiled wasm file’s name is supposed to be for those packages with `crate-type=[“cdylib”]` in Cargo.toml. Although it doesn’t make much difference as far as deployment, the names help you figure out if this wasm file was compiled for your project. You’ll be happier seeing idea-vote-actor.wasm instead of an old-looking sample-actor.wasm in the dev-runner/local/b-node folder.

I renamed actor/codec/Cargo.toml:

[package]
name = "idea-vote-actor-codec"
version = "0.1.0"
edition = "2021"

The codec package is not a cdylib, so it won’t get compiled into a standalone idea_vote_actor_codec.wasm file. Instead, it’s included in another package (e.g. idea-vote-actor) inside the impl folder.

For actor/impl/Cargo.toml, we rename the package name to `idea-vote-actor`. Note, this package is a `crate-type=[“cdylib”]`, so it will be compiled to idea_vote_actor.wasm file during build.

We similarly rename the state-actor/codec/Cargo.toml to `idea-vote-state-actor-codec` and the state-actor/impl/Cargo.toml to `idea-vote-state-actor`.

As long as we changed those two package names, all dependencies need to be updated as well. For example, in `actor/impl/Cargo.toml`, the dependencies need to update to the new package name. This is the final version. Note the first two lines under dependencies.

[package]
name = "idea-vote-actor"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
idea-vote-actor-codec = { path = "../codec" }
idea-vote-state-actor-codec = { path = "../../state-actor/codec" }
tea-sdk = { workspace = true, features = ["wasm"] }
thiserror = { workspace = true }
serde_json = { workspace = true }
log = { workspace = true }
prost = { workspace = true }
primitive-types = {workspace = true}
serde = { workspace = true }
serde_derive = { workspace = true }

[dev-dependencies]
tokio = { workspace = true, features = ["full"] }

The following is the final version of `state-actor/impl/Cargo.toml`. Please note the package name and the first line under dependencies.

[package]
name = "idea-vote-state-actor"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
state-actor-codec = { path = "../codec" }
tea-sdk = { workspace = true, features = ["wasm"] }
thiserror = { workspace = true }
serde_json = { workspace = true }
log = { workspace = true }
base64 = { workspace = true }
prost = { workspace = true }

[dev-dependencies]
tokio = { workspace = true, features = ["full"] }

Rename file in build.sh

Because we changed the compiled wasm file name, we also need to change the scripts in build.sh. Otherwise, the build.sh will still be looking for the sample-actor.wasm and sample-txn-executor.wasm files. Please use the new names idea_vote_actor.wasm and idea_vote_state-actor.wasm.

Rename the reference package name in the source file

ist of compiling errors. That’s normal, because there are so many places in the code that reference the old “sample-actor” or “SampleActor” name. Because we no longer have such a name, it will fail in compiling. You can run a global search in your IDE where you’ll find a lot of SampleActor or sample-actor mentions. You’ll need to replace them all with the new name. Since there are too many of them, I’m not going to list all of them in this article. Please do this on your own until the tough Rust compiler is satisifed. I know it will take a while, but it’s one of the tasks a developer’s supposed to do.

Some other notes need to be mentioned here.

The NAME const value needs to be changed from
`pub const NAME: &[u8] = b”someone.sample”;` to
`pub const NAME: &[u8] = b”com.developer.idea-vote-actor”;` because the name of package changed. Similarly the same applies to another actor.

While updating the code, you can also remove some code that’s only needed for the sample-actor, such as the hello world GreetingRequest or AddRequest etc. They’re no longer needed in the new idea-depot app.

build two actors

Run ./build.sh in both the actor and state-actor folders. Very likely you get some compiler errors which you’ll need to fix one by one. These are mostly caused by the renaming.

If you can successfully build these two actors, you should see them under the dev-runner/local/a-node and b-node folders.

How about the front end?

Right now, the front end code is still the tutorial-v1 reward branch. All the front end code will still try to send request to the backend looking for the token_id 00000… and actor name to sample-actor. We’ll need to change this to make it work correctly.

Update .env.test & .env.prod

There are two hidden files under the root of the front-end folder. If you cannot find them, use `ls -a` to list all files. The `.env.test` file is used to define the local test environment. The file `.env.prod` is used to define the production deployment environment.

You’ll need to change the original VUE_APP_TAPP_ID from the token_id of tutorial-v1 0000… to new token_id we set to 11111…

NODE_ENV = dev
VUE_APP_LAYER2_URL=http://127.0.0.1:8000
VUE_APP_TAPP_ID=0x1111111111111111111111111111111111111111

The value of VUE_APP_LAYER2_URL tells the front end which URL it’s supposed to send requests to. If we run the backend locally using dev-runner, it’s by default `http://127.0.0.1:8000`.

In the `.env.prod` you can leave the VUE_APP_LAYER2_URL empty, because it will by default point to the hosting node URL which the front end was downloaded from. This is the miner’s IP.

Again, when deploying to production (testnet or mainnet), the 0x11111 needs to be replace by the actualy **real** token_id you deployed to the Developer Portal.

After these modifications, after the front end starts running locally, it will use`http://127.0.0.1:8000` as the backend URL, and send requests to the actor whose `token_id = 0x1111111111111111111111111111111111111111`.

Test run locally using dev-runner

The step to run the TApp locally is exactly the same as how you’d run the tutorial-v1 using dev-runner.

If you’ve done everything correctly (and it might take you a few times), you should have the backend running in docker. Then run `npm install && npm start` to start the front end from your front-end folder. Use the URL showing on the npm command line output to launch the TApp in your browser. You should see exactly the same tutorial-v1 reward branch working. You can try to test if all existing tutorial-v1 business logic runs correctly (hello world, create task etc).

Note that we haven’t modified or added any new logic for our new TApp idea depot yet. We just created a new project using tutorial-v1/reward as a boilerplate.

Congratulations, you’ve just taken your first step into the world of building TApps!

If you have errors and aren’t celebrating yet then please read the next article for troubleshooting. Don’t worry, you’re not alone. I bet 99.99% of readers will run into some type of trouble. Stay calm and stay tuned.

• The first actual tutorial on building an actual TApp where someone can login with Metamask starts with the aptly named login branch of the tutorial.
• It looks like the tutorial goes over how to build a decentralized task app that includes confirmation that task is done as well as funds transfer. This is really cool and could be the basis of a decentralized Fiverr type of dApp. Really impressed that they released a fully-featured tutorial app like this.
• The next step involves the `SQL` branch so named for the database because that step of the tutorial focuses on implementing the database structure.
• Then there’s the `reward` branch which goes over fund transfer.

Since every branch builds on the last, I thought it was a bit tedious to checkout each branch, do the actual tutorial, then tear it down and checkout the next branch. So I decided to read over the `login` and `sql` branch sections and decided to dive in at the `reward` branch.

Follow the bouncing ball between the two repos

To get started with the `reward` branch I download the **tutorial-v1** repo and switch branches:

git clone https://github.com/tearust/tutorial-v1.git
git checkout reward

I’ll be following the [reward branch tutorial](https://dev.teaproject.org/020_tutorial/060_reward_fund_transfer) and taking notes here. The actual steps can be found in that link so I won’t bother repeating verbatim what you can already read there, I’ll just be providing my notes as I go through the process.

One thing to keep in mind is that you have to have the `dev-runner` environment up to run your tutorial code on top of. So this was the first part that was a little confusing and I’ll paraphrase here as best I can.

• Now that I’ve installed the `tutorial-v1` and switched to the `reward` branch, it’s time to install the dev environment.
• I followed the [install instructions for dev-runner](https://dev.teaproject.org/020_tutorial/010_install-dev-env): `git clone https://github.com/tearust/dev-runner.git`. There’s plenty of other things mentioned on that page that you should install. One of the biggest takeaways that tripped me up when trying to run `npm start` later in the tutorial was making sure I was running node version 14.14.0.
• Now when you run the `build.sh` scripts in the `tutorial-v1` repo, these will output wasm files into the `dev-runner` local folder. These are the actor files.

That’s what I mean by “follow the bouncing ball” as the two repos are interlinked. I first had to run the build.sh scripts in `tutorial-v1` and only after those actor files were output could I then jump back into the `dev-runner` repo and start up the local dev environment with `docker-compose up`.

Launching the actual app

With the preliminaries out of the way, I jumped back into `tutorial-v1`, specifically the `sample-front-end` directory and ran the following commands:

npm install
npm start

I was really excited to access the TApp in the browser by launching http://localhost:3200.

I tried to login and was met with this:

I got a little ahead of myself as I forgot to go to the admin tab and press the two initialization buttons first:

Launching the TApp the first thing you probably want to do is login so don’t forget that important initialization step.

Another issue I found is that when I returned to do this tutorial again, I got an error message when I tried to initialize the app:

I found out that this involves the dev-runner docker images being out of date. To fix, you’ll need to run `docker-compose down` to clear the container and then check for updates to the docker images. There are two images which you can update using `docker pull` to get the latest docker images (the actual commands are available in [the dev-runner faq]). Then you’ll run `docker-compose up` to reload the `dev-runner` environment.

Next I was able to login with Metamask and activate the faucet as well as set the spending limit so I could use the TApp.

Using the actual app

I actually needed two Metamask accounts to test the logic of the app (one for the task creator and the other for the task taker). Once the task maker has created the task, the task taker will claim it and begin working on it.

One thing that through me for a loop was that some funds were removed from the task taker’s account when they took the task. Evidently this is done as a way to ensure that task takers don’t indiscriminately take tasks, otherwise they could hoard all the tasks for themselves. There is some opportunity cost related to taking a task which is fair from the perspective of the system. The issue I see is that the task creator can decline the submission for whatever reason and the task taker doesn’t get their funds back. This is an issue that a creative dev can solve with some forethought balancing the needs of fairness on both sides.

As mentioned, the task creator alone can decide whether the task has been done up to standards or not.

This I see as a potential for abuse as anyone who wants work done can create a task, reject it even when a good job is submitted, then claim the task with another account and sign off on it to claim the bounty. This problem is remedied by using a secure oracle to decide if the task is done properly or not without human intervention, something the TEA Project shows in their retweet task example.

The ultimate goal of the TEA Project is to establish a framework for existing web2 developers allowing them to build web3 apps with minimal effort. That means if you’re already a web2 developer, you don’t need to learn blockchain, solidity , smart contracts, consensus, etc. just so you can build web3 apps. The TEA Project helps abstract away many web3 constructs and leaves you to build with tools you’re familiar with.

In this step, we’ll design the Idea Depot app. The system design of this app is actually identical to your typical web2 app design. Yes, you can still use SQL, and you still need to define data structures, requests, and responses. That’s as per usual, which is exactly what we want the TEA Project to feel like using it.

The Matrix: Neo's Black Cat Deja Vu Explained

Before venturing into the next step you should familarize yourself with some of the concepts introduced in our step by step tutorial.

Data structure — Idea

We can compare two very different kinds of system designers:

1. The first types starts from the UI and designs the request/response before then focusing on backend services finally the data structures that support all the operations.
2. The second type starts from the data structure to make sure it meets all of the business requirements, then the mutation functions, and then the request/response. It’s only at the very last stage where they turn their focus to make the UI interactive

I happen to be the latter of the two and prefer to start with data structures, so let’s start there.

For our business requirements, we know that we’ll need to have an `idea` data structure that stores the idea. It basically uses the `task` data structure in the tutorial but with a few additional properties. One of the newly added properties is `total_contribution: String`. This is how many TEA token has been voted towards this idea. Our business requirement doesn’t care how many time the same voter votes on the same idea, we only care that they’re adding money to their pledge, so we don’t need to store the voter’s address. This significantly reduces the difficulty level.

So the `Idea` struct looks like:

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct Idea {
 pub id: String,
 pub title: String,
 pub description: String,
 pub owner: Account,
 pub create_at: u64,
 pub total_contribution: String,
}

The total_contribution is String type instead of Balance. This is because Balance:u258 is too large to store in SQL. We convert the Balance to String when storing to SQL, then convert it back to u256 after reading it from SQL.

Txns

There are two transactions to manipulate the idea and its votes. They are

    CreateIdea {
        id: String,
        title: String,
        description: String,
        owner: Account,
        auth_b64: String,
        unit: Balance,
    },
    VoteIdea {
        id: String,
        user: Account,
        auth_b64: String,
        price: Balance,
    },

These are very straightforward. As long as you know a little about the Rust language, you’ll understand this. The only thing to note here would be the auth_b64. This is the string that the end user signed when logging in to this Idea_depot app. This string contains what the end user allows this app to do with their assets. We have explained this in the tutorial `login` step. With the limitation of auth string, the app developer cannot do anything beyond what the end user allow them to.

SQL

SQL is in the TEA Project is as simple as you’d encounter in a traditional web2 app. We’ll need SQL statements to create idea in SQL database and increase the vote_num when someone votes for an idea.

The intiial SQLtable use the following SQL statement

CREATE TABLE Ideas
(
  id                      TEXT UNIQUE,
  title              TEXT,
  description          TEXT,
  owner              TEXT,
 create_at               INTEGER,
  total_contribution      TEXT
);
CREATE INDEX idx_id ON Ideas (id);

This SQL is called during SQL intiialization which happens the first time that this TApp was deployed.

Later on when someone creates an idea we have the following logic:

    let sql = format!(
        r#"
    INSERT INTO Ideas VALUES (
        '{id}', '{title}', '{description}', '{owner:?}', {create_at}, '{total_contribution}'
    );
        "#,
        create_at = to_short_timestamp(tsid.ts)?,
        total_contribution = unit.to_string(),
    );
    exec_sql(tsid, sql).await

If someone votes on an idea to increase their T contribution:

 format!("UPDATE Ideas SET total_contribution = '{}' WHERE id = '{id}';", new_total_contribution.to_string()),

Requests and Responses

The following are the Rust code that’s needed to generate the SQL statements. The client will need to query the list of ideas and actions to create an idea or vote on an idea.

To create a new idea:

#[derive(Debug, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct CreateIdeaRequest {
  pub uuid: String,
  pub address: String,
  pub tapp_id_b64: String,
  pub auth_b64: String,

  pub id: String,
  pub title: String,
  pub description: String,
  pub unit: String,
}

To query the list of ideas:

#[derive(Debug, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct QueryIdeaRequest {
  pub uuid: String,
}

The uuid is a system assigned id number for the client to query for a response at a later time. We’ll have a detailed explanation on this later in the tutorial.

To vote and contribute to an idea:

#[derive(Debug, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct VoteIdeaRequest {
  pub uuid: String,
  pub address: String,
  pub tapp_id_b64: String,
  pub auth_b64: String,

  pub id: String,
  pub price: String,
}

Handler

There’s not too much complex logic going on in this simple app. The QueryIdeaRequest handler for instance just queries the SQL database. The VoteIdeaRequest handler just queries the current total_contribution, then adds their new contribution and then updates SQL.

You might be wondering how we can use two steps to update the total_contribution? In normal SQL design, we should use a single-step atomic operation “increase” to update total_contribution. In TEA Project, all txn execution is serialized. No matter which hosting node sends the txn to the state machine maintainers, they will be sorted based on True Timestamp in every state machine. Because the True Timestamp comes from Global sync atomic clock (GPS), all maintainers will have the same sequence of all txns. The state machine will execute those sequencial txns one by one. There is no parallel execution. You don’t need to worry about multiple SQL statements executed in parallell causing race conditions. This model is more like the Ethereum EVM rather than SQL database.

Workflow

There’s nothing special to explain about the workflow. This is the typical TApp workflow which is the same as the tutorial app. Basically:

• Front end browser sends request to hosting node.
• Hosting node handles the request. If needed, it will generate txn to the state machine maintainer.
• State machine maintainers sort the txn from all hosting nodes. After a short buffer delay, all txns are executed one after another.
• State machine sends back the result of txn execution.
• The front end browser keeps querying for the result until the hosting node receives and relays the result back to the front end.
• Front end shows the UI update to the user.

In the next step, we’ll start to clone the code from the tutorial to make sure it can compile and run locally. Then we’ll modify the code to fit all the business logic specific to our TApp.

The best way to learn how to build a TApp is to read our dev tutorials. Developers can check out our developer docs tutorial section to learn about coding a TApp. One problem we hear from developers new to web3 is that they feel burdened having to learn about smart contracts (and smart contract tooling), new programming languages, and blockchain concepts. The TEA Project abstracts all of that away. Even though the TApp will leverage blockchain and run decentralized, you as the developer can use any Wasm-compatible language and even have an SQL database available.

The tutorial goes over how to create a Task TApp where anyone can propose a task along with a bounty reward. Anyone who wants to work on the task will put up a good faith deposit and receive both their deposit and the bounty when they finish the task.

Our idea depot voting app meshes well with the existing tutorial as the idea voting and task apps have many features in common. Because of their similarities, we’ll leverage the existing tutorial code base and make minimal changes.

Picking the Best Tutorial Starting Point

To build our idea depot voting TApp, we’ll find the closest step in the tutorial as our starting point. We’ll choose the following `Reward fund Transfer` branch as the closest starting point. You can find the link to that branch here.

We’re choosing this branch for the following reasons:

• It has a fund transfer feature. We’ll need this fund transfer functionality due to the deposit / collateral required when voting.
• It has basic SQL support which it inherits from the previous `SQL` step in the tutorial. We can use the basic SQL features and then add our own business logic on top.
• The Metamask login/out, account balance, and general main framework are all ready to use. These important features being available means that we don’t need to build our own.

So we can use this branch as our code base. But we’ll still add the following features that aren’t existing in the tutorial so far:

• We’ll create a new data structure called `idea`to hold the proposals.
• A SQL data structure to store idea content and voter address and deposit amount
• Modify the UI to shift away from task creater to idea creater. We’ll also need to make the content area larger since the idea may need more explanatory content than the original task content.
• Modify the `worker` UI logic to `voter` UI logic. The “take” button changes to “vote”. Additionally anyone can boost their vote, so we’ll also need to allow users to add to their existing vote amount.
• Add backend logic to handle voter voting event and adding to the existing deposit
• Add backend logic to calculate the total of all voters deposits added together to the creater’s deposit. Use this total to sort in SQL.
• Remove the `worker` take-task and task-confirmation logic. In the original tutorial, a worker can take a task after which the task creator can confirm it’s been done properly. After confirmation, the deposit would be released to the worker. We don’t have any such logic for anyone to “take” a task (and thus for the original creator to confirm it) for now.

Once we have the above changes, the original tutorial will turn into a new TApp Idea Voting app.

In the next section, we’ll start with the system design.

We at the TEA Project are often asked what kind of apps they should build using the forthcoming TApp SDK and dev tutorials. Developers are curious about what apps best utilize TEA’s decentralization, secure enclaves, and unstoppable compute layer. There has been a lot of discussion in our community with many of our community members contributing their own creative ideas. These include:

• Social media apps.
• Wager-based apps.
• Bridging web2 APIs to unlock web3 functionality.

We have a way to capture such ideas from our community through Github discussions. For example, we’ve already made a voting page specifically about expanding functionality for our Task TApp which you can find here.

Our main teaproject Github repo is open and anyone can create a discussion about ideas they have. But that got us thinking: why not use the TEA Project platform itself to mimic this functionality? Since we’re a software platform, why don’t we make this idea (of gathering and voting for ideas) into a TApp? So this is what prompted us to write this build series of posts that show developers can create their own voting application.

What Will the Idea Depot App Do?

Many content management systems in the web2 world have some functionality for voting on different topics to gauge what’s most popular with the community. For example, this is what it looks like in the Zendesk CRM:

We want to unlock the same functionality on web3 specifically as a TApp on the TEA Project platform. We’re going to be building a TApp that collects ideas for apps and allows voting on them. For our app idea we’re going to implement the following features:

• Everyone can post ideas about what TApps they want to build. For every TApp idea they post they’ll need to put up at least 1 T as an initial deposit for each idea.
• Everyone in the community can vote to support an idea by locking as collateral for their vote of at least 1T. All T collateral that’s put up for votes will be added to the initial deposit.
• Once a user has voted, they cannot withdraw their T-vote collateral. But they can increase their collateral deposit by voting again and adding at least 1T to their existing pledge.
• The ideas are ordered by the total deposit count. The higher the vote total, as measured by the total vote collateral (including the initial deposit), the higher its position will be in the app.
• We currently don’t have a worker feature for users to complete the voted-on idea as a task. So although an app idea can only remain in this TApp indefinitely, in the future this feature could be added.

One of the last missing pieces for this app is what to do at “task completion”. We can imagine these ideas for apps as being tasks waiting for completion, where “task completion” means completing the app idea and making it into a functional TApp. Perhaps the app will have another segment where the collected deposit for each idea will be released from escrow to a developer when certain conditions are met. This is beyond the scope of this write-up but we invite developers to think up creative ways to reward app developers for taking on the ideas as tasks.

Moving from Web2 to Web3

As mentioned, this kind of idea voting is typical and easy to implement as a web2 app. We have to move beyond the traditional web framework when designing such an app for web3. In the next section, we’ll look at how to design such a voting app from the ground up as a web3 app using the TEA Project framework.

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)

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 for the amount borrowed over time. 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 small 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 is calculated using the AMM curve. That means 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.

Genesis TEA Loans can be paid off in full or just the interest to extend the loan

In epoch 2.1, you couldn’t only pay the interest due to extend the loan. Now you can extend the loan as long as you pay the interest accrued by the end of the loan due date.

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:

Top up 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 approximate .0003 TEA balance necessary to make transactions, we’ve added back the top-up 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!

Mining machines are no longer free. Contestants will use COFFEE to buy one

You will 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. Going forward, 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: performing mining yourself or staking onto 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 are 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.

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 price of the token is calculated by the AMM based on each token’s bonding curve. Generally speaking, the earlier you invest, the lower the price.

(in this image, n > 1, but we set n = 1/2 and m = 1 and 0.7)

In epoch 3, we use the basic bonding curve of

The a is 1 for the buying curve, 0.7 for the selling curve. The integral

is used to calculate the TEA amount for the funding pool and the reserve pool.

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.

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 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.

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 for expenses.

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 true for the expenses, such as paying for hosting fees.

The bonding curve is constantly changing. Every consumption and expense event will make the price change a little. This is how a typical AMM (Automatic Market Maker) application works to attract venture capital.

Once you’ve invested in any TApps, you can see them on your Assets page under the My investment in TApps tab:

What if I have no idea about bonding curves and fancy equations?

It’s not important that you understand all the nuances of the bonding curve in order to use it effectively just as you don’t need to know how an engine works to drive a car. Very few people in the world totally understand how Wall Street works but they still use their financial services every day. Of course, those who understand the important aspects of the financial system are in a better position to make more money.

If you don’t yet understand how the bonding curve works to set prices, try to buy or sell a TApp’s token and notice how the price changes. Sooner or later you’ll get the gist of how the bonding curve price correlates with supply. Bonding curves are becoming an increasingly important part of more and more crypto projects, so learning about them now will put you ahead of those Wall Street people.

Epoch 3: hosting TApps = hosting income

TApps need to be hosted in mining machines to run. This is exactly what the TEA Project is designed for — to make a decentralized cloud computing platform.

If your mining machine starts without hosting any TApp, it just makes the basic RA (Remote Attestation FaaS public service fee). That amount is very little, not even enough to cover the COFFEE interest you paid for the loan amount to buy your machine. So to prevent financial insolvency, you have to find a more profitable usage of your mining machine, which is to host TApps and earn a hosting income. That is the better way to utilize your mining machine.

Host / unhost TApp

In the TApp list, you can host or unhost TApps for your mining CML. There are few important rules you will need to know.

Performance requirement and remaining performance

Your CML has to have enough remaining performance to cover the cost of the TApp’s Host performance requirement. Because your CML has limited performance, the TApps it can possibly host is also limited. With this limitation, you should be smart enough to choose the TApps that make the most out of your CML’s performance.

Current /Max hosts

For most TApps, as long as the hosting CML reaches a minimum threshold, the application performance will be good enough. More hosting CMLs for the TApp won’t increase performance past a point and sometimes might even cause the performance to degrade. So every TApp has to have an upper limit called Max hosts.

Another consideration is the cost of hosting. The more hosts a TApp has, the more the TApp will need to pay for its hosting fee. So if there’s a popular and profitable TApp in the list, you’ll need to rush to host it before it reaches the max hosts number.

In epoch 3, we simply set Max hosts to a fixed value. In real life, these numbers are constantly changing due to the scale changes as required by the TApp.

YTB TApp simulator

The TApps for epoch 3 will be simulated TApps each based on a YouTube video that covers some aspects of the TEA Project. We have a non-playing character (NPC) called sudo who will create 3 videos TApps, and pay TEA as a consume action every day based on the view numbers on YouTube. The sudo account will check YouTube view numbers at a moment in time each day. The one who has the largest increase will win the TEA for that day.

• The sudo account notes who has the largest gain in views compared to 24 hours ago and notes down the increased view count (let’s call it delta) of the winner for that day.
• The sudo account pays one TEA for each increased view of the winner (delta TEA in total) using the “consume” function every day. For example, let’s say video A has the most views in the past 24 hours. It was at 100 views yesterday but now is at 180 views today. Sudo will consume 80 TEA into video A’s TApp bonding curve.

Tips and tricks for new epoch 3

Many of you have probably gained many tips and tricks from epoch 2. Most of them are still valid for epoch 3, but some of the strategies will need changing. You can learn about and share your best strategies over at our mining contest strategy discussion.

Hosting and investments make much more than dumb mining

Dumb mining means you start a mining CML but do not host any TApps. In this case, the CML will only run public services like RA which makes very little money. To be more competitive, try hosting TApps to earn the hosting fee.

As long as you make some TEA from mining or simply from incurring COFFEE debt, use your TEA to invest in the bonding curve of TApps. If you invest in the correct TApp, it makes much more than the compound interest. Of course, if you don’t choose wisely, that will affect your standing on the leader board. Your total asset value is calculated based on how many TApp tokens you own multiplied by the current token price. Because the market cap of your bonding curve tokens is part of how your assets are evaluated on the leader board, it’s very important to choose your YTB TApp wisely.

YTB TApps contest

Contestants can choose to invest in YouTube videos TApp and then use their social influence to increase the value of their YTB Tapps investment. They can use curation marketing and their social media influence to pump up the views by sharing the YouTube link and spreading its popularity on social media.

This is the landing page: https://teaproject.org/landingpage/preview_1/

If you are interested in previewing how TEA mining looks like or would like to win the $1500 USDT award. Click the link above to register and join the TEA mining competition.

Once you click the link and get to the landing page, you can get the basic information. The register form shows when you click “Join Now” or “Get Started”.

Your email, TEA address, and ERC20 address will be put on our waiting list.

Once Epoch 2.1 is ready to start, we will announce on our telegram channel https://t.me/teaprojectorg .

If you cannot wait or would like to practice before the real game starts, please leave a Medium post comment below with your TEA address (the Polkadot account address, starts with “5…”). I will add your address to our Epoch 1.xx testing which is happening now. So that you can start testing within one day.

What is Epoch?

During early-stage testing, we will restart the chain frequently. Every time we restart the chain, it is called a new epoch. All assets will be reset in the new epoch. Since the assets in the contest net are not real money, so you do not really care, do you? The only thing you do care about probably is the award. We will send awards to your ERC20 address at the end of each epoch.

Every time we restart the contest net, there will be some bug fix and business logic change. You will note an epoch number here:

Assuming you are registering Epoch 2.1, you will need to wait for your turn when this number becomes 2.1. You can see we are still running 1.13, which means it is the 13th epoch we are running. If you would like to preview and practice, we will invite you to our next 1.14 or 1.15 epoch if you leave comments below.

Joining the testing in 1.xx epoch as a front-runner

The real competition starts from Epoch 2.1. Right now, we are running internal testing. If you join the internal testing, you will not get awarded. And you are required to report bugs to our Github repo https://github.com/tearust/tea-browser-wallet.

Your benefits are that you will learn how to use the TEA mining wallet, and, most important, the best competitive strategy you should use before your competitors learn. You are technically a front-runner!

Notes:

• Epoch 1.xx may restart without notice. If you found your assets are all gone, this is not communist, this is restart. You will notice the Epoch number bumps.
• There are bugs. That’s why we invite you to test. If you see something, say something
• Join our telegram group and GitHub discussion board for your question https://github.com/tearust/teaproject/discussions/
• Again, there is no award for epoch 1.xx. Your award is waiting for you in epoch 2.1

Happy mining/farming!

He is a professional tech writer who was major in English and familiar with blockchain technologies. We spend a full day together in my office discussing my dream of the Trusted Web 3.0. Right after the discussion, he wrote his first impression on TEA Project.

First Impression of TEA Series #1

I have to say although he just spends a few days with me, he can write a much better introduction article than I can do for the last few years. We can see more awesome tech introductions from him very soon.

Miners 2 questions:

If the TEA project were Uber for cloud computing, miners are drivers. The incentive to the drivers is the fuel to drive the TEA token economy. Unlike centralized company can pay salaries or own those nodes, in the blockchain world, a carefully designed token economy can keep the system running and create speculation to boost growth.

Rather than the big dream of the TEA project, what miners care about is just ROI. Just two questions from miners:

1. How much tokens I can mine on a particular investment (hardware, maintenance, time)
2. Will the token pricing increase and maintain the value?

Green mining? or no, green farming!

Comparing with other crypto-mining projects, the TEA project is very “green”. It doesn’t burn huge energy with greedy processors, and it doesn’t need to fill up hard drive spaces. It can run on small, inexpensive IoT machines. So the hardware is no longer an issue and source of cost. The majority of the cost comes from the Camellia NFT.

Positive infinity loop

For miners to get camellia seeds, an auction is required, and miners must pay TEA as currency. When new camellia seeds are generated and sold through the bidding, the DAO burns the TEA paid by the bidder. Because the supply of the seeds is heavily controlled and limited, the price could increase sharply as long as more miners want to buy seeds. Miners want to purchase the seeds simply because mining TEA is profitable, which means the TEA price is high. The TEA price is going high because TEA supply drops. TEA supply drops because DAO burns TEA, and the initial harvest outcome is low (Camellia needs time to grow). DAO burns TEA because miners want to buy the seeds. This circulation becomes an infinity loop. As long as it can cold-start, it would run as expected. Now let’s see how it could start?

Cold start

In the beginning, there are no TEA tokens in the TEA blockchain. There are only frozen Camellia seeds (the NFT). Based on the logic settings, there are only a very few seeds are defrosted at the beginning. They belong to the early investors. They start mining and harvest TEA at a relatively low outcome rate because the camellia needs time to grow. The TEA supply is minimal at this point, and all the TEA owners are early investors. They are supposed to know the value of TEA and Camellia. Otherwise, they won’t invest in the TEA Project. Since they know, they are not likely to dump the TEA in the market. Instead, they would invest their harvest TEA to more staking slots and start more mining nodes to plant their camellia seeds. The logic is that they can occupy the best staking slots position, which is scarce over a long period. For example, if you got the insider message that a train station will be built somewhere, most likely, you will buy the surrounding land before everyone else knows. If most of the early TEA tokens are used in reinvest, there would be limited supply in the market. No doubt the TEA price will go high, not to mention the investors have tons of money to buy more TEA tokens from the market.

Interestingly enough that if the TEA price goes high, the more profitable for the TEA farming business. If the TEA farming is profitable, more miners would like to jump the TEA farming, but they need TEA to buy Camellia seeds. So the TEA price goes higher and higher.

What if someone dumps?

Even most of the early investors are rational and will reinvest. There is no way to prevent someone from trying to dump TEA in the market. As I mentioned above, at the early stage, the harvest outcome of TEA is minimal. There should not be too much TEA farmed and sold on the market. It would be much easier for the market maker to buy in the keep the price healthy. As long as the price can keep at a healthy level and increase gradually, those who sold the TEA previously would regret their irrational behavior. Therefore, the dump can be digested by the majority of miners.

Leverage existing IPFS miners

Building a new miners community is very hard. The TEA project won’t create such a new community from scratch. Leveraging the existing community is the key. The TEA project can bring value to them. For example, IPFS miners can merge mining the FIL and TEA. TEA makes IPFS into “Interplanetary Function as a Service” rather than a pure file system. TEA dApps need code and data storage on IPFS, which brings real use case to IPFS. Other smart contract platforms, DOT, ETH, can offload their computing load to TEA. This offloading is not a diversion of their profit but creates more rich computing demands that are originally not doable in their blockchain. In return, more dApps run on their blockchain generates more revenue. TEA is not trying to compete to or diverse profit from other partners, but to create new demands benefits all.

Eventually, the demand and usage of TEA token is the key

No matter how well we design the miners’ economy to boost the TEA initially, it is still a short-term solution. In the long run, the key is the demand for usage of TEA tokens. The TEA project team has started working on the so-called Rich dApps that run on TEA networks. Building the ecosystem, especially leveraging the existing FIL, ETH, DOT ecosystem, is the team’s main goal. The TEA Project team has started looking for cooperation with other major players to build the fusion ecosystem. One example is if we add the computing module to the IPFS. The IPFS miners can merge mine both FIL and TEA. The dApps also need to store data and code on IPFS, bringing more real use cases for IPFS. This is a win-win-win situation.

Let’s see what our real-life economy runs.

The USD is a worldwide currency. Assume USD is a stable coin although it inflated faster and faster. You are not supposed to keep the USD bill in your vault and expect it to grow, right? What you are gonna do? Of course, to invest. Let’s see you invest your USD capital in businesses. Every business in the market is an NFT. The business born, grows, and eventually dies. Every business is unique. It has a different business model, different management team, different life span. If you invest in a blue-chip or early start-up, you will have different gains and risks. Rain or shine, most investors make more money than keep their money sleep in the bank account.

Let’s turn back to the TEA economy. $T is USD. Holding $T in your Gluon wallet won’t make you rich. You will need to invest. You can use your $T to buy Camellia seed and grow it. You can either make money from the $T generated from the Camellia mining or just simply sell it after it grows up. Remember the young camellia won’t be as productive as a grown one. So the price will be different by their age. Another choice is to buy other miner’s staking slots. In this case, you gain the shared revenue from other miners. Because every camellia is a different NFT, and every slot has a different “weight”. Find the ideal slots to invest is the key to your investment strategy. This is just like investing in a start-up or a blue-chip. All have their own pros and cons.

If you are smart and not too greedy, you can probably earn a lot from investing your $T in the TEA economy rather than sell them in the market. This helps “lock” the $T and maintain a stable $T token price. Especially in the early stage of the TEA eco-system.

There are a lot of detailed designs on the TEA token economy. I am trying to design an ideal token economy based on what I learn from economics.