update cosmetics; compress long lists (#7)

jito-labs · Aug 26, 2024 · 1c3b40b · 1c3b40b
1 parent cb0b798
commit 1c3b40b
Show file tree

Hide file tree

Showing 8 changed files with 64 additions and 52 deletions.
diff --git a/docs/images/Jitolabs_Logo_Green.svg b/docs/images/Jitolabs_Logo_Green.svg
diff --git a/docs/requirements.txt b/docs/requirements.txt
@@ -3,4 +3,5 @@ sphinx-rtd-theme==2.0.0
 docutils>=0.19
 myst-parser==4.0.0
 sphinx-fontawesome==0.0.6
+sphinx-copybutton==0.5.2
 #sphinxemoji==0.3.0
diff --git a/docs/source/conf.py b/docs/source/conf.py
@@ -19,6 +19,7 @@
     'sphinx.ext.intersphinx',
     'myst_parser',
     'sphinx_fontawesome',
+    'sphinx_copybutton',
 #    'sphinxemoji.sphinxemoji',
 ]
 

diff --git a/docs/source/howdoessytemwork.md b/docs/source/howdoessytemwork.md
@@ -1,6 +1 @@
-## How does the system work
 
-What do bundles do?
-How do they work?
-What is the auction?
-How does it roughly work at something between 30,000 foot view and ground floor?
diff --git a/docs/source/index.md b/docs/source/index.md
@@ -1,3 +1,4 @@
+![Jito Labs](../images/Jitolabs_Logo_Green.svg)
 # About Jito
 
 Developing high-performance systems to enhance Solana's scalability and maximize rewards for validators and stakers
@@ -11,12 +12,19 @@ Jito Labs develops high-performance MEV infrastructure for Solana with the follo
   3. Maximizing MEV returns to users and stakers 📈
 
 ```{toctree}
-:maxdepth: 2
+:maxdepth: 1
 :hidden:
 
 Intro <prodandaudience.md>
 
 ⚡ Low Latency Transaction Sending <lowlatencytxnsend.md>
+  ```{toctree}
+  :maxdepth: 2
+  :hidden:
+
+  System Overview <lowlatencytxnsend.md#system-overview>
+  API Documentation <lowlatencytxnsend.md#api>
+  Tips <lowlatencytxnsend.md#tips>
 
 
 ➤ Low Latency Transaction Feed (ShreadStream) <lowlatencytxnfeed.md>

diff --git a/docs/source/lowlatencytxnfeed.md b/docs/source/lowlatencytxnfeed.md
@@ -44,7 +44,7 @@ The proxy client connects to the Jito Block Engine and authenticates using the p
 
 View logs with `docker logs -f jito-shredstream-proxy`
 
-### Host Networking (Recommended)
+### 🐳 Host Networking (Recommended)
 
 This exposes all ports, bypassing Docker NAT.
 
@@ -62,7 +62,7 @@ docker run -d \
 jitolabs/jito-shredstream-proxy shredstream
 ```
 
-### Bridge Networking
+### 🚝 Bridge Networking
 
 Use bridge networking in environments where Docker host networking is unavailable. This setup requires manual exposure of each destination. For shred listeners running locally on the Docker host, use Docker's bridge IP (typically `172.17.0.1`). For non-local endpoints, use their regular IP addresses. Note that Docker's bridge IP can vary, so confirm it by running: `ip -brief address show dev docker0`.
 
@@ -82,7 +82,8 @@ docker run -d \
 jitolabs/jito-shredstream-proxy shredstream
 ```
 
-### Running Natively
+### 🦾 Running Natively
+
 
 ```bash
 git clone https://github.com/jito-labs/shredstream-proxy.git --recurse-submodules
@@ -94,29 +95,17 @@ RUST_LOG=info cargo run --release --bin jito-shredstream-proxy -- shredstream \
     --dest-ip-ports 127.0.0.1:8001,10.0.0.1:8001
 ```
 
-### Firewall Configuration
+### 📛 Firewall Configuration
 
 If you use a firewall, allow access to the following IPs:
 
-**Amsterdam**
-- 74.118.140.240
-- 202.8.8.174
-
-**Frankfurt**
-- 145.40.93.84
-- 145.40.93.41
-
-**New York**
-- 141.98.216.96
-- 64.130.48.56
-
-**SLC**
-- 64.130.53.8
-- 64.130.53.57
-
-**Tokyo**
-- 202.8.9.160
-- 202.8.9.19
+| Location        | IP Addresses                                     |
+|-----------------|--------------------------------------------------|
+| 🇳🇱 Amsterdam       | `74.118.140.240`, `202.8.8.174`                  |
+| 🇩🇪 Frankfurt       | `145.40.93.84`, `145.40.93.41`                   |
+| 🇺🇸 New York        | `141.98.216.96`, `64.130.48.56`                  |
+| 🇺🇸 Salt Lake City  | `64.130.53.8`, `64.130.53.57`                    |
+| 🇯🇵 Tokyo           | `202.8.9.160`, `202.8.9.19`                      |
 
 ## Troubleshooting
 
@@ -126,3 +115,4 @@ To verify, query the number of packets received before and after configuring Shr
 
 ```sql
 SELECT shred_count FROM "shred_fetch" WHERE time > now() - 1h
+```
diff --git a/docs/source/lowlatencytxnsend.md b/docs/source/lowlatencytxnsend.md
@@ -6,31 +6,31 @@ Jito provides Solana MEV users with superior transaction execution through fast
 
 ## System Overview
 
-How does the system work?
+### 🌐 How does the system work?
 
 - Jito provides a modified Solana validator client called J- ito-Solana that enables MEV extraction and rewards
 - It uses a block engine to simulate and process MEV trades
 - A relayer acts as a proxy to filter and verify transactions for validators
 - Validators running Jito-Solana can receive MEV rewards in addition to regular staking rewards
 - JitoSOL is a liquid staking token that allows users to stake SOL and receive MEV rewards
 
-What do Bundles do?
+### 💼 What do Bundles do?
 
 - Bundles are groups of transactions packaged together
 - They allow traders to propose profitable transaction orderings
 - Bundles are executed sequentially, atomically, and all-or-nothing
 - They can include tips to validators for priority treatment
 - Bundles enable complex MEV strategies like atomic arbitrage
 
-How do Bundles work?
+### 📬 How do Bundles work?
 
 - Traders submit bundle bids to block engines
 - Block engines simulate bundles to determine the most profitable combinations
 - Winning bundles are sent to validators to include in blocks
 - Validators execute bundles atomically and collect tips
 - MEV rewards from bundles are distributed to validators and stakers
 
-What is the auction?
+### ⚖️ What is the auction?
 
 - Traders submit bids for bundle execution in an auction process
 - Block engines run simulations to determine highest value bundles
@@ -39,19 +39,25 @@ What is the auction?
 - It reduces network spam and congestion from MEV trading
 - Auction proceeds are distributed to validators and stakers as rewards
 
+---
+
 ## API
 You can send JSON-RPC requests to any Block Engine using the following URLs. To route to a specific region, specify the desired region:
 
-- **Mainnet:** `https://mainnet.block-engine.jito.wtf`
-- **Amsterdam:** `https://amsterdam.mainnet.block-engine.jito.wtf`
-- **Frankfurt:** `https://frankfurt.mainnet.block-engine.jito.wtf`
-- **New York:** `https://ny.mainnet.block-engine.jito.wtf`
-- **Tokyo:** `https://tokyo.mainnet.block-engine.jito.wtf`
-- **Salt Lake City:** `https://slc.mainnet.block-engine.jito.wtf`
+| Location        | URL                                                     |
+|-----------------|---------------------------------------------------------|
+| 🌍 🌎 🌏 **Mainnet**         | `https://mainnet.block-engine.jito.wtf`             |
+| 🇳🇱 **Amsterdam**         | `https://amsterdam.mainnet.block-engine.jito.wtf`     |
+| 🇩🇪 **Frankfurt**         | `https://frankfurt.mainnet.block-engine.jito.wtf`     |
+| 🇺🇸 **New York**          | `https://ny.mainnet.block-engine.jito.wtf`            |
+| 🇯🇵 **Tokyo**             | `https://tokyo.mainnet.block-engine.jito.wtf`         |
+| 🇺🇸 **Salt Lake City**    | `https://slc.mainnet.block-engine.jito.wtf`           |
+
 
-### Transactions
+### 📨 Transactions(`/api/v1/transactions`)
 
 For single transaction-related methods, use the URL path `/api/v1/transactions`
+
 For example: `https://mainnet.block-engine.jito.wtf/api/v1/transactions`
 
 #### sendTransaction
@@ -117,7 +123,7 @@ Do we offer mev-protection here?
 
         Example: api/v1/bundles?uuid=<uuid>
 
-### Bundles
+### 💼 Bundles (`/api/v1/bundles`)
 
 Bundles are a list of up to 5 transactions that execute sequentially and atomically, ensuring an all-or-nothing outcome. Here’s what that means:
 
@@ -129,7 +135,7 @@ Bundles are a list of up to 5 transactions that execute sequentially and atomica
 
 This guarantees that all transactions in a bundle are executed in sequence and either all succeed or none are executed.
 
-For bundle-related methods, use the URL path /api/v1/bundles. Refer to the documentation to see the available JSON-RPC endpoints for bundles.
+For bundle-related methods, use the URL path `/api/v1/bundles`. Refer to the documentation to see the available JSON-RPC endpoints for bundles.
 
 #### sendBundle
 
@@ -405,12 +411,11 @@ curl https://mainnet.block-engine.jito.wtf/api/v1/bundles -X POST -H "Content-Ty
 }
 ```
 
-
-
 ## Tips
 
-### Tip Amount
+### 🪙 Tip Amount
 
+#### sendTransaction
 When using `sendTransaction`, it is recommended to use a 70/30 split between priority fee and jito tip.
 
 Example:
@@ -424,14 +429,16 @@ So, when using sendTransaction:
     You would allocate 0.7 SOL as the priority fee.
     And 0.3 SOL as the Jito tip.
 
-
+#### sendBundle
 When using `sendBundle`, only the Jito tip matters.
 
 
-### Get Tip Info
-REST API endpoint showing most recent tip amounts: http://bundles-api-rest.jito.wtf/api/v1/bundles/tip_floor
+### 💸 Get Tip Information
+REST API endpoint showing most recent tip amounts:
+`http://bundles-api-rest.jito.wtf/api/v1/bundles/tip_floor`
 
-WebSocket showing tip amounts: ws://bundles-api-rest.jito.wtf/api/v1/bundles/tip_stream
+WebSocket showing tip amounts:
+`ws://bundles-api-rest.jito.wtf/api/v1/bundles/tip_stream`
 
 ## Rate limits
 What are the defaults?

diff --git a/docs/source/prodandaudience.md b/docs/source/prodandaudience.md
@@ -4,8 +4,8 @@
 
 Jito provides specialized solutions tailored to the needs of Solana MEV users:
 
-- Fast Transaction Sending: Essential for any Solana MEV user requiring rapid and reliable transaction execution.
-- Bundles: Offers MEV protection, fast transaction landing, support for multiple transactions, and revert protection, making it ideal for developers of Telegram bots and automated trading systems.
-- Shredstream: Ensures minimal latency for receiving shreds to any RPC or validator on the network, saving hundreds of milliseconds during trading on Solana. It also provides a redundant shred path for servers in remote locations, enhancing reliability.
+- 🌪️ **Fast Transaction Sending:** Essential for any Solana MEV user requiring rapid and reliable transaction execution.
+- 💼 **Bundles:** Offers MEV protection, fast transaction landing, support for multiple transactions, and revert protection, making it ideal for developers of Telegram bots and automated trading systems.
+- 🧲 **Shredstream:** Ensures minimal latency for receiving shreds to any RPC or validator on the network, saving hundreds of milliseconds during trading on Solana. It also provides a redundant shred path for servers in remote locations, enhancing reliability.
 
 These use cases offer a competitive edge to traders, bot developers, and anyone seeking robust MEV protection in the Solana ecosystem.