Terminology updates and edits

public/samples/ChainlinkFunctions/AutomatedFunctionsConsumerExample.sol

@@ -50,7 +50,7 @@ contract AutomatedFunctionsConsumerExample is FunctionsClient, ConfirmedOwner {
 
     /// @notice Update the request settings
     /// @dev Only callable by the owner of the contract
-    /// @param _request The new encoded CBOR request to be set. The request is encoded off-chain
+    /// @param _request The new encoded CBOR request to be set. The request is encoded offchain
     /// @param _subscriptionId The new subscription ID to be set
     /// @param _gasLimit The new gas limit to be set
     /// @param _donID The new job ID to be set

public/samples/ChainlinkFunctions/CustomAutomatedFunctionsConsumerExample.sol

@@ -87,7 +87,7 @@ contract CustomAutomatedFunctionsConsumerExample is
 
     /// @notice Update the request settings
     /// @dev Only callable by the owner of the contract
-    /// @param _request The new encoded CBOR request to be set. The request is encoded off-chain
+    /// @param _request The new encoded CBOR request to be set. The request is encoded offchain
     /// @param _subscriptionId The new subscription ID to be set
     /// @param _gasLimit The new gas limit to be set
     /// @param _donID The new job ID to be set

public/samples/DataStreams/StreamsUpkeep.sol

@@ -44,7 +44,7 @@ contract StreamsUpkeep is ILogAutomation, StreamsLookupCompatibleInterface {
         uint32 observationsTimestamp; // Latest timestamp for which price is applicable
         uint192 nativeFee; // Base cost to validate a transaction using the report, denominated in the chain’s native token (WETH/ETH)
         uint192 linkFee; // Base cost to validate a transaction using the report, denominated in LINK
-        uint32 expiresAt; // Latest timestamp where the report can be verified on-chain
+        uint32 expiresAt; // Latest timestamp where the report can be verified onchain
         int192 price; // DON consensus median price, carried to 8 decimal places
     }
 
@@ -54,7 +54,7 @@ contract StreamsUpkeep is ILogAutomation, StreamsLookupCompatibleInterface {
         uint32 observationsTimestamp; // Latest timestamp for which price is applicable
         uint192 nativeFee; // Base cost to validate a transaction using the report, denominated in the chain’s native token (WETH/ETH)
         uint192 linkFee; // Base cost to validate a transaction using the report, denominated in LINK
-        uint32 expiresAt; // Latest timestamp where the report can be verified on-chain
+        uint32 expiresAt; // Latest timestamp where the report can be verified onchain
         int192 price; // DON consensus median price, carried to 8 decimal places
         int192 bid; // Simulated price impact of a buy order up to the X% depth of liquidity utilisation
         int192 ask; // Simulated price impact of a sell order up to the X% depth of liquidity utilisation
@@ -101,7 +101,7 @@ contract StreamsUpkeep is ILogAutomation, StreamsLookupCompatibleInterface {
     // The Data Streams report bytes is passed here.
     // extraData is context data from feed lookup process.
     // Your contract may include logic to further process this data.
-    // This method is intended only to be simulated off-chain by Automation.
+    // This method is intended only to be simulated offchain by Automation.
     // The data returned will then be passed by Automation into performUpkeep
     function checkCallback(
         bytes[] calldata values,
@@ -110,7 +110,7 @@ contract StreamsUpkeep is ILogAutomation, StreamsLookupCompatibleInterface {
         return (true, abi.encode(values, extraData));
     }
 
-    // function will be performed on-chain
+    // function will be performed onchain
     function performUpkeep(bytes calldata performData) external {
         // Decode the performData bytes passed in by CL Automation.
         // This contains the data returned by your implementation in checkCallback().

public/samples/Functions/adding-functions-to-projects/docs-source-example.js

@@ -3,7 +3,7 @@
 // Expects a different consumer contract than FunctionsConsumer.sol.
 // Modify your consumer contract before using this example.
 
-// Arguments can be provided when a request is initiated on-chain and used in the request source code as shown below
+// Arguments can be provided when a request is initiated onchain and used in the request source code as shown below
 const coinGeckoCoinId = args[0]
 const coinPaprikaCoinId = args[1]
 const badApiCoinId = args[2]

public/samples/Functions/adding-functions-to-projects/example-source.js

@@ -5,7 +5,7 @@
 
 // Refer to https://github.com/smartcontractkit/functions-hardhat-starter-kit#javascript-code
 
-// Arguments can be provided when a request is initated on-chain and used in the request source code as shown below
+// Arguments can be provided when a request is initated onchain and used in the request source code as shown below
 const fromSymbol = args[0]
 const toSymbol = args[1]
 

src/config/sidebar.ts

@@ -94,11 +94,11 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
           url: "data-feeds/solana",
         },
         {
-          title: "Using Data Feeds Off-Chain",
+          title: "Using Data Feeds Offchain",
           url: "data-feeds/solana/using-data-feeds-off-chain",
         },
         {
-          title: "Using Data Feeds On-Chain",
+          title: "Using Data Feeds Onchain",
           url: "data-feeds/solana/using-data-feeds-solana",
         },
       ],
@@ -171,7 +171,7 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
               url: "architecture-overview/architecture-decentralized-model?parent=dataFeeds",
             },
             {
-              title: "Off-Chain Reporting",
+              title: "Offchain Reporting",
               url: "architecture-overview/off-chain-reporting?parent=dataFeeds",
             },
           ],
@@ -278,7 +278,7 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
               url: "architecture-overview/architecture-decentralized-model?parent=dataStreams",
             },
             {
-              title: "Off-Chain Reporting",
+              title: "Offchain Reporting",
               url: "architecture-overview/off-chain-reporting?parent=dataStreams",
             },
           ],
@@ -445,7 +445,7 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
               url: "architecture-overview/architecture-decentralized-model?parent=automation",
             },
             {
-              title: "Off-Chain Reporting",
+              title: "Offchain Reporting",
               url: "architecture-overview/off-chain-reporting?parent=automation",
             },
           ],
@@ -636,7 +636,7 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
               url: "architecture-overview/architecture-decentralized-model?parent=chainlinkFunctions",
             },
             {
-              title: "Off-Chain Reporting",
+              title: "Offchain Reporting",
               url: "architecture-overview/off-chain-reporting?parent=chainlinkFunctions",
             },
           ],
@@ -790,7 +790,7 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
               url: "architecture-overview/architecture-decentralized-model?parent=vrf",
             },
             {
-              title: "Off-Chain Reporting",
+              title: "Offchain Reporting",
               url: "architecture-overview/off-chain-reporting?parent=vrf",
             },
           ],
@@ -976,7 +976,7 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
               url: "architecture-overview/architecture-decentralized-model?parent=ccip",
             },
             {
-              title: "Off-Chain Reporting",
+              title: "Offchain Reporting",
               url: "architecture-overview/off-chain-reporting?parent=ccip",
             },
           ],
@@ -1277,7 +1277,7 @@ export const SIDEBAR: Partial<Record<Sections, SectionEntry[]>> = {
               url: "architecture-overview/architecture-decentralized-model",
             },
             {
-              title: "Off-Chain Reporting",
+              title: "Offchain Reporting",
               url: "architecture-overview/off-chain-reporting",
             },
           ],

src/content/any-api/api-reference.mdx

@@ -360,7 +360,7 @@ function expectResponseFor(bytes32 _requestId)
 
 <Aside type="caution" title="Be careful adding external requests">
 
-Being able to change a request means that you can change the data fed into a contract. Permissioning someone to make external requests can allow them to change the outcome of your contract. You should be sure to make sure that they are a trusted to do so. If they are not trusted to do so, you should put the request making logic on-chain where it is auditable and tamperproof.
+Being able to change a request means that you can change the data fed into a contract. Permissioning someone to make external requests can allow them to change the outcome of your contract. You should be sure to make sure that they are a trusted to do so. If they are not trusted to do so, you should put the request making logic onchain where it is auditable and tamperproof.
 
 </Aside>
 
@@ -379,7 +379,7 @@ In case an oracle node does not respond, it may be necessary to retrieve the LIN
 
 The default expiration for a request is five minutes, after which it can be cancelled. The cancellation must be sent by the address which was specified as the callback location of the contract.
 
-For the sake of efficient gas usage, only a hash of the request's parameters are stored on-chain. In order to validate the terms of the request and that it can be calculated, the request parameters must be provided. Additionally, cancellation must be called by the address which the callback would otherwise have been called on.
+For the sake of efficient gas usage, only a hash of the request's parameters are stored onchain. In order to validate the terms of the request and that it can be calculated, the request parameters must be provided. Additionally, cancellation must be called by the address which the callback would otherwise have been called on.
 
 `cancelChainlinkRequest` emits a [ChainlinkCancelled](#chainlinkcancelled) event.
 
@@ -560,7 +560,7 @@ library Chainlink {
 
 The Chainlink Request struct encapsulates all of the fields needed for a Chainlink request and its corresponding response callback.
 
-The Chainlink protocol aims to be flexible and not restrict application developers. The Solidity Chainlink Request model is a great example of that. It is exceptionally flexible, given the limitations of Solidity. The request can contain an arbitrary amount of keys and values to be passed off-chain to the oracles for each request. It does so by converting the parameters into CBOR, and then storing them in a buffer. This allows for any number of parameters all of different types to be encoded on-chain.
+The Chainlink protocol aims to be flexible and not restrict application developers. The Solidity Chainlink Request model is a great example of that. It is exceptionally flexible, given the limitations of Solidity. The request can contain an arbitrary amount of keys and values to be passed offchain to the oracles for each request. It does so by converting the parameters into CBOR, and then storing them in a buffer. This allows for any number of parameters all of different types to be encoded onchain.
 
 The request's ID is generated by hashing the sender's address and the request's nonce. This scheme ensures that only the requester can generate their request ID, and no other contract can trigger a response from an oracle with that ID. New requests whose IDs match an unfulfilled request ID will not be accepted by the oracle.
 
@@ -745,7 +745,7 @@ function setBuffer(
 )
 ```
 
-Set the CBOR payload directly on the request object, avoiding the cost of encoding the parameters in CBOR. This can be helpful when reading the bytes from storage or having them passed in from off-chain where they were pre-encoded.
+Set the CBOR payload directly on the request object, avoiding the cost of encoding the parameters in CBOR. This can be helpful when reading the bytes from storage or having them passed in from offchain where they were pre-encoded.
 
 {/* prettier-ignore */}
 ```solidity
@@ -762,6 +762,6 @@ function requestPrice(bytes _cbor)
 
 <Aside type="caution" title="Be careful setting the request buffer directly">
 
-Moving the CBOR encoding logic off-chain can save some gas, but it also opens up the opportunity for people to encode parameters that not all parties agreed to. Be sure that whoever is permissioned to call `setBuffer` is trusted or auditable.
+Moving the CBOR encoding logic offchain can save some gas, but it also opens up the opportunity for people to encode parameters that not all parties agreed to. Be sure that whoever is permissioned to call `setBuffer` is trusted or auditable.
 
 </Aside>

src/content/any-api/get-request/examples/existing-job-request.mdx

@@ -30,7 +30,7 @@ Using an _existing_ Oracle Job makes your smart contract code more succinct. Thi
 
 ## Example
 
-In [Single Word Response Example](/any-api/get-request/examples/single-word-response), the example contract code declared which URL to use, where to find the data in the response, and how to convert it so that it can be represented on-chain.
+In [Single Word Response Example](/any-api/get-request/examples/single-word-response), the example contract code declared which URL to use, where to find the data in the response, and how to convert it so that it can be represented onchain.
 
 This example uses an existing job that is pre-configured to make requests to get [the gas price](https://docs.etherscan.io/api-endpoints/gas-tracker#get-gas-oracle). Using specialized jobs makes your contracts succinct and more simple.
 

src/content/any-api/getting-started.mdx

@@ -4,7 +4,7 @@ date: Last Modified
 title: "Getting Started with Any API"
 excerpt: "Calling APIs from Smart Contracts"
 whatsnext:
-  { "Learn how to bring data on-chain and do off-chain computation using Chainlink Functions": "/chainlink-functions" }
+  { "Learn how to bring data onchain and do offchain computation using Chainlink Functions": "/chainlink-functions" }
 metadata:
   image: "/files/04b8e56-cl.png"
 ---
@@ -33,7 +33,7 @@ The request and receive cycle describes how a smart contract requests data from
 
 For contracts that use [Chainlink VRF](/vrf), you request randomness from a VRF oracle and then await the response. The fulfillment function is already given to us from the `VRFConsumerBase` contract, so oracles already know where to send the response to. However, with API calls, the contract itself _defines_ which function it wants to receive the response to.
 
-Before creating any code, you should understand how Oracle jobs can get data on-chain.
+Before creating any code, you should understand how Oracle jobs can get data onchain.
 
 ## What are jobs?
 

src/content/any-api/introduction.mdx

@@ -30,7 +30,7 @@ import { Aside } from "@components"
   documentation](/chainlink-functions) to learn more.
 </Aside>
 
-**Connecting to any API** with Chainlink enables your contracts to access to _any_ external data source through our decentralized oracle network. We understand making smart contracts compatible with off-chain data adds to the complexity of building smart contracts. We created a framework with minimal requirements, yet unbounded flexibility, so developers can focus more on the functionality of smart contracts rather than what feeds them. Chainlink’s decentralized oracle network provides smart contracts with the ability to push and pull data, facilitating the interoperability between on-chain and off-chain applications.
+**Connecting to any API** with Chainlink enables your contracts to access to _any_ external data source through our decentralized oracle network. We understand making smart contracts compatible with offchain data adds to the complexity of building smart contracts. We created a framework with minimal requirements, yet unbounded flexibility, so developers can focus more on the functionality of smart contracts rather than what feeds them. Chainlink’s decentralized oracle network provides smart contracts with the ability to push and pull data, facilitating the interoperability between onchain and offchain applications.
 
 Whether your contract requires sports results, the latest weather, or any other publicly available data, the [Chainlink contract library](https://github.com/smartcontractkit/chainlink/tree/master/contracts) provides the tools required for your contract to consume it.
 
@@ -42,9 +42,9 @@ If your smart contracts need access to price feed data, try using [Chainlink Dat
 
 </Aside>
 
-### Requesting off-chain data
+### Requesting offchain data
 
-Outlined below are multiple ways developers can connect smart contracts to off-chain data feeds. Click a request type to learn more about it:
+Outlined below are multiple ways developers can connect smart contracts to offchain data feeds. Click a request type to learn more about it:
 
 | Request Type                                                                                | Description                                                                                                                                                                                                                                                                                                        |
 | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |