diff --git a/.github/workflows/build-docs.yml b/.github/workflows/build-docs.yml new file mode 100644 index 000000000..909564563 --- /dev/null +++ b/.github/workflows/build-docs.yml @@ -0,0 +1,28 @@ +name: 'build-docs' +on: + push: + branches: ['main'] + pull_request: + branches: ['main'] + workflow_dispatch: + +defaults: + run: + shell: bash + +jobs: + build-docs: + runs-on: ubuntu-latest + steps: + - name: Trigger mintlify workflow + if: github.event_name == 'push' + uses: actions/github-script@v7 + with: + github-token: ${{ secrets.DOCS_CHILDREN_ACTIONS_TRIGGER_TOKEN }} + script: | + await github.rest.actions.createWorkflowDispatch({ + owner: 'mintlify-onboarding', + repo: 'skip', + workflow_id: 'mintlify-action.yml', + ref: 'main', + }); diff --git a/docs/incentivize-slashing.mdx b/docs/incentivize-slashing.mdx new file mode 100644 index 000000000..11d40008c --- /dev/null +++ b/docs/incentivize-slashing.mdx @@ -0,0 +1,88 @@ +--- +title: 'Incentivization & Slashing' +--- + +## 🤝 Validators and Slinky[​](#-validators-and-slinky 'Direct link to heading') + +✅ **Validators are the lifeblood of Slinky operation** - Slinky is a restaking product. This means it reuses all available network stake of a protocol to secure oracle operation. To do this, validators need to run the infrastructure required for Slinky to operate. + +✅ **Validators do this by running the Slinky Sidecar** - Slinky comes with a highly optimized and reliable piece of software called the Sidecar, which validators run in tandem with chain binaries to fetch prices safely and reliably. + +✅ **Validators benefit from running Slinky** - Validators can (should!) be rewarded for doing more for the chains they operate on. To accomplish this, Slinky can providet `fee-sharing` for validators who honestly operate the oracle. Fees can come from trading activity, inflation, or other mechanisms. + +✅ **Validators can be punished for misuse** - As they are with the consensus process, validators can be punished if they don't report prices or report incorrect prices. As long as validators follow the correct operation guides and act honestly, this should never happen. To ensure its accuracy, Slinky has two prebuilt mechanisms to enable slashing. + +## 💰 Reward Mechanism[​](#-reward-mechanism 'Direct link to heading') + +- When Slinky is integrated, it can assign per-block rewards to validators who operate it correctly. Correct operation means: + - posting prices reliably + - posting correct prices + +Rewards can come from various sources. The easiest to implement is an additional share of inflation yield. However, Slinky also can support sharing of trading-fees and any arbitrary source of revenue. + + + +We Share Everything + +Skip is dedicated to rewarding validators. For any fees a chain agrees to pay Skip for Slinky operation, we share 20% of this with the validators who operate it. + + + +With fee sharing, a fixed amount of fees is shared **per-block** to validators that correctly operate Slinky. + +- This means, if `$1000` was allocated for a certain block, and only 10 validators correctly operated Slinky that block, each validator would recieve an additional `$100` on top of their block rewards. + +Note that the Slinky reward is **additional** to normal validator commission. + +## 📉 Downtime slashing[​](#-downtime-slashing 'Direct link to heading') + +Slinky comes prebuilt with the optional `x/sla` module, which enforces a minimum Service-Level Agreement (SLA) on validators and is verified on-chain. + +See the code here: [https://github.com/skip-mev/slinky/tree/main/x/sla](https://github.com/skip-mev/slinky/tree/main/x/sla) + +The SLA module is designed to issue a (small) slash whenever a validator doesn't meet the uptime SLA for a specific price feed over a moving window of blocks. For example, with an SLA set to `80%` for a currency pair (e.g. `ETH/USDC`) over a block-window of `100`, then: + +- Every block, the `x/sla` module will find how many blocks in the past `100` each validator posted a price. +- If the percentage of blocks with prices is less than `80%`, then the validator is issued a small slash, proportional to their stake-weight. +- This process repeats until the validator is hitting the SLA. +- All these parameters, and the module itself, are initiated and set by governance. They are `OFF` by default. + +For new currency pairs, there is a "grace period" that can be configured in case validators need to make updates. Correct operation should be simple and heavily assisted by Skip: our intention is for downtime slashing to never impact any validator. + +Here is a rundown of the parameters for `x/sla`: + +- `MaximumViableWindow` (e.g. `100` ) + - This is the **window of blocks from head** that are evaluated to determine the uptime a validator had. + - For example, if set to `100` , the chain will look at every rolling window of `100` blocks to determine what percentage of the blocks the validator included a price update in their vote extension +- `ExpectedUptime` (e.g. `0.8` ) + - This is the percentage of uptime expected from all validators for a specific currency pair. This is evaluated every `Frequency` number of blocks, and the check will be roughly `ExpectedUptime >= (NumBlocksWithUpdates / MaximumViableWindow)` +- `SlashConstant` (e.g. `6` ) + - This is a constant amount of stake to slash every `Frequency` of blocks if the SLA is not being kept. + - In the case of SLA breach, the final amount to be slashed would be roughly `SlashConstant * StakeWeight(Validator)` . This would repeat every `Frequency` number of blocks that a specific validator breached the SLA +- `MinimumBlockUpdates` (e.g. `20` ) + - This is a safety mechanism to avoid double-slashing validators experiencing overall downtime. + - This value represents the minimum number of blocks within the `MaximumViableWindow` that a validator needs to sign before the overall Oracle SLA kicks in. + - For example, if in `100` blocks a validator was only live & signing for `10` , if the `MinimumBlockUpdates` is set to `20` , then the validator will not be subject to Oracle SLA slashing penalties. + - This is useful for preventing slashing around chain upgrades, when multiple validators might be offline at once. +- `Frequency` (e.g. `10` ) + - This is the number-of-block cadence when the SLA is checked for every validator for a specific price feed. + - This is mostly used to save computation resources - with a long `MaximumViableWindow` , we recommend increasing the `Frequency` to be upwards of `1` to save node resources. +- `MinStakeWeightToSlash` (e.g. `0.66` = 66% of stake weight) + - This is the minimum cumulative stake weight of validator price reports that is required before **any** slashing happens. This constitutes the "grace period" when a new currency pair is added and validators are getting set up. + +## ❌ Incorrect-price slashing[​](#-incorrect-price-slashing 'Direct link to heading') + +Downtime is serious, but not as serious as the network reporting incorrect prices. To prevent this, we have an exact replica of the **[ChainLink Town Crier](https://blog.chain.link/town-crier-and-chainlink/)** mechanism implemented as the `x/alerts` module. + +The `x/alerts` module does not slash individual mistakes or one-off errors. It activates when a permissionless `alerter` raises an alarm that the **entire network** has reported an incorrect price. The `alerter` has to post a `bond`, which is money they put up and legitimizes their claim. + +The `alert` raised is then forwarded to a `Concluder` network of trusted actors who can verify the validity of the `alert`. + +- If the `alert` is deemed invalid (i.e. the network's prices **were** close enough to the best-effort prices that the `concluder` network can fetch), then the `alerter` bond is seized and distributed to validators. +- If the `alert` is deemed valid (i.e. the network's prices are **very different** from the best-effort prices that the `concluder` network can fetch), then all participating validators in the incorrect price are slashed, and the alerter receives the slashed amount. + +This process is not designed to be even a remotely common occurrence. Slashing is a serious event, and the network should only slash in the event network prices are completely incorrect. As with the `x/sla` module, everything is defaulted to `OFF`, and all parameters are decided by governance. + +For chains that wish to enable `x/alerts`, please contact us so we can help you implement it correctly. It is a highly sophisticated and nuanced system. + +![](/images/slinky-town-crier.png) diff --git a/docs/slinky/overview.mdx b/docs/overview.mdx similarity index 100% rename from docs/slinky/overview.mdx rename to docs/overview.mdx diff --git a/docs/slinky/security-properties.mdx b/docs/security-properties.mdx similarity index 100% rename from docs/slinky/security-properties.mdx rename to docs/security-properties.mdx diff --git a/docs/slinky/incentivize-slashing.mdx b/docs/slinky/incentivize-slashing.mdx deleted file mode 100644 index 2197615e2..000000000 --- a/docs/slinky/incentivize-slashing.mdx +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: "Incentivization & Slashing" ---- -## 🤝 Validators and Slinky[​](#-validators-and-slinky "Direct link to heading") - -✅ **Validators are the lifeblood of Slinky operation** - Slinky is a restaking product. This means it reuses all available network stake of a protocol to secure oracle operation. To do this, validators need to run the infrastructure required for Slinky to operate. - -✅ **Validators do this by running the Slinky Sidecar** - Slinky comes with a highly optimized and reliable piece of software called the Sidecar, which validators run in tandem with chain binaries to fetch prices safely and reliably. - -✅ **Validators benefit from running Slinky** - Validators can (should!) be rewarded for doing more for the chains they operate on. To accomplish this, Slinky can providet `fee-sharing` for validators who honestly operate the oracle. Fees can come from trading activity, inflation, or other mechanisms. - -✅ **Validators can be punished for misuse** - As they are with the consensus process, validators can be punished if they don't report prices or report incorrect prices. As long as validators follow the correct operation guides and act honestly, this should never happen. To ensure its accuracy, Slinky has two prebuilt mechanisms to enable slashing. - -## 💰 Reward Mechanism[​](#-reward-mechanism "Direct link to heading") - -* When Slinky is integrated, it can assign per-block rewards to validators who operate it correctly. Correct operation means: - * posting prices reliably - * posting correct prices - -Rewards can come from various sources. The easiest to implement is an additional share of inflation yield. However, Slinky also can support sharing of trading-fees and any arbitrary source of revenue. - - -We Share Everything - -Skip is dedicated to rewarding validators. For any fees a chain agrees to pay Skip for Slinky operation, we share 20% of this with the validators who operate it. - - -With fee sharing, a fixed amount of fees is shared **per-block** to validators that correctly operate Slinky. - -* This means, if `$1000` was allocated for a certain block, and only 10 validators correctly operated Slinky that block, each validator would recieve an additional `$100` on top of their block rewards. - -Note that the Slinky reward is **additional** to normal validator commission. - -## 📉 Downtime slashing[​](#-downtime-slashing "Direct link to heading") - -Slinky comes prebuilt with the optional `x/sla` module, which enforces a minimum Service-Level Agreement (SLA) on validators and is verified on-chain. - -See the code here: [https://github.com/skip-mev/slinky/tree/main/x/sla](https://github.com/skip-mev/slinky/tree/main/x/sla) - -The SLA module is designed to issue a (small) slash whenever a validator doesn't meet the uptime SLA for a specific price feed over a moving window of blocks. For example, with an SLA set to `80%` for a currency pair (e.g. `ETH/USDC`) over a block-window of `100`, then: - -* Every block, the `x/sla` module will find how many blocks in the past `100` each validator posted a price. -* If the percentage of blocks with prices is less than `80%`, then the validator is issued a small slash, proportional to their stake-weight. -* This process repeats until the validator is hitting the SLA. -* All these parameters, and the module itself, are initiated and set by governance. They are `OFF` by default. - -For new currency pairs, there is a "grace period" that can be configured in case validators need to make updates. Correct operation should be simple and heavily assisted by Skip: our intention is for downtime slashing to never impact any validator. - -Here is a rundown of the parameters for `x/sla`: - -* `MaximumViableWindow` (e.g. `100` ) - * This is the **window of blocks from head** that are evaluated to determine the uptime a validator had. - * For example, if set to `100` , the chain will look at every rolling window of `100` blocks to determine what percentage of the blocks the validator included a price update in their vote extension -* `ExpectedUptime` (e.g. `0.8` ) - * This is the percentage of uptime expected from all validators for a specific currency pair. This is evaluated every `Frequency` number of blocks, and the check will be roughly `ExpectedUptime >= (NumBlocksWithUpdates / MaximumViableWindow)` -* `SlashConstant` (e.g. `6` ) - * This is a constant amount of stake to slash every `Frequency` of blocks if the SLA is not being kept. - * In the case of SLA breach, the final amount to be slashed would be roughly `SlashConstant * StakeWeight(Validator)` . This would repeat every `Frequency` number of blocks that a specific validator breached the SLA -* `MinimumBlockUpdates` (e.g. `20` ) - * This is a safety mechanism to avoid double-slashing validators experiencing overall downtime. - * This value represents the minimum number of blocks within the `MaximumViableWindow` that a validator needs to sign before the overall Oracle SLA kicks in. - * For example, if in `100` blocks a validator was only live & signing for `10` , if the `MinimumBlockUpdates` is set to `20` , then the validator will not be subject to Oracle SLA slashing penalties. - * This is useful for preventing slashing around chain upgrades, when multiple validators might be offline at once. -* `Frequency` (e.g. `10` ) - * This is the number-of-block cadence when the SLA is checked for every validator for a specific price feed. - * This is mostly used to save computation resources - with a long `MaximumViableWindow` , we recommend increasing the `Frequency` to be upwards of `1` to save node resources. -* `MinStakeWeightToSlash` (e.g. `0.66` = 66% of stake weight) - * This is the minimum cumulative stake weight of validator price reports that is required before **any** slashing happens. This constitutes the "grace period" when a new currency pair is added and validators are getting set up. - -## ❌ Incorrect-price slashing[​](#-incorrect-price-slashing "Direct link to heading") - -Downtime is serious, but not as serious as the network reporting incorrect prices. To prevent this, we have an exact replica of the **[ChainLink Town Crier](https://blog.chain.link/town-crier-and-chainlink/)** mechanism implemented as the `x/alerts` module. - -The `x/alerts` module does not slash individual mistakes or one-off errors. It activates when a permissionless `alerter` raises an alarm that the **entire network** has reported an incorrect price. The `alerter` has to post a `bond`, which is money they put up and legitimizes their claim. - -The `alert` raised is then forwarded to a `Concluder` network of trusted actors who can verify the validity of the `alert`. - -* If the `alert` is deemed invalid (i.e. the network's prices **were** close enough to the best-effort prices that the `concluder` network can fetch), then the `alerter` bond is seized and distributed to validators. -* If the `alert` is deemed valid (i.e. the network's prices are **very different** from the best-effort prices that the `concluder` network can fetch), then all participating validators in the incorrect price are slashed, and the alerter receives the slashed amount. - -This process is not designed to be even a remotely common occurrence. Slashing is a serious event, and the network should only slash in the event network prices are completely incorrect. As with the `x/sla` module, everything is defaulted to `OFF`, and all parameters are decided by governance. - -For chains that wish to enable `x/alerts`, please contact us so we can help you implement it correctly. It is a highly sophisticated and nuanced system. - -![](/images/slinky-town-crier.png) \ No newline at end of file diff --git a/docs/slinky/upcoming-features.mdx b/docs/upcoming-features.mdx similarity index 100% rename from docs/slinky/upcoming-features.mdx rename to docs/upcoming-features.mdx diff --git a/docs/slinky/validator-docs/quickstart.mdx b/docs/validator-docs/quickstart.mdx similarity index 65% rename from docs/slinky/validator-docs/quickstart.mdx rename to docs/validator-docs/quickstart.mdx index f7c8797fb..a305a4a6c 100644 --- a/docs/slinky/validator-docs/quickstart.mdx +++ b/docs/validator-docs/quickstart.mdx @@ -1,12 +1,14 @@ --- -title: "Quickstart" +title: 'Quickstart' --- + **Running Slinky? First step is to join our [Discord](https://discord.gg/amAgf9Z39w)** + -## Summary of Steps[​](#summary-of-steps "Direct link to heading") +## Summary of Steps[​](#summary-of-steps 'Direct link to heading') **Estimated Time**: 10 mins @@ -18,18 +20,18 @@ In this walkthrough, we'll be going through the 5 steps to set up Slinky. 4. Run the slinky sidecar. 5. Start the chain application. -## 1\. Install the Chain Binary ✅[​](#1-install-the-chain-binary- "Direct link to heading") +## 1. Install the Chain Binary ✅[​](#1-install-the-chain-binary- 'Direct link to heading') **🚨** Please visit the chain's validator-specific instructions to install and configure the node binary for the desired chain. For the purposes of this guide we'll use `testappd` as our example application binary, but it will be the same for any chain! -## 2\. Install the `slinky` binary ✅[​](#2-install-the-slinky-binary- "Direct link to heading") +## 2. Install the `slinky` binary ✅[​](#2-install-the-slinky-binary- 'Direct link to heading') You can install the slinky binary either by building from source or by downloading a pre-built binary. -* Install the latest binary from the **[releases page](https://github.com/skip-mev/slinky/releases)** -* Build from source by cloning the **[repo](https://github.com/skip-mev/slinky)** and running `make install` +- Install the latest binary from the **[releases page](https://github.com/skip-mev/slinky/releases)** +- Build from source by cloning the **[repo](https://github.com/skip-mev/slinky)** and running `make install` ```bash git clone git@github.com:skip-mev/slinky.git @@ -38,14 +40,15 @@ make install ``` - Slinky should now be in your path. Check to make sure with: -## 3\. Configure your Slinky Sidecar Process ✅[​](#3-configure-your-slinky-sidecar-process- "Direct link to heading") +## 3. Configure your Slinky Sidecar Process ✅[​](#3-configure-your-slinky-sidecar-process- 'Direct link to heading') + +- The provided releases include an `oracle.toml` file that you can use as a template for configuring your sidecar process. +- Alternatively, the repository contains the most up-to-date version of the config file **[here](https://github.com/skip-mev/slinky/blob/main/config/local/oracle.toml)** -* The provided releases include an `oracle.toml` file that you can use as a template for configuring your sidecar process. -* Alternatively, the repository contains the most up-to-date version of the config file **[here](https://github.com/skip-mev/slinky/blob/main/config/local/oracle.toml)** + danger **Make sure your config matches your version and chain!** @@ -53,9 +56,10 @@ danger The config file in the Slinky repository is regenerated every time a change is made to the sidecar. As such, it may contain additional config options that are not yet supported by earlier versions of the sidecar. Please use the config file from the release if you are unsure. Config files for the sidecar are generally chain-specific. Prefer to use the config file provided by the chain you're running for instead of the default config located in the repository. + -## 4\. Run the Slinky Sidecar ✅[​](#4-run-the-slinky-sidecar- "Direct link to heading") +## 4. Run the Slinky Sidecar ✅[​](#4-run-the-slinky-sidecar- 'Direct link to heading') You can run the slinky sidecar by running the following command: @@ -64,7 +68,6 @@ slinky oracle --config oracle.toml ``` - You can verify whether prices are being retrieved by running the following command: ```bash @@ -72,7 +75,6 @@ curl --request -x GET 'http://localhost:8080/slinky/v1/oracle/prices | jq .' ``` - You should see output similar to the following: ```json @@ -88,14 +90,12 @@ You should see output similar to the following: }, "timestamp": "2024-01-23T01:15:09.776890Z" } - ``` - -## 5\. Start the chain application ✅[​](#5-start-the-chain-application- "Direct link to heading") +## 5. Start the chain application ✅[​](#5-start-the-chain-application- 'Direct link to heading') Starting the chain application should be no different than starting the application without the sidecar. -## Troubleshooting[​](#troubleshooting "Direct link to heading") +## Troubleshooting[​](#troubleshooting 'Direct link to heading') -If you are having issues running the oracle sidecar, please see the [Troubleshooting section](https://docs.skip.money/slinky/validator/troubleshooting) for more information. \ No newline at end of file +If you are having issues running the oracle sidecar, please see the [Troubleshooting section](https://docs.skip.money/slinky/validator/troubleshooting) for more information. diff --git a/docs/slinky/validator-docs/slinky-troubleshoot.mdx b/docs/validator-docs/slinky-troubleshoot.mdx similarity index 100% rename from docs/slinky/validator-docs/slinky-troubleshoot.mdx rename to docs/validator-docs/slinky-troubleshoot.mdx diff --git a/docs/slinky/validator-docs/validator-config-ref.mdx b/docs/validator-docs/validator-config-ref.mdx similarity index 100% rename from docs/slinky/validator-docs/validator-config-ref.mdx rename to docs/validator-docs/validator-config-ref.mdx diff --git a/docs/favicon.png b/favicon.png similarity index 100% rename from docs/favicon.png rename to favicon.png diff --git a/docs/images/1.png b/images/1.png similarity index 100% rename from docs/images/1.png rename to images/1.png diff --git a/docs/images/2.png b/images/2.png similarity index 100% rename from docs/images/2.png rename to images/2.png diff --git a/docs/images/3ff1176-Screen_Shot_2023-07-25_at_11.46.38_AM.png b/images/3ff1176-Screen_Shot_2023-07-25_at_11.46.38_AM.png similarity index 100% rename from docs/images/3ff1176-Screen_Shot_2023-07-25_at_11.46.38_AM.png rename to images/3ff1176-Screen_Shot_2023-07-25_at_11.46.38_AM.png diff --git a/docs/images/443a393-Screen_Shot_2023-07-25_at_11.46.47_AM.png b/images/443a393-Screen_Shot_2023-07-25_at_11.46.47_AM.png similarity index 100% rename from docs/images/443a393-Screen_Shot_2023-07-25_at_11.46.47_AM.png rename to images/443a393-Screen_Shot_2023-07-25_at_11.46.47_AM.png diff --git a/docs/images/51dc78a-Screen_Shot_2023-07-25_at_3.04.14_PM.png b/images/51dc78a-Screen_Shot_2023-07-25_at_3.04.14_PM.png similarity index 100% rename from docs/images/51dc78a-Screen_Shot_2023-07-25_at_3.04.14_PM.png rename to images/51dc78a-Screen_Shot_2023-07-25_at_3.04.14_PM.png diff --git a/docs/images/5b993ce-swap-warning-image.png b/images/5b993ce-swap-warning-image.png similarity index 100% rename from docs/images/5b993ce-swap-warning-image.png rename to images/5b993ce-swap-warning-image.png diff --git a/docs/images/66a9d2b-Screen_Shot_2023-07-25_at_9.50.00_AM.png b/images/66a9d2b-Screen_Shot_2023-07-25_at_9.50.00_AM.png similarity index 100% rename from docs/images/66a9d2b-Screen_Shot_2023-07-25_at_9.50.00_AM.png rename to images/66a9d2b-Screen_Shot_2023-07-25_at_9.50.00_AM.png diff --git a/docs/images/a61a075-swap-warning-page-image.png b/images/a61a075-swap-warning-page-image.png similarity index 100% rename from docs/images/a61a075-swap-warning-page-image.png rename to images/a61a075-swap-warning-page-image.png diff --git a/docs/images/prepare-ab3b2b6898825f3eb78a2c901a9436e8.svg b/images/prepare-ab3b2b6898825f3eb78a2c901a9436e8.svg similarity index 100% rename from docs/images/prepare-ab3b2b6898825f3eb78a2c901a9436e8.svg rename to images/prepare-ab3b2b6898825f3eb78a2c901a9436e8.svg diff --git a/docs/images/sidecar-18cc25dad8b4ca6d0ac7afc01b7511e0.svg b/images/sidecar-18cc25dad8b4ca6d0ac7afc01b7511e0.svg similarity index 100% rename from docs/images/sidecar-18cc25dad8b4ca6d0ac7afc01b7511e0.svg rename to images/sidecar-18cc25dad8b4ca6d0ac7afc01b7511e0.svg diff --git a/docs/images/slinky-arch-cbd6c2e4e5b05737441aed9995c278e0.png b/images/slinky-arch-cbd6c2e4e5b05737441aed9995c278e0.png similarity index 100% rename from docs/images/slinky-arch-cbd6c2e4e5b05737441aed9995c278e0.png rename to images/slinky-arch-cbd6c2e4e5b05737441aed9995c278e0.png diff --git a/docs/images/slinky-banner.png b/images/slinky-banner.png similarity index 100% rename from docs/images/slinky-banner.png rename to images/slinky-banner.png diff --git a/docs/images/slinky-town-crier.png b/images/slinky-town-crier.png similarity index 100% rename from docs/images/slinky-town-crier.png rename to images/slinky-town-crier.png diff --git a/docs/images/slinky_customers.png b/images/slinky_customers.png similarity index 100% rename from docs/images/slinky_customers.png rename to images/slinky_customers.png diff --git a/docs/images/slinky_math.png b/images/slinky_math.png similarity index 100% rename from docs/images/slinky_math.png rename to images/slinky_math.png diff --git a/docs/logo/dark.png b/logo/dark.png similarity index 100% rename from docs/logo/dark.png rename to logo/dark.png diff --git a/docs/logo/light.png b/logo/light.png similarity index 100% rename from docs/logo/light.png rename to logo/light.png diff --git a/docs/mint.json b/mint.json similarity index 77% rename from docs/mint.json rename to mint.json index b9f9ffed4..e856e54b3 100644 --- a/docs/mint.json +++ b/mint.json @@ -43,25 +43,25 @@ { "name": "Home", "icon": "house", - "url": "https://docs.skip.money" + "url": "https://skip.mintlify.app" } ], "navigation": [ { "group": "Slinky", "pages": [ - "slinky/overview", - "slinky/security-properties", - "slinky/incentivize-slashing", + "docs/overview", + "docs/security-properties", + "docs/incentivize-slashing", { "group": "Validator Docs", "pages": [ - "slinky/validator-docs/quickstart", - "slinky/validator-docs/validator-config-ref", - "slinky/validator-docs/slinky-troubleshoot" + "docs/validator-docs/quickstart", + "docs/validator-docs/validator-config-ref", + "docs/validator-docs/slinky-troubleshoot" ] }, - "slinky/upcoming-features" + "docs/upcoming-features" ] } ], diff --git a/docs/style.css b/style.css similarity index 100% rename from docs/style.css rename to style.css