This commit is contained in:
54
docs/core-concepts/burning.md
Normal file
54
docs/core-concepts/burning.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Burning
|
||||
|
||||
## Token Model Overview
|
||||
|
||||
Token burning permanently removes tokens from circulation.
|
||||
When a percentage of real revenue is used to **buy and burn tokens**, it directly reduces the total supply, creating scarcity.
|
||||
If demand stays constant or increases, the token price naturally rises.
|
||||
|
||||
---
|
||||
|
||||
## Base Assumptions
|
||||
|
||||
| Parameter | Value |
|
||||
| -------------------------- | --------------------------------------------- |
|
||||
| TFT Price (initial) | $0.10 |
|
||||
| Market Cap (Fully Diluted) | $100,000,000 |
|
||||
| Burn on Revenue | 10% |
|
||||
| Revenue over 4 years | $1,000,000,000 |
|
||||
| Tokens Burned | 1,000,000,000 |
|
||||
| Tokens Left | 0 |
|
||||
| Market Size Reference | Cloud & AI markets worth several trillion USD |
|
||||
|
||||
|
||||
> Conclusion: There can never be 0 tokens in a functioning economy, so the price will keep rising as supply decreases.
|
||||
|
||||
---
|
||||
|
||||
## Step-by-Step Logic
|
||||
|
||||
1. **Starting Condition**
|
||||
There are 1 billion TFT tokens in circulation, each worth $0.10, giving a $100 million total market cap.
|
||||
|
||||
2. **Revenue-Driven Burn**
|
||||
Ten percent (10%) of all generated revenue is used to purchase tokens on the open market and destroy them.
|
||||
This converts real economic activity into direct buying pressure.
|
||||
|
||||
3. **Cumulative Effect**
|
||||
Over four years, with $1 billion in revenue, $100 million is used to buy TFT at market prices.
|
||||
At $0.10 per token, this burns the full 1 billion tokens.
|
||||
|
||||
4. **Deflationary Result**
|
||||
As supply decreases, each remaining token represents a larger claim on the network’s total value.
|
||||
Even if only part of the supply is burned, the reduced float and consistent demand drive higher prices.
|
||||
|
||||
5. **Price Appreciation Mechanism**
|
||||
|
||||
* Demand from users and investors remains or grows.
|
||||
* Supply falls due to the burn.
|
||||
* The balance of supply and demand shifts upward, increasing token price to maintain total market value.
|
||||
|
||||
30
docs/core-concepts/liquidity-pool.md
Normal file
30
docs/core-concepts/liquidity-pool.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
|
||||
## Liquidity Pool
|
||||
|
||||
There will be multiple liquidity pools. Each pool serves a specific purpose and has its own rules and mechanisms.
|
||||
|
||||
We want to launch the liquidity pools 1-1-2026
|
||||
|
||||
|
||||
### CC-TFT
|
||||
|
||||
- **Function**: Enables conversion between TFT and CC, its a position based liquidity pool.
|
||||
- **Source of Funds**: Only CC generated from revenue can be converted into TFTF
|
||||
- **Purpose**: Facilitates internal settlements and allows revenue to be converted into an asset (TFTF) that reflects the market value of TFT
|
||||
- **Flexibility**: Allows users to maintain TFT exposure while holding stable CC
|
||||
|
||||
### CC-USDC Pool
|
||||
|
||||
- **Function**: Provides a controlled bridge between the internal ecosystem (TFTF) and an external stablecoin (USDC)
|
||||
- **Purpose**: Enables fiat exit for operational needs while protecting against system drainage
|
||||
|
||||
**Rules:**
|
||||
- **Dutch Auction Principles**: The pool operates based on [Dutch auction mechanics](./dutch-auction-exit.md)
|
||||
- **Liquidity Cap**: No more than 5% of the USDC liquidity in the pool can be used in a single transaction or period to prevent dramatic price shifts
|
||||
- **Minimum Margin**: A minimum discount of 20% is maintained, ensuring a margin for the pool
|
||||
- **Position-Based Pool**: The pool's mechanics are based on its current position and liquidity. More info at [Position Based LP](./position-based-lp.md)
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Token System
|
||||
@@ -8,87 +8,57 @@ Our ecosystem uses a multi-currency system to ensure both stability for utility
|
||||
|
||||
## Token Types
|
||||
|
||||
## TFP (ThreeFold Point) = is same as TFT but only exists in the marketplace
|
||||
|
||||
- **Definition**: TFP is a converted TFT and only exists within the marketplace ecosystem for internal accounting and settlements.
|
||||
- 1 TFP = 1 TFT (at time of conversion)
|
||||
- TFP cannot be converted back to TFT until the market price of TFT exceeds the fixed conversion rate of CC to TFP (see below in swap section).
|
||||
- in other words if on public markets the TFT is prices higher than 1 CC in USD value then you can convert back.
|
||||
- Once the market price surpasses the fixed rate, users can return TFP to unlock their original TFT.
|
||||
- When a user buys storage, compute, or bandwidth, they pay in CC, but the settlement to farmers is done in TFP.
|
||||
- When users convert to TFP, their TFT is locked until they return TFP to unlock their TFT.
|
||||
|
||||
### TFT (ThreeFold Token)
|
||||
|
||||
- **Type**: Tradable reserve asset
|
||||
- **Availability**: Traded on public blockchains
|
||||
- **Characteristics**: Price can be volatile, currently trading at artificially low prices
|
||||
- **Role**: Market-facing asset and entry gateway into the ecosystem
|
||||
- **Supply**: Scarce, capped at 1 billion maximum
|
||||
- Not directly usable inside the marketplace, must be converted to TFP first
|
||||
|
||||
### CC (Cloud Credit)
|
||||
|
||||
- **Type**: Stable utility token
|
||||
- **Peg**: 1/1000 of a gram of gold (0.001g)
|
||||
- **Availability**: Only circulates within the digital marketplace (non-tradable)
|
||||
- **Purpose**: Primary medium of exchange for services within the ecosystem
|
||||
- **Acquisition**: Users can acquire CC at a fixed rate of **1 CC for 2 TFT**, until the market price of TFT surpasses this rate
|
||||
- **Generation**: Minted when users enter with TFT or credit card, burned when exiting
|
||||
|
||||
### TFTF (TFT Future)
|
||||
- **Type**: Internal accounting token
|
||||
- **Link**: Tied to the market price of TFT
|
||||
- **Purpose**: Used for internal accounting and liquidity management
|
||||
- **Function**: Represents a future claim on TFT
|
||||
---
|
||||
|
||||
This system is supported by three distinct liquidity pools that manage the flow of value between these currencies and external markets.
|
||||
## Swaps
|
||||
|
||||
---
|
||||
### TFP to CC Swap (both directions)
|
||||
|
||||
## Liquidity Pools
|
||||
- **Function**: Allows users to swap TFP for CC at a fixed rate, which either mints new CC or burns existing CC
|
||||
- **Acquisition**: Users can acquire CC at a fixed rate of **1 CC for 2 TFP**, until the market price of TFP surpasses this rate
|
||||
- Open Question: maybe it should be 1 CC = 1 TFP? Lets use forum to decide.
|
||||
|
||||
There are three liquidity pools to manage the ecosystem's economy:
|
||||
### USD to CC Swap (one way)
|
||||
|
||||
### 1. TFT to CC Swap (One-Way)
|
||||
- **Function**: Allows users to purchase CC directly with USD via credit card
|
||||
- **Rate**: Fixed rate of 1 CC = $0.128 (as of Oct 8, 2025, changes as the price of gold changes)
|
||||
- **Purpose**: Provides an easy entry point for new users unfamiliar with TFT or cryptocurrencies
|
||||
- **USD Treasury**: USD collected is held in a treasury to back the CC in circulation
|
||||
|
||||
- **Function**: Allows users to swap TFT for CC at a fixed rate, which either mints new CC or burns existing CC
|
||||
- **Direction**: This is a one-way path; CC cannot be converted back to TFT through this mechanism for now
|
||||
- **Purpose**: Provides a simple and predictable on-ramp for users to acquire Cloud Credits for service payments
|
||||
- **Note**: This is not a liquidity pool but a direct mint/burn swap
|
||||
---
|
||||
|
||||
**How it works:**
|
||||
1. Users enter with TFT or credit card
|
||||
2. TFT gets **locked** (not converted)
|
||||
3. Equivalent CC is **minted** based on the lock
|
||||
4. Users receive CC in their wallet
|
||||
## Link to Revenue
|
||||
|
||||
### 2. TFTF to CC Pool (Two-Way)
|
||||
|
||||
- **Function**: Enables conversion between TFTF and CC based on the internal currency rate
|
||||
- **Source of Funds**: Only CC generated from revenue can be converted into TFTF
|
||||
- **Purpose**: Facilitates internal settlements and allows revenue to be converted into an asset (TFTF) that reflects the market value of TFT
|
||||
- **Flexibility**: Allows users to maintain TFT exposure while holding stable CC
|
||||
|
||||
### 3. TFTF-USDC Pool (Controlled Two-Way)
|
||||
|
||||
- **Function**: Provides a controlled bridge between the internal ecosystem (TFTF) and an external stablecoin (USDC)
|
||||
- **Purpose**: Enables fiat exit for operational needs while protecting against system drainage
|
||||
|
||||
**Rules:**
|
||||
- **Dutch Auction Principles**: The pool operates based on [Dutch auction mechanics](./dutch-auction-exit.md)
|
||||
- **Liquidity Cap**: No more than 5% of the USDC liquidity in the pool can be used in a single transaction or period to prevent dramatic price shifts
|
||||
- **Minimum Margin**: A minimum discount of 20% is maintained, ensuring a margin for the pool
|
||||
- **Position-Based Pool**: The pool's mechanics are based on its current position and liquidity. More info at [Position Based LP](./position-based-lp.md)
|
||||
|
||||
---
|
||||
|
||||
## Minting and Burning of CC
|
||||
|
||||
The creation (minting) and destruction (burning) of Cloud Credits (CC) is a straightforward process tied to market activity.
|
||||
|
||||
### Minting
|
||||
CC is minted when a user **buys** it, either with TFT or by converting TFTF. This ensures that every CC in circulation is backed by an equivalent value.
|
||||
|
||||
### Burning
|
||||
CC is burned when it is **sold** or used to pay for services that are then settled in TFTF.
|
||||
|
||||
### Key Principle: Mint and Destroy Cycle
|
||||
|
||||
When users exit from CC:
|
||||
1. Users request to exit from CC
|
||||
2. CC is **destroyed/burned**
|
||||
3. Locked TFT is **released** back to the user
|
||||
4. Exit is subject to liquidity pool rules and Dutch auction mechanics
|
||||
|
||||
This simple in-out mechanism guarantees that the supply of CC directly reflects the real-time demand and economic activity within the ecosystem. **The system doesn't create unbacked credits**; it only issues them when value is deposited.
|
||||
- Hosters (farmers) are paid in TFP, which they can convert to TFT or hold for potential appreciation (80% of revenue)
|
||||
- 10% of revenue is burned to reduce supply and maintain peg stability, burned TFT.
|
||||
- 10% of revenue goes to ThreeFold Foundation for ecosystem development and maintenance
|
||||
|
||||
---
|
||||
|
||||
@@ -101,7 +71,3 @@ This multi-token architecture solves several critical problems:
|
||||
- **Controlled Liquidity**: Prevents sudden token dumps while maintaining fairness
|
||||
- **Sustainable Growth**: Minting/burning mechanisms ensure backing and prevent inflation
|
||||
- **Operational Viability**: Farmers receive stable CC for planning while retaining TFT exposure options
|
||||
|
||||
:::tip Next Steps
|
||||
Learn more about how this system prevents impermanent loss and rewards long-term participation in [Position-Based Liquidity Pools](./position-based-lp.md).
|
||||
:::
|
||||
|
||||
8
docs/roadmap/_category_.json
Normal file
8
docs/roadmap/_category_.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"label": "Roadmap",
|
||||
"position": 5,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"description": "Roadmap."
|
||||
}
|
||||
}
|
||||
@@ -4,10 +4,10 @@ sidebar_position: 1
|
||||
|
||||
# Liquidity Pools: Simplified Overview
|
||||
|
||||
Our ecosystem uses three interconnected liquidity pools to manage the flow of value between tokens and external markets. This page provides a high-level understanding before diving into the detailed mechanics.
|
||||
Our ecosystem uses interconnected liquidity pools to manage the flow of value between tokens and external markets. This page provides a high-level understanding before diving into the detailed mechanics.
|
||||
|
||||
:::tip Start Here
|
||||
If you're new to the system, read this overview first. Then explore the detailed documentation on [Position-Based Pools](/core-concepts/position-based-lp) and [Dutch Auction Exits](/core-concepts/dutch-auction-exit).
|
||||
If you're new to the system, read this overview first. Then explore the detailed documentation on [Position-Based Pools](/roadmap/position-based-lp) and [Dutch Auction Exits](/roadmap/dutch-auction-exit).
|
||||
:::
|
||||
|
||||
---
|
||||
@@ -120,14 +120,14 @@ Margin benefit: Goes to remaining pool members
|
||||
|
||||
## Traditional DeFi vs. Our Approach
|
||||
|
||||
| Feature | Traditional Liquidity Pools | ThreeFold Position-Based Pools |
|
||||
|---------|---------------------------|-------------------------------|
|
||||
| **LP Tokens** | Floating value tokens issued | No tokens - fixed positions tracked |
|
||||
| **Your Share** | Changes with market volatility | Fixed based on contribution + time |
|
||||
| **Exit** | Instant (swap LP tokens) | Controlled (Dutch auction) |
|
||||
| **Impermanent Loss** | Yes - you lose value in volatile markets | No - your position doesn't change |
|
||||
| **Gaming Risk** | Front-running, sandwich attacks | Protected by time-weighting |
|
||||
| **Best For** | Active traders | Long-term supporters |
|
||||
| Feature | Traditional Liquidity Pools | ThreeFold Position-Based Pools |
|
||||
| -------------------- | ---------------------------------------- | ----------------------------------- |
|
||||
| **LP Tokens** | Floating value tokens issued | No tokens - fixed positions tracked |
|
||||
| **Your Share** | Changes with market volatility | Fixed based on contribution + time |
|
||||
| **Exit** | Instant (swap LP tokens) | Controlled (Dutch auction) |
|
||||
| **Impermanent Loss** | Yes - you lose value in volatile markets | No - your position doesn't change |
|
||||
| **Gaming Risk** | Front-running, sandwich attacks | Protected by time-weighting |
|
||||
| **Best For** | Active traders | Long-term supporters |
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user