feat: frontmatter description (#138)

Author: yash-atreya

vocs/docs/pages/contract-interactions/queries.md

@@ -1,3 +1,7 @@
+---
+description: Query contract storage, deployed bytecode, and event logs from the blockchain
+---
+
 ## Querying Contracts
 
 ### Query Contract Storage

vocs/docs/pages/contract-interactions/read-contract.mdx

@@ -1,3 +1,7 @@
+---
+description: Call view functions on smart contracts using the sol! macro's CallBuilder for read operations
+---
+
 ## Reading a contract
 
 We shall leverage the `sol!` macro and its `rpc` attribute to get the [WETH](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) balance of an address.

vocs/docs/pages/contract-interactions/using-sol!.mdx

@@ -1,3 +1,7 @@
+---
+description: Generate type-safe Rust bindings from Solidity code using the powerful sol! procedural macro
+---
+
 ## Using the sol! macro
 
 Alloy provides a powerful and intuitive way to read and write to contracts using the `sol!` procedural macro.

vocs/docs/pages/contract-interactions/write-contract.mdx

@@ -1,3 +1,7 @@
+---
+description: Send transactions to smart contracts using the sol! macro's CallBuilder for seamless write operations
+---
+
 ## Writing to a contract
 
 The `sol!` macro also helps up building transactions and submit them to the chain seamless.

vocs/docs/pages/guides/fillers.mdx

@@ -1,3 +1,7 @@
+---
+description: Build transaction preprocessing pipelines using fillers to automatically fill missing transaction properties
+---
+
 # Building a High-Priority Transaction Queue with Alloy Fillers
 
 In this guide, we will explore more advanced use cases of Alloy Providers APIs. We will cover non-standard ways to instantiate and customize providers and deep dive into custom layers and fillers implementations. We have a lot to cover, so let's get started!

vocs/docs/pages/guides/interacting-with-multiple-networks.md

@@ -1,3 +1,7 @@
+---
+description: Use the Network trait to seamlessly interact with different blockchain networks and handle varying RPC types
+---
+
 # Interacting with multiple networks
 
 The provider trait is generic over the network type, `Provider<N: Network = Ethereum>`, with the default network set to `Ethereum`.

vocs/docs/pages/guides/layers.mdx

@@ -1,3 +1,7 @@
+---
+description: Customize HTTP-related aspects of RPC communication using Tower-based layers and services
+---
+
 # Customizing RPC Communication with Alloy's Layers
 
 In the [previous guide](/guides/fillers), we covered [Alloy fillers](/rpc-providers/understanding-fillers). This time we'll discuss how to use [Alloy layers](https://alloy.rs/examples/layers/README) to customize HTTP-related aspects of RPC client communication.

vocs/docs/pages/guides/multicall.md

@@ -1,10 +1,15 @@
+---
+description: Optimize RPC usage by batching multiple smart contract calls using Multicall Builder and Layer
+---
+
 # Multicall and Multicall Batching layer
 
-## What is Multicall? 
+## What is Multicall?
+
+Multicall is a smart contract and pattern that allows you to batch multiple read-only calls to the Ethereum blockchain into a single request. Instead of sending separate RPC requests, Multicall combines them into one transaction, significantly reducing network overhead and latency. This solves various problems such as reduced latency and rate-limiting, network overhead, atomic state reading & offers better UX.
 
-Multicall is a smart contract and pattern that allows you to batch multiple read-only calls to the Ethereum blockchain into a single request. Instead of sending separate RPC requests, Multicall combines them into one transaction, significantly reducing network overhead and latency. This solves various problems such as reduced latency and rate-limiting, network overhead, atomic state reading & offers better UX. 
+## When should I use Multicall ?
 
-## When should I use Multicall ? 
 - To read multiple contract states e.g. fetching balances, allowances, or prices across multiple contracts
 - To reduce request count e.g. working with public RPC endpoints that have rate limits
 - To ensure data consistency e.g. when you need multiple values from the same blockchain state
@@ -13,7 +18,8 @@ Note that Multicall is not suitable for write operations (transactions that chan
 
 ## Multicall with Alloy
 
-Alloy provides two ways in which a user can make multicalls to the [Multicall3 contract](https://www.multicall3.com/), both of which tightly integrated with the `Provider` to make usage as easy as possible: 
+Alloy provides two ways in which a user can make multicalls to the [Multicall3 contract](https://www.multicall3.com/), both of which tightly integrated with the `Provider` to make usage as easy as possible:
+
 1. Multicall Builder: The `multicall()` method gives you explicit control over which calls to batch
 2. Multi-batching Layer: The batching layer automatically batches requests that are made in parallel
 
@@ -36,15 +42,16 @@ let multicall = provider
 
 You can find the complete example [here](/examples/providers/multicall)
 
-This approach is suitable when: 
+This approach is suitable when:
+
 - You know exactly which calls you want to batch together
 - You need to explicitly collect related data in a single request
 - You need fine-grained control over the order of results
 - You are working with varied contract types in a single batch
 
 ### 2. Multicall Batching Layer
 
-The batching layer is especially powerful because it requires no changes to your existing code and reduces the number of network requests. 
+The batching layer is especially powerful because it requires no changes to your existing code and reduces the number of network requests.
 
 However, this only works when requests are made in parallel, for example when using the
 [`tokio::join!`] macro or in multiple threads/tasks, as otherwise the requests will be sent one
@@ -75,5 +82,6 @@ async fn f(url: &str) -> Result<(), Box<dyn std::error::Error>> {
 ```
 
 Find the complete example [here](/examples/providers/multicall_batching). This approach is suitable when:
+
 - You want to optimize existing code without restructuring it
-- You need to batch calls that are made from different parts of your codebase
+- You need to batch calls that are made from different parts of your codebase

vocs/docs/pages/guides/rpc-provider-abstraction.md

@@ -1,27 +1,31 @@
+---
+description: Abstract provider implementations to work seamlessly across different transport layers and connection types
+---
+
 # RPC Provider Abstractions
 
-Alloy offers *Provider Wrapping* as a design pattern that lets you extend or customize the behavior of a Provider by encapsulating it inside another object. 
+Alloy offers _Provider Wrapping_ as a design pattern that lets you extend or customize the behavior of a Provider by encapsulating it inside another object.
 
 There are several reasons why you would want create your own RPC provider abstractions, for example to simplify complex workflows, or build more intuitive interfaces for particular use cases (like deployment, data indexing, or trading).
 
 Let's dive into an example: Imagine you have multiple contracts that need to be deployed and monitored. Rather than repeating the same boilerplate code throughout your application, you can create specialized abstractions that wrap the Provider. Your `Deployer` struct ingests the `Provider` and the bytecode to deploy contracts and interact with them. More on this in the example snippets below.
 
-There are two ways to ways to implement provider wrapping, both offer different trade-offs depending on your use case: 
+There are two ways to ways to implement provider wrapping, both offer different trade-offs depending on your use case:
 
 1. Using Generics (`P: Provider`): Preserves type information and enables static dispatch
 2. Using Type Erasure (`DynProvider`): Simplifies types at the cost of some runtime overhead
 
 ## 1. Using generics `P: Provider`
 
-The ideal way is by using the `P: Provider` generic on the encapsulating type. This approach Preserves full type information and static dispatch, though can lead to complex type signatures and handling generics. 
+The ideal way is by using the `P: Provider` generic on the encapsulating type. This approach Preserves full type information and static dispatch, though can lead to complex type signatures and handling generics.
 
 This is depicted by the following [example](/examples/providers/wrapped_provider). Use generics when you need maximum performance and type safety, especially in library code.
 
 ```rust [wrapped_provider.rs]
 // [!include ~/snippets/providers/examples/wrapped_provider.rs]
 ```
 
-During this approach the compiler creates a unique `Deployer` struct for each Provider type you use static dispatch with slightly better runtime overhead. 
+During this approach the compiler creates a unique `Deployer` struct for each Provider type you use static dispatch with slightly better runtime overhead.
 Use this approach when performance is critical, type information is valuable e.g. when creating library code or working with embedded systems.
 Type information is valuable: You need to know the exact Provider type for specialized behavior
 
@@ -35,10 +39,10 @@ Use DynProvider when you prioritize simplicity and flexibility, such as in appli
 // [!include ~/snippets/providers/examples/dyn_provider.rs]
 ```
 
-With `DynProvider` we use dynamic dispatch, accept a slightly slower runtime overhead but can avoid dealing with generics. 
-Use this approach when you prefer simplicity over speed speed, minimise compile and binary size or want to create heterogeneous collections. 
+With `DynProvider` we use dynamic dispatch, accept a slightly slower runtime overhead but can avoid dealing with generics.
+Use this approach when you prefer simplicity over speed speed, minimise compile and binary size or want to create heterogeneous collections.
 
-## `Provider` does not require `Arc` 
+## `Provider` does not require `Arc`
 
 You might be tempted to wrap a `Provider` in `Arc` to enable sharing and cloning:
 
@@ -57,4 +61,4 @@ struct MyProvider<P: Provider + Clone> {
 }
 ```
 
-This eliminates common boilerplate and prevents potential performance issues from double Arc-ing.
+This eliminates common boilerplate and prevents potential performance issues from double Arc-ing.

vocs/docs/pages/guides/signers-vs-ethereum-wallet.md

@@ -1,3 +1,7 @@
+---
+description: Manage different signer types within a single EthereumWallet for flexible transaction signing strategies
+---
+
 # Signers vs Ethereum Wallet
 
 ## Signer