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/overview.mdx b/docs/overview.mdx new file mode 100644 index 000000000..15be1a777 --- /dev/null +++ b/docs/overview.mdx @@ -0,0 +1,82 @@ +--- +title: 'Overview' +--- + +![](/images/slinky-banner.png) + + +Block SDK + +Slinky is **business-licensed software** under BSL. It is source viewable, but [**reach out to us**](https://skip.money/contact) to us if you are interested in integrating! We are limiting the number of chains we work with to seven in 2024. We apologize if we run out of capacity. + +Visit the GitHub repo [here](https://github.com/skip-mev/slinky). + +For support, [**join our discord**](https://skip.money/discord)! + + + +![](/images/slinky_customers.png) + +## 🦾 Slinky Features[​](#-slinky-features 'Direct link to heading') + +βœ… **Runs on the chain validator set** - Slinky leverages the chain’s security, giving the fastest updates possible, and removing the requirements for any 3rd party systems. + +βœ… **Highly performant** - Slinky can support over 2000 currency pairs and price feeds, allowing the launch of thousands of permissionless on-chain markets. + +βœ… **Full operational support** - comes with a 1-day SLAs for adding new feeds, and 24/7 on-call support and maintenance by the Skip team. + +βœ… **Better Application UX** - by leveraging new advancements in consensus like vote extensions & ABCI++, Slinky guarantees a millisecond-fresh oracle update every block, allowing applications to build without sacrificing UX for safety. + +## 🏎️ The Slinky Sidecar[​](#️-the-slinky-sidecar 'Direct link to heading') + +- The Slinky sidecar is an out-of-process service that efficiently fetches prices from various data sources and runs aggregation logic to combine them into a single price for each feed. +- Validators use GRPC requests to the sidecar to fetch the latest updates to update on-chain prices from over 20+ providers. + +![Sidecar](/images/sidecar-18cc25dad8b4ca6d0ac7afc01b7511e0.svg) + +## ⚑️ On-chain aggregation[​](#️-on-chain-aggregation 'Direct link to heading') + +Slinky uses **[ABCI++](https://docs.cometbft.com/v0.37/spec/abci/)** to separate Oracle aggregation and into secure and efficient steps. + +![Slinky Architecture](/images/slinky-arch-cbd6c2e4e5b05737441aed9995c278e0.png) + +### Extend Vote / Verify Vote[​](#extend-vote--verify-vote 'Direct link to heading') + +The `ExtendVote` and `VerifyVote` methods of ABCI++ are where a price is first queried. + +- The validators fetch prices from the sidecar from a series of `providers` (e.g. Binance / Coinbase) for each currency pair. +- For each pair, the median is taken between all `providers`. +- Each validator then submits their final prices to the chain via the ABCI++ `ExtendVote` method. +- `VerifyVote` is used to ensure that the submitted data is valid--i.e. it can be unmarshalled by another validator. + +### Prepare Proposal[​](#prepare-proposal 'Direct link to heading') + +During `PrepareProposal`, the vote extensions from the previous block are aggregated by the block proposer into their block proposal, after various checks are run on them. + +- Slinky ensures that the set of vote extensions comprise the required minimum stake required for a price update (default of 2/3). + +- It also ensures that the vote extensions are valid and can be understood by the application. + +- Finally, it encodes the vote extensions and injects them into the top of the block proposal as a pseudo-transaction ignored by the chain. + + ![Prepare Proposal](/images/prepare-ab3b2b6898825f3eb78a2c901a9436e8.svg) + +For more information on vote extensions in general, refer to **[the Cosmos SDK docs](https://docs.cosmos.network/main/build/abci/vote-extensions)**. + +### Process Proposal[​](#process-proposal 'Direct link to heading') + +`ProcessProposal` is identical to PrepareProposal, except it is run on every validator to validate the block proposal. + +- If the validator comes to the conclusion that the injected votes are valid and comprise the required minimum stake, it will accept the proposal. +- If not, the validator will reject the proposal. + +### Finalize Block[​](#finalize-block 'Direct link to heading') + +The end of a price's journey is in the `Preblock` step. + +- Here, the the injected transaction data is unmarshalled back into vote extensions, and the application takes a stake-weighted median of the prices reported by every validator. +- The resulting canonical price for each pair is stored in the `x/oracle` module and can be queried by any application or RPC. + +### Full Flow[​](#full-flow 'Direct link to heading') + +- This full set of steps repeats on every block resulting in a continuous stream of guaranteed prices. The oracle is enshrined in the application by the validator set, and so is fundamentally equivalent to chain liveness (i.e. the oracle can't go down without the chain going down) diff --git a/docs/security-properties.mdx b/docs/security-properties.mdx new file mode 100644 index 000000000..46e9349b3 --- /dev/null +++ b/docs/security-properties.mdx @@ -0,0 +1,41 @@ +--- +title: "Security Properties" +--- + +![](/images/slinky_math.png) + +## ⛓️ Overall Assumptions[​](#️-overall-assumptions "Direct link to heading") + +βœ… **Slinky is as secure as the chain it is deployed on** - This is the meaning of a "restaked" oracle - Slinky leverages all available security that the chain can provide by using the existing validator set and tying updates to consensus via vote extensions. + +βœ… **Prices require 2/3 participation from validators to be posted on chain** - We require a minimum of 2/3 of stake weight to contribute to a price aggregation for that price to actually update chain state. This is the same stake weight required to commit blocks. + +βœ… **Slinky avoids any external dependencies** - Slinky injects price data directly into the chain it's deployed on. This means there's no additional chain, token, relayer, or other outside actor dependency. The same operators that run the chain run the oracle. + +βœ… **Slinky price updates are atomic with liveness** - Since Slinky data is signed atomically with `PreCommit` votes via Vote Extensions, chains can configure their application (or parts of their application) to depend on per-block price updates. This makes almost all forms of oracle attacks impossible, and allows applications to avoid having to build their own UX roadblocks to ensure safety. + +## πŸ”€ Impact of Vote Extensions[​](#-impact-of-vote-extensions "Direct link to heading") + +Slinky updates by having over 2/3 of the validator set (by stake weight) suggest a series of prices, and then aggregates across them using a stake-weighted median. This price data is committed to the chain by validators through [vote extensions](https://docs.cosmos.network/main/build/abci/vote-extensions). + +Vote extensions are arbitrary metadata that is signed atomically with a validator's `PreCommit` vote. In Slinky's case, that metadata is locally observed prices for a series of `CurrencyPairs` (e.g. `ETH/USDC`). + +Given blocks cannot progress without 2/3 of stake weight submitting votes, blocks also cannot progress without 2/3 of vote extensions. Additionally, the `x/oracle` module (where prices are stored on chain) requires at least 2/3 of voting power to have contributed to individual price updates. This means that every price update has the same participation as block validity itself. + +## πŸ‘Ί Manipulation Thresholds[​](#-manipulation-thresholds "Direct link to heading") + +In the standard configuration of Slinky, it requires `1/3` of stake to be manipulated to post an incorrect oracle price. This is because: + +* `2/3` of stake is required to post any update (as described above) +* half of that stake must be manipulated to post incorrect prices in the _same direction_ to move the stake-weighted median final price posted on-chain +* That is, (`2/3 / 2 = 1/3`) of stake must be manipulated to post a malicious price. + +However, Slinky can support additional constraints to increase this level to `2/3` of stake. To do this, the final on-chain prices are re-checked by all validators on the network in the `ProcessProposal` step to enforce some minimum deviation from their local prices are not exceeded. `2/3` of stake weight is required to vote "yes" on this check, raising the overall security back to that of the chain itself. + +There are tradeoffs to increasing the security to this level. Validators may reject proposals more often if there is high volatility in price updates between them, which could result in longer periods of oracle downtime in periods of crypto market instability. + +## πŸŽ–οΈ Importance of Operational Excellence[​](#️-importance-of-operational-excellence "Direct link to heading") + +Security assumptions, no matter how good, are no substitute for the oracle operators (the chain's validator set) keeping high uptime, reliable, and accurate price updates. Slinky makes this easy for validators, providing an ample amount of operational support and tooling for alerting, upgrading, and maintaining the Slinky sidecar. We work with operators from respected oracles like [ChainLink](https://chain.link/) to ensure validators replicate best practices. + +Operational excellence is heavily tied to incentivization and disincentivization mechanisms imposed on operators. Please read our section on [Incentivization & Slashing](https://docs.skip.money/slinky/slashing) for more info. \ No newline at end of file diff --git a/docs/upcoming-features.mdx b/docs/upcoming-features.mdx new file mode 100644 index 000000000..90a711bdd --- /dev/null +++ b/docs/upcoming-features.mdx @@ -0,0 +1,44 @@ +--- +title: "Upcoming Features" +--- +## What's next for Slinky?[​](#whats-next-for-slinky "Direct link to heading") + +Slinky has a number of major releases already in the works. Below, we outline a couple of the research and product directions we're building. + +--- + +### πŸ”€ New Types of Data[​](#-new-types-of-data "Direct link to heading") + +**_Estimated: April 2024_** + +As a fast follow to our support for prices, Slinky will be able to provide chains with Verifiable Randomness Functions, offchain asset reserve proofs (to support RWA tokens), and light client support (to borrow security and post data to other protocols, like EigenLayer or Celestia). + +### 🀝 Validator Subsetting[​](#-validator-subsetting "Direct link to heading") + +**_Estimated: June 2024_** + +In it's standard implementation, all validators running Slinky are expected and accountable for posting prices for **_all_** currency pairs every block. Although Slinky is optimized to do this for over a thousand currency pairs, it can scale further if **_subsets_** of validators are selected to report specific prices. + +Our excitement is for this feature to enable an active marketplace, with users and traders creating incentive pools for validators that support their desired currency pair, and validators opting-into additional committments to do so. + +### 🌈 Rollup Support[​](#-rollup-support "Direct link to heading") + +**_Estimated: August 2024_** + +Already, Slinky integrators are using the oracle to gossip prices to rollups that use their chain as a settlement or DA layer. We plan to expand the tooling to more easily support rollups in general, and help our integrators become hubs for fast, verifiable data provisioning across the L2 landscape. + +Currently, we are working with Celestia and RollKit team to build out a first version. + +### πŸ’» Sidecar Restaking Services[​](#-sidecar-restaking-services "Direct link to heading") + +**_Estimated: November 2024_** + +Slinky is a restaked operation by design. However, the incentive and slashing mechanisms tied to the operation of the Slinky oracle can be extended to other services that validators can offer chains. For example, this would include: + +1. Running IBC-relayers within Slinky in an on-chain, verifiable way, and rewarding validators on a per-packet basis. +2. Running indexers and servers within the sidecar to service decentralized frontends. +3. Running bridge software (e.g. "Peggo") to give chains guaranteed interoperability with outside networks. +4. Running generalized offchain computation and posting ZK proofs (e.g. optimal routing, fee markets) to lighten node binary computation burden while still having verifiable ways of posting computation results. +5. Running an external transaction gossip network to lower bandwidth load on Comet/Tendermint, allowing chains to finalize significantly faster. + +Our integration partners will be invited to test and influence these features, effectively leveraging their existing operator set for greater and greater value. \ No newline at end of file diff --git a/docs/validator-docs/quickstart.mdx b/docs/validator-docs/quickstart.mdx new file mode 100644 index 000000000..a305a4a6c --- /dev/null +++ b/docs/validator-docs/quickstart.mdx @@ -0,0 +1,101 @@ +--- +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') + +**Estimated Time**: 10 mins + +In this walkthrough, we'll be going through the 5 steps to set up Slinky. + +1. Install the binary of a support chain application. +2. Install the slinky binary. +3. Configure your slinky sidecar process. +4. Run the slinky sidecar. +5. Start the chain application. + +## 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') + +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` + +```bash +git clone git@github.com:skip-mev/slinky.git +cd slinky +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') + +- 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!** + +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') + +You can run the slinky sidecar by running the following command: + +```bash +slinky oracle --config oracle.toml + +``` + +You can verify whether prices are being retrieved by running the following command: + +```bash +curl --request -x GET 'http://localhost:8080/slinky/v1/oracle/prices | jq .' + +``` + +You should see output similar to the following: + +```json +{ + "prices": { + "ATOM/USD": "920650000", + "BITCOIN/USD": "3980283250000", + "DYDX/USD": "273682500", + "ETHEREUM/BITCOIN": "5842000", + "ETHEREUM/USD": "232550500000", + "POLKADOT/USD": "638800000", + "SOLANA/USD": "8430350000" + }, + "timestamp": "2024-01-23T01:15:09.776890Z" +} +``` + +## 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') + +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/validator-docs/slinky-troubleshoot.mdx b/docs/validator-docs/slinky-troubleshoot.mdx new file mode 100644 index 000000000..e88381a9f --- /dev/null +++ b/docs/validator-docs/slinky-troubleshoot.mdx @@ -0,0 +1,22 @@ +--- +title: Slinky Troubleshooting +--- +## Troubleshooting FAQs +We are in the process of building up our core documentation around operational issues and troubleshooting. For now, we are available 24/7 for any questions. The fastest way to reach us is by emailing support@skip.money + +## Can I run Slinky on the same machine as my validator? +Yes, you can run it anywhere - but please defer to any chain-specific reccommendations if there are any! + +## Can I get slashed for running Slinky? +Not usually. If a chain uses Slinky and requires oracle prices to be posted, running the Slinky sidecar is the best way to avoid downtime or incorrect prices. For more information, check out the [Incentivization Docs](/slinky/incentivize-slashing). + +Many chains will reward good operation of Slinky with additional validator yield, make sure to ask the team! + +## Does Slinky take up a lot of resources? +No, it's a very lightweight binary. + +## ## Can I contribute to Slinky? +Yes - feel free to contribute via opening an issue in our [repo](https://github.com/skip-mev/docs)! + +I do not see an issue addressing my question. +Please reach out to us using your preferred method. We are available on [our website](https://skip.money/contact) or via a [Github issue](https://github.com/skip-mev/docs/issues/new). \ No newline at end of file diff --git a/docs/validator-docs/validator-config-ref.mdx b/docs/validator-docs/validator-config-ref.mdx new file mode 100644 index 000000000..69e90cf54 --- /dev/null +++ b/docs/validator-docs/validator-config-ref.mdx @@ -0,0 +1,514 @@ +--- +title: "Validator Configuration Reference" +description: This readme gives an overview of the configuration options for the oracle service and its corresponding metrics intrumentation. +--- + +Validators running on a network that supports the oracle **must** run the oracle side-car. Non-validator nodes can configure their oracle config's to be disabled, and the oracle side-car will not run. + +> +|Type |Oracle Config|App Config| +|-------------|-------------|----------| +|Validator |Required |Required | +|Non-Validator|Optional |Optional | + + +All oracle configurations are broken down into two files: + +1. **Oracle side-car configuration (`oracle.toml`):** This contains the data provider's that are utilized, the desired markets to be requested, metrics instrumentation, and more. +2. **Oracle configuration in the application (`app.toml`):** A few additional lines of code that must be added to the application's `app.toml` file to configure the oracle side car into the application. + +The `app.toml` file is the configuration file that is consumed by the application. This file contains over-arching configurations for your entire Cosmos SDK application, as well as a few new configurations for the oracle. You must use this template to add the oracle configurations to your `app.toml` file: + +```perl +# Other configurations + +... + +############################################################################### +### Oracle ### +############################################################################### +[oracle] +# Enabled indicates whether the oracle is enabled. +enabled = "{{ .Oracle.Enabled }}" + +# Oracle Address is the URL of the out of process oracle sidecar. This is used to +# connect to the oracle sidecar when the application boots up. Note that the address +# can be modified at any point, but will only take effect after the application is +# restarted. This can be the address of an oracle container running on the same +# machine or a remote machine. +oracle_address = "{{ .Oracle.OracleAddress }}" + +# Client Timeout is the time that the client is willing to wait for responses from +# the oracle before timing out. +client_timeout = "{{ .Oracle.ClientTimeout }}" + +# MetricsEnabled determines whether oracle metrics are enabled. Specifically +# this enables intsrumentation of the oracle client and the interaction between +# the oracle and the app. +metrics_enabled = "{{ .Oracle.MetricsEnabled }}" + +# PrometheusServerAddress is the address of the prometheus server that metrics will be +# exposed to. +prometheus_server_address = "{{ .Oracle.PrometheusServerAddress }}" + +... + +# More configurations +``` +In your `app.toml`, you should see / write something that looks like this. + + +This is only required if you are running a validator node. If you are running a non-validator node, you can skip this section. + + +```perl +... + + +############################################################################### +### Oracle ### +############################################################################### +[oracle] +# Enabled indicates whether the oracle is enabled. +enabled = "true" + +# Oracle Address is the URL of the out of process oracle sidecar. This is used to +# connect to the oracle sidecar when the application boots up. Note that the address +# can be modified at any point, but will only take effect after the application is +# restarted. This can be the address of an oracle container running on the same +# machine or a remote machine. +oracle_address = "0.0.0.0:8080" + +# Client Timeout is the time that the client is willing to wait for responses from +# the oracle before timing out. +client_timeout = "1s" + +# MetricsEnabled determines whether oracle metrics are enabled. Specifically +# this enables intsrumentation of the oracle client and the interaction between +# the oracle and the app. +metrics_enabled = "true" + +# PrometheusServerAddress is the address of the prometheus server that metrics will be +# exposed to. +prometheus_server_address = "0.0.0.0:8001" + +... + +``` + + +The `oracle.toml` file is the configuration file that is consumed by the oracle side-car. Note that in most cases, this should **NOT** be custom made by validators. A predefined oracle side car configuration should be provided by the chain that the oracle supports. This file contains: + +* The desired data providers to be utilized i.e. Coinbase, Binance, etc. +* The desired markets to be requested (i.e. BTC/USD, ETH/USD, etc.). +* Metrics instrumentation. + +## Oracle Configuration[​](#oracle-configuration "Direct link to heading") + +The main oracle configuration object is located in [oracle.go](https://github.com/skip-mev/slinky/blob/main/oracle/config/oracle.go). This is utilized to set up the oracle and to configure the providers that the oracle will use. The object is defined as follows: + +``` +type OracleConfig struct { + UpdateInterval time.Duration `mapstructure:"update_interval" toml:"update_interval"` + Providers []ProviderConfig `mapstructure:"providers" toml:"providers"` + CurrencyPairs []oracletypes.CurrencyPair `mapstructure:"currency_pairs" toml:"currency_pairs"` + Production bool `mapstructure:"production" toml:"production"` + Metrics MetricsConfig `mapstructure:"metrics" toml:"metrics"` +} + +``` + + +## UpdateInterval[​](#updateinterval "Direct link to heading") + +This field is utilized to set the interval at which the oracle will fetch prices from providers. + +## Providers[​](#providers "Direct link to heading") + +This field is utilized to set the list of providers that the oracle will fetch prices from. A given provider's configuration is composed of: + +* A market configuration that defines the currency pairs that the oracle will fetch prices for from the provider. +* An API configuration that defines the various API configurations that the oracle will use to fetch prices from the provider. +* A WebSocket configuration that defines the various WebSocket configurations that the oracle will use to fetch prices from the provider. + +> Note: Typically only one of either the API or websocket config is required. However, some providers may require both. Please read the provider's documentation to learn more about how to configure the provider. Each provider provides sensible defaults for the API and WebSocket configurations that should be used for most cases. + +``` +type ProviderConfig struct { + Name string `mapstructure:"name" toml:"name"` + API APIConfig `mapstructure:"api" toml:"api"` + WebSocket WebSocketConfig `mapstructure:"web_socket" toml:"web_socket"` + Market MarketConfig `mapstructure:"market_config" toml:"market_config"` +} + +``` + + +### Name[​](#name "Direct link to heading") + +This field is utilized to set the name of the provider. This name is used to identify the provider in the oracle's logs as well as in the oracle's metrics. + +### API[​](#api "Direct link to heading") + +This field is utilized to set the various API configurations that are specific to the provider. + +``` +type APIConfig struct { + Enabled bool `mapstructure:"enabled" toml:"enabled"` + Timeout time.Duration `mapstructure:"timeout" toml:"timeout"` + Interval time.Duration `mapstructure:"interval" toml:"interval"` + MaxQueries int `mapstructure:"max_queries" toml:"max_queries"` + Atomic bool `mapstructure:"atomic" toml:"atomic"` + URL string `mapstructure:"url" toml:"url"` + Name string `mapstructure:"name" toml:"name"` +} + +``` + + +#### Enabled (API)[​](#enabled-api "Direct link to heading") + +This field is utilized to set whether the provider is API based. If the provider is not API based, this field should be set to `false`. + +#### Timeout[​](#timeout "Direct link to heading") + +This field is utilized to set the amount of time the provider should wait for a response from its API before timing out. + +#### Interval[​](#interval "Direct link to heading") + +This field is utilized to set the interval at which the provider should update the prices. Note that provider's may rate limit based on this interval so it is recommended to tune this value as necessary. + +#### MaxQueries[​](#maxqueries "Direct link to heading") + +This field is utilized to set the maximum number of queries that the provider will make within the interval. + +#### Atomic[​](#atomic "Direct link to heading") + +This field is utilized to set whether the provider can fulfill its queries in a single request. If the provider can fulfill its queries in a single request, this field should be set to `true`. Otherwise, this field should be set to `false`. In the case where all requests can be fulfilled atomically, the oracle will make a single request to the provider to fetch prices for all currency pairs once every interval. + +#### URL[​](#url "Direct link to heading") + +This field is utilized to set the URL that is used to fetch data from the API. + +#### Name (Should be the same as the provider's name)[​](#name-should-be-the-same-as-the-providers-name "Direct link to heading") + +This field is utilized to set the name of the provider. Mostly used as a sanity check to ensure the API configurations correctly correspond to the provider. + +### WebSocket[​](#websocket "Direct link to heading") + +This field is utilized to set the various WebSocket configurations that are specific to the provider. + +``` +type WebSocketConfig struct { + Enabled bool `mapstructure:"enabled" toml:"enabled"` + MaxBufferSize int `mapstructure:"max_buffer_size" toml:"max_buffer_size"` + ReconnectionTimeout time.Duration `mapstructure:"reconnection_timeout" toml:"reconnection_timeout"` + WSS string `mapstructure:"wss" toml:"wss"` + Name string `mapstructure:"name" toml:"name"` + ReadBufferSize int `mapstructure:"read_buffer_size" toml:"read_buffer_size"` + WriteBufferSize int `mapstructure:"write_buffer_size" toml:"write_buffer_size"` + HandshakeTimeout time.Duration `mapstructure:"handshake_timeout" toml:"handshake_timeout"` + EnableCompression bool `mapstructure:"enable_compression" toml:"enable_compression"` + ReadTimeout time.Duration `mapstructure:"read_deadline" toml:"read_deadline"` + WriteTimeout time.Duration `mapstructure:"write_deadline" toml:"write_deadline"` + PingInterval time.Duration `mapstructure:"ping_interval" toml:"ping_interval"` + MaxReadErrorCount int `mapstructure:"max_read_error_count" toml:"max_read_error_count"` +} + +``` + + +#### Enabled (Websocket)[​](#enabled-websocket "Direct link to heading") + +This field is utilized to set whether the provider is WebSocket based. If the provider is not WebSocket based, this field should be set to `false`. + +#### MaxBufferSize[​](#maxbuffersize "Direct link to heading") + +This field is utilized to set the maximum number of messages that the provider will buffer at any given time. If the provider receives more messages than this, it will block receiving messages until the buffer is cleared. + +#### ReconnectionTimeout[​](#reconnectiontimeout "Direct link to heading") + +This field is utilized to set the timeout for the provider to attempt to reconnect to the websocket endpoint. In the case when the connection is corrupted, the provider will wait the `ReconnectionTimeout` before attempting to reconnect. + +#### WSS[​](#wss "Direct link to heading") + +This field is utilized to set the websocket endpoint for the provider. + +#### Name (Should match the provider's name)[​](#name-should-match-the-providers-name "Direct link to heading") + +This field is utilized to set the name of the provider. Mostly used as a sanity check to ensure the WebSocket configurations correctly correspond to the provider. + +#### ReadBufferSize[​](#readbuffersize "Direct link to heading") + +This field is utilized to set the I/O read buffer size. If a buffer size of 0 is specified, then a default buffer size is used. + +#### WriteBufferSize[​](#writebuffersize "Direct link to heading") + +This field is utilized to set the I/O write buffer size. If a buffer size of 0 is specified, then a default buffer size is used. + +#### HandshakeTimeout[​](#handshaketimeout "Direct link to heading") + +This field is utilized to set the duration for the handshake to complete. + +#### EnableCompression[​](#enablecompression "Direct link to heading") + +This field is utilized to set whether the client should attempt to negotiate per message compression (RFC 7692). Setting this value to true does not guarantee that compression will be supported. Note that enabling compression may increase latency. + +#### ReadTimeout[​](#readtimeout "Direct link to heading") + +This field is utilized to set the read deadline on the underlying network connection. After a read has timed out, the websocket connection state is corrupt and all future reads will return an error. A zero value for t means reads will not time out. + +#### WriteTimeout[​](#writetimeout "Direct link to heading") + +This field is utilized to set the write deadline on the underlying network connection. After a write has timed out, the websocket state is corrupt and all future writes will return an error. A zero value for t means writes will not time out. + +#### PingInterval[​](#pinginterval "Direct link to heading") + +This field is utilized to set the interval to ping the server. Note that a ping interval of 0 disables pings. This is utilized to send heartbeat messages to the server to ensure that the connection is still alive. + +#### MaxReadErrorCount[​](#maxreaderrorcount "Direct link to heading") + +This field is utilized to set the maximum number of read errors that the provider will tolerate before closing the connection and attempting to reconnect. + +### MarketConfig[​](#marketconfig "Direct link to heading") + +This field is utilized to set the various market configurations that are specific to the provider i.e. what prices is this provider responsible for fetching. + +``` +type MarketConfig struct { + Name string `mapstructure:"name" toml:"name"` + CurrencyPairToMarketConfigs map[string]CurrencyPairMarketConfig `mapstructure:"currency_pair_to_market_configs" toml:"currency_pair_to_market_configs"` +} + +type CurrencyPairMarketConfig struct { + Ticker string `mapstructure:"ticker" toml:"ticker"` + CurrencyPair oracletypes.CurrencyPair `mapstructure:"currency_pair" toml:"currency_pair"` +} + +``` + + +#### Name (Should match the provider's name)[​](#name-should-match-the-providers-name-1 "Direct link to heading") + +This field is utilized to set the name of the provider. Mostly used as a sanity check to ensure the market configurations correctly correspond to the provider. + +#### CurrencyPairToMarketConfigs[​](#currencypairtomarketconfigs "Direct link to heading") + +This field is utilized to set the mappings between on-chain and off-chain currency pairs. In particular, this config maps the on-chain currency pair representation (i.e. BITCOIN/USD) to the off-chain currency pair representation (i.e. BTC/USD). + +## CurrencyPairs[​](#currencypairs "Direct link to heading") + +This field is utilized to set the list of currency pairs that the oracle will fetch prices for. These should be the same exact currency pairs that the oracle module (`x/oracle`) is currently configured to accept. + +## Production[​](#production "Direct link to heading") + +This field is utilized to set whether the oracle is running in production mode. This is used to determine whether the oracle should be run in debug mode or not. This particularly helpful for logging purposes. + +## Metrics[​](#metrics "Direct link to heading") + +This field is utilized to set the metrics configurations for the oracle. To read more about the various metrics that are collected and corresponding queries, please read the [Readme](https://github.com/skip-mev/slinky/blob/main/oracle/metrics/README.md). + +``` +type MetricsConfig struct { + PrometheusServerAddress string `mapstructure:"prometheus_server_address" toml:"prometheus_server_address"` + Enabled bool `mapstructure:"enabled" toml:"enabled"` +} + +``` + + +### PrometheusServerAddress[​](#prometheusserveraddress "Direct link to heading") + +This field is utilized to set the address of the prometheus server that the oracle will expose metrics to. + +### Enabled[​](#enabled "Direct link to heading") + +This field is utilized to set whether metrics should be enabled. + +Sample configuration: + +```json +update_interval = "1s" +production = true + +[[providers]] + name = "coinbase" + [providers.api] + enabled = true + timeout = "500ms" + interval = "1s" + max_queries = 5 + atomic = false + url = "https://api.coinbase.com/v2/prices/%s/spot" + name = "coinbase" + [providers.web_socket] + enabled = false + max_buffer_size = 0 + reconnection_timeout = "0s" + wss = "" + name = "" + read_buffer_size = 0 + write_buffer_size = 0 + handshake_timeout = "0s" + enable_compression = false + read_deadline = "0s" + write_deadline = "0s" + ping_interval = "0s" + max_read_error_count = 0 + [providers.market_config] + name = "coinbase" + [providers.market_config.currency_pair_to_market_configs] + [providers.market_config.currency_pair_to_market_configs."ATOM/USD"] + ticker = "ATOM-USD" + [providers.market_config.currency_pair_to_market_configs."ATOM/USD".currency_pair] + Base = "ATOM" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."AVAX/USD"] + ticker = "AVAX-USD" + [providers.market_config.currency_pair_to_market_configs."AVAX/USD".currency_pair] + Base = "AVAX" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."BITCOIN/USD"] + ticker = "BTC-USD" + [providers.market_config.currency_pair_to_market_configs."BITCOIN/USD".currency_pair] + Base = "BITCOIN" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."CELESTIA/USD"] + ticker = "TIA-USD" + [providers.market_config.currency_pair_to_market_configs."CELESTIA/USD".currency_pair] + Base = "CELESTIA" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."DYDX/USD"] + ticker = "DYDX-USD" + [providers.market_config.currency_pair_to_market_configs."DYDX/USD".currency_pair] + Base = "DYDX" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."ETHEREUM/BITCOIN"] + ticker = "ETH-BTC" + [providers.market_config.currency_pair_to_market_configs."ETHEREUM/BITCOIN".currency_pair] + Base = "ETHEREUM" + Quote = "BITCOIN" + [providers.market_config.currency_pair_to_market_configs."ETHEREUM/USD"] + ticker = "ETH-USD" + [providers.market_config.currency_pair_to_market_configs."ETHEREUM/USD".currency_pair] + Base = "ETHEREUM" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."OSMOSIS/USD"] + ticker = "OSMO-USD" + [providers.market_config.currency_pair_to_market_configs."OSMOSIS/USD".currency_pair] + Base = "OSMOSIS" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."SOLANA/USD"] + ticker = "SOL-USD" + [providers.market_config.currency_pair_to_market_configs."SOLANA/USD".currency_pair] + Base = "SOLANA" + Quote = "USD" + +[[providers]] + name = "okx" + [providers.api] + enabled = false + timeout = "0s" + interval = "0s" + max_queries = 0 + atomic = false + url = "" + name = "" + [providers.web_socket] + enabled = true + max_buffer_size = 1000 + reconnection_timeout = "10s" + wss = "wss://ws.okx.com:8443/ws/v5/public" + name = "okx" + read_buffer_size = 0 + write_buffer_size = 0 + handshake_timeout = "45s" + enable_compression = false + read_deadline = "45s" + write_deadline = "45s" + ping_interval = "0s" + max_read_error_count = 100 + [providers.market_config] + name = "okx" + [providers.market_config.currency_pair_to_market_configs] + [providers.market_config.currency_pair_to_market_configs."ATOM/USD"] + ticker = "ATOM-USD" + [providers.market_config.currency_pair_to_market_configs."ATOM/USD".currency_pair] + Base = "ATOM" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."AVAX/USD"] + ticker = "AVAX-USD" + [providers.market_config.currency_pair_to_market_configs."AVAX/USD".currency_pair] + Base = "AVAX" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."BITCOIN/USD"] + ticker = "BTC-USD" + [providers.market_config.currency_pair_to_market_configs."BITCOIN/USD".currency_pair] + Base = "BITCOIN" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."CELESTIA/USD"] + ticker = "TIA-USD" + [providers.market_config.currency_pair_to_market_configs."CELESTIA/USD".currency_pair] + Base = "CELESTIA" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."DYDX/USD"] + ticker = "DYDX-USD" + [providers.market_config.currency_pair_to_market_configs."DYDX/USD".currency_pair] + Base = "DYDX" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."ETHEREUM/BITCOIN"] + ticker = "ETH-BTC" + [providers.market_config.currency_pair_to_market_configs."ETHEREUM/BITCOIN".currency_pair] + Base = "ETHEREUM" + Quote = "BITCOIN" + [providers.market_config.currency_pair_to_market_configs."ETHEREUM/USD"] + ticker = "ETH-USD" + [providers.market_config.currency_pair_to_market_configs."ETHEREUM/USD".currency_pair] + Base = "ETHEREUM" + Quote = "USD" + [providers.market_config.currency_pair_to_market_configs."SOLANA/USD"] + ticker = "SOL-USD" + [providers.market_config.currency_pair_to_market_configs."SOLANA/USD".currency_pair] + Base = "SOLANA" + Quote = "USD" + +[[currency_pairs]] + Base = "BITCOIN" + Quote = "USD" + +[[currency_pairs]] + Base = "ETHEREUM" + Quote = "USD" + +[[currency_pairs]] + Base = "ATOM" + Quote = "USD" + +[[currency_pairs]] + Base = "SOLANA" + Quote = "USD" + +[[currency_pairs]] + Base = "CELESTIA" + Quote = "USD" + +[[currency_pairs]] + Base = "AVAX" + Quote = "USD" + +[[currency_pairs]] + Base = "DYDX" + Quote = "USD" + +[[currency_pairs]] + Base = "ETHEREUM" + Quote = "BITCOIN" + +[[currency_pairs]] + Base = "OSMOSIS" + Quote = "USD" + +[metrics] + prometheus_server_address = "0.0.0.0:8002" + enabled = true +``` diff --git a/favicon.png b/favicon.png new file mode 100644 index 000000000..0975457d5 Binary files /dev/null and b/favicon.png differ diff --git a/images/1.png b/images/1.png new file mode 100644 index 000000000..6213a44f2 Binary files /dev/null and b/images/1.png differ diff --git a/images/2.png b/images/2.png new file mode 100644 index 000000000..4d7b56d19 Binary files /dev/null and b/images/2.png differ diff --git a/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 new file mode 100644 index 000000000..4d2f22070 Binary files /dev/null and b/images/3ff1176-Screen_Shot_2023-07-25_at_11.46.38_AM.png differ diff --git a/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 new file mode 100644 index 000000000..e0956ab61 Binary files /dev/null and b/images/443a393-Screen_Shot_2023-07-25_at_11.46.47_AM.png differ diff --git a/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 new file mode 100644 index 000000000..15fd2000b Binary files /dev/null and b/images/51dc78a-Screen_Shot_2023-07-25_at_3.04.14_PM.png differ diff --git a/images/5b993ce-swap-warning-image.png b/images/5b993ce-swap-warning-image.png new file mode 100644 index 000000000..cc21717a3 Binary files /dev/null and b/images/5b993ce-swap-warning-image.png differ diff --git a/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 new file mode 100644 index 000000000..e475e4b36 Binary files /dev/null and b/images/66a9d2b-Screen_Shot_2023-07-25_at_9.50.00_AM.png differ diff --git a/images/a61a075-swap-warning-page-image.png b/images/a61a075-swap-warning-page-image.png new file mode 100644 index 000000000..e67d0b96f Binary files /dev/null and b/images/a61a075-swap-warning-page-image.png differ diff --git a/images/prepare-ab3b2b6898825f3eb78a2c901a9436e8.svg b/images/prepare-ab3b2b6898825f3eb78a2c901a9436e8.svg new file mode 100644 index 000000000..2a8995189 --- /dev/null +++ b/images/prepare-ab3b2b6898825f3eb78a2c901a9436e8.svg @@ -0,0 +1,21 @@ + + + + + + + + VEs* well formed* contains 2/3 stakeVerifyProposalInjected VEPrice DataPrepare Proposal \ No newline at end of file diff --git a/images/sidecar-18cc25dad8b4ca6d0ac7afc01b7511e0.svg b/images/sidecar-18cc25dad8b4ca6d0ac7afc01b7511e0.svg new file mode 100644 index 000000000..f4a944b88 --- /dev/null +++ b/images/sidecar-18cc25dad8b4ca6d0ac7afc01b7511e0.svg @@ -0,0 +1,21 @@ + + + + + + + + Chain ApplicationCrypto.comCoinbaseMexcKucoinBinance& MorePricesOracle SidecarPrice Providers \ No newline at end of file diff --git a/images/slinky-arch-cbd6c2e4e5b05737441aed9995c278e0.png b/images/slinky-arch-cbd6c2e4e5b05737441aed9995c278e0.png new file mode 100644 index 000000000..5133cff73 Binary files /dev/null and b/images/slinky-arch-cbd6c2e4e5b05737441aed9995c278e0.png differ diff --git a/images/slinky-banner.png b/images/slinky-banner.png new file mode 100644 index 000000000..2f0529539 Binary files /dev/null and b/images/slinky-banner.png differ diff --git a/images/slinky-town-crier.png b/images/slinky-town-crier.png new file mode 100644 index 000000000..9620983f7 Binary files /dev/null and b/images/slinky-town-crier.png differ diff --git a/images/slinky_customers.png b/images/slinky_customers.png new file mode 100644 index 000000000..0fede17e2 Binary files /dev/null and b/images/slinky_customers.png differ diff --git a/images/slinky_math.png b/images/slinky_math.png new file mode 100644 index 000000000..d7f3fc1af Binary files /dev/null and b/images/slinky_math.png differ diff --git a/logo/dark.png b/logo/dark.png new file mode 100644 index 000000000..624a4e359 Binary files /dev/null and b/logo/dark.png differ diff --git a/logo/light.png b/logo/light.png new file mode 100644 index 000000000..6c5f85ee8 Binary files /dev/null and b/logo/light.png differ diff --git a/mint.json b/mint.json new file mode 100644 index 000000000..e856e54b3 --- /dev/null +++ b/mint.json @@ -0,0 +1,72 @@ +{ + "$schema": "https://mintlify.com/schema.json", + "name": "Skip", + "logo": { + "light": "/logo/light.png", + "dark": "/logo/dark.png" + }, + "favicon": "/favicon.png", + "colors": { + "primary": "#0E0E0E", + "light": "#FAFAFA", + "dark": "#0E0E0E", + "background": { + "dark": "#151617" + } + }, + "topbarLinks": [ + { + "name": "Products", + "url": "https://skip.money/products" + }, + { + "name": "Contact", + "url": "https://skip.money/contact" + }, + { + "name": "Research", + "url": "https://ideas.skip.money" + }, + { + "name": "Jobs", + "url": "https://jobs.skip.money" + } + ], + "modeToggle": { + "default": "dark" + }, + "topAnchor": { + "name": "Slinky", + "icon": "wand-magic-sparkles" + }, + "anchors": [ + { + "name": "Home", + "icon": "house", + "url": "https://skip.mintlify.app" + } + ], + "navigation": [ + { + "group": "Slinky", + "pages": [ + "docs/overview", + "docs/security-properties", + "docs/incentivize-slashing", + { + "group": "Validator Docs", + "pages": [ + "docs/validator-docs/quickstart", + "docs/validator-docs/validator-config-ref", + "docs/validator-docs/slinky-troubleshoot" + ] + }, + "docs/upcoming-features" + ] + } + ], + "footerSocials": { + "twitter": "https://twitter.com/skipprotocol", + "discord": "https://discord.com/invite/hFeHVAE26P" + } +} \ No newline at end of file diff --git a/style.css b/style.css new file mode 100644 index 000000000..e48449464 --- /dev/null +++ b/style.css @@ -0,0 +1,9 @@ +@import url('https://fonts.googleapis.com/css2?family=Inconsolata:wght@200..900&display=swap'); + +h1, h2, h3, #navbar { + font-family: "Inconsolata", monospace; +} + +.dark #navbar { + background-color: #121213; +}