switchboard-xyz · mgild · Feb 5, 2024 · Feb 12, 2024 · Mar 11, 2024
diff --git a/website/docs/00-overview.mdx b/website/docs/00-overview.mdx
@@ -108,10 +108,3 @@ and submits the data back to the Data Feed Program for protocols to utilize.
 requests to the program and receive directly back in their own program.
 
 </CustomDetails>
-
-
-<CustomDetails header="Tokens">
-
-to be completed
-
-</CustomDetails>
diff --git a/website/docs/101-architecture/00-switchboard-v3/103-economic-security.mdx b/website/docs/101-architecture/00-switchboard-v3/103-economic-security.mdx
@@ -1,6 +1,6 @@
 ---
 slug: ./economic-security
-title: Economic Security WIP
+title: 🚧 Economic Security
 keywords:
   [Switchboard, web3, oracle, data feeds, vrf, randomness, solana, aptos]
 ---

diff --git a/website/docs/101-architecture/00-switchboard-v3/104-queue.mdx b/website/docs/101-architecture/00-switchboard-v3/104-queue.mdx
@@ -1,6 +1,6 @@
 ---
 slug: ./queue
-title: Queue WIP
+title: 🚧 Queue
 ---
 
 ## Work in progress

diff --git a/website/docs/101-architecture/00-switchboard-v3/105-attestation-program.mdx b/website/docs/101-architecture/00-switchboard-v3/105-attestation-program.mdx
@@ -1,6 +1,6 @@
 ---
 slug: ./attestation-program
-title: Attestation Program WIP
+title: 🚧 Attestation Program
 ---
 
 ## Work in progress

diff --git a/website/docs/101-architecture/00-switchboard-v3/110-data-models.mdx b/website/docs/101-architecture/00-switchboard-v3/110-data-models.mdx
@@ -1,6 +1,6 @@
 ---
 slug: ./data-model
-title: The Data Models WIP
+title: 🚧 The Data Models
 keywords:
   [Switchboard, web3, oracle, data feeds, vrf, randomness, solana, aptos]
 ---

diff --git a/website/docs/101-architecture/10-data-feed-services/30-on-demand-service.mdx b/website/docs/101-architecture/10-data-feed-services/30-on-demand-service.mdx
@@ -0,0 +1,124 @@
+---
+slug: ../on-demand-service
+title: On Demand Service
+keywords: [Switchboard, web3, oracle, data feeds]
+---
+
+import MarkdownImage from "/src/components/MarkdownImage";
+import { Box, Typography, Grid } from "@mui/material";
+import Link from "@docusaurus/Link";
+import CustomAdmonition from "/src/components/CustomAdmonition";
+
+<CustomAdmonition type="tip">
+
+Switchboard On Demand Service exclusively propagates quantitative data, if you 
+wish to securely formulate your own complete transactions on-chain, please see 
+the [Switchboard Function Service](../function-service)
+
+</CustomAdmonition>
+
+Oracles are **NOT** a one-size-fits-all solution. While some solutions 
+focus very narrowly on pricing fidelity, other's focus on risk management
+or customizability. Switchboard has pioneered the customizable oracle solution 
+through our Data Feed Builder and have been heavily involved in the step-wise 
+evolutions of each of these arch-types and, after viewing market behavior, 
+have seen many pain points remain in oracles as a blockchain primitive.
+
+### Introducing Switchboard On Demand Service
+
+<CustomAdmonition type="note">
+
+The On Demand Service is currently supported on Solana. Future expansion of the 
+service to other ecosystems/blockchains are to subject to demand.
+
+To start using it, read the [Request From On Demand Service Guide](../../solana/data-feed-guides/request-from-on-demand-service).
+
+</CustomAdmonition>
+
+The Switchboard On Demand Service is built on the principles of:
+- [ ] Highest data security level to the protocol
+- [ ] Lowest cost to maintain data
+- [ ] Fastest oracle in any blockchain
+- [ ] Easiest to build and develop with
+
+To dive into the Switchboard On Demand architecture, let's review all personas in 
+its request lifecycle:
+
+| Entity                  | Role                                                                                                                                                                                       |
+|-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Guardian                | A set of peer SGX-verified machines that is onboarded through a DAO approval before kicking off the SGX verification process for the entire process. |
+| Oracle Queue            | Read about [Switchboard Queues](../switchboard-v3/queue). In short, Switchboard utilizes Queues to segragate different network operations run by different set of nodes and/or protocols. |
+| On-Demand Oracle        | An oracle that acts as its own web service, hosting a REST API to fetch and sign data where users pay for and to utilize on-chain. The On Demand Oracle is different from a Push Oracle, and as such have been broken down into 3 components: |
+| Oracle Router Frontend  | To mitigate DOS risks on oracles' public web service, a dedicated frontend is implemented to traffic control unfiltered public access from price processing infrastructure. |
+| Oracle Router (Gateway) | A Gateway is utilized to route how requests are distributed between the queue where it takes into consideration: **current oracle stake, current oracle performance, oracle self-advertised capacity (oracles are slashed if they over-advertise), and oracle successful liveness checks**. |
+| Oracle Worker           | This is the ultimate destination of a user request where the data is fetched, processed, and signed. |
+| Data Feed               | A Data Feed is deployed on IPFS and its hash will be fetched upon every request to be executed. |
+| Data Feed (Job)         | A Data Feed can be built with a combination of multiple jobs, typically each job represents a data source such as a job for Binance and another for Jupiter. This allows oracles to take a median from these results |
+| Data Feed (Task)        | A Data Feed consists of multiple jobs built using task types. These task types facilitate the composition of the jobs, such as an `HttpTask` or `JupiterSwapTask`. Check out our list of [task types](../../api/protos/Task).
+
+### Oracle Onboarding Procedure
+
+1. Guardians are DAO-approved and onboarded to the network as the root of SGX attestations.
+2. Oracle gets DAO approval to join the default queue.
+3. Guardians attest SGX quotes of the onboarding oracle and add it to the oracle queue.
+
+### Request Lifecycle
+
+1. User requests Data Feed from Gateway and receives a signature-set in response.
+2. User posts signatures on-chain and updates price in their transaction.
+
+### Configuration WIP
+
+1. [Build your own jobs](../../solana/data-feed-guides/build-data-feeds) to utilize in data feeds.
+2. Understand [data feeds best practices](../../solana/data-feed-guides/data-feed-best-practices).
+3. Create on-chain data feed account and integration.
+3. Submit requests when users invoke.
+
+### Data Feed Composability WIP [MIGRATE TO BUILD DATA FEEDS](../../solana/data-feed-guides/build-data-feeds)
+
+Data feeds may reference other data feeds and build upon each other. It is
+**_strongly_** recommended that you own any feed that you reference in case of
+downstream impacts out of your control.
+
+As an example, you could construct the following feed definition:
+
+- Create a Switchboard feed that sources SOL/USD prices from a variety of
+  exchanges, each weighted by their 7d volume, along with a history buffer
+- Create a Switchboard feed that uses an OracleTask to fetch the Pyth SOL/USD
+  price every 10 seconds, along with a history buffer
+- Create a Switchboard feed that uses an OracleTask to fetch the Chainlink
+  SOL/USD price every 10 seconds, along with a history buffer
+- Finally, create a Switchboard feed that calculates the 1min TWAP of each
+  source above and returns the median of the results
+
+This is just a small window into how Switchboard feeds can build on each other
+and let the downstream consumer configure their feeds to meet their own use
+cases.
+
+### Latency WIP
+
+**How fast is this? Do we have a set of data that we can back it up with?**
+
+### Cost WIP
+
+Since end users submits the requests for an update, the users are to pay for 
+the update. Each data feed update cost can be calculated by the following equation:
+
+$T_{costPerUpdate}=(1 + numSuccess) × T_{queueReward}$
+
+where,
+
+- `T` is the raw token amount in base units (_Ex: lamports or satoshis_)
+- _`+1`_ is to reward the update requester for keeping the feed updating
+- `numSuccess` is the number of successful oracle responses, which will always
+  be between `[aggregator.minOracleResults, aggregator.oracleRequestBatchSize]`
+- `queue.reward` is the queue's set oracle reward
+
+If an update round fails to receive `minOracleResults`, only the update
+requester receives funds from the lease escrow.
+
+<CustomAdmonition type="note">
+
+On the default permissionless queue on Solana, the rewards are at 12500 lamports.
+
+</CustomAdmonition>
diff --git a/...101-architecture/40-data-feed-service.mdx → ...10-data-feed-services/40-push-service.mdx b/...101-architecture/40-data-feed-service.mdx → ...10-data-feed-services/40-push-service.mdx
@@ -1,11 +1,9 @@
 ---
-slug: ./data-feed-service
-title: Data Feed Service WIP
+slug: ../push-service
+title: ❓ Push Service
 keywords: [Switchboard, web3, oracle, data feeds]
 ---
 
-## Work in progress
-
 import MarkdownImage from "/src/components/MarkdownImage";
 import { Box, Typography, Grid } from "@mui/material";
 import Link from "@docusaurus/Link";

diff --git a/website/docs/101-architecture/10-data-feed-services/_category_.json b/website/docs/101-architecture/10-data-feed-services/_category_.json
@@ -0,0 +1,3 @@
+{
+  "label": "Data Feed Service"
+}
diff --git a/website/docs/101-architecture/50-randomness-service.mdx b/website/docs/101-architecture/50-randomness-service.mdx
@@ -1,45 +1,92 @@
 ---
 slug: ./randomness-service
-title: Randomness Service WIP
+title: Randomness Service
 keywords:
-  [
-    Switchboard,
-    web3,
-    oracle,
-    randomness,
-    vrf,
-    solana,
-    evm,
-    arbitrum,
-    core,
-    coredao,
-  ]
+  [Switchboard, web3, oracle, randomness, vrf, solana, evm, arbitrum, core, coredao,]
 ---
 
-## Work in progress
+import CustomAdmonition from "/src/components/CustomAdmonition";
+
+<CustomAdmonition type="caution">
+
+Be wary and skeptical of teams claiming they offer true randomness from 
+both on-chain and off-chain sources!
+
+</CustomAdmonition>
 
 While true-randomness on some computers can be made possible via atmospheric
 noise and special hardware modules, such solutions on blockchains are not
 possible since they are virtual machines without physical hardware. Thus,
-pseudorandom-functions are needed to close this gap. **_You should be skeptical
-of teams claiming they offer true randomness._**
+pseudorandom-functions are needed to close this gap. 
 
-Random numbers are crucial for many DeFi applications whether its fair NFT
-launches, gambling, gaming, or assigning user roles in a DAO. Without an element
-of randomness, each of the above could be exploited and the final outcome
-predicted.
+Random numbers are crucial for many types of applications whether its fair NFT
+mints, gambling, gaming, etc. Without an element of randomness, each of the 
+above could be exploited and the final outcome predicted.
 
 Switchboard has had a Verifiable Random Function (VRF) deployed on Solana since
 February 2022. While this is not going away, it should be replaced in favor of
-using a [Switchboard Function](/functions) to generate randomness within a TEE
-and perform the callback into the users program. The Solana VRF implementation
-required 40+ transactions in order to perform the necessary computations while a
-Switchboard Function will take only a single transaction to settle resulting in
-a better user experience.
+using a the [V3 oracle infrastructure](./switchboard/tee) to generate randomness 
+within a TEE and optimize latency, costs and developer experience.
+
+<CustomAdmonition type="info">
+
+The Solana VRF implementation required 40+ transactions in order to perform the 
+necessary computations while a Switchboard Function will take only a single 
+transaction to settle, resulting in a better developer and user experience.
+
+**Read below to find out the costs and latency for the Randomness Service!**
+
+</CustomAdmonition>
+
+### Introducing Switchboard Randomness Service
+
+The Randomness Service uses a Switchboard SGX enabled oracle to provide randomness 
+to any Solana program using a callback instruction. The Service Product allows you 
+as a developer and user of Switchboard to seamlessly tap into common use cases such 
+as randomness, hence, through this method of usage, you do not need to run your own 
+queue or function to achieve a set of on-chain randomness byte(s).
+
+<CustomAdmonition type="note">
+
+The Randomness Service is currently supported on Solana. Future expansion of the 
+service to other ecosystems/blockchains are to subject to demand.
+
+To start using it, read the [Requesting From Randomness Service Guide](../solana/randomness-guides/request-from-randomness-service).
+
+</CustomAdmonition>
+
+### Request lifecycle
+
+1. User's program invokes the `simple_randomness_v1` instruction with a CPI call along with the number of randomness bytes, the custom callback instruction, and the priority fee configuration.
+    - Creates a `SimpleRandomnessV1Account` account
+    - Sets the custom callback
+    - Wraps funds into an escrow to reward the oracle for fulfilling the request
+2. Off-chain SGX enabled oracle reads the request account
+    - Generates random bytes inside of the enclave
+    - Builds a transaction with your callback and desired priority fees
+    - Simulates the transaction. If successful, relays the transaction on-chain.
+        - If error, relays an error instruction with the error message which is viewable in a blockchain explorer.
+3. Transaction relayed on-chain
+    - Oracle rewarded for fulfilling request
+    - Oracle invokes the users callback instruction
+    - Request account is closed and the rent-exemption is returned to the original payer
+
+### Latency
+
+Each randomness request round trip is about 1-2 slots latency. However this will subject 
+to network health and confirmation time.
+
+### Costs
+
+Each randomness request cost can be calculated by the following equation: 
 
-:::tip
+$$
+T_{costPerRequest}=T_{transactionCost}+T_{oracleReward}+T_{userPriorityFee}
+$$
 
-A [**Switchboard Function**](/functions) can be used to generate randomness
-within a secure enclave.
+where,
 
-:::
+* `T` is the raw token amount in base units, in this case lamports
+* `transactionCost` = 10_000 lamports
+* `oracleReward` = 10_000 lamports
+* `userPriorityFee` = user defined amount of lamports
diff --git a/website/docs/101-architecture/60-function-service.mdx b/website/docs/101-architecture/60-function-service.mdx
@@ -1,6 +1,6 @@
 ---
 slug: ./function-service
-title: Function Service WIP
+title: ❓ Function Service
 keywords: [Switchboard, web3, oracle, serverless]
 description:
   "Learn about Switchboard Functions and how they can be used to write custom

diff --git a/website/docs/101-architecture/70-secrets-service.mdx b/website/docs/101-architecture/70-secrets-service.mdx
@@ -1,19 +1,12 @@
 ---
-slug: /secrets-service
-title: Secrets Service
+slug: ./secrets-service
+title: 🚧 Secrets Service
 keywords: [Switchboard, web3, oracle, data feeds]
 ---
 
 import CustomAdmonition from "/src/components/CustomAdmonition";
 
-<CustomAdmonition type="info">
-
-Dive deeper into the usage of Secrets Server here: 
-[Secrets Server Github Repository](https://github.com/switchboard-xyz/sbv3/tree/main/apps/secrets-server)
-
-</CustomAdmonition>
-
-## What are Secrets?
+### What are Secrets?
 Secrets are sensitive information like API keys, passwords, and database 
 credentials. In order to bring these types of information on-chain without 
 leaking the secrets, it is important to store them securely so unauthorized 
@@ -38,4 +31,20 @@ individuals cannot access/tamper with them.
   and only decrypt them within the SGX enclave for confidentiality and security.
 * **Easy integration:** Easily access your secrets directly from your Switchboard 
   Function with simple SDK calls.
-* **Self-hosting option:** You can self-host the server for ultimate control and privacy.
+* **Self-hosting option:** You can self-host the server for ultimate control and privacy.
+
+### How to use
+
+<CustomAdmonition type="construction">
+
+We're currently working on a `SecretTask` as part of our Data Feed Service, allowing 
+you to run jobs that can fetch from private endpoints.
+
+</CustomAdmonition>
+
+<CustomAdmonition type="info">
+
+To run your own Secrets Server, please refer to our 
+[Secrets Server Github Repository](https://github.com/switchboard-xyz/sbv3/tree/main/apps/secrets-server).
+
+</CustomAdmonition>