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
|
# Token System
|
||||||
@@ -8,87 +8,57 @@ Our ecosystem uses a multi-currency system to ensure both stability for utility
|
|||||||
|
|
||||||
## Token Types
|
## 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)
|
### TFT (ThreeFold Token)
|
||||||
|
|
||||||
- **Type**: Tradable reserve asset
|
- **Type**: Tradable reserve asset
|
||||||
- **Availability**: Traded on public blockchains
|
- **Availability**: Traded on public blockchains
|
||||||
- **Characteristics**: Price can be volatile, currently trading at artificially low prices
|
- **Characteristics**: Price can be volatile, currently trading at artificially low prices
|
||||||
- **Role**: Market-facing asset and entry gateway into the ecosystem
|
- **Role**: Market-facing asset and entry gateway into the ecosystem
|
||||||
- **Supply**: Scarce, capped at 1 billion maximum
|
- **Supply**: Scarce, capped at 1 billion maximum
|
||||||
|
- Not directly usable inside the marketplace, must be converted to TFP first
|
||||||
|
|
||||||
### CC (Cloud Credit)
|
### CC (Cloud Credit)
|
||||||
|
|
||||||
- **Type**: Stable utility token
|
- **Type**: Stable utility token
|
||||||
- **Peg**: 1/1000 of a gram of gold (0.001g)
|
- **Peg**: 1/1000 of a gram of gold (0.001g)
|
||||||
- **Availability**: Only circulates within the digital marketplace (non-tradable)
|
- **Availability**: Only circulates within the digital marketplace (non-tradable)
|
||||||
- **Purpose**: Primary medium of exchange for services within the ecosystem
|
- **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
|
- **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:**
|
## Link to Revenue
|
||||||
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
|
|
||||||
|
|
||||||
### 2. TFTF to CC Pool (Two-Way)
|
- 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.
|
||||||
- **Function**: Enables conversion between TFTF and CC based on the internal currency rate
|
- 10% of revenue goes to ThreeFold Foundation for ecosystem development and maintenance
|
||||||
- **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.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
@@ -101,7 +71,3 @@ This multi-token architecture solves several critical problems:
|
|||||||
- **Controlled Liquidity**: Prevents sudden token dumps while maintaining fairness
|
- **Controlled Liquidity**: Prevents sudden token dumps while maintaining fairness
|
||||||
- **Sustainable Growth**: Minting/burning mechanisms ensure backing and prevent inflation
|
- **Sustainable Growth**: Minting/burning mechanisms ensure backing and prevent inflation
|
||||||
- **Operational Viability**: Farmers receive stable CC for planning while retaining TFT exposure options
|
- **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
|
# 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
|
:::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
|
## Traditional DeFi vs. Our Approach
|
||||||
|
|
||||||
| Feature | Traditional Liquidity Pools | ThreeFold Position-Based Pools |
|
| Feature | Traditional Liquidity Pools | ThreeFold Position-Based Pools |
|
||||||
|---------|---------------------------|-------------------------------|
|
| -------------------- | ---------------------------------------- | ----------------------------------- |
|
||||||
| **LP Tokens** | Floating value tokens issued | No tokens - fixed positions tracked |
|
| **LP Tokens** | Floating value tokens issued | No tokens - fixed positions tracked |
|
||||||
| **Your Share** | Changes with market volatility | Fixed based on contribution + time |
|
| **Your Share** | Changes with market volatility | Fixed based on contribution + time |
|
||||||
| **Exit** | Instant (swap LP tokens) | Controlled (Dutch auction) |
|
| **Exit** | Instant (swap LP tokens) | Controlled (Dutch auction) |
|
||||||
| **Impermanent Loss** | Yes - you lose value in volatile markets | No - your position doesn't change |
|
| **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 |
|
| **Gaming Risk** | Front-running, sandwich attacks | Protected by time-weighting |
|
||||||
| **Best For** | Active traders | Long-term supporters |
|
| **Best For** | Active traders | Long-term supporters |
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
Reference in New Issue
Block a user