celestiaorg · jcstein · Apr 22, 2025 · Apr 14, 2025 · Apr 14, 2025 · Apr 15, 2025
diff --git a/how-to-guides/bridge-node.md b/how-to-guides/bridge-node.md
@@ -13,7 +13,7 @@ Bridge nodes connect the data availability layer and the consensus layer.
 A Celestia bridge node has the following properties:
 
 1. Import and process “raw” headers & blocks from a trusted core process
-   (meaning a trusted RPC connection to a celestia-core node) in the
+   (meaning a trusted RPC connection to a consensus node) in the
    Consensus network. Bridge nodes can run this core process internally
    (embedded) or simply connect to a remote endpoint. Bridge nodes also
    have the option of being an active validator in the consensus network.
@@ -86,7 +86,7 @@ Using an RPC of your own, or one from the
 [list on the Arabica devnet page](/how-to-guides/arabica-devnet.md#community-rpc-endpoints),
 start your node.
 
-Connecting to a core endpoint with `--core.ip string`
+Connecting to a consensus node endpoint (flag: `--core.ip string`)
 provides the light node with access to state queries (reading balances, submitting
 transactions, and other state-related queries).
 
@@ -112,8 +112,7 @@ celestia bridge init --core.ip <URI> --core.port <port> \
 
 ### Run the bridge node
 
-Start the bridge node with a connection to a validator node's gRPC endpoint
-(which is usually exposed on port 9090):
+Start the bridge node with a connection to a consensus node's gRPC endpoint, which is usually exposed on port 9090:
 
 ```sh
 celestia bridge start --core.ip <URI> --core.port <port>

diff --git a/how-to-guides/celestia-app.md b/how-to-guides/celestia-app.md
@@ -18,7 +18,7 @@ This tutorial will guide you through installing celestia-app, both
 [a pre-built binary](#installing-a-pre-built-binary)
 
 Celestia-app is the software that allows you to run
-validator nodes and provide RPC endpoints.
+consensus nodes — including validators — and provide RPC endpoints.
 
 ## Building binary from source
 

diff --git a/how-to-guides/celestia-node-troubleshooting.md b/how-to-guides/celestia-node-troubleshooting.md
@@ -59,7 +59,7 @@ If you run a node on a cloud server, make sure that the ports are open
 on the server's firewall. If you run a node at home, make sure that your
 router allows connections to the correct ports.
 
-For example, validator ports 9090
+For example, validator (consensus node) ports 9090
 and 26657 need to be accessible by the bridge, and port 2121 is
 required for P2P connections for all node types.
 

diff --git a/how-to-guides/config-toml.md b/how-to-guides/config-toml.md
@@ -27,11 +27,11 @@ After initialization, for any type of node, you will find a
 
 Let's break down some of the most used sections.
 
-### Core
+### Core (Consensus)
 
 This section is needed for the Celestia bridge node.
 By default, `Remote = false`. Still for devnet, we are going
-to use the remote core option and this can also be set
+to use the remote consensus node option and this can also be set
 by the command line flag `--core.remote`.
 
 ### P2P
@@ -56,7 +56,7 @@ need to change the field `PeerExchange` from false to true.
 #### TrustedHash and TrustedPeer
 
 `TrustedHash` is needed to properly initialize a Celestia bridge
-node with an already-running `Remote` celestia-core node. Celestia
+node with an already-running `Remote` Celestia consensus node. Celestia
 light node will take a genesis hash as the trusted one, if no hash
 is manually provided during initialization phase.
 

diff --git a/how-to-guides/consensus-node.md b/how-to-guides/consensus-node.md
@@ -354,7 +354,7 @@ There are several ways to reset your consensus node, depending on what you need
 
 #### Option 1: Reset blockchain data with `reset-state`
 
-This command removes blockchain data but preserves validator state and address book:
+This command removes blockchain data but preserves validator state and address book of the consensus node:
 
 ```sh
 celestia-appd tendermint reset-state

diff --git a/how-to-guides/full-storage-node.md b/how-to-guides/full-storage-node.md
@@ -57,14 +57,14 @@ celestia full init --p2p.network arabica
 
 #### Start the full storage node
 
-Start the full storage node with a connection to a validator node's gRPC endpoint
+Start the full storage node with a connection to a consensus node's gRPC endpoint
 (which is usually exposed on port 9090):
 
 In order for access to the ability to get/submit
 state-related information, such as the ability to
 submit `PayForBlob` transactions, or query for the
 node's account balance, a gRPC endpoint of a validator
-(core) node must be passed as directed below.
+(consensus) node must be passed as directed below.
 
 :::warning Important
 Make sure port 2121 TCP/UDP is open and publicly accessible on your full storage node so it can be discovered by other peers in the DHT network. This port is essential for P2P connectivity and if not properly configured, your node won't be able to participate in the network effectively.
@@ -84,7 +84,7 @@ Using an RPC of your own, or one from
 [Arabica devnet](/how-to-guides/arabica-devnet.md#integrations),
 start your node.
 
-Connecting to a core endpoint with `--core.ip string`
+Connecting to a consensus node endpoint with `--core.ip string`
 provides the light node with access to state queries (reading balances, submitting
 transactions, and other state-related queries).
 
@@ -115,7 +115,7 @@ If you are running a full-storage node for your sovereign
 rollup, it is highly recommended to request Arabica devnet tokens
 as Arabica has the latest changes that can be used to
 test for developing your sovereign rollup. You can still use
-Mocha testnet as well, it is just mostly used for validator operations.
+the Mocha testnet as well, although it is primarily used for validator operations.
 :::
 
 ### Optional: run the full storage node with a custom key

diff --git a/how-to-guides/light-node.md b/how-to-guides/light-node.md
@@ -79,14 +79,14 @@ config. It will also show confirmation that the node store has been initialized.
 
 ## Start the light node
 
-Start the light node with a connection to a validator node's gRPC endpoint (which
+Start the light node with a connection to a consensus node's gRPC endpoint (which
 is usually exposed on port 9090):
 
 In order for access to the ability to get and submit
 state-related information, such as the ability to
 submit `PayForBlobs` transactions, or query for the
 node's account balance, a gRPC endpoint of a validator
-(core) node must be passed as directed below.
+(consensus) node must be passed as directed below.
 
 Refer to
 [the ports section of the celestia-node troubleshooting page](/how-to-guides/celestia-node-troubleshooting.md#ports)
@@ -177,9 +177,9 @@ $request <CELESTIA-ADDRESS>
 Where `<CELESTIA-ADDRESS>` is the `celestia1******` address generated
 when you created the wallet.
 
-### Optional: start light node with core endpoint with authentication
+### Optional: start light node with consensus node endpoint with authentication
 
-If you are running a light node with a core endpoint that requires authentication,
+If you are running a light node connected to a consensus node endpoint that requires authentication,
 you can pass the directory containing the json of your x-token to the light node with
 the following command:
 

diff --git a/how-to-guides/mainnet.md b/how-to-guides/mainnet.md
@@ -104,8 +104,8 @@ These RPC providers are meant to be used in production environments.
 | Numia | For data warehouse access: <https://docs.numia.xyz/sql/querying-data/chains/celestia> |
 | QuickNode | <https://www.quicknode.com/chains/celestia> ([docs](https://quicknode.com/docs/celestia)) |
 
-If you are using QuickNode or another provider with authentication of endpoints,
-see [the light node guide](/how-to-guides/light-node.md#optional-start-light-node-with-core-endpoint-with-authentication)
+If you are using QuickNode or another provider with authenticated endpoints,
+see [the light node guide](/how-to-guides/light-node.md#optional-start-light-node-with-consensus-node-endpoint-with-authentication)
 to learn how to use an endpoint with x-token.
 
 ### Community consensus endpoints

diff --git a/how-to-guides/snapshots.md b/how-to-guides/snapshots.md
@@ -20,7 +20,7 @@ There are two main types of snapshots available:
 
 Pruned snapshots contain only the essential state needed to run a node. They exclude historical data that isn't necessary for current operations, making them much smaller in size. These are ideal for:
 
-- Validator nodes that only need recent state to participate in consensus
+- Consensus nodes (including validators) that only need recent state to participate in consensus
 - Consensus nodes that don't need complete historical data
 - Users who want to get started quickly and aren't concerned with historical queries
 

diff --git a/tutorials/node-tutorial.md b/tutorials/node-tutorial.md
@@ -16,7 +16,7 @@ and retrieve data (blobs) from the data availability layer by their namespace.
 ### Blobs
 
 Data is posted to Celestia's DA layer by using `MsgPayForBlobs`
-transactions to the core network. Read
+transactions to the consensus node network. Read
 [more about `MsgPayForBlobs`](https://github.com/celestiaorg/celestia-app/blob/main/x/blob/README.md#messages).
 
 ### Namespaces
@@ -81,10 +81,10 @@ Instantiating (or initializing) the node means setting up
 a node store on your machine. This is where the data and
 your keys will be stored.
 
-### Connect to a core endpoint
+### Connect to a consensus node endpoint
 
 Let's now run the Celestia Light node with a gRPC connection
-to an example core endpoint. Connecting to a core endpoint
+to an example consensus node endpoint. Connecting to a consensus node endpoint
 provides the light node with access to state queries (reading balances, submitting
 transactions, and other state-related queries).
 
@@ -871,7 +871,7 @@ celestia share get-by-namespace \
 In order to post a blob using curl, you will need a light node running
 with the `--core.ip string` and `--core.port string` flags, providing access to a consensus
 endpoint.
-The flags indicate to the node to connect to the given core consensus node.
+The flags indicate to the node to connect to the given consensus node.
 Examples: `127.0.0.1` or `subdomain.domain.tld`.
 Using either IP or DNS assumes RPC port 26657 and gRPC port 9090
 as default unless otherwise specified.