Update formatting

ecosystem/supersim.md

@@ -160,35 +160,35 @@ Given the application flow, the following services will be part of supersim:
 
 1. **Orchestrator**: This is the main focus and interface for developers using supersim. 
     
-    i. Runs all of the other services in supersim and manages their lifecycle. 
-    ii. Provides an interface to the user
+    * Runs all of the other services in supersim and manages their lifecycle
+    * Provides an interface to the user
     
         * Initially a static interface.
         * Medium-term, offer an API interface that the orchestrator exposes to make it easier to build new offchain services that hook into the runtime.
 
 2. **Anvil Instances**: Anvil instances are run by the orchestrator after initial prep work to allow them to mirror the Superchain interop environment.
 
-    i. Should be run in `--optimism` mode so the extra fields in transactions are there.
-    ii. Orchestrator should also run an L1 instance, though L1 withdrawals won’t initially be supported.
-    iii. Eventually supersim can be extended to be used with HardHat and other local simulation tools as well.
+    * Should be run in `--optimism` mode so the extra fields in transactions are there.
+    * Orchestrator should also run an L1 instance, though L1 withdrawals won’t initially be supported.
+    * Eventually supersim can be extended to be used with HardHat and other local simulation tools as well.
 
 3. **Genesis-applier** : The `genesis-applier` takes genesis files output by the monorepo and applies them to anvil instances.
 
-    i. The genesis files needed will differ depending on whether the user is in vanilla or forked mode, and forked mode is unlikely to need anything other than the interop contracts initially. 
-    ii. Can be multi-step: multiple genesis files can be applied idempotently, particularly in forking mode (when you fork a network that has bedrock contracts but not interop contracts, for instance).
-    iii. Genesis-applier should work as a standalone tool: if a developer is using Anvil outside the context of the orchestrator, they should be able to use genesis-applier to apply genesis state to their instance. In the context of supersim, the `orchestrator` will use the `genesis-applier` to apply the needed genesis state to the anvil instances it is running. 
+    * The genesis files needed will differ depending on whether the user is in vanilla or forked mode, and forked mode is unlikely to need anything other than the interop contracts initially. 
+    * Can be multi-step: multiple genesis files can be applied idempotently, particularly in forking mode (when you fork a network that has bedrock contracts but not interop contracts, for instance).
+    * Genesis-applier should work as a standalone tool: if a developer is using Anvil outside the context of the orchestrator, they should be able to use genesis-applier to apply genesis state to their instance. In the context of supersim, the `orchestrator` will use the `genesis-applier` to apply the needed genesis state to the anvil instances it is running. 
 
 4. **Chain-config-loader**: Downloads the latest chain config from the superchain registry to allow the orchestrator to apply needed configs to anvil instances. Should be a standalone tool that works with the orchestrator but could be used directly on local testing nodes. 
 
 5. **L2-fork-state-finder**: From an L1 reference block, runs an algorithm to identify the latest L2 height derived from the L1 block for each network.
 
 6. **Op-simulator**: Proxy server in front of anvil instances that simulates op-stack services without the real derivation pipeline.
 
-    i. Simulates deposits by listening to the `optimismPortal` and forwarding deposit txs via `eth_sendRawTransaction`.
-    ii. Implements `eth_sendRawTransaction` and first applies any necessary out-of-protocol validation such as the interop spec variants.
-    iii. Calls `eth_getLog` on other chains to fetch event logs for invariant checks.
-    iv. All other rpc calls are proxied by the orchestrator to the anvil instances.
-    v. **Withdrawal pathway to Ethereum is not supported** (at least to start)
+    * Simulates deposits by listening to the `optimismPortal` and forwarding deposit txs via `eth_sendRawTransaction`.
+    * Implements `eth_sendRawTransaction` and first applies any necessary out-of-protocol validation such as the interop spec variants.
+    * Calls `eth_getLog` on other chains to fetch event logs for invariant checks.
+    * All other rpc calls are proxied by the orchestrator to the anvil instances.
+    * **Withdrawal pathway to Ethereum is not supported** (at least to start)
 
 ### Sequence Diagram