tfgrid/info_tfgrid
30
3
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases Activity

...

Browse Source
This commit is contained in:
despiegk 2024-08-17 13:22:25 +02:00
parent d93f748bfb
commit 3c0082a005
13 changed files with 941 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
books/projectinca/SUMMARY.md
View File

@ -8,6 +8,14 @@
- [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)

29
collections/projectinca/funding/incag_funding.md Normal file
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.

34
collections/projectinca/specs_blockchain/blockchain.md Normal file
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.

132
collections/projectinca/specs_blockchain/bridging_contract.md Normal file
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
```

88
collections/projectinca/specs_blockchain/code_contract.md Normal file
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
```

158
collections/projectinca/specs_blockchain/generator_token.md Normal file
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
```

71
collections/projectinca/specs_blockchain/liquidity_pool_contract.md Normal file
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;
```

79
collections/projectinca/specs_blockchain/minting_contract.md Normal file
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
```

93
collections/projectinca/specs_blockchain/oracle_contract.md Normal file
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
```

198
collections/projectinca/specs_blockchain/ourworld_blockchain.md Normal file
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;
```

61
collections/projectinca/tokenomics/inca_a.md
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.

33
collections/projectinca/tokenomics/incag.md Normal file
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)

23
collections/projectinca/tokenomics/tokens.md
View File

@ -13,11 +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.
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.
- 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
@ -91,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