docs: remove Arabica network references

.github/workflows/README.md

@@ -23,7 +23,7 @@ This directory contains the workflows used to lint, deploy, and keep release met
 ## `latest-tags.yaml` — Latest Tags
 
 - **Triggers:** every 6 hours, or manual `workflow_dispatch` with `network`.
-- **What it does:** for each network (`mainnet`, `arabica`, `mocha`), fetches the latest matching GitHub Release tags for `celestiaorg/celestia-app` and `celestiaorg/celestia-node`, resolves them to commit SHAs, updates `constants/<network>_versions.json`, and opens a PR if values changed.
+- **What it does:** for each network (`mainnet`, `mocha`), fetches the latest matching GitHub Release tags for `celestiaorg/celestia-app` and `celestiaorg/celestia-node`, resolves them to commit SHAs, updates `constants/<network>_versions.json`, and opens a PR if values changed.
 - **Required secret:** `PAT_CREATE_PR` (token used by `peter-evans/create-pull-request` to push a branch and open a PR in this repo). Uses `GITHUB_TOKEN` for API reads.
 
 ## Notes

.github/workflows/latest-tags.yaml

@@ -9,7 +9,6 @@ on:
         type: choice
         options:
           - mainnet
-          - arabica
           - mocha
   schedule:
     - cron: '0 */6 * * *'
@@ -24,7 +23,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        network: ${{ fromJSON(github.event_name == 'workflow_dispatch' && format('["{0}"]', github.event.inputs.network) || '["mainnet","arabica","mocha"]') }}
+        network: ${{ fromJSON(github.event_name == 'workflow_dispatch' && format('["{0}"]', github.event.inputs.network) || '["mainnet","mocha"]') }}
     permissions:
       contents: write
       pull-requests: write
@@ -47,7 +46,6 @@ jobs:
             const network = process.env.NETWORK;
 
             const networkSuffix = network === 'mainnet' ? null : `-${network}`;
-            const nonMainnetSuffixes = new Set(['-arabica', '-mocha']);
 
             async function getLatestReleaseTag(repo) {
               const releases = await github.paginate(github.rest.repos.listReleases, {
@@ -64,10 +62,7 @@ jobs:
 
                 if (networkSuffix) return tag.endsWith(networkSuffix);
 
-                for (const suffix of nonMainnetSuffixes) {
-                  if (tag.endsWith(suffix)) return false;
-                }
-                return true;
+                return !tag.slice(1).includes('-');
               });
 
               if (!match) {

README.md

@@ -106,14 +106,13 @@ This section outlines the standards and guidelines for maintaining consistent, h
 - **Sentence case**: use sentence case for headings and titles (reference: https://github.com/celestiaorg/docs/issues/161)
 - **No “click here”**: avoid using “click here” for link text (reference: https://github.com/celestiaorg/docs/issues/1073)
 - **International English**: use international (common) English spelling and terminology
-- **Network names**: use “Arabica devnet”, not “Arabica Devnet”
 - **Node types**: use lowercase for node types (e.g., “bridge node”, not “Bridge Node”)
 - **Politeness**: avoid using “please” in instructional content
 - **Unique headings**: ensure no duplicate headings within a document
 - **Network references**: use "Mainnet Beta" network (note the specific capitalization)
 - **Latin abbreviations**: use italicized _i.e._ or _e.g._ instead of plain i.e. or e.g.
 - **Code references**: use “celestia-app” in regular text (not inline code) when referring to the application name
-- **Tab ordering**: when using tabs, order them as: Mainnet Beta, Mocha, Arabica
+- **Tab ordering**: when using network tabs, order them as: Mainnet Beta, Mocha
 - **Placeholders**: use angle brackets with underscores for placeholders: `<flag_name>` not `<flag-name>` or `<flag name>`
 
 ### Documentation update procedures

app/learn/TIA/submit-data/page.mdx

@@ -16,7 +16,7 @@ The _exact_ maximum total blob size in a transaction depends on:
 - the share version and layout rules,
 - and the fact that the **first sparse share has 478 bytes**, while **all subsequent sparse shares have 482 bytes**.
 
-The current max square size on Arabica is 128 MiB, Mocha is 32 MiB, and Mainnet is 8 MiB.
+The current max square size on Mocha is 32 MiB, and Mainnet Beta is 8 MiB.
 
 Under v6 and future upgrades, networks will use larger square sizes, so the absolute maximum blob capacity per transaction will increase correspondingly—up to the global **8 MiB transaction size limit**, which is now the binding constraint.
 
@@ -178,7 +178,7 @@ state config in `config.toml`. Each mode has different throughput characteristic
 ### Default behavior (TxWorkerAccounts = 0)
 
 By default, `TxWorkerAccounts` is set to `0`, which means queued submission is disabled. All PayForBlobs transactions are submitted
-immediately to the mempool without waiting for confirmations. This is the same behavior as versions prior to [v0.28.2-arabica](https://github.com/celestiaorg/celestia-node/releases/tag/v0.28.2-arabica).
+immediately to the mempool without waiting for confirmations. This is the same behavior as versions before queued submission was introduced.
 
 The mempool maintains a fork of the canonical state each block, updating the sequence number (nonce) for each account that submits a
 transaction. If you wish to submit multiple transactions from the same account in quick succession, you must specify the nonce
@@ -217,7 +217,7 @@ directly without waiting for confirmations.
 ### Parallel transaction submission (TxWorkerAccounts > 1)
 
 <Callout type="info" title="Network availability">
-This feature is currently available on Arabica devnet and Mocha testnet (v0.28.2-arabica and later).
+This feature is currently available on Mocha testnet.
 </Callout>
 
 For high-throughput applications that do not require sequential transaction ordering, you can enable parallel transaction submission

app/operate/consensus-validators/consensus-node/page.mdx

@@ -36,7 +36,7 @@ Follow the tutorial on [installing `celestia-app`](/operate/consensus-validators
 To initialize the network, pick a "node-name" that describes your
 node. Keep in mind that this might change if a new testnet is deployed.
 
-<Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+<Tabs items={['Mainnet Beta', 'Mocha']}>
   <Tabs.Tab>
     ```bash
     celestia-appd init "node-name" --chain-id {{constants['mainnetChainId']}}
@@ -47,16 +47,11 @@ node. Keep in mind that this might change if a new testnet is deployed.
     celestia-appd init "node-name" --chain-id {{constants['mochaChainId']}}
     ```
   </Tabs.Tab>
-  <Tabs.Tab>
-    ```bash
-    celestia-appd init "node-name" --chain-id {{constants['arabicaChainId']}}
-    ```
-  </Tabs.Tab>
 </Tabs>
 
 Download the `genesis.json` file:
 
-<Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+<Tabs items={['Mainnet Beta', 'Mocha']}>
   <Tabs.Tab>
     ```bash
     celestia-appd download-genesis {{constants['mainnetChainId']}}
@@ -67,16 +62,11 @@ Download the `genesis.json` file:
     celestia-appd download-genesis {{constants['mochaChainId']}}
     ```
   </Tabs.Tab>
-  <Tabs.Tab>
-    ```bash
-    celestia-appd download-genesis {{constants['arabicaChainId']}}
-    ```
-  </Tabs.Tab>
 </Tabs>
 
 Set seeds in the `$HOME/.celestia-app/config/config.toml` file:
 
-<Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+<Tabs items={['Mainnet Beta', 'Mocha']}>
   <Tabs.Tab>
     ```bash
     SEEDS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/{{constants['mainnetChainId']}}/seeds.txt | tr '\n' ',')
@@ -91,14 +81,6 @@ Set seeds in the `$HOME/.celestia-app/config/config.toml` file:
     sed -i.bak -e "s/^seeds *=.*/seeds = \"$SEEDS\"/" $HOME/.celestia-app/config/config.toml
     ```
   </Tabs.Tab>
-  <Tabs.Tab>
-    ```bash
-    # For Arabica, you can set seeds manually in the
-    # `$HOME/.celestia-app/config/config.toml` file:
-    # Comma separated list of seed nodes to connect to
-    seeds = ""
-    ```
-  </Tabs.Tab>
 </Tabs>
 
 </Steps>
@@ -109,9 +91,9 @@ Set seeds in the `$HOME/.celestia-app/config/config.toml` file:
 You can set persistent peers in your `config.toml` file. If you set persistent peers, your node will **always** try to connect to these peers. This is useful when running a local devnet, for example, when you would always want to connect to the same local nodes in your devnet. In production, setting persistent peers is advised only if you are running a [sentry node](https://hub.cosmos.network/main/validators/security.html#sentry-nodes-ddos-protection).
 </Callout>
 
-You can get the persistent peers from the [@cosmos/chain-registry](https://github.com/cosmos/chain-registry) repository (for Mainnet Beta) or [@celestiaorg/networks repository](https://github.com/celestiaorg/networks) repo (for Mocha and Arabica) with the following commands:
+You can get the persistent peers from the [@cosmos/chain-registry](https://github.com/cosmos/chain-registry) repository (for Mainnet Beta) or [@celestiaorg/networks repository](https://github.com/celestiaorg/networks) repo (for Mocha) with the following commands:
 
-<Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+<Tabs items={['Mainnet Beta', 'Mocha']}>
   <Tabs.Tab>
     ```bash
     PERSISTENT_PEERS=$(curl -s https://raw.githubusercontent.com/cosmos/chain-registry/master/{{constants['mainnetChainId']}}/chain.json | jq -r '.peers.persistent_peers[].address' | tr '\n' ',' | sed 's/,$/\n/')
@@ -126,13 +108,6 @@ You can get the persistent peers from the [@cosmos/chain-registry](https://githu
     sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.celestia-app/config/config.toml
     ```
   </Tabs.Tab>
-  <Tabs.Tab>
-    ```bash
-    PERSISTENT_PEERS=$(curl -sL https://raw.githubusercontent.com/celestiaorg/networks/master/{{constants['arabicaChainId']}}/peers.txt | tr '\n' ',')
-    echo $PERSISTENT_PEERS
-    sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$PERSISTENT_PEERS\"/" $HOME/.celestia-app/config/config.toml
-    ```
-  </Tabs.Tab>
 </Tabs>
 
 ## Storage and pruning configurations
@@ -284,7 +259,7 @@ copied from.
 
 Run the following command to quick-sync from a snapshot:
 
-<Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+<Tabs items={['Mainnet Beta', 'Mocha']}>
   <Tabs.Tab>
     ```bash
     cd $HOME
@@ -307,17 +282,6 @@ Run the following command to quick-sync from a snapshot:
     tar xf celestia-snap.tar -C ~/.celestia-app/data/
     ```
   </Tabs.Tab>
-  <Tabs.Tab>
-    ```bash
-    cd $HOME
-    rm -rf ~/.celestia-app/data
-    mkdir -p ~/.celestia-app/data
-    SNAP_NAME=$(curl -s https://snaps.qubelabs.io/celestia/ | \
-        egrep -o ">{{constants['arabicaChainId']}}.*tar" | tr -d ">")
-    aria2c -x 16 -s 16 -o celestia-snap.tar "https://snaps.qubelabs.io/celestia/${SNAP_NAME}"
-    tar xf celestia-snap.tar -C ~/.celestia-app/data/
-    ```
-  </Tabs.Tab>
 </Tabs>
 
 <Callout type="info">
@@ -339,7 +303,7 @@ celestia-appd start --rpc.grpc_laddr tcp://0.0.0.0:9098
 
 If you are running celestia-app v2.x.x then you'll want to start the node with a `--v2-upgrade-height` that is dependent on the network. The `--v2-upgrade-height` flag is only needed during the v2 upgrade height so after your node has executed the upgrade (e.g. you see the log `upgraded from app version 1 to 2`), you don't need to provide this flag for future `celestia-appd start` invocations.
 
-<Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+<Tabs items={['Mainnet Beta', 'Mocha']}>
   <Tabs.Tab>
     ```sh
     celestia-appd start --v2-upgrade-height 2371495
@@ -350,11 +314,6 @@ If you are running celestia-app v2.x.x then you'll want to start the node with a
     celestia-appd start --v2-upgrade-height 2585031
     ```
   </Tabs.Tab>
-  <Tabs.Tab>
-    ```sh
-    celestia-appd start --v2-upgrade-height 1751707
-    ```
-  </Tabs.Tab>
 </Tabs>
 
 

app/operate/consensus-validators/install-celestia-app/page.mdx

@@ -46,7 +46,7 @@ Be sure to select the correct network to install the binary for.
 
 ### Check out the desired version
 
-   <Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+   <Tabs items={['Mainnet Beta', 'Mocha']}>
      <Tabs.Tab>
        ```bash
        git checkout tags/{{mainnetVersions['app-latest-tag']}}
@@ -57,11 +57,6 @@ Be sure to select the correct network to install the binary for.
        git checkout tags/{{mochaVersions['app-latest-tag']}}
        ```
      </Tabs.Tab>
-     <Tabs.Tab>
-       ```bash
-       git checkout tags/{{arabicaVersions['app-latest-tag']}}
-       ```
-     </Tabs.Tab>
    </Tabs>
 
 ### Build and install the `celestia-appd` binary with multiplexer support

app/operate/consensus-validators/validator-node/page.mdx

@@ -61,10 +61,9 @@ is properly configured in your consensus node's `app.toml` file. The `[grpc]`
 section should have `enable = true` and the appropriate address setting for the
 bridge node to connect successfully.
 
-Using an RPC of your own, or one from
-[Mainnet Beta](/operate/networks/mainnet-beta#integrations),
-[Mocha testnet](/operate/networks/mocha-testnet#rpc-for-da-bridge-full-and-light-nodes) or
-[Arabica devnet](/operate/networks/arabica-devnet#integrations),
+Using an RPC of your own, or one listed for
+[Mainnet Beta](/operate/networks/mainnet-beta#integrations) or
+[Mocha testnet](/operate/networks/mocha-testnet#rpc-for-da-bridge-full-and-light-nodes),
 initialize your node.
 
 ### Run the bridge node
@@ -94,7 +93,7 @@ In order to create a validator on-chain, follow the steps below.
 
 1. Export an environment variable for the chain ID you want to run on:
 
-   <Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+   <Tabs items={['Mainnet Beta', 'Mocha']}>
      <Tabs.Tab>
        ```bash
        export CHAIN_ID={{constants['mainnetChainId']}}
@@ -105,11 +104,6 @@ In order to create a validator on-chain, follow the steps below.
        export CHAIN_ID={{constants['mochaChainId']}}
        ```
      </Tabs.Tab>
-     <Tabs.Tab>
-       ```bash
-       export CHAIN_ID={{constants['arabicaChainId']}}
-       ```
-     </Tabs.Tab>
    </Tabs>
 
 1. Export more environment variables.
@@ -125,26 +119,9 @@ In order to create a validator on-chain, follow the steps below.
    export VALIDATOR_PUBKEY=$(celestia-appd tendermint show-validator)
    ```
 
-1. If you want to create a validator on a testnet that is on app version 4 (currently only Arabica), you will need to create a `validator.json` file.
-
-   **Arabica:**
-   ```bash
-   cat <<EOF > validator.json
-   {
-     "pubkey": $VALIDATOR_PUBKEY,
-     "amount": "1000000utia",
-     "moniker": "$MONIKER",
-     "commission-rate": "0.1",
-     "commission-max-rate": "0.2",
-     "commission-max-change-rate": "0.01",
-     "min-self-delegation": "1"
-   }
-   EOF
-   ```
-
 1. Create a validator
 
-   <Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+   <Tabs items={['Mainnet Beta', 'Mocha']}>
      <Tabs.Tab>
        ```bash
        celestia-appd tx staking create-validator \
@@ -189,16 +166,6 @@ In order to create a validator on-chain, follow the steps below.
            --yes
        ```
      </Tabs.Tab>
-     <Tabs.Tab>
-       ```bash
-       celestia-appd tx staking create-validator validator.json \
-           --from $VALIDATOR_WALLET \
-           --keyring-backend test \
-           --fees 21000utia \
-           --gas=220000 \
-           --yes
-       ```
-     </Tabs.Tab>
    </Tabs>
 
 You should see output like:

app/operate/data-availability/bridge-node/page.mdx

@@ -84,8 +84,7 @@ Refer to
 for information on which ports are required to be open on your machine.
 
 Using an RPC of your own, or one from the
-[list on the Mocha testnet page](/operate/networks/mocha-testnet#community-rpc-endpoints) or
-[list on the Arabica devnet page](/operate/networks/arabica-devnet#community-rpc-endpoints),
+[list on the Mocha testnet page](/operate/networks/mocha-testnet#community-rpc-endpoints),
 start your node.
 
 Connecting to a consensus node endpoint (flag: `--core.ip string`)
@@ -95,7 +94,7 @@ transactions, and other state-related queries).
 Here is an example of initializing the bridge node:
 
 
-<Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+<Tabs items={['Mainnet Beta', 'Mocha']}>
   <Tabs.Tab>
     ```sh
     celestia bridge init --core.ip <URI> --core.port <port>
@@ -107,12 +106,6 @@ Here is an example of initializing the bridge node:
         --p2p.network mocha
     ```
   </Tabs.Tab>
-  <Tabs.Tab>
-    ```sh
-    celestia bridge init --core.ip <URI> --core.port <port> \
-        --p2p.network arabica
-    ```
-  </Tabs.Tab>
 </Tabs>
 
 
@@ -130,12 +123,6 @@ Here is an example of starting the bridge node on Mocha:
 celestia bridge start --core.ip rpc-mocha.pops.one --core.port 9090 --p2p.network mocha
 ```
 
-And on Arabica:
-
-```sh
-celestia bridge start --core.ip validator-1.celestia-{{constants['arabicaChainId']}}.com \
-  --p2p.network arabica --core.port 9090
-```
 <Callout type="info">
 If you're connecting your bridge node to a localhost consensus node (`--core.ip localhost` or `--core.ip 127.0.0.1`), ensure that gRPC is enabled in your consensus node's `app.toml` configuration file. Look for the `[grpc]` section and verify that `enable = true` is set:
 </Callout>
@@ -170,7 +157,6 @@ You do not need to declare a network for Mainnet Beta. Refer to
 You can get testnet tokens from:
 
 - [Mocha](/operate/networks/mocha-testnet)
-- [Arabica](/operate/networks/arabica-devnet)
 
 > **Note:** If you are running a bridge node for your validator, it is highly recommended to request Mocha testnet tokens as this is the testnet used to test out validator operations.
 
@@ -183,7 +169,7 @@ In order to run a bridge node using a custom key:
 2. The name of the custom key must be passed upon `start`, like so:
 
 
-<Tabs items={['Mainnet Beta', 'Mocha', 'Arabica']}>
+<Tabs items={['Mainnet Beta', 'Mocha']}>
   <Tabs.Tab>
     ```sh
     celestia bridge start --core.ip <URI> --keyring.keyname <name-of-custom-key> \
@@ -196,12 +182,6 @@ In order to run a bridge node using a custom key:
         --p2p.network mocha --core.port <port>
     ```
   </Tabs.Tab>
-  <Tabs.Tab>
-    ```sh
-    celestia bridge start --core.ip <URI> --keyring.keyname <name-of-custom-key> \
-        --p2p.network arabica --core.port <port>
-    ```
-  </Tabs.Tab>
 </Tabs>