final page cleanup

Author: Cordtus

docs/documentation/concepts/accounts.mdx

@@ -232,6 +232,6 @@ You can query an account address using CLI, gRPC, REST, or JSON-RPC:
 </Tabs>
 
 <Note>
-For JSON-RPC methods, see [`eth_accounts`](/api-reference/ethereum-json-rpc/methods#eth-accounts) and [`personal_listAccounts`](/api-reference/ethereum-json-rpc/methods#personal-listAccounts) documentation.
+For JSON-RPC methods, see [`eth_accounts`](/docs/api-reference/ethereum-json-rpc/methods#eth-accounts) and [`personal_listAccounts`](/docs/api-reference/ethereum-json-rpc/methods#personal-listAccounts) documentation.
 </Note>
 

docs/documentation/concepts/encoding.mdx

@@ -9,28 +9,102 @@ In Ethereum, integers must be represented in big-endian binary form with no lead
 
 The Cosmos Stargate release introduces protobuf as the main encoding format for both client and state serialization. All the EVM module types that are used for state and clients, such as transaction messages, genesis, query services, etc., will be implemented as protocol buffer messages. The Cosmos SDK also supports the legacy Amino encoding. Protocol Buffers (protobuf) is a language-agnostic binary serialization format that is smaller and faster than JSON. It is used to serialize structured data, such as messages, and is designed to be highly efficient and extensible. The encoding format is defined in a language-agnostic language called Protocol Buffers Language (proto3), and the encoded messages can be used to generate code for a variety of programming languages. The main advantage of protobuf is its efficiency, which results in smaller message sizes and faster serialization and deserialization times. The RLP decoding process is as follows: according to the first byte (i.e., prefix) of input data and decoding the data type, the length of the actual data and offset; according to the type and offset of data, decode the data correspondingly.
 
-## Prerequisite Readings[​](#prerequisite-readings "Direct link to Prerequisite Readings")
+## Prerequisite Readings
 
-* [Cosmos SDK Encoding](https://docs.cosmos.network/main/learn/advanced/encoding)
-* [Ethereum RLP](https://eth.wiki/en/fundamentals/rlp)
+<CardGroup cols={2}>
+  <Card title="Cosmos SDK Encoding" icon="code" href="https://docs.cosmos.network/main/learn/advanced/encoding">
+    Learn about protobuf and Amino encoding in Cosmos SDK
+  </Card>
+  <Card title="Ethereum RLP" icon="ethereum" href="https://eth.wiki/en/fundamentals/rlp">
+    Understand Recursive Length Prefix encoding
+  </Card>
+</CardGroup>
 
-## Encoding Formats[​](#encoding-formats "Direct link to Encoding Formats")
+## Encoding Formats
 
-### Protocol Buffers[​](#protocol-buffers "Direct link to Protocol Buffers")
+<Tabs>
+  <Tab title="Protocol Buffers">
+    **Primary encoding for Cosmos EVM**
+    
+    The Cosmos [Stargate](https://stargate.cosmos.network/) release introduces [protobuf](https://developers.google.com/protocol-buffers) as the main encoding format for both client and state serialization.
+    
+    <Info>
+    All EVM module types (transaction messages, genesis, query services) are implemented as protocol buffer messages.
+    </Info>
+    
+    **Advantages:**
+    - Language-agnostic binary serialization
+    - Smaller message sizes than JSON
+    - Faster serialization/deserialization
+    - Strongly typed with schema validation
+  </Tab>
+  
+  <Tab title="RLP">
+    **Ethereum compatibility encoding**
+    
+    Recursive Length Prefix ([RLP](https://eth.wiki/en/fundamentals/rlp)) is an encoding/decoding algorithm that serializes messages for Ethereum compatibility.
+    
+    <Note>
+    Cosmos EVM uses RLP specifically for Ethereum transaction encoding to ensure JSON-RPC compatibility.
+    </Note>
+    
+    **Usage in Cosmos EVM:**
+    - Encoding `MsgEthereumTx` for JSON-RPC
+    - Transaction signing and verification
+    - Block hash computation
+    - Merkle tree data structures
+  </Tab>
+  
+  <Tab title="Amino (Legacy)">
+    **Backwards compatibility only**
+    
+    The Cosmos SDK supports legacy Amino encoding for backwards compatibility with older versions.
+    
+    <Warning>
+    Cosmos EVM does not support Amino in the EVM module. It's only available for other Cosmos SDK modules that enable it.
+    </Warning>
+    
+    **Limited use cases:**
+    - Client encoding for legacy wallets
+    - Signing with Ledger devices
+    - Not used for EVM transactions
+  </Tab>
+</Tabs>
 
-The Cosmos [Stargate](https://stargate.cosmos.network/) release introduces [protobuf](https://developers.google.com/protocol-buffers) as the main encoding format for both client and state serialization. All the EVM module types that are used for state and clients (transaction messages, genesis, query services, etc) will be implemented as protocol buffer messages.
+### Transaction Encoding Implementation
 
-### Amino[​](#amino "Direct link to Amino")
+The `x/vm` module handles `MsgEthereumTx` encoding by converting to go-ethereum's `Transaction` format and using RLP:
 
-The Cosmos SDK also supports the legacy Amino encoding format for backwards compatibility with previous versions, specially for client encoding and signing with Ledger devices. Cosmos EVM does not support Amino in the EVM module, but it is supported for all other Cosmos SDK modules that enable it.
-
-### RLP[​](#rlp "Direct link to RLP")
-
-Recursive Length Prefix ([RLP](https://eth.wiki/en/fundamentals/rlp)), is an encoding/decoding algorithm that serializes a message and allows for quick reconstruction of encoded data. Cosmos EVM uses RLP to encode/decode Ethereum messages for JSON-RPC handling to conform messages to the proper Ethereum format. This allows messages to be encoded and decoded in the exact format as Ethereum's.
-
-The `x/vm` transactions (`MsgEthereumTx`) encoding is performed by casting the message to a go-ethereum's `Transaction` and then marshaling the transaction data using RLP:
+<CodeGroup>
 
+```go TxEncoder
+// TxEncoder overwrites sdk.TxEncoder to support MsgEthereumTx
+func (g txConfig) TxEncoder() sdk.TxEncoder {
+  return func(tx sdk.Tx) ([]byte, error) {
+    msg, ok := tx.(*evmtypes.MsgEthereumTx)
+    if ok {
+      return msg.AsTransaction().MarshalBinary()
+    }
+    return g.TxConfig.TxEncoder()(tx)
+  }
+}
 ```
-// TxEncoder overwrites sdk.TxEncoder to support MsgEthereumTxfunc (g txConfig) TxEncoder() sdk.TxEncoder {return func(tx sdk.Tx) ([]byte, error) {  msg, ok := tx.(*evmtypes.MsgEthereumTx)  if ok {    return msg.AsTransaction().MarshalBinary()  }  return g.TxConfig.TxEncoder()(tx)}}// TxDecoder overwrites sdk.TxDecoder to support MsgEthereumTxfunc (g txConfig) TxDecoder() sdk.TxDecoder {return func(txBytes []byte) (sdk.Tx, error) {  tx := &ethtypes.Transaction{}  err := tx.UnmarshalBinary(txBytes)  if err == nil {    msg := &evmtypes.MsgEthereumTx{}    msg.FromEthereumTx(tx)    return msg, nil  }  return g.TxConfig.TxDecoder()(txBytes)}}
+
+```go TxDecoder
+// TxDecoder overwrites sdk.TxDecoder to support MsgEthereumTx
+func (g txConfig) TxDecoder() sdk.TxDecoder {
+  return func(txBytes []byte) (sdk.Tx, error) {
+    tx := &ethtypes.Transaction{}
+    err := tx.UnmarshalBinary(txBytes)
+    if err == nil {
+      msg := &evmtypes.MsgEthereumTx{}
+      msg.FromEthereumTx(tx)
+      return msg, nil
+    }
+    return g.TxConfig.TxDecoder()(txBytes)
+  }
+}
 ```
 
+</CodeGroup>
+

docs/documentation/concepts/mempool.mdx

@@ -204,7 +204,7 @@ You can also explore these methods interactively using the [RPC Explorer](/docs/
 ## Integration
 
 <Note>
-For chain developers looking to integrate the mempool into their Cosmos SDK chain, see the [EVM Mempool Integration Guide](/documentation/integration/mempool-integration) for complete setup instructions.
+For chain developers looking to integrate the mempool into their Cosmos SDK chain, see the [EVM Mempool Integration Guide](/docs/documentation/integration/mempool-integration) for complete setup instructions.
 </Note>
 
 ## State Management

docs/documentation/concepts/pending-state.mdx

@@ -8,7 +8,7 @@ During the pending state, the transaction initiator is allowed to change the tra
 ## Prerequisite Readings[​](#prerequisite-readings "Direct link to Prerequisite Readings")
 
 * [Cosmos SDK Mempool](https://docs.cosmos.network/main/building-apps/app-mempool)
-* [Mempool Architecture](/documentation/concepts/mempool)
+* [Mempool Architecture](/docs/documentation/concepts/mempool)
 
 ## Cosmos EVM vs Ethereum[​](#cosmos-evm-vs-ethereum "Direct link to Cosmos EVM vs Ethereum")
 
@@ -145,6 +145,6 @@ const fasterTx = await wallet.sendTransaction({
 ## Architecture Details
 
 For a detailed understanding of how the pending state is managed:
-- See [Mempool Architecture](/documentation/concepts/mempool#architecture) for the two-tier system design
-- Review [Transaction Flow](/documentation/concepts/mempool#transaction-flow) for state transitions
-- Check [Integration Guide](/documentation/integration/mempool-integration) for implementation details
+- See [Mempool Architecture](/docs/documentation/concepts/mempool#architecture) for the two-tier system design
+- Review [Transaction Flow](/docs/documentation/concepts/mempool#transaction-flow) for state transitions
+- Check [Integration Guide](/docs/documentation/integration/mempool-integration) for implementation details

docs/documentation/concepts/transactions.mdx

@@ -10,22 +10,22 @@ Additionally, a transaction needs to be signed using the sender's private key. T
 In a nutshell, the transaction lifecycle once a signed transaction is submitted to the network is the following:
 
 * A transaction hash is cryptographically generated.
-* The transaction is validated through CheckTx and added to the mempool:
-  * **For Ethereum transactions**: If the nonce is correct, it enters the public mempool immediately. If there's a nonce gap, it's queued locally until the gap is filled (see [Mempool](/docs/documentation/concepts/mempool) for details).
-  * **For Cosmos transactions**: Standard sequential nonce validation applies.
+* The transaction is validated through CheckTx and added to the mempool (see [Transaction Ordering](#transaction-ordering-and-prioritization) below).
 * The transaction is broadcasted to the network peers (only if immediately executable).
 * A validator selects your transaction for inclusion in a block based on fee prioritization.
 * The transaction is executed and the state change is committed.
 
-For a more detailed explanation of the transaction lifecycle, see [the corresponding section](https://docs.cosmos.network/main/basics/tx-lifecycle) and the [Mempool documentation](/docs/documentation/concepts/mempool#transaction-flow).
+<Note>
+For detailed transaction flow and mempool behavior, see the [Mempool documentation](/docs/documentation/concepts/mempool#transaction-flow) and [Cosmos SDK lifecycle](https://docs.cosmos.network/main/basics/tx-lifecycle).
+</Note>
 
 The transaction hash is a unique identifier and can be used to check transaction information, for example, the events emitted, if was successful or not.
 
 Transactions can fail for various reasons. For example, the provided gas or fees may be insufficient. Also, the transaction validation may fail. Each transaction has specific conditions that must fullfil to be considered valid. A widespread validation is that the sender is the transaction signer. In such a case, if you send a transaction where the sender address is different than the signer's address, the transation will fail, even if the fees are sufficient.
 
 Nowadays, transactions can not only perform state transitions on the chain in which are submitted, but also can execute transactions on another blockchains. Interchain transactions are possible through the [Inter-Blockchain Communication protocol (IBC)](https://ibcprotocol.org/). Find a more detailed explanation on the section below.
 
-## Transaction Types[​](#transaction-types "Direct link to Transaction Types")
+## Transaction Types
 
 Cosmos EVM supports two transaction types:
 
@@ -38,7 +38,7 @@ Although most of the information included on both of these transaction types is
 
 Find more information about these two types on the following sections.
 
-### Cosmos Transactions[​](#cosmos-transactions "Direct link to Cosmos Transactions")
+### Cosmos Transactions
 
 On Cosmos chains, transactions are comprised of metadata held in contexts and `sdk.Msg`s that trigger state changes within a module through the module's Protobuf [Msg service](https://docs.cosmos.network/main/building-modules/msg-services).
 
@@ -55,13 +55,12 @@ A Cosmos transaction includes the following information:
 
 To submit a Cosmos transaction, users must use one of the provided clients.
 
-### Ethereum Transactions[​](#ethereum-transactions "Direct link to Ethereum Transactions")
+### Ethereum Transactions
 
 Ethereum transactions refer to actions initiated by EOAs (externally-owned accounts, managed by humans), rather than internal smart contract calls. Ethereum transactions transform the state of the EVM and therefore must be broadcasted to the entire network.
 
 Ethereum transactions also require a fee, known as `gas`. ([EIP-1559](https://eips.ethereum.org/EIPS/eip-1559)) introduced the idea of a base fee, along with a priority fee which serves as an incentive for validators to include specific transactions in blocks.
 
-**Nonce Management**: Unlike traditional Cosmos transactions, Ethereum transactions can be submitted with nonce gaps. The EVM mempool will queue these transactions locally until the gaps are filled, enabling compatibility with Ethereum tooling that sends batch transactions. See the [Mempool documentation](/docs/documentation/concepts/mempool) for details on nonce gap handling.
 
 There are several categories of Ethereum transactions:
 
@@ -73,7 +72,7 @@ An Ethereum transaction includes the following information:
 
 * `recipient`: receiving address
 * `signature`: sender's signature
-* `nonce`: counter of tx number from account (supports out-of-order submission with queuing)
+* `nonce`: counter of tx number from account
 * `value`: amount of ETH to transfer (in wei)
 * `data`: include arbitrary data. Used when deploying a smart contract or making a smart contract method call
 * `gasLimit`: max amount of gas to be consumed
@@ -96,13 +95,8 @@ Cosmos EVM is capable of processing Ethereum transactions by wrapping them on a
 
 One remark about the `MsgEthereumTx` is that it implements both the `sdk.Msg` and `sdk.Tx` interfaces (generally SDK messages only implement the former, while the latter is a group of messages bundled together). The reason for this is that the `MsgEthereumTx` must not be included in a `auth.StdTx` (SDK's standard transaction type) as it performs gas and fee checks using the Ethereum logic from Geth instead of the Cosmos SDK checks done on the auth module `AnteHandler`.
 
-**Mempool Handling**: `MsgEthereumTx` transactions receive special treatment in the mempool:
-- Transactions with correct nonces are immediately added to the public mempool and broadcast
-- Transactions with nonce gaps are intercepted and queued locally without broadcasting
-- When gaps are filled, queued transactions are automatically promoted and broadcast
-- This enables compatibility with Ethereum tooling that sends batched transactions
 
-#### Ethereum Tx Type[​](#ethereum-tx-type "Direct link to Ethereum Tx Type")
+#### Ethereum Tx Type
 
 There are three types of transaction types used in Cosmos EVM's [Go Ethereum](https://github.com/ethereum/go-ethereum/blob/b946b7a13b749c99979e312c83dce34cac8dd7b1/core/types/transaction.go#L43-L48) implementation that came from Ethereum Improvement Proposals(EIPs):
 
@@ -114,7 +108,7 @@ There are three types of transaction types used in Cosmos EVM's [Go Ethereum](ht
 
 These transaction types represent Ethereum's continuous evolution and improvements to its network, helping address challenges related to scalability, security, and user experience.
 
-### Interchain Transactions[​](#interchain-transactions "Direct link to Interchain Transactions")
+### Interchain Transactions
 
 Interchain transactions refer to the transfer of digital assets or data between two or more different blockchain networks.
 
@@ -133,19 +127,31 @@ Interchain transactions are becoming increasingly important as the number of dif
 
 ## Transaction Ordering and Prioritization
 
-In Cosmos EVM, both Ethereum and Cosmos transactions compete fairly for block inclusion based on their effective tips:
-
-### Fee-Based Priority
-- **Ethereum transactions**: Priority determined by `gas_tip_cap` or `min(gas_tip_cap, gas_fee_cap - base_fee)`
-- **Cosmos transactions**: Priority calculated as `(fee_amount / gas_limit) - base_fee`
-- Transactions with higher effective tips are selected first, regardless of type
-
-### Nonce Sequencing
-- Within each account, transactions must be executed in nonce order
-- The mempool automatically handles nonce gaps for Ethereum transactions
-- See the [Mempool Architecture](/docs/documentation/concepts/mempool#architecture) for detailed flow diagrams
-
-## Transaction Receipts[​](#transaction-receipts "Direct link to Transaction Receipts")
+In Cosmos EVM, both Ethereum and Cosmos transactions compete fairly for block inclusion:
+
+<Tabs>
+  <Tab title="Fee Priority">
+    Transactions are ordered by their effective tips:
+    - **Ethereum**: `gas_tip_cap` or `min(gas_tip_cap, gas_fee_cap - base_fee)`
+    - **Cosmos**: `(fee_amount / gas_limit) - base_fee`
+    - Higher tips = higher priority, regardless of transaction type
+  </Tab>
+  
+  <Tab title="Nonce Handling">
+    **Ethereum transactions** support nonce gaps:
+    - Correct nonce → immediate broadcast
+    - Nonce gap → queued locally
+    - Gap filled → automatic promotion
+    
+    **Cosmos transactions** require sequential nonces.
+  </Tab>
+</Tabs>
+
+<Info>
+For detailed mempool behavior and flow diagrams, see [Mempool Architecture](/docs/documentation/concepts/mempool#architecture).
+</Info>
+
+## Transaction Receipts
 
 A transaction receipt shows data returned by an Ethereum client to represent the result of a particular transaction, including a hash of the transaction, its block number, the amount of gas used, and, in case of deployment of a smart contract, the address of the contract. Additionally, it includes custom information from the events emitted in the smart contract.