diff --git a/archived/bg/run_publish/references.md b/archived/bg/run_publish/references.md index 244fb1063bf..6b68f6d269b 100644 --- a/archived/bg/run_publish/references.md +++ b/archived/bg/run_publish/references.md @@ -207,8 +207,6 @@ SubQuery Projects are usually run in a javascript sandbox for security to limit Although this enhances security we understand that this limits the available functionality of your SubQuery. The `--unsafe` command imports all default javascript modules which greatly increases sandbox functionality with the tradeoff of decreased security. -**Note that the `--unsafe` command will prevent your project from being run in the SubQuery Network, and you must contact support if you want this command to be run with your project in [SubQuery's Managed Service](https://managedservice.subquery.network).** - ### --batch-size This flag allows you to set the batch size in the command line. If batch size is also set in the config file, this takes precedent. @@ -438,8 +436,6 @@ This flag enables certain aggregation functions including sum, max, avg and othe These are disabled by default due to the entity limit. -**Note that the `--unsafe` command will prevent your project from being run in the SubQuery Network, and you must contact support if you want this command to be run with your project in [SubQuery's Managed Services](https://managedservice.subquery.network).** - ### --port The port the subquery query service binds to. By default this is set to `3000` diff --git a/docs/build/mapping/algorand.md b/docs/build/mapping/algorand.md index 48bd96d8d3d..246ce73e676 100644 --- a/docs/build/mapping/algorand.md +++ b/docs/build/mapping/algorand.md @@ -61,7 +61,7 @@ const txGroup: AlgorandTransaction[] = tx.block.getTransactionsByGroup( ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/arbitrum.md b/docs/build/mapping/arbitrum.md index 2a2e1f761db..daf58069e7f 100644 --- a/docs/build/mapping/arbitrum.md +++ b/docs/build/mapping/arbitrum.md @@ -92,7 +92,7 @@ The above example assumes that the user has an ABI file named `erc20.json`, so t ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/avalanche.md b/docs/build/mapping/avalanche.md index 58218cc849e..35b5a082514 100644 --- a/docs/build/mapping/avalanche.md +++ b/docs/build/mapping/avalanche.md @@ -102,7 +102,7 @@ The above example assumes that the user has an ABI file named `erc20.json`, so t ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/bsc.md b/docs/build/mapping/bsc.md index d1e61e1e6c5..6058d4dbf8a 100644 --- a/docs/build/mapping/bsc.md +++ b/docs/build/mapping/bsc.md @@ -92,7 +92,7 @@ The above example assumes that the user has an ABI file named `erc20.json`, so t ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/concordium.md b/docs/build/mapping/concordium.md index 55731652f38..805d4137852 100644 --- a/docs/build/mapping/concordium.md +++ b/docs/build/mapping/concordium.md @@ -95,7 +95,7 @@ export async function handleSpecialEvent( ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/cosmos.md b/docs/build/mapping/cosmos.md index ae765defb7a..314bef60492 100644 --- a/docs/build/mapping/cosmos.md +++ b/docs/build/mapping/cosmos.md @@ -93,7 +93,7 @@ export async function handleMessage( ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/ethereum.md b/docs/build/mapping/ethereum.md index 6b1de4c3d14..cb748a1a6b6 100644 --- a/docs/build/mapping/ethereum.md +++ b/docs/build/mapping/ethereum.md @@ -88,7 +88,7 @@ The above example assumes that the user has an ABI file named `erc20.json`, so t ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/flare.md b/docs/build/mapping/flare.md index 56ebd892373..4aca0d71476 100644 --- a/docs/build/mapping/flare.md +++ b/docs/build/mapping/flare.md @@ -102,7 +102,7 @@ The above example assumes that the user has an ABI file named `erc20.json`, so t ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/gnosis.md b/docs/build/mapping/gnosis.md index 00ed94c2c98..cf0540d05a9 100644 --- a/docs/build/mapping/gnosis.md +++ b/docs/build/mapping/gnosis.md @@ -92,7 +92,7 @@ The above example assumes that the user has an ABI file named `erc20.json`, so t ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/near.md b/docs/build/mapping/near.md index b84fd202567..26bc1bb7cfc 100644 --- a/docs/build/mapping/near.md +++ b/docs/build/mapping/near.md @@ -108,7 +108,7 @@ Documents in [NEAR `JsonRpcProvider`](https://docs.near.org/tools/near-api-js/re ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/optimism.md b/docs/build/mapping/optimism.md index 51ea16ec5ee..623f2804768 100644 --- a/docs/build/mapping/optimism.md +++ b/docs/build/mapping/optimism.md @@ -92,7 +92,7 @@ The above example assumes that the user has an ABI file named `erc20.json`, so t ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/polkadot.md b/docs/build/mapping/polkadot.md index 63c8018771d..dfacd9cdaf3 100644 --- a/docs/build/mapping/polkadot.md +++ b/docs/build/mapping/polkadot.md @@ -95,7 +95,7 @@ async function handleEvmCall( ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do so, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/polygon.md b/docs/build/mapping/polygon.md index bb6fe2baa98..2226003bc39 100644 --- a/docs/build/mapping/polygon.md +++ b/docs/build/mapping/polygon.md @@ -92,7 +92,7 @@ The above example assumes that the user has an ABI file named `erc20.json`, so t ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/mapping/stellar.md b/docs/build/mapping/stellar.md index b6b376c6780..153a9625958 100644 --- a/docs/build/mapping/stellar.md +++ b/docs/build/mapping/stellar.md @@ -130,7 +130,7 @@ export async function handleEvent(event: SorobanEvent): Promise { ## Third-party Library Support - the Sandbox -SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is required to decentralise SubQuery in the SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. +SubQuery is deterministic by design, that means that each SubQuery project is guaranteed to index the same data set. This is a critical factor that is makes it possible to verify data in the decentralised SubQuery Network. This limitation means that in default configuration, the indexer is by default run in a strict virtual machine, with access to a strict number of third party libraries. **You can easily bypass this limitation however, allowing you to retrieve data from external API endpoints, non historical RPC calls, and import your own external libraries into your projects.** In order to do to, you must run your project in `unsafe` mode, you can read more about this in the [references](../../run_publish/references.md#unsafe-node-service). An easy way to do this while developing (and running in Docker) is to add the following line to your `docker-compose.yml`: diff --git a/docs/build/project-upgrades.md b/docs/build/project-upgrades.md index e420f178776..6a249dbbbe0 100644 --- a/docs/build/project-upgrades.md +++ b/docs/build/project-upgrades.md @@ -59,7 +59,6 @@ These are in addition to [Project Upgrade requirements](#requirements): ### Supported Migrations Supported migrations: - - Adding new entities - Removing entities (this is destructive) - Adding new fields (however only [nullable fields](./graphql.md#entities) are supported) @@ -70,9 +69,9 @@ Supported migrations: - Please note: When field update is detected, the original field column will be dropped (with all existing data in that field), and a new column will be created with the new field types. Other notes: - - Only supports PostgreSQL stores - Does not support adding new [foreign key relations](./graphql.md#entity-relationships) - Does not support enum creation or removal - Migrations will not succeed `--unfinalizedBlocks` is enabled - [GraphQL subscriptions](../run_publish/subscription.md) are not supported +- [Rewind](../run_publish/historical.md) will only be supported if the new schema does not drop any `fields` or `entity`. Note that [automated historical state tracking](../run_publish/historical.md) must be enabled to support rewind. diff --git a/docs/quickstart/quickstart.md b/docs/quickstart/quickstart.md index 1c15a807bd2..1ee08287daa 100644 --- a/docs/quickstart/quickstart.md +++ b/docs/quickstart/quickstart.md @@ -104,13 +104,13 @@ SubQuery supports various blockchain networks and provides a dedicated guide for Scaffolding saves time during SubQuery project creation by automatically generating typescript facades for EVM transactions, logs, and types. -When you are initalising a new project using the `subql init` command, SubQuery will give you the option to set up a scaffolded SubQuery project based on your JSON ABI. If you have select an compatiable network type (EVM), it will prompt +When you are initalising a new project using the `subql init` command, SubQuery will give you the option to set up a scaffolded SubQuery project based on your JSON ABI. If you select a compatible network type (EVM), it will prompt: ```shell ? Do you want to generate scaffolding with an existing abi contract? ``` -So for example, If I wanted to create the [Ethereum Gravatar indexer](./quickstart_chains/ethereum-gravatar.md), I would download the Gravity ABI contract JSON from [Etherscan](https://etherscan.io/address/0x2e645469f354bb4f5c8a05b3b30a929361cf77ec#code), save it as `Gravity.json`, and then run the following. +For example, to create the [Ethereum Gravatar indexer](./quickstart_chains/ethereum-gravatar.md), download the Gravity ABI contract JSON from [Etherscan](https://etherscan.io/address/0x2e645469f354bb4f5c8a05b3b30a929361cf77ec#code), save it as `Gravity.json`, and then run the following: ![Project Scaffolding EVM](/assets/img/build/project-scaffold-evm.png) diff --git a/docs/quickstart/quickstart_chains/ethereum-gravatar.md b/docs/quickstart/quickstart_chains/ethereum-gravatar.md index d57f93782a9..b658f31548e 100644 --- a/docs/quickstart/quickstart_chains/ethereum-gravatar.md +++ b/docs/quickstart/quickstart_chains/ethereum-gravatar.md @@ -16,7 +16,7 @@ The final code of this project can be found [here](https://github.com/subquery/e -We are indexing all Gravatars from the Gravatar contract, first you will need to import the contract abi defintion. You can copy the entire JSON and save as a file `./Gravity.json` in the `/abis` directory. +Since we are indexing all Gravatars from the Gravatar contract, the first step is to import the contract abi definition. Copy the entire JSON and save it as a file called `./Gravity.json` in the `/abis` directory. This section in the Project Manifest now imports all the correct definitions and lists the triggers that we look for on the blockchain when indexing. diff --git a/docs/run_publish/references.md b/docs/run_publish/references.md index 82f10a16546..b901aacd341 100644 --- a/docs/run_publish/references.md +++ b/docs/run_publish/references.md @@ -334,8 +334,6 @@ By extension, the `--unsafe` command on the SubQuery Node also allows: - making external requests (e.g. via Fetch to an external HTTP address or fs) - querying block data at any height via the unsafeApi -**Note that users must be on a paid plan to run projects with the `--unsafe` command (on the node service) within [SubQuery's Managed Service](https://managedservice.subquery.network). Additionally, it will prevent your project from being run in the SubQuery Network in the future.** - Also review the [--unsafe command on the query service](#unsafe-query-service). ### --version @@ -466,8 +464,6 @@ We use the [graphql-query-complexity](https://www.npmjs.com/package/graphql-quer **Boolean** - This flag enables certain aggregation functions including sum, max, avg and others. Read more about this feature [here](../run_publish/aggregate.md). These are disabled by default for database performance reasons. -**Note that you must be on a paid plan if you would like to run projects with the `--unsafe` command (on the query service) within [SubQuery's Managed Service](https://managedservice.subquery.network). Additionally, it will prevent your project from being run in the SubQuery Network in the future.** - ### --version **Boolean** - This displays the current version. diff --git a/docs/subquery_network/node_operators/indexers/become-an-indexer.md b/docs/subquery_network/node_operators/indexers/become-an-indexer.md index 2674495a46b..35ba71fffc7 100644 --- a/docs/subquery_network/node_operators/indexers/become-an-indexer.md +++ b/docs/subquery_network/node_operators/indexers/become-an-indexer.md @@ -74,8 +74,8 @@ This will overwrite the existing docker-compose.yml file. Always use the latest | Service | Version Tag | | :-------------------------------------------------------------------------------------------------- | :---------- | -| [subquerynetwork/indexer-coordinator](https://hub.docker.com/r/subquerynetwork/indexer-coordinator) | `v1.2.0` | -| [subquerynetwork/indexer-proxy](https://hub.docker.com/r/subquerynetwork/indexer-proxy) | `v1.2.0` | +| [subquerynetwork/indexer-coordinator](https://hub.docker.com/r/subquerynetwork/indexer-coordinator) | `v1.4.10` | +| [subquerynetwork/indexer-proxy](https://hub.docker.com/r/subquerynetwork/indexer-proxy) | `v1.3.9` | ::: warning Important diff --git a/docs/subquery_network/node_operators/indexers/indexer-security-guide.md b/docs/subquery_network/node_operators/indexers/indexer-security-guide.md index ead24d518e1..f778f52efbf 100644 --- a/docs/subquery_network/node_operators/indexers/indexer-security-guide.md +++ b/docs/subquery_network/node_operators/indexers/indexer-security-guide.md @@ -54,6 +54,14 @@ Expose the port 8000 allow Only My IP (change 192.168.10.1 to your IP Address): ```bash ufw route allow proto tcp from 192.168.10.1 to 172.18.0.28 port 8000 comment 'allow indexer_coordinator 8000/tcp indexer_services' ``` +:::tip Tip + +You can find IPAddress Mapping ex `172.18.0.10`, `172.18.0.28` with +``` +docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' +``` + +::: Show the current firewall allowed forward rules @@ -103,7 +111,7 @@ sudo apt install -y nginx ```shell # docker-compose.yml proxy: - image: subquerynetwork/indexer-proxy:v1.2.0 + image: subquerynetwork/indexer-proxy:v1.3.9 container_name: indexer_proxy restart: always ports: diff --git a/docs/subquery_network/publish.md b/docs/subquery_network/publish.md index 94f086176d0..6e4d921983a 100644 --- a/docs/subquery_network/publish.md +++ b/docs/subquery_network/publish.md @@ -15,14 +15,13 @@ The SubQuery Network is the future of web3 infrastructure, it allows you to comp - Infinitely scalable - As your user base grows, more indexers will serve you data allowing you to infinitely scale without interruption. - Seamless transition - We're here to help you migrate, and we've made it easy to integrate in your dApps with our network client SDKs. -**With the SubQuery Kepler Network, you can now go to your community and say with confidence** **_"our dApp is truly decentralised"._** +**With the SubQuery Kepler Network, you can now go to your community and say with confidence _"our dApp is truly decentralised"._** ## Prerequisites for your project running on Kepler -1. Your project must be running in safe mode, you cannot be running it with the `--unsafe` [command line argument](../run_publish/references.md#unsafe-node-service). -2. Kepler does not support GraphQL subscriptions, so you can't enable the `--subscription` [command line argument](../run_publish/subscription.md) -3. Your client application (the one that will query data from Kepler) must be able to run a JS library -4. Your project can generate stable proof of indexing results. This means you should avoid: +1. Kepler does not support GraphQL subscriptions, so you can't enable the `--subscription` [command line argument](../run_publish/subscription.md) +2. Your client application (the one that will query data from Kepler) must be able to run a JS library +3. Your project can generate stable proof of indexing results. This means you should avoid: 1. Random ordered DB operations, e.g. avoid using `Promise.all()` in your mapping functions. 2. Introducing external data dependent on runtime, e.g. initialising a new current date using `new Date()`. diff --git a/docs/subquery_network/token/tokenomics-old.md b/docs/subquery_network/token/tokenomics-old.md new file mode 100644 index 00000000000..fc97cc20a1e --- /dev/null +++ b/docs/subquery_network/token/tokenomics-old.md @@ -0,0 +1,29 @@ +# Tokenomics + +:::warning +Please note that everything below is still subject to change. +::: + +Total Supply: The total supply will be 10 Billion SQT tokens. + +Inflation: The inflation is expected to be ~2% per annum. This will be used to help the SubQuery Foundation bootstrap the network by supporting Node Operators during the early launch phase where Consumers numbers will still be growing. + +![token allocation](/assets/img/network/token_allocation.png) + +From the start, SubQuery has been focused on building value within the community and this aim continues with the largest allocation of tokens (~51%) being apportioned to the Community, SubQuery Foundation, and for the public sale. + +The Foundation, which is expected to be established in late 2023, will administer the future governance and growth of the ecosystem and the ownership of the SubQuery Network will come under the SubQuery Foundation initially. This large allocation also includes consideration for future investment into the development and operations of the Network, and key ecosystem growth drivers. This will include tools such as grants and ecosystem incentives/events as well as other marketing activities including bug bounties and mainnet incentives. + +Early investors in both the Seed, Series A, and Series B rounds have a combined allocation of ~29%. In the case of our seed investors, SubQuery is grateful for their early vision and commitment to build the initial phase of SubQuery. Following on from this, growth was accelerated with the support of Series A and B investors who allowed the project to accelerate to the next level.cce + +Finally, the SubQuery Team and Launch Partners have been allocated 20% of the token supply in return for their tireless dedication and contribution in building and promoting the project over multiple years of hard work. + +## Vesting schedule + +We have designed our vesting schedule to demonstrate the commitment of various stakeholders. The graphic below illustrates the planned release of the SQT tokens to each participant over time culminating in the full circulation of tokens occurring 5 years (60 months) after launch. + +![vesting schedule](/assets/img/network/vesting_schedule.png) + +The vesting schedules for each participant has been designed to create long-term value for the project and generate confidence to token-holders. Perhaps most significantly, the core team will have a 24 month lock-up period which will then vest over another 24 months while some Public Sale participants can freely use the utility of their token upon launch. + +The Foundation and Community will have approximately 30% of the allocation unlocked from the start to meet the operational needs of launching and promoting mainnet with the rest of the allocation vesting gradually over 5 years. diff --git a/docs/subquery_network/token/tokenomics.md b/docs/subquery_network/token/tokenomics.md index fc97cc20a1e..75ee721d405 100644 --- a/docs/subquery_network/token/tokenomics.md +++ b/docs/subquery_network/token/tokenomics.md @@ -1,29 +1,21 @@ # Tokenomics :::warning -Please note that everything below is still subject to change. +Please note that detailed tokenomics will be [released closer to the token sale](https://subquery.foundation/sale) ::: Total Supply: The total supply will be 10 Billion SQT tokens. Inflation: The inflation is expected to be ~2% per annum. This will be used to help the SubQuery Foundation bootstrap the network by supporting Node Operators during the early launch phase where Consumers numbers will still be growing. -![token allocation](/assets/img/network/token_allocation.png) +From the start, SubQuery has been focused on building value within the community and this aim continues with the largest allocation of tokens on launch being apportioned to the Community, SubQuery Foundation, and for the public sale. -From the start, SubQuery has been focused on building value within the community and this aim continues with the largest allocation of tokens (~51%) being apportioned to the Community, SubQuery Foundation, and for the public sale. - -The Foundation, which is expected to be established in late 2023, will administer the future governance and growth of the ecosystem and the ownership of the SubQuery Network will come under the SubQuery Foundation initially. This large allocation also includes consideration for future investment into the development and operations of the Network, and key ecosystem growth drivers. This will include tools such as grants and ecosystem incentives/events as well as other marketing activities including bug bounties and mainnet incentives. - -Early investors in both the Seed, Series A, and Series B rounds have a combined allocation of ~29%. In the case of our seed investors, SubQuery is grateful for their early vision and commitment to build the initial phase of SubQuery. Following on from this, growth was accelerated with the support of Series A and B investors who allowed the project to accelerate to the next level.cce - -Finally, the SubQuery Team and Launch Partners have been allocated 20% of the token supply in return for their tireless dedication and contribution in building and promoting the project over multiple years of hard work. +The [SubQuery Foundation](https://subquery.foundation), will administer the future governance and growth of the ecosystem and the ownership of the SubQuery Network will come under the SubQuery Foundation initially. This large allocation also includes consideration for future investment into the development and operations of the Network, and key ecosystem growth drivers. This will include tools such as grants and ecosystem incentives/events as well as other marketing activities including bug bounties and mainnet incentives. ## Vesting schedule -We have designed our vesting schedule to demonstrate the commitment of various stakeholders. The graphic below illustrates the planned release of the SQT tokens to each participant over time culminating in the full circulation of tokens occurring 5 years (60 months) after launch. - -![vesting schedule](/assets/img/network/vesting_schedule.png) +We have designed our vesting schedule to demonstrate the commitment of various stakeholders. The planned release of SQT tokens after launch will take time culminating in the full circulation of tokens at least 4 years (48 months) after launch. -The vesting schedules for each participant has been designed to create long-term value for the project and generate confidence to token-holders. Perhaps most significantly, the core team will have a 24 month lock-up period which will then vest over another 24 months while some Public Sale participants can freely use the utility of their token upon launch. +The vesting schedules for each participant has been designed to create long-term value for the project and generate confidence to token-holders. Perhaps most significantly, the core team will have a vesting period of 48 months while some Public Sale participants can freely use the utility of their token upon launch. -The Foundation and Community will have approximately 30% of the allocation unlocked from the start to meet the operational needs of launching and promoting mainnet with the rest of the allocation vesting gradually over 5 years. +The Foundation and Community will have portion of their allocation unlocked from the start to meet the operational needs of launching and promoting mainnet with the rest of the allocation vesting gradually over subsequent years.