chore(docs): Use lower case for full node

docs/content/_snippets/info-high-traffic.mdx

@@ -2,6 +2,6 @@
 
 It is suggested to use dedicated nodes/shared services rather than public endpoints for production apps with high traffic volume.
 
-You can either run your own Full nodes, or outsource this to a professional infrastructure provider (preferred for apps that have high traffic).
+You can either run your own full nodes, or outsource this to a professional infrastructure provider (preferred for apps that have high traffic).
 
 :::

docs/content/_snippets/initialize-iota-client-cli.mdx

@@ -7,13 +7,13 @@ See [Publish a Package](../developer/getting-started/publish.mdx) for a more det
 Before publishing your code, you must first initialize the IOTA Client CLI, if you haven't already. To do so, in a terminal or console at the root directory of the project enter `iota client`. If you receive the following response, complete the remaining instructions:
 
 ```
-Config file ["<FILE-PATH>/.iota/iota_config/client.yaml"] doesn't exist, do you want to connect to a IOTA Full node server [y/N]?
+Config file ["<FILE-PATH>/.iota/iota_config/client.yaml"] doesn't exist, do you want to connect to a IOTA full node server [y/N]?
 ```
 
 Enter `y` to proceed. You receive the following response:
 
 ```
-IOTA Full node server URL (Defaults to IOTA Devnet if not specified) :
+IOTA full node server URL (Defaults to IOTA Devnet if not specified) :
 ```
 
 Leave this blank (press Enter). You receive the following response:

docs/content/_snippets/warning-advanced-instructions-node-setup.mdx

@@ -1,6 +1,6 @@
 :::warning Advanced 
 
-These instructions are for setting up a Full node for network participation. If you just need a local development environment, 
-you should instead follow the instructions in [Create a Local IOTA Network](/developer/getting-started/local-network) to create a local Full node, validators, and faucet.
+These instructions are for setting up a full node for network participation. If you just need a local development environment, 
+you should instead follow the instructions in [Create a Local IOTA Network](/developer/getting-started/local-network) to create a local full node, validators, and faucet.
 
 :::

docs/content/developer/advanced/custom-indexer.mdx

@@ -1,14 +1,14 @@
 ---
 title: Custom Indexer
-description: You can build custom indexers using the IOTA micro-data ingestion framework. To create an indexer, you subscribe to a checkpoint stream with full checkpoint content. Establishing a custom indexer helps improve latency, allows pruning the data of your IOTA Full node, and provides efficient assemblage of checkpoint data.
+description: You can build custom indexers using the IOTA micro-data ingestion framework. To create an indexer, you subscribe to a checkpoint stream with full checkpoint content. Establishing a custom indexer helps improve latency, allows pruning the data of your IOTA full node, and provides efficient assemblage of checkpoint data.
 ---
 
 import Quiz from '@site/src/components/Quiz';
 import questions from '/json/developer/advanced-topics/custom-indexer.json';
 
 You can build custom indexers using the IOTA micro-data ingestion framework. To create an indexer, you subscribe to a checkpoint stream with full checkpoint content. This stream can be one of the publicly available streams from IOTA, one that you set up in your local environment, or a combination of the two.
 
-Establishing a custom indexer helps improve latency, allows pruning the data of your IOTA Full node, and provides efficient assemblage of checkpoint data.
+Establishing a custom indexer helps improve latency, allows pruning the data of your IOTA full node, and provides efficient assemblage of checkpoint data.
 
 ## Interface and Data Format
 
@@ -61,9 +61,9 @@ This is suitable for setups with a single ingestion pipeline where progress trac
 
 ### Local Reader
 
-Colocate the data ingestion daemon with a Full node and enable checkpoint dumping on the latter to set up a local stream source. After enabling, the Full node starts dumping executed checkpoints as files to a local directory, and the data ingestion daemon subscribes to changes in the directory through an inotify-like mechanism. This approach allows minimizing ingestion latency (checkpoint are processed immediately after a checkpoint executor on a Full node) and getting rid of dependency on an externally managed bucket.
+Colocate the data ingestion daemon with a full node and enable checkpoint dumping on the latter to set up a local stream source. After enabling, the full node starts dumping executed checkpoints as files to a local directory, and the data ingestion daemon subscribes to changes in the directory through an inotify-like mechanism. This approach allows minimizing ingestion latency (checkpoint are processed immediately after a checkpoint executor on a full node) and getting rid of dependency on an externally managed bucket.
 
-To enable, add the following to your [Full node configuration](../../operator/iota-full-node/overview.mdx) file:
+To enable, add the following to your [full node configuration](../../operator/iota-full-node/overview.mdx) file:
 
 ```yaml
 checkpoint-executor-config:
@@ -106,7 +106,7 @@ The concurrency parameter specifies how many threads the workflow uses. Having a
 
 ### Hybrid Mode
 
-Specify both a local and remote store as a fallback to ensure constant data flow. The framework always prioritizes locally available checkpoint data over remote data. It's useful when you want to start utilizing your own Full node for data ingestion but need to partially backfill historical data or just have a failover.
+Specify both a local and remote store as a fallback to ensure constant data flow. The framework always prioritizes locally available checkpoint data over remote data. It's useful when you want to start utilizing your own full node for data ingestion but need to partially backfill historical data or just have a failover.
 ```rust
 executor.run(
     PathBuf::from("./chk".to_string()), // path to a local directory

docs/content/developer/advanced/iota-repository.mdx

@@ -26,7 +26,7 @@ overview of the most important folders:
   IOTA.
 - [docker](https://github.com/iotaledger/iota/tree/develop/docker): Contains the docker files needed to spin up a node,
   an
-  indexer, a Full node, or other services.
+  indexer, a full node, or other services.
 - [docs](https://github.com/iotaledger/iota/tree/develop/docs): Contains this documentation and the source for this
   site.
 - [examples](https://github.com/iotaledger/iota/tree/develop/examples): Contains examples of apps written for IOTA and
@@ -59,7 +59,7 @@ The following primary directories offer a good starting point for exploring the
   0x2,
   0x3).
 - [iota-network](https://github.com/iotaledger/iota/tree/develop/crates/iota-network) - Networking interfaces.
-- [iota-node](https://github.com/iotaledger/iota/tree/develop/crates/iota-node) - Validator and Full node software.
+- [iota-node](https://github.com/iotaledger/iota/tree/develop/crates/iota-node) - Validator and full node software.
 - [iota-protocol-config](https://github.com/iotaledger/iota/tree/develop/crates/iota-protocol-config) - On-chain system
   configuration and limits.
 - [iota-sdk](https://github.com/iotaledger/iota/tree/develop/crates/iota-sdk) - The IOTA Rust SDK.

docs/content/developer/cryptography.mdx

@@ -15,7 +15,7 @@ Go to [Transaction Authentication](./cryptography/transaction-auth.mdx).
 ## Checkpoint Verification
 
 Checkpoints define the history of the IOTA blockchain, similarly to how blocks define the history of traditional blockchains like Bitcoin or Ethereum.
-For Full nodes and validators to trust a checkpoint, they must first verify it. Verification ensures that the checkpoint is a true checkpoint that the IOTA validator committee created.
+For full nodes and validators to trust a checkpoint, they must first verify it. Verification ensures that the checkpoint is a true checkpoint that the IOTA validator committee created.
 
 Go to [Checkpoint Verification](./cryptography/checkpoint-verification.mdx).
 

docs/content/developer/cryptography/checkpoint-verification.mdx

@@ -1,6 +1,6 @@
 ---
 title: Checkpoint Verification
-description: On the IOTA network, checkpoints define the history of the blockchain. Checkpoint verification is how Full nodes and other clients guarantee their state is exactly the same as the IOTA network.
+description: On the IOTA network, checkpoints define the history of the blockchain. Checkpoint verification is how full nodes and other clients guarantee their state is exactly the same as the IOTA network.
 ---
 
 import Quiz from '@site/src/components/Quiz';
@@ -14,15 +14,15 @@ Checkpoints contain:
 - A list of all the transaction digests (and the corresponding transaction effects digests) that are included in the checkpoint.
 - A set of signatures from a quorum (more than 2/3rds) of the validators that formed the committee at the time the checkpoint was created.
 
-Both validators and Full nodes consume checkpoints to remain synchronized with the network.
+Both validators and full nodes consume checkpoints to remain synchronized with the network.
 
 ## Checkpoint verification
 
-For Full nodes and validators to trust a checkpoint, they must first verify it. Verification ensures that the checkpoint is a true checkpoint that the IOTA validator committee created.
+For full nodes and validators to trust a checkpoint, they must first verify it. Verification ensures that the checkpoint is a true checkpoint that the IOTA validator committee created.
 
 Checkpoint verification requires two interdependent pieces:
 
-1. Assuming that the Full node (or other client) has the public keys of the validator committee that created the checkpoint, it can check the signatures on the checkpoint for validity.
+1. Assuming that the full node (or other client) has the public keys of the validator committee that created the checkpoint, it can check the signatures on the checkpoint for validity.
 
     Checkpoints are signed by the aggregated BLS signatures of a quorum of the committee.
     If the signatures are valid, the client now knows that the checkpoint was created by the validator committee, and not by some other party.
@@ -46,11 +46,11 @@ This allows the client to eventually verify all checkpoints up to the present ti
 
 After a client verifies a checkpoint, what can it do with that information?
 
-As mentioned earlier, a checkpoint contains a list of transactions so a Full node, for instance, can begin fetching and executing those transactions. Because the transactions are identified by their digest (a cryptographic hash), the client can be sure that the transactions it executes have not been altered.
+As mentioned earlier, a checkpoint contains a list of transactions so a full node, for instance, can begin fetching and executing those transactions. Because the transactions are identified by their digest (a cryptographic hash), the client can be sure that the transactions it executes have not been altered.
 
 Additionally, the checkpoint contains the effects digests of each transaction. The effects digest is the cryptographic hash of the `TransactionEffects`, which is itself a structure that lists all of the inputs and outputs of a transaction. It includes the digests of all objects that were written by the transaction.
-This allows a Full node to verify that it has obtained the same execution results as those that the validators attested to when signing the checkpoint.
+This allows a full node to verify that it has obtained the same execution results as those that the validators attested to when signing the checkpoint.
 
-By executing checkpoints, and verifying transaction outputs, a Full node can build up the entire state of the IOTA network (that is, the collection of objects in the network) and trust that every byte of every object is correct.
+By executing checkpoints, and verifying transaction outputs, a full node can build up the entire state of the IOTA network (that is, the collection of objects in the network) and trust that every byte of every object is correct.
 
 <Quiz questions={questions} />

docs/content/developer/exchange-integration/exchange-integration.mdx

@@ -11,21 +11,21 @@ This topic describes how to integrate IOTA, the token native to the IOTA network
 ## Requirements to configure a IOTA integration
 
 The requirements to configure a IOTA integration include:
- - A IOTA Full node. You can operate your own IOTA Full node or use a Full node from a node operator.
- - Suggested hardware requirements to run a IOTA Full node:
+ - A IOTA full node. You can operate your own IOTA full node or use a full node from a node operator.
+ - Suggested hardware requirements to run a IOTA full node:
     - CPU: 8 physical cores / 16 vCPUs
     - RAM: 128 GB
     - Storage (SSD): 4 TB NVMe drive
 
-For best results, run IOTA Full nodes on Linux. IOTA supports the Ubuntu and Debian distributions. You can also fun a Full node on macOS.
+For best results, run IOTA full nodes on Linux. IOTA supports the Ubuntu and Debian distributions. You can also fun a full node on macOS.
 
 ## Local testing
 
 You can develop and test your integration using a local development server. It will spin up a local network with some test nodes, an indexer, and a faucet. You can find detailed instructions in the [local development guide](../getting-started/local-network.mdx).
 
 ## Configure a IOTA Full node
 
-You can set up and configure a [IOTA Full node](../../operator/iota-full-node/overview.mdx) using Docker or directly from source code in the IOTA GitHub repository.
+You can set up and configure a [IOTA full node](../../operator/iota-full-node/overview.mdx) using Docker or directly from source code in the IOTA GitHub repository.
 
 ## Set up IOTA addresses
 
@@ -96,7 +96,7 @@ You can track balance changes by calling `iotax_getBalance` at predefined interv
 
 ### Using cURL
 
-The following bash example demonstrates how to use `iotax_getBalance` for address `0x849d63687330447431a2e76fecca4f3c10f6884ebaa9909674123c6c662612a3`. If you use a network other than Devnet, replace the value for `rpc` with the URL to the appropriate Full node.
+The following bash example demonstrates how to use `iotax_getBalance` for address `0x849d63687330447431a2e76fecca4f3c10f6884ebaa9909674123c6c662612a3`. If you use a network other than Devnet, replace the value for `rpc` with the URL to the appropriate full node.
 
 
 ```bash

docs/content/developer/iota-101/transactions/sponsored-transactions/use-sponsored-transactions.mdx

@@ -26,7 +26,7 @@ To set up a user-initiated sponsored transaction, follow these steps:
 2. **User sends `GasLessTransactionData` to the sponsor**: The user forwards the transaction data to the sponsor.
 3. **Sponsor validates and signs**: The sponsor reviews the transaction, constructs `TransactionData` with gas fees, and signs it.
 4. **Sponsor returns signed transaction**: The sponsor sends the signed `TransactionData` and their `Signature` back to the user.
-5. **User verifies and signs**: The user verifies the transaction, signs the `TransactionData`, and submits the dual-signed transaction to the IOTA network via a Full node or through the sponsor.
+5. **User verifies and signs**: The user verifies the transaction, signs the `TransactionData`, and submits the dual-signed transaction to the IOTA network via a full node or through the sponsor.
 
 ### Understanding `GasLessTransactionData`
 
@@ -96,7 +96,7 @@ Use the API endpoint to receive dual-signed `SenderSignedData` and return the tr
 pub fn submit_dual_signed_transaction(dual_signed_data: SenderSignedData) -> Result<(Transaction, CertifiedTransactionEffects), Error>;
 ```
 
-For user and sponsor-initiated transactions, users can submit the dual-signed transaction either through the sponsor or directly to a Full node.
+For user and sponsor-initiated transactions, users can submit the dual-signed transaction either through the sponsor or directly to a full node.
 
 #### Data Structures for Sponsored Transactions
 

docs/content/developer/standards/display.mdx

@@ -12,7 +12,7 @@ Use a `Publisher` object that you own to set `iota::display` for a type.
 
 In IOTA Move, `Display<T>` represents an object that specifies a set of named templates for the type `T`. For example, for a type `0x2::hero::Hero` the display syntax is:  `Display<0x2::hero::Hero>`.
 
-IOTA Full nodes process all objects of the type `T` by matching the `Display` definition, and return the processed result when you query an object with the `{ showDisplay: true }` setting in the query.
+IOTA full nodes process all objects of the type `T` by matching the `Display` definition, and return the processed result when you query an object with the `{ showDisplay: true }` setting in the query.
 
 ## Display properties
 

docs/content/operator/archives.mdx

@@ -1,14 +1,14 @@
 ---
 title: IOTA Archives
-description: The archive is a historical record of all transactions on IOTA. Enable archiving on your Full nodes as a best practice.
+description: The archive is a historical record of all transactions on IOTA. Enable archiving on your full nodes as a best practice.
 ---
 
 import Quiz from '@site/src/components/Quiz';
 import questions from '/json/node-operators/archives.json';
 
-An IOTA archive is a history of all transaction data on IOTA, trailing behind the latest checkpoint by 10 minutes. As an IOTA node operator, you can write this history to an object store like S3, GCS, or similar for safe keeping. Saving this archive data is considered a best practice because IOTA prunes transactions on Full nodes to remove historical transactions and their effects. Peer nodes, for example, might not catch up with all transactions and effects through synchronization if they lag behind the current epoch by more than the latest few epochs. Instead of relying on synchronization, peer nodes can fallback to downloading this information from an archive.
+An IOTA archive is a history of all transaction data on IOTA, trailing behind the latest checkpoint by 10 minutes. As an IOTA node operator, you can write this history to an object store like S3, GCS, or similar for safe keeping. Saving this archive data is considered a best practice because IOTA prunes transactions on full nodes to remove historical transactions and their effects. Peer nodes, for example, might not catch up with all transactions and effects through synchronization if they lag behind the current epoch by more than the latest few epochs. Instead of relying on synchronization, peer nodes can fallback to downloading this information from an archive.
 
-IOTA Archival nodes (Full nodes that write to an archive) don't store historical state on local storage and don't help query historical data. They serve the purpose of enabling peer nodes to catch up to the latest checkpoint and are useful for auditing and verifying the complete history of all transactions on the network.
+IOTA Archival nodes (full nodes that write to an archive) don't store historical state on local storage and don't help query historical data. They serve the purpose of enabling peer nodes to catch up to the latest checkpoint and are useful for auditing and verifying the complete history of all transactions on the network.
 
 ## Create an Archival node