...
This commit is contained in:
parent
d93f748bfb
commit
3c0082a005
@ -8,6 +8,14 @@
|
|||||||
- [Decentralization 4.x](projectinca/decentralization4.md)
|
- [Decentralization 4.x](projectinca/decentralization4.md)
|
||||||
- [TF Validators 4.x](projectinca/TFValidatorCluster.md)
|
- [TF Validators 4.x](projectinca/TFValidatorCluster.md)
|
||||||
- [All Trust](tfgrid4/alltrust.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)
|
- [**Technology**](projectinca/technology.md)
|
||||||
- [Project Info](projectinca/project_info.md)
|
- [Project Info](projectinca/project_info.md)
|
||||||
- [About Us](tfgrid3/who_are_we.md)
|
- [About Us](tfgrid3/who_are_we.md)
|
||||||
|
|||||||
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.
|
||||||
|
|
||||||
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;
|
||||||
|
```
|
||||||
@ -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,11 +13,9 @@ flowchart TD
|
|||||||
C -->|10%| F[Validators<br>Commercial Partners]
|
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 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.
|
||||||
|
|
||||||
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
|
## 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.
|
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.
|
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
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user