Initial commit: TFGrid Economics documentation site
Some checks failed
Deploy to GitHub Pages / Deploy to GitHub Pages (push) Has been cancelled
Some checks failed
Deploy to GitHub Pages / Deploy to GitHub Pages (push) Has been cancelled
- Based on working minting_plan repository - Configured for threefold.info/economics deployment - Added ops documentation for server deployment - Updated baseUrl and URL configuration
This commit is contained in:
mik-tf
39
.github/workflows/deploy.yml
vendored
Normal file
39
.github/workflows/deploy.yml
vendored
Normal file
@@ -0,0 +1,39 @@
|
||||
name: Deploy to GitHub Pages
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
contents: write
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
name: Deploy to GitHub Pages
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 20
|
||||
cache: npm
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm install
|
||||
|
||||
- name: Build website
|
||||
run: npm run build
|
||||
|
||||
- name: Deploy to GitHub Pages
|
||||
uses: peaceiris/actions-gh-pages@v3
|
||||
with:
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
publish_dir: ./build
|
||||
user_name: github-actions[bot]
|
||||
user_email: github-actions[bot]@users.noreply.github.com
|
||||
27
.gitignore
vendored
Normal file
27
.gitignore
vendored
Normal file
@@ -0,0 +1,27 @@
|
||||
# Dependencies
|
||||
/node_modules
|
||||
|
||||
# Production
|
||||
/build
|
||||
|
||||
# Generated files
|
||||
.docusaurus
|
||||
.cache-loader
|
||||
|
||||
# Misc
|
||||
.DS_Store
|
||||
.env.local
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
|
||||
# IDE
|
||||
.idea
|
||||
.vscode
|
||||
*.swp
|
||||
*.swo
|
||||
*~
|
||||
147
README.md
Normal file
147
README.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# TFT Minting Transition Plan
|
||||
|
||||
Community e-book for the ThreeFold Token (TFT) minting transition plan.
|
||||
|
||||
**Live Site**: https://plan.threefold.pro
|
||||
|
||||
## Overview
|
||||
|
||||
This repository contains the documentation for the TFT Minting Transition Plan, a comprehensive proposal for transitioning ThreeFold's token economics to a more sustainable and community-oriented model. The plan introduces:
|
||||
|
||||
- **Dual Token System**: TFT (tradable) and Cloud Credits (stable utility)
|
||||
- **Position-Based Liquidity Pools**: Fair, time-weighted rewards
|
||||
- **Dutch Auction Exit Mechanism**: Controlled, sustainable liquidity
|
||||
- **Yin-Yang Currency Philosophy**: Balancing market and community
|
||||
|
||||
## Quick Start
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Node.js 18+
|
||||
- npm
|
||||
|
||||
### Installation
|
||||
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/mik-tf/minting_plan.git
|
||||
cd minting_plan
|
||||
|
||||
# Install dependencies
|
||||
npm install
|
||||
|
||||
# Start development server
|
||||
npm start
|
||||
```
|
||||
|
||||
The site will open at `http://localhost:3000`.
|
||||
|
||||
### Build
|
||||
|
||||
```bash
|
||||
# Create production build
|
||||
npm run build
|
||||
|
||||
# Serve production build locally
|
||||
npm run serve
|
||||
```
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
minting_plan/
|
||||
├── docs/ # Documentation content
|
||||
│ ├── intro.md # Homepage/Introduction
|
||||
│ ├── core-concepts/ # Core finance concepts
|
||||
│ ├── appendix/ # Meeting notes & resources
|
||||
│ └── ops/ # Operations documentation
|
||||
├── static/ # Static assets
|
||||
│ ├── img/ # Images
|
||||
│ └── CNAME # Custom domain config
|
||||
├── src/ # Custom components & styles
|
||||
│ └── css/
|
||||
│ └── custom.css # Custom styling
|
||||
├── docusaurus.config.js # Docusaurus configuration
|
||||
├── sidebars.js # Sidebar structure
|
||||
└── package.json # Dependencies
|
||||
```
|
||||
|
||||
## Contributing
|
||||
|
||||
### Making Changes
|
||||
|
||||
1. Pull latest changes:
|
||||
```bash
|
||||
git pull origin main
|
||||
```
|
||||
|
||||
2. Make your edits in `docs/`
|
||||
|
||||
3. Test locally:
|
||||
```bash
|
||||
npm start
|
||||
```
|
||||
|
||||
4. Test production build:
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
5. Commit and push:
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Description of changes"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
6. GitHub Actions automatically deploys to https://plan.threefold.pro
|
||||
|
||||
### Content Guidelines
|
||||
|
||||
- Write clear, concise documentation
|
||||
- Use proper Markdown formatting
|
||||
- Add alt text to images
|
||||
- Test builds before pushing
|
||||
- See [Content Updates Guide](./docs/ops/content-updates.md) for details
|
||||
|
||||
## Deployment
|
||||
|
||||
This site automatically deploys to GitHub Pages via GitHub Actions when you push to the `main` branch.
|
||||
|
||||
- **Domain**: plan.threefold.pro
|
||||
- **Branch**: gh-pages (auto-generated)
|
||||
- **Build Time**: ~2-3 minutes
|
||||
|
||||
See [Deployment Guide](./docs/ops/deployment.md) for full details.
|
||||
|
||||
## Community Feedback
|
||||
|
||||
We welcome community feedback on this plan through:
|
||||
|
||||
- **Telegram**: https://t.me/threefoldfarmers
|
||||
- **Forum**: https://forum.threefold.io
|
||||
- **Community Call**: https://bit.ly/tfcommunitycall
|
||||
|
||||
## Documentation
|
||||
|
||||
Full documentation available at:
|
||||
- [Local Development](./docs/ops/local-development.md)
|
||||
- [Deployment](./docs/ops/deployment.md)
|
||||
- [Content Updates](./docs/ops/content-updates.md)
|
||||
|
||||
## Technology Stack
|
||||
|
||||
- [Docusaurus 3](https://docusaurus.io/) - Documentation framework
|
||||
- [React 18](https://react.dev/) - UI library
|
||||
- [GitHub Pages](https://pages.github.com/) - Hosting
|
||||
- [GitHub Actions](https://github.com/features/actions) - CI/CD
|
||||
|
||||
## License
|
||||
|
||||
Copyright © 2025 ThreeFold
|
||||
|
||||
## Links
|
||||
|
||||
- [ThreeFold](https://threefold.io)
|
||||
- [ThreeFold Forum](https://forum.threefold.io)
|
||||
- [Telegram Community](https://t.me/threefoldfarmers)
|
||||
8
docs/core-concepts/_category_.json
Normal file
8
docs/core-concepts/_category_.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"label": "Core Concepts",
|
||||
"position": 2,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"description": "Fundamental mechanisms of the TFT minting transition plan."
|
||||
}
|
||||
}
|
||||
128
docs/core-concepts/dutch-auction-exit.md
Normal file
128
docs/core-concepts/dutch-auction-exit.md
Normal file
@@ -0,0 +1,128 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# Dutch Auction Exit: Fair and Controlled Liquidity Release
|
||||
|
||||
To keep our liquidity pool strong and sustainable, we use a Dutch auction system for exits. This creates a market-driven, disciplined, and fair process that protects long-term participants and discourages opportunistic withdrawals.
|
||||
|
||||
## Why a Dutch Auction?
|
||||
|
||||
Unlike open liquidity pools where anyone can withdraw anytime, a Dutch auction:
|
||||
|
||||
- Prevents sudden value loss or pool drain
|
||||
- Encourages long-term holding by adding discipline to exits
|
||||
- Ensures price discovery — exits only happen at a price the market agrees on
|
||||
|
||||
## Key Principles
|
||||
|
||||
### 1. No Timing Advantage
|
||||
|
||||
Everyone can submit their bids before the auction closes. It doesn't matter when you bid — what matters is how low you're willing to go.
|
||||
|
||||
### 2. Price Determines Priority
|
||||
|
||||
Those who are willing to exit at a lower price per token (i.e. accept a greater discount) get filled first. If more exits are requested than the system allows, only the lowest-price bids are executed.
|
||||
|
||||
### 3. Capped Exit Volume
|
||||
|
||||
Only up to 50% of total liquidity ever contributed (minus past exits) is allowed to leave through Dutch auctions. This cap protects the pool from being drained.
|
||||
|
||||
---
|
||||
|
||||
## How It Works — Step by Step
|
||||
|
||||
### 1. Bids Are Submitted
|
||||
|
||||
Liquidity providers (LPs) submit a request like:
|
||||
|
||||
*"I want to exit with €500,000, and I'm willing to sell my tokens at no less than €0.092 each."*
|
||||
|
||||
### 2. Bids Are Sorted by Price (Low to High)
|
||||
|
||||
The system ranks all bids from lowest price to highest — those willing to accept the biggest discount come first.
|
||||
|
||||
### 3. Clearing Price Is Found
|
||||
|
||||
The auction accepts bids from the bottom up (lowest price first) until the total exit amount hits the allowed maximum (e.g., €3 million).
|
||||
|
||||
The last bid that fits sets the **clearing price** — everyone who bid at or below this price exits at that same clearing price.
|
||||
|
||||
### 4. Settlement
|
||||
|
||||
Successful LPs receive their share of the paired token (e.g., USDC or mg Gold). Others can try again in the next round.
|
||||
|
||||
---
|
||||
|
||||
## Example Scenario
|
||||
|
||||
Let's say:
|
||||
|
||||
- Max exit allowed this round = €3 million
|
||||
- There can be other rules too (e.g., minimum price thresholds)
|
||||
- LPs submit the following bids:
|
||||
|
||||
| LP | Amount | Minimum Price |
|
||||
|----|--------|----------------|
|
||||
| A | €500k | €0.088 |
|
||||
| B | €600k | €0.090 |
|
||||
| C | €400k | €0.092 |
|
||||
| D | €700k | €0.095 |
|
||||
| E | €300k | €0.098 |
|
||||
| F | €200k | €0.100 |
|
||||
| G | €500k | €0.105 |
|
||||
| H | €400k | €0.110 |
|
||||
|
||||
After sorting from lowest price to highest, we fill bids starting from the bottom. The system stops when total accepted bids reach €3 million.
|
||||
|
||||
Suppose this happens at **LP F's bid at €0.100** — that becomes the clearing price.
|
||||
|
||||
**Result**: Everyone who bid €0.100 or lower gets filled at €0.100, even if they asked for less.
|
||||
|
||||
Bids above €0.100 are not executed.
|
||||
|
||||
---
|
||||
|
||||
## Margin Redistribution to Pool Members
|
||||
|
||||
The margin between what a bidder was willing to accept and the final clearing price is collected by the pool. This value is then redistributed to all liquidity providers who remain in the pool, proportional to their share of the total liquidity.
|
||||
|
||||
### Example
|
||||
|
||||
- **LP A** bids to exit at €0.088, but the clearing price is €0.100
|
||||
- The **€0.012 margin per token** is collected by the pool
|
||||
- This margin is aggregated across all filled bids and shared among the remaining LPs
|
||||
- **The longer you hold, the more you benefit** when others leave
|
||||
|
||||
---
|
||||
|
||||
## Why This Works
|
||||
|
||||
| Benefit | Description |
|
||||
|---------|-------------|
|
||||
| **Fair** | All successful bidders receive the same clearing price |
|
||||
| **Protective** | Exits only happen with a discount, preventing abuse |
|
||||
| **Incentivizing** | Remaining LPs gain rewards when others exit |
|
||||
| **Sustainable** | Controls liquidity outflow with capped exit volume and loss-based exit mechanics |
|
||||
|
||||
---
|
||||
|
||||
## Key Takeaways
|
||||
|
||||
:::tip Market-Driven Fairness
|
||||
The Dutch auction mechanism ensures that:
|
||||
- No one can "front-run" or time the market for unfair advantage
|
||||
- Those most eager to exit subsidize those who stay
|
||||
- The pool becomes stronger with each exit, not weaker
|
||||
:::
|
||||
|
||||
:::info Protection Mechanisms
|
||||
- Maximum exit caps prevent pool drainage
|
||||
- Minimum discounts ensure pool sustainability
|
||||
- Clearing price mechanism ensures equal treatment
|
||||
- Margin redistribution rewards patient participants
|
||||
:::
|
||||
|
||||
:::note Related Concepts
|
||||
This mechanism works hand-in-hand with [Position-Based Liquidity Pools](./position-based-lp.md) to create a fair and sustainable system.
|
||||
:::
|
||||
282
docs/core-concepts/liquidity-pools-overview.md
Normal file
282
docs/core-concepts/liquidity-pools-overview.md
Normal file
@@ -0,0 +1,282 @@
|
||||
---
|
||||
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.
|
||||
|
||||
:::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).
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## The Big Picture: Three Pools
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph External["External World"]
|
||||
FIAT[💵 Fiat/USDC]
|
||||
TFT_MARKET[🌐 TFT Market]
|
||||
end
|
||||
|
||||
subgraph Internal["ThreeFold Ecosystem"]
|
||||
TFT_LOCKED[🔒 Locked TFT]
|
||||
CC[💎 Cloud Credits CC]
|
||||
TFTF[📊 TFT Future TFTF]
|
||||
|
||||
POOL1["Pool 1: TFT → CC<br/>(One-Way Entry)"]
|
||||
POOL2["Pool 2: CC ↔ TFTF<br/>(Internal Trading)"]
|
||||
POOL3["Pool 3: TFTF ↔ USDC<br/>(Controlled Exit)"]
|
||||
end
|
||||
|
||||
TFT_MARKET -->|Buy TFT| POOL1
|
||||
POOL1 -->|Lock TFT<br/>Mint CC| CC
|
||||
|
||||
CC <-->|Convert| POOL2
|
||||
POOL2 <-->|Based on TFT price| TFTF
|
||||
|
||||
TFTF <-->|Dutch Auction<br/>5% cap, 20% discount| POOL3
|
||||
POOL3 <-->|Controlled bridge| FIAT
|
||||
|
||||
style POOL1 fill:#e1f5ff
|
||||
style POOL2 fill:#fff4e1
|
||||
style POOL3 fill:#ffe1e1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Your Journey Through the System
|
||||
|
||||
### 1. Entry (Pool 1: TFT → CC)
|
||||
|
||||
**What it does**: Converts your TFT into stable Cloud Credits
|
||||
|
||||
**How it works**:
|
||||
- You bring TFT (purchased from market or earned from farming)
|
||||
- TFT gets **locked** (not sold, not converted - just held)
|
||||
- CC is **minted** at a fixed rate (currently 1 CC for 2 TFT)
|
||||
- You receive CC to spend on cloud services
|
||||
|
||||
**Key point**: This is a **one-way** swap. You can't directly convert CC back to TFT through this pool.
|
||||
|
||||
**Example**:
|
||||
```
|
||||
You have: 1,000 TFT
|
||||
You deposit → 1,000 TFT gets locked
|
||||
You receive → 500 CC (at 2:1 rate)
|
||||
Your CC is pegged to gold (~$0.128 per CC as of Oct 2024)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Internal Movement (Pool 2: CC ↔ TFTF)
|
||||
|
||||
**What it does**: Lets you maintain TFT exposure while holding stable CC
|
||||
|
||||
**How it works**:
|
||||
- You earn CC from farming or have CC from services
|
||||
- You can convert CC to TFTF (TFT Future) based on current TFT market price
|
||||
- TFTF represents a claim on TFT value without holding actual TFT
|
||||
- You can convert back to CC when needed
|
||||
|
||||
**Key point**: This allows you to **participate in TFT upside** without immediately exiting to fiat.
|
||||
|
||||
**Example**:
|
||||
```
|
||||
You earned: 500 CC from farming
|
||||
TFT market price: $0.10
|
||||
You convert → 500 CC becomes 5,000 TFTF
|
||||
If TFT rises to $0.15, your TFTF value increases
|
||||
You can convert back to CC at any time
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Exit to Fiat (Pool 3: TFTF ↔ USDC)
|
||||
|
||||
**What it does**: Provides a controlled bridge to cash out to fiat currency
|
||||
|
||||
**How it works**:
|
||||
- You submit a bid in the Dutch auction: amount + minimum acceptable price
|
||||
- Bids are sorted from lowest price to highest (most discount to least)
|
||||
- System fills bids until reaching the monthly cap (e.g., 5% of total liquidity)
|
||||
- Successful bidders receive USDC at the clearing price
|
||||
|
||||
**Key point**: This is **controlled liquidity** - not instant withdrawals. It protects the pool from being drained.
|
||||
|
||||
**Example**:
|
||||
```
|
||||
You want to exit: 10,000 TFTF (worth ~$1,000)
|
||||
You're willing to accept: 20% discount minimum
|
||||
Others bid: 15%, 18%, 22%, 25%, 30%
|
||||
Clearing price: 22% (your bid gets filled)
|
||||
You receive: $780 USDC (after 22% discount)
|
||||
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 |
|
||||
|
||||
---
|
||||
|
||||
## Why Three Pools?
|
||||
|
||||
Each pool serves a distinct purpose:
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[User Needs] --> B{What do you need?}
|
||||
|
||||
B -->|Stable pricing for services| P1[Pool 1: TFT→CC<br/>Get stable credits]
|
||||
B -->|Keep TFT upside exposure| P2[Pool 2: CC↔TFTF<br/>Maintain position]
|
||||
B -->|Cash out for operations| P3[Pool 3: TFTF→USDC<br/>Controlled exit]
|
||||
|
||||
style P1 fill:#e1f5ff
|
||||
style P2 fill:#fff4e1
|
||||
style P3 fill:#ffe1e1
|
||||
```
|
||||
|
||||
### Pool 1: Stability
|
||||
Gives you predictable pricing for cloud services without exposure to TFT volatility.
|
||||
|
||||
### Pool 2: Flexibility
|
||||
Allows you to move between stable CC and TFT-linked TFTF based on your market outlook.
|
||||
|
||||
### Pool 3: Liquidity
|
||||
Provides real fiat exit when needed, with controls that protect all participants.
|
||||
|
||||
---
|
||||
|
||||
## Visual Flow: Complete User Journey
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
START([👤 New User]) --> BUY[Buy TFT on Market]
|
||||
BUY --> ENTER[Enter Pool 1]
|
||||
ENTER --> LOCKED[TFT Locked + CC Minted]
|
||||
|
||||
LOCKED --> USE{How to use CC?}
|
||||
|
||||
USE -->|Spend on services| SERVICES[☁️ Use ThreeFold Cloud]
|
||||
USE -->|Hold as stable value| HOLD[💎 Keep CC]
|
||||
USE -->|Want TFT exposure| CONVERT[Convert to TFTF in Pool 2]
|
||||
|
||||
SERVICES --> BURN[CC Burned by Network]
|
||||
HOLD --> WAIT[Wait for opportunities]
|
||||
CONVERT --> TFTF_HOLD[Hold TFTF Position]
|
||||
|
||||
TFTF_HOLD --> TFTF_USE{What next?}
|
||||
TFTF_USE -->|Need stability again| BACK[Back to CC in Pool 2]
|
||||
TFTF_USE -->|Need fiat| EXIT[Enter Pool 3 Dutch Auction]
|
||||
|
||||
EXIT --> BID[Submit bid with discount]
|
||||
BID --> AUCTION{Bid filled?}
|
||||
AUCTION -->|Yes| RECEIVE[Receive USDC]
|
||||
AUCTION -->|No| RETRY[Try next auction round]
|
||||
|
||||
BACK --> LOCKED
|
||||
WAIT --> USE
|
||||
|
||||
style START fill:#90EE90
|
||||
style RECEIVE fill:#90EE90
|
||||
style BURN fill:#FFB6C1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Key Protections Built In
|
||||
|
||||
### 1. No Unlimited Dumping
|
||||
- Exits are capped per period (e.g., max 5% of total liquidity)
|
||||
- Dutch auction requires accepting a discount
|
||||
- Protects all participants from sudden value crashes
|
||||
|
||||
### 2. Fair Distribution
|
||||
- Position-based tracking means early supporters aren't diluted
|
||||
- Time-weighting rewards long-term commitment
|
||||
- No front-running or gaming the system
|
||||
|
||||
### 3. Sustainable Liquidity
|
||||
- Only 50% of total contributed liquidity can ever exit via Dutch auctions
|
||||
- Margin from discounts gets redistributed to remaining participants
|
||||
- System strengthens with each exit, rather than weakening
|
||||
|
||||
### 4. Transparency
|
||||
- All positions are clearly tracked and visible
|
||||
- Rules are consistent and applied equally
|
||||
- No hidden fees or complex formulas
|
||||
|
||||
---
|
||||
|
||||
## Common Questions
|
||||
|
||||
<details>
|
||||
<summary><strong>Can I get my TFT back immediately?</strong></summary>
|
||||
|
||||
Not instantly. You need to:
|
||||
1. Convert CC to TFTF (Pool 2)
|
||||
2. Exit TFTF via Dutch auction (Pool 3) to USDC
|
||||
3. Buy TFT on the market with USDC if you want TFT again
|
||||
|
||||
The original TFT you deposited is locked to back the CC that was minted.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>What if I just want stable income from farming?</strong></summary>
|
||||
|
||||
Perfect! Just keep your earnings in CC. You get:
|
||||
- Stable value (pegged to gold)
|
||||
- No exposure to TFT market swings
|
||||
- Ability to convert to TFTF later if you want upside
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>How do I benefit from TFT price increases?</strong></summary>
|
||||
|
||||
Convert your CC to TFTF in Pool 2. TFTF value tracks TFT market price, so if TFT goes up, your TFTF position becomes more valuable in CC or USDC terms.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>What happens to the margin from Dutch auctions?</strong></summary>
|
||||
|
||||
When someone exits at, say, a 25% discount, that 25% margin is collected and redistributed to all remaining liquidity providers proportionally. The longer you hold, the more you benefit from others exiting.
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><strong>Is this like Uniswap or Curve?</strong></summary>
|
||||
|
||||
Fundamentally different. Traditional AMMs use value-weighted pools with instant liquidity and impermanent loss. We use time-weighted, position-based pools with controlled exits and no impermanent loss. Trade-off: less instant liquidity, more fairness and protection.
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you understand the overall flow, dive deeper:
|
||||
|
||||
1. **[Token System](/core-concepts/token-system)** - Understand TFT, CC, and TFTF roles
|
||||
2. **[Position-Based Liquidity Pools](/core-concepts/position-based-lp)** - Learn why this approach is fair
|
||||
3. **[Dutch Auction Exit](/core-concepts/dutch-auction-exit)** - See exactly how exits work with examples
|
||||
4. **[Yin-Yang Currency](/core-concepts/yin-yang-currency)** - The philosophy behind dual tokens
|
||||
|
||||
---
|
||||
|
||||
:::tip Simplified Summary
|
||||
- **Pool 1**: Get in (TFT → CC)
|
||||
- **Pool 2**: Move around (CC ↔ TFTF)
|
||||
- **Pool 3**: Get out (TFTF → USDC)
|
||||
|
||||
All three work together to give you **stability**, **flexibility**, and **controlled liquidity**.
|
||||
:::
|
||||
127
docs/core-concepts/position-based-lp.md
Normal file
127
docs/core-concepts/position-based-lp.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Position-Based Liquidity Pools
|
||||
|
||||
## Overview
|
||||
|
||||
In traditional DeFi systems, liquidity providers (LPs) are issued **floating LP tokens** that represent their proportional share of a pool's current value. These are known as **value-weighted pools**, where your position fluctuates with market volatility and total pool value.
|
||||
|
||||
However, our model uses a **time-weighted, position-based pool** — a fundamentally different approach that prioritizes fairness and long-term contribution over market speculation.
|
||||
|
||||
## Key Principles
|
||||
|
||||
### 1. Position-Based Accounting
|
||||
|
||||
Every liquidity contribution is recorded as a **fixed position**:
|
||||
|
||||
- Token type (e.g., USDC, Peaq, TFT)
|
||||
- Contribution amount (e.g., 1,000 USDC)
|
||||
- Timestamp (e.g., January 1, 2025)
|
||||
|
||||
These positions are tracked permanently and **do not change with price fluctuations**.
|
||||
|
||||
### 2. No Floating LP Tokens
|
||||
|
||||
- Unlike standard DeFi protocols, we **do not issue LP tokens** that float with pool value
|
||||
- Users do not gain or lose share based on volatility
|
||||
- Instead, share is determined by:
|
||||
- **How much** you contributed
|
||||
- **How early** you contributed
|
||||
|
||||
## Why This Matters
|
||||
|
||||
| Feature | Value-Weighted Pools | Time-Weighted, Position-Based Pools |
|
||||
| ------------------------------- | -------------------- | ----------------------------------- |
|
||||
| Contribution tracking | Dynamic | Fixed (amount + time) |
|
||||
| Exposure to volatility | Yes | No |
|
||||
| Fairness over time | No | Yes |
|
||||
| Transferable LP tokens | Yes | No |
|
||||
| Encourages long-term commitment | No | Yes |
|
||||
| Impermanent loss | Yes | No |
|
||||
|
||||
## Implications
|
||||
|
||||
### Pros
|
||||
|
||||
- **Fair distribution** based on participation, not market timing
|
||||
- **No front-running or last-minute pool stacking**
|
||||
- **No impermanent loss** (unlike traditional DeFi pools)
|
||||
- Encourages **early and stable contributions**
|
||||
- Aligns incentives with long-term growth, not speculation
|
||||
|
||||
### Trade-Offs
|
||||
|
||||
- **No instant liquidity switching** between pools
|
||||
- Internal migrations between pools require **position translation**, not token swaps
|
||||
- Less suitable for active traders; optimized for committed supporters
|
||||
|
||||
## Internal Switching Considerations
|
||||
|
||||
Because we track original token amounts and timestamps:
|
||||
|
||||
- Users cannot simply "convert" one pool share into another
|
||||
- Any movement between pools requires:
|
||||
- Removing the original position from Pool A
|
||||
- Translating it into an equivalent position in Pool B, preserving contribution integrity
|
||||
|
||||
This model behaves more like **vesting or NFT-based positions** than traditional LP tokens.
|
||||
|
||||
---
|
||||
|
||||
## Value Calculation and Profit Distribution
|
||||
|
||||
### How Value is Calculated
|
||||
|
||||
Value in this system is calculated using a fundamentally different approach:
|
||||
|
||||
- Each liquidity contribution maintains its **original value** rather than floating with market prices
|
||||
- Your share of the pool is determined by **contribution amount** and **contribution time**
|
||||
|
||||
### Profit Distribution When Someone Exits
|
||||
|
||||
When liquidity providers exit the pool through the Dutch auction mechanism:
|
||||
|
||||
#### Dutch Auction Process
|
||||
|
||||
1. LPs submit exit bids with an amount and minimum acceptable price
|
||||
2. Bids are sorted from lowest price to highest
|
||||
3. The system fills bids from the bottom up until reaching the maximum allowed exit amount
|
||||
4. The last accepted bid sets the clearing price for all successful exits
|
||||
|
||||
#### Margin Collection
|
||||
|
||||
- A discount is defined per pair of tokens (e.g., USDC to TFT)
|
||||
- When LPs exit, they receive the agreed amount minus this discount
|
||||
- The collected margin (the discount amount) is pooled together
|
||||
|
||||
#### Profit Distribution
|
||||
|
||||
- Collected margins are redistributed to all **remaining liquidity providers**
|
||||
- Distribution is proportional to each LP's share of the total liquidity
|
||||
- **The longer you hold, the more you benefit** when others leave
|
||||
|
||||
#### Exit Protections
|
||||
|
||||
- Only up to 50% of total liquidity ever contributed (minus past exits) can leave through Dutch auctions
|
||||
- This cap protects the pool from being drained
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Our system is built on **time-weighted, position-based liquidity** — not market-weighted value shares. This ensures that:
|
||||
|
||||
- All participants are rewarded based on **what** they contributed and **when**
|
||||
- Not how the market fluctuates afterward
|
||||
|
||||
It's a principled approach for long-term alignment, fair participation, and stable tokenomics.
|
||||
|
||||
:::info Virtuous Cycle
|
||||
This creates a virtuous cycle where early and committed participants are rewarded, while the pool remains protected from being drained by opportunistic withdrawals.
|
||||
:::
|
||||
|
||||
:::tip Learn More
|
||||
See how exits work in practice with the [Dutch Auction Exit Mechanism](./dutch-auction-exit.md).
|
||||
:::
|
||||
107
docs/core-concepts/token-system.md
Normal file
107
docs/core-concepts/token-system.md
Normal file
@@ -0,0 +1,107 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Token System
|
||||
|
||||
Our ecosystem uses a multi-currency system to ensure both stability for utility and opportunities for growth and investment.
|
||||
|
||||
## Token Types
|
||||
|
||||
### 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
|
||||
|
||||
### 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.
|
||||
|
||||
---
|
||||
|
||||
## Liquidity Pools
|
||||
|
||||
There are three liquidity pools to manage the ecosystem's economy:
|
||||
|
||||
### 1. TFT to CC Swap (One-Way)
|
||||
|
||||
- **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
|
||||
|
||||
### 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.
|
||||
|
||||
---
|
||||
|
||||
## Why This System?
|
||||
|
||||
This multi-token architecture solves several critical problems:
|
||||
|
||||
- **Price Stability**: CC provides predictable pricing for services (pegged to gold)
|
||||
- **Market Opportunity**: TFT remains tradable with upside potential
|
||||
- **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).
|
||||
:::
|
||||
104
docs/core-concepts/yin-yang-currency.md
Normal file
104
docs/core-concepts/yin-yang-currency.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# Yin vs. Yang Currencies
|
||||
|
||||
Our token system is philosophically rooted in economist Bernard Lietaer's concept of complementary currencies. Understanding this framework helps explain why we use both TFT and Cloud Credits.
|
||||
|
||||
## Currency Philosophies
|
||||
|
||||
### Yang Currencies
|
||||
|
||||
- **Nature**: Conventional, national currencies (e.g., dollar, euro, yen)
|
||||
- **Creation**: Centralized, can be fair-launched or created by a centralized authority
|
||||
- **Characteristics**: Promote **competition**, **scarcity**, **hierarchy**, and **analytical or linear thinking**
|
||||
- **Strengths**: Efficient for global trade and industrial economic activities
|
||||
- **Limitations**: Relying solely on Yang currencies fosters fragility, social isolation, and volatility
|
||||
|
||||
### Yin Currencies
|
||||
|
||||
- **Nature**: Complementary or community currencies (e.g., barter systems, time banking, trade credits, caring relationship tickets)
|
||||
- **Creation**: Decentralized, often **mutual credit systems** created by participants themselves
|
||||
- **Foundation**: Rely on **community trust** rather than a central issuer
|
||||
- **Characteristics**: Foster **cooperation**, **egalitarian relationships**, **quality of life**, **sustainability**, and **social trust**
|
||||
- **Environment**: Thrive within **bounded communities**, where circulation and reciprocity reinforce social cohesion
|
||||
|
||||
---
|
||||
|
||||
## Why Both Matter: The Complementarity
|
||||
|
||||
Lietaer doesn't present Yin and Yang currencies as antagonistic — but as **complementary tools**, each serving distinct purposes:
|
||||
|
||||
- Societies that incorporate both systems, **dual currency systems**, are typically more **resilient**, **socially robust**, and thrive economically
|
||||
|
||||
### Real-World Examples
|
||||
|
||||
#### Bali's Dual System
|
||||
- **National (Yang) currency**: Used for wider commerce
|
||||
- **Community-based Yin currency**: *narayan banjar* (based on hours of service)
|
||||
- **Impact**: Empowers communal projects and mutual support
|
||||
- **Scale**: About **30% of adult life** in Bali occurs in this Yin economy, reinforcing trust and collective well-being
|
||||
|
||||
#### Japan's Care Economy
|
||||
- **System**: Complementary Yin currencies reward caregiving
|
||||
- **Function**: Caring-for-elderly credits can be used for university tuition
|
||||
- **Result**: Solves multiple community needs through alternative value systems
|
||||
|
||||
---
|
||||
|
||||
## Lietaer's Integral Economy Vision
|
||||
|
||||
Lietaer's broader vision forms part of his **"Integral Economy"**: a balanced system where:
|
||||
|
||||
- **Financial capital (Yang)** and **social capital (Yin)** coexist harmoniously
|
||||
- **Goal**: Foster **integral wealth** — not just material accumulation, but also community, natural, and social well-being
|
||||
|
||||
---
|
||||
|
||||
## Summary Table
|
||||
|
||||
| Feature | Yang Currency | Yin Currency |
|
||||
| ------------------- | -------------------------------------------------- | --------------------------------------------- |
|
||||
| **Creation** | Central authority, fiat | Mutual credit, community-based |
|
||||
| **Focus** | Liquidity, scarcity, hierarchy | Cooperation, mutual credit |
|
||||
| **Use Case** | Trade, blockchain, investment, liquidity providing | Mutual credit, services, exchange of capacity |
|
||||
| **Examples** | USD, EUR, JPY, TFT | Time banking, cloud computing capacity, CC |
|
||||
| **Role in Society** | Efficiency & growth of capital | Builds trust and resilience alongside Yang |
|
||||
|
||||
---
|
||||
|
||||
## Application to ThreeFold
|
||||
|
||||
In our system:
|
||||
|
||||
- **TFT (Yang)**: Tradable, scarce, subject to market forces, provides investment opportunity
|
||||
- **CC (Yin)**: Stable, community-focused, promotes cooperation, enables predictable service exchange
|
||||
|
||||
This dual structure aims to:
|
||||
- Preserve market efficiency and investment potential (Yang)
|
||||
- Enable stable, community-oriented value exchange (Yin)
|
||||
- Create resilience through complementarity
|
||||
- Balance speculation with sustainability
|
||||
|
||||
---
|
||||
|
||||
## Final Thoughts
|
||||
|
||||
Bernard Lietaer's Yin-Yang currency model invites us to **rethink our relationship with money**. By blending **efficiency and competitiveness** (Yang) with **cooperation and scarcity-healing systems** (Yin), communities can cultivate greater **resilience, trust, and sustainable abundance**.
|
||||
|
||||
:::info Philosophy in Practice
|
||||
Our dual-token system isn't just about technical mechanics — it's about creating an economy that serves both market efficiency and community well-being.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- [The Yin and Yang of Money: Complementary Currencies](https://baritessler.com/2009/05/yin-and-yang-currency/)
|
||||
- [The Yin and yang of currency](https://syntropic.world/the-yin-and-yang-of-currency/)
|
||||
- [Bernard Lietaer, Visionary Economist](https://www.rozsavage.com/bernard-lietaer-visionary-economist/)
|
||||
- [Of Human Wealth - Bernard Lietaer](https://bernard-lietaer.org/wp-content/uploads/2022/07/2004-Of-Human-Wealth-Beyond-Greed-Scarcity-Lieater-Belgin-annotated.pdf)
|
||||
- [Interview with Bernard Lietaer -- Money, Community & Social ...](https://uazu.net/money/lietaer.html)
|
||||
- [THE FUTURE OF MONEY - Bernard A. Lietaer](https://library.uniteddiversity.coop/Money_and_Economics/The_Future_of_Money-Bernard_Lietaer.pdf)
|
||||
- [Trade: The Yin Currency I Love to Use](https://baritessler.com/2017/07/trade-yin-currency-love-use/)
|
||||
275
docs/implementation-roadmap.md
Normal file
275
docs/implementation-roadmap.md
Normal file
@@ -0,0 +1,275 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Implementation & Roadmap
|
||||
|
||||
:::info Community Update
|
||||
This page shares what we know **right now** about the implementation status and roadmap. We're committed to transparency with the community, even when some details are still being finalized. More information will be shared as it becomes available.
|
||||
|
||||
**Join the discussion**: Share your feedback in the [forum thread](https://forum.threefold.io/t/tft-minting-transition-plan-community-e-book/4647).
|
||||
:::
|
||||
|
||||
## Current Status Overview
|
||||
|
||||
We're making significant progress on multiple fronts to deliver a sustainable, farmer-friendly ecosystem. Here's where we stand on the key components mentioned in our recent community discussions.
|
||||
|
||||
---
|
||||
|
||||
## Token Economics: Proposed Solution
|
||||
|
||||
We've designed a comprehensive solution to the token economics challenge. The mechanisms are described in this e-book:
|
||||
|
||||
- **Dual Token System**: TFT (tradable) and Cloud Credits (stable utility) - [Learn more](/core-concepts/token-system)
|
||||
- **Controlled Liquidity**: Dutch auction mechanism prevents dumping - [Details](/core-concepts/dutch-auction-exit)
|
||||
- **Fair Distribution**: Position-based pools reward long-term commitment - [Read more](/core-concepts/position-based-lp)
|
||||
|
||||
The system is designed and ready for implementation with the marketplace features below.
|
||||
|
||||
---
|
||||
|
||||
## Marketplace Implementation 🚧
|
||||
|
||||
### Stable Cloud Credit Currency
|
||||
|
||||
**Status**: Design Complete | Implementation in Progress
|
||||
|
||||
Cloud Credits (CC) provide the stable utility currency needed for day-to-day operations:
|
||||
|
||||
- **Peg**: 1/1000 gram of gold (~$0.128 USD as of Oct 2024)
|
||||
- **Purpose**: Predictable pricing for farmers and users
|
||||
- **Acquisition**: Users convert TFT to CC at a fixed rate or purchase with fiat
|
||||
- **Stability**: No exposure to TFT market volatility for service pricing
|
||||
|
||||
### Farmer Price Setting Capability
|
||||
|
||||
**Status**: Coming Soon
|
||||
|
||||
Farmers will be able to set their own pricing for capacity:
|
||||
|
||||
- **Flexible Pricing**: Set competitive rates for your node's resources
|
||||
- **Market-Driven**: Respond to demand and differentiate your offerings
|
||||
- **Integration**: Works alongside ThreeFold's standard bid packages
|
||||
- **Transparency**: Clear pricing visible to potential customers
|
||||
|
||||
:::note
|
||||
This feature is being designed to balance farmer autonomy with marketplace consistency.
|
||||
:::
|
||||
|
||||
### 80% Revenue Share Model
|
||||
|
||||
**Status**: Confirmed | Implementation in Progress
|
||||
|
||||
The revenue distribution is farmer-first:
|
||||
|
||||
- **80% to Farmers**: Directly compensates capacity providers
|
||||
- **10% Burned**: Reduces TFT supply, supporting token value
|
||||
- **10% to ThreeFold**: Funds ongoing development and operations
|
||||
|
||||
This model ensures farmers receive the majority of revenue generated from their infrastructure.
|
||||
|
||||
### Slices Implementation
|
||||
|
||||
**Status**: Designed | Implementation in Progress
|
||||
|
||||
The slices system provides better node partitioning:
|
||||
|
||||
- **Resource Packaging**: Nodes divided into standardized "slices" of compute capacity
|
||||
- **Efficient Utilization**: Better matching of user needs to available resources
|
||||
- **Clear Pricing**: Each slice has defined resources and pricing
|
||||
- **Flexible Scaling**: Users can consume exactly what they need
|
||||
|
||||
This is part of the TFGrid v4 rollout. See the [Node Economics section](/node-economics/slices-overview) for detailed specifications and pricing.
|
||||
|
||||
---
|
||||
|
||||
## Bidding & Capacity Marketplace
|
||||
|
||||
### Capacity Bidding (vast.ai Model)
|
||||
|
||||
**Status**: Coming Soon
|
||||
|
||||
A marketplace where users can bid on capacity and farmers can accept offers:
|
||||
|
||||
- **Demand-Driven**: Users post requirements and budget
|
||||
- **Competitive**: Farmers compete to provide best value
|
||||
- **Transparent**: Clear matching between needs and offerings
|
||||
- **Flexible**: Supports both standard and custom configurations
|
||||
|
||||
### Income Clarity for Farmers
|
||||
|
||||
**Status**: Documentation Complete | Tools in Development
|
||||
|
||||
We're providing clear visibility into farmer economics:
|
||||
|
||||
- **Pricing Calculators**: Estimate income based on node specs - See [pricing models](/node-economics/pricing-model)
|
||||
- **Revenue Projections**: Min/max income scenarios documented
|
||||
- **Cost Transparency**: Hardware costs amortized over 5-year lifespan
|
||||
- **ROI Models**: Clear break-even and profit projections
|
||||
|
||||
The [Node Specifications](/node-economics/node-specifications) page provides detailed income projections for various node configurations.
|
||||
|
||||
---
|
||||
|
||||
## Dutch Auction Liquidity Pool
|
||||
|
||||
**Status**: Design Complete | Smart Contract Development in Progress
|
||||
|
||||
The controlled liquidity mechanism that protects the ecosystem:
|
||||
|
||||
- **Exit Controls**: Maximum 50% of contributed liquidity can exit via auctions
|
||||
- **Fair Pricing**: Market-driven clearing price ensures fairness
|
||||
- **Pool Protection**: Minimum discounts maintain pool sustainability
|
||||
- **Margin Redistribution**: Remaining LPs benefit when others exit
|
||||
|
||||
Read the full [Dutch Auction Exit Mechanism](/core-concepts/dutch-auction-exit) for details.
|
||||
|
||||
---
|
||||
|
||||
## Infrastructure Development
|
||||
|
||||
### Kubernetes Cloud
|
||||
|
||||
**Status**: Complete ✅
|
||||
|
||||
The Kubernetes cloud is operational and uses TFT underneath:
|
||||
|
||||
- **Production Ready**: Deployed and available for workloads
|
||||
- **TFT-Powered**: Runs on the token economics described in this plan
|
||||
- **Waiting On**: Marketplace features above before major marketing push
|
||||
|
||||
### TFGrid v4 & ZOS v4
|
||||
|
||||
**Status**: Development Phase | 2-3 Months to Production
|
||||
|
||||
The next generation of ThreeFold Grid infrastructure:
|
||||
|
||||
- **Timeline**: 2-3 months until production-ready
|
||||
- **Current**: v3 remains operational and available
|
||||
- **Improvements**: Enhanced performance, better resource management
|
||||
- **Compatibility**: Smooth migration path from v3
|
||||
|
||||
:::caution Interim Period
|
||||
For immediate deployments, TFGrid v3 remains fully supported and operational.
|
||||
:::
|
||||
|
||||
### High-Performance Nodes & GPU Expansion
|
||||
|
||||
**Status**: Actively Working On It 🔨
|
||||
|
||||
We're expanding the network with quality infrastructure:
|
||||
|
||||
- **Goal**: More high-quality, high-performance nodes
|
||||
- **Priority**: Significantly more GPU capacity for AI workloads
|
||||
- **Partnerships**: Working with hardware providers and farmers
|
||||
- **See**: [Certified nodes coming Q4 2025](/node-economics/node-specifications#certified-nodes-q4-2025) including dedicated AI configurations
|
||||
|
||||
---
|
||||
|
||||
## End-User Applications
|
||||
|
||||
**Status**: Teams Working On It 🚀
|
||||
|
||||
Applications being built on top of TFGrid:
|
||||
|
||||
- **Purpose**: Give distribution channels something to sell
|
||||
- **Development**: Multiple teams actively building
|
||||
- **Integration**: Leveraging the Kubernetes cloud and marketplace
|
||||
- **Timeline**: Coordinated with marketplace readiness
|
||||
|
||||
:::info
|
||||
Specific applications and partners will be announced as they reach appropriate milestones.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Market Questions & Offtakers
|
||||
|
||||
### Who Are the Offtakers?
|
||||
|
||||
We're in discussions with several potential high-volume customers, but cannot share specific names at this stage due to:
|
||||
|
||||
- **Confidentiality agreements** during negotiation phases
|
||||
- **Competitive sensitivity** in the cloud services market
|
||||
- **Deal contingencies** that haven't been finalized
|
||||
|
||||
### Why Can't We Share Details Yet?
|
||||
|
||||
Standard business practice in enterprise sales:
|
||||
|
||||
- Partners often require NDAs until public announcements
|
||||
- Premature disclosure can jeopardize negotiations
|
||||
- We want to announce confirmed commitments, not speculative discussions
|
||||
|
||||
### How Much Capacity Will They Take?
|
||||
|
||||
This depends on:
|
||||
|
||||
- **Marketplace readiness**: Features listed above need to be live
|
||||
- **Network capacity**: Sufficient GPU and high-performance nodes
|
||||
- **Application maturity**: End-user apps that drive demand
|
||||
- **Pricing competitiveness**: Market rates for comparable services
|
||||
|
||||
:::note Transparency Commitment
|
||||
We will share offtaker information and capacity commitments **as soon as commercially appropriate**. This community's trust matters to us, and we're balancing transparency with business realities.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## What This Means For You
|
||||
|
||||
### For Farmers
|
||||
|
||||
- **Stable Income**: CC-based payments protect against TFT volatility
|
||||
- **Clear Economics**: Documented pricing and income projections
|
||||
- **Fair Compensation**: 80% revenue share
|
||||
- **Protected Value**: No more unlimited TFT dumping harming token price
|
||||
- **Controlled Exits**: Dutch auction provides liquidity when revenue enters system
|
||||
|
||||
### For TFT Holders
|
||||
|
||||
- **Token Protection**: Minting controls prevent dilution
|
||||
- **Value Accrual**: 10% burn mechanism
|
||||
- **Upside Preserved**: TFT remains tradable with growth potential
|
||||
- **Fair System**: Position-based pools reward early and long-term supporters
|
||||
|
||||
### For Users
|
||||
|
||||
- **Predictable Pricing**: CC pegged to gold provides stability
|
||||
- **Quality Infrastructure**: Focus on high-performance, GPU-enabled nodes
|
||||
- **Mature Platform**: Kubernetes cloud ready, v4 improvements coming
|
||||
- **Growing Ecosystem**: Applications and services launching on TFGrid
|
||||
|
||||
---
|
||||
|
||||
## Timeline Summary
|
||||
|
||||
| Component | Status | Timeline |
|
||||
|-----------|--------|----------|
|
||||
| Token Economics Design | ✅ Designed | Awaiting implementation |
|
||||
| Slices System | 🚧 Designed | Part of TFGrid v4 |
|
||||
| Kubernetes Cloud | ✅ Running | Now |
|
||||
| Dutch Auction Mechanism | 🚧 In Development | Q4 2024 |
|
||||
| Marketplace Features | 🚧 In Development | Q4 2024 - Q1 2025 |
|
||||
| TFGrid v4 / ZOS v4 | 🚧 In Development | 2-3 months |
|
||||
| GPU Node Expansion | 🔨 Active Effort | Ongoing |
|
||||
| End-User Applications | 🔨 Active Development | Q1-Q2 2025 |
|
||||
| Offtaker Announcements | 🔒 Under NDA | When commercially ready |
|
||||
|
||||
:::tip Stay Updated
|
||||
Join the discussion and get the latest updates as implementation progresses:
|
||||
- [Forum Discussion Thread](https://forum.threefold.io/t/tft-minting-transition-plan-community-e-book/4647)
|
||||
- [Community Call](https://bit.ly/tfcommunitycall)
|
||||
- [Telegram](https://t.me/threefoldfarmers)
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Review the Core Concepts**: Understand the token mechanics that solve the sustainability challenge
|
||||
2. **Explore Node Economics**: See concrete examples of farmer income with the new system
|
||||
3. **Join the Discussion**: Share feedback, ask questions, help refine the details
|
||||
4. **Stay Engaged**: Implementation updates will be shared regularly through community channels
|
||||
|
||||
This is a collaborative journey. Your input helps shape the final implementation to serve the entire ThreeFold ecosystem.
|
||||
96
docs/intro.md
Normal file
96
docs/intro.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
slug: /
|
||||
---
|
||||
|
||||
# TFT Minting Transition Plan
|
||||
|
||||
Welcome to the **TFT Minting Transition Plan** community e-book. This document outlines the proposed changes to the ThreeFold Token (TFT) minting system and introduces a new liquidity framework designed to create sustainable value for all participants.
|
||||
|
||||
## Purpose
|
||||
|
||||
This plan is a **living document** created to:
|
||||
|
||||
- Share the proposed token economics and liquidity mechanisms
|
||||
- Acknowledge areas that still need refinement
|
||||
- Invite community feedback and discussion
|
||||
- Foster transparent collaboration on the future of ThreeFold's token system
|
||||
|
||||
## What This Plan Covers
|
||||
|
||||
The transition plan introduces several interconnected concepts:
|
||||
|
||||
- **Implementation Status & Roadmap**: Current progress on marketplace features, infrastructure, and timeline
|
||||
- **Dual Token System**: TFT as a tradable asset and Cloud Credits (CC) as a stable utility token
|
||||
- **Position-Based Liquidity Pools**: A fair, time-weighted approach to rewarding contributors
|
||||
- **Dutch Auction Exit Mechanism**: Controlled, sustainable liquidity with built-in protections
|
||||
- **Yin-Yang Currency Philosophy**: Balancing market efficiency with community cooperation
|
||||
- **Node Economics & Pricing**: Detailed specifications, income projections, and ThreeFold's capacity commitments
|
||||
|
||||
:::info Work in Progress
|
||||
This plan represents our current thinking but is **not finalized**. We are actively seeking community input to refine and improve these mechanisms.
|
||||
:::
|
||||
|
||||
## Open Questions & Gaps
|
||||
|
||||
We acknowledge there are still important decisions to be made and gaps to fill. Your feedback on these issues is particularly valuable:
|
||||
|
||||
<div className="open-questions">
|
||||
|
||||
### Key Areas We're Seeking Feedback On:
|
||||
|
||||
- **Entry Price**: Should the fixed TFT to CC conversion rate be **$0.05** or **$0.01** per TFT?
|
||||
- **Peg Currency**: Should Cloud Credits be pegged to **gold** (1/1000 gram) or **USD**?
|
||||
- **Liquidity Pool Parameters**:
|
||||
- What should the maximum exit percentage per period be?
|
||||
- What minimum discount is appropriate for Dutch auction exits?
|
||||
- **Gaming Prevention**: Are there scenarios where the system could be exploited that we haven't addressed?
|
||||
- **Farmer Liquidity**: What's the right balance between stability and operational liquidity for farmers?
|
||||
- **Migration Strategy**: How should we transition from v3 to v4 in the fairest way possible?
|
||||
- **Exit Restrictions**: When TFT market price is low, what exit rules best protect the system while serving farmers?
|
||||
|
||||
</div>
|
||||
|
||||
## How to Provide Feedback
|
||||
|
||||
<div className="feedback-box">
|
||||
|
||||
### 📢 We Need Your Input!
|
||||
|
||||
Your experience and perspective are valuable to making this plan work for everyone. Please join the discussion through any of these channels:
|
||||
|
||||
<div className="feedback-links">
|
||||
<a href="https://forum.threefold.io/t/tft-minting-transition-plan-community-e-book/4647" target="_blank" className="feedback-link">💬 Forum Discussion</a>
|
||||
<a href="https://t.me/threefoldfarmers" target="_blank" className="feedback-link">💬 Telegram Chat</a>
|
||||
<a href="https://bit.ly/tfcommunitycall" target="_blank" className="feedback-link">📞 Community Call</a>
|
||||
</div>
|
||||
|
||||
**Main Discussion**: Join the [forum thread](https://forum.threefold.io/t/tft-minting-transition-plan-community-e-book/4647) to share your thoughts and ask questions.
|
||||
|
||||
**Community Call**: We're scheduling a dedicated call to walk through this plan and gather your feedback. [Join the call](https://bit.ly/tfcommunitycall).
|
||||
|
||||
</div>
|
||||
|
||||
## What Happens Next
|
||||
|
||||
1. **Community Review**: We want your feedback on the concepts, parameters, and any concerns you have
|
||||
2. **Refinement**: Based on input, we'll update and clarify the plan
|
||||
3. **Community Call**: Interactive session to discuss and answer questions
|
||||
4. **Finalization**: Incorporate feedback and prepare for implementation
|
||||
5. **Migration**: Clear timeline and process for moving from v3 to v4
|
||||
|
||||
## How to Read This Documentation
|
||||
|
||||
- **Implementation & Roadmap**: See what's happening now and what's coming soon
|
||||
- **Core Concepts**: Understand the fundamental token and liquidity mechanisms
|
||||
- **Node Economics**: Explore farmer income models, pricing, and capacity commitments
|
||||
- **Appendix**: Meeting notes and detailed technical discussions for transparency
|
||||
- **Operations**: Technical documentation for deployment and maintenance
|
||||
|
||||
:::tip Get Started
|
||||
Ready to dive in? Start with the [Token System](/core-concepts/token-system) to understand the foundational architecture.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
*This is a community-driven initiative. Your participation helps shape the future of ThreeFold's token economics.*
|
||||
10
docs/node-economics/_category_.json
Normal file
10
docs/node-economics/_category_.json
Normal file
@@ -0,0 +1,10 @@
|
||||
{
|
||||
"label": "Node Economics & Pricing",
|
||||
"position": 3,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"title": "Node Economics & Pricing",
|
||||
"description": "Understand the economic model for TFGrid farmers, including node specifications, pricing structures, income projections, and ThreeFold's committed capacity bids.",
|
||||
"slug": "/node-economics"
|
||||
}
|
||||
}
|
||||
496
docs/node-economics/node-specifications.md
Normal file
496
docs/node-economics/node-specifications.md
Normal file
@@ -0,0 +1,496 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Node Specifications & Income Projections
|
||||
|
||||
This page provides detailed specifications for all node types, including hardware costs, resource allocations, and income projections based on the slices model.
|
||||
|
||||
:::info Price Assumptions
|
||||
- **Cloud Credits (CC)** pegged at 1/1000 gram of gold ≈ **$0.128 USD** (as of Oct 8, 2024)
|
||||
- **Hardware costs** amortized over **5-year lifespan**
|
||||
- **Revenue share**: 80% to farmer, 10% burned, 10% to ThreeFold
|
||||
- **No CPU oversubscription** in current calculations
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Non-Certified Nodes
|
||||
|
||||
Non-certified nodes are community-contributed hardware that meets minimum specifications but hasn't gone through the formal certification process.
|
||||
|
||||
### 3Node Home
|
||||
|
||||
**Target**: Home users, hobbyists, small-scale farmers
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $500 |
|
||||
| **CPU Cores** | 16 |
|
||||
| **Passmark** | 22,000 |
|
||||
| **Memory** | 32 GB |
|
||||
| **SSD Storage** | 1,000 GB |
|
||||
| **GPU Memory** | - |
|
||||
| **TPS** | - |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 25 |
|
||||
| **HW Cost/Month (5Y)** | 8 CC |
|
||||
| **Min Income/Month** | 10.92 CC |
|
||||
| **Max Income/Month** | 126 CC |
|
||||
| **Typical Active Slices** | 7 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 2.3 cores
|
||||
- Performance: 3,143 Passmark
|
||||
- Memory: 4.0 GB
|
||||
- Storage: 143 GB
|
||||
- Price Range: 1.2 - 12.0 CC/month
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~3-4 years at minimum income
|
||||
- **Best case**: 6-8 months at maximum utilization
|
||||
- **Realistic**: 12-18 months at 50% utilization
|
||||
|
||||
---
|
||||
|
||||
### Large TFGrid Node
|
||||
|
||||
**Target**: Dedicated farmers, data center deployments
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $2,000 |
|
||||
| **CPU Cores** | 36 |
|
||||
| **Passmark** | 20,000 |
|
||||
| **Memory** | 512 GB |
|
||||
| **SSD Storage** | 4,000 GB |
|
||||
| **GPU Memory** | - |
|
||||
| **TPS** | - |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 100 |
|
||||
| **HW Cost/Month (5Y)** | 33 CC |
|
||||
| **Min Income/Month** | 198.12 CC |
|
||||
| **Max Income/Month** | 2,286 CC |
|
||||
| **Typical Active Slices** | 20 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 1.8 cores
|
||||
- Performance: 1,000 Passmark
|
||||
- Memory: 25.4 GB
|
||||
- Storage: 200 GB
|
||||
- Price Range: 7.6 - 76.2 CC/month
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~10-12 months at minimum income
|
||||
- **Best case**: 1 month at maximum utilization
|
||||
- **Realistic**: 4-6 months at 40% utilization
|
||||
|
||||
:::tip High Memory Advantage
|
||||
This node's high memory (512 GB) makes it ideal for memory-heavy slices, commanding premium pricing.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
### Large TFGrid Node 2
|
||||
|
||||
**Target**: Budget-conscious farmers, balanced workloads
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $1,200 |
|
||||
| **CPU Cores** | 36 |
|
||||
| **Passmark** | 20,000 |
|
||||
| **Memory** | 128 GB |
|
||||
| **SSD Storage** | 2,000 GB |
|
||||
| **GPU Memory** | - |
|
||||
| **TPS** | - |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 100 |
|
||||
| **HW Cost/Month (5Y)** | 20 CC |
|
||||
| **Min Income/Month** | 48.36 CC |
|
||||
| **Max Income/Month** | 558 CC |
|
||||
| **Typical Active Slices** | 20 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 1.8 cores
|
||||
- Performance: 1,000 Passmark
|
||||
- Memory: 6.2 GB
|
||||
- Storage: 100 GB
|
||||
- Price Range: 1.9 - 18.6 CC/month
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~2-3 years at minimum income
|
||||
- **Best case**: 2-3 months at maximum utilization
|
||||
- **Realistic**: 8-12 months at 40% utilization
|
||||
|
||||
---
|
||||
|
||||
## Certified Nodes (New Batch Q4 2025)
|
||||
|
||||
Certified nodes are pre-configured, tested hardware packages from approved vendors, ensuring quality and reliability.
|
||||
|
||||
### Mini 1
|
||||
|
||||
**Target**: Entry-level certified farming
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $350 |
|
||||
| **CPU Cores** | 16 |
|
||||
| **Passmark** | 16,000 |
|
||||
| **Memory** | 32 GB |
|
||||
| **SSD Storage** | 1,000 GB |
|
||||
| **GPU Memory** | - |
|
||||
| **TPS** | - |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 25 |
|
||||
| **HW Cost/Month (5Y)** | 6 CC |
|
||||
| **Min Income/Month** | 11 CC |
|
||||
| **Max Income/Month** | 126 CC |
|
||||
| **Typical Active Slices** | 7 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 2.3 cores
|
||||
- Performance: 2,286 Passmark
|
||||
- Memory: 4.0 GB
|
||||
- Storage: 143 GB
|
||||
- Price Range: 1.2 - 12.0 CC/month
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~3 years at minimum income
|
||||
- **Best case**: 3-4 months at maximum utilization
|
||||
- **Realistic**: 10-14 months at 50% utilization
|
||||
|
||||
---
|
||||
|
||||
### Mini 2
|
||||
|
||||
**Target**: Mid-range certified farming, small business
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $800 |
|
||||
| **CPU Cores** | 24 |
|
||||
| **Passmark** | 25,000 |
|
||||
| **Memory** | 64 GB |
|
||||
| **SSD Storage** | 2,000 GB |
|
||||
| **GPU Memory** | - |
|
||||
| **TPS** | - |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 25 |
|
||||
| **HW Cost/Month (5Y)** | 13 CC |
|
||||
| **Min Income/Month** | 23 CC |
|
||||
| **Max Income/Month** | 270 CC |
|
||||
| **Typical Active Slices** | 15 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 1.6 cores
|
||||
- Performance: 1,667 Passmark
|
||||
- Memory: 4.0 GB
|
||||
- Storage: 133 GB
|
||||
- Price Range: 1.2 - 12.0 CC/month
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~2.5-3 years at minimum income
|
||||
- **Best case**: 3-4 months at maximum utilization
|
||||
- **Realistic**: 10-12 months at 55% utilization
|
||||
|
||||
---
|
||||
|
||||
### Mini 3
|
||||
|
||||
**Target**: Serious certified farmers, enterprise edge deployments
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $1,000 |
|
||||
| **CPU Cores** | 24 |
|
||||
| **Passmark** | 25,000 |
|
||||
| **Memory** | 128 GB |
|
||||
| **SSD Storage** | 4,000 GB |
|
||||
| **GPU Memory** | - |
|
||||
| **TPS** | - |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 25 |
|
||||
| **HW Cost/Month (5Y)** | 17 CC |
|
||||
| **Min Income/Month** | 48 CC |
|
||||
| **Max Income/Month** | 558 CC |
|
||||
| **Typical Active Slices** | 25 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 1.0 cores
|
||||
- Performance: 1,000 Passmark
|
||||
- Memory: 5.0 GB
|
||||
- Storage: 160 GB
|
||||
- Price Range: 1.5 - 14.9 CC/month
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~1.5-2 years at minimum income
|
||||
- **Best case**: 2 months at maximum utilization
|
||||
- **Realistic**: 6-8 months at 60% utilization
|
||||
|
||||
:::tip Sweet Spot
|
||||
Mini 3 offers excellent balance of cost, performance, and storage. Strong ROI potential with good network utilization.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## AI-Focused Certified Nodes
|
||||
|
||||
These nodes include dedicated GPU hardware for AI/ML workloads, representing the future growth area of TFGrid.
|
||||
|
||||
### Mini AI 1
|
||||
|
||||
**Target**: Entry-level AI workloads, inference, development
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $2,000 |
|
||||
| **CPU Cores** | 32 |
|
||||
| **Passmark** | 50,000 |
|
||||
| **Memory** | 128 GB |
|
||||
| **SSD Storage** | 4,000 GB |
|
||||
| **GPU Memory** | 128 GB |
|
||||
| **TPS** | 20 |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 4 |
|
||||
| **HW Cost/Month (5Y)** | 33 CC |
|
||||
| **Min Income/Month** | 52 CC |
|
||||
| **Max Income/Month** | 600 CC |
|
||||
| **Typical Active Slices** | 4 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 8.0 cores
|
||||
- Performance: 12,500 Passmark
|
||||
- Memory: 31.0 GB
|
||||
- Storage: 1,000 GB
|
||||
- GPU: Shared access
|
||||
- TPS: 5
|
||||
- Price Range: 10 - 100 CC/month
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~3 years at minimum income
|
||||
- **Best case**: 3-4 months at maximum utilization
|
||||
- **Realistic**: 8-12 months at 70% utilization
|
||||
|
||||
---
|
||||
|
||||
### Nvidia 6000 (Single GPU)
|
||||
|
||||
**Target**: Professional AI training, high-end inference
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $15,000 |
|
||||
| **CPU Cores** | 24 |
|
||||
| **Passmark** | 35,000 |
|
||||
| **Memory** | 128 GB |
|
||||
| **SSD Storage** | 4,000 GB |
|
||||
| **GPU Memory** | 96 GB |
|
||||
| **TPS** | 350 |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 1 (dedicated full node) |
|
||||
| **HW Cost/Month (5Y)** | 250 CC |
|
||||
| **Min Income/Month** | 390 CC |
|
||||
| **Max Income/Month** | 4,500 CC |
|
||||
| **Typical Active Slices** | 1 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 24 cores (full node)
|
||||
- Performance: 35,000 Passmark
|
||||
- Memory: 124 GB
|
||||
- Storage: 4,000 GB
|
||||
- GPU: 96 GB dedicated
|
||||
- TPS: 350
|
||||
- Price Range: 300 - 3,000 CC/month
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~3 years at minimum income
|
||||
- **Best case**: 3-4 months at maximum utilization
|
||||
- **Realistic**: 10-14 months at 60% utilization
|
||||
|
||||
:::note High-Value Target
|
||||
These nodes target high-value AI workloads. Even at minimum pricing, they generate significant income if utilized.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
### Nvidia 6000 (Dual GPU)
|
||||
|
||||
**Target**: Large-scale AI training, enterprise ML operations
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $30,000 |
|
||||
| **CPU Cores** | 24 |
|
||||
| **Passmark** | 35,000 |
|
||||
| **Memory** | 128 GB |
|
||||
| **SSD Storage** | 8,000 GB |
|
||||
| **GPU Memory** | 192 GB (2x 96GB) |
|
||||
| **TPS** | 700 |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 2 (can be sold separately) |
|
||||
| **HW Cost/Month (5Y)** | 500 CC |
|
||||
| **Min Income/Month** | 780 CC |
|
||||
| **Max Income/Month** | 9,000 CC |
|
||||
| **Typical Active Slices** | 2 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 12 cores
|
||||
- Performance: 17,500 Passmark
|
||||
- Memory: 62 GB
|
||||
- Storage: 4,000 GB
|
||||
- GPU: 96 GB dedicated per slice
|
||||
- TPS: 350
|
||||
- Price Range: 300 - 3,000 CC/month per slice
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~3 years at minimum income
|
||||
- **Best case**: 3-4 months at maximum utilization
|
||||
- **Realistic**: 12-16 months at 50% utilization
|
||||
|
||||
---
|
||||
|
||||
### Tenstorrent 8x
|
||||
|
||||
**Target**: Cutting-edge AI acceleration, next-gen ML workloads
|
||||
|
||||
| Specification | Value |
|
||||
|--------------|-------|
|
||||
| **Estimate Cost** | $30,000 |
|
||||
| **CPU Cores** | 24 |
|
||||
| **Passmark** | 35,000 |
|
||||
| **Memory** | 128 GB |
|
||||
| **SSD Storage** | 8,000 GB |
|
||||
| **GPU Memory** | 192 GB |
|
||||
| **TPS** | 2,000 |
|
||||
|
||||
**Slices Economics**:
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| **Max Slices** | 2 |
|
||||
| **HW Cost/Month (5Y)** | 500 CC |
|
||||
| **Min Income/Month** | 780 CC |
|
||||
| **Max Income/Month** | 9,000 CC |
|
||||
| **Typical Active Slices** | 2 |
|
||||
|
||||
**Per Slice Resources**:
|
||||
- CPU: 12 cores
|
||||
- Performance: 17,500 Passmark
|
||||
- Memory: 62 GB
|
||||
- Storage: 4,000 GB
|
||||
- AI Memory: 96 GB dedicated per slice
|
||||
- TPS: 1,000
|
||||
- Price Range: 300 - 3,000 CC/month per slice
|
||||
|
||||
**ROI Analysis**:
|
||||
- **Break-even**: ~3 years at minimum income
|
||||
- **Best case**: 3-4 months at maximum utilization
|
||||
- **Realistic**: 12-16 months at 50% utilization
|
||||
|
||||
:::tip Tenstorrent Advantage
|
||||
With 2,000 TPS (vs 700 for Nvidia), Tenstorrent offers superior AI performance for specific workloads at the same price point.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Comparison Table: All Nodes
|
||||
|
||||
| Node Type | Cost | Monthly HW Cost | Min Income | Max Income | Break-Even (Min) | Break-Even (Max) |
|
||||
|-----------|------|-----------------|------------|------------|------------------|------------------|
|
||||
| **Non-Certified** |
|
||||
| 3Node Home | $500 | 8 CC | 10.92 CC | 126 CC | 3-4 years | 6-8 months |
|
||||
| Large TFGrid | $2,000 | 33 CC | 198.12 CC | 2,286 CC | 10-12 months | 1 month |
|
||||
| Large TFGrid 2 | $1,200 | 20 CC | 48.36 CC | 558 CC | 2-3 years | 2-3 months |
|
||||
| **Certified Q4 2025** |
|
||||
| Mini 1 | $350 | 6 CC | 11 CC | 126 CC | 3 years | 3-4 months |
|
||||
| Mini 2 | $800 | 13 CC | 23 CC | 270 CC | 2.5-3 years | 3-4 months |
|
||||
| Mini 3 | $1,000 | 17 CC | 48 CC | 558 CC | 1.5-2 years | 2 months |
|
||||
| **AI Nodes** |
|
||||
| Mini AI 1 | $2,000 | 33 CC | 52 CC | 600 CC | 3 years | 3-4 months |
|
||||
| Nvidia 6000 1x | $15,000 | 250 CC | 390 CC | 4,500 CC | 3 years | 3-4 months |
|
||||
| Nvidia 6000 2x | $30,000 | 500 CC | 780 CC | 9,000 CC | 3 years | 3-4 months |
|
||||
| Tenstorrent 8x | $30,000 | 500 CC | 780 CC | 9,000 CC | 3 years | 3-4 months |
|
||||
|
||||
---
|
||||
|
||||
## Key Insights
|
||||
|
||||
### For Standard Compute Nodes
|
||||
|
||||
- **3Node Home / Mini 1**: Good for hobbyists, learning the ecosystem
|
||||
- **Mini 2 / Mini 3**: Best balance of cost and ROI for serious farmers
|
||||
- **Large TFGrid**: Premium option for those with high memory workload expectations
|
||||
|
||||
### For AI-Focused Farming
|
||||
|
||||
- **Mini AI 1**: Entry point for AI farming, lower risk
|
||||
- **Nvidia 6000**: Industry-standard, proven demand
|
||||
- **Tenstorrent 8x**: Higher TPS for specific AI workloads, emerging technology
|
||||
|
||||
### General Observations
|
||||
|
||||
1. **AI nodes have higher upfront costs** but command premium pricing
|
||||
2. **Certified nodes** coming Q4 2025 provide quality assurance
|
||||
3. **Memory-heavy configurations** can charge more per slice
|
||||
4. **Break-even highly dependent** on network utilization
|
||||
5. **80% revenue share** means farmers keep majority of value
|
||||
|
||||
---
|
||||
|
||||
## Important Notes
|
||||
|
||||
**(*) Revenue Distribution**: 80% to hoster/farmer, 10% burned, 10% to ThreeFold
|
||||
|
||||
**No CPU Oversubscription**: Current calculations assume no CPU oversubscription. In reality, users will have more CPU available during low-demand periods, and potential oversubscription could increase effective income.
|
||||
|
||||
**Cloud Credit Conversion**: CC can be acquired by converting 2 TFT or by purchasing at fiat equivalent of 1/1000 gram of gold price = ~$0.128 USD (price as of Oct 8, 2024)
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **[Pricing Model](/node-economics/pricing-model)** - Deep dive into income scenarios and ROI calculations
|
||||
- **[TF Bid Packages](/node-economics/tf-bid-packages)** - See what ThreeFold is willing to buy
|
||||
- **[Slices Overview](/node-economics/slices-overview)** - Understand the slice concept
|
||||
|
||||
:::tip Hardware Planning
|
||||
Use these specifications to plan your hardware investment based on your budget, risk tolerance, and market expectations.
|
||||
:::
|
||||
449
docs/node-economics/pricing-model.md
Normal file
449
docs/node-economics/pricing-model.md
Normal file
@@ -0,0 +1,449 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Pricing Model & Income Analysis
|
||||
|
||||
Understanding the economics of farming is essential for making informed hardware decisions. This page breaks down pricing, utilization scenarios, and ROI calculations.
|
||||
|
||||
---
|
||||
|
||||
## Pricing Components
|
||||
|
||||
### Per-Slice Pricing Structure
|
||||
|
||||
Each slice has two key price points:
|
||||
|
||||
**Minimum Price** (Floor):
|
||||
- Conservative market pricing
|
||||
- Ensures farmers can cover costs
|
||||
- Competitive with major cloud providers at bulk rates
|
||||
- Assumes moderate demand
|
||||
|
||||
**Maximum Price** (Ceiling):
|
||||
- Premium positioning
|
||||
- Comparable to retail cloud pricing
|
||||
- Assumes high demand and full utilization
|
||||
- Competitive advantage scenarios
|
||||
|
||||
**Example: Standard Compute Slice**
|
||||
- Min: 1.2 CC/month (~$0.15)
|
||||
- Max: 12.0 CC/month (~$1.54)
|
||||
- Range: 10x spread between floor and ceiling
|
||||
|
||||
---
|
||||
|
||||
## Revenue Share Breakdown
|
||||
|
||||
Every Cloud Credit (CC) spent on TFGrid capacity is distributed as follows:
|
||||
|
||||
```mermaid
|
||||
pie title Revenue Distribution per 100 CC
|
||||
"Farmer (You!)" : 80
|
||||
"TFT Burn (Deflationary)" : 10
|
||||
"ThreeFold Operations" : 10
|
||||
```
|
||||
|
||||
### What This Means
|
||||
|
||||
If a user pays **100 CC** for your slices:
|
||||
|
||||
| Recipient | Amount | Purpose |
|
||||
|-----------|--------|---------|
|
||||
| **Farmer** | 80 CC | Your income |
|
||||
| **TFT Burn** | 10 CC | Reduces TFT supply → supports token value |
|
||||
| **ThreeFold** | 10 CC | Platform development, operations, support |
|
||||
|
||||
:::tip Farmer-First Model
|
||||
With 80% going directly to farmers, you keep the vast majority of value generated by your infrastructure.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Income Scenarios by Node Type
|
||||
|
||||
### Scenario Analysis Framework
|
||||
|
||||
We analyze three utilization scenarios for each node:
|
||||
|
||||
1. **Conservative** (20-30% utilization): Network still growing
|
||||
2. **Moderate** (50-60% utilization): Healthy network adoption
|
||||
3. **Optimistic** (80-100% utilization): High demand period
|
||||
|
||||
---
|
||||
|
||||
### Example: Mini 3 (Certified Node)
|
||||
|
||||
**Hardware Investment**: $1,000
|
||||
**Monthly HW Cost**: 17 CC
|
||||
**Maximum Slices**: 25
|
||||
**Typical Active Slices**: 25 (can provide full 25)
|
||||
|
||||
#### Conservative Scenario (30% utilization, min pricing)
|
||||
|
||||
```
|
||||
Active Slices: 25 × 30% = 7.5 slices
|
||||
Price per Slice: 1.5 CC (minimum)
|
||||
Gross Income: 7.5 × 1.5 = 11.25 CC/month
|
||||
Your Share (80%): 9 CC/month
|
||||
Net Profit: 9 - 17 = -8 CC/month (not profitable yet)
|
||||
```
|
||||
|
||||
**Status**: Needs higher utilization or pricing to be profitable
|
||||
|
||||
#### Moderate Scenario (60% utilization, mid pricing)
|
||||
|
||||
```
|
||||
Active Slices: 25 × 60% = 15 slices
|
||||
Price per Slice: 7.5 CC (midpoint)
|
||||
Gross Income: 15 × 7.5 = 112.5 CC/month
|
||||
Your Share (80%): 90 CC/month
|
||||
Net Profit: 90 - 17 = 73 CC/month
|
||||
Annual Profit: 73 × 12 = 876 CC (~$112/year)
|
||||
ROI: $1,000 investment / $112/year = 8.9 years
|
||||
```
|
||||
|
||||
**Status**: Profitable but slow ROI
|
||||
|
||||
#### Optimistic Scenario (100% utilization, premium pricing)
|
||||
|
||||
```
|
||||
Active Slices: 25 × 100% = 25 slices
|
||||
Price per Slice: 14.9 CC (maximum)
|
||||
Gross Income: 25 × 14.9 = 372.5 CC/month
|
||||
Your Share (80%): 298 CC/month
|
||||
Net Profit: 298 - 17 = 281 CC/month
|
||||
Annual Profit: 281 × 12 = 3,372 CC (~$432/year)
|
||||
ROI: $1,000 investment / $432/year = 2.3 years
|
||||
```
|
||||
|
||||
**Status**: Excellent ROI with strong demand
|
||||
|
||||
---
|
||||
|
||||
### Example: Large TFGrid Node
|
||||
|
||||
**Hardware Investment**: $2,000
|
||||
**Monthly HW Cost**: 33 CC
|
||||
**Maximum Slices**: 100
|
||||
**Typical Active Slices**: 20 (limited by resource balance)
|
||||
|
||||
#### Conservative Scenario (25% utilization, min pricing)
|
||||
|
||||
```
|
||||
Active Slices: 20 × 25% = 5 slices
|
||||
Price per Slice: 7.6 CC (minimum)
|
||||
Gross Income: 5 × 7.6 = 38 CC/month
|
||||
Your Share (80%): 30.4 CC/month
|
||||
Net Profit: 30.4 - 33 = -2.6 CC/month (slight loss)
|
||||
```
|
||||
|
||||
**Status**: Nearly break-even at low utilization
|
||||
|
||||
#### Moderate Scenario (50% utilization, mid pricing)
|
||||
|
||||
```
|
||||
Active Slices: 20 × 50% = 10 slices
|
||||
Price per Slice: 40 CC (midpoint)
|
||||
Gross Income: 10 × 40 = 400 CC/month
|
||||
Your Share (80%): 320 CC/month
|
||||
Net Profit: 320 - 33 = 287 CC/month
|
||||
Annual Profit: 287 × 12 = 3,444 CC (~$441/year)
|
||||
ROI: $2,000 investment / $441/year = 4.5 years
|
||||
```
|
||||
|
||||
**Status**: Solid profitability
|
||||
|
||||
#### Optimistic Scenario (100% utilization, premium pricing)
|
||||
|
||||
```
|
||||
Active Slices: 20 × 100% = 20 slices
|
||||
Price per Slice: 76.2 CC (maximum)
|
||||
Gross Income: 20 × 76.2 = 1,524 CC/month
|
||||
Your Share (80%): 1,219 CC/month
|
||||
Net Profit: 1,219 - 33 = 1,186 CC/month
|
||||
Annual Profit: 1,186 × 12 = 14,232 CC (~$1,822/year)
|
||||
ROI: $2,000 investment / $1,822/year = 1.1 years
|
||||
```
|
||||
|
||||
**Status**: Outstanding ROI
|
||||
|
||||
:::tip High-Memory Advantage
|
||||
Large TFGrid Node's 512 GB RAM enables premium memory-heavy slice pricing, driving higher income per active slice.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
### Example: Nvidia 6000 (Dual GPU)
|
||||
|
||||
**Hardware Investment**: $30,000
|
||||
**Monthly HW Cost**: 500 CC
|
||||
**Maximum Slices**: 2 (dedicated GPU slices)
|
||||
**Typical Active Slices**: 2
|
||||
|
||||
#### Conservative Scenario (50% utilization, min pricing)
|
||||
|
||||
```
|
||||
Active Slices: 2 × 50% = 1 slice
|
||||
Price per Slice: 300 CC (minimum)
|
||||
Gross Income: 1 × 300 = 300 CC/month
|
||||
Your Share (80%): 240 CC/month
|
||||
Net Profit: 240 - 500 = -260 CC/month (loss)
|
||||
```
|
||||
|
||||
**Status**: Needs higher utilization for profitability
|
||||
|
||||
#### Moderate Scenario (75% utilization, mid pricing)
|
||||
|
||||
```
|
||||
Active Slices: 2 × 75% = 1.5 slices
|
||||
Price per Slice: 1,650 CC (midpoint)
|
||||
Gross Income: 1.5 × 1,650 = 2,475 CC/month
|
||||
Your Share (80%): 1,980 CC/month
|
||||
Net Profit: 1,980 - 500 = 1,480 CC/month
|
||||
Annual Profit: 1,480 × 12 = 17,760 CC (~$2,273/year)
|
||||
ROI: $30,000 investment / $2,273/year = 13.2 years
|
||||
```
|
||||
|
||||
**Status**: Profitable but requires patience
|
||||
|
||||
#### Optimistic Scenario (100% utilization, premium pricing)
|
||||
|
||||
```
|
||||
Active Slices: 2 × 100% = 2 slices
|
||||
Price per Slice: 3,000 CC (maximum)
|
||||
Gross Income: 2 × 3,000 = 6,000 CC/month
|
||||
Your Share (80%): 4,800 CC/month
|
||||
Net Profit: 4,800 - 500 = 4,300 CC/month
|
||||
Annual Profit: 4,300 × 12 = 51,600 CC (~$6,605/year)
|
||||
ROI: $30,000 investment / $6,605/year = 4.5 years
|
||||
```
|
||||
|
||||
**Status**: Excellent returns with AI demand
|
||||
|
||||
:::note AI Premium Pricing
|
||||
GPU nodes can command significantly higher prices due to AI/ML demand. Market pricing for comparable GPU cloud instances supports these ranges.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Income Comparison: All Nodes at 50% Utilization
|
||||
|
||||
Assuming **50% utilization** and **mid-point pricing**:
|
||||
|
||||
| Node Type | HW Cost | Monthly Net | Annual Net | ROI (Years) | Annual % Return |
|
||||
|-----------|---------|-------------|------------|-------------|-----------------|
|
||||
| 3Node Home | $500 | ~35 CC | ~420 CC | ~10 | ~10% |
|
||||
| Large TFGrid | $2,000 | ~287 CC | ~3,444 CC | ~4.5 | ~22% |
|
||||
| Large TFGrid 2 | $1,200 | ~100 CC | ~1,200 CC | ~8 | ~12.5% |
|
||||
| Mini 1 | $350 | ~30 CC | ~360 CC | ~8 | ~12.5% |
|
||||
| Mini 2 | $800 | ~60 CC | ~720 CC | ~9 | ~11% |
|
||||
| Mini 3 | $1,000 | ~73 CC | ~876 CC | ~9 | ~11% |
|
||||
| Mini AI 1 | $2,000 | ~140 CC | ~1,680 CC | ~9.5 | ~10.5% |
|
||||
| Nvidia 6000 1x | $15,000 | ~875 CC | ~10,500 CC | ~11.4 | ~8.8% |
|
||||
| Nvidia 6000 2x | $30,000 | ~1,480 CC | ~17,760 CC | ~13.5 | ~7.4% |
|
||||
| Tenstorrent 8x | $30,000 | ~1,480 CC | ~17,760 CC | ~13.5 | ~7.4% |
|
||||
|
||||
*CC values converted to USD at $0.128/CC for ROI calculations*
|
||||
|
||||
---
|
||||
|
||||
## Key Factors Affecting Income
|
||||
|
||||
### 1. Network Utilization
|
||||
|
||||
**What drives it**:
|
||||
- Total TFGrid capacity available
|
||||
- Number of active users/applications
|
||||
- Seasonal demand fluctuations
|
||||
- Marketing and ecosystem growth
|
||||
|
||||
**Your influence**:
|
||||
- Limited direct control
|
||||
- Participate in community promotion
|
||||
- Ensure node uptime and reliability
|
||||
|
||||
### 2. Pricing Strategy
|
||||
|
||||
**Competitive considerations**:
|
||||
- AWS, GCP, Azure pricing benchmarks
|
||||
- Other TFGrid farmers' pricing
|
||||
- Your node's specifications (certified vs. non-certified)
|
||||
- Geographic location / latency advantages
|
||||
|
||||
**Your influence**:
|
||||
- Set competitive pricing when marketplace allows
|
||||
- Offer discounts for long-term commitments
|
||||
- Premium pricing for certified or high-spec nodes
|
||||
|
||||
### 3. Node Uptime & Reliability
|
||||
|
||||
**Impact**:
|
||||
- Downtime = no income during that period
|
||||
- Poor reliability = lost customers
|
||||
- Consistent uptime = reputation and repeat business
|
||||
|
||||
**Your influence**:
|
||||
- Invest in quality hardware
|
||||
- Ensure stable internet connection
|
||||
- Monitor and maintain proactively
|
||||
- Use UPS/backup power if possible
|
||||
|
||||
### 4. Resource Balance
|
||||
|
||||
**What matters**:
|
||||
- Nodes limited by weakest resource (CPU, RAM, or storage)
|
||||
- Well-balanced nodes can sell more slices
|
||||
- Bottlenecks reduce effective slice count
|
||||
|
||||
**Your influence**:
|
||||
- Choose balanced hardware configurations
|
||||
- Consider upgrading bottlenecks (e.g., add RAM)
|
||||
- Understand which resource constrains your node
|
||||
|
||||
---
|
||||
|
||||
## ROI Sensitivities
|
||||
|
||||
### Utilization Impact
|
||||
|
||||
For a **Mini 3** node ($1,000 investment):
|
||||
|
||||
| Utilization | Monthly Net Profit | Annual Profit | ROI Years |
|
||||
|-------------|-------------------|---------------|-----------|
|
||||
| 20% | -8 CC | -96 CC | Never (loss) |
|
||||
| 30% | 9 CC | 108 CC | 74 years |
|
||||
| 40% | 45 CC | 540 CC | 14.8 years |
|
||||
| 50% | 73 CC | 876 CC | 9.1 years |
|
||||
| 60% | 109 CC | 1,308 CC | 6.1 years |
|
||||
| 80% | 181 CC | 2,172 CC | 3.7 years |
|
||||
| 100% | 253 CC | 3,036 CC | 2.6 years |
|
||||
|
||||
*Assumes mid-point pricing at all utilization levels*
|
||||
|
||||
### Pricing Impact
|
||||
|
||||
For a **Large TFGrid Node** ($2,000 investment) at **50% utilization**:
|
||||
|
||||
| Price Point | Monthly Net Profit | Annual Profit | ROI Years |
|
||||
|-------------|-------------------|---------------|-----------|
|
||||
| Minimum | 99 CC | 1,188 CC | 13.4 years |
|
||||
| 25th percentile | 420 CC | 5,040 CC | 3.2 years |
|
||||
| Midpoint | 287 CC | 3,444 CC | 4.6 years |
|
||||
| 75th percentile | 756 CC | 9,072 CC | 1.8 years |
|
||||
| Maximum | 1,186 CC | 14,232 CC | 1.1 years |
|
||||
|
||||
---
|
||||
|
||||
## Comparative Cloud Pricing
|
||||
|
||||
To validate our pricing model, here's how TFGrid compares to major cloud providers:
|
||||
|
||||
### Standard Compute Instance
|
||||
|
||||
**TFGrid Standard Slice**:
|
||||
- 2 cores, 4 GB RAM, ~140 GB SSD
|
||||
- Price: 1.2 - 12.0 CC/month ($0.15 - $1.54/month)
|
||||
- Hourly: $0.005 - $0.05/hour
|
||||
|
||||
**AWS t3.medium**:
|
||||
- 2 vCPUs, 4 GB RAM
|
||||
- Price: ~$30/month (~$0.042/hour)
|
||||
|
||||
**GCP e2-medium**:
|
||||
- 2 vCPUs, 4 GB RAM
|
||||
- Price: ~$24/month (~$0.033/hour)
|
||||
|
||||
**TFGrid Advantage**: 50-95% cheaper than major clouds at similar specs
|
||||
|
||||
### AI/GPU Instance
|
||||
|
||||
**TFGrid AI Slice (Nvidia 6000)**:
|
||||
- 24 cores, 124 GB RAM, 96 GB GPU
|
||||
- Price: 300 - 3,000 CC/month ($38 - $384/month)
|
||||
- Hourly: $0.053 - $0.53/hour
|
||||
|
||||
**AWS p3.2xlarge** (V100 16GB):
|
||||
- 8 vCPUs, 61 GB RAM, 16 GB GPU
|
||||
- Price: ~$3.06/hour (~$2,200/month for full-time)
|
||||
|
||||
**GCP a2-highgpu-1g** (A100 40GB):
|
||||
- 12 vCPUs, 85 GB RAM, 40 GB GPU
|
||||
- Price: ~$3.67/hour (~$2,640/month for full-time)
|
||||
|
||||
**TFGrid Advantage**: 80-95% cheaper with larger GPU memory (96 GB vs 16-40 GB)
|
||||
|
||||
:::tip Competitive Positioning
|
||||
Even at maximum pricing, TFGrid undercuts major cloud providers significantly. At minimum pricing, it's dramatically cheaper while providing more resources.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Risk Factors & Considerations
|
||||
|
||||
### Market Risks
|
||||
|
||||
- **Network adoption rate**: Slower than expected growth delays profitability
|
||||
- **Competition**: Other decentralized cloud platforms
|
||||
- **Pricing pressure**: Race to the bottom if oversupply occurs
|
||||
- **Technology shifts**: New hardware makes existing nodes obsolete faster
|
||||
|
||||
### Operational Risks
|
||||
|
||||
- **Electricity costs**: Not included in hardware cost calculations
|
||||
- **Internet costs**: Bandwidth charges in some regions
|
||||
- **Maintenance**: Hardware failures, replacements
|
||||
- **Obsolescence**: 5-year amortization assumes hardware remains competitive
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
- **Start small**: Test with lower-cost nodes before scaling
|
||||
- **Diversify**: Mix node types (standard + AI)
|
||||
- **Stay informed**: Active participation in community
|
||||
- **Plan for upgrades**: Budget for hardware refresh cycles
|
||||
|
||||
---
|
||||
|
||||
## Total Capacity & Market Size
|
||||
|
||||
Based on ThreeFold's current bid commitments (see [TF Bid Packages](/node-economics/tf-bid-packages)):
|
||||
|
||||
**Total Potential Market**:
|
||||
- ~24,150 slices across all bid types
|
||||
- ~$253,800/month at minimum pricing
|
||||
- ~$3,965,625/month at maximum pricing
|
||||
- ~$507 million annual market at maximum pricing
|
||||
|
||||
**This represents committed ThreeFold demand**, not total market potential. Additional demand will come from:
|
||||
- End-user applications
|
||||
- Enterprise offtakers
|
||||
- Individual developers and projects
|
||||
- Partner ecosystems
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### For Potential Farmers
|
||||
|
||||
1. **Review [Node Specifications](/node-economics/node-specifications)** - Choose hardware based on budget
|
||||
2. **Run your own calculations** - Use your local electricity/internet costs
|
||||
3. **Start conservative** - Plan for 30-40% utilization initially
|
||||
4. **Monitor and adjust** - Track real performance and optimize
|
||||
|
||||
### For Current Farmers
|
||||
|
||||
1. **Evaluate upgrade paths** - Consider certified nodes Q4 2025
|
||||
2. **Optimize pricing** - Balance competitiveness with profitability
|
||||
3. **Improve uptime** - Maximize income from existing hardware
|
||||
4. **Plan for AI** - GPU nodes represent significant growth opportunity
|
||||
|
||||
---
|
||||
|
||||
:::info Living Document
|
||||
As the network matures and real utilization data becomes available, these projections will be refined. Join the community to stay updated on actual farmer income reports.
|
||||
:::
|
||||
|
||||
:::tip Questions?
|
||||
Discuss pricing strategies and share experiences in the [ThreeFold Forum](https://forum.threefold.io) and [Telegram community](https://t.me/threefoldfarmers).
|
||||
:::
|
||||
274
docs/node-economics/slices-overview.md
Normal file
274
docs/node-economics/slices-overview.md
Normal file
@@ -0,0 +1,274 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Understanding Slices
|
||||
|
||||
Slices are the fundamental unit of capacity allocation in TFGrid v4. Think of them as standardized "packages" of compute resources that make it easy to price, allocate, and utilize node capacity efficiently.
|
||||
|
||||
---
|
||||
|
||||
## What is a Slice?
|
||||
|
||||
A **slice** is a defined portion of a node's total resources, including:
|
||||
|
||||
- **CPU Cores**: Processing power allocated to the slice
|
||||
- **Performance (Passmark)**: Benchmark score indicating CPU performance
|
||||
- **Memory (RAM)**: Gigabytes of system memory
|
||||
- **Storage (SSD)**: Gigabytes of fast storage
|
||||
- **TPS (Tokens Per Second)**: For AI workloads, processing capability
|
||||
|
||||
Rather than selling "whole nodes" or arbitrary resource amounts, slices provide:
|
||||
- **Standardization**: Predictable resource bundles
|
||||
- **Flexibility**: Users can consume 1 slice or 100 slices
|
||||
- **Efficiency**: Better matching of supply to demand
|
||||
- **Clarity**: Transparent pricing per slice
|
||||
|
||||
---
|
||||
|
||||
## Why Slices?
|
||||
|
||||
### The Old Problem
|
||||
|
||||
**Without slices**:
|
||||
- Users need to understand complex hardware specifications
|
||||
- Pricing is inconsistent across different node types
|
||||
- Hard to compare value between providers
|
||||
- Resources often underutilized or over-provisioned
|
||||
|
||||
### The Slice Solution
|
||||
|
||||
**With slices**:
|
||||
- Simple, standardized packages (like buying "small", "medium", "large")
|
||||
- Consistent pricing model across the network
|
||||
- Easy comparison: "This slice costs X, provides Y resources"
|
||||
- Better utilization: Divide nodes into right-sized portions
|
||||
|
||||
---
|
||||
|
||||
## How Nodes Divide Into Slices
|
||||
|
||||
Each physical node can support a **maximum number of slices** based on its specifications.
|
||||
|
||||
### Example: 3Node Home
|
||||
|
||||
**Total Resources**:
|
||||
- 16 CPU cores
|
||||
- 22,000 Passmark score
|
||||
- 32 GB RAM
|
||||
- 1,000 GB SSD
|
||||
|
||||
**Maximum Slices**: 25
|
||||
|
||||
**Per Slice** (resources divided):
|
||||
- 2.3 cores (16 ÷ 7 slices actually used)
|
||||
- 3,143 Passmark performance
|
||||
- 4.0 GB RAM
|
||||
- 143 GB SSD
|
||||
|
||||
:::note Resource Allocation
|
||||
Not all nodes use their maximum slice count. The actual slices used depends on the node's resource constraints. For example, a 3Node Home is limited by RAM, so it provides 7 slices despite having capacity for 25.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Slice Types
|
||||
|
||||
Different workloads need different resource balances. ThreeFold offers several slice configurations:
|
||||
|
||||
### Standard Compute Slice
|
||||
**Best for**: General applications, web services, APIs
|
||||
|
||||
**Resources**:
|
||||
- ~2,000 Passmark performance
|
||||
- 4 GB RAM
|
||||
- Standard storage
|
||||
|
||||
**Price**: ~1.2 CC/month minimum
|
||||
|
||||
### Memory-Heavy Slice
|
||||
**Best for**: Databases, caching, memory-intensive applications
|
||||
|
||||
**Resources**:
|
||||
- Standard performance
|
||||
- 8 GB RAM (double standard)
|
||||
- Standard storage
|
||||
|
||||
**Price**: ~2.4 CC/month minimum
|
||||
|
||||
### AI Slice (Standard)
|
||||
**Best for**: AI inference, small models, development
|
||||
|
||||
**Resources**:
|
||||
- Moderate performance
|
||||
- 124 GB RAM
|
||||
- Shared GPU access
|
||||
|
||||
**Price**: ~50 CC/month minimum
|
||||
|
||||
### AI Slice (Dedicated GPU)
|
||||
**Best for**: AI training, large models, high-performance inference
|
||||
|
||||
**Resources**:
|
||||
- High performance
|
||||
- 124-250 GB RAM
|
||||
- Dedicated GPU (96-192 GB GPU memory)
|
||||
|
||||
**Price**: 500-1,000 CC/month minimum
|
||||
|
||||
See [TF Bid Packages](/node-economics/tf-bid-packages) for complete specifications.
|
||||
|
||||
---
|
||||
|
||||
## Slices and Farmer Income
|
||||
|
||||
Slices directly determine farmer earnings:
|
||||
|
||||
### Income Calculation
|
||||
|
||||
```
|
||||
Monthly Income = (Number of Active Slices) × (Price Per Slice) × (Utilization Rate)
|
||||
```
|
||||
|
||||
**Example**:
|
||||
- Node: Large TFGrid Node with 20 slices
|
||||
- Price per slice: 7.6 CC (minimum pricing)
|
||||
- Utilization: 80% (16 slices rented)
|
||||
- **Monthly Income**: 16 × 7.6 = 121.6 CC/month (~$15.56 at 1 CC = $0.128)
|
||||
|
||||
### Income Ranges
|
||||
|
||||
Each node type has:
|
||||
- **Minimum Income**: Conservative pricing, partial utilization
|
||||
- **Maximum Income**: Premium pricing, full utilization
|
||||
|
||||
See [Pricing Model](/node-economics/pricing-model) for detailed projections and ROI analysis.
|
||||
|
||||
---
|
||||
|
||||
## Slices and the 80% Revenue Share
|
||||
|
||||
The slice pricing includes the revenue share model:
|
||||
|
||||
1. **User pays for slice**: Example: 10 CC/month
|
||||
2. **Revenue distribution**:
|
||||
- **80%** → Farmer (8 CC)
|
||||
- **10%** → TFT Burn (1 CC worth of TFT burned)
|
||||
- **10%** → ThreeFold Operations (1 CC)
|
||||
|
||||
:::tip Farmer-First Economics
|
||||
With 80% going directly to farmers, the slice model ensures capacity providers receive the majority of value generated.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Oversubscription
|
||||
|
||||
One important note from the current calculation: **CPU oversubscription is not currently factored in**.
|
||||
|
||||
### What is Oversubscription?
|
||||
|
||||
In practice, most workloads don't use 100% of allocated CPU 100% of the time. Cloud providers often oversubscribe CPU (sell more CPU cores than physically exist) because:
|
||||
- Most workloads are bursty (high usage occasionally, low usage normally)
|
||||
- Statistical multiplexing: not all users peak at the same time
|
||||
- Better hardware utilization and economics
|
||||
|
||||
### Future Implementation
|
||||
|
||||
TFGrid may implement CPU oversubscription carefully:
|
||||
- **Benefit**: Higher effective income per node
|
||||
- **Risk**: Must ensure quality of service isn't degraded
|
||||
- **Balance**: Conservative ratios (e.g., 1.5x or 2x) rather than aggressive oversubscription
|
||||
|
||||
:::caution Current Status
|
||||
The income projections in this documentation assume **no CPU oversubscription**. Actual income could be higher if careful oversubscription is implemented in the future.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Slices in Practice
|
||||
|
||||
### For Users
|
||||
|
||||
**Simple shopping experience**:
|
||||
1. Browse available slice types
|
||||
2. See clear pricing and resources
|
||||
3. Deploy workloads to slices
|
||||
4. Scale up or down as needed
|
||||
|
||||
**No complex calculations** about "how many cores do I need vs. RAM vs. storage?"
|
||||
|
||||
### For Farmers
|
||||
|
||||
**Predictable capacity planning**:
|
||||
1. Know your node specifications
|
||||
2. Calculate maximum slices
|
||||
3. Set competitive pricing
|
||||
4. Track utilization and income
|
||||
|
||||
**Clear comparison** between different hardware investments.
|
||||
|
||||
---
|
||||
|
||||
## Example Scenarios
|
||||
|
||||
### Scenario 1: Web Hosting Company
|
||||
|
||||
**Needs**: Run 50 WordPress sites
|
||||
|
||||
**Solution**:
|
||||
- Rent 10 Standard Compute Slices
|
||||
- Each slice hosts 5 sites
|
||||
- Cost: 10 × 1.2 CC = 12 CC/month (~$1.54)
|
||||
- Clear, predictable pricing
|
||||
|
||||
### Scenario 2: AI Startup
|
||||
|
||||
**Needs**: Train a medium language model
|
||||
|
||||
**Solution**:
|
||||
- Rent 2 AI Slice Big (Nvidia 2x)
|
||||
- Dedicated 192 GB GPU memory each
|
||||
- Cost: 2 × 1,000 CC = 2,000 CC/month (~$256)
|
||||
- Direct comparison to AWS/GCP alternatives
|
||||
|
||||
### Scenario 3: Farmer Planning
|
||||
|
||||
**Hardware**: Investing in Mini 3 node
|
||||
|
||||
**Capacity**: 25 slices maximum
|
||||
|
||||
**Income Target**:
|
||||
- Conservative: 48 CC/month minimum (partial utilization)
|
||||
- Optimistic: 558 CC/month maximum (full utilization, premium pricing)
|
||||
- Realistic: ~200-300 CC/month with good network adoption
|
||||
|
||||
See [Node Specifications](/node-economics/node-specifications) for all node types.
|
||||
|
||||
---
|
||||
|
||||
## Key Takeaways
|
||||
|
||||
✅ **Slices standardize capacity** into easy-to-understand packages
|
||||
|
||||
✅ **Better resource utilization** than whole-node or arbitrary allocations
|
||||
|
||||
✅ **Clear pricing model** for both users and farmers
|
||||
|
||||
✅ **Flexible scaling** - consume exactly what you need
|
||||
|
||||
✅ **Direct income correlation** - more slices rented = more income
|
||||
|
||||
✅ **Farmer-first revenue share** - 80% goes to capacity providers
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **[Node Specifications](/node-economics/node-specifications)** - See detailed specs for all node types
|
||||
- **[Pricing Model](/node-economics/pricing-model)** - Understand income projections and ROI
|
||||
- **[TF Bid Packages](/node-economics/tf-bid-packages)** - Explore standard ThreeFold offerings
|
||||
|
||||
:::tip Related Concept
|
||||
Slices work seamlessly with the [Cloud Credits (CC)](/core-concepts/token-system) stable pricing system, ensuring predictable economics for everyone.
|
||||
:::
|
||||
418
docs/node-economics/tf-bid-packages.md
Normal file
418
docs/node-economics/tf-bid-packages.md
Normal file
@@ -0,0 +1,418 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# ThreeFold Bid Packages
|
||||
|
||||
ThreeFold commits to purchasing specific capacity packages at defined minimum specifications and pricing. These "bids" represent guaranteed demand that farmers can fulfill by providing qualifying capacity.
|
||||
|
||||
:::info What Are Bids?
|
||||
Bids are ThreeFold's standing offers to purchase specific types of slices. If your node meets the minimum requirements, you can fulfill these bids and receive the stated pricing.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Standard Bid Packages
|
||||
|
||||
### Standard Compute Slice
|
||||
|
||||
**Target Workloads**: General web applications, APIs, microservices, development environments
|
||||
|
||||
**Minimum Requirements**:
|
||||
|
||||
| Specification | Minimum Value |
|
||||
|--------------|---------------|
|
||||
| **Performance** | 2,000 Passmark |
|
||||
| **Memory** | 4 GB |
|
||||
| **GPU Memory** | - |
|
||||
|
||||
**Pricing**:
|
||||
- **1.2 CC/month** per slice
|
||||
- Can scale based on reservation duration (see [Reservation Pricing](#reservation-duration-pricing) below)
|
||||
|
||||
**Total ThreeFold Commitment**:
|
||||
- **20,000 slices** at this specification
|
||||
- **Total monthly value**: 24,000 CC (~$3,072 at $0.128/CC)
|
||||
|
||||
**Who Can Provide**:
|
||||
Most node types qualify:
|
||||
- 3Node Home ✅
|
||||
- All Mini series (1, 2, 3) ✅
|
||||
- Large TFGrid nodes ✅
|
||||
- AI nodes (but better used for AI bids) ✅
|
||||
|
||||
---
|
||||
|
||||
### Memory-Heavy Slice
|
||||
|
||||
**Target Workloads**: Databases (PostgreSQL, MySQL, Redis), caching layers, in-memory processing
|
||||
|
||||
**Minimum Requirements**:
|
||||
|
||||
| Specification | Minimum Value |
|
||||
|--------------|---------------|
|
||||
| **Memory** | 8 GB |
|
||||
|
||||
**Pricing**:
|
||||
- **2.4 CC/month** per slice (2x standard compute price)
|
||||
- Can scale based on reservation duration
|
||||
|
||||
**Total ThreeFold Commitment**:
|
||||
- **2,000 slices** at this specification
|
||||
- **Total monthly value**: 4,800 CC (~$614)
|
||||
|
||||
**Who Can Provide**:
|
||||
Nodes with higher memory configurations:
|
||||
- Mini 2 ✅
|
||||
- Mini 3 ✅
|
||||
- Large TFGrid Node ✅ (512 GB RAM - excellent fit)
|
||||
- All AI nodes ✅
|
||||
|
||||
:::tip High-Memory Premium
|
||||
Memory-heavy slices command 2x pricing of standard compute. If your node has abundant RAM, prioritize these bids.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## AI & GPU Bid Packages
|
||||
|
||||
### AI Slice (Standard)
|
||||
|
||||
**Target Workloads**: AI inference, small model training, ML development
|
||||
|
||||
**Minimum Requirements**:
|
||||
|
||||
| Specification | Minimum Value |
|
||||
|--------------|---------------|
|
||||
| **Memory** | 124 GB |
|
||||
|
||||
**Pricing**:
|
||||
- **50 CC/month** per slice
|
||||
- Based on full-node AI configuration (e.g., AI 395+ new nodes)
|
||||
|
||||
**Total ThreeFold Commitment**:
|
||||
- **2,000 slices** at this specification
|
||||
- **Total monthly value**: 100,000 CC (~$12,800)
|
||||
|
||||
**Who Can Provide**:
|
||||
High-spec AI nodes:
|
||||
- Mini AI 1 ✅ (entry point)
|
||||
- Nvidia 6000 variants ✅
|
||||
- Tenstorrent 8x ✅
|
||||
|
||||
**Note**: This represents full-node access for AI workloads with shared GPU resources.
|
||||
|
||||
---
|
||||
|
||||
### AI Slice Big (Nvidia 1x)
|
||||
|
||||
**Target Workloads**: Professional AI training, large model inference, production ML pipelines
|
||||
|
||||
**Minimum Requirements**:
|
||||
|
||||
| Specification | Minimum Value |
|
||||
|--------------|---------------|
|
||||
| **Memory** | 124 GB |
|
||||
| **GPU Memory** | 96 GB (dedicated) |
|
||||
|
||||
**Pricing**:
|
||||
- **500 CC/month** per slice
|
||||
- Dedicated GPU access (not shared)
|
||||
|
||||
**Total ThreeFold Commitment**:
|
||||
- **50 slices** at this specification
|
||||
- **Total monthly value**: 25,000 CC (~$3,200)
|
||||
|
||||
**Who Can Provide**:
|
||||
- Nvidia 6000 (Single GPU) ✅
|
||||
- Nvidia 6000 (Dual GPU) ✅ (can provide 2 slices)
|
||||
|
||||
**Key Feature**: **96 GB dedicated GPU memory** - significantly larger than typical cloud offerings (16-40 GB)
|
||||
|
||||
---
|
||||
|
||||
### AI Slice Big (Nvidia 2x)
|
||||
|
||||
**Target Workloads**: Large-scale AI training, multi-GPU model parallelism, enterprise ML operations
|
||||
|
||||
**Minimum Requirements**:
|
||||
|
||||
| Specification | Minimum Value |
|
||||
|--------------|---------------|
|
||||
| **Memory** | 250 GB |
|
||||
| **GPU Memory** | 192 GB (dedicated) |
|
||||
|
||||
**Pricing**:
|
||||
- **1,000 CC/month** per slice
|
||||
- Dual dedicated GPU access
|
||||
|
||||
**Total ThreeFold Commitment**:
|
||||
- **50 slices** at this specification
|
||||
- **Total monthly value**: 50,000 CC (~$6,400)
|
||||
|
||||
**Who Can Provide**:
|
||||
- Nvidia 6000 (Dual GPU) ✅
|
||||
|
||||
**Key Feature**: **192 GB AI Memory** for massive model training and inference
|
||||
|
||||
---
|
||||
|
||||
### AI Slice Big (Tenstorrent 8x)
|
||||
|
||||
**Target Workloads**: Next-generation AI acceleration, cutting-edge ML research, high-throughput inference
|
||||
|
||||
**Minimum Requirements**:
|
||||
|
||||
| Specification | Minimum Value |
|
||||
|--------------|---------------|
|
||||
| **Memory** | 250 GB |
|
||||
| **GPU Memory** | 192 GB (AI memory) |
|
||||
|
||||
**Pricing**:
|
||||
- **1,000 CC/month** per slice
|
||||
- 8x Tenstorrent accelerators
|
||||
|
||||
**Total ThreeFold Commitment**:
|
||||
- **50 slices** at this specification
|
||||
- **Total monthly value**: 50,000 CC (~$6,400)
|
||||
|
||||
**Who Can Provide**:
|
||||
- Tenstorrent 8x nodes ✅
|
||||
|
||||
**Key Advantage**: **2,000 TPS** (vs 700 for Nvidia) - significantly higher throughput for specific AI workloads
|
||||
|
||||
:::note Tenstorrent vs. Nvidia
|
||||
While Nvidia is industry-standard with broader ecosystem support, Tenstorrent offers superior performance (2,000 TPS vs 700 TPS) for certain AI workloads at the same price point.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Total Market Summary
|
||||
|
||||
**Combined ThreeFold Commitments**:
|
||||
|
||||
| Bid Package | Slices | Monthly Value | Annual Value |
|
||||
|-------------|--------|---------------|--------------|
|
||||
| Standard Compute | 20,000 | 24,000 CC | 288,000 CC |
|
||||
| Memory-Heavy | 2,000 | 4,800 CC | 57,600 CC |
|
||||
| AI Slice (Standard) | 2,000 | 100,000 CC | 1,200,000 CC |
|
||||
| AI Big (Nvidia 1x) | 50 | 25,000 CC | 300,000 CC |
|
||||
| AI Big (Nvidia 2x) | 50 | 50,000 CC | 600,000 CC |
|
||||
| AI Big (Tenstorrent 8x) | 50 | 50,000 CC | 600,000 CC |
|
||||
| **TOTAL** | **24,150** | **253,800 CC** | **3,045,600 CC** |
|
||||
|
||||
**Annual Value in USD** (at $0.128/CC): ~$389,837
|
||||
|
||||
:::tip Guaranteed Demand
|
||||
These bids represent **committed ThreeFold demand**. This is baseline capacity the platform will purchase, providing farmers with guaranteed revenue opportunities.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Reservation Duration Pricing
|
||||
|
||||
The pricing listed above is **baseline monthly pricing**. Actual prices vary based on minimum reservation duration:
|
||||
|
||||
### Pricing Tiers by Duration
|
||||
|
||||
**Example pricing structure**:
|
||||
|
||||
| Min Reservation | Price Modifier | Example (Standard Compute) |
|
||||
|-----------------|----------------|---------------------------|
|
||||
| **1 hour** | 1.0x - 10.0x | 1.2 - 12.0 CC/month |
|
||||
| **1 day** | 0.9x - 8.0x | 1.08 - 9.6 CC/month |
|
||||
| **1 week** | 0.8x - 6.0x | 0.96 - 7.2 CC/month |
|
||||
| **1 month** | 0.7x - 4.0x | 0.84 - 4.8 CC/month |
|
||||
| **3 months** | 0.6x - 3.0x | 0.72 - 3.6 CC/month |
|
||||
| **1 year** | 0.5x - 2.0x | 0.60 - 2.4 CC/month |
|
||||
|
||||
**Key Principle**: Longer commitments = lower per-unit pricing
|
||||
|
||||
**Benefits**:
|
||||
- **For farmers**: More predictable income, can offer discounts
|
||||
- **For users**: Cost savings for long-term workloads
|
||||
- **For platform**: Improved capacity planning
|
||||
|
||||
:::info Flexible Market
|
||||
These are baseline bids. Farmers can set custom pricing when the marketplace allows farmer price-setting (coming soon). See [Implementation Roadmap](/implementation-roadmap#farmer-price-setting-capability).
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## How to Qualify for Bids
|
||||
|
||||
### 1. Meet Minimum Specifications
|
||||
|
||||
Your node must meet or exceed the minimum requirements for the bid package:
|
||||
- Check [Node Specifications](/node-economics/node-specifications) for your hardware
|
||||
- Ensure adequate CPU, RAM, storage, and GPU (if applicable)
|
||||
|
||||
### 2. Maintain Uptime
|
||||
|
||||
High-quality, reliable capacity:
|
||||
- Target: 99%+ uptime
|
||||
- Stable internet connection
|
||||
- Proactive monitoring and maintenance
|
||||
|
||||
### 3. Proper Node Configuration
|
||||
|
||||
- Correct slice partitioning in node setup
|
||||
- Accurate resource reporting
|
||||
- Compatible with TFGrid v4 (when released) or v3 (currently)
|
||||
|
||||
### 4. Pricing Within Range
|
||||
|
||||
- Set pricing at or below bid price ceiling
|
||||
- Competitive with other farmers
|
||||
- Consider reservation duration discounts
|
||||
|
||||
---
|
||||
|
||||
## Beyond ThreeFold Bids
|
||||
|
||||
These bids represent **ThreeFold's committed demand**, not the total market:
|
||||
|
||||
### Additional Demand Sources
|
||||
|
||||
**End-User Applications**:
|
||||
- Applications built on TFGrid by partner teams
|
||||
- Direct user deployments
|
||||
- Enterprise customers
|
||||
|
||||
**Marketplace Transactions**:
|
||||
- Custom capacity requests
|
||||
- Bid-based capacity allocation (vast.ai model coming)
|
||||
- Private arrangements between users and farmers
|
||||
|
||||
**Partner Ecosystems**:
|
||||
- Integration with other platforms
|
||||
- White-label cloud offerings
|
||||
- Reseller channels
|
||||
|
||||
**Offtaker Agreements**:
|
||||
- Large-scale enterprise commitments
|
||||
- To be announced when commercially appropriate
|
||||
- Potentially significantly larger than baseline bids
|
||||
|
||||
:::note Market Growth
|
||||
As the ecosystem matures, demand will expand beyond these baseline bids. Early farmers establishing reputation and capacity will be well-positioned for growth.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Strategic Considerations for Farmers
|
||||
|
||||
### Capacity Planning
|
||||
|
||||
**Question**: Which bid packages should I target?
|
||||
|
||||
**Factors to consider**:
|
||||
1. **Hardware you can afford**: Start with budget constraints
|
||||
2. **Market competition**: Standard compute is crowded; AI is underserved
|
||||
3. **Growth potential**: AI demand is expanding rapidly
|
||||
4. **Risk tolerance**: Higher investment (AI) = higher potential returns but more risk
|
||||
|
||||
### Investment Strategies
|
||||
|
||||
**Conservative**:
|
||||
- Focus on Mini 1-3 nodes
|
||||
- Target standard compute and memory-heavy bids
|
||||
- Lower investment, proven demand
|
||||
- Slower but steadier ROI
|
||||
|
||||
**Balanced**:
|
||||
- Mix of standard nodes and entry AI (Mini AI 1)
|
||||
- Diversify across bid types
|
||||
- Moderate investment and risk
|
||||
- Flexible capacity allocation
|
||||
|
||||
**Aggressive**:
|
||||
- Focus on high-end AI nodes (Nvidia 6000, Tenstorrent)
|
||||
- Target AI bid packages
|
||||
- High investment, high potential returns
|
||||
- Bet on AI growth trajectory
|
||||
|
||||
### Geographic Considerations
|
||||
|
||||
**Latency-Sensitive Workloads**:
|
||||
- Closer to major population centers = potential pricing premium
|
||||
- Edge computing use cases value low latency
|
||||
- Consider location when pricing
|
||||
|
||||
**Energy Costs**:
|
||||
- High electricity costs reduce profitability
|
||||
- Consider renewable energy for cost savings
|
||||
- Factor into pricing strategy
|
||||
|
||||
---
|
||||
|
||||
## Worked Example: Fulfilling Bids
|
||||
|
||||
### Scenario: You Have a Large TFGrid Node
|
||||
|
||||
**Your Node Specs**:
|
||||
- 36 CPU cores, 20,000 Passmark
|
||||
- 512 GB RAM
|
||||
- 4,000 GB SSD
|
||||
- Max 100 slices, typically provides 20
|
||||
|
||||
**Bid Fulfillment Strategy**:
|
||||
|
||||
**Option A: All Memory-Heavy**
|
||||
- Leverage your 512 GB RAM advantage
|
||||
- Provide 20 memory-heavy slices at 8 GB each = 160 GB used
|
||||
- Income: 20 × 2.4 CC = 48 CC/month minimum
|
||||
- Premium positioning due to high RAM
|
||||
|
||||
**Option B: Mixed Strategy**
|
||||
- 10 memory-heavy slices: 10 × 2.4 = 24 CC
|
||||
- 10 standard compute slices: 10 × 1.2 = 12 CC
|
||||
- Total: 36 CC/month minimum
|
||||
- More flexibility, broader market
|
||||
|
||||
**Option C: Target Higher Pricing**
|
||||
- Compete in marketplace when available
|
||||
- Offer custom pricing for longer reservations
|
||||
- Potential: 40-100 CC/month with market pricing
|
||||
|
||||
**Recommendation**: Option A or C - leverage your high RAM to target premium memory-heavy demand.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### For New Farmers
|
||||
|
||||
1. **Review [Node Specifications](/node-economics/node-specifications)** - Choose hardware
|
||||
2. **Identify bid packages you can fulfill** - Match specs to bids
|
||||
3. **Calculate ROI with [Pricing Model](/node-economics/pricing-model)** - Ensure profitability
|
||||
4. **Acquire hardware and configure node** - Get started
|
||||
|
||||
### For Existing Farmers
|
||||
|
||||
1. **Evaluate which bids you currently fulfill** - Optimize allocation
|
||||
2. **Consider upgrades** - Add RAM for memory-heavy bids, or GPU for AI bids
|
||||
3. **Plan for certification** - Q4 2025 certified nodes coming
|
||||
4. **Set competitive pricing** - When marketplace allows
|
||||
|
||||
---
|
||||
|
||||
:::tip Community Resources
|
||||
- **[ThreeFold Forum](https://forum.threefold.io)** - Discuss strategies with other farmers
|
||||
- **[Telegram](https://t.me/threefoldfarmers)** - Real-time community support
|
||||
- **[Community Calls](https://bit.ly/tfcommunitycall)** - Weekly updates and Q&A
|
||||
|
||||
Share your experiences and learn from others building the decentralized cloud!
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Important Notes
|
||||
|
||||
**(*) Revenue Distribution**: All pricing listed is gross revenue. Farmers receive 80%, with 10% burned and 10% to ThreeFold operations.
|
||||
|
||||
**CC Acquisition**: Cloud Credits can be purchased at fiat equivalent of 1/1000 gram of gold ≈ $0.128 USD (Oct 8, 2024 pricing) or by converting 2 TFT per 1 CC.
|
||||
|
||||
**Pricing Flexibility**: Bids represent minimum commitments at stated prices. Marketplace implementation will allow farmers to set custom pricing for competitive differentiation.
|
||||
|
||||
**Duration Matters**: The pricing reflects monthly rates, but can vary significantly based on minimum reservation duration (hour, day, week, month, year).
|
||||
8
docs/ops/_category_.json
Normal file
8
docs/ops/_category_.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"label": "Operations",
|
||||
"position": 4,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"description": "Technical documentation for deployment, development, and content management."
|
||||
}
|
||||
}
|
||||
586
docs/ops/content-updates.md
Normal file
586
docs/ops/content-updates.md
Normal file
@@ -0,0 +1,586 @@
|
||||
---
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
||||
# Content Updates
|
||||
|
||||
This guide covers how to update content, add new documentation, and manage the site structure.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| Task | Action |
|
||||
|------|--------|
|
||||
| Edit existing page | Modify `.md` file in `docs/` |
|
||||
| Add new page | Create new `.md` file with frontmatter |
|
||||
| Add image | Place in `static/img/`, reference with `` |
|
||||
| Update navigation | Edit `sidebars.js` or frontmatter |
|
||||
| Deploy changes | Push to `main` branch |
|
||||
|
||||
---
|
||||
|
||||
## Editing Existing Pages
|
||||
|
||||
### 1. Locate the File
|
||||
|
||||
All documentation lives in `docs/`:
|
||||
|
||||
```
|
||||
docs/
|
||||
├── intro.md # Homepage content
|
||||
├── core-concepts/
|
||||
│ ├── token-system.md
|
||||
│ ├── position-based-lp.md
|
||||
│ ├── dutch-auction-exit.md
|
||||
│ └── yin-yang-currency.md
|
||||
└── ops/
|
||||
├── deployment.md
|
||||
├── local-development.md
|
||||
└── content-updates.md # This file
|
||||
```
|
||||
|
||||
### 2. Make Your Changes
|
||||
|
||||
Open the file in your text editor and modify the markdown:
|
||||
|
||||
```markdown
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Page Title
|
||||
|
||||
Your content here in **Markdown** format.
|
||||
|
||||
- Bullet points
|
||||
- More bullets
|
||||
|
||||
## Subheading
|
||||
|
||||
More content...
|
||||
```
|
||||
|
||||
### 3. Preview Changes
|
||||
|
||||
If running dev server (`npm start`), changes appear immediately in your browser.
|
||||
|
||||
### 4. Deploy
|
||||
|
||||
```bash
|
||||
git add docs/intro.md
|
||||
git commit -m "Update introduction page"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
GitHub Actions automatically builds and deploys in ~3 minutes.
|
||||
|
||||
---
|
||||
|
||||
## Adding New Pages
|
||||
|
||||
### Create the File
|
||||
|
||||
```bash
|
||||
# Add to core concepts
|
||||
touch docs/core-concepts/new-topic.md
|
||||
|
||||
# Or to node economics
|
||||
touch docs/node-economics/new-resource.md
|
||||
```
|
||||
|
||||
### Add Frontmatter
|
||||
|
||||
Every page needs frontmatter at the top:
|
||||
|
||||
```markdown
|
||||
---
|
||||
sidebar_position: 5
|
||||
title: Custom Page Title (optional)
|
||||
---
|
||||
|
||||
# New Topic
|
||||
|
||||
Your content here...
|
||||
```
|
||||
|
||||
### Sidebar Position
|
||||
|
||||
- Lower numbers appear first (1, 2, 3...)
|
||||
- Pages without position appear after numbered pages
|
||||
- Categories have their own positions
|
||||
|
||||
### The Page Appears Automatically!
|
||||
|
||||
Docusaurus automatically adds the page to the sidebar based on:
|
||||
1. The folder it's in
|
||||
2. The `sidebar_position` value
|
||||
3. The first heading (`#`) as the title
|
||||
|
||||
---
|
||||
|
||||
## Working with Images
|
||||
|
||||
### Adding Images
|
||||
|
||||
1. **Place image in static folder:**
|
||||
```bash
|
||||
cp ~/Downloads/diagram.png static/img/
|
||||
```
|
||||
|
||||
2. **Reference in markdown:**
|
||||
```markdown
|
||||
|
||||
```
|
||||
|
||||
### Image Best Practices
|
||||
|
||||
✅ **Do**:
|
||||
- Use descriptive filenames: `token-flow-diagram.png`
|
||||
- Add alt text: ``
|
||||
- Optimize images (compress before adding)
|
||||
- Use PNG for diagrams, JPG for photos
|
||||
|
||||
❌ **Don't**:
|
||||
- Use absolute paths: `` ❌
|
||||
- Skip alt text: `` ❌
|
||||
- Use huge unoptimized images (slow loading)
|
||||
|
||||
### Image Locations
|
||||
|
||||
```
|
||||
static/img/
|
||||
├── logo.png # Site logo
|
||||
├── margin_distribution.png # Dutch auction images
|
||||
└── margin_distribution_1.png
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Organizing Content
|
||||
|
||||
### Category Structure
|
||||
|
||||
Each folder can have a `_category_.json` file:
|
||||
|
||||
```json
|
||||
{
|
||||
"label": "Core Concepts",
|
||||
"position": 2,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"description": "Overview description here."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Moving Pages
|
||||
|
||||
To move a page to a different section:
|
||||
|
||||
1. Move the file:
|
||||
```bash
|
||||
mv docs/core-concepts/old.md docs/appendix/old.md
|
||||
```
|
||||
|
||||
2. Update any links to it in other pages
|
||||
|
||||
3. Test build: `npm run build`
|
||||
|
||||
---
|
||||
|
||||
## Markdown Features
|
||||
|
||||
### Basic Syntax
|
||||
|
||||
```markdown
|
||||
# Heading 1
|
||||
## Heading 2
|
||||
### Heading 3
|
||||
|
||||
**Bold text**
|
||||
*Italic text*
|
||||
|
||||
[Link text](./other-page.md)
|
||||
[External link](https://example.com)
|
||||
|
||||
- Bullet list
|
||||
- More bullets
|
||||
|
||||
1. Numbered list
|
||||
2. More numbers
|
||||
```
|
||||
|
||||
### Tables
|
||||
|
||||
```markdown
|
||||
| Column 1 | Column 2 | Column 3 |
|
||||
|----------|----------|----------|
|
||||
| Data | Data | Data |
|
||||
| Data | Data | Data |
|
||||
```
|
||||
|
||||
### Code Blocks
|
||||
|
||||
````markdown
|
||||
```javascript
|
||||
const example = "code block with syntax highlighting";
|
||||
```
|
||||
|
||||
```bash
|
||||
npm install
|
||||
npm start
|
||||
```
|
||||
````
|
||||
|
||||
### Admonitions
|
||||
|
||||
```markdown
|
||||
:::note
|
||||
This is a note
|
||||
:::
|
||||
|
||||
:::tip
|
||||
This is a tip
|
||||
:::
|
||||
|
||||
:::info
|
||||
This is info
|
||||
:::
|
||||
|
||||
:::warning
|
||||
This is a warning
|
||||
:::
|
||||
|
||||
:::danger
|
||||
This is danger
|
||||
:::
|
||||
```
|
||||
|
||||
### Custom Styles
|
||||
|
||||
The site includes custom CSS classes:
|
||||
|
||||
```markdown
|
||||
<div className="feedback-box">
|
||||
|
||||
### Special Feedback Section
|
||||
|
||||
With custom styling!
|
||||
|
||||
</div>
|
||||
|
||||
<div className="open-questions">
|
||||
|
||||
### Open Questions
|
||||
|
||||
Highlighted questions section
|
||||
|
||||
</div>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Link Management
|
||||
|
||||
### Internal Links
|
||||
|
||||
**Between pages in same folder:**
|
||||
```markdown
|
||||
[See Token System](./token-system.md)
|
||||
```
|
||||
|
||||
**To different folder:**
|
||||
```markdown
|
||||
[See Deployment Guide](../ops/deployment.md)
|
||||
```
|
||||
|
||||
**Using path from root:**
|
||||
```markdown
|
||||
[See Deployment Guide](/ops/deployment)
|
||||
```
|
||||
|
||||
### External Links
|
||||
|
||||
```markdown
|
||||
[ThreeFold](https://threefold.io)
|
||||
[Forum](https://forum.threefold.io)
|
||||
```
|
||||
|
||||
External links automatically open in new tabs.
|
||||
|
||||
### Link Checking
|
||||
|
||||
Build process checks for broken links:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
Look for warnings about broken links in output.
|
||||
|
||||
---
|
||||
|
||||
## Common Content Tasks
|
||||
|
||||
### Update Open Questions (Intro Page)
|
||||
|
||||
Edit `docs/intro.md`, find the open questions section:
|
||||
|
||||
```markdown
|
||||
<div className="open-questions">
|
||||
|
||||
### Key Areas We're Seeking Feedback On:
|
||||
|
||||
- **Entry Price**: Should the fixed TFT to CC conversion rate be...
|
||||
- **New Question**: Add your new question here
|
||||
|
||||
</div>
|
||||
```
|
||||
|
||||
### Update Community Links
|
||||
|
||||
Edit `docusaurus.config.js`:
|
||||
|
||||
```javascript
|
||||
{
|
||||
href: 'https://t.me/threefoldfarmers',
|
||||
label: 'Telegram',
|
||||
position: 'right',
|
||||
}
|
||||
```
|
||||
|
||||
### Add to Footer
|
||||
|
||||
Edit `docusaurus.config.js` footer section:
|
||||
|
||||
```javascript
|
||||
footer: {
|
||||
links: [
|
||||
{
|
||||
title: 'New Section',
|
||||
items: [
|
||||
{
|
||||
label: 'New Link',
|
||||
href: 'https://example.com',
|
||||
},
|
||||
],
|
||||
},
|
||||
],
|
||||
}
|
||||
```
|
||||
|
||||
### Update Announcement Bar
|
||||
|
||||
Edit `docusaurus.config.js`:
|
||||
|
||||
```javascript
|
||||
announcementBar: {
|
||||
id: 'new_announcement',
|
||||
content: 'Your new announcement here!',
|
||||
backgroundColor: '#20232a',
|
||||
textColor: '#fff',
|
||||
isCloseable: true,
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Content Workflow
|
||||
|
||||
### Standard Update Process
|
||||
|
||||
1. **Create a branch (optional but recommended):**
|
||||
```bash
|
||||
git checkout -b update-intro-page
|
||||
```
|
||||
|
||||
2. **Make changes:**
|
||||
- Edit markdown files
|
||||
- Add/update images
|
||||
- Test locally: `npm start`
|
||||
|
||||
3. **Test build:**
|
||||
```bash
|
||||
npm run build
|
||||
npm run serve
|
||||
```
|
||||
|
||||
4. **Commit changes:**
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Update intro page with new questions"
|
||||
```
|
||||
|
||||
5. **Push to GitHub:**
|
||||
```bash
|
||||
git push origin update-intro-page
|
||||
# Or if working directly on main:
|
||||
git push origin main
|
||||
```
|
||||
|
||||
6. **Create Pull Request (if using branches):**
|
||||
- Go to GitHub repository
|
||||
- Click "Pull Requests" → "New Pull Request"
|
||||
- Review changes, merge to main
|
||||
|
||||
7. **Automatic deployment:**
|
||||
- GitHub Actions builds and deploys
|
||||
- Monitor in Actions tab
|
||||
- Live in ~3 minutes
|
||||
|
||||
---
|
||||
|
||||
## Multiple Contributors
|
||||
|
||||
### Collaborative Workflow
|
||||
|
||||
**Before starting work:**
|
||||
```bash
|
||||
git pull origin main
|
||||
```
|
||||
|
||||
**After your changes:**
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Clear description of changes"
|
||||
git pull origin main # Get any new changes
|
||||
git push origin main
|
||||
```
|
||||
|
||||
### Handling Conflicts
|
||||
|
||||
If you get a merge conflict:
|
||||
|
||||
```bash
|
||||
# Open the conflicted file
|
||||
# Look for conflict markers:
|
||||
<<<<<<< HEAD
|
||||
Your changes
|
||||
=======
|
||||
Their changes
|
||||
>>>>>>> main
|
||||
|
||||
# Resolve by choosing one or combining both
|
||||
# Then:
|
||||
git add resolved-file.md
|
||||
git commit -m "Resolve merge conflict"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Content Guidelines
|
||||
|
||||
### Writing Style
|
||||
|
||||
✅ **Do**:
|
||||
- Write clear, concise sentences
|
||||
- Use active voice
|
||||
- Break up long paragraphs
|
||||
- Add examples where helpful
|
||||
- Use headings to organize
|
||||
|
||||
❌ **Avoid**:
|
||||
- Jargon without explanation
|
||||
- Very long paragraphs
|
||||
- Walls of text
|
||||
- Broken links
|
||||
|
||||
### Formatting Consistency
|
||||
|
||||
- Use `**bold**` for emphasis
|
||||
- Use `*italic*` for terminology
|
||||
- Use `` `code` `` for commands, filenames, code
|
||||
- Use proper heading hierarchy (H1 → H2 → H3)
|
||||
|
||||
### Accessibility
|
||||
|
||||
- Add alt text to all images
|
||||
- Use descriptive link text (not "click here")
|
||||
- Maintain proper heading structure
|
||||
- Ensure good color contrast
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Build Fails After Edit
|
||||
|
||||
**Check for:**
|
||||
- Broken markdown syntax
|
||||
- Invalid frontmatter
|
||||
- Broken links: `[text](./wrong-file.md)`
|
||||
- Unclosed code blocks
|
||||
- Special characters in YAML frontmatter
|
||||
|
||||
**Test locally:**
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
Error messages show the problem file and line number.
|
||||
|
||||
### Changes Don't Appear Live
|
||||
|
||||
**Possible causes:**
|
||||
1. **Build failed** - Check GitHub Actions tab
|
||||
2. **Cache issue** - Hard refresh browser: Ctrl+Shift+R
|
||||
3. **Deployment lag** - Wait 3-5 minutes after push
|
||||
|
||||
### Images Not Loading
|
||||
|
||||
**Check:**
|
||||
- Image is in `static/img/`
|
||||
- Path is correct: ``
|
||||
- Image filename matches exactly (case-sensitive)
|
||||
- Image was committed: `git add static/img/name.png`
|
||||
|
||||
---
|
||||
|
||||
## Advanced Topics
|
||||
|
||||
### Custom React Components
|
||||
|
||||
Place in `src/components/`:
|
||||
|
||||
```jsx
|
||||
// src/components/CustomCard.js
|
||||
export default function CustomCard({title, children}) {
|
||||
return (
|
||||
<div className="custom-card">
|
||||
<h3>{title}</h3>
|
||||
{children}
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
Use in markdown:
|
||||
|
||||
```markdown
|
||||
import CustomCard from '@site/src/components/CustomCard';
|
||||
|
||||
<CustomCard title="My Card">
|
||||
Content here
|
||||
</CustomCard>
|
||||
```
|
||||
|
||||
### Custom Styling
|
||||
|
||||
Edit `src/css/custom.css` to add global styles.
|
||||
|
||||
### Versioning (Future)
|
||||
|
||||
When ready to version docs:
|
||||
|
||||
```bash
|
||||
npm run docusaurus docs:version 1.0
|
||||
```
|
||||
|
||||
This creates a snapshot of current docs as version 1.0.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- [Deployment Guide](./deployment.md) - Deploy changes to production
|
||||
- [Local Development](./local-development.md) - Set up your dev environment
|
||||
298
docs/ops/deployment.md
Normal file
298
docs/ops/deployment.md
Normal file
@@ -0,0 +1,298 @@
|
||||
---
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Deployment to plan.threefold.pro
|
||||
|
||||
This guide covers how to deploy the TFT Minting Transition Plan site to the custom domain `plan.threefold.pro` using GitHub Pages.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- GitHub repository: `https://github.com/mik-tf/minting_plan`
|
||||
- Access to DNS provider for `threefold.pro` domain
|
||||
- GitHub Pages enabled on the repository
|
||||
- Node.js 18+ installed locally (for testing before deployment)
|
||||
|
||||
---
|
||||
|
||||
## DNS Configuration
|
||||
|
||||
Configure your DNS settings at your domain provider to point `plan.threefold.pro` to GitHub Pages.
|
||||
|
||||
### Option 1: CNAME Record (Recommended)
|
||||
|
||||
Add the following DNS record:
|
||||
|
||||
```
|
||||
Type: CNAME
|
||||
Name: plan
|
||||
Value: mik-tf.github.io
|
||||
TTL: 3600 (or your provider's default)
|
||||
```
|
||||
|
||||
### Option 2: A Records (Alternative)
|
||||
|
||||
If your DNS provider doesn't support CNAME for subdomains, use A records:
|
||||
|
||||
```
|
||||
Type: A
|
||||
Name: plan
|
||||
Value: 185.199.108.153
|
||||
TTL: 3600
|
||||
|
||||
Type: A
|
||||
Name: plan
|
||||
Value: 185.199.109.153
|
||||
TTL: 3600
|
||||
|
||||
Type: A
|
||||
Name: plan
|
||||
Value: 185.199.110.153
|
||||
TTL: 3600
|
||||
|
||||
Type: A
|
||||
Name: plan
|
||||
Value: 185.199.111.153
|
||||
TTL: 3600
|
||||
```
|
||||
|
||||
:::tip DNS Propagation
|
||||
DNS changes can take anywhere from 5 minutes to 48 hours to propagate globally. Typically it's 15-30 minutes.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## GitHub Repository Settings
|
||||
|
||||
### 1. Enable GitHub Pages
|
||||
|
||||
1. Go to your repository: `https://github.com/mik-tf/minting_plan`
|
||||
2. Click **Settings** → **Pages** (left sidebar)
|
||||
3. Under "Source", select:
|
||||
- **Branch**: `gh-pages`
|
||||
- **Folder**: `/ (root)`
|
||||
4. Click **Save**
|
||||
|
||||
### 2. Configure Custom Domain
|
||||
|
||||
1. Still in the Pages settings
|
||||
2. Under "Custom domain", enter: `plan.threefold.pro`
|
||||
3. Click **Save**
|
||||
4. Wait for DNS check (green checkmark ✓ will appear)
|
||||
5. Once verified, check **Enforce HTTPS** (automatic SSL certificate)
|
||||
|
||||
:::warning Important
|
||||
The CNAME file in the `static/` folder ensures the custom domain persists after each deployment. Don't delete it!
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## GitHub Actions Workflow
|
||||
|
||||
The repository includes an automated deployment workflow at `.github/workflows/deploy.yml`. This workflow:
|
||||
|
||||
- Triggers automatically on push to `main` branch
|
||||
- Installs dependencies
|
||||
- Builds the Docusaurus site
|
||||
- Deploys to `gh-pages` branch
|
||||
|
||||
### How It Works
|
||||
|
||||
```yaml
|
||||
name: Deploy to GitHub Pages
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- main
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 18
|
||||
cache: npm
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
- name: Build website
|
||||
run: npm run build
|
||||
- name: Deploy to GitHub Pages
|
||||
uses: peaceiris/actions-gh-pages@v3
|
||||
with:
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
publish_dir: ./build
|
||||
```
|
||||
|
||||
### Manual Deployment (if needed)
|
||||
|
||||
If you need to deploy manually:
|
||||
|
||||
```bash
|
||||
# Build the site
|
||||
npm run build
|
||||
|
||||
# Deploy to GitHub Pages
|
||||
npm run deploy
|
||||
```
|
||||
|
||||
:::info Automatic Deployment
|
||||
With GitHub Actions, you don't need to manually deploy. Just push to `main` and the site updates automatically in 2-3 minutes.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Verification Steps
|
||||
|
||||
After deployment, verify everything works:
|
||||
|
||||
### 1. Check GitHub Actions
|
||||
|
||||
1. Go to repository → **Actions** tab
|
||||
2. Verify the latest workflow run succeeded (green checkmark)
|
||||
3. If failed, click to see error logs
|
||||
|
||||
### 2. Check GitHub Pages Status
|
||||
|
||||
1. Go to repository → **Settings** → **Pages**
|
||||
2. You should see: "Your site is live at https://plan.threefold.pro"
|
||||
3. Green checkmark next to custom domain
|
||||
|
||||
### 3. Test the Website
|
||||
|
||||
Visit these URLs and verify they work:
|
||||
|
||||
- https://plan.threefold.pro (homepage/intro)
|
||||
- https://plan.threefold.pro/core-concepts/token-system
|
||||
- https://plan.threefold.pro/ops/deployment (this page!)
|
||||
|
||||
### 4. Verify SSL Certificate
|
||||
|
||||
- Ensure the site loads with `https://` (not `http://`)
|
||||
- Check browser shows padlock icon (secure connection)
|
||||
- Certificate should be issued by GitHub
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### DNS Not Resolving
|
||||
|
||||
**Symptoms**: Site doesn't load, "DNS_PROBE_FINISHED_NXDOMAIN" error
|
||||
|
||||
**Solutions**:
|
||||
1. Wait longer for DNS propagation (up to 48 hours)
|
||||
2. Check DNS records are correct using:
|
||||
```bash
|
||||
dig plan.threefold.pro
|
||||
```
|
||||
3. Try accessing from different network/device (might be local DNS cache)
|
||||
4. Flush your local DNS cache:
|
||||
```bash
|
||||
# Linux
|
||||
sudo systemd-resolve --flush-caches
|
||||
|
||||
# macOS
|
||||
sudo dscacheutil -flushcache
|
||||
```
|
||||
|
||||
### 404 Errors
|
||||
|
||||
**Symptoms**: Homepage loads but inner pages show 404
|
||||
|
||||
**Solutions**:
|
||||
1. Verify `trailingSlash: false` in `docusaurus.config.js`
|
||||
2. Check GitHub Pages is deploying from `gh-pages` branch root
|
||||
3. Wait a few minutes after deployment completes
|
||||
|
||||
### Build Failures
|
||||
|
||||
**Symptoms**: GitHub Actions workflow fails
|
||||
|
||||
**Solutions**:
|
||||
1. Check Actions tab for error logs
|
||||
2. Verify `package.json` has correct dependencies
|
||||
3. Test build locally: `npm run build`
|
||||
4. Check for broken links in markdown files
|
||||
|
||||
### Custom Domain Not Persisting
|
||||
|
||||
**Symptoms**: Custom domain resets after deployment
|
||||
|
||||
**Solutions**:
|
||||
1. Ensure `static/CNAME` file exists with content: `plan.threefold.pro`
|
||||
2. The CNAME file should be committed to git
|
||||
3. After build, verify `build/CNAME` exists
|
||||
|
||||
---
|
||||
|
||||
## Deployment Timeline
|
||||
|
||||
Understanding what happens when you push changes:
|
||||
|
||||
| Time | Event |
|
||||
|------|-------|
|
||||
| T+0s | Push commit to `main` branch |
|
||||
| T+10s | GitHub Actions workflow starts |
|
||||
| T+2min | Build completes, deploys to `gh-pages` branch |
|
||||
| T+3min | GitHub Pages processes update |
|
||||
| T+5min | Site live at plan.threefold.pro |
|
||||
|
||||
:::tip Quick Updates
|
||||
For urgent fixes, monitor the Actions tab to see when deployment completes, then verify changes immediately.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Security Considerations
|
||||
|
||||
### HTTPS/SSL
|
||||
- GitHub Pages provides automatic SSL via Let's Encrypt
|
||||
- Certificate renews automatically
|
||||
- Always enforce HTTPS in settings
|
||||
|
||||
### Branch Protection
|
||||
Consider protecting the `main` branch:
|
||||
1. Settings → Branches → Add rule
|
||||
2. Require pull request reviews
|
||||
3. Require status checks to pass
|
||||
|
||||
### Access Control
|
||||
- Only repository collaborators can push to `main`
|
||||
- Manage access in Settings → Collaborators
|
||||
|
||||
---
|
||||
|
||||
## Maintenance
|
||||
|
||||
### Regular Updates
|
||||
|
||||
Keep Docusaurus and dependencies updated:
|
||||
|
||||
```bash
|
||||
# Check for updates
|
||||
npm outdated
|
||||
|
||||
# Update dependencies
|
||||
npm update
|
||||
|
||||
# Update Docusaurus to latest
|
||||
npm install @docusaurus/core@latest @docusaurus/preset-classic@latest
|
||||
```
|
||||
|
||||
### Monitoring
|
||||
|
||||
Monitor these regularly:
|
||||
- GitHub Actions workflow status
|
||||
- Site accessibility at plan.threefold.pro
|
||||
- SSL certificate validity (automatic but good to check)
|
||||
- Build times (should stay under 3 minutes)
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- [Local Development](./local-development.md) - Test changes before deploying
|
||||
- [Content Updates](./content-updates.md) - How to edit and add content
|
||||
391
docs/ops/local-development.md
Normal file
391
docs/ops/local-development.md
Normal file
@@ -0,0 +1,391 @@
|
||||
---
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
# Local Development
|
||||
|
||||
This guide covers how to set up and run the TFT Minting Transition Plan site locally for development and testing.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Required Software
|
||||
|
||||
- **Node.js**: Version 18.0 or higher
|
||||
- **npm**: Comes with Node.js
|
||||
- **Git**: For version control
|
||||
|
||||
### Check Your Versions
|
||||
|
||||
```bash
|
||||
node --version # Should be v18.0.0 or higher
|
||||
npm --version # Should be 8.0.0 or higher
|
||||
git --version # Any recent version
|
||||
```
|
||||
|
||||
### Installing Node.js
|
||||
|
||||
If you don't have Node.js 18+:
|
||||
|
||||
**Linux (Ubuntu/Debian)**:
|
||||
```bash
|
||||
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
|
||||
sudo apt-get install -y nodejs
|
||||
```
|
||||
|
||||
**macOS**:
|
||||
```bash
|
||||
brew install node@18
|
||||
```
|
||||
|
||||
**Using nvm (recommended)**:
|
||||
```bash
|
||||
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
|
||||
nvm install 18
|
||||
nvm use 18
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Initial Setup
|
||||
|
||||
### 1. Clone the Repository
|
||||
|
||||
```bash
|
||||
git clone https://github.com/mik-tf/minting_plan.git
|
||||
cd minting_plan
|
||||
```
|
||||
|
||||
### 2. Install Dependencies
|
||||
|
||||
```bash
|
||||
npm install
|
||||
```
|
||||
|
||||
This will install all required packages listed in `package.json`, including:
|
||||
- Docusaurus core
|
||||
- React
|
||||
- MDX support
|
||||
- Theme packages
|
||||
|
||||
:::info First Install
|
||||
The first `npm install` will take 1-2 minutes as it downloads all dependencies. Subsequent installs will be faster thanks to npm cache.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Development Server
|
||||
|
||||
### Start the Dev Server
|
||||
|
||||
```bash
|
||||
npm start
|
||||
```
|
||||
|
||||
This command:
|
||||
- Starts a local development server
|
||||
- Opens your browser to `http://localhost:3000`
|
||||
- Enables hot reloading (changes appear immediately)
|
||||
- Shows build errors in the terminal and browser
|
||||
|
||||
### What You'll See
|
||||
|
||||
```
|
||||
[INFO] Starting the development server...
|
||||
[SUCCESS] Docusaurus website is running at: http://localhost:3000/
|
||||
```
|
||||
|
||||
:::tip Hot Reloading
|
||||
Edit any markdown file and save - your browser will automatically refresh with changes. No need to restart the server!
|
||||
:::
|
||||
|
||||
### Stop the Server
|
||||
|
||||
Press `Ctrl+C` in the terminal where the server is running.
|
||||
|
||||
---
|
||||
|
||||
## Building for Production
|
||||
|
||||
### Create Production Build
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
This command:
|
||||
- Creates optimized production files in `build/` directory
|
||||
- Minifies JavaScript and CSS
|
||||
- Generates static HTML for all pages
|
||||
- Checks for broken links
|
||||
|
||||
### Preview Production Build
|
||||
|
||||
```bash
|
||||
npm run serve
|
||||
```
|
||||
|
||||
This serves the production build locally at `http://localhost:3000` so you can test it before deployment.
|
||||
|
||||
:::warning Test Before Push
|
||||
Always run `npm run build` before pushing to ensure there are no build errors. The production build is stricter than dev mode.
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## Common Development Tasks
|
||||
|
||||
### Adding a New Page
|
||||
|
||||
1. Create a new `.md` file in the appropriate docs folder:
|
||||
```bash
|
||||
touch docs/core-concepts/new-concept.md
|
||||
```
|
||||
|
||||
2. Add frontmatter:
|
||||
```markdown
|
||||
---
|
||||
sidebar_position: 5
|
||||
---
|
||||
|
||||
# New Concept Title
|
||||
|
||||
Your content here...
|
||||
```
|
||||
|
||||
3. The page appears automatically in the sidebar!
|
||||
|
||||
### Editing Existing Content
|
||||
|
||||
1. Navigate to the file (e.g., `docs/intro.md`)
|
||||
2. Make your changes
|
||||
3. Save the file
|
||||
4. Browser auto-refreshes with changes
|
||||
|
||||
### Adding Images
|
||||
|
||||
1. Place images in `static/img/`:
|
||||
```bash
|
||||
cp ~/my-image.png static/img/
|
||||
```
|
||||
|
||||
2. Reference in markdown:
|
||||
```markdown
|
||||
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
minting_plan/
|
||||
├── docs/ # All documentation content
|
||||
│ ├── intro.md # Homepage
|
||||
│ ├── core-concepts/ # Core concept docs
|
||||
│ ├── appendix/ # Meeting notes, etc.
|
||||
│ └── ops/ # Operations guides
|
||||
├── static/ # Static assets
|
||||
│ ├── img/ # Images
|
||||
│ └── CNAME # Custom domain file
|
||||
├── src/ # Custom React components
|
||||
│ ├── css/ # Custom styles
|
||||
│ └── pages/ # Custom pages (optional)
|
||||
├── docusaurus.config.js # Site configuration
|
||||
├── sidebars.js # Sidebar structure
|
||||
├── package.json # Dependencies
|
||||
└── .github/workflows/ # GitHub Actions
|
||||
└── deploy.yml # Auto-deployment
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Useful Commands
|
||||
|
||||
### Clear Cache
|
||||
|
||||
If you see weird behavior, clear the cache:
|
||||
|
||||
```bash
|
||||
npm run clear
|
||||
```
|
||||
|
||||
### Check for Build Issues
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
Look for:
|
||||
- ✅ Success: Build completed
|
||||
- ❌ Errors: Broken links, invalid markdown, missing files
|
||||
|
||||
### Format Code (if using Prettier)
|
||||
|
||||
```bash
|
||||
npx prettier --write "docs/**/*.md"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### Typical Workflow
|
||||
|
||||
1. **Pull latest changes**
|
||||
```bash
|
||||
git pull origin main
|
||||
```
|
||||
|
||||
2. **Start dev server**
|
||||
```bash
|
||||
npm start
|
||||
```
|
||||
|
||||
3. **Make changes**
|
||||
- Edit markdown files in `docs/`
|
||||
- See changes instantly in browser
|
||||
|
||||
4. **Test production build**
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
5. **Commit and push**
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Description of changes"
|
||||
git push origin main
|
||||
```
|
||||
|
||||
6. **Auto-deployment**
|
||||
- GitHub Actions builds and deploys automatically
|
||||
- Check Actions tab for status
|
||||
- Site updates at plan.threefold.pro in ~3 minutes
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Port 3000 Already in Use
|
||||
|
||||
**Error**: `Something is already running on port 3000`
|
||||
|
||||
**Solution**:
|
||||
```bash
|
||||
# Find and kill the process
|
||||
lsof -i :3000
|
||||
kill -9 <PID>
|
||||
|
||||
# Or use a different port
|
||||
npm start -- --port 3001
|
||||
```
|
||||
|
||||
### Module Not Found Errors
|
||||
|
||||
**Error**: `Cannot find module '@docusaurus/...'`
|
||||
|
||||
**Solution**:
|
||||
```bash
|
||||
# Delete node_modules and reinstall
|
||||
rm -rf node_modules package-lock.json
|
||||
npm install
|
||||
```
|
||||
|
||||
### Build Fails Locally
|
||||
|
||||
**Error**: Build fails with various errors
|
||||
|
||||
**Solution**:
|
||||
```bash
|
||||
# Clear cache and rebuild
|
||||
npm run clear
|
||||
npm run build
|
||||
```
|
||||
|
||||
### Changes Not Appearing
|
||||
|
||||
**Problem**: Saved changes don't show in browser
|
||||
|
||||
**Solution**:
|
||||
1. Check the terminal for build errors
|
||||
2. Hard refresh browser: `Ctrl+Shift+R` (Linux/Win) or `Cmd+Shift+R` (Mac)
|
||||
3. Restart dev server: `Ctrl+C`, then `npm start`
|
||||
|
||||
### Node Version Issues
|
||||
|
||||
**Error**: `The engine "node" is incompatible with this module`
|
||||
|
||||
**Solution**:
|
||||
```bash
|
||||
# Check your version
|
||||
node --version
|
||||
|
||||
# Install correct version using nvm
|
||||
nvm install 18
|
||||
nvm use 18
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Before Committing
|
||||
|
||||
✅ **Do**:
|
||||
- Test build locally: `npm run build`
|
||||
- Check for broken links in build output
|
||||
- Preview with `npm run serve`
|
||||
- Write clear commit messages
|
||||
|
||||
❌ **Don't**:
|
||||
- Commit `node_modules/` (it's in .gitignore)
|
||||
- Commit `build/` directory (it's generated)
|
||||
- Push without testing build
|
||||
- Use absolute URLs for internal links
|
||||
|
||||
### Writing Documentation
|
||||
|
||||
✅ **Good practices**:
|
||||
- Use relative links: `[link](./other-page.md)`
|
||||
- Add alt text to images: ``
|
||||
- Use frontmatter for sidebar position
|
||||
- Keep markdown files in appropriate folders
|
||||
|
||||
❌ **Avoid**:
|
||||
- Absolute URLs for internal pages
|
||||
- Missing alt text on images
|
||||
- Inconsistent heading levels
|
||||
- Very long lines (wrap at ~100 chars)
|
||||
|
||||
---
|
||||
|
||||
## IDE Setup
|
||||
|
||||
### VS Code (Recommended)
|
||||
|
||||
Install these extensions for better experience:
|
||||
|
||||
- **Markdown All in One**: Markdown preview and shortcuts
|
||||
- **Prettier**: Code formatting
|
||||
- **ESLint**: JavaScript linting
|
||||
|
||||
### Settings
|
||||
|
||||
Add to `.vscode/settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"editor.formatOnSave": true,
|
||||
"editor.defaultFormatter": "esbenp.prettier-vscode",
|
||||
"[markdown]": {
|
||||
"editor.wordWrap": "on"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- [Deployment](./deployment.md) - Deploy to plan.threefold.pro
|
||||
- [Content Updates](./content-updates.md) - Learn content management workflows
|
||||
180
docusaurus.config.js
Normal file
180
docusaurus.config.js
Normal file
@@ -0,0 +1,180 @@
|
||||
// @ts-check
|
||||
// `@type` JSDoc annotations allow editor autocompletion and type checking
|
||||
// (when paired with `@ts-check`).
|
||||
// There are various equivalent ways to declare your Docusaurus config.
|
||||
// See: https://docusaurus.io/docs/api/docusaurus-config
|
||||
|
||||
import {themes as prismThemes} from 'prism-react-renderer';
|
||||
|
||||
// Mermaid theme support
|
||||
const mermaidTheme = {
|
||||
theme: {
|
||||
light: 'default',
|
||||
dark: 'dark',
|
||||
},
|
||||
};
|
||||
|
||||
/** @type {import('@docusaurus/types').Config} */
|
||||
const config = {
|
||||
title: 'TFT Minting Transition Plan',
|
||||
tagline: 'Community Feedback & Discussion',
|
||||
favicon: 'img/favicon.png',
|
||||
|
||||
// Set the production url of your site here
|
||||
url: 'https://threefold.info',
|
||||
// Set the /<baseUrl>/ pathname under which your site is served
|
||||
// For GitHub pages deployment, it is often '/<projectName>/'
|
||||
baseUrl: '/economics/',
|
||||
|
||||
// GitHub pages deployment config.
|
||||
// If you aren't using GitHub pages, you don't need these.
|
||||
organizationName: 'tfgrid', // Usually your GitHub org/user name.
|
||||
projectName: 'tfgrid-economics', // Usually your repo name.
|
||||
deploymentBranch: 'gh-pages',
|
||||
trailingSlash: false,
|
||||
|
||||
onBrokenLinks: 'throw',
|
||||
|
||||
// Even if you don't use internationalization, you can use this field to set
|
||||
// useful metadata like html lang. For example, if your site is Chinese, you
|
||||
// may want to replace "en" with "zh-Hans".
|
||||
i18n: {
|
||||
defaultLocale: 'en',
|
||||
locales: ['en'],
|
||||
},
|
||||
|
||||
presets: [
|
||||
[
|
||||
'classic',
|
||||
/** @type {import('@docusaurus/preset-classic').Options} */
|
||||
({
|
||||
docs: {
|
||||
routeBasePath: '/',
|
||||
sidebarPath: './sidebars.js',
|
||||
},
|
||||
blog: false,
|
||||
theme: {
|
||||
customCss: './src/css/custom.css',
|
||||
},
|
||||
}),
|
||||
],
|
||||
],
|
||||
|
||||
themes: ['@docusaurus/theme-mermaid'],
|
||||
|
||||
markdown: {
|
||||
mermaid: true,
|
||||
hooks: {
|
||||
onBrokenMarkdownLinks: 'warn',
|
||||
},
|
||||
},
|
||||
|
||||
themeConfig:
|
||||
/** @type {import('@docusaurus/preset-classic').ThemeConfig} */
|
||||
({
|
||||
// Replace with your project's social card
|
||||
image: 'img/logo.png',
|
||||
navbar: {
|
||||
title: '',
|
||||
logo: {
|
||||
alt: 'TFT Logo',
|
||||
src: 'img/new_logo_tft.png',
|
||||
},
|
||||
items: [
|
||||
{
|
||||
type: 'docSidebar',
|
||||
sidebarId: 'mainSidebar',
|
||||
position: 'left',
|
||||
label: 'Docs',
|
||||
},
|
||||
{
|
||||
href: 'https://t.me/threefoldfarmers',
|
||||
label: 'Telegram',
|
||||
position: 'right',
|
||||
},
|
||||
{
|
||||
href: 'https://forum.threefold.io',
|
||||
label: 'Forum',
|
||||
position: 'right',
|
||||
},
|
||||
],
|
||||
},
|
||||
footer: {
|
||||
style: 'dark',
|
||||
links: [
|
||||
{
|
||||
title: 'Documentation',
|
||||
items: [
|
||||
{
|
||||
label: 'Introduction',
|
||||
to: '/',
|
||||
},
|
||||
{
|
||||
label: 'Implementation & Roadmap',
|
||||
to: '/implementation-roadmap',
|
||||
},
|
||||
{
|
||||
label: 'Core Concepts',
|
||||
to: '/core-concepts',
|
||||
},
|
||||
{
|
||||
label: 'Node Economics',
|
||||
to: '/node-economics',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'Community',
|
||||
items: [
|
||||
{
|
||||
label: 'Telegram Chat',
|
||||
href: 'https://t.me/threefoldfarmers',
|
||||
},
|
||||
{
|
||||
label: 'Forum',
|
||||
href: 'https://forum.threefold.io',
|
||||
},
|
||||
{
|
||||
label: 'Community Call',
|
||||
href: 'https://bit.ly/tfcommunitycall',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'More',
|
||||
items: [
|
||||
{
|
||||
label: 'Forum Discussion',
|
||||
href: 'https://forum.threefold.io/t/tft-minting-transition-plan-community-e-book/4647',
|
||||
},
|
||||
{
|
||||
label: 'ThreeFold Website',
|
||||
href: 'https://threefold.io',
|
||||
}
|
||||
],
|
||||
},
|
||||
],
|
||||
copyright: `Copyright © ${new Date().getFullYear()} ThreeFold.`,
|
||||
},
|
||||
prism: {
|
||||
theme: prismThemes.github,
|
||||
darkTheme: prismThemes.dracula,
|
||||
},
|
||||
mermaid: mermaidTheme,
|
||||
colorMode: {
|
||||
defaultMode: 'dark',
|
||||
disableSwitch: true,
|
||||
respectPrefersColorScheme: false,
|
||||
},
|
||||
announcementBar: {
|
||||
id: 'community_call',
|
||||
content:
|
||||
'📞 <strong>Join the Community Call</strong> to discuss this plan! <a target="_blank" rel="noopener noreferrer" href="https://bit.ly/tfcommunitycall">Join the call</a>',
|
||||
backgroundColor: '#20232a',
|
||||
textColor: '#fff',
|
||||
isCloseable: true,
|
||||
},
|
||||
}),
|
||||
};
|
||||
|
||||
export default config;
|
||||
31
ops/README.md
Normal file
31
ops/README.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Operations Documentation
|
||||
|
||||
**Internal documentation for the ops team - not published to the website.**
|
||||
|
||||
This directory contains operational documentation for deploying and managing the TFGrid Economics site. These files are **not** part of the Docusaurus website content (which lives in `docs/`).
|
||||
|
||||
## Contents
|
||||
|
||||
- **[server-deployment.md](./server-deployment.md)** - Guide for deploying to threefold.info/economics using zinit and Caddy
|
||||
|
||||
## Structure
|
||||
|
||||
```
|
||||
tfgrid-economics/
|
||||
├── docs/ # Public website content (Docusaurus)
|
||||
│ ├── ops/ # Public ops docs (GitHub Pages deployment)
|
||||
│ └── ...
|
||||
├── ops/ # Internal ops documentation (this directory)
|
||||
│ └── server-deployment.md
|
||||
└── ...
|
||||
```
|
||||
|
||||
## Important Notes
|
||||
|
||||
- **Public website docs**: `docs/` - Content that gets published to plan.threefold.pro
|
||||
- **Internal ops docs**: `ops/` - Private operational documentation for the team
|
||||
- Files in this directory should **not** be referenced from the Docusaurus site
|
||||
|
||||
## Repository
|
||||
|
||||
https://git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
421
ops/server-deployment.md
Normal file
421
ops/server-deployment.md
Normal file
@@ -0,0 +1,421 @@
|
||||
# Server Deployment Guide for TFGrid Economics
|
||||
|
||||
Production deployment guide for hosting the TFGrid Economics documentation site at `threefold.info/economics`.
|
||||
|
||||
**Repository**: https://git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
|
||||
## Overview
|
||||
|
||||
- **URL**: https://threefold.info/economics/
|
||||
- **Service Manager**: zinit
|
||||
- **Web Server**: Caddy (reverse proxy)
|
||||
- **Port**: 9997
|
||||
- **Branch**: main
|
||||
|
||||
The repository is pre-configured with `baseUrl: '/economics/'` in `docusaurus.config.js`.
|
||||
|
||||
## Quick Reference
|
||||
|
||||
```bash
|
||||
# Update site
|
||||
cd /root/code/git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
git pull && zinit restart tfgrid-economics
|
||||
|
||||
# View logs
|
||||
zinit log tfgrid-economics
|
||||
|
||||
# Check status
|
||||
zinit list | grep tfgrid-economics
|
||||
ss -tuln | grep 9997
|
||||
```
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Linux server with:
|
||||
- Git installed
|
||||
- Node.js 18+ installed
|
||||
- Caddy web server installed
|
||||
- zinit service manager installed
|
||||
- Root or sudo access
|
||||
- SSH access to the server (e.g., `root@info.ourworld.tf`)
|
||||
|
||||
## Step 1: Clone the Repository
|
||||
|
||||
```bash
|
||||
# Create directory structure
|
||||
mkdir -p /root/code/git.ourworld.tf/tfgrid/
|
||||
cd /root/code/git.ourworld.tf/tfgrid/
|
||||
|
||||
# Clone the repository
|
||||
git clone https://git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
cd tfgrid-economics
|
||||
git checkout main
|
||||
```
|
||||
|
||||
## Step 2: Build the Site
|
||||
|
||||
The repository is already configured with the correct base URL (`/economics/`) in `docusaurus.config.js`.
|
||||
|
||||
Build the static site files:
|
||||
|
||||
```bash
|
||||
# Install dependencies
|
||||
npm install
|
||||
|
||||
# Build the production site
|
||||
npm run build
|
||||
```
|
||||
|
||||
This creates a `build/` directory with static HTML, CSS, and JavaScript files.
|
||||
|
||||
## Step 3: Create a zinit Service
|
||||
|
||||
Create a zinit service to serve the built site:
|
||||
|
||||
### 3.1 Create the Service Script
|
||||
|
||||
```bash
|
||||
mkdir -p /etc/zinit/cmds
|
||||
nano /etc/zinit/cmds/tfgrid-economics.sh
|
||||
```
|
||||
|
||||
Add the following content:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
cd /root/code/git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
|
||||
# Pull latest changes
|
||||
git checkout main
|
||||
git pull
|
||||
|
||||
# Install dependencies and build
|
||||
npm install
|
||||
npm run build
|
||||
|
||||
# Serve the built site using a simple HTTP server
|
||||
# npx serve is a lightweight static server
|
||||
exec npx serve -s build -l 9997
|
||||
```
|
||||
|
||||
Make the script executable:
|
||||
|
||||
```bash
|
||||
chmod +x /etc/zinit/cmds/tfgrid-economics.sh
|
||||
```
|
||||
|
||||
### 3.2 Create the zinit Service Definition
|
||||
|
||||
```bash
|
||||
nano /etc/zinit/tfgrid-economics.yaml
|
||||
```
|
||||
|
||||
Add the following content:
|
||||
|
||||
```yaml
|
||||
exec: "/bin/bash -c /etc/zinit/cmds/tfgrid-economics.sh"
|
||||
```
|
||||
|
||||
## Step 4: Configure Caddy
|
||||
|
||||
Navigate to your Caddy configuration directory:
|
||||
|
||||
```bash
|
||||
cd /root/code/github/despiegk/env_web/ourworld/ovh1_web_current/caddy/
|
||||
```
|
||||
|
||||
### 4.1 Add Import to Main Caddyfile
|
||||
|
||||
Edit the main Caddyfile and add the import statement:
|
||||
|
||||
```bash
|
||||
nano Caddyfile
|
||||
```
|
||||
|
||||
Add this line:
|
||||
```
|
||||
import economics.caddy
|
||||
```
|
||||
|
||||
### 4.2 Create Economics Caddy Config
|
||||
|
||||
Create the dedicated configuration file:
|
||||
|
||||
```bash
|
||||
nano economics.caddy
|
||||
```
|
||||
|
||||
Add the following content:
|
||||
|
||||
```
|
||||
# TFGrid Economics
|
||||
threefold.info {
|
||||
handle_path /economics* {
|
||||
reverse_proxy localhost:9997 {
|
||||
header_up Host {host}
|
||||
header_up X-Real-IP {remote}
|
||||
header_up X-Forwarded-Proto {scheme}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Notes:**
|
||||
- The `handle_path` directive strips `/economics` from the path before forwarding to port 9997
|
||||
- If you already have other services using `threefold.info`, add the `handle_path` block to the existing configuration
|
||||
- Multiple `handle_path` blocks can coexist in the same domain config
|
||||
|
||||
## Step 5: Start Services with zinit
|
||||
|
||||
Monitor and start the service:
|
||||
|
||||
```bash
|
||||
# Monitor the zinit service
|
||||
zinit monitor tfgrid-economics
|
||||
|
||||
# Start the service
|
||||
zinit start tfgrid-economics
|
||||
|
||||
# Restart Caddy to load new configuration
|
||||
zinit restart caddy
|
||||
```
|
||||
|
||||
## Updating the Application
|
||||
|
||||
To update the site after making changes:
|
||||
|
||||
```bash
|
||||
# Go to the repository directory
|
||||
cd /root/code/git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
|
||||
# Pull the latest changes
|
||||
git checkout main
|
||||
git pull
|
||||
|
||||
# Rebuild and restart
|
||||
zinit restart tfgrid-economics
|
||||
```
|
||||
|
||||
The service script will automatically rebuild the site when restarted.
|
||||
|
||||
## Monitoring
|
||||
|
||||
Check the application status:
|
||||
|
||||
```bash
|
||||
# Check if the service is running
|
||||
zinit list | grep tfgrid-economics
|
||||
|
||||
# View application logs
|
||||
zinit log tfgrid-economics
|
||||
|
||||
# Monitor logs in real-time
|
||||
tail -f /var/log/zinit/tfgrid-economics.log
|
||||
|
||||
# Check port is listening
|
||||
ss -tuln | grep 9997
|
||||
```
|
||||
|
||||
## Verification
|
||||
|
||||
After deployment, verify the site is accessible:
|
||||
|
||||
```bash
|
||||
# Test locally on the server
|
||||
curl http://localhost:9997
|
||||
|
||||
# Test via Caddy
|
||||
curl https://threefold.info/economics/
|
||||
```
|
||||
|
||||
Visit in your browser: **https://threefold.info/economics/**
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Application Not Starting
|
||||
|
||||
Check for errors in the application logs:
|
||||
|
||||
```bash
|
||||
zinit log tfgrid-economics
|
||||
```
|
||||
|
||||
### Build Failures
|
||||
|
||||
Check if Node.js and dependencies are properly installed:
|
||||
|
||||
```bash
|
||||
cd /root/code/git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
node --version # Should be 18+
|
||||
npm install
|
||||
npm run build
|
||||
```
|
||||
|
||||
### Connection Refused
|
||||
|
||||
Make sure the application is running and listening on the correct port:
|
||||
|
||||
```bash
|
||||
ss -tuln | grep 9997
|
||||
```
|
||||
|
||||
### Port Already in Use
|
||||
|
||||
If port 9997 is already in use, choose a different port:
|
||||
1. Update the port in `/etc/zinit/cmds/tfgrid-economics.sh`
|
||||
2. Update the port in the Caddy configuration
|
||||
3. Restart both services
|
||||
|
||||
```bash
|
||||
zinit restart tfgrid-economics
|
||||
zinit restart caddy
|
||||
```
|
||||
|
||||
### Caddy Not Serving the Site
|
||||
|
||||
Verify Caddy configuration:
|
||||
|
||||
```bash
|
||||
# Test Caddy configuration
|
||||
caddy validate --config /root/code/github/despiegk/env_web/ourworld/ovh1_web_current/caddy/Caddyfile
|
||||
|
||||
# Check Caddy logs
|
||||
zinit log caddy
|
||||
|
||||
# Restart Caddy
|
||||
zinit restart caddy
|
||||
```
|
||||
|
||||
### Git Authentication Issues
|
||||
|
||||
If the repository requires authentication:
|
||||
|
||||
```bash
|
||||
# Configure git credentials
|
||||
git config --global credential.helper store
|
||||
|
||||
# Or use SSH instead of HTTPS
|
||||
cd /root/code/git.ourworld.tf/tfgrid/
|
||||
rm -rf tfgrid-economics
|
||||
git clone git@git.ourworld.tf:tfgrid/tfgrid-economics.git
|
||||
cd tfgrid-economics
|
||||
git checkout main
|
||||
```
|
||||
|
||||
## Alternative: Direct Caddy File Server
|
||||
|
||||
Instead of using `npx serve`, you can configure Caddy to serve the static files directly.
|
||||
|
||||
**Edit `economics.caddy`:**
|
||||
```
|
||||
threefold.info {
|
||||
handle_path /economics* {
|
||||
root * /root/code/git.ourworld.tf/tfgrid/tfgrid-economics/build
|
||||
file_server
|
||||
try_files {path} {path}/ /index.html
|
||||
encode gzip
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Benefits:**
|
||||
- Simpler setup (no need for `npx serve`)
|
||||
- Caddy handles compression and caching efficiently
|
||||
- One less service to manage
|
||||
|
||||
With this approach, you don't need the zinit service - just rebuild when you update:
|
||||
|
||||
```bash
|
||||
cd /root/code/git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
git checkout main
|
||||
git pull
|
||||
npm install
|
||||
npm run build
|
||||
# Caddy automatically serves the updated build/ directory
|
||||
```
|
||||
|
||||
**Optional update script** (`/usr/local/bin/update-tfgrid-economics.sh`):
|
||||
```bash
|
||||
#!/bin/bash
|
||||
cd /root/code/git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
git checkout main
|
||||
git pull
|
||||
npm install
|
||||
npm run build
|
||||
echo "TFGrid Economics updated successfully"
|
||||
```
|
||||
|
||||
## Security Considerations
|
||||
|
||||
### File Permissions
|
||||
|
||||
Ensure proper file permissions:
|
||||
|
||||
```bash
|
||||
# Set ownership
|
||||
chown -R root:root /root/code/git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
|
||||
# Set directory permissions
|
||||
find /root/code/git.ourworld.tf/tfgrid/tfgrid-economics -type d -exec chmod 755 {} \;
|
||||
|
||||
# Set file permissions
|
||||
find /root/code/git.ourworld.tf/tfgrid/tfgrid-economics -type f -exec chmod 644 {} \;
|
||||
|
||||
# Make zinit script executable
|
||||
chmod +x /etc/zinit/cmds/tfgrid-economics.sh
|
||||
```
|
||||
|
||||
### HTTPS/SSL
|
||||
|
||||
Caddy automatically provisions SSL certificates via Let's Encrypt for your domain. Ensure:
|
||||
- Your domain resolves to the server
|
||||
- Ports 80 and 443 are open
|
||||
- Caddy can write to its data directory
|
||||
|
||||
### Firewall
|
||||
|
||||
Ensure required ports are open:
|
||||
|
||||
```bash
|
||||
# Check firewall status
|
||||
ufw status
|
||||
|
||||
# Open ports if needed
|
||||
ufw allow 80/tcp
|
||||
ufw allow 443/tcp
|
||||
```
|
||||
|
||||
## Service Management Summary
|
||||
|
||||
**Commands for daily operations:**
|
||||
|
||||
```bash
|
||||
# Start service
|
||||
zinit start tfgrid-economics
|
||||
|
||||
# Stop service
|
||||
zinit stop tfgrid-economics
|
||||
|
||||
# Restart service (rebuilds site)
|
||||
zinit restart tfgrid-economics
|
||||
|
||||
# Check status
|
||||
zinit list | grep tfgrid-economics
|
||||
|
||||
# View logs
|
||||
zinit log tfgrid-economics
|
||||
|
||||
# Monitor in real-time
|
||||
zinit monitor tfgrid-economics
|
||||
```
|
||||
|
||||
## Links
|
||||
|
||||
- **Repository**: https://git.ourworld.tf/tfgrid/tfgrid-economics
|
||||
- **Live Site**: https://threefold.info/economics/
|
||||
- **Server**: info.ourworld.tf
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- For local development setup, see `README.md` in the repository
|
||||
- For content updates and editing, see the repository documentation
|
||||
19291
package-lock.json
generated
Normal file
19291
package-lock.json
generated
Normal file
File diff suppressed because it is too large
Load Diff
47
package.json
Normal file
47
package.json
Normal file
@@ -0,0 +1,47 @@
|
||||
{
|
||||
"name": "tfgrid-economics",
|
||||
"version": "1.0.0",
|
||||
"private": true,
|
||||
"description": "TFGrid Economics - Minting Transition Plan",
|
||||
"scripts": {
|
||||
"docusaurus": "docusaurus",
|
||||
"start": "docusaurus start",
|
||||
"build": "docusaurus build",
|
||||
"swizzle": "docusaurus swizzle",
|
||||
"deploy": "docusaurus deploy",
|
||||
"clear": "docusaurus clear",
|
||||
"serve": "docusaurus serve",
|
||||
"write-translations": "docusaurus write-translations",
|
||||
"write-heading-ids": "docusaurus write-heading-ids"
|
||||
},
|
||||
"dependencies": {
|
||||
"@docusaurus/core": "^3.5.2",
|
||||
"@docusaurus/preset-classic": "^3.5.2",
|
||||
"@docusaurus/theme-mermaid": "^3.5.2",
|
||||
"@mdx-js/react": "^3.0.0",
|
||||
"clsx": "^2.0.0",
|
||||
"prism-react-renderer": "^2.3.0",
|
||||
"react": "^18.2.0",
|
||||
"react-dom": "^18.2.0"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@docusaurus/module-type-aliases": "^3.5.2",
|
||||
"@docusaurus/tsconfig": "^3.5.2",
|
||||
"@docusaurus/types": "^3.5.2"
|
||||
},
|
||||
"browserslist": {
|
||||
"production": [
|
||||
">0.5%",
|
||||
"not dead",
|
||||
"not op_mini all"
|
||||
],
|
||||
"development": [
|
||||
"last 3 chrome version",
|
||||
"last 3 firefox version",
|
||||
"last 5 safari version"
|
||||
]
|
||||
},
|
||||
"engines": {
|
||||
"node": ">=18.0"
|
||||
}
|
||||
}
|
||||
55
sidebars.js
Normal file
55
sidebars.js
Normal file
@@ -0,0 +1,55 @@
|
||||
/**
|
||||
* Creating a sidebar enables you to:
|
||||
- create an ordered group of docs
|
||||
- render a sidebar for each doc of that group
|
||||
- provide next/previous navigation
|
||||
|
||||
The sidebars can be generated from the filesystem, or explicitly defined here.
|
||||
|
||||
Create as many sidebars as you want.
|
||||
*/
|
||||
|
||||
// @ts-check
|
||||
|
||||
/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */
|
||||
const sidebars = {
|
||||
mainSidebar: [
|
||||
'intro',
|
||||
'implementation-roadmap',
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Core Concepts',
|
||||
link: {
|
||||
type: 'generated-index',
|
||||
title: 'Core Finance Concepts',
|
||||
description: 'Understand the fundamental mechanisms of the TFT minting transition plan, including token systems, liquidity pools, and exit mechanisms.',
|
||||
slug: '/core-concepts',
|
||||
},
|
||||
items: [
|
||||
'core-concepts/liquidity-pools-overview',
|
||||
'core-concepts/token-system',
|
||||
'core-concepts/position-based-lp',
|
||||
'core-concepts/dutch-auction-exit',
|
||||
'core-concepts/yin-yang-currency',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Node Economics & Pricing',
|
||||
link: {
|
||||
type: 'generated-index',
|
||||
title: 'Node Economics & Pricing',
|
||||
description: 'Understand the economic model for TFGrid farmers, including node specifications, pricing structures, income projections, and ThreeFold\'s committed capacity bids.',
|
||||
slug: '/node-economics',
|
||||
},
|
||||
items: [
|
||||
'node-economics/slices-overview',
|
||||
'node-economics/node-specifications',
|
||||
'node-economics/pricing-model',
|
||||
'node-economics/tf-bid-packages',
|
||||
],
|
||||
},
|
||||
],
|
||||
};
|
||||
|
||||
export default sidebars;
|
||||
107
src/css/custom.css
Normal file
107
src/css/custom.css
Normal file
@@ -0,0 +1,107 @@
|
||||
/**
|
||||
* Any CSS included here will be global. The classic template
|
||||
* bundles Infima by default. Infima is a CSS framework designed to
|
||||
* work well for content-centric websites.
|
||||
*/
|
||||
|
||||
/* You can override the default Infima variables here. */
|
||||
:root {
|
||||
--ifm-color-primary: #2e8555;
|
||||
--ifm-color-primary-dark: #29784c;
|
||||
--ifm-color-primary-darker: #277148;
|
||||
--ifm-color-primary-darkest: #205d3b;
|
||||
--ifm-color-primary-light: #33925d;
|
||||
--ifm-color-primary-lighter: #359962;
|
||||
--ifm-color-primary-lightest: #3cad6e;
|
||||
--ifm-code-font-size: 95%;
|
||||
--docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1);
|
||||
}
|
||||
|
||||
/* For readability improvements */
|
||||
[data-theme='dark'] {
|
||||
--ifm-color-primary: #25c2a0;
|
||||
--ifm-color-primary-dark: #21af90;
|
||||
--ifm-color-primary-darker: #1fa588;
|
||||
--ifm-color-primary-darkest: #1a8870;
|
||||
--ifm-color-primary-light: #29d5b0;
|
||||
--ifm-color-primary-lighter: #32d8b4;
|
||||
--ifm-color-primary-lightest: #4fddbf;
|
||||
--docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3);
|
||||
}
|
||||
|
||||
/* Custom styles for feedback callouts */
|
||||
.feedback-box {
|
||||
background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
|
||||
padding: 2rem;
|
||||
border-radius: 10px;
|
||||
margin: 2rem 0;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.feedback-box h2 {
|
||||
color: white;
|
||||
margin-top: 0;
|
||||
}
|
||||
|
||||
.feedback-links {
|
||||
display: flex;
|
||||
gap: 1rem;
|
||||
margin-top: 1.5rem;
|
||||
flex-wrap: wrap;
|
||||
}
|
||||
|
||||
.feedback-link {
|
||||
display: inline-block;
|
||||
padding: 0.75rem 1.5rem;
|
||||
background: rgba(255, 255, 255, 0.2);
|
||||
border-radius: 5px;
|
||||
color: white;
|
||||
text-decoration: none;
|
||||
font-weight: bold;
|
||||
transition: all 0.3s ease;
|
||||
}
|
||||
|
||||
.feedback-link:hover {
|
||||
background: rgba(255, 255, 255, 0.3);
|
||||
color: white;
|
||||
text-decoration: none;
|
||||
transform: translateY(-2px);
|
||||
}
|
||||
|
||||
/* Open questions styling */
|
||||
.open-questions {
|
||||
background: #fff3cd;
|
||||
border-left: 4px solid #ffc107;
|
||||
padding: 1.5rem;
|
||||
margin: 2rem 0;
|
||||
border-radius: 5px;
|
||||
}
|
||||
|
||||
[data-theme='dark'] .open-questions {
|
||||
background: #3d3416;
|
||||
border-left-color: #ffca28;
|
||||
}
|
||||
|
||||
.open-questions h3 {
|
||||
margin-top: 0;
|
||||
color: #856404;
|
||||
}
|
||||
|
||||
[data-theme='dark'] .open-questions h3 {
|
||||
color: #ffd54f;
|
||||
}
|
||||
|
||||
.open-questions ul {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
/* Table improvements */
|
||||
table {
|
||||
display: table;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
/* Code block improvements */
|
||||
pre {
|
||||
border-radius: 8px;
|
||||
}
|
||||
1
static/CNAME
Normal file
1
static/CNAME
Normal file
@@ -0,0 +1 @@
|
||||
plan.threefold.pro
|
||||
BIN
static/img/favicon.png
Normal file
BIN
static/img/favicon.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 327 B |
BIN
static/img/margin_distribution.png
Normal file
BIN
static/img/margin_distribution.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
BIN
static/img/margin_distribution_1.png
Normal file
BIN
static/img/margin_distribution_1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.1 MiB |
BIN
static/img/new_logo_tft.png
Normal file
BIN
static/img/new_logo_tft.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 8.2 KiB |
Reference in New Issue
Block a user