Add Keyword Tags to all content under build

docs/build/advanced-concepts/account-abstraction.md

@@ -1,4 +1,13 @@
 ---
+title: Account Abstraction
+description: Learn how Flow provides native support for key use cases enabled by Account Abstraction, including multi-sig transactions, sponsored transactions, and more.
+keywords:
+  - account abstraction
+  - multi-sig
+  - sponsored transactions
+  - bundled transactions
+  - account recovery
+  - multi-factor authentication
 sidebar_position: 2
 ---
 
@@ -54,4 +63,4 @@ These improvements are especially notable on mobile, where users are typically m
 
 | Account Abstraction                                                                                                                                                                                                           | Flow                                                                                                                                                                       |
 | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Developers can build new features that streamline the user experience of Web3 apps, such as ‘session keys’ that pre-approve transactions for a period of time or setting custom limits on transaction volume or network fees. | Since all accounts are smart contracts, Flow has support for these new controls that enable apps to sign pre-approved transactions based on user controls and preferences. |
+| Developers can build new features that streamline the user experience of Web3 apps, such as 'session keys' that pre-approve transactions for a period of time or setting custom limits on transaction volume or network fees. | Since all accounts are smart contracts, Flow has support for these new controls that enable apps to sign pre-approved transactions based on user controls and preferences. |

docs/build/advanced-concepts/flix.md

@@ -1,4 +1,16 @@
 ---
+title: FLIX (Flow Interaction Templates)
+description: Learn about Flow Interaction Templates (FLIX), a standard for creating, auditing, and verifying Flow scripts and transactions with improved security and metadata.
+keywords:
+  - FLIX
+  - Flow Interaction Templates
+  - templates
+  - transactions
+  - scripts
+  - smart contracts
+  - FCL
+  - interaction templates
+  - template service
 sidebar_position: 3
 ---
 
@@ -8,7 +20,7 @@ Flow Interaction Templates is a standard for how contract developers, wallets, u
 
 Interaction Templates provide a way to use and reuse existing scripts and transactions, as well as to provide more metadata such as a human-readable title and description of what the transaction or script will do, which can be used by the developer as well as the user of the application. 
 
-By using FLIX transactions and scripts, developers don’t have to write their own for common operations!
+By using FLIX transactions and scripts, developers don't have to write their own for common operations!
 
 Read more about the design and purpose of FLIX in the [FLIP](https://github.com/onflow/flips/blob/main/application/20220503-interaction-templates.md)
 

docs/build/advanced-concepts/metadata-views.md

@@ -1,5 +1,19 @@
 ---
 title: NFT Metadata Views
+description: Learn about Flow's standardized way to represent and manage NFT metadata through MetadataViews, enabling consistent metadata interpretation across different platforms and marketplaces.
+keywords:
+  - NFT metadata
+  - MetadataViews
+  - NFT standards
+  - metadata views
+  - Flow NFT
+  - ViewResolver
+  - NFT traits
+  - NFT royalties
+  - NFT editions
+  - contract metadata
+  - NFT display
+  - metadata implementation
 sidebar_label: NFT Metadata Views
 ---
 

docs/build/advanced-concepts/randomness.md

@@ -1,13 +1,27 @@
 ---
 title: Flow On-chain Randomness in Cadence
+description: Learn how Flow provides native, secure on-chain randomness at the protocol level, enabling developers to build applications with verifiable, unpredictable outcomes without external oracles.
+keywords:
+  - randomness
+  - VRF
+  - on-chain randomness
+  - revertibleRandom
+  - random beacon
+  - commit-reveal
+  - random number generation
+  - blockchain randomness
+  - secure randomness
+  - Flow protocol
+  - randomness beacon
+  - PRNG
 sidebar_label: VRF (Randomness) in Cadence
 ---
 
 # Randomness on FLOW
 
 Flow enhances blockchain functionality and eliminates reliance on external oracles by providing native onchain randomness at the protocol level. This secure, decentralized feature empowers developers to build a variety of applications with truly unpredictable, transparent, and fair outcomes, achieved with greater efficiency.
 
-Flow’s onchain randomness delivers immediate random values within smart contracts, bypassing the latency and complexity of oracle integration. Developers can obtain verifiably random results with a single line of Cadence code, streamlining the development process and enhancing the performance of decentralized applications.
+Flow's onchain randomness delivers immediate random values within smart contracts, bypassing the latency and complexity of oracle integration. Developers can obtain verifiably random results with a single line of Cadence code, streamlining the development process and enhancing the performance of decentralized applications.
 
 ## Use Cases of Onchain Randomness
 
@@ -31,7 +45,7 @@ For over three years, the beacon has ensured protocol security by selecting whic
 Cadence has historically provided the `unsafeRandom` function to return a pseudo-random number. The stream of random numbers produced was potentially unsafe in the following two regards:
 
 1. The sequence of random numbers is potentially predictable by transactions within the same block and by other smart contracts calling into your smart contract.
-2. A transaction calling into your smart contract can potentially bias the sequence of random numbers which your smart contract internally generates. Currently, the block hash seeds `unsafeRandom`. Consensus nodes can *easily* bias the block hash and **influence the seed for `unsafeRandom`**.
+2. A transaction calling into your smart contract can potentially bias the sequence of random numbers which your smart contract internally generates. Currently, the block hash seeds `unsafeRandom`. Consensus nodes can *easily* bias the block hash and **influence the seed for `unsafeRandom`**.
 
 <Callout type="warning">
 ⚠️ Note `unsafeRandom` is deprecated since the Cadence 1.0 release.
@@ -93,10 +107,10 @@ There are ideas how to further optimize the developer experience in the future.
 On Flow, we have absorbed all security complexity into the platform.
 
 [FLIP 123: On-chain Random beacon history for commit-reveal schemes](https://github.com/onflow/flips/blob/main/protocol/20230728-commit-reveal.md#flip-123-on-chain-random-beacon-history-for-commit-reveal-schemes) was introduced to provide a safe pattern to use randomness in transactions so that it's not possible to revert unfavorable randomized transaction results.
-We recommend this approach as a best-practice example for implementing a commit-reveal scheme in Cadence. The `RandomBeaconHistory` contract provides a convenient archive, where for each past block height (starting Nov 2023) the respective “source of randomness” can be retrieved. The `RandomBeaconHistory` contract is automatically executed by the system at each block to store the next source of randomness value.
+We recommend this approach as a best-practice example for implementing a commit-reveal scheme in Cadence. The `RandomBeaconHistory` contract provides a convenient archive, where for each past block height (starting Nov 2023) the respective "source of randomness" can be retrieved. The `RandomBeaconHistory` contract is automatically executed by the system at each block to store the next source of randomness value.
 
 <Callout type="info">
-💡 While the commit-and-reveal scheme mitigates post-selection of results by adversarial clients, Flow’s secure randomness additionally protects against any pre-selection vulnerabilities (like biasing attacks by byzantine miners).
+💡 While the commit-and-reveal scheme mitigates post-selection of results by adversarial clients, Flow's secure randomness additionally protects against any pre-selection vulnerabilities (like biasing attacks by byzantine miners).
 </Callout>
 
 A commit-reveal scheme can be implemented as follows. The coin toss example described earlier will be used for illustration:
@@ -193,7 +207,7 @@ This is an invitation for builders and creators: leverage Flow's onchain randomn
 
 ## Learn More
 
-If you’d like to dive deeper into Flow’s onchain randomness, here’s a list of resources:
+If you'd like to dive deeper into Flow's onchain randomness, here's a list of resources:
 
 - To learn more about how randomness works under the hood, see [the forum post](https://forum.flow.com/t/secure-random-number-generator-for-flow-s-smart-contracts/5110).
 - These documents provide a more in-depth technical understanding of the updates and enhancements to the Flow blockchain.

docs/build/advanced-concepts/scaling.md

@@ -1,5 +1,18 @@
 ---
 title: Scaling Transactions from a Single Account
+description: Learn how to scale transactions from a single account on Flow using multiple proposer keys, enabling concurrent transaction processing for system-level operations.
+keywords:
+  - scaling
+  - transactions
+  - proposer keys
+  - sequence numbers
+  - concurrent transactions
+  - system transactions
+  - transaction scaling
+  - Flow blockchain
+  - account scaling
+  - transaction workers
+  - batch operations
 sidebar_label: Scaling Transactions from a Single Account
 ---
 
@@ -16,19 +29,19 @@ Flow is designed for consumer-scale internet applications and is one of the fast
     * Swapping tokens on decentralized exchanges (DEXs)
     * Staking or unstaking tokens
 
-    In this category, each transaction originates from a unique account and is sent to the Flow network from a different machine. Developers don’t need to take special measures to scale for this category, beyond ensuring their logic is primarily on-chain and their supporting systems (e.g., frontend, backend) can handle scaling if they become bottlenecks. Flow’s protocol inherently manages scaling for user transactions.
+    In this category, each transaction originates from a unique account and is sent to the Flow network from a different machine. Developers don't need to take special measures to scale for this category, beyond ensuring their logic is primarily on-chain and their supporting systems (e.g., frontend, backend) can handle scaling if they become bottlenecks. Flow's protocol inherently manages scaling for user transactions.
 
 2. **System Transactions**
 
-    These are transactions initiated by an app’s backend or various tools, such as:
+    These are transactions initiated by an app's backend or various tools, such as:
 
     * Minting thousands of tokens from a single minter account
     * Creating transaction workers for custodians
     * Running maintenance jobs and batch operations
 
     In this category, many transactions originate from the same account and are sent to the Flow network from the same machine, which can make scaling tricky. This guide focuses on strategies for scaling transactions from a single account.
 
-In the following sections, we’ll explore how to execute concurrent transactions from a single account on Flow using multiple proposer keys.
+In the following sections, we'll explore how to execute concurrent transactions from a single account on Flow using multiple proposer keys.
 
 :::info
 
@@ -40,7 +53,7 @@ This guide is specific to non-EVM transactions. For EVM-compatible transactions,
 
 Blockchains use sequence numbers, also known as nonces, for each transaction to prevent [replay attacks](https://en.wikipedia.org/wiki/Replay_attack) and allow users to specify the order of their transactions. The Flow network requires a specific sequence number for each incoming transaction and will reject any transaction where the sequence number does not exactly match the expected next value.
 
-This behavior presents a challenge for scaling, as sending multiple transactions does not guarantee that they will be executed in the order they were sent. This is a fundamental aspect of Flow’s resistance to MEV (Maximal Extractable Value), as transaction ordering is randomized within each block.
+This behavior presents a challenge for scaling, as sending multiple transactions does not guarantee that they will be executed in the order they were sent. This is a fundamental aspect of Flow's resistance to MEV (Maximal Extractable Value), as transaction ordering is randomized within each block.
 
 If a transaction arrives out of order, the network will reject it and return an error message similar to the following:
 ```
@@ -86,13 +99,13 @@ We can leverage this model to design an ideal system transaction architecture as
 
     To simplify the system further, we can reuse the same cryptographic key multiple times within the same account by adding it as a new key. These additional keys can have a weight of 0 since they do not need to authorize transactions.
 
-Here’s a visual example of how such an [account configuration](https://www.flowscan.io/account/18eb4ee6b3c026d2?tab=keys) might look:
+Here's a visual example of how such an [account configuration](https://www.flowscan.io/account/18eb4ee6b3c026d2?tab=keys) might look:
 
 ![Example.Account](scaling-example-account.png "Example Account")
 
 As shown, the account includes additional weightless keys designated for proposals, each with its own independent sequence number. This setup ensures that multiple workers can operate concurrently without conflicts or synchronization issues.
 
-In the next section, we’ll demonstrate how to implement this architecture using the [Go SDK](https://github.com/onflow/flow-go-sdk).
+In the next section, we'll demonstrate how to implement this architecture using the [Go SDK](https://github.com/onflow/flow-go-sdk).
 
 ## Example Implementation
 
@@ -163,7 +176,7 @@ transaction(code: String, numKeys: Int) {
 }
 ```
 
-Next, the main loop starts. Each worker will process a transaction request from the queue and execute it. Here’s the code for the main loop:
+Next, the main loop starts. Each worker will process a transaction request from the queue and execute it. Here's the code for the main loop:
 
 ```go
 // populate the job channel with the number of transactions to execute

docs/build/app-architecture/index.md

@@ -1,7 +1,19 @@
 ---
 sidebar_position: 5
 title: App Architecture
-description: Describes building self-custody and app custody applications on Flow Blockchain.
+description: Learn about self-custody and app custody architectural patterns for building applications on Flow blockchain, including their benefits, considerations, and ideal use cases.
+keywords:
+  - app architecture
+  - self custody
+  - app custody
+  - Flow blockchain
+  - walletless onboarding
+  - account linking
+  - dApp architecture
+  - blockchain architecture
+  - key management
+  - user experience
+  - web3 development
 sidebar_custom_props:
   icon: 🏗️
 ---