fix: terminology link

docs/docusaurus.config.js

@@ -84,7 +84,10 @@ module.exports = {
           label: "More",
           position: "left",
           items: [
-            { label: "Terminology", to: "terminology" },
+            {
+              label: "Terminology",
+              href: "https://solana.com/docs/terminology",
+            },
             { label: "Staking", to: "staking" },
             { label: "Integrations", to: "integrations/exchange" },
             { label: "Economics", to: "economics_overview" },

docs/src/api/deprecated/_getFees.mdx

@@ -51,7 +51,7 @@ The result will be an RpcResponse JSON object with `value` set to a JSON object
 - `blockhash: <string>` - a Hash as base-58 encoded string
 - `feeCalculator: <object>` - FeeCalculator object, the fee schedule for this block hash
 - `lastValidSlot: <u64>` - DEPRECATED - this value is inaccurate and should not be relied upon
-- `lastValidBlockHeight: <u64>` - last [block height](../../terminology.md#block-height) at which the blockhash will be valid
+- `lastValidBlockHeight: <u64>` - last [block height](https://solana.com/docs/terminology#block-height) at which the blockhash will be valid
 
 </CodeParams>
 

docs/src/api/methods/_getBlock.mdx

@@ -242,7 +242,7 @@ Transactions are quite different from those on other blockchains. Be sure to rev
 
 The JSON structure of a transaction is defined as follows:
 
-- `signatures: <array[string]>` - A list of base-58 encoded signatures applied to the transaction. The list is always of length `message.header.numRequiredSignatures` and not empty. The signature at index `i` corresponds to the public key at index `i` in `message.accountKeys`. The first one is used as the [transaction id](../../terminology.md#transaction-id).
+- `signatures: <array[string]>` - A list of base-58 encoded signatures applied to the transaction. The list is always of length `message.header.numRequiredSignatures` and not empty. The signature at index `i` corresponds to the public key at index `i` in `message.accountKeys`. The first one is used as the [transaction id](https://solana.com/docs/terminology#transaction-id).
 - `message: <object>` - Defines the content of the transaction.
   - `accountKeys: <array[string]>` - List of base-58 encoded public keys used by the transaction, including by the instructions and for signatures. The first `message.header.numRequiredSignatures` public keys must sign the transaction.
   - `header: <object>` - Details the account types and signatures required by the transaction.

docs/src/api/methods/_getLatestBlockhash.mdx

@@ -46,7 +46,7 @@ Configuration object containing the following fields:
 `RpcResponse<object>` - RpcResponse JSON object with `value` field set to a JSON object including:
 
 - `blockhash: <string>` - a Hash as base-58 encoded string
-- `lastValidBlockHeight: <u64>` - last [block height](../../terminology.md#block-height) at which the blockhash will be valid
+- `lastValidBlockHeight: <u64>` - last [block height](https://solana.com/docs/terminology#block-height) at which the blockhash will be valid
 
 </CodeParams>
 

docs/src/api/methods/_getSignatureStatuses.mdx

@@ -12,7 +12,7 @@ import {
 
 ## getSignatureStatuses
 
-Returns the statuses of a list of signatures. Each signature must be a [txid](/terminology#transaction-id), the first signature of a transaction.
+Returns the statuses of a list of signatures. Each signature must be a [txid](https://solana.com/docs/terminology#transaction-id), the first signature of a transaction.
 
 :::info
 Unless the `searchTransactionHistory` configuration parameter is included,

docs/src/api/methods/_sendTransaction.mdx

@@ -36,7 +36,7 @@ Before submitting, the following preflight checks are performed:
    preflight commitment to avoid confusing behavior.
 
 The returned signature is the first signature in the transaction, which
-is used to identify the transaction ([transaction id](../../terminology.md#transaction-id)).
+is used to identify the transaction ([transaction id](https://solana.com/docs/terminology#transaction-id)).
 This identifier can be easily extracted from the transaction data before
 submission.
 
@@ -88,7 +88,7 @@ Values: `base58` (_slow_, **DEPRECATED**), or `base64`.
 
 ### Result:
 
-`<string>` - First Transaction Signature embedded in the transaction, as base-58 encoded string ([transaction id](../../terminology.md#transaction-id))
+`<string>` - First Transaction Signature embedded in the transaction, as base-58 encoded string ([transaction id](https://solana.com/docs/terminology#transaction-id))
 
 </CodeParams>
 

docs/src/api/websocket/_signatureSubscribe.mdx

@@ -35,7 +35,7 @@ transaction signature, as base-58 encoded string
 :::info
 
 The transaction signature must be the first signature from the transaction (see
-[transaction id](/terminology#transaction-id) for more details).
+[transaction id](https://solana.com/docs/terminology#transaction-id) for more details).
 
 :::
 

docs/src/cli/deploy-a-program.md

@@ -2,8 +2,9 @@
 title: Deploy a Program
 ---
 
-Developers can deploy on-chain [programs](terminology.md#program) (often called
-smart contracts elsewhere) with the Solana tools.
+Developers can deploy on-chain
+[programs](https://solana.com/docs/terminology#program) (often called smart
+contracts elsewhere) with the Solana tools.
 
 To learn about developing and executing programs on Solana, start with the
 [intro to Solana programs](developing/intro/programs.md) and then dig into the
@@ -100,10 +101,10 @@ solana program deploy <PROGRAM_FILEPATH>
 
 By default, programs are deployed to accounts that are twice the size of the
 original deployment. Doing so leaves room for program growth in future
-redeployments. But, if the initially deployed program is very small  and then
-later grows substantially, the redeployment may fail. To avoid this, specify
-a `max_len` that is at least the size (in bytes) that the program is expected
-to become (plus some wiggle room).
+redeployments. But, if the initially deployed program is very small and then
+later grows substantially, the redeployment may fail. To avoid this, specify a
+`max_len` that is at least the size (in bytes) that the program is expected to
+become (plus some wiggle room).
 
 ```bash
 solana program deploy --max-len 200000 <PROGRAM_FILEPATH>
@@ -117,9 +118,9 @@ is locked up permanently.
 ### Resuming a failed deploy
 
 If program deployment fails, there will be a hanging intermediate buffer account
-that contains a non-zero balance. In order to recoup that balance you may
-resume a failed deployment by providing the same intermediate buffer to a new
-call to `deploy`.
+that contains a non-zero balance. In order to recoup that balance you may resume
+a failed deployment by providing the same intermediate buffer to a new call to
+`deploy`.
 
 Deployment failures will print an error message specifying the seed phrase
 needed to recover the generated intermediate buffer's keypair:
@@ -158,8 +159,8 @@ Both program and buffer accounts can be closed and their lamport balances
 transferred to a recipient's account.
 
 If deployment fails there will be a left over buffer account that holds
-lamports. The buffer account can either be used to [resume a
-deploy](#resuming-a-failed-deploy) or closed.
+lamports. The buffer account can either be used to
+[resume a deploy](#resuming-a-failed-deploy) or closed.
 
 The program or buffer account's authority must be present to close an account,
 to list all the open program or buffer accounts that match the default
@@ -273,9 +274,10 @@ $ sha256sum extended.so dump.so
 ### Using an intermediary Buffer account
 
 Instead of deploying directly to the program account, the program can be written
-to an intermediary buffer account. Intermediary accounts can be useful for things
-like multi-entity governed programs where the governing members fist verify the
-intermediary buffer contents and then vote to allow an upgrade using it.
+to an intermediary buffer account. Intermediary accounts can be useful for
+things like multi-entity governed programs where the governing members fist
+verify the intermediary buffer contents and then vote to allow an upgrade using
+it.
 
 ```bash
 solana program write-buffer <PROGRAM_FILEPATH>

docs/src/cluster/commitments.md

@@ -1,6 +1,8 @@
 ---
 title: Commitment Status
-description: "Processed, confirmed, and finalized. Learn the differences between the different commitment statuses on the Solana blockchain."
+description:
+  "Processed, confirmed, and finalized. Learn the differences between the
+  different commitment statuses on the Solana blockchain."
 keywords:
   - processed
   - confirmed
@@ -10,7 +12,9 @@ keywords:
   - blockhash
 ---
 
-The [commitment](./../terminology.md#commitment) metric gives clients a standard measure of the network confirmation for the block. Clients can then use this information to derive their own measures of commitment.
+The [commitment](https://solana.com/docs/terminology#commitment) metric gives
+clients a standard measure of the network confirmation for the block. Clients
+can then use this information to derive their own measures of commitment.
 
 There are three specific commitment statuses: