added info for first page projectinca #131
@ -7,6 +7,15 @@
|
||||
- [Decentralization 3.x](projectinca/decentralization3.md)
|
||||
- [Decentralization 4.x](projectinca/decentralization4.md)
|
||||
- [TF Validators 4.x](projectinca/TFValidatorCluster.md)
|
||||
- [All Trust](tfgrid4/alltrust.md)
|
||||
- [Blockchain](projectinca/blockchain.md)
|
||||
- [Blockchain](projectinca/ourworld_blockchain.md)
|
||||
- [Generator Tokens](projectinca/generator_token.md)
|
||||
- [Minting Contract](projectinca/minting_contract.md)
|
||||
- [Oracle Contract](projectinca/oracle_contract.md)
|
||||
- [Code Contract](projectinca/code_contract.md)
|
||||
- [Bridging Contract](projectinca/bridging_contract.md)
|
||||
- [Liquidity Pool](projectinca/liquidity_pool_contract.md)
|
||||
- [**Technology**](projectinca/technology.md)
|
||||
- [Project Info](projectinca/project_info.md)
|
||||
- [About Us](tfgrid3/who_are_we.md)
|
||||
|
||||
@ -1,135 +0,0 @@
|
||||
|
||||
|
||||
# The plan with INCA and INCA Generator
|
||||
|
||||
> INCA = INternet CApacity (is the token of buying/selling Internet/Cloud Capacity)
|
||||
<br>
|
||||
> INCA-G = INCA Generator (is a token generating INCA typically over 48 months)
|
||||
|
||||
An INCA-G token generates INCA over a certain period. INCA stands for Internet Capacity token, enabling individuals to buy/sell Internet & Cloud Capacity.
|
||||
|
||||
We can analogize the generation of Cloud/Internet capacity to the generation of electricity. In this analogy, INCA is akin to the KWH token, while INCA-G is comparable to the KW token (representing capacity to generate electricity).
|
||||
|
||||
INCA-G tokens are unique and come with metadata specifying how INCA will be generated. This metadata outlines the generation schedule of INCA over the next X months.
|
||||
|
||||
## High Level Tokenomics INCA
|
||||
|
||||
There can never be more than 4 Billion INCA
|
||||
|
||||
- 2 Billion for TFT holders
|
||||
- Will be sold uniquely to TFT Holders (mainly farmers of the current TFGrid)
|
||||
- We expect to never fully get to this amount, each TFT converted to INCA gets burned (destroyed).
|
||||
- 0.8 Billion for community expansion
|
||||
- promotion of the TFGrid
|
||||
- farming
|
||||
- creation of technology on top of the TF Grid
|
||||
- reward for farmers and other contributors
|
||||
- peer2peer promotion program
|
||||
- release schedule: max 40% year 1, 40% year 2, 20 % year 3
|
||||
- 0.8 Billion for expansion of farming capacity of the grid
|
||||
- Will be sold through partners e.g. SwissBorg (through INCA-G) and others...
|
||||
- 0.4 Billion for team with 24 months accelerated vesting.
|
||||
- 10 % of total
|
||||
- is for people who help to expand the Grid (starting now)
|
||||
- a lot of it is to reward our partners to help launch the INCA Tokens & the TF Grid
|
||||
|
||||
|
||||
```echarts
|
||||
option = {
|
||||
title: {
|
||||
text: 'INCA Token',
|
||||
subtext: 'Distribution',
|
||||
left: 'center'
|
||||
},
|
||||
tooltip: {
|
||||
trigger: 'item'
|
||||
},
|
||||
series: [
|
||||
{
|
||||
name: 'Distribution',
|
||||
type: 'pie',
|
||||
radius: '70%',
|
||||
data: [
|
||||
{ value: 2, name: 'TF Original Farmers' },
|
||||
{ value: 0.8, name: 'Farming Rewards' },
|
||||
{ value: 0.8, name: 'Community Expansion' },
|
||||
{ value: 0.4, name: 'Team' },
|
||||
],
|
||||
emphasis: {
|
||||
itemStyle: {
|
||||
shadowBlur: 10,
|
||||
shadowOffsetX: 0,
|
||||
shadowColor: 'rgba(0, 0, 0, 0.5)'
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
};
|
||||
```
|
||||
|
||||
*Accelerated Vesting means: if INCA gets above 0.5 CHF per INCA the vesting accelerates 50%, if above 0.6 CHF 60%, ... if above 1 CHF 100% acceleration.*
|
||||
|
||||
|
||||
## How can people acquire an INCA-G token?
|
||||
|
||||
### Round 1: SwissBorg & TF Cooperative
|
||||
|
||||
1 INCA-G token generates 15,000 INCA over 48 months
|
||||
|
||||
1 INCA-G can be bought:
|
||||
|
||||
- from SwissBorg for 500 CHF
|
||||
- crypto enabled bank in Switserland
|
||||
- Maximum sold is 5,000 INCA-G tokens
|
||||
- with TFT which is the founder creator currency of the current grid
|
||||
- there will never be more than 1 billion TFT
|
||||
- 1 INCA-G token costs 10,000 TFT (\*)
|
||||
|
||||
> (\*) The pricing will depend on price of TFT at that moment.
|
||||
|
||||
### Round 2: **A**frica and latin **A**merica INCA-G Tokens (AA)
|
||||
|
||||
1 INCA-G AA Token, generates 10,000 INCA over 48 months
|
||||
|
||||
AA stands for Africa and latin America
|
||||
|
||||
- from SwissBorg for TBD CHF.
|
||||
|
||||
The incoming funds will be used to generate Cloud & Internet capacity in these regions, <br>which are serious growth regions in the world.
|
||||
|
||||
## INCA governance
|
||||
|
||||
A Wisdom Council approves budgets in line to tokenomics above.
|
||||
|
||||
- ThreeFold Wisdom Council, to be created, 9 people, 6 need to agree.
|
||||
- 1 OurWorld (MWW)
|
||||
- 1 ThreeFold DMCC (Adnan)
|
||||
- 1 TF9 (Kristof)
|
||||
- 1 Sikana (Greg)
|
||||
- **5 people with name in community**
|
||||
- Budgets get allocated to projects on git.threefold.info, clear stories with clear budget allocations and cashflow tracking or time tracking.
|
||||
|
||||
## How does TFT related to INCA
|
||||
|
||||
- TFT is the original creator farming token and can be used to buy/sell IT capacity (compute, storage, network).
|
||||
- INCA-G is the new genertor token which produces INCA over 48 months.
|
||||
|
||||
TFT Holders can get into INCA and INCA-G in 2 ways
|
||||
|
||||
- buy INCA-G tokens: generates INCA over 4 year
|
||||
- buy INCA tokens: 1 TFT buys 2 INCA tokens.
|
||||
|
||||
> note TFT will keep its original purpose, as well as getting a new purpose thanks to INCA-G.
|
||||
|
||||
## Technical TFT, INCA & INCA-G
|
||||
|
||||
#### Implementation
|
||||
|
||||
- TFT is a token on Stellar blockchain (the original farming token)
|
||||
- INCA is a token on Solana Blockchain (as digital currency for Internet Capacity)
|
||||
- INCA-G Implemented as an NFT on the Solana Blockchain.
|
||||
|
||||
#### Metadata for INCA-G
|
||||
|
||||
- release date
|
||||
- list of values, each value is nr of INCA's to be released in a month
|
||||
@ -1,88 +0,0 @@
|
||||
|
||||
|
||||
# Plan B
|
||||
|
||||
Simple model where TFT can convert into INCA.
|
||||
|
||||
## Tokens
|
||||
|
||||
- 1 TFT -> 3 INCA
|
||||
- the mechanism in which this happens needs to be defined
|
||||
- max 4 billion INCA
|
||||
|
||||
## How to go from TFT to INCA
|
||||
|
||||
> please note TFT will keep its own purpose, TFT can be used to buy/sell IT capacity (compute, storage, network). INCA is a new token made for the DePIN space, TFT holders can voluntary choose to go from TFT to INCA.
|
||||
|
||||
- mechanism hasn't been defined yet
|
||||
- there might be conditions to conversion
|
||||
- vesting?
|
||||
- requirement to put some cash in a liquidity pool?
|
||||
- others?
|
||||
|
||||
## the 1 billion INCA expansion for the Ecosystem
|
||||
|
||||
- promotion through grants
|
||||
- technical achievements (develop tech)
|
||||
- reward for farmers and other contributors (expansion)
|
||||
- peer2peer promotion program
|
||||
|
||||
Governance
|
||||
|
||||
- ThreeFold Wisdom Council, to be created, 9 people, 6 need to agree.
|
||||
- 1 OurWorld (MWW)
|
||||
- 1 ThreeFold DMCC (Adnan)
|
||||
- 1 TF9 (Kristof)
|
||||
- 1 Sikana (Greg)
|
||||
- **5 people with name in community**
|
||||
- Budgets get allocated to projects on http://git.threefold.info, clear stories with clear budget allocations and cashflow tracking or time tracking.
|
||||
|
||||
|
||||
# Tokenomics
|
||||
|
||||
> this is only a suggestion, the DePIN advisor team will probably come up with improvements and other requirements.
|
||||
|
||||
The following is the chart suggesting how the INCA might be distributed.
|
||||
|
||||
```echarts
|
||||
option = {
|
||||
title: {
|
||||
text: 'INCA Token',
|
||||
subtext: 'Distribution',
|
||||
left: 'center'
|
||||
},
|
||||
tooltip: {
|
||||
trigger: 'item'
|
||||
},
|
||||
series: [
|
||||
{
|
||||
name: 'Distribution',
|
||||
type: 'pie',
|
||||
radius: '70%',
|
||||
data: [
|
||||
{ value: 75000, name: 'TFT Conversion' },
|
||||
{ value: 10000, name: 'Farming Rewards' },
|
||||
{ value: 5000, name: 'Community Expansion (Grants)' },
|
||||
{ value: 4000, name: 'Team'}
|
||||
{ value: 2000, name: 'Liquidity' },
|
||||
{ value: 2000, name: '3Node Rewards' },
|
||||
{ value: 2000, name: 'Developer Grants' },
|
||||
|
||||
],
|
||||
emphasis: {
|
||||
itemStyle: {
|
||||
shadowBlur: 10,
|
||||
shadowOffsetX: 0,
|
||||
shadowColor: 'rgba(0, 0, 0, 0.5)'
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
};
|
||||
```
|
||||
|
||||
No INCA tokens are used for funding or reward of existing team, this all comes out of the historical TFT Tokens.
|
||||
|
||||
- The 75% is the big one and is for conversion of TFT to INCA (1 TFT becomes 3 INCA)
|
||||
- The other 25% is all for rewarding the ecosystem to make INCA succesfull.
|
||||
|
||||
@ -1,52 +0,0 @@
|
||||
# Tokenomics INCA
|
||||
|
||||
> this is a suggestion, the DePIN advisor team will probably come up with improvements and other requirements.
|
||||
|
||||
The following is the chart suggesting how the INCA might be distributed.
|
||||
|
||||
```echarts
|
||||
option = {
|
||||
title: {
|
||||
text: 'INCA Token',z
|
||||
subtext: 'Distribution',
|
||||
left: 'center'
|
||||
},
|
||||
tooltip: {
|
||||
trigger: 'item'
|
||||
},
|
||||
series: [
|
||||
{
|
||||
name: 'Distribution',
|
||||
type: 'pie',
|
||||
radius: '70%',
|
||||
data: [
|
||||
{ value: 50000, name: 'TFT Conversion' },
|
||||
{ value: 25000, name: 'INCA Cloud' },
|
||||
{ value: 10000, name: 'Farming Rewards' },
|
||||
{ value: 2500, name: 'Liquidity' },
|
||||
{ value: 2500, name: 'Airdrops' },
|
||||
{ value: 2500, name: '3Node Rewards' },
|
||||
{ value: 2500, name: 'Developer Grants' },
|
||||
{ value: 5000, name: 'Community Grants' }
|
||||
],
|
||||
emphasis: {
|
||||
itemStyle: {
|
||||
shadowBlur: 10,
|
||||
shadowOffsetX: 0,
|
||||
shadowColor: 'rgba(0, 0, 0, 0.5)'
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
};
|
||||
```
|
||||
|
||||
- 0-50% allows ThreeFold Token (TFT) holders to swap into INCA Cloud Tokens if they would like to switch Cloud.
|
||||
- 25% of 1 Billion INCA is sold as a pre-sale for people who are buying cloud capacity from INCA Cloud.
|
||||
|
||||
- The 50% is the big one and is for conversion of TFT to INCA (1 TFT becomes 3 INCA)
|
||||
- The other 25% is all for rewarding the ecosystem to make INCA succesfull.
|
||||
|
||||
## Distribution Detail
|
||||
|
||||
|
||||
@ -1,50 +0,0 @@
|
||||
# Tokenomics B
|
||||
|
||||
> this is only a suggestion, the DePIN advisor team will probably come up with improvements and other requirements.
|
||||
|
||||
The following is the chart suggesting how the INCA might be distributed.
|
||||
|
||||
```echarts
|
||||
option = {
|
||||
title: {
|
||||
text: 'INCA Token',
|
||||
subtext: 'Distribution',
|
||||
left: 'center'
|
||||
},
|
||||
tooltip: {
|
||||
trigger: 'item'
|
||||
},
|
||||
series: [
|
||||
{
|
||||
name: 'Distribution',
|
||||
type: 'pie',
|
||||
radius: '70%',
|
||||
data: [
|
||||
{ value: 75000, name: 'TFT Conversion' },
|
||||
{ value: 10000, name: 'Farming Rewards' },
|
||||
{ value: 2500, name: 'Liquidity' },
|
||||
{ value: 2500, name: 'Airdrops' },
|
||||
{ value: 2500, name: '3Node Rewards' },
|
||||
{ value: 2500, name: 'Developer Grants' },
|
||||
{ value: 5000, name: 'Community Grants' }
|
||||
],
|
||||
emphasis: {
|
||||
itemStyle: {
|
||||
shadowBlur: 10,
|
||||
shadowOffsetX: 0,
|
||||
shadowColor: 'rgba(0, 0, 0, 0.5)'
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
};
|
||||
```
|
||||
|
||||
No INCA tokens are used for funding or reward of existing team, this all comes out of the historical TFT Tokens.
|
||||
|
||||
- The 75% is the big one and is for conversion of TFT to INCA (1 TFT becomes 3 INCA)
|
||||
- The other 25% is all for rewarding the ecosystem to make INCA succesfull.
|
||||
|
||||
## Distribution Detail
|
||||
|
||||
|
||||
@ -2,9 +2,8 @@
|
||||
|
||||
# Remuneration
|
||||
|
||||
Our aim is to get the marketcap to billions of USD which means we expect the INCA token to reach potentially 1 USD. Looking at what competition is doing, this should be possible.
|
||||
|
||||
We believe the best way to remunerate our virtual teams is by rewarding INCA tokens with a vesting scheme.
|
||||
- Our aim is to get the marketcap to billions of USD (*).
|
||||
- We believe the best way to remunerate our team is by rewarding INCA tokens with a vesting scheme.
|
||||
|
||||
## Remuneration of Launch of this Project
|
||||
|
||||
@ -16,4 +15,7 @@ We believe the best way to remunerate our virtual teams is by rewarding INCA tok
|
||||
- If above 0.6 CHF 60%
|
||||
- ...
|
||||
- If above 1 CHF 100% acceleration
|
||||
- Agreement with TF DMCC
|
||||
- Agreement with TF DMCC or Smart Contract
|
||||
|
||||
|
||||
> (*) Disclaimer, no promise...
|
||||
@ -1,35 +1,44 @@
|
||||
# Teams
|
||||
|
||||
> TODO: complete
|
||||
## ThreeFold DMCC
|
||||
|
||||
We operate from Dubai
|
||||
|
||||
## Core Team
|
||||
- Adnan CEO
|
||||
- Sam Communication
|
||||
- Marion, websites, community
|
||||
- Kristof, CTO
|
||||
- Florian, Biz Dev
|
||||
|
||||
> todo:
|
||||
## Community Management
|
||||
|
||||
- Mik
|
||||
- Scott
|
||||
- 5 people in India
|
||||
|
||||
## Strategy, Funding
|
||||
|
||||
- Funding process, Kristof, Florian, Quentin
|
||||
|
||||
## Token Team
|
||||
|
||||
- Quentin
|
||||
- Kristof (will also do the tech)
|
||||
- David (Holochain) as advisor
|
||||
|
||||
## Direct Promotion: PP2P teams
|
||||
|
||||
To create
|
||||
|
||||
- Hit the forums
|
||||
- Use the referral based system for the P2PP
|
||||
- Multiple teams, per region, can split to more regions e.g. Europe becomes 3 groups who become 3 subgroups, etc.
|
||||
|
||||
## Marketing & Communication Coordination...
|
||||
|
||||
- Georges, Michael, ...
|
||||
To create
|
||||
|
||||
- Marketing (Marc parttime as adviser)
|
||||
- Find influencers...
|
||||
- Find members for teams...
|
||||
|
||||
## Strategy, Funding
|
||||
|
||||
- Find funding for liquidity pools
|
||||
|
||||
## Token Team
|
||||
|
||||
- David (Holochain)
|
||||
- Kristof (will also do the tech)
|
||||
- Florian
|
||||
- ?
|
||||
|
||||
## What
|
||||
|
||||
- Marketmaking
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
|
||||
# Funding Through OurWorld
|
||||
|
||||
Our partner projects are fundraising and do need a lot of capacity, they are planning to buy a lot of TFT/INCA.
|
||||
Our partner projects are fundraising and do need a lot of capacity, they are planning to buy a lot of INCA.
|
||||
|
||||
# Funding Through Private Token Sale
|
||||
|
||||
|
||||
29
collections/projectinca/funding/incag_funding.md
Normal file
29
collections/projectinca/funding/incag_funding.md
Normal file
@ -0,0 +1,29 @@
|
||||
|
||||
|
||||
### Round 1: SwissBorg & TF Cooperative
|
||||
|
||||
1 INCA-G token generates 15,000 INCA over 48 months.
|
||||
|
||||
1 INCA-G can be bought:
|
||||
|
||||
- From SwissBorg for 500 CHF
|
||||
- Crypto-enabled bank in Switzerland
|
||||
- Maximum sold is 5,000 INCA-G tokens
|
||||
- with TFT which is the founder creator currency of the current grid
|
||||
- There will never be more than 1 billion TFT
|
||||
- 1 INCA-G token costs 10,000 TFT (\*)
|
||||
|
||||
> (\*) The pricing will depend on price of TFT at that moment.
|
||||
|
||||
### Round 2: **A**frica and Latin **A**merica INCA-G Tokens (AA)
|
||||
|
||||
> TODO: to be discussed
|
||||
|
||||
1 INCA-G AA Token generates 10,000 INCA over 48 months.
|
||||
|
||||
AA stands for Africa and latin America
|
||||
|
||||
- From SwissBorg for *TBD* CHF.
|
||||
|
||||
The incoming funds will be used to generate Cloud & Internet capacity in these regions, <br>which are serious growth regions in the world.
|
||||
|
||||
@ -1,36 +1,36 @@
|
||||
|
||||
|
||||
|
||||
> TODO: not good enough
|
||||
|
||||
# Liquidity
|
||||
|
||||
## Liquidity Pool
|
||||
|
||||
We expect our Liquidity Pool to be a very efficient mechanism to reward people to provide liquidity to our ecosystem. Read more in our [Liquidity Pool Document](liquidity_pool.md)
|
||||
|
||||
## Solana
|
||||
|
||||
Our INCA token will probably be released on Solana blockchain and we are relying on their ecosystem to provide liquidity.
|
||||
The ThreeFold v4 token called INCA will probably be released on Solana blockchain and this might provide us access to large liquidity pools.
|
||||
|
||||
## Exchanges
|
||||
|
||||
We are working with our partners to see which exchanges are good to list and get listed on.
|
||||
ThreeFold is working with our partners to see which exchanges are good to list and get listed on.
|
||||
|
||||
## MarketMakers
|
||||
|
||||
ThreeFold is planning to work with professional marketmakers.
|
||||
|
||||
## MultiChain
|
||||
|
||||
ThreeFold would love to have bridges between our main chosen chain and many other chains, making it super easy for our community to use our tokens on multiple chains. INCA represents compute, storage and network capacity, we believe this type of currency is a currency of the future.
|
||||
|
||||
## DEXes
|
||||
|
||||
We will partner with many DEX'es and make our token available where possible.
|
||||
ThreeFold will partner with many DEX'es and make our token available where possible.
|
||||
We are on the Stellar DEX today, unfortunatelly there is low liquidity.
|
||||
|
||||
## THORChain
|
||||
|
||||
THORCHain is an amazing platform, with a super nice decentralized exchange (DEX). We need to find some cash to launch the project on this chain.
|
||||
THORCHain is an amazing platform, with a super nice decentralized exchange (DEX). Our plan is to integrate there as well.
|
||||
|
||||
## LiquidCrypto
|
||||
|
||||
See the [liquidCrypto](https://liquidcrypto.finance/) website.
|
||||
|
||||
- A very nice platform
|
||||
- We can even whitelabel if that would be required
|
||||
- Works on many blockchain platforms and is very well integrated with many DEXes
|
||||
- There will be an INCA liquidity pool, which can have parameters as defined by us
|
||||
- This liquidity pool can be accessed from multiple blockchains e.g. Solana, Stellar, Ethereum-based chains
|
||||
|
||||
## Stellar (History)
|
||||
|
||||
Existing mechanism is the Stellar DEX. It has low liquidity and is not very useful today.
|
||||
@ -1,7 +1,71 @@
|
||||
|
||||
|
||||
|
||||
# Liquidity Pool
|
||||
# ThreeFold Liquidity Pool
|
||||
|
||||
> Kristof: todo
|
||||
The Threefold Liquidity Pool Concept represents a significant advancement over traditional liquidity pools, particularly those known as Automatic Market Makers (AMMs). This system is designed to offer a more sophisticated and transparent approach to our token liquidity management, with several unique features:
|
||||
|
||||
Advanced Digital Accounting System:
|
||||
|
||||
- Unlike typical AMMs, the ThreeFold Liquidity Pool incorporates a full digital accounting system secured by blockchain technology.
|
||||
- This ensures that all transactions are accurately recorded and transparently reflected in the accounts of all participants.
|
||||
|
||||
GOLD-Centric Pairs:
|
||||
|
||||
- Our liquidity pool pair GOLD with either a INCA or a FIAT currency (e.g., CHF, EUR).
|
||||
- This approach ensures that GOLD remains a central and stable element in all transactions, providing a reliable store of value and reducing volatility.
|
||||
|
||||
Transparent Pool Rules:
|
||||
|
||||
- The rules governing each pool are fully transparent and accessible to all participants.
|
||||
- These include the distribution percentages between GOLD and INCA, the spread, and other key parameters.
|
||||
- This transparency helps maintain trust and fairness within the ecosystem.
|
||||
|
||||
Private, Registered Participants:
|
||||
|
||||
- Each participant in a pool is registered with a private record that details their holdings (e.g., Mr. X has 100 gram of Gold and 10,000 TFT).
|
||||
- This system ensures that transactions are securely tracked and that each participant's share of the pool is accurately accounted for.
|
||||
|
||||
Reflective Transaction Mechanism:
|
||||
|
||||
- For every transaction within the pool, participants’ accounts are adjusted accordingly.
|
||||
- For example, if 1m of TFT is sold for gold and Mr. X holds 5% of the TFT pool, his account is updated to reflect a 5% reduction in TFT and a corresponding increase in his gold holdings, adjusted by the transaction spread (the margin).
|
||||
|
||||
Optional Lockup Rules:
|
||||
|
||||
- Pools can optionally include lockup periods during which participants cannot withdraw their assets.
|
||||
- These periods can be linked to value acceleration mechanisms, incentivizing long-term participation and protecting against market manipulation, such as front-running.
|
||||
|
||||
Customizable Price Limits:
|
||||
|
||||
- Participants can set minimum selling prices or maximum buying prices for their assets TFT or INCA.
|
||||
- These settings can remain private unless the pool's rules require public aggregation.
|
||||
- If no specific price is set, default values established by pool administrators are applied.
|
||||
|
||||
Aggregate Transaction Statistics:
|
||||
|
||||
- The system provides aggregated daily statistics on transactions, offering participants insights without compromising privacy.
|
||||
- This information includes the default buy/sell prices, helping guide market activity while ensuring that individual transactions remain confidential.
|
||||
|
||||
Fair and Transparent Participation:
|
||||
|
||||
- The system is designed to be fair and transparent, adjusting each participant's position in the pool relative to their entry time and participation level.
|
||||
- This dynamic adjustment over time ensures that the system remains equitable and reflective of each participant’s contribution.
|
||||
|
||||
Liquidity Optimization:
|
||||
|
||||
- While the system rewards liquidity providers and maximizes liquidity availability, it does not guarantee it.
|
||||
- In cases where liquidity is insufficient, participants cannot execute trades until liquidity returns.
|
||||
- However, they can still place requests in the pool, ensuring that their needs are met over time as liquidity improves.
|
||||
|
||||
Participation in Liquidity Pool Defines the Discount on the TFGrid
|
||||
|
||||
- The pricing engine for the marketplace will use the position of the user in the Liquidity Pool to define discount level, this means the more someone is vested in the ecosystem the more the discount will be.
|
||||
|
||||
|
||||
### Link To Digital Asset Exchange in OurWorld Digital FreeZone
|
||||
|
||||
The mother company of ThreeFold is a holding company called OurWorld.
|
||||
|
||||
OurWorld also owns a Digital Freezone in which a lot of digital assets will be traded, the above described Liquidity Pool concept comes from there and ThreeFold (INCA) is one of the tokens traded on the OurWorld Digital Exchange.
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
|
||||
|
||||
- The Farmers set pricing but the sheet above shows you have the TFGrid is super competive.
|
||||
- In the calculation above the user has enough TFT/INCA in his account on the TF Liquidity Pool to get 50% discount.
|
||||
- In the calculation above the user has enough INCA in his account on the TF Liquidity Pool to get 50% discount.
|
||||
|
||||
To see average prices you can look at [cloudorado](https://www.cloudorado.com/)
|
||||
|
||||
|
||||
@ -5,13 +5,12 @@ The network of 3Nodes running Zero-OS will use a marketplace as its front end.
|
||||
|
||||
## NEW
|
||||
|
||||
- Simplified concept of [Cloud Slices](tfgrid4:Cloud Slice.md) & [StorageSlices](tfgrid4:storageslice.md)
|
||||
- Simplified concept of [Cloud Slices](tfgrid4:cloudslice.md) & [StorageSlices](tfgrid4:storageslice.md)
|
||||
- SLA management
|
||||
- More strict enforcement about suportability from a farming perspective
|
||||
- All farmers can set their pricing
|
||||
- Mutual credit based billing & tracking
|
||||
- Introduction of 3bot as our personal System administrator
|
||||
- Introduction of the TF Marketplace as the best way how to provision and manage workloads on the TFGrid 4.0
|
||||
- INCA is the currency for TFGrid 4
|
||||
|
||||
> TODO: and so much more
|
||||
- Introduction of the Liquidity Pool Concept
|
||||
- Introduction of Marketplace, users can use FIAT Currencies
|
||||
|
||||
34
collections/projectinca/specs_blockchain/blockchain.md
Normal file
34
collections/projectinca/specs_blockchain/blockchain.md
Normal file
@ -0,0 +1,34 @@
|
||||
|
||||
|
||||
# Blockchain
|
||||
|
||||
ThreeFold has chosen for a multi blockchain approach.
|
||||
|
||||
- there will be a main blockchain chosen where the minting of the token happens
|
||||
- candidates are Solana, Ethereum based one, Hedera Hashgraph, ...
|
||||
- then bridges will make sure token exist on many more blockchains
|
||||
- many ethereum chains
|
||||
- stellar
|
||||
- solana
|
||||
- ...
|
||||
|
||||
There are multiple tokens
|
||||
|
||||
- INCA = Our main INternet CApacity token
|
||||
- INCAG = a generator token, generates X amount of INCA per month can be with acceleration
|
||||
- TFT = the original token used to create our grid, can convert to INCAG tokens
|
||||
|
||||
### Initial Smart Contracts
|
||||
|
||||
The smart contracts we use run on a blockchain as has been developed by us to be used in a digital freezone
|
||||
|
||||
- [OurWorld Blockchain](projectinca/ourworld_blockchain.md)
|
||||
- [Generator Tokens](projectinca/generator_token.md)
|
||||
- [Minting Contract](projectinca/minting_contract.md)
|
||||
- [Oracle Contract](projectinca/oracle_contract.md)
|
||||
- [Code Contract](projectinca/code_contract.md)
|
||||
- [Bridging Contract](projectinca/bridging_contract.md)
|
||||
- [Liquidity Pool](projectinca/liquidity_pool_contract.md)
|
||||
|
||||
Do note that minting and token management is done by the master blockchain, we did not re-implement how to deal with digital currencies or even NFT's, we use multisignature capabilities on these blockchains.
|
||||
|
||||
132
collections/projectinca/specs_blockchain/bridging_contract.md
Normal file
132
collections/projectinca/specs_blockchain/bridging_contract.md
Normal file
@ -0,0 +1,132 @@
|
||||
# Bridging Contract
|
||||
|
||||
Is code which has the capability to bridge between multiple blockchains.
|
||||
|
||||
A bridging mechanism allows tokens to be transferred between different blockchains. Here's how it typically works:
|
||||
|
||||
1. A user sends tokens to the `src_bridge_address` on the source chain.
|
||||
2. The bridging contract detects this transaction.
|
||||
3. The lockers on the source chain verify and lock the tokens at the `src_lock_address`.
|
||||
4. The minters on the destination chain are notified and create an equivalent amount of tokens on the destination chain.
|
||||
5. The new tokens are released to the user's address on the destination chain.
|
||||
6. The original tokens remain locked on the source chain until a reverse bridge operation is performed.
|
||||
|
||||
Here's an example JSON for a Bridging Contract:
|
||||
|
||||
```json
|
||||
{
|
||||
"bridging_contract": {
|
||||
"name": "INCA_SOLANA_BNC_BRIDGE",
|
||||
"description": "Bridging contract for INCA tokens between Solana and Binance Chain",
|
||||
"address": "0x1234567890123456789012345678901234567890",
|
||||
"src_token_name": "INCA",
|
||||
"src_chain": "SOLANA",
|
||||
"src_bridge_address": "0xABCDEF1234567890ABCDEF1234567890ABCDEF12",
|
||||
"src_lock_address": "0x9876543210987654321098765432109876543210",
|
||||
"dest_token_name": "INCA",
|
||||
"dest_chain": "BNC",
|
||||
"lockers": {
|
||||
"lockers_multisig_accounts": [
|
||||
"0x1111111111111111111111111111111111111111",
|
||||
"0x2222222222222222222222222222222222222222",
|
||||
"0x3333333333333333333333333333333333333333",
|
||||
"0x4444444444444444444444444444444444444444",
|
||||
"0x5555555555555555555555555555555555555555",
|
||||
"0x6666666666666666666666666666666666666666",
|
||||
"0x7777777777777777777777777777777777777777",
|
||||
"0x8888888888888888888888888888888888888888",
|
||||
"0x9999999999999999999999999999999999999999"
|
||||
],
|
||||
"lockers_multisig_min_signature": 6
|
||||
},
|
||||
"minters": {
|
||||
"minter_multisig_accounts": [
|
||||
"bnb1aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
|
||||
"bnb1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",
|
||||
"bnb1cccccccccccccccccccccccccccccccccccc",
|
||||
"bnb1dddddddddddddddddddddddddddddddddddd",
|
||||
"bnb1eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee",
|
||||
"bnb1ffffffffffffffffffffffffffffffffffff",
|
||||
"bnb1gggggggggggggggggggggggggggggggggggg",
|
||||
"bnb1hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh",
|
||||
"bnb1iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii"
|
||||
],
|
||||
"minter_multisig_min_signature": 6
|
||||
},
|
||||
"smart_contract_addr": "0xFEDCBA9876543210FEDCBA9876543210FEDCBA98"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This JSON structure represents a bridging contract for INCA tokens between Solana and Binance Chain. It includes:
|
||||
|
||||
1. Basic information about the bridge (name, description, address).
|
||||
2. Source and destination chain details, including token names and relevant addresses.
|
||||
3. Multisig requirements for lockers on the source chain.
|
||||
4. Multisig requirements for minters on the destination chain.
|
||||
5. The smart contract address that implements the bridging logic.
|
||||
|
||||
This structure allows for a secure and decentralized bridging process, requiring multiple signatures for locking tokens on the source chain, minting on the destination chain, and overall bridge operations.
|
||||
|
||||
### details about properties
|
||||
|
||||
- name
|
||||
- description
|
||||
- address, the address of this contract
|
||||
- src_token_name e.g. INCA in case of ThreeFold
|
||||
- src_chain e.g. SOLANA
|
||||
- src_bridge_address
|
||||
- address where tokens have been sent to which need to be bridged, they are locked untill executed
|
||||
- src_lock_address
|
||||
- once the tokens where created on the dest chain then on source they are locked
|
||||
- dest_token_name e.g. INCA in case of ThreeFold
|
||||
- dest_chain e.g. BNC
|
||||
- the lockers on source
|
||||
- lockers_multisig_accounts = list e.g 9 accounts
|
||||
- lockers_multisig_min_signature: 6
|
||||
- the minters on dest
|
||||
- minter_multisig_accounts = list e.g 9 accounts
|
||||
- minter_multisig_min_signature: 6
|
||||
- multisig_accounts e.g. 9 accounts need to sign
|
||||
- multisig_min_signature e.g. 6 need to sign, this is for releasing the generated token INCA
|
||||
- smart_contract_addr: address of the smart contract
|
||||
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User
|
||||
participant SourceChain
|
||||
participant BridgingContract
|
||||
participant DestChain
|
||||
|
||||
User->>SourceChain: Send tokens to src_bridge_address
|
||||
SourceChain->>BridgingContract: Notify of received tokens
|
||||
BridgingContract->>SourceChain: Verify transaction
|
||||
|
||||
alt Transaction valid
|
||||
BridgingContract->>SourceChain: Request token lock
|
||||
SourceChain->>SourceChain: Lock tokens at src_lock_address
|
||||
SourceChain-->>BridgingContract: Confirm lock
|
||||
|
||||
BridgingContract->>BridgingContract: Initiate multisig process
|
||||
loop Until minimum signatures reached
|
||||
BridgingContract->>BridgingContract: Collect locker signatures
|
||||
end
|
||||
|
||||
BridgingContract->>DestChain: Request token minting
|
||||
DestChain->>DestChain: Initiate minter multisig process
|
||||
loop Until minimum signatures reached
|
||||
DestChain->>DestChain: Collect minter signatures
|
||||
end
|
||||
|
||||
DestChain->>DestChain: Mint equivalent tokens
|
||||
DestChain->>User: Transfer minted tokens
|
||||
DestChain-->>BridgingContract: Confirm minting and transfer
|
||||
|
||||
BridgingContract->>User: Notify successful bridge
|
||||
else Transaction invalid
|
||||
BridgingContract->>User: Notify failed bridge
|
||||
end
|
||||
```
|
||||
|
||||
|
||||
88
collections/projectinca/specs_blockchain/code_contract.md
Normal file
88
collections/projectinca/specs_blockchain/code_contract.md
Normal file
@ -0,0 +1,88 @@
|
||||
#### smart contract code mgmt
|
||||
|
||||
each contract is registered in the database and has following properties:
|
||||
|
||||
- contract_address = unique id, cannot be changed
|
||||
- contract_hash = the latest code for this contract (is a hash of the sorted directory, so everyone can check)
|
||||
- contract_link = where can the code be found
|
||||
- upgrade_multisig_accounts e.g. 9 accounts need to sign for an upgrade of the code
|
||||
- upgrade_multisig_min_signature e.g. 6 need to sign
|
||||
|
||||
### Example Record
|
||||
|
||||
```json
|
||||
{
|
||||
"smart_contract_code_mgmt": {
|
||||
"contract_address": "0x1234567890123456789012345678901234567890",
|
||||
"contract_hash": "0xabcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890",
|
||||
"contract_link": "https://github.com/freeflowuniverse/mysmartcontract/src",
|
||||
"upgrade_multisig_accounts": [
|
||||
"0x1111111111111111111111111111111111111111",
|
||||
"0x2222222222222222222222222222222222222222",
|
||||
"0x3333333333333333333333333333333333333333",
|
||||
"0x4444444444444444444444444444444444444444",
|
||||
"0x5555555555555555555555555555555555555555",
|
||||
"0x6666666666666666666666666666666666666666",
|
||||
"0x7777777777777777777777777777777777777777",
|
||||
"0x8888888888888888888888888888888888888888",
|
||||
"0x9999999999999999999999999999999999999999"
|
||||
],
|
||||
"upgrade_multisig_min_signature": 6
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
How does it work
|
||||
|
||||
- someone asks for upgrade e.g. location can have a branch inside
|
||||
- the hash needs to be specified
|
||||
- the upgraders will get a request to look at the code
|
||||
- once the code is audited and approved they will sign the upgrade transaction
|
||||
- once majority is achieved the record will be changed to show the new location & hash
|
||||
- now the execution engines in the field (the validators of the blockchain) will see there is new code, they will build the code themselves, verify the hash, if all ok then the new code will be used, otherwise the smart contract will stop to operate
|
||||
|
||||
## implementation detail
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Proposer
|
||||
participant UpgradeSystem
|
||||
participant MultisigAccounts
|
||||
participant BlockchainDB
|
||||
participant Validators
|
||||
|
||||
Proposer->>UpgradeSystem: Propose upgrade (new hash & location)
|
||||
UpgradeSystem->>BlockchainDB: Retrieve current contract info
|
||||
BlockchainDB-->>UpgradeSystem: Return contract info
|
||||
|
||||
UpgradeSystem->>MultisigAccounts: Notify of upgrade request
|
||||
|
||||
loop Until upgrade_multisig_min_signature reached or all reviewed
|
||||
MultisigAccounts->>MultisigAccounts: Review and audit new code
|
||||
alt Code approved
|
||||
MultisigAccounts->>UpgradeSystem: Sign upgrade transaction
|
||||
else Code rejected
|
||||
MultisigAccounts->>UpgradeSystem: Reject upgrade
|
||||
end
|
||||
end
|
||||
|
||||
alt Sufficient signatures collected
|
||||
UpgradeSystem->>BlockchainDB: Update contract record (new hash & link)
|
||||
BlockchainDB-->>UpgradeSystem: Confirm update
|
||||
UpgradeSystem->>Validators: Notify of contract update
|
||||
|
||||
loop For each Validator
|
||||
Validators->>Validators: Fetch and build new code
|
||||
Validators->>Validators: Verify code hash
|
||||
alt Hash verified
|
||||
Validators->>Validators: Deploy new code
|
||||
else Hash mismatch
|
||||
Validators->>Validators: Stop contract operation
|
||||
end
|
||||
end
|
||||
|
||||
UpgradeSystem->>Proposer: Notify upgrade success
|
||||
else Insufficient signatures or rejected
|
||||
UpgradeSystem->>Proposer: Notify upgrade failure
|
||||
end
|
||||
```
|
||||
158
collections/projectinca/specs_blockchain/generator_token.md
Normal file
158
collections/projectinca/specs_blockchain/generator_token.md
Normal file
@ -0,0 +1,158 @@
|
||||
# Generator Token
|
||||
|
||||
A Generator token is a token which mints tokens over a certain period following well defined properties and the tokens are then sent fo the destination_address as specified by the owner
|
||||
|
||||
### Properties
|
||||
|
||||
The properties:
|
||||
|
||||
- name e.g. INCAG in case of ThreeFold
|
||||
- owner_address, is the person who owns the generator token
|
||||
- dest_token_name e.g. INCA in case of ThreeFold
|
||||
- dest_chain e.g. SOLANA
|
||||
- dest_address, where the minted tokens will be sent too
|
||||
- owner can change the dest address
|
||||
- description
|
||||
- code = smart contract related
|
||||
- smart_contract_addr: address of the smart contract
|
||||
- this smart contract executes the code as needed to execute this contract, this smart contract will ask the minter code to create tokens as needed.
|
||||
- minter related
|
||||
- minter_contract_addr: address of the smart contract which generates the tokens (minting)
|
||||
- info about minter, the minter creates the Generator Tokens as well as the Destination Tokens
|
||||
- source related
|
||||
- can be empty if there is no source token
|
||||
- source_token_name e.g. TFT (can also be address)
|
||||
- source_token_chain e.g. STELLAR
|
||||
- sourcetable
|
||||
- list of the sourcetokens (amount, src_address) e.g. 1000 TFT was input of this INCAG token.
|
||||
- mintingtable
|
||||
- nr of $dest_token_name e.g. INCA to be minted over which time
|
||||
- is a table with date + minting amount of our specific "dest_token" which is generated (minted) over time
|
||||
- acceleration_table
|
||||
- accelerated minting rules
|
||||
- per row we find a date, oracleaddress, minimum, maximum, nrminted e.g. if oracle about INCA price is higher than 0.5 USD, there is no max, then we mint e.g. 1000 INCA on a specific Date
|
||||
the INCAG
|
||||
- if not specified then the owner of the INCAG can freely define the destination
|
||||
- clawback (stop the minting and if any incoming tokens, send them back to the originator)
|
||||
- clawback_multisig_accounts e.g. accounts which can instantiate a clawback
|
||||
- clawback_multisig_min_signature e.g. nr of signatures needed for clawback
|
||||
- clawback_address (*is only relevant if the originating tokens come from somewhere*)
|
||||
- when clawback is executed it basically means the generator token no longer exists
|
||||
|
||||
|
||||
### Example Generator Token
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "INCAG",
|
||||
"owner_address": "0x9876543210987654321098765432109876543210",
|
||||
"dest_token_name": "INCA",
|
||||
"dest_chain": "SOLANA",
|
||||
"dest_address": "0x9876543210987654321098765432109876543210",
|
||||
"description": "INCA-G token for generating INCA (Internet Capacity token) over time",
|
||||
"smart_contract_addr": "0x1234567890123456789012345678901234567890",
|
||||
"minter_contract_addr": "0x1234567890123456789012345678901234567890",
|
||||
"source": {
|
||||
"source_token_name": "TFT",
|
||||
"source_token_chain": "STELLAR",
|
||||
"sourcetable": [
|
||||
{
|
||||
"amount": 1000,
|
||||
"src_address": "GDFZ...STELLAR...ADDRESS"
|
||||
}
|
||||
]
|
||||
},
|
||||
"mintingtable": [
|
||||
{
|
||||
"date": "2026-08-17",
|
||||
"minting_amount": 100
|
||||
},
|
||||
{
|
||||
"date": "2026-09-17",
|
||||
"minting_amount": 200
|
||||
},
|
||||
{
|
||||
"date": "2026-10-17",
|
||||
"minting_amount": 700
|
||||
}
|
||||
],
|
||||
"acceleration_table": [
|
||||
{
|
||||
"date": "2025-08-17",
|
||||
"oracle_address": "0xABCDEF1234567890ABCDEF1234567890ABCDEF12",
|
||||
"minimum": 0.5,
|
||||
"maximum": null,
|
||||
"nr_minted": 500
|
||||
},
|
||||
{
|
||||
"date": "2025-12-17",
|
||||
"oracle_address": "0xABCDEF1234567890ABCDEF1234567890ABCDEF12",
|
||||
"minimum": 0.75,
|
||||
"maximum": null,
|
||||
"nr_minted": 500
|
||||
}
|
||||
],
|
||||
"clawback": {
|
||||
"clawback_multisig_accounts": [
|
||||
"GABC...STELLAR...ADDRESS1",
|
||||
"GDEF...STELLAR...ADDRESS2",
|
||||
"GHIJ...STELLAR...ADDRESS3",
|
||||
"GKLM...STELLAR...ADDRESS4",
|
||||
"GNOP...STELLAR...ADDRESS5"
|
||||
],
|
||||
"clawback_multisig_min_signature": 3
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Owner
|
||||
participant GeneratorToken
|
||||
participant SmartContract
|
||||
participant MinterContract
|
||||
participant DestChain
|
||||
participant Oracle
|
||||
|
||||
Owner->>GeneratorToken: Create Generator Token
|
||||
GeneratorToken->>SmartContract: Initialize
|
||||
|
||||
loop For each date in mintingtable
|
||||
SmartContract->>SmartContract: Check current date
|
||||
alt Current date matches mintingtable date
|
||||
SmartContract->>MinterContract: Request minting
|
||||
MinterContract->>DestChain: Mint tokens
|
||||
DestChain->>Owner: Transfer minted tokens to dest_address
|
||||
end
|
||||
end
|
||||
|
||||
loop For each date in acceleration_table
|
||||
SmartContract->>SmartContract: Check current date
|
||||
alt Current date matches acceleration_table date
|
||||
SmartContract->>Oracle: Request price data
|
||||
Oracle-->>SmartContract: Return price data
|
||||
alt Price meets acceleration criteria
|
||||
SmartContract->>MinterContract: Request accelerated minting
|
||||
MinterContract->>DestChain: Mint additional tokens
|
||||
DestChain->>Owner: Transfer additional minted tokens to dest_address
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
alt Clawback initiated
|
||||
Owner->>GeneratorToken: Request clawback
|
||||
loop Until clawback_multisig_min_signature reached
|
||||
GeneratorToken->>GeneratorToken: Collect signatures
|
||||
end
|
||||
GeneratorToken->>SmartContract: Execute clawback
|
||||
SmartContract->>SmartContract: Stop minting
|
||||
alt Source tokens exist
|
||||
SmartContract->>Owner: Return source tokens
|
||||
end
|
||||
SmartContract->>GeneratorToken: Deactivate Generator Token
|
||||
end
|
||||
|
||||
Owner->>GeneratorToken: Change dest_address
|
||||
GeneratorToken->>SmartContract: Update dest_address
|
||||
```
|
||||
@ -0,0 +1,71 @@
|
||||
|
||||
# Liquidity Pool Contract
|
||||
|
||||
|
||||
> [More info see here](liquidity_pool.md)
|
||||
|
||||
|
||||
## some further specs
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
Start((Start)) --> Register[Register Participant]
|
||||
Register --> SetPreferences[Set Price Preferences]
|
||||
SetPreferences --> JoinPool[Join Liquidity Pool]
|
||||
|
||||
JoinPool --> Transaction{Transaction?}
|
||||
Transaction -->|Buy| BuyProcess[Buy Process]
|
||||
Transaction -->|Sell| SellProcess[Sell Process]
|
||||
Transaction -->|No Transaction| Monitor[Monitor Pool]
|
||||
|
||||
BuyProcess --> CheckLiquidity{Sufficient Liquidity?}
|
||||
CheckLiquidity -->|Yes| ExecuteBuy[Execute Buy]
|
||||
CheckLiquidity -->|No| QueueRequest[Queue Buy Request]
|
||||
|
||||
SellProcess --> CheckPriceLimit{Meet Price Limit?}
|
||||
CheckPriceLimit -->|Yes| ExecuteSell[Execute Sell]
|
||||
CheckPriceLimit -->|No| WaitForPrice[Wait for Price Change]
|
||||
|
||||
ExecuteBuy --> UpdateAccounts[Update All Accounts]
|
||||
ExecuteSell --> UpdateAccounts
|
||||
UpdateAccounts --> CalculateDiscount[Calculate TFGrid Discount]
|
||||
|
||||
QueueRequest --> Monitor
|
||||
WaitForPrice --> Monitor
|
||||
|
||||
Monitor --> AggregateStats[Aggregate Daily Stats]
|
||||
AggregateStats --> PublishStats[Publish Aggregate Stats]
|
||||
|
||||
PublishStats --> CheckLockup{Lockup Period?}
|
||||
CheckLockup -->|Yes| ContinueHolding[Continue Holding]
|
||||
CheckLockup -->|No| Withdraw{Withdraw?}
|
||||
|
||||
Withdraw -->|Yes| ProcessWithdrawal[Process Withdrawal]
|
||||
Withdraw -->|No| Transaction
|
||||
|
||||
ProcessWithdrawal --> UpdateAccounts
|
||||
ContinueHolding --> Transaction
|
||||
|
||||
subgraph "Liquidity Pool Operations"
|
||||
Transaction
|
||||
BuyProcess
|
||||
SellProcess
|
||||
CheckLiquidity
|
||||
CheckPriceLimit
|
||||
ExecuteBuy
|
||||
ExecuteSell
|
||||
QueueRequest
|
||||
WaitForPrice
|
||||
UpdateAccounts
|
||||
Monitor
|
||||
AggregateStats
|
||||
PublishStats
|
||||
end
|
||||
|
||||
classDef process fill:#f9f,stroke:#333,stroke-width:2px;
|
||||
classDef decision fill:#ff9,stroke:#333,stroke-width:2px;
|
||||
classDef start fill:#9f9,stroke:#333,stroke-width:2px;
|
||||
class Start start;
|
||||
class Transaction,CheckLiquidity,CheckPriceLimit,Withdraw,CheckLockup decision;
|
||||
class Register,SetPreferences,JoinPool,BuyProcess,SellProcess,ExecuteBuy,ExecuteSell,QueueRequest,WaitForPrice,UpdateAccounts,CalculateDiscount,Monitor,AggregateStats,PublishStats,ContinueHolding,ProcessWithdrawal process;
|
||||
```
|
||||
79
collections/projectinca/specs_blockchain/minting_contract.md
Normal file
79
collections/projectinca/specs_blockchain/minting_contract.md
Normal file
@ -0,0 +1,79 @@
|
||||
|
||||
# Minting Contract
|
||||
|
||||
The minting can happen over multiple blockchains.
|
||||
|
||||
- name e.g. INCAG in case of ThreeFold
|
||||
- description
|
||||
- address, the address of this minting contract
|
||||
- dest_token_name e.g. INCA in case of ThreeFold
|
||||
- dest_chain e.g. SOLANA
|
||||
- link (link to more info about the minter)
|
||||
- multisig_accounts e.g. 9 accounts need to sign
|
||||
- multisig_min_signature e.g. 6 need to sign, this is for releasing the generated token INCA
|
||||
- smart_contract_addr: address of the smart contract
|
||||
|
||||
```json
|
||||
{
|
||||
"minting_contract": {
|
||||
"name": "INCAG",
|
||||
"description": "Minting contract for INCA (Internet Capacity) tokens",
|
||||
"address": "0xABCDEF1234567890ABCDEF1234567890ABCDEF12",
|
||||
"dest_token_name": "INCA",
|
||||
"dest_chain": "SOLANA",
|
||||
"link": "https://example.com/incag_minter_info",
|
||||
"multisig_accounts": [
|
||||
"0x1111111111111111111111111111111111111111",
|
||||
"0x2222222222222222222222222222222222222222",
|
||||
"0x3333333333333333333333333333333333333333",
|
||||
"0x4444444444444444444444444444444444444444",
|
||||
"0x5555555555555555555555555555555555555555",
|
||||
"0x6666666666666666666666666666666666666666",
|
||||
"0x7777777777777777777777777777777777777777",
|
||||
"0x8888888888888888888888888888888888888888",
|
||||
"0x9999999999999999999999999999999999999999"
|
||||
],
|
||||
"multisig_min_signature": 6,
|
||||
"smart_contract_addr": "0xABCDEF1234567890ABCDEF1234567890ABCDEF12",
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## implementation diagram
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Requester
|
||||
participant MintingContract
|
||||
participant MultisigAccounts
|
||||
participant SmartContract
|
||||
participant DestChain
|
||||
|
||||
Requester->>MintingContract: Request token minting
|
||||
MintingContract->>SmartContract: Verify request
|
||||
|
||||
alt Request is valid
|
||||
SmartContract->>MultisigAccounts: Initiate signature collection
|
||||
|
||||
loop Until multisig_min_signature reached
|
||||
MultisigAccounts->>MultisigAccounts: Collect signatures
|
||||
end
|
||||
|
||||
MultisigAccounts-->>SmartContract: Return collected signatures
|
||||
|
||||
alt Sufficient signatures collected
|
||||
SmartContract->>DestChain: Mint tokens (dest_token_name)
|
||||
DestChain-->>SmartContract: Confirm minting
|
||||
SmartContract-->>MintingContract: Minting successful
|
||||
MintingContract-->>Requester: Tokens minted successfully
|
||||
else Insufficient signatures
|
||||
SmartContract-->>MintingContract: Minting failed (insufficient signatures)
|
||||
MintingContract-->>Requester: Minting request denied
|
||||
end
|
||||
else Request is invalid
|
||||
SmartContract-->>MintingContract: Invalid request
|
||||
MintingContract-->>Requester: Minting request denied (invalid)
|
||||
end
|
||||
|
||||
```
|
||||
93
collections/projectinca/specs_blockchain/oracle_contract.md
Normal file
93
collections/projectinca/specs_blockchain/oracle_contract.md
Normal file
@ -0,0 +1,93 @@
|
||||
# Oracle Contracts
|
||||
|
||||
An oracle can get information from the world as well as from other blockchains e.g. price of a token
|
||||
|
||||
- name e.g. TFT_PRICE
|
||||
- description
|
||||
- address, the address of this oracle contract
|
||||
- link (link to more info about the oracle)
|
||||
- multisig_accounts e.g. 9 accounts need to sign
|
||||
- multisig_min_signature e.g. 6 need to sign, this is for releasing the generated token INCA
|
||||
- smart_contract_addr: address of the smart contract
|
||||
- period_measure: period in seconds we will measure
|
||||
- period_calc: period in seconds over which we will calculate min, max and avg (is rolling window)
|
||||
|
||||
## default methods
|
||||
|
||||
- get(name:string) -> fl64
|
||||
- will return minimum, maximum, average over the specified period _calc
|
||||
|
||||
|
||||
## Example record in Blockchain DB
|
||||
|
||||
```json
|
||||
{
|
||||
"oracle_contract": {
|
||||
"name": "TFT_PRICE",
|
||||
"description": "Oracle contract for retrieving TFT token price",
|
||||
"address": "0xFEDCBA9876543210FEDCBA9876543210FEDCBA98",
|
||||
"link": "https://example.com/tft_price_oracle_info",
|
||||
"multisig_accounts": [
|
||||
"0x1111111111111111111111111111111111111111",
|
||||
"0x2222222222222222222222222222222222222222",
|
||||
"0x3333333333333333333333333333333333333333",
|
||||
"0x4444444444444444444444444444444444444444",
|
||||
"0x5555555555555555555555555555555555555555",
|
||||
"0x6666666666666666666666666666666666666666",
|
||||
"0x7777777777777777777777777777777777777777",
|
||||
"0x8888888888888888888888888888888888888888",
|
||||
"0x9999999999999999999999999999999999999999"
|
||||
],
|
||||
"multisig_min_signature": 6,
|
||||
"smart_contract_addr": "0xABCDEF1234567890ABCDEF1234567890ABCDEF12",
|
||||
"period_measure": 3600,
|
||||
"period_calc": 86400
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
### Implementation
|
||||
|
||||
```mermaid
|
||||
|
||||
sequenceDiagram
|
||||
participant ExternalSource
|
||||
participant OracleContract
|
||||
participant MultisigAccounts
|
||||
participant SmartContract
|
||||
participant BlockchainDB
|
||||
participant Requester
|
||||
|
||||
loop Every period_measure (3600 seconds)
|
||||
ExternalSource->>OracleContract: Provide TFT price data
|
||||
OracleContract->>SmartContract: Validate and process data
|
||||
|
||||
alt Data is valid
|
||||
SmartContract->>MultisigAccounts: Request signatures
|
||||
|
||||
loop Until multisig_min_signature reached
|
||||
MultisigAccounts->>MultisigAccounts: Collect signatures
|
||||
end
|
||||
|
||||
MultisigAccounts-->>SmartContract: Return collected signatures
|
||||
|
||||
alt Sufficient signatures collected
|
||||
SmartContract->>BlockchainDB: Store price data
|
||||
BlockchainDB-->>SmartContract: Confirm storage
|
||||
else Insufficient signatures
|
||||
SmartContract->>OracleContract: Discard data (insufficient signatures)
|
||||
end
|
||||
else Data is invalid
|
||||
SmartContract->>OracleContract: Reject invalid data
|
||||
end
|
||||
end
|
||||
|
||||
Requester->>OracleContract: Call get("TFT_PRICE")
|
||||
OracleContract->>SmartContract: Process request
|
||||
SmartContract->>BlockchainDB: Retrieve price data for period_calc (86400 seconds)
|
||||
BlockchainDB-->>SmartContract: Return price data
|
||||
SmartContract->>SmartContract: Calculate min, max, avg
|
||||
SmartContract-->>OracleContract: Return calculated values
|
||||
OracleContract-->>Requester: Provide min, max, avg price
|
||||
```
|
||||
198
collections/projectinca/specs_blockchain/ourworld_blockchain.md
Normal file
198
collections/projectinca/specs_blockchain/ourworld_blockchain.md
Normal file
@ -0,0 +1,198 @@
|
||||
|
||||
|
||||
# OurWorld Blockchain
|
||||
|
||||
This blockchain has been implemented for the Digital FreeZone Company OurWorld of Zanzibar.
|
||||
|
||||
The blockchain has unique properties
|
||||
|
||||
- run by trusted parties who have strong agreement with the OurWorld Digital Freezone
|
||||
- it can run very flexible smart contracts
|
||||
- the smart contracts can interact with multiple blockchains at once
|
||||
- every execution is logged for in a blockchain log system which can not be modified (WORM)
|
||||
- the result of actions are records being changed in a normal SQL relational database
|
||||
- certain fields of this database can be private
|
||||
- the consensus mechanism is very strong
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph Validator1
|
||||
CE1[Consensus Engine]
|
||||
EE1[Execution Engine]
|
||||
BE1[Build Engine]
|
||||
BL1[Blockchain Logger]
|
||||
|
||||
subgraph Storage1
|
||||
BD1[(Blockchain DB)]
|
||||
ZS1[Zero-Stor]
|
||||
ZDB1[(Zero-DB)]
|
||||
end
|
||||
end
|
||||
|
||||
subgraph Validator2
|
||||
CE2[Consensus Engine]
|
||||
EE2[Execution Engine]
|
||||
BE2[Build Engine]
|
||||
BL2[Blockchain Logger]
|
||||
|
||||
subgraph Storage2
|
||||
BD2[(Blockchain DB)]
|
||||
ZS2[Zero-Stor]
|
||||
ZDB2[(Zero-DB)]
|
||||
end
|
||||
end
|
||||
|
||||
subgraph Validator3
|
||||
CE3[Consensus Engine]
|
||||
EE3[Execution Engine]
|
||||
BE3[Build Engine]
|
||||
BL3[Blockchain Logger]
|
||||
|
||||
subgraph Storage3
|
||||
BD3[(Blockchain DB)]
|
||||
ZS3[Zero-Stor]
|
||||
ZDB3[(Zero-DB)]
|
||||
end
|
||||
end
|
||||
|
||||
RPC[RPC Requests] --> CE1
|
||||
RPC --> CE2
|
||||
RPC --> CE3
|
||||
|
||||
CE1 <--> CE2
|
||||
CE2 <--> CE3
|
||||
CE3 <--> CE1
|
||||
|
||||
CE1 --> EE1
|
||||
CE1 --> BE1
|
||||
BE1 --> EE1
|
||||
EE1 --> BD1
|
||||
EE1 --> BL1
|
||||
BL1 --> ZS1
|
||||
ZS1 --> ZDB1
|
||||
|
||||
CE2 --> EE2
|
||||
CE2 --> BE2
|
||||
BE2 --> EE2
|
||||
EE2 --> BD2
|
||||
EE2 --> BL2
|
||||
BL2 --> ZS2
|
||||
ZS2 --> ZDB2
|
||||
|
||||
CE3 --> EE3
|
||||
CE3 --> BE3
|
||||
BE3 --> EE3
|
||||
EE3 --> BD3
|
||||
EE3 --> BL3
|
||||
BL3 --> ZS3
|
||||
ZS3 --> ZDB3
|
||||
|
||||
classDef validator1 fill:#f9f,stroke:#333,stroke-width:2px;
|
||||
classDef validator2 fill:#ff9,stroke:#333,stroke-width:2px;
|
||||
classDef validator3 fill:#9ff,stroke:#333,stroke-width:2px;
|
||||
classDef storage fill:#bbf,stroke:#333,stroke-width:2px;
|
||||
|
||||
class Validator1 validator1;
|
||||
class Validator2 validator2;
|
||||
class Validator3 validator3;
|
||||
class Storage1,Storage2,Storage3 storage;
|
||||
```
|
||||
|
||||
### Initial Smart Contracts
|
||||
|
||||
- [Generator Tokens](projectinca/generator_token.md)
|
||||
- [Minting Contract](projectinca/minting_contract.md)
|
||||
- [Oracle Contract](projectinca/oracle_contract.md)
|
||||
- [Code Contract](projectinca/code_contract.md)
|
||||
- [Bridging Contract](projectinca/bridging_contract.md)
|
||||
|
||||
### Implementation Details
|
||||
|
||||
Implemented using consensus engine which has unique properties
|
||||
|
||||
- super flexible execution is possible (flexible contracts as above)
|
||||
- each execution is logged and auditable afterwards
|
||||
- secure by consensus ring (which is a custom made blockchain based on Tendermint)
|
||||
- the data is stored in relational database (postgresql)
|
||||
- the consensus ring guarantees correct execution and consensus over the databases
|
||||
- each validator has 1 database
|
||||
- the validators can talk to multiple blockchains e.g. Stellar, ...
|
||||
|
||||
### the blockchain has following components
|
||||
|
||||
- Validator
|
||||
- is a node which runs all the components as described below
|
||||
- Consensus_Engine
|
||||
- every RPC (remote procedure call) request goes over the engine
|
||||
- the engine make sure all RPC's are executed in order and reach all Validator
|
||||
- Blockchain_DB = Blockchain Database
|
||||
- a SQL Database
|
||||
- Blockchain_Logger = logger whichs records all changes, logs, ... and stores them on the Zero-Stor
|
||||
- Zero-Stor = is a key valye stor which stores everything in containers which are encoded, encrypted, compressed and dispersed to multiple Zero-DB's
|
||||
- Zero-Stor will check validity of the data and makes sure data can never be corrupted nor lost
|
||||
- the Zero-Stor is used in WORM mode which means Write One Time, read Many Times
|
||||
- Zero-DB = the storage engine behind which stores the info on the storage device
|
||||
- Build_Engine:
|
||||
- builds the code (if needed) to run by the Execution_Engine
|
||||
- will check the hashes and signatures to make sure the right code is run
|
||||
- Execution_Engine
|
||||
- there can be more than one and they can even be created in multiple languages
|
||||
- they will execute all the logic (the smart contracts)
|
||||
- only if all execution engines have the same result the the consensus engine will agree with the RPC request and the transaction is valid.
|
||||
|
||||
|
||||
## Consensus Engine
|
||||
|
||||
Is a proper proof of stake blockchain
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
Start((Start)) --> Proposer
|
||||
Proposer -->|Create block| ProposeBlock[Propose Block]
|
||||
ProposeBlock --> Broadcast[Broadcast to Network]
|
||||
Broadcast --> Validators[Validators Receive]
|
||||
|
||||
Validators --> ValidCheck{Valid Block?}
|
||||
ValidCheck -->|Yes| Prevote[Prevote]
|
||||
ValidCheck -->|No| NilPrevote[Nil Prevote]
|
||||
|
||||
Prevote --> CollectPrevotes[Collect Prevotes]
|
||||
NilPrevote --> CollectPrevotes
|
||||
|
||||
CollectPrevotes --> PrevoteCheck{2/3+ Prevotes?}
|
||||
PrevoteCheck -->|Yes| Precommit[Precommit]
|
||||
PrevoteCheck -->|No| NextRound[Next Round]
|
||||
|
||||
Precommit --> CollectPrecommits[Collect Precommits]
|
||||
|
||||
CollectPrecommits --> PrecommitCheck{2/3+ Precommits?}
|
||||
PrecommitCheck -->|Yes| Commit[Commit Block]
|
||||
PrecommitCheck -->|No| NextRound
|
||||
|
||||
Commit --> Finalize[Finalize Block]
|
||||
Finalize --> End((End))
|
||||
|
||||
NextRound --> Start
|
||||
|
||||
subgraph Consensus Engine
|
||||
Proposer
|
||||
ProposeBlock
|
||||
Broadcast
|
||||
Validators
|
||||
ValidCheck
|
||||
Prevote
|
||||
NilPrevote
|
||||
CollectPrevotes
|
||||
PrevoteCheck
|
||||
Precommit
|
||||
CollectPrecommits
|
||||
PrecommitCheck
|
||||
Commit
|
||||
Finalize
|
||||
end
|
||||
|
||||
classDef process fill:#f9f,stroke:#333,stroke-width:2px;
|
||||
classDef decision fill:#ff9,stroke:#333,stroke-width:2px;
|
||||
class Proposer,ProposeBlock,Broadcast,Validators,Prevote,NilPrevote,CollectPrevotes,Precommit,CollectPrecommits,Commit,Finalize process;
|
||||
class ValidCheck,PrevoteCheck,PrecommitCheck decision;
|
||||
```
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 169 KiB After Width: | Height: | Size: 169 KiB |
@ -1,61 +0,0 @@
|
||||
|
||||
|
||||
|
||||
## TOKENS
|
||||
|
||||
There might be 2 tokens
|
||||
|
||||
> TODO: to complete
|
||||
|
||||
### INCA Token
|
||||
|
||||
> INCA = INternet CApacity (is the token of buying/selling Internet/Cloud Capacity)
|
||||
|
||||
- 4 billion INCA will be created
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
### INCA-G (to be discussed)
|
||||
|
||||
> INCA-G = INCA Generator (is a token generating INCA typically over 48 months)
|
||||
|
||||
An INCA-G token generates INCA over a certain period. INCA stands for Internet Capacity token, enabling individuals to buy/sell Internet & Cloud Capacity.
|
||||
|
||||
We can analogize the generation of Cloud/Internet capacity to the generation of electricity. In this analogy, INCA is akin to the KWH token, while INCA-G is comparable to the KW token (representing capacity to generate electricity).
|
||||
|
||||
INCA-G tokens are unique and come with metadata specifying how INCA will be generated. This metadata outlines the generation schedule of INCA over the next X months.
|
||||
|
||||
!!wiki.include page:'projectinca:inca.md'
|
||||
|
||||
## How to Acquire the INCA-G Token?
|
||||
|
||||
> TODO: to be discussed
|
||||
|
||||
### Round 1: SwissBorg & TF Cooperative
|
||||
|
||||
1 INCA-G token generates 15,000 INCA over 48 months.
|
||||
|
||||
1 INCA-G can be bought:
|
||||
|
||||
- From SwissBorg for 500 CHF
|
||||
- Crypto-enabled bank in Switzerland
|
||||
- Maximum sold is 5,000 INCA-G tokens
|
||||
- with TFT which is the founder creator currency of the current grid
|
||||
- There will never be more than 1 billion TFT
|
||||
- 1 INCA-G token costs 10,000 TFT (\*)
|
||||
|
||||
> (\*) The pricing will depend on price of TFT at that moment.
|
||||
|
||||
### Round 2: **A**frica and Latin **A**merica INCA-G Tokens (AA)
|
||||
|
||||
> TODO: to be discussed
|
||||
|
||||
1 INCA-G AA Token generates 10,000 INCA over 48 months.
|
||||
|
||||
AA stands for Africa and latin America
|
||||
|
||||
- From SwissBorg for *TBD* CHF.
|
||||
|
||||
The incoming funds will be used to generate Cloud & Internet capacity in these regions, <br>which are serious growth regions in the world.
|
||||
|
||||
33
collections/projectinca/tokenomics/incag.md
Normal file
33
collections/projectinca/tokenomics/incag.md
Normal file
@ -0,0 +1,33 @@
|
||||
|
||||
|
||||
|
||||
There are multiple tokens in the ThreeFold ecosystem:
|
||||
|
||||
|
||||
- INCA = INternet CApacity (is the token of buying/selling Internet/Cloud Capacity)
|
||||
- INCAG = INCA Generator token, mints token over time
|
||||
- TFT = the creator token for grid 3.x, can convert at any time in INCAG Token
|
||||
|
||||
- 4 billion INCA will be created
|
||||
|
||||
|
||||
### INCA-G
|
||||
|
||||
> INCA-G = INCA Generator (is a token generating INCA)
|
||||
|
||||
An INCA-G token generates INCA over a certain period. INCA stands for Internet Capacity token, enabling individuals to buy/sell Internet & Cloud Capacity.
|
||||
|
||||
We can analogize the generation of Cloud/Internet capacity to the generation of electricity. In this analogy, INCA is akin to the KWH token, while INCA-G is comparable to the KW token (representing capacity to generate electricity).
|
||||
|
||||
INCA-G tokens are unique and come with metadata specifying how INCA will be generated. This metadata outlines the generation schedule of INCA over the next X months.
|
||||
|
||||
|
||||
### How to Acquire the INCA-G Token?
|
||||
|
||||
- converting from TFT
|
||||
- buying from a pool as generated by a farming pool (others farm on your behalf)
|
||||
- as an investor
|
||||
|
||||
### Properties of a Generator Token
|
||||
|
||||
> see [Generator Token](generator_token.md)
|
||||
@ -13,7 +13,9 @@ flowchart TD
|
||||
C -->|10%| F[Validators<br>Commercial Partners]
|
||||
```
|
||||
|
||||
Farmers are rewarded by 80% of the fees as paid by the Cloud Users, the user pays in Fiat Currency. The marketplace automatically converts the FIAT currency to TFT and INCA as is needed to fullfil the request.
|
||||
- Farmers are rewarded by 80% of the fees as paid by the Cloud Users, the user pays in Fiat Currency. The marketplace automatically converts the FIAT currency to TFT and INCA as is needed to fullfil the request.
|
||||
- The Farmers also get rewards from Farming Reward pools to get to expansion faster, 40m Tokens are granted per month to farmers based on their location, uptime or other achievements.
|
||||
- The [Liquidity Pool](liquidity_pool.md) is a central concept from our tokenomics. Vested tokens can only be unvested through the liquidity pool and the liquidity pool has mechanisms built in the help protect volatility in the price.
|
||||
|
||||
## Distribution
|
||||
|
||||
@ -37,8 +39,8 @@ option = {
|
||||
{ value: 1475, name: 'Farmers ThreeFold Grid 4+' },
|
||||
{ value: 300, name: 'Community Rewards + Promotion' },
|
||||
{ value: 300, name: 'Grants' },
|
||||
{ value: 200, name: 'Liquidity / Dex' },
|
||||
{ value: 400, name: 'Investors' },
|
||||
{ value: 150, name: 'Liquidity / Dex' },
|
||||
{ value: 450, name: 'Investors' },
|
||||
{ value: 100, name: 'ThreeFold Dubai Holdings' },
|
||||
{ value: 500, name: 'Team' },
|
||||
],
|
||||
@ -64,9 +66,9 @@ There can never be more than 4 Billion Tokens.
|
||||
- Promotion of the TFGrid, Marketing Activities, ...
|
||||
- 7.5% Community grants
|
||||
- We want to expand and build our project in first place together with the community
|
||||
- 5% for liquidity providing (DEX, marketmakers, ...)
|
||||
- 3.8% for liquidity providing (DEX, marketmakers, ...)
|
||||
- 2.5% ThreeFold Dubai holdings (held by the company who manages and promotes the grid)
|
||||
- 10% For Investors
|
||||
- 11.3% For Investors
|
||||
- 12.5% for team and contributor rewards
|
||||
|
||||
> Do note this table is still under deliberation and can change
|
||||
@ -87,3 +89,18 @@ This leads to following maximum unlocking table
|
||||
The vesting accelerates if the token price gets above 0.5 USD, for each 0.1 USD above additional 10% unlocks into the INCA Liquidity pool.
|
||||
Thanks to the liquidity pool the price remains stable even if people decide to chose the option to unvest faster.
|
||||
|
||||
## TFT to INCA
|
||||
|
||||
TFT holders can go to INCA based on following rules
|
||||
|
||||
- There is 1-1 relationship between TFT and INCA
|
||||
- TFT can only go to INCA not back.
|
||||
- There is vesting implemented over 2 years
|
||||
- X TFT becomes an INCAG with following properties
|
||||
- X INCA, to be minted over 2 years, equal parts per month
|
||||
- acelleration unlock rules are:
|
||||
- 10% when INCA token hits 0.5 USD longer than 1 month avg out
|
||||
- 10% when INCA token hits 0.6 USD longer than 1 month avg out
|
||||
- goes on, 10% per 0.1 USD higher price
|
||||
|
||||
More details see [INCA Generator, is like an NFT generating INCA over time](incag.md) token
|
||||
|
||||
@ -17,7 +17,6 @@ ThreeFold Grid (TFGrid) is a foundational layer which can be used by any web2/3
|
||||
## The Project Purpose
|
||||
|
||||
The purpose is to deliver a new infrastructure layer to build a new internet on top of. This layer is sovereign, more scalable, peer-to-peer and co-owned. The project delivers network, compute and storage to anyone who needs it for their own usecases.
|
||||
[See the high level tech description.](tech:key_innovations.md)
|
||||
|
||||
## Who Benefits The Most From The TFGrid's Capabilities?
|
||||
|
||||
|
||||
@ -4,50 +4,44 @@
|
||||
<h1>All Trust</h1>
|
||||
|
||||
- [A Paradigm of Trust](#a-paradigm-of-trust)
|
||||
- [Guardian Circles: Humans Ensuring Oversight](#guardian-circles-humans-ensuring-oversight)
|
||||
- [Everyone can be a Service Provider / Merchant](#everyone-can-be-a-service-provider--merchant)
|
||||
- [IOUs Enable Trusted Transactions = mutual credit](#ious-enable-trusted-transactions--mutual-credit)
|
||||
- [Farmers: Investors in Shared Internet/Cloud Infrastructure](#farmers-investors-in-shared-internetcloud-infrastructure)
|
||||
- [ThreeFold Farmers: Investors in Shared Internet/Cloud Infrastructure](#threefold-farmers-investors-in-shared-internetcloud-infrastructure)
|
||||
- [Shared Internet, Network \& AI Services](#shared-internet-network--ai-services)
|
||||
- [Guardian Circles: Humans Ensuring Oversight](#guardian-circles-humans-ensuring-oversight)
|
||||
|
||||
***
|
||||
|
||||
## A Paradigm of Trust
|
||||
|
||||
What if instead of distrusting others, we embrace a paradigm of trust?
|
||||
|
||||
Our system is built on this principle of trust between all participants.
|
||||
|
||||
Each actor is represented by a digital assistant (based on our Hero) who helps us to organize our collaboration, e-commerce flows, system administration tasks, ...
|
||||
|
||||
A Human chain rather than a Blockchain has the capability to build/maintain a good governance system.
|
||||
|
||||
## Guardian Circles: Humans Ensuring Oversight
|
||||
|
||||
- We believe a Guardian Circle has the potential to be as good as blockchain and more because Guardian Circles still provide human oversight over key decisions when needed, the bulk of transactions run automated.
|
||||
- Circles enact decisions when their 9-99 member nodes reach consensus. They manage treasuries, set policies, enable collaboration between regional grids, and more.
|
||||
- Their flexibility allows customization by each grid community based on local needs.
|
||||
- Circles leverage tools like multisig wallets, OurVerse consensus, and VLang DSLs to codify logic while retaining human checks and balances.
|
||||
|
||||
- What if instead of distrusting others, we embrace a paradigm of trust?
|
||||
- Our system is built on this principle of trust between all participants.
|
||||
- Each actor is represented by a digital assistant (based on our Hero) who helps us to organize our collaboration, e-commerce flows, system administration tasks, ...
|
||||
- An Automated Human Chain has the capability to build/maintain a good governance system with greater flexibility compared to Block Chain.
|
||||
|
||||
## Everyone can be a Service Provider / Merchant
|
||||
|
||||
- Farmers define their own pricing policies for their services based on usage. Costs may vary based on compute time, storage quantities, bandwidth, etc.
|
||||
- Pricing flexibility creates an open market. Farmers can price based on costs and desired profit margins. Consumers can shop for services based on performance, reliability, location, and price.
|
||||
- Farmers define their own pricing policies for their services based on usage.
|
||||
- Costs may vary based on compute time, storage quantities, bandwidth, etc.
|
||||
- Pricing flexibility creates an open market. Farmers can price based on costs and desired profit margins.
|
||||
- Consumers can shop for services based on performance, reliability, location, and price.
|
||||
|
||||
## IOUs Enable Trusted Transactions = mutual credit
|
||||
|
||||
- IOUs (I Owe You) represent agreements between farmers and consumers or for any other Internet / Hero Service
|
||||
- Both parties digitally sign each IOU, ensuring consensus on the transaction details.
|
||||
- At regular intervals, farmers submit IOUs to the Payment Bridges which are typically operated in a Digital Freezone. This aggregates IOUs and requests payment from the Hero's who represent the buyers.
|
||||
- Reputations are maintained on a decentralized ledfer to identify any bad actors abusing the system.
|
||||
- At regular intervals, farmers submit IOUs to the Payment Bridges which are typically operated in a Digital Freezone.
|
||||
- This aggregates IOUs and requests payment from the Hero's who represent the buyers.
|
||||
- Reputations are maintained on a decentralized ledger to identify any bad actors abusing the system.
|
||||
- **Fundamentally, the system relies on trust between participants.**
|
||||
|
||||
## Farmers: Investors in Shared Internet/Cloud Infrastructure
|
||||
## ThreeFold Farmers: Investors in Shared Internet/Cloud Infrastructure
|
||||
|
||||
- Farmers invest in hardware capacity for the Internet and Cloud (web gateways, 5G, etc). This capacity can be used for cloud workloads, AI, web2, web3 or hosting Hero's of project mycelium
|
||||
- Farmers invest in hardware capacity for the Internet and Cloud (web gateways, 5G, etc).
|
||||
- This capacity can be used for cloud workloads, AI, web2, web3 or hosting Hero's of project mycelium
|
||||
- Smaller farmers join a Farming Cooperative which helps with the commercial and operational duties if needed.
|
||||
- Farmers earn rewards when people purchase and utilize the infrastructure capacity they invested in. Their autonomous agents (hero) handle billing, monitoring, support issues, etc.
|
||||
- Farmers earn rewards when people purchase and utilize the infrastructure capacity they invested in.
|
||||
- Their autonomous agents (hero) handle billing, monitoring, support issues, etc.
|
||||
|
||||
## Shared Internet, Network & AI Services
|
||||
|
||||
@ -60,3 +54,10 @@ A Human chain rather than a Blockchain has the capability to build/maintain a go
|
||||
- Oracles for pricing, weather, ...
|
||||
- ...
|
||||
|
||||
|
||||
## Guardian Circles: Humans Ensuring Oversight
|
||||
|
||||
- We believe a Guardian Circle has the potential to be as good as blockchain and more because Guardian Circles still provide human oversight over key decisions when needed, the bulk of transactions run automated.
|
||||
- Circles enact decisions when their 9-99 member nodes reach consensus. They manage treasuries, set policies, enable collaboration between regional grids, and more.
|
||||
- Their flexibility allows customization by each grid community based on local needs.
|
||||
- Circles leverage tools like multisig wallets, OurVerse consensus, and VLang DSLs to codify logic while retaining human checks and balances.
|
||||
|
||||
@ -1,68 +0,0 @@
|
||||
# All Trust
|
||||
|
||||
What if in stead of not trusting anyone, we change the paradigm and we are going to trust everyone.
|
||||
|
||||
The TFGrid 4.0 system is built up out of actors, each actor is implemented inside a 3bot.
|
||||
|
||||
Some example actors
|
||||
|
||||
- farming: represents selected Grid Servives which run on top of 3nodes
|
||||
- farming cooperative: a cooperative of farmers, working on behalf of many farmers, who don't want to manage their own operation
|
||||
- 3node: manages one 3node and its operating system called ZOS
|
||||
- OurVerse node: manages a OurVerse node, OurVerse can be installed on deskopts, phones, ...
|
||||
- grid service: a grid service can be storage, compute, telecom, network services and can run on ZeroOS or OurVerse Node
|
||||
- grid consumer: an actor who works on behalf of a consumer of services of tfgrid, and helps the user to deploy and manage solutions deployed on the grid, payments are done on behalf of user
|
||||
|
||||
All of these actors work together to make a super scalable network of services which can support millions (if not billions) of consumers & service providers.
|
||||
|
||||
## Farmers
|
||||
|
||||
- Invest in TFNodes or other OurVerse based Services e.g. web gateway, telco service (5G,sms), ...
|
||||
- A Farmer invested in the required hardware to run these services.
|
||||
- A Farmer or Farming Cooperative will operationally run the services (set billing parameters, monitor environment, manage the networks, optionally give support, ...). Farming Cooperatives define how they distribute the margin they make to their members.
|
||||
- A Farmer can actively manage his own infrastructure or become part of a Farming Cooperative.
|
||||
- Farmers make profit thanks to people using their infrastructure and optionally monthly fixed farming rewards.
|
||||
|
||||
## Grid Services
|
||||
|
||||
In TFGrid 4.0 hundreds if eventually not thousands of services can be deployed inside the ecosystem of a new internet
|
||||
|
||||
How does it work?
|
||||
|
||||
- Grid Services track used capacity (e.g. bandwidth, storage, rpc requests), report this capacity to the relevant farming actor (or farming cooperative).
|
||||
- The Grid Consumer can talk to any of the Grid Services directly over OurVerse Reliable Message bus. The Consumer can ask for status reports, monitoring, or can ask for deployment of a serice or ask for a service request e.g. send SMS, send email, ask AI cloud ...
|
||||
- The Farming Actor will use their flexible pricing policies to define the price for the request or deployed capacity.
|
||||
- The Farming Actor will use OurVerse Pay to request payment (my means of request for IOU)
|
||||
|
||||
## IOU = I Owe You (Mutual Credit system)
|
||||
|
||||
- proofs of consumption & payment
|
||||
- farmers & consumers agree on the IOU (think about like a checque in the old banking days)
|
||||
- farmers & consumers sign both the IOU (done automatically by the actors using OurVerse for security)
|
||||
- the farmer will request the OurVerse Pay Bridge to do the payment at regular intervals e.g. once a day.
|
||||
- The OurVerse Pay Bridge is implemented inside a TFGrid Guardian Circle.
|
||||
- The OurVerse Pay Bridge will safely aggregate the IUO's and ask the relevant Consumer Actor to do the payment (in future their might be the notion of escrow accounts, so Consumers need to park money before asking services with a chosen Bridge).
|
||||
- Reputation of the Consumers is kept in the relevant TFGrid Guardian Circle, to make sure bad actors cannot cause harm.
|
||||
|
||||
## TFGrid Guardian Circle (our replace for blockchain)
|
||||
|
||||
- We believe in human chains, which acts and behaves as a blockchain but is directly linked to Humans rather than just a piece of code.
|
||||
- A Guardian Circle is a group of minimum 9 people (max 99).
|
||||
- Each person runs a 3bot who works on their behalf, so they don't have to do many tasks manually.
|
||||
- The Guradian owned 3bots communicate over OurVerse which takes care of security, encryption, consensus and reliable message delivery.
|
||||
- The OurVerse Concensus mechanism uses a derivate of Tendermint (see Kosmos blockchain ecosystem) to make sure that the consensus between the members is solid and done in time & space order.
|
||||
- A Guardian Circle can own one or more Treasury Wallets which are wallets of money blockchains (Ethereum, Stellar), these wallets use multisignature between all signers of a Guardian Circle.
|
||||
- The 3bots use VLang based DSL (Domain Specic coding Language) to describe the functionality.
|
||||
- All required actions are executing using 3Script (our own scripting language, super high level and easy), these 3scripts get executed by all members of the Guardian Circle, only if each Guardian TFNode comes to the exact same conclusion the action will be executed.
|
||||
- Typical actions as can be executed by a Guardian Circle
|
||||
- voting
|
||||
- roll up of IOU
|
||||
- validation of TFGrid status and auditing of capacity as provided by TFGrid
|
||||
- payments from Treasury as result of vote of roll up of IOU
|
||||
- pricing mechanism
|
||||
- billing for TfGrid Services
|
||||
- If needed manual actions (checks) can be done by the humans behind a Gurdian Circle e.g. validate a price chain.
|
||||
- Such a TFGrid Guardian Circle is ultra flexible, there can be millions of them and they can all work together, they can be made fully compatible with any chosen money blockchain or other financial institute.
|
||||
- Its very easy for developers to extend capabilities of a Guardian Circle (alternative to smart contracts on blockchain)
|
||||
|
||||
|
||||
@ -2,17 +2,14 @@
|
||||
|
||||
!!wiki.include page:'slice_intro.md'
|
||||
|
||||
An AI box is a unit of AI capacity (GPU or future TPU driven).
|
||||
|
||||
- An AI box is a unit of AI capacity (GPU or in the future TPU).
|
||||
- The mininal GPU supported for now is a Nvidia 4090 or comparable
|
||||
|
||||
An AI box can be launched in our Zero-OS and can enable any possible AI workload.
|
||||
- An AI box can be launched in our Zero-OS and can enable any possible AI workload.
|
||||
|
||||
## AI Hour (AH)
|
||||
|
||||
AI hour (AH) is like a kwatth unit for electricty: it represents a AI Slice being used for 1h and billed as such.
|
||||
|
||||
INCA Hosts (our cloud providers) can price the AI Hour themselves in a chosen currency.
|
||||
- AI hour (AH) is like a kwatth unit for electricty: it represents a AI Slice being used for 1h and billed as such.
|
||||
- ThreeFold Farmers can price the AI Hour in a chosen currency.
|
||||
|
||||
## AI Slice Properties
|
||||
|
||||
@ -20,7 +17,7 @@ The service provider (hoster) defines the following properties per AI Slice:
|
||||
|
||||
- Type of GPU
|
||||
- Price per hour
|
||||
- Discounts if used for longer periods & if renter has large amount of TFT in wallet
|
||||
- Maximum Discount (based on participation in Liquidity Pool and/or longer renting periods)
|
||||
- Max bandwidth
|
||||
- Min bandwidth (min 1 mbit/sec)
|
||||
- Cost per GB bandwidth if any
|
||||
@ -29,5 +26,4 @@ The service provider (hoster) defines the following properties per AI Slice:
|
||||
- If linked to Hosting Pool (company giving support on the machines)
|
||||
- Location & type of location
|
||||
|
||||
Each AI Slice has unique ID and can be looked at through a portal (or found).
|
||||
|
||||
|
||||
@ -4,12 +4,9 @@
|
||||
|
||||
## Cloud Slice
|
||||
|
||||
A Cloud Slice is a unit of compute, fast storage and memory.
|
||||
There are unlimited different configurations of Cloud Slice.
|
||||
|
||||
A configuration of a machine defines the Cloud Slice which can be made.
|
||||
|
||||
A Cloud Slice can be aggregated to make a bigger Cloud Slice.
|
||||
- A Cloud Slice is a unit of compute, fast storage and memory.
|
||||
- A configuration of a machine defines the Cloud Slice which can be made.
|
||||
- A Cloud Slice can be aggregated to make a bigger Cloud Slice.
|
||||
|
||||
The default Cloud Slice has
|
||||
|
||||
@ -26,12 +23,12 @@ Terms
|
||||
|
||||
**Example a node with 64 GB or mem and 2 TB of SSD and 24 virtual cores.**
|
||||
|
||||
- 15 StorageSlices each:
|
||||
- 15 Cloud Slices each:
|
||||
- 4 GB of memory (60 GB total)
|
||||
- 120 GB of SSD capacity
|
||||
- 6.4 logical CPU core (oversubscription of 4, which means user can max use 4x CPU capacity if system allows)
|
||||
- when a user choses the full machine, then he/she will have reserved all StorageSlices capacity which means the machine is now dedicated reserved for the user, the hoster specifies the discount for this typically 50%. On a dedicated machine the user has full access to the GPU.
|
||||
- Min 2GB always needs to be left as buffer for memory and 10% of SSD capacity
|
||||
- when a user choses the full machine, then he/she will have reserved all Compute Slices capacity which means the machine is now dedicated reserved for the user, the hoster specifies the discount for this typically 50%.
|
||||
- Min 2GB always needs to be left as buffer for memory and 10% of SSD capacity on the host machine
|
||||
|
||||
How does it work:
|
||||
|
||||
@ -39,19 +36,18 @@ How does it work:
|
||||
|
||||
## Cloud Hour (CH)
|
||||
|
||||
A cloudhour is like a kwatth unit for electricty: it represents a Cloud Slice being used for 1h and billed as such.
|
||||
|
||||
INCA Hosts (our cloud providers) can price the CloudHour themselves in a chosen currency.
|
||||
- A Cloud Hour is like a kwatth unit for electricty: it represents a Cloud Slice being used for 1h and billed as such.
|
||||
- ThreeFold Farmers (Providers) can define the proce of the Cloud Hour in a chosen currency.
|
||||
|
||||
## Cloud Slice Properties
|
||||
|
||||
The service provider (hoster) defines the following properties per cloud box
|
||||
The ThreeFold Farmer defines the following properties per Cloud Slice
|
||||
|
||||
- Cost of 1 CloudHour (use the box for 1h)
|
||||
- Discounts if used for longer periods & if renter has large amount of TFT in wallet
|
||||
- Cost of 1 Cloud Hour (use the slice for 1h)
|
||||
- Maximum Discount (based on participation in Liquidity Pool and/or longer renting periods)
|
||||
- Min available storage in GB (min 50)
|
||||
- Max available storage in GB
|
||||
- Min passmark, max passmark
|
||||
- Min passmark, Max passmark
|
||||
- Max bandwidth
|
||||
- Min bandwidth (min 1 mbit/sec)
|
||||
- Cost per GB bandwidth
|
||||
@ -59,10 +55,9 @@ The service provider (hoster) defines the following properties per cloud box
|
||||
- Max additional storage
|
||||
- Max aggregation size (how many of the Cloud Slice can be combined)
|
||||
- Link to support site if any (find info about hoster and service capabilities)
|
||||
- If linked to Hosting Pool (company giving support on the machines)
|
||||
- Pub ip address possible or not (is option)
|
||||
- If linked to Farming Pool (company giving support on the machines)
|
||||
- Pub IP address possible or not (is option)
|
||||
- Link to monitoring page (if any)
|
||||
- Location & type of location
|
||||
|
||||
Each Cloud Slice has unique ID and can be looked at through a portal (or found).
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
|
||||
A Cloud, Storage or AI Slice is a part of a server/computer (3Node) which delivers a service which has well defined properties in relation to capacity, pricing, serviceabity, capabilities.
|
||||
|
||||
These Cloud, Storage or AI Slices can be bought by the ThreeFold Community through the TF Marketplace.
|
||||
These Cloud, Storage or AI Slices can be bought by the ThreeFold Community through the Marketplace.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## Storage Slice
|
||||
|
||||
A Storage Slice is a unit of ZDB storage as can be used as backend for Zero-Stor (our quantum safe storage system).
|
||||
A Storage Slice is a unit of ZDB storage (our key value stor) as can be used as backend for Zero-Stor (our quantum safe storage system).
|
||||
|
||||
The default Cloud Slice has:
|
||||
|
||||
@ -12,16 +12,15 @@ The default Cloud Slice has:
|
||||
|
||||
## Storage Hour (SH)
|
||||
|
||||
A storagehour is like a kwatth unit for electricty, it represents a Storage Slice being used for 1h and billed as such.
|
||||
|
||||
INCA Hosts (our cloud providers) can price the StorageHour themselves in a chosen currency.
|
||||
- A Storage Hour is like a kwatth unit for electricty, it represents a Storage Slice being used for 1h and billed as such.
|
||||
- ThreeFold Farmers can price the StorageHour themselves in a chosen currency.
|
||||
|
||||
## Storage Slice Properties
|
||||
|
||||
The service provider (hoster) defines the following properties per Storage Slice:
|
||||
|
||||
- Min size in GB (100GB+), max size
|
||||
- Discounts if used for longer periods & if renter has large amount of TFT in wallet
|
||||
- Maximum Discount (based on participation in Liquidity Pool and/or longer renting periods)
|
||||
- Max bandwidth
|
||||
- Min bandwidth (min 1 mbit/sec)
|
||||
- Cost per GB bandwidth
|
||||
@ -30,5 +29,4 @@ The service provider (hoster) defines the following properties per Storage Slice
|
||||
- If linked to Hosting Pool (company giving support on the machines)
|
||||
- Location & type of location
|
||||
|
||||
Each Storage Slice has unique ID and can be looked at through a portal (or found).
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user