Replaced blockquotes with callout

.vitepress/theme/components/DocFooter.vue

@@ -29,7 +29,7 @@ const { hasNext, hasPrev, next, prev } = usePrevNext()
 <template>
   <nav
     v-if="frontmatter.footer !== false" mx-auto max-md:px-32
-    max-w="74ch" grid="~ cols-1 sm:cols-[auto_auto] justify-between gap-16 md:gap-40" pt-0 pb="96 md:128"
+    max-w="74ch" grid="~ cols-1 sm:cols-[auto_auto] justify-between items-center gap-16 md:gap-40" pt-0 pb="96 md:128"
     :class="!hasPrev && !hasNext ? 'grid-rows-1' : 'grid-rows-[auto_auto_auto_auto] xs:grid-rows-2'"
   >
     <a :href="editThisLink" target="_blank" rel="noopener" un-text-12 op70 arrow lh-0>

learn/protocol/mempool.md

@@ -40,7 +40,11 @@ After the two mempools are fed with transactions respecting the verification pro
 
 ![Alt Text](/assets/images/protocol/mempool.png)
 
-> 💡 Note that once the transactions are added to the micro block, they aren’t ordered. The order is made in the mempool.
+<Callout type='info'>
+
+Note that once the transactions are added to the micro block, they aren’t ordered. The order is made in the mempool.
+
+</Callout>
 
 After a transaction is added, the user’s balance is updated, and the validators must update their mempool accordingly. Mind that each validator owns a mempool and broadcasts and verifies transactions constantly. Adding and deleting transactions from each mempool is a continuous process. Also, two validators may attempt to add the same transaction to different blocks. In this case, the first transaction to be added is the valid one, and the other validator must discard the respective transaction in his mempool.
 

learn/protocol/rpc-client.md

@@ -1,6 +1,6 @@
 # RPC client
 
-## Requisites
+## Requirements
 
 - Rust and its package manager Cargo (installation instructions [here](https://www.rust-lang.org/learn/get-started))
 - Clone the Albatross source code from [GitHub](https://github.com/nimiq/core-rs-albatross) and follow the [installation instructions](https://github.com/nimiq/core-rs-albatross#installation)
@@ -16,7 +16,11 @@ The usage of the RPC client is exclusive to Nimiq clients. To interact with the
 5. Run `./nimiq-rpc` to fetch a list of all available commands
 6. For a detailed description of a command usage, add the desired command followed by `--help`
 
-> 👉 Commands may require additional arguments and/or allow further options as input. Commands with available options work without the option added; however, commands with arguments return an error if the argument is not added.
+<Callout type="tip">
+
+Commands may require additional arguments and/or allow further options as input. Commands with available options work without the option added; however, commands with arguments return an error if the argument is not added.
+
+</Callout>
 
 Listed below are the commands grouped by subject and a few examples of the usage of the RPC client.
 

learn/protocol/sync-protocol/state-live-sync.md

@@ -12,7 +12,11 @@ Hash values are propagated up the tree from lower to higher levels until the sta
 
 ![Alt Text](/assets/images/protocol/merkle.png)
 
-> 💡 This figure is merely illustrative as the accounts tree hold multiple accounts.
+<Callout type='warning'>
+
+This figure is merely illustrative as the accounts tree hold multiple accounts.
+
+</Callout>
 
 ## State sync
 

learn/protocol/transactions.md

@@ -44,4 +44,6 @@ Hence, when a validator includes a transaction to the micro block, it may succee
 - **Succeed**: the sender has enough funds to cover both the transaction value and fees, and the user’s balance is updated.
 - **Failed**: the sender has insufficient funds to pay out the transaction value but transaction fees can be deducted.
 
-> 💡 Let's consider a scenario where Alice, with 100 NIM in her balance, sends two transactions. In the first transaction (transaction 1), she intends to send 80 NIM to Bob. Following the succeed-fail principle mentioned above, transaction 1 succeeds. However, immediately after, Alice attempts to send 50 NIM to Charlie in transaction 2, which fails due to insufficient balance. Both transactions are recorded in the blockchain. Transaction 1 is logged as a successful transaction, whereas transaction 2 is marked as fail. Our protocol accommodates failed transactions, deducting the associated fees even in cases of failure.
+---
+
+Let's consider a scenario where Alice, with 100 NIM in her balance, sends two transactions. In the first transaction (transaction 1), she intends to send 80 NIM to Bob. Following the succeed-fail principle mentioned above, transaction 1 succeeds. However, immediately after, Alice attempts to send 50 NIM to Charlie in transaction 2, which fails due to insufficient balance. Both transactions are recorded in the blockchain. Transaction 1 is logged as a successful transaction, whereas transaction 2 is marked as fail. Our protocol accommodates failed transactions, deducting the associated fees even in cases of failure.

package.json

@@ -29,7 +29,7 @@
     "jszip": "^3.10.1",
     "markdown-it-mathjax3": "^4.3.2",
     "medium-zoom": "^1.1.0",
-    "nimiq-css": "^0.0.62",
+    "nimiq-css": "^0.0.63",
     "prettier": "^3.2.5",
     "radix-vue": "^1.6.2",
     "svg-packer": "^0.0.3",