fix(docs): sentence newline

Author: nikerzetic-aflabs

docs/smart-accounts/5-custom-instruction-comparison.mdx

@@ -18,8 +18,10 @@ keywords:
 
 Flare Smart Accounts expose two custom instruction memo opcodes that ultimately execute the same `PackedUserOperation` against a personal account:
 
-- [**Custom Instruction**](/smart-accounts/custom-instruction) - opcode `0xFE`. The XRPL memo carries only `keccak256(userOp)` in fixed 42 bytes; an off-chain executor delivers the ABI-encoded custom instruction (`userOp`) via `executeDirectMintingWithData`.
-- [**Raw Custom Instruction**](/smart-accounts/raw-custom-instruction) - opcode `0xFF`. The XRPL memo contains the ABI-encoded `PackedUserOperation` in full.
+- [**Custom Instruction**](/smart-accounts/custom-instruction) - opcode `0xFE`.
+  The XRPL memo carries only `keccak256(userOp)` in fixed 42 bytes; an off-chain executor delivers the ABI-encoded custom instruction (`userOp`) via `executeDirectMintingWithData`.
+- [**Raw Custom Instruction**](/smart-accounts/raw-custom-instruction) - opcode `0xFF`.
+  The XRPL memo contains the ABI-encoded `PackedUserOperation` in full.
 
 Both flows are validated on-chain against the same `(sender, nonce)` rules and emit the same [`UserOperationExecuted`](/smart-accounts/reference/IMasterAccountController#useroperationexecuted) event.
 The difference is purely in how the user-operation bytes travel to Flare, and which actor performs which step.
@@ -46,7 +48,8 @@ The 0xFE memo is a constant 42 bytes regardless of the user operation size, whic
 
 **Use the custom instruction (`0xFE`) when**
 
-- The user operation's ABI encoding exceeds the XRPL memo cap (long `bytes` arguments, large call batches, or deeply nested structs). Without it, you would either split the logical user operation into multiple XRPL payments (paying minting and executor fees on each) or deploy a Flare-side shim contract to compress the call - the custom instruction eliminates both.
+- The user operation's ABI encoding exceeds the XRPL memo cap (long `bytes` arguments, large call batches, or deeply nested structs).
+  Without it, you would either split the logical user operation into multiple XRPL payments (paying minting and executor fees on each) or deploy a Flare-side shim contract to compress the call - the custom instruction eliminates both.
 - You want the call payload to remain off the public XRPL ledger.
 - You already operate an executor that observes XRPL payments and submits Flare transactions - the custom instruction lets that executor batch deliveries or rate-limit submissions without splitting user operations into multiple XRPL payments.
 - You need fee predictability: the XRPL memo is always 42 bytes, so the XRPL fee is constant regardless of how complex the user operation is.
@@ -81,7 +84,8 @@ The example helpers in [`flare-viem-starter`](https://github.com/flare-foundatio
 
 A practical decision rule when integrating:
 
-1. Default to the custom instruction (`0xFE`). It fits every call batch and keeps the call payload off the public XRPL ledger.
+1. Default to the custom instruction (`0xFE`).
+   It fits every call batch and keeps the call payload off the public XRPL ledger.
 2. Reach for the raw custom instruction (`0xFF`) only when you do not want to operate or coordinate with an executor service, and you can guarantee `abi.encode(userOp)` stays well under ~900 bytes (leaving room for the 10-byte header and XRPL framing).
 
 ## Reference

docs/smart-accounts/guides/typescript-viem/02-custom-instruction.mdx

@@ -148,9 +148,12 @@ The on-chain checks (XRPL signature, `proofOwner` binding, `keccak256(data)` com
 
 Each entry in the user operation is a [`Call`](/smart-accounts/reference/IPersonalAccount#call) struct with three fields:
 
-- `target` - the address of the Flare contract to invoke. The personal account dispatches the call with itself as `msg.sender`, so this is the contract that ultimately runs the call.
-- `value` - the amount of the native token (FLR on mainnet, C2FLR on Coston2) in wei to attach to the call. The sum of `value` across all calls is what the executor must attach as `msg.value` on `executeDirectMintingWithData` in Step 2; that value flows `AssetManagerFXRP -> MasterAccountController -> PersonalAccount.executeUserOp` and is split back across the inner calls.
-- `data` - the ABI-encoded calldata (4-byte function selector followed by ABI-encoded arguments) the personal account passes to `target`. Use Viem's [`encodeFunctionData`](https://viem.sh/docs/contract/encodeFunctionData) to build it from the contract ABI, function name, and arguments.
+- `target` - the address of the Flare contract to invoke.
+  The personal account dispatches the call with itself as `msg.sender`, so this is the contract that ultimately runs the call.
+- `value` - the amount of the native token (FLR on mainnet, C2FLR on Coston2) in wei to attach to the call.
+  The sum of `value` across all calls is what the executor must attach as `msg.value` on `executeDirectMintingWithData` in Step 2; that value flows `AssetManagerFXRP -> MasterAccountController -> PersonalAccount.executeUserOp` and is split back across the inner calls.
+- `data` - the ABI-encoded calldata (4-byte function selector followed by ABI-encoded arguments) the personal account passes to `target`.
+  Use Viem's [`encodeFunctionData`](https://viem.sh/docs/contract/encodeFunctionData) to build it from the contract ABI, function name, and arguments.
 
 ```typescript
 export type Call = {
@@ -411,8 +414,11 @@ export async function executeDirectMintingWithData({
 
 Two details are critical here:
 
-- **`proofOwner`**: the FDC `XRPPayment` request binds the proof to the externally owned account that will eventually submit it. `AssetManagerFXRP` enforces this through `TransactionAttestation.verifyProofOwnership`. Pass the executor's address so the proof can only be used by that executor.
-- **`value`**: `msg.value` on `executeDirectMintingWithData` is forwarded `AssetManager -> MasterAccountController.handleMintedFAssets -> PersonalAccount.executeUserOp`. It must therefore equal the sum of `call.value` across the user operation - exactly the `totalCallValue` returned by Step 1.
+- **`proofOwner`**: the FDC `XRPPayment` request binds the proof to the externally owned account that will eventually submit it.
+  `AssetManagerFXRP` enforces this through `TransactionAttestation.verifyProofOwnership`.
+  Pass the executor's address so the proof can only be used by that executor.
+- **`value`**: `msg.value` on `executeDirectMintingWithData` is forwarded `AssetManager -> MasterAccountController.handleMintedFAssets -> PersonalAccount.executeUserOp`.
+  It must therefore equal the sum of `call.value` across the user operation - exactly the `totalCallValue` returned by Step 1.
 
 ## Step 3: confirm execution from the receipt
 

docs/smart-accounts/reference/IMasterAccountController.mdx

@@ -273,7 +273,8 @@ Parameters:
 - `_underlyingTimestamp`: The XRPL transaction timestamp.
 - `_memoData`: The raw XRPL memo bytes carrying the [memo instruction](/smart-accounts/custom-instruction-comparison).
 - `_executor`: The executor address; must equal the personal account's pinned executor when one is set.
-- `_data`: Extra data not contained in the XRPL memo. For the `0xFE` custom instruction this is the ABI-encoded `PackedUserOperation`; for all other instruction IDs it is ignored.
+- `_data`: Extra data not contained in the XRPL memo.
+  For the `0xFE` custom instruction this is the ABI-encoded `PackedUserOperation`; for all other instruction IDs it is ignored.
 
 The `AssetManager` is the only address allowed to call this function — any other caller reverts with [`OnlyAssetManager`](#onlyassetmanager).