fix(docs): update to match AddressValidity

Author: nikerzetic-aflabs

docs/fdc/guides/evm-transaction.mdx

@@ -61,6 +61,8 @@ Each succeeding script will then read that file to load the data.
 The JSON request to the verifier is the same form for all attestation types, but the values of the fields differ between them.
 It contains the following fields.
 
+### Required Fields
+
 - `attestationType` is the UTF8 hex string encoding of the attestation type name, zero-padded to 32 bytes.
 - `sourceId` is the UTF8 hex string encoding of the data source identifier name, zero-padded to 32 bytes.
 - `requestBody` is different for each attestation type.
@@ -73,22 +75,29 @@ In the case of `EVMTransaction`, `requestBody` is a JSON containing the fields:
 - `listEvents`: a `bool` determining whether the `events` field is included in the response
 - `logIndices`: an `uint32` array of indices of the events to be included in the response; if `listEvents` is set to false `false` and this field is not `[]`, the attestation request will fail
 
+### Reference Documentation
+
 We can find the required fields in the [specification](https://gitlab.com/flarenetwork/docs-team/flare-specs/-/blob/main/src/FDC/AttestationTypes/EVMTransaction.md?ref_type=heads) for the `EVMTransaction` attestation type.
 Alternatively, we can check the verifier's [interactive docs](https://fdc-verifiers-testnet.flare.network/verifier/api-doc#/ETH/ETHEVMTransactionVerifierController_prepareRequest).
 Here we can also check the verifier's response by providing the necessary data.
 Though the URLs are slightly different, the verifier has the same API for both [FLR](https://fdc-verifiers-testnet.flare.network/verifier/flr/api-doc#/AddressValidity/BTCAddressValidityVerifierController_prepareRequest) and [SGB](https://fdc-verifiers-testnet.flare.network/verifier/sgb/api-doc#/AddressValidity/BTCAddressValidityVerifierController_prepareRequest).
 
-In our example, the values we will be using are:
+### Example Values
 
 - `transactionHash`: `0x4e636c6590b22d8dcdade7ee3b5ae5572f42edb1878f09b3034b2f7c3362ef3c`
 - `requiredConfirmations`: `1`
 - `provideInput`: `true`
 - `listEvents`: `true`
 - `logIndices`: `[]`
 
-To produce the UTF8 hex string encoding of a given value, we define the `toUtf8HexString` and `toHexString` helper functions.
-In the [example repository](https://github.com/flare-foundation/flare-foundry-starter), these are shipped within an [Base](https://github.com/flare-foundation/flare-foundry-starter/blob/master/script/fdcExample/Base.s.sol) library, since all attestation type examples make use of them.
-But you may as well define them within the same contract or within the same file.
+### Encoding Functions
+
+To encode values into UTF8 hex:
+
+- `toUtf8HexString`: Converts a string to UTF8 hex.
+- `toHexString`: Zero-right-pads the string to 32 bytes.
+
+These functions are included in the [Base library](https://github.com/flare-foundation/flare-foundry-starter/blob/master/script/fdcExample/Base.s.sol) within the [example repository](https://github.com/flare-foundation/flare-foundry-starter), but they can also be defined locally in your contract or script.
 
 The first function translates a string to a UTF8 encoded hex string.
 The other then zero-right-pads such a string, so that it is 32 bytes long.
@@ -382,11 +391,11 @@ Base.writeToFile(
 
 ## 2. Submitting the request to the FDC.
 
-In contrast to the previous steps, which took many lines of code that required little explanation, we really need only five to submit the request to the `FdcHub` protocol, but all of them require a closer look.
+This step transitions from off-chain request preparation to on-chain interaction with the FDC protocol. Now, we submit the validated request to the blockchain using deployed smart contracts.
+
+### Submitting the Request
 
-:::note
-So far, everything has been happening off-chain; in this step, we will start interacting with deployed contracts.
-:::
+The entire submission process requires only five key steps:
 
 ```solidity title="scrip/fdcExample/Base.s.sol"
 function submitAttestationRequest(bytes memory abiEncodedRequest) internal {
@@ -413,51 +422,60 @@ function submitAttestationRequest(bytes memory abiEncodedRequest) internal {
 }
 ```
 
-First of all, we read the private key of our account from a `.env` file using a Foundry shortcode:
+### Step-by-Step Breakdown
+
+1.  Load Private Key
+    The private key is read from the `.env` file using Foundry's `envUint` function:
 
 ```solidity
-uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
+       uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
 ```
 
-We then broadcast all the code enveloped between `vm.startBroadcast` and `vm.stopBroadcast` shortcodes, to the chain (the console command parameter `--rpc-url` determines which one).
+2.  Obtain Request Fee
+    We retrieve the required requestFee from the `FdcRequestFeeConfigurations` contract:
 
-To acquire access to the `FcdHub` contract, we first import the `ContractRegistry` library from the `flare-periphery` package.
-The purpose of this library is to provide getter functions for the most commonly used Flare contracts.
-It calls the `getContractAddressByName("FdcHub")` function of the `ContractRegistry` contract, deployed on the correct address.
+```solidity
+        IFdcRequestFeeConfigurations fdcRequestFeeConfigurations = ContractRegistry
+            .getFdcRequestFeeConfigurations();
+        uint256 requestFee = fdcRequestFeeConfigurations.getRequestFee(
+            response.abiEncodedRequest
+        );
 
-We assign the `FcdHub` to a variable, and declare its type as `IFcdHub` (we must import this interface separately).
+```
 
-Finally, we can call the `requestAttestation` method of this contract.
-But, to execute the transaction, we must pay a certain amount of ether to the contract.
-To obtain the exact amount, we call on another contract from the `ContractRegistry` library.
+    This is done in a separate broadcast to ensure `requestFee` is available before submitting the request.
 
-```solidity title="scrip/fdcExample/Base.s.sol"
-IFdcRequestFeeConfigurations fdcRequestFeeConfigurations = ContractRegistry
- .getFdcRequestFeeConfigurations();
- uint256 requestFee = fdcRequestFeeConfigurations.getRequestFee(
- abiEncodedRequest
- )
+3. Access `FdcHub` Contract
+   Using the `ContractRegistry` library (from `flare-periphery`), we fetch the `FdcHub` contract:
+
+```solidity
+   IFdcHub fdcHub = ContractRegistry.getFdcHub();
+   console.log("fcdHub address:");
+   console.log(address(fdcHub));
+   console.log("\n");
 ```
 
-We do so within a separate broadcast so that the value `requestFee` is available to us when we post the request.
+4. Submit the Attestation Request
+   We send the attestation request with the required fee:
 
-```solidity title="scrip/fdcExample/Base.s.sol"
-fdcHub.requestAttestation{requestFee}(abiEncodedRequest);
+```solidity
+ fdcHub.requestAttestation{value: requestFee}(response.abiEncodedRequest);
 ```
 
-Next, we calculate the voting round number in which the above attestation request takes place.
-We do so through the `FlareSystemsManager` contract, which we acquire the same way as we did `FdcHub`.
+5.  Calculate Voting Round Number
+    To determine the voting round in which the attestation request is processed, we query the `FlareSystemsManager` contract:
 
-```solidity title="scrip/fdcExample/Base.s.sol"
-// Calculating roundId
-IFlareSystemsManager flareSystemsManager = ContractRegistry
- .getFlareSystemsManager();
+```solidity
+       // Calculating roundId
+       IFlareSystemsManager flareSystemsManager = ContractRegistry
+           .getFlareSystemsManager();
+
+       uint32 roundId = flareSystemsManager.getCurrentVotingEpochId();
+       console.log("roundId: %s\n", Strings.toString(roundId));
 
-uint32 roundId = flareSystemsManager.getCurrentVotingEpochId();
-console.log("roundId: %s\n", Strings.toString(roundId));
 ```
 
-We can either do that within the previous broadcast or start a new one (in the demo repository, we chose the second option, because it allowed us to organize the code better).
+This can be done within the existing broadcast or in a new one (as done in the demo repository for better code organization).
 
 Again, we write the `roundId` to a file (`data/EVMTransaction_roundId.txt`).
 
@@ -627,7 +645,7 @@ We then access the `FdcVerification` contract through the `ContractRegistry`, an
 If we proof is valid, the function `verifyEVMTransaction` will return `true`, otherwise `false`.
 As before, we wrap the whole thing into a broadcast environment, using the `PRIVATE_KEY` variable from our `.env` file.
 
-```solidity title="scrip/fdcExample/EVMTransaction.s.sol"
+```solidity
 uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
 vm.startBroadcast(deployerPrivateKey);
 
@@ -764,8 +782,6 @@ contract TransferEventListener is ITransferEventListener {
 }
 ```
 
-{/* <!-- TODO --> */}
-
 We deploy the contract through a simple script. The script creates a new `TransferEventListener` contract, and writes its address to a file (`data/EVMTransaction_listenerAddress.txt`).
 
 ```solidity title="scrip/fdcExample/EVMTransaction.s.sol"