Merge branch 'development' into development_update2

merge dev
This commit is contained in:
Mik-TF 2024-08-19 15:37:21 -04:00
commit ec07a2d4d3
33 changed files with 1116 additions and 566 deletions

View File

@ -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)

View File

@ -1,135 +0,0 @@
![alt text](theplan.png)
# 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

View File

@ -1,88 +0,0 @@
![alt text](theplan.png)
# 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.

View File

@ -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
![alt text](tokenomics.png)

View File

@ -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
![alt text](tokenomics.png)

View File

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

View File

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

View File

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

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

View File

@ -1,36 +1,36 @@
![](cloud_computing_with_liquidity_of_water_flow_aspect_19_12.png)
> 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.

View File

@ -1,7 +1,71 @@
![](cloud_computing_with_liquidity_of_water_flow_aspect_19_12.png)
# 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 participants 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.

View File

@ -7,7 +7,7 @@
![](img/inca_pricing.png)
- 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/)

View File

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

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

View 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
```

View 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
```

View 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
```

View File

@ -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;
```

View 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
```

View 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
```

View 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: 161 KiB

After

Width:  |  Height:  |  Size: 169 KiB

View File

@ -1,61 +0,0 @@
![](cloud_computing_with_liquidity_of_water_flow_aspect_19_12.png)
## 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.

View File

@ -0,0 +1,33 @@
![](cloud_computing_with_liquidity_of_water_flow_aspect_19_12.png)
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)

View File

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

View File

@ -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?

View File

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

View File

@ -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)

View File

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

View File

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

View File

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

View File

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