Merge pull request #1135 from MinaProtocol/2025-09-v3-upgrade

45930 · web-flow · commit d5fcaa893460 · 2025-09-24T09:43:44.000-04:00
upgrade docusaurus to v3
diff --git a/docs/exchange-operators/rosetta/build-from-sources.mdx b/docs/exchange-operators/rosetta/build-from-sources.mdx
@@ -21,7 +21,7 @@ If you already have mina-archive up and running, you can also build and run the
 
 :::tip
 
-To run mina daemon and mina-archive natively, follow the [Archive Node page](node-operators/archive-node/getting-started) instructions.
+To run mina daemon and mina-archive natively, follow the [Archive Node page](/node-operators/archive-node/getting-started) instructions.
 
 :::
 
diff --git a/docs/exchange-operators/rosetta/samples/requests.mdx b/docs/exchange-operators/rosetta/samples/requests.mdx
@@ -137,7 +137,8 @@ In Mina implementation, each operation object has following fields:
 - `account`: the account identifier which the operation relates to
 - `amount`: an object with `value` - a signed number representing of the accounts' balance
 
-<details><summary>A sample JSON object that represents an operation</summary>
+<details>
+<summary>A sample JSON object that represents an operation</summary>
 
 ```json
 {
@@ -180,7 +181,8 @@ In Mina, each operation represents an [Account Update](/zkapps/writing-a-zkapp/i
 - for decreasing sender account balance
 - for increasing receiver account balance
 
-<details><summary>A sample object that represents a transfer transaction</summary>
+<details>
+<summary>A sample object that represents a transfer transaction</summary>
 
 ```json
 {
diff --git a/docs/exchange-operators/rosetta/samples/using-signer.mdx b/docs/exchange-operators/rosetta/samples/using-signer.mdx
@@ -32,7 +32,7 @@ To generate a private key, run:
 
 To derive public key, run:
 
-    signer derive-public-key --private-key <private key>
+    signer derive-public-key --private-key `<private key>`
 
 In the output you will also get a Mina account address associated with this key pair.
 
@@ -56,7 +56,7 @@ See [Sending Transactions](send-transactions) page to learn more.
 
 To sign a transaction, run:
 
-    signer sign --private-key <private key> --unsigned-transaction <tx>
+    signer sign --private-key `<private key>` --unsigned-transaction `<tx>`
 
 :::note 
 
diff --git a/docs/mina-protocol/sending-a-payment.mdx b/docs/mina-protocol/sending-a-payment.mdx
@@ -77,7 +77,7 @@ Additionally you can use the `mina accounts create` command to generate new acco
 
 Since the public key is quite long and difficult to remember, let's save it as an environment variable. Use the following command but replace `<YOUR-PUBLIC-KEY>` with the public key output from the previous command:
 
-    export MINA_PUBLIC_KEY=<YOUR-PUBLIC-KEY>
+    export MINA_PUBLIC_KEY=`<YOUR-PUBLIC-KEY>`
 
 Now we can access this everywhere as `$MINA_PUBLIC_KEY` -- check if it saved properly by trying `echo $MINA_PUBLIC_KEY`.
 
@@ -87,15 +87,15 @@ Note that these environment variables will only be saved for the current shell s
 
 If you are running the node on a cloud virtual machine, make sure to export and save the key file. You can export the key with:
 
-    mina accounts export --public-key <PUBLIC-KEY> --privkey-path <EXPORT-PATH>
+    mina accounts export --public-key `<PUBLIC-KEY>` --privkey-path `<EXPORT-PATH>`
 
 Then save it to your local machine, maybe using [scp](https://linux.die.net/man/1/scp):
 
-    scp <EXPORT-PATH> <LOCAL-DESTINATION>
+    scp `<EXPORT-PATH>` `<LOCAL-DESTINATION>`
 
 Later, when starting up a new VM, you can upload the key and then import it:
 
-    mina accounts import --privkey-path <PRIVATE-KEY-FILE>
+    mina accounts import --privkey-path `<PRIVATE-KEY-FILE>`
 
 :::
 
diff --git a/docs/mina-protocol/whats-in-a-block.mdx b/docs/mina-protocol/whats-in-a-block.mdx
@@ -125,7 +125,7 @@ When a [block producer](/mina-protocol/block-producers) wins a slot to produce a
 * A list of SNARK proofs generated by [SNARK workers](/mina-protocol/snark-workers) for prior transactions added
 * Pending coinbase
 
-A staged ledger can be regarded as a pending accounts database that has transactions(payments, coinbase, and proof fee payments) applied for which there are no SNARKs available yet. A staged ledger consists of the accounts state (a ledger) and a transaction queue for transactions without SNARK proofs, which is the [scan state](/node-operators/scan-state).
+A staged ledger can be regarded as a pending accounts database that has transactions(payments, coinbase, and proof fee payments) applied for which there are no SNARKs available yet. A staged ledger consists of the accounts state (a ledger) and a transaction queue for transactions without SNARK proofs, which is the [scan state](/mina-protocol/scan-state).
 
 ### Delta Transition Chain Proof
 
diff --git a/docs/node-developers/index.mdx b/docs/node-developers/index.mdx
@@ -13,7 +13,7 @@ Other documents relevant to contributing code include:
 
 - [Style Guide](/node-developers/style-guide)
 - [Code Review Guidelines](/node-developers/code-review-guidelines)
-- [Repository Structure](/node-developers/directory-structure)
-- [BIP44 Information](/node-developers/bip44-information)
+- [Repository Structure](/node-developers/repository-structure)
+- [BIP44 Information](/node-developers/bip44)
 
 Mina is entirely open source. The code is distributed under the terms of the [Apache License 2.0](https://github.com/MinaProtocol/mina/blob/master/LICENSE).
diff --git a/docs/node-developers/sandbox-node.mdx b/docs/node-developers/sandbox-node.mdx
@@ -44,7 +44,7 @@ And stop mina by running.
 docker stop mina
 ```
 
-You can use the Mina CLI to interact with the sandbox node. The following command opens a shell inside the docker container from where you can issue any of the available [cli commands](/node-operators/cli-reference).
+You can use the Mina CLI to interact with the sandbox node. The following command opens a shell inside the docker container from where you can issue any of the available [cli commands](/node-operators/mina-cli-reference).
 
 ```
 docker exec -it mina bash
diff --git a/docs/node-operators/archive-node/archive-redundancy.mdx b/docs/node-operators/archive-node/archive-redundancy.mdx
@@ -37,7 +37,7 @@ Similarly, it is possible to have multiple archive processes write to the same d
 
 However, multiple archive processes concurrently writing to a database could cause data inconsistencies (explained in https://github.com/MinaProtocol/mina/issues/7567). To avoid this, set the transaction isolation level of the archive database to `Serializable` with the following query:
 
-    ALTER DATABASE <DATABASE NAME> SET DEFAULT_TRANSACTION_ISOLATION TO SERIALIZABLE ;
+    ALTER DATABASE `<DATABASE NAME>` SET DEFAULT_TRANSACTION_ISOLATION TO SERIALIZABLE ;
 
 Set the transaction level after you create the [database](/node-operators/archive-node/getting-started) and before you connect an archive process to it.
 
diff --git a/docs/node-operators/archive-node/getting-started.mdx b/docs/node-operators/archive-node/getting-started.mdx
@@ -114,7 +114,7 @@ To run a local archive node to run it in the foreground for testing:
 
   ```
 
-  To connect to an archive process on another machine, specify a hostname with <ipaddress:portnumber> i.e. `154.97.53.97:3086`.
+  To connect to an archive process on another machine, specify a hostname with `<ipaddress:portnumber>` i.e. `154.97.53.97:3086`.
 
 ## Set up the archive node using Docker
 
@@ -195,7 +195,7 @@ short lived network created mainly for testing, local development or experimenta
      --archive-address 3086
 
    ```
-  To connect to an archive process on another machine, specify a hostname with <ipaddress:portnumber> i.e. `154.97.53.97:3086`.
+  To connect to an archive process on another machine, specify a hostname with `<ipaddress:portnumber>` i.e. `154.97.53.97:3086`.
 
 
 ## Set up the archive node using Docker Compose
@@ -267,7 +267,7 @@ To run the archive node using Docker Compose:
 
    ```
 
-     To connect to an archive process on another machine, specify a hostname with <ipaddress:portnumber> i.e. `154.97.53.97:3086`.
+     To connect to an archive process on another machine, specify a hostname with `<ipaddress:portnumber>` i.e. `154.97.53.97:3086`.
 
 
 ## Using the Archive Node
diff --git a/docs/node-operators/data-and-history/rosetta.mdx b/docs/node-operators/data-and-history/rosetta.mdx
@@ -98,7 +98,7 @@ To run docker-start.sh and connect to the live Devnet:
         -e MINA_ARCHIVE_DUMP_URL=https://storage.googleapis.com/mina-archive-dumps \
         -e MINA_GENESIS_LEDGER_URL=http://673156464838-mina-genesis-ledgers.s3-website-us-west-2.amazonaws.com/devnet/genesis_ledger.json \
         -e BLOCKS_BUCKET=https://storage.googleapis.com/mina_network_block_data \
-        minaprotocol/mina-rosetta:<TAG>
+        minaprotocol/mina-rosetta:`<TAG>`
 
 Please replace `<TAG>` with the latest release tag compatible with the network you are trying to connect to.
 
diff --git a/docs/node-operators/staking-service-guidelines.mdx b/docs/node-operators/staking-service-guidelines.mdx
@@ -59,7 +59,7 @@ It requires an argument to identifier of the ledger you wish to export. The tabl
 <br />
 
 
-In order to ensure you always have each staking ledger available for use after epochs have expired, we recommend exporting the staking-epoch-ledger every $\dfrac{7140\times3}{60} = 357$ hours (there are $7140$ slots in an epoch, and each slot is $3$ minutes long).
+In order to ensure you always have each staking ledger available for use after epochs have expired, we recommend exporting the staking-epoch-ledger every (7140 × 3) ÷ 60 = 357 hours (there are 7140 slots in an epoch, and each slot is 3 minutes long).
 
 By default, ledgers are exported as json data. See `mina ledger export -help` for documentation of flags which will enable other formats. When output as json, the ledger will be represented as an array of account objects. Below is an example of what an account object in json looks like.
 
@@ -108,13 +108,13 @@ Blocks in Mina are produced within distinct time intervals called "slots". Each
 
 The stake distribution that is sampled when determining the VRF threshold are contained in a special ledger called the "staking ledger". Staking ledgers are fixed ledgers from past epochs in the network (epochs are fixed spans of slots; every epoch is 7140 slots long). Using past fixed ledgers prevents malicious stakers from increasing their chances of winning during an epoch by altering the distribution of stake on the main ledger (the "staged ledger"). Every epoch, the staking ledger changes. Due to this constraint, any account on the system can only check for "winning slots" within the next 2 epochs at any given time.
 
-Once you know the staking ledger that will be used for a given epoch, the required VRF threshold for producing blocks in that epoch can be computed for each account. We can compute a stake ratio for a given account by dividing the stake that account controls in the staking ledger by the total amount of currency in the staking ledger. Figure 1 on page 20 of the [Ouroboros Genesis](https://eprint.iacr.org/2018/378.pdf) paper provides the raw function for computing VRF thresholds. Filling in Mina's value for the active slots coefficient $f$ gives us the following function: $\phi\left(\alpha\right) \triangleq 1 - \left(\dfrac{1}{4}\right)^\alpha$. This function takes as a parameter $\alpha$, which is the stake ratio we compute for an account.
+Once you know the staking ledger that will be used for a given epoch, the required VRF threshold for producing blocks in that epoch can be computed for each account. We can compute a stake ratio for a given account by dividing the stake that account controls in the staking ledger by the total amount of currency in the staking ledger. Figure 1 on page 20 of the [Ouroboros Genesis](https://eprint.iacr.org/2018/378.pdf) paper provides the raw function for computing VRF thresholds. Filling in Mina's value for the active slots coefficient f gives us the following function: φ(α) = 1 - (1/4)^α. This function takes as a parameter α, which is the stake ratio we compute for an account.
 
-Since each VRF is compared against this threshold (which is between 0 and 1), and each VRF is a pseudo-random number between 0 and 1, the VRF threshold for a given account is essentially the probability that a slot will be won by that account. Thus, we can extrapolate this function for computing VRF thresholds to compute the mean number of blocks we can expect a given account to win within an epoch. This can be done merely by summing all the probabilities for winning each slot of an epoch, and since the probability for an entire epoch is fixed, the mathematical expression to compute this simplifies to $\phi\left(\alpha\right)\times7140$.
+Since each VRF is compared against this threshold (which is between 0 and 1), and each VRF is a pseudo-random number between 0 and 1, the VRF threshold for a given account is essentially the probability that a slot will be won by that account. Thus, we can extrapolate this function for computing VRF thresholds to compute the mean number of blocks we can expect a given account to win within an epoch. This can be done merely by summing all the probabilities for winning each slot of an epoch, and since the probability for an entire epoch is fixed, the mathematical expression to compute this simplifies to φ(α) × 7140.
 
-As an example, let's say there is an account on the network which has $10^6$ (1 million) mina tokens in the staking ledger epoch $ep$. This same staking ledger for epoch $ep$ has a total supply of $8\times10^8$ (800 million) mina tokens. We can compute the odds that this account will win an individual slot in $ep$ using $\phi\left(\dfrac{10^6}{8\times10^8}\right) = 0.0017313674$. This gives us a $\sim0.17\%$ chance that this account will win each slot during epoch $ep$. We can then compute the mean number of blocks we expect this account to produce for this epoch by multiplying the result by $7140$, giving us a probabilistic mean of $\sim12.36$ blocks for the epoch.
+As an example, let's say there is an account on the network which has 10^6 (1 million) mina tokens in the staking ledger epoch ep. This same staking ledger for epoch ep has a total supply of 8×10^8 (800 million) mina tokens. We can compute the odds that this account will win an individual slot in ep using φ(10^6 ÷ 8×10^8) = 0.0017313674. This gives us a ~0.17% chance that this account will win each slot during epoch ep. We can then compute the mean number of blocks we expect this account to produce for this epoch by multiplying the result by 7140, giving us a probabilistic mean of ~12.36 blocks for the epoch.
 
-Another way to calculate the probability is $1 - 0.25^{\left(\dfrac{10^6}{8\times10^8}\right)}$ which gives the same result as above.
+Another way to calculate the probability is 1 - 0.25^(10^6 ÷ 8×10^8) which gives the same result as above.
 
 ## Sending Many Transactions
 
diff --git a/docs/participate/bugs-and-feature-requests.mdx b/docs/participate/bugs-and-feature-requests.mdx
@@ -25,7 +25,7 @@ You can participate in the private Mina Foundation Bounty Program on [https://ha
 
 ### 4. Found an urgent issue?
 
-If your issue is time-sensitive and needs immediate attention, please send more details and your contact information to <security@o1labs.org>. A member of the engineering team will reach out promptly.
+If your issue is time-sensitive and needs immediate attention, please send more details and your contact information to security@o1labs.org. A member of the engineering team will reach out promptly.
 
 :::note
 
diff --git a/docs/zkapps/faq.mdx b/docs/zkapps/faq.mdx
@@ -52,8 +52,8 @@ A general-purpose API for creating zk proofs. A ZkProgram is similar to a zkApp
 
 Use the appropriate module to work with the live network or with historical archive nodes:
 
-- [getActions](/zkapps/o1js-reference/namespaces/Mina/functions/getactions) works with the blockchain network
-- [fetchActions](/zkapps/o1js-reference/namespaces/Mina/functions/fetchactions) works with archive nodes
+- [getActions](/zkapps/o1js-reference/namespaces/Mina/functions/getActions) works with the blockchain network
+- [fetchActions](/zkapps/o1js-reference/namespaces/Mina/functions/fetchActions) works with archive nodes
 
 ### Does o1js compile my JavaScript code to an arithmetic circuit?
 
diff --git a/docs/zkapps/o1js-reference/classes/Int64.mdx b/docs/zkapps/o1js-reference/classes/Int64.mdx
@@ -486,7 +486,7 @@ mod(y:
 Calculates the integer remainder of this Int64 divided by the given value.
 
 The result `z` satisfies the following conditions:
-1. 0 <= z < |y|
+1. 0 ≤ z &lt; |y|
 2. x - z is divisible by y
 
 Note: This method follows the "truncate toward zero" convention for negative numbers.
diff --git a/docs/zkapps/o1js-reference/classes/TokenAccountUpdateIterator.mdx b/docs/zkapps/o1js-reference/classes/TokenAccountUpdateIterator.mdx
@@ -122,7 +122,7 @@ exactly once, when called repeatedly.
 
 The method makes a best effort to avoid visiting account updates that are not using the token,
 and in particular, to avoid returning dummy updates.
-However, neither can be ruled out. We're returning { update, usesThisToken: Bool } and let the
+However, neither can be ruled out. We're returning `{ update, usesThisToken: Bool }` and let the
 caller handle the irrelevant case where `usesThisToken` is false.
 
 #### Returns
diff --git a/docs/zkapps/o1js-reference/variables/Gadgets.mdx b/docs/zkapps/o1js-reference/variables/Gadgets.mdx
@@ -315,7 +315,7 @@ It only guarantees that the result is in the correct residue class.
 Prove that each of the given Field3 elements is "almost" reduced modulo f,
 i.e., satisfies the assumptions required by Gadgets.ForeignField.mul and other gadgets:
 - each limb is in the range [0, 2^88)
-- the most significant limb is less or equal than the modulus, x[2] <= f[2]
+- the most significant limb is less or equal than the modulus, x[2] ≤ f[2]
 
 **Note**: This method is most efficient when the number of input elements is a multiple of 3.
 
@@ -393,7 +393,7 @@ Gadgets.ForeignField.assertLessThan(x, f);
 
 ### ForeignField.assertLessThanOrEqual()
 
-Prove that x <= f for any constant f < 2^264, or for another `Field3` f.
+Prove that x ≤ f for any constant f &lt; 2^264, or for another `Field3` f.
 
 See [ForeignField.assertLessThan](../classes/ForeignField.mdx#assertlessthan) for details and usage examples.
 
diff --git a/docs/zkapps/o1js/bitwise-operations.mdx b/docs/zkapps/o1js/bitwise-operations.mdx
@@ -120,7 +120,7 @@ c.assertEquals(0b0110);
 leftShift32(field: Field, bits: number) => Field
 ```
 
-The `leftShift32()` gadget is a provable equivalent to the [Left shift (<<)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Left_shift) operator in JavaScript. It moves the bits of a binary number to the left by the specified number of `bits`. Any bits that fall off the left side are discarded. 0s are padded in from the right. It returns a new `Field` element that is range-checked to 32 bits.
+The `leftShift32()` gadget is a provable equivalent to the [Left shift (&lt;&lt;)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Left_shift) operator in JavaScript. It moves the bits of a binary number to the left by the specified number of `bits`. Any bits that fall off the left side are discarded. 0s are padded in from the right. It returns a new `Field` element that is range-checked to 32 bits.
 
 The input `Field` must not exceed 32 bits in size. You can use [rangeCheck32](#rangecheck32) to ensure this.
 
@@ -138,7 +138,7 @@ y.assertEquals(0b110000); // 48 in binary
 leftShift64(field: Field, bits: number) => Field
 ```
 
-The `leftShift64()` gadget is a provable equivalent to the [Left shift (<<)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Left_shift) operator in JavaScript. It moves the bits of a binary number to the left by the specified number of `bits`. Any bits that fall off the left side are discarded. 0s are padded in from the right. It returns a new `Field` element that is range-checked to 64 bits.
+The `leftShift64()` gadget is a provable equivalent to the [Left shift (&lt;&lt;)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Left_shift) operator in JavaScript. It moves the bits of a binary number to the left by the specified number of `bits`. Any bits that fall off the left side are discarded. 0s are padded in from the right. It returns a new `Field` element that is range-checked to 64 bits.
 
 The input `Field` must not exceed 64 bits in size. You can use [rangeCheck64](#rangecheck64) to ensure this.
 
diff --git a/docs/zkapps/o1js/foreign-fields.mdx b/docs/zkapps/o1js/foreign-fields.mdx
diff --git a/docs/zkapps/tutorials/anonymous-message-board.mdx b/docs/zkapps/tutorials/anonymous-message-board.mdx
diff --git a/docusaurus.config.js b/docusaurus.config.js
diff --git a/package-lock.json b/package-lock.json
diff --git a/package.json b/package.json
diff --git a/src/theme/DocItem/Footer/index.js b/src/theme/DocItem/Footer/index.js
diff --git a/src/theme/DocItem/Layout/index.js b/src/theme/DocItem/Layout/index.js
diff --git a/src/theme/DocItem/TOC/Desktop/index.js b/src/theme/DocItem/TOC/Desktop/index.js
