Merge branch 'development' into development_update2
merge dev
This commit is contained in:
Mik-TF
@@ -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: 161 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
|
||||
|
||||
Reference in New Issue
Block a user