From 97bc077ae819900ce325402327059bdd9162f21f Mon Sep 17 00:00:00 2001 From: Shigoto-dev19 Date: Wed, 4 Feb 2026 22:49:01 +0300 Subject: [PATCH 1/6] Add Mesa upgrade overview and update docs for MIPs 7-9 --- docs/glossary.mdx | 4 +- docs/mesa-upgrade/archive-upgrade.mdx | 2 +- docs/mesa-upgrade/mesa-upgrade-overview.mdx | 107 ++++++++++++++++++ docs/zkapps/tutorials/10-account-updates.mdx | 6 + .../feature-overview/actions-and-reducer.mdx | 6 + .../feature-overview/events.mdx | 6 + .../feature-overview/on-chain-values.mdx | 4 +- .../how-zkapps-work.mdx | 2 +- .../smart-contracts.mdx | 4 +- sidebars.js | 10 +- 10 files changed, 142 insertions(+), 9 deletions(-) create mode 100644 docs/mesa-upgrade/mesa-upgrade-overview.mdx diff --git a/docs/glossary.mdx b/docs/glossary.mdx index 515bef481..6052071d4 100644 --- a/docs/glossary.mdx +++ b/docs/glossary.mdx @@ -333,7 +333,7 @@ A transfer of value or data, including transactions, that exist on and have been ### on-chain state -State that lives on the Mina blockchain. Each zkApp account provides eight fields of 32 bytes each of arbitrary storage for the on-chain state. +State that lives on the Mina blockchain. Each zkApp account provides 32 fields of 32 bytes each of arbitrary storage for the on-chain state. ### oracle @@ -601,7 +601,7 @@ A command line tool that zkApp developers use to scaffold and deploy smart contr ### zkApp account -A smart contract account. Each zkApp account provides 8 fields of 32 bytes each of arbitrary storage. When a Mina address contains a verification key, it acts as a zkApp account. +A smart contract account. Each zkApp account provides 32 fields of 32 bytes each of arbitrary storage. When a Mina address contains a verification key, it acts as a zkApp account. ### zkApp manager account diff --git a/docs/mesa-upgrade/archive-upgrade.mdx b/docs/mesa-upgrade/archive-upgrade.mdx index ea11192af..7ebf9a671 100644 --- a/docs/mesa-upgrade/archive-upgrade.mdx +++ b/docs/mesa-upgrade/archive-upgrade.mdx @@ -134,7 +134,7 @@ The `zkapp_state_nullable` table has been modified to include new columns `eleme ); ``` -This expansion allows zkApps to store up to 31 state elements instead of the previous 8, significantly increasing the state storage capacity for complex smart contracts. +This expansion allows zkApps to store up to 32 state elements (element0 through element31) instead of the previous 8, significantly increasing the state storage capacity for complex smart contracts. ### Version Table diff --git a/docs/mesa-upgrade/mesa-upgrade-overview.mdx b/docs/mesa-upgrade/mesa-upgrade-overview.mdx new file mode 100644 index 000000000..57adbe0e2 --- /dev/null +++ b/docs/mesa-upgrade/mesa-upgrade-overview.mdx @@ -0,0 +1,107 @@ +--- +title: Mesa Upgrade Overview +sidebar_label: Overview +description: Overview of the Mesa upgrade for the Mina network, including MIP-7 (expanded on-chain state), MIP-8 (actions and events), and MIP-9 (account update limits). +keywords: + - Mesa upgrade + - MIP-7 + - MIP-8 + - MIP-9 + - on-chain state + - account updates + - actions + - events + - hardfork + - mina upgrade +--- + +# Mesa Upgrade Overview + +The Mesa upgrade is Mina Protocol's hard fork that bundles four Mina Improvement Proposals (MIPs 6-9). These proposals were approved through an on-chain community vote. + +This page summarizes the key changes that affect zkApp developers. + +## MIP-7: Expanded On-Chain State + +Each zkApp account's on-chain state has been expanded from **8 fields to 32 fields** (each field is ~32 bytes). + +### Before Mesa + +- zkApp accounts could store at most **8 field elements** of on-chain state. +- Developers frequently needed workarounds for storage-constrained applications: packing multiple values into a single field, splitting state across multiple zkApp accounts, or pushing state off-chain. + +### After Mesa + +- zkApp accounts can store up to **32 field elements** of on-chain state. +- This enables simpler zkApps as you get more storage for metadata and avoid the complicated workarounds that add dev overhead and circuit constraints, although it wouldn't completely remove the need for the workarounds mentioned above if you need to store more than 32 states. + +For more details on on-chain state, see [Smart Contracts](/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts#on-chain-state) and [On-Chain Values](/zkapps/writing-a-zkapp/feature-overview/on-chain-values). + +## MIP-8: Increased Actions and Events Capacity + +The per-transaction capacity for both actions and events has been significantly increased. + +### Before Mesa + +| Limit | Value | +| ----------------------------------------- | ----- | +| Max event field elements per transaction | 100 | +| Max action field elements per transaction | 100 | + +### After Mesa + +| Limit | Value | +| ----------------------------------------- | ----- | +| Max event field elements per transaction | 1,024 | +| Max action field elements per transaction | 1,024 | + +This 10x increase allows zkApps to emit richer, more expressive events and actions within a single transaction. Applications that need to log detailed state transitions or dispatch complex actions benefit from the expanded capacity. + +For more details on actions and events, see [Events](/zkapps/writing-a-zkapp/feature-overview/events), [Actions & Reducer](/zkapps/writing-a-zkapp/feature-overview/actions-and-reducer), and [How to Fetch Events and Actions](/zkapps/writing-a-zkapp/feature-overview/fetch-events-and-actions). + +## MIP-9: Increased Account Update Limits + +The transaction cost model for account updates has been simplified and the limits increased. + +### Before Mesa + +Transactions used a **cost-based model** where each type of account update segment had a fractional cost, and the total cost of all segments had to stay within a limit of 69.45 cost units: + +| Segment Type | Cost per Segment | +| -------------------------- | ---------------- | +| Proof-based update | 10.26 | +| Signed pair update | 10.08 | +| Signed single update | 9.14 | +| **Transaction cost limit** | **69.45** | + +This yielded approximately **6 proof-based** or **7 signature-based** account updates per transaction. + +### After Mesa + +Mesa replaces the cost-based model with a simpler **segment-count model**. Each segment counts as 1 unit regardless of type, with a maximum of **16 segments per transaction**: + +| Segment Type | Cost per Segment | +| -------------------------------- | ---------------- | +| Proof-based update | 1 | +| Signed pair update | 1 | +| Signed single update | 1 | +| **Max segments per transaction** | **16** | + +This means: + +- **Up to 16 proof-based account updates** per transaction (previously ~6) +- **Up to 16 signed-single account updates** per transaction +- **Up to 32 signature-based account updates** if all are paired (16 pairs) +- Any combination where `proof_segments + signed_single_segments + signed_pair_segments <= 16` + +This enables fitting more account updates into one transaction, whether by multiple calls or interactions with zkApps, or more logic in your zkApp including cross-calls with other zkApps within one zkApp method. + +:::note + +In practice, each zkApp method call generates one proof-based account update. The highest total number of account updates in a single transaction would be 31: 1 proof segment for the method call plus 15 signed-pair segments (each containing 2 updates = 30 signed updates). + +The actual number of max account updates varies depending on the combination of segments used. + +::: + +For more details on account updates, see [Tutorial 10: Account Updates](/zkapps/tutorials/account-updates). diff --git a/docs/zkapps/tutorials/10-account-updates.mdx b/docs/zkapps/tutorials/10-account-updates.mdx index edba2d1f2..aa627ea83 100644 --- a/docs/zkapps/tutorials/10-account-updates.mdx +++ b/docs/zkapps/tutorials/10-account-updates.mdx @@ -21,6 +21,12 @@ keywords: The fundamental data structure that Mina transactions are built from is called an _account update_. Account updates are a flexible and powerful data structure that can express all kinds of updates, events, and preconditions you use to develop smart contracts. +:::info Mesa Upgrade + +The account updates limit has been increased from ~6 to **16 segments per transaction**. See the [Mesa upgrade overview](/mesa-upgrade/mesa-upgrade-overview#mip-9-increased-account-update-limits) for more details. + +::: + Each zkApp transaction constructed by o1js is composed of one or more [AccountUpdate](../o1js-reference/classes/AccountUpdate) classes, which are a set of instructions for the Mina network to perform, such as altering on-chain state, emitting an event, and so on. Each `AccountUpdate` can make assertions about its account, apply updates to its account, and make assertions about its child `AccountUpdates`. diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/actions-and-reducer.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/actions-and-reducer.mdx index e0fa24586..d648bc2b8 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/actions-and-reducer.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/actions-and-reducer.mdx @@ -27,6 +27,12 @@ Please follow the guidelines [**here**](/zkapps/writing-a-zkapp/introduction-to- ::: +:::info Mesa Upgrade + +With the [Mesa upgrade](/mesa-upgrade/mesa-upgrade-overview), the per-transaction capacity for actions has been increased from 100 to **1,024 field elements**. This allows zkApps to dispatch richer, more complex actions within a single transaction. + +::: + # Actions & Reducer Like events, **actions** are _public_ arbitrary information that are passed along with a zkApp transaction. However, actions give you additional power: you can process previous actions in a smart contract! Under the hood, this is possible because a commitment is stored to the history of dispatched actions on every account -- the **actionState**. It allows you to prove that the actions you process are, in fact, the actions that were dispatched to the same smart contract. diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/events.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/events.mdx index 838a6a64a..2d9594871 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/events.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/events.mdx @@ -65,6 +65,12 @@ A zkApp can retrieve events and actions from one or more Mina archive nodes. If ::: +:::info Mesa Upgrade + +With the [Mesa upgrade](/mesa-upgrade/mesa-upgrade-overview), the per-transaction capacity for events has been increased from 100 to **1,024 field elements**. This allows zkApps to emit richer, more detailed events within a single transaction. + +::: + This is all you need to know about events! Think of them as a convenience feature -- a lightweight way of attaching information about your smart contract execution to expose the event to the outside world, such as your UI. Don't treat events as fully-fledged storage that can be safely accessed in smart contracts. ### Events: API reference diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/on-chain-values.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/on-chain-values.mdx index 653a1b59a..3ab58a54d 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/on-chain-values.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/on-chain-values.mdx @@ -21,7 +21,7 @@ import MigrateBanner from '@site/src/components/snippets/migrate-banner.mdx'; In a zkApp, you can access the current [on-chain state](/zkapps/writing-a-zkapp/introduction-to-zkapps/how-to-write-a-zkapp#on-chain-state) and many other on-chain values of the account. -The zkApp account's on-chain state can be updated by account updates included in a transaction (see [Tutorial 10: Account Updates](/zkapps/tutorials/account-updates)). On the Mina blockchain, each zkApp account provides eight fields of ~32 bytes each of arbitrary storage for the on-chain state. +The zkApp account's on-chain state can be updated by account updates included in a transaction (see [Tutorial 10: Account Updates](/zkapps/tutorials/account-updates)). On the Mina blockchain, each zkApp account provides 32 fields of ~32 bytes each of arbitrary storage for the on-chain state. Two possible use cases: @@ -116,7 +116,7 @@ this.account.nonce.get(): UInt32; this.account.delegate.get(): PublicKey; // boolean indicating whether an account is new (= didn't exist before the transaction) this.account.isNew.get(): Bool; -// boolean indicating whether all 8 on-chain state fields where last changed by a transaction +// boolean indicating whether all 32 on-chain state fields where last changed by a transaction // authorized by a zkApp proof (as opposed to a signature) this.account.provedState.get(): Bool; // hash receipt which includes all prior transaction to an account diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/how-zkapps-work.mdx b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/how-zkapps-work.mdx index 1c094e741..6a50b221d 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/how-zkapps-work.mdx +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/how-zkapps-work.mdx @@ -141,7 +141,7 @@ The integrity of these account updates is ensured by passing a hash of the accou ### On-chain state -Each zkApp account provides 8 fields of 32 bytes each of arbitrary storage. You may store anything here as long as it fits in the size provided. +Each zkApp account provides 32 fields of 32 bytes each of arbitrary storage. You may store anything here as long as it fits in the size provided. If you anticipate your state to be larger, or if the state accumulates per user with your zkApp, then use off-chain state instead. diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts.mdx b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts.mdx index ac3299d4f..767553a8d 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts.mdx +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/smart-contracts.mdx @@ -110,9 +110,9 @@ class HelloWorld extends SmartContract { } ``` -Here, `x` is of type `Field`. Like with method inputs, only o1js structs can be used for state variables. The state can consist of at most 8 fields of 32 bytes each. These states are stored on the zkApp account. +Here, `x` is of type `Field`. Like with method inputs, only o1js structs can be used for state variables. The state can consist of at most 32 fields of 32 bytes each. These states are stored on the zkApp account. -Some structs take up more than one `Field`. For example, a `PublicKey` needs two of the eight fields. +Some structs take up more than one `Field`. For example, a `PublicKey` needs two of the 32 fields. States are initialized with the `State()` function. diff --git a/sidebars.js b/sidebars.js index 0cfff6d68..b00ac4119 100644 --- a/sidebars.js +++ b/sidebars.js @@ -40,7 +40,15 @@ module.exports = { { type: 'category', label: 'Mesa Upgrade', - items: ['mesa-upgrade/preflight-network', 'mesa-upgrade/archive-upgrade'], + link: { + type: 'doc', + id: 'mesa-upgrade/mesa-upgrade-overview', + }, + items: [ + 'mesa-upgrade/mesa-upgrade-overview', + 'mesa-upgrade/preflight-network', + 'mesa-upgrade/archive-upgrade', + ], }, { type: 'category', From 1dcdc8e6b8a3f379678d29aefe1e970a2006cedb Mon Sep 17 00:00:00 2001 From: Shigoto-dev19 Date: Wed, 4 Feb 2026 23:06:16 +0300 Subject: [PATCH 2/6] Document MIP-6 slot time reduction and update slot references across docs --- docs/exchange-operators/faq.mdx | 2 +- docs/glossary.mdx | 4 +-- docs/mesa-upgrade/mesa-upgrade-overview.mdx | 28 ++++++++++++++++++- docs/mina-protocol/lifecycle-of-a-payment.mdx | 12 ++++---- docs/mina-protocol/time-locked-accounts.mdx | 2 +- .../archive-node/archive-redundancy.mdx | 2 +- .../staking-service-guidelines.mdx | 2 +- docs/node-operators/troubleshooting.mdx | 4 +-- .../feature-overview/on-chain-values.mdx | 2 +- .../feature-overview/time-locked-accounts.mdx | 2 +- .../how-to-write-a-zkapp.mdx | 2 +- 11 files changed, 44 insertions(+), 18 deletions(-) diff --git a/docs/exchange-operators/faq.mdx b/docs/exchange-operators/faq.mdx index 689cdb85a..e5bba6227 100644 --- a/docs/exchange-operators/faq.mdx +++ b/docs/exchange-operators/faq.mdx @@ -86,7 +86,7 @@ To calculate your transaction fees, use [https://fees.mina.tools](https://fees.m This is a known issue for some earlier releases. Restart your mina node whenever this issue is detected. -You can use the following script to run a cron job every 3 minutes (the slot length) or more frequently: +You can use the following script to run a cron job every 90 seconds (the slot length) or more frequently: ``` MINA_STATUS=$($MINA client status --json) diff --git a/docs/glossary.mdx b/docs/glossary.mdx index 6052071d4..0870f39f0 100644 --- a/docs/glossary.mdx +++ b/docs/glossary.mdx @@ -165,7 +165,7 @@ An approach to public key cryptography based on the algebraic structure of ellip ### epoch -A unit of time equal to 7140 slots at Mainnet. An epoch is divided into [slots](#slot) of 3 minutes each. +A unit of time equal to 7140 slots at Mainnet. An epoch is divided into [slots](#slot) of 90 seconds each. ### extensional blocks @@ -471,7 +471,7 @@ The local testing blockchain you use in the first phase of testing. Using a simu ### slot -A unit of time in the Mina network. As of Mainnet launch, a slot in Mina is 3minutes long. An [epoch](#epoch) is divided into slots. Block producers can find eligible slots to produce blocks in to earn rewards. +A unit of time in the Mina network. A slot in Mina is 90 seconds long. An [epoch](#epoch) is divided into slots. Block producers can find eligible slots to produce blocks in to earn rewards. ### smart contract diff --git a/docs/mesa-upgrade/mesa-upgrade-overview.mdx b/docs/mesa-upgrade/mesa-upgrade-overview.mdx index 57adbe0e2..10947fca4 100644 --- a/docs/mesa-upgrade/mesa-upgrade-overview.mdx +++ b/docs/mesa-upgrade/mesa-upgrade-overview.mdx @@ -1,12 +1,14 @@ --- title: Mesa Upgrade Overview sidebar_label: Overview -description: Overview of the Mesa upgrade for the Mina network, including MIP-7 (expanded on-chain state), MIP-8 (actions and events), and MIP-9 (account update limits). +description: Overview of the Mesa upgrade for the Mina network, including MIP-6 (slot time reduction), MIP-7 (expanded on-chain state), MIP-8 (actions and events), and MIP-9 (account update limits). keywords: - Mesa upgrade + - MIP-6 - MIP-7 - MIP-8 - MIP-9 + - slot time - on-chain state - account updates - actions @@ -21,6 +23,30 @@ The Mesa upgrade is Mina Protocol's hard fork that bundles four Mina Improvement This page summarizes the key changes that affect zkApp developers. +## MIP-6: Slot Time Reduction + +The slot duration has been halved, increasing block production frequency and reducing transaction inclusion latency. + +### Before Mesa + +| Parameter | Value | +| ------------- | -------------------- | +| Slot duration | 180 seconds (3 min) | + +### After Mesa + +| Parameter | Value | +| ------------- | -------------------- | +| Slot duration | 90 seconds (1.5 min) | + +The 50% reduction in slot time means blocks are produced twice as frequently, which roughly halves the time it takes for transactions to be included in a block. + +:::note + +The reduced slot time does not mean every transaction is included within 90 seconds. Transaction inclusion latency ranges from roughly 40 to 600 seconds, which is approximately half the previous range. The slot duration defines the block production window, not a guarantee on individual transaction confirmation time. + +::: + ## MIP-7: Expanded On-Chain State Each zkApp account's on-chain state has been expanded from **8 fields to 32 fields** (each field is ~32 bytes). diff --git a/docs/mina-protocol/lifecycle-of-a-payment.mdx b/docs/mina-protocol/lifecycle-of-a-payment.mdx index 536e98c21..4c439da4e 100644 --- a/docs/mina-protocol/lifecycle-of-a-payment.mdx +++ b/docs/mina-protocol/lifecycle-of-a-payment.mdx @@ -51,15 +51,15 @@ With each subsequent block, a recipient has a higher degree of confidence that t In the Bitcoin network, a transaction is confirmed after [6 blocks](https://en.bitcoin.it/wiki/Confirmation) (60 mins) with an assumption that an attacker is unlikely to amass more than 10% of the hashrate. -With a slot duration of 3 mins and assuming 90% honest stake, the following table shows the finality in blocks, the average time it takes to produce the corresponding number of blocks, and the confidence that payment will be confirmed. +With a slot duration of 90 seconds and assuming 90% honest stake, the following table shows the finality in blocks, the average time it takes to produce the corresponding number of blocks, and the confidence that payment will be confirmed. | Finality (in blocks) | Average time for finality | Finality confidence (%) | | -------------------- | ------------------------- | ----------------------- | -| 8 | 33 mins | 98.6709 | -| 15 | 60 mins | 99.9231 | -| 23 | 1hr 32mins | 99.9965 | -| 30 | 2hrs | 99.9998 | -| 38 | 2hrs 32mins | 100 | +| 8 | 16 mins | 98.6709 | +| 15 | 30 mins | 99.9231 | +| 23 | 46 mins | 99.9965 | +| 30 | 60 mins | 99.9998 | +| 38 | 1hr 16mins | 100 | Average time is calculated based on consensus constants that determine the number of slots filled per epoch. This is currently set to 75%. diff --git a/docs/mina-protocol/time-locked-accounts.mdx b/docs/mina-protocol/time-locked-accounts.mdx index f639e67e2..e7121d33f 100644 --- a/docs/mina-protocol/time-locked-accounts.mdx +++ b/docs/mina-protocol/time-locked-accounts.mdx @@ -34,7 +34,7 @@ If you'd like to expose liquid balances for vesting accounts at some particular ``` (* - * uint32 global_slot -- the "clock" it starts at 0 at the genesis block and ticks up every 3minutes. + * uint32 global_slot -- the "clock" it starts at 0 at the genesis block and ticks up every 90 seconds. * uint32 cliff_time -- the slot where the cliff is (similar to startup equity vesting) * uint32 cliff_amount -- the amount that unlocks at the cliff * amount vesting_increment -- unlock this amount every "period" diff --git a/docs/node-operators/archive-node/archive-redundancy.mdx b/docs/node-operators/archive-node/archive-redundancy.mdx index addf0cd26..6a25a3bde 100644 --- a/docs/node-operators/archive-node/archive-redundancy.mdx +++ b/docs/node-operators/archive-node/archive-redundancy.mdx @@ -123,6 +123,6 @@ Export these ledgers using the mina cli command: mina ledger export [current-staged-ledger|staking-epoch-ledger|next-epoch-ledger] -Epoch ledger transition happens once every 14 days (given slot-time = 3mins and slots-per-epoch = 7140). +Epoch ledger transition happens once every 7 days (given slot-time = 90 seconds and slots-per-epoch = 7140). The window to backup a staking ledger is ~27 days considering "next" staking ledger is finalized after k (currently 290) blocks in the current epoch and therefore is available for the rest of the current epoch and the entire next epoch. diff --git a/docs/node-operators/staking-service-guidelines.mdx b/docs/node-operators/staking-service-guidelines.mdx index d1ba93a7b..c18679e73 100644 --- 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
-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). +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 × 1.5) ÷ 60 = 178.5 hours (there are 7140 slots in an epoch, and each slot is 90 seconds 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. diff --git a/docs/node-operators/troubleshooting.mdx b/docs/node-operators/troubleshooting.mdx index daff746ba..8e88f40e5 100644 --- a/docs/node-operators/troubleshooting.mdx +++ b/docs/node-operators/troubleshooting.mdx @@ -308,7 +308,7 @@ It is also possible to produce a block in catchup, and this block will also be q There are a few reasons why you could miss a slot / not successfully produce a block, for example, the node restarting and being in bootstrap at the time of producing a slot. -Also, you must produce a block within the slot time (3 mins). If you are on less powerful hardware or the daemon is competing for resources, it may not produce the block in time. In this instance, you should find in your logs: +Also, you must produce a block within the slot time (90 seconds). If you are on less powerful hardware or the daemon is competing for resources, it may not produce the block in time. In this instance, you should find in your logs: `Internally generated block $state_hash cannot be rebroadcast because it's not a valid time to do so ($timing)` @@ -316,7 +316,7 @@ It is not recommended to run a SNARK worker on the same machine at the same time ### Why is the block rate so low / how often should there be a block? -A slot on the current network is every 3 mins, though not all slots should have a block produced, so on average, we would expect a block every 4 mins. However, not all the stake is online and active in producing blocks, and so not all slots will have a block, and sometimes there can be long delays between blocks. As more of the stake is online and staking, this situation improves. +A slot on the current network is every 90 seconds, though not all slots should have a block produced, so on average, we would expect a block every 2 mins. However, not all the stake is online and active in producing blocks, and so not all slots will have a block, and sometimes there can be long delays between blocks. As more of the stake is online and staking, this situation improves. ### Why does o1Labs win most of the blocks? diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/on-chain-values.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/on-chain-values.mdx index 3ab58a54d..d5e533ea7 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/on-chain-values.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/on-chain-values.mdx @@ -78,7 +78,7 @@ this.network.timestamp.get(): UInt64; this.network.blockchainLength.get(): UInt32; // total minted currency measured in units of 1e-9 MINA this.network.totalCurrency.get(): UInt64; -// slots since genesis / hardfork -- a "slot" is the Mina-native time unit of 3 minutes +// slots since genesis / hardfork -- a "slot" is the Mina-native time unit of 90 seconds this.network.globalSlotSinceGenesis.get(): UInt32; this.network.globalSlotSinceHardFork.get(): UInt32; // hash of the snarked ledger -- i.e., the state of Mina included in the blockchain proof diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/time-locked-accounts.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/time-locked-accounts.mdx index 32ddc2316..667f90e87 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/time-locked-accounts.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/time-locked-accounts.mdx @@ -60,7 +60,7 @@ As shown, the maximum amount of unlocked tokens is defined by the `initialMinimu The other timing-related properties are: -- `cliffTime`: The initial time period during which all tokens are locked (should be from the current slot onwards). Note that 'time' is measured in Mina by 'slots', where 1 slot is 3min. +- `cliffTime`: The initial time period during which all tokens are locked (should be from the current slot onwards). Note that 'time' is measured in Mina by 'slots', where 1 slot is 90 seconds. - `cliffAmount`: The quantity of tokens to be unlocked when the cliff time has elapsed. If this amount is greater or equal the 'initial minimum balance', all tokens are unlocked after the cliff time elapses. - `vestingPeriod`: After the cliff time elapses, tokens can be set to unlock periodically at a fixed interval, by a fixed quantity. The vesting period is the length of that interval. - `vestingIncrement`: The quantity of tokens that are unlocked after each vesting period elapses. diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/how-to-write-a-zkapp.mdx b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/how-to-write-a-zkapp.mdx index 8c0cbe208..ffc3866e4 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/how-to-write-a-zkapp.mdx +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/how-to-write-a-zkapp.mdx @@ -157,7 +157,7 @@ Examples are based on the standard project structure and provide additional file 1. Fund the fee payer account. After you fund the fee payer account, you can use to to pay fees across multiple zkApps. - Follow the prompts to request tMINA to fund your fee payer account. For this example, your MINA address is populated on the Testnet Faucet. tMINA arrives at your address when the next block is produced (~3 minutes). + Follow the prompts to request tMINA to fund your fee payer account. For this example, your MINA address is populated on the Testnet Faucet. tMINA arrives at your address when the next block is produced (~90 seconds). 1. Deploy to Testnet: From e61440ca1a44f035cb1ec9ca41dfeeaf31aaae5c Mon Sep 17 00:00:00 2001 From: Shigoto-dev19 Date: Wed, 4 Feb 2026 23:48:45 +0300 Subject: [PATCH 3/6] Update block rewards and delegation latency for MIP-6 --- .../data-and-history/querying-data.mdx | 2 +- .../foundation-delegation-program.mdx | 16 ++++++++-------- docs/node-operators/staking-and-snarking.mdx | 6 +++--- docs/using-mina/how-to-delegate.mdx | 8 ++++---- .../front-end-integration-guides/angular.mdx | 2 +- .../o1js-reference/interfaces/Permissions.mdx | 2 +- docs/zkapps/tutorials/01-hello-world.mdx | 2 +- .../interact-with-mina.mdx | 4 ++-- 8 files changed, 21 insertions(+), 21 deletions(-) diff --git a/docs/node-operators/data-and-history/querying-data.mdx b/docs/node-operators/data-and-history/querying-data.mdx index e19372613..05151608c 100644 --- a/docs/node-operators/data-and-history/querying-data.mdx +++ b/docs/node-operators/data-and-history/querying-data.mdx @@ -99,7 +99,7 @@ query StakingInfo { If the delegateAccount.publicKey is null, then this account is "staking directly" and this private key should be used for block production directly. -Note that the actual staking and delegating in the current "epoch" is drawn from the "staking ledger". We are currently implementing a mechanism for accessing this staking ledger directly, but for now you'll need to periodically query for this information and store it internally and then refer to it when it becomes active. On epoch transitions, a new staking ledger is selected by promoting the SNARKed ledger of the last block two epochs prior. In practice, this is between 2-4 weeks. +Note that the actual staking and delegating in the current "epoch" is drawn from the "staking ledger". We are currently implementing a mechanism for accessing this staking ledger directly, but for now you'll need to periodically query for this information and store it internally and then refer to it when it becomes active. On epoch transitions, a new staking ledger is selected by promoting the SNARKed ledger of the last block two epochs prior. In practice, this is between 1-2 weeks. ### Get Transaction Details diff --git a/docs/node-operators/delegation-program/foundation-delegation-program.mdx b/docs/node-operators/delegation-program/foundation-delegation-program.mdx index a96ae02a7..09911a704 100644 --- a/docs/node-operators/delegation-program/foundation-delegation-program.mdx +++ b/docs/node-operators/delegation-program/foundation-delegation-program.mdx @@ -142,7 +142,7 @@ You must return rewards to the address specified in the [Mina Delegation Program Rewards must be distributed at least once for a given epoch. You must send one payment in the amount of your obligation to the correct address specified in the [Mina Delegation Program Return Addresses](https://docs.google.com/spreadsheets/d/1Fm4XSS9Xu4eWAhpM06sdySUKvLClR5SculXfP5o5sSc/edit?usp=sharing) mapping document and if applicable, send the correct amount to the burn address. Both payments should have a memo field with the md5 hash value of your block producer public key. This is the easiest method to avoid confusion in tracking payments and will reduce the likelihood you will be incorrectly flagged as delinquent. -All the rewards for epoch N must be delivered (ie. accepted in a block, not just sent) no later than slot number 3,500 of the next epoch. This gives you about a week to sort out these payments. +All the rewards for epoch N must be delivered (ie. accepted in a block, not just sent) no later than slot number 3,500 of the next epoch. This gives you about half a week to sort out these payments. ### How do I calculate the reward payout? @@ -162,9 +162,9 @@ At the end of each epoch, do all of the following: 2. Compute the share of stake from the token provider (from both accounts) by dividing the token provider delegation by the total stake. (i.e. `provider_share = provider_delegation / total_stake`). The resulting share should be between 0 and 1. -3. For each block produced that has a non-zero block-reward on the canonical chain rewards must be calculated based on 720 MINA. +3. For each block produced that has a non-zero block-reward on the canonical chain rewards must be calculated based on 360 MINA. -4. Calculate the Mina Foundation payout by multiplying the coinbase reward (equal to `720 MINA` ) by the provider share calculated in the previous step minus an 8% percent fee. (i.e. `payout = (provider_share * 0.92) * 720)`. +4. Calculate the Mina Foundation payout by multiplying the coinbase reward (equal to `360 MINA` ) by the provider share calculated in the previous step minus an 8% percent fee. (i.e. `payout = (provider_share * 0.92) * 360)`. 5. Send a transaction to the token provider accounts with the appropriate payout and memo - please follow the rules in the "Payout Attribution" section with your transaction. More details in the following source code parts: [PayoutCalculatorIsolateSuperCharge.ts](https://github.com/jrwashburn/mina-pool-payout/blob/7f00dbd9e693f76ea6a950c29862120a170625a9/src/core/payoutCalculator/PayoutCalculatorIsolateSuperCharge.ts#L126) and [ConfigurationManager.ts](https://github.com/jrwashburn/mina-pool-payout/blob/7f00dbd9e693f76ea6a950c29862120a170625a9/src/configuration/ConfigurationManager.ts#L21C15-L21C15). @@ -191,11 +191,11 @@ Now let's consider Epoch 5. The share of the stake from the Foundation is `6 mil 3 blocks are produced in this epoch that end up on the canonical chain. The blocks were won by Account A. -1. Account A retains, 0.2 x 720 MINA x 3 blocks = 432 MINA. -2. Mina Foundation, Account B, payout would be: (0.6 x 0.92) x 720 MINA x 3 blocks = 1,192.32 MINA. -3. Account A retains 8%, (0.6 x 0.08) x 720 MINA x 3 blocks = 103.68 MINA. -3. Account C payout would be: (0.2 x 0.92) x 720 MINA x 3 blocks = 397.44 MINA. -4. Account A retains 8%, (0.2 x 0.08) x 720 MINA x 3 blocks = 34.56 MINA +1. Account A retains, 0.2 x 360 MINA x 3 blocks = 216 MINA. +2. Mina Foundation, Account B, payout would be: (0.6 x 0.92) x 360 MINA x 3 blocks = 596.16 MINA. +3. Account A retains 8%, (0.6 x 0.08) x 360 MINA x 3 blocks = 51.84 MINA. +3. Account C payout would be: (0.2 x 0.92) x 360 MINA x 3 blocks = 198.72 MINA. +4. Account A retains 8%, (0.2 x 0.08) x 360 MINA x 3 blocks = 17.28 MINA ### Relevant Links diff --git a/docs/node-operators/staking-and-snarking.mdx b/docs/node-operators/staking-and-snarking.mdx index 14ab68a86..d416ed404 100644 --- a/docs/node-operators/staking-and-snarking.mdx +++ b/docs/node-operators/staking-and-snarking.mdx @@ -29,7 +29,7 @@ Mina is a public and decentralized blockchain that is open for anyone in the wor You can earn block rewards by participating in block production through staking. -- Your new stake delegation comes into effect after a latency period of a 2-4 weeks. +- Your new stake delegation comes into effect after a latency period of 1-2 weeks. - You can undelegate at any time with no penalty. Submit a delegation transaction with the new staking service or back to yourself if you want to be a block producer. Updates are made after a delay of 1-2 epochs. ### Requirements @@ -97,8 +97,8 @@ Consensus configuration: Delta: 0 k: 290 Slots per epoch: 7140 - Slot duration: 3m - Epoch duration: 14d21h + Slot duration: 1m30s + Epoch duration: 7d10h30m Chain start timestamp: 2023-10-17 16:01:01.000000Z Acceptable network delay: 3m diff --git a/docs/using-mina/how-to-delegate.mdx b/docs/using-mina/how-to-delegate.mdx index 103bc9f52..ebe6b55f6 100644 --- a/docs/using-mina/how-to-delegate.mdx +++ b/docs/using-mina/how-to-delegate.mdx @@ -48,14 +48,14 @@ When you delegate MINA to a validator: 1. Your tokens **never leave your wallet** - you maintain full control 2. The validator uses your stake weight to increase their chances of producing blocks -3. When the validator wins a block (720 MINA reward), they distribute rewards proportionally to all delegators +3. When the validator wins a block (360 MINA reward), they distribute rewards proportionally to all delegators 4. The validator takes a commission fee and you receive your share of the remaining rewards -5. It takes **2-4 weeks** for your delegation to become active on the network +5. It takes **1-2 weeks** for your delegation to become active on the network 6. You can change validators anytime with no penalties :::note -Values like staking rewards, epoch duration, and APY are subject to change with network upgrades. After the upcoming Mesa upgrade, block rewards will decrease from 720 to 360 MINA per block, and epoch duration will reduce from 2-4 weeks to 1-2 weeks. +Values like staking rewards, epoch duration, and APY are subject to change with network upgrades. For example, after the latest Mesa upgrade, block rewards decreased from 720 to 360 MINA per block, and epoch duration was reduced from 2-4 weeks to 1-2 weeks. ::: @@ -125,7 +125,7 @@ When selecting a validator to delegate to, consider these factors: ### Choosing a Validator -Your delegation will become active after **2-4 weeks** (1-2 epochs). Here are some extra things to note: +Your delegation will become active after **1-2 weeks** (1-2 epochs). Here are some extra things to note: - **Checking Your Status:** Most wallets show your current delegation status, including: - Which validator you're delegated to diff --git a/docs/zkapps/front-end-integration-guides/angular.mdx b/docs/zkapps/front-end-integration-guides/angular.mdx index 51d3a0a65..7ff08d454 100644 --- a/docs/zkapps/front-end-integration-guides/angular.mdx +++ b/docs/zkapps/front-end-integration-guides/angular.mdx @@ -28,7 +28,7 @@ keywords:
- Fund your wallet using the [Mina Faucet](https://faucet.minaprotocol.com/). - - You'll need to wait one block (~3 minutes) to see the change in balance reflected on chain. You can use [Minascan](https://minascan.io/devnet) to track the status of your transaction. + - You'll need to wait one block (~90 seconds) to see the change in balance reflected on chain. You can use [Minascan](https://minascan.io/devnet) to track the status of your transaction.
diff --git a/docs/zkapps/o1js-reference/interfaces/Permissions.mdx b/docs/zkapps/o1js-reference/interfaces/Permissions.mdx index 61a9523fb..5c87bd00b 100644 --- a/docs/zkapps/o1js-reference/interfaces/Permissions.mdx +++ b/docs/zkapps/o1js-reference/interfaces/Permissions.mdx @@ -54,7 +54,7 @@ The Permission corresponding to the ability to emit actions to the account. editState: AuthRequired; ``` -The Permission corresponding to the 8 state fields associated with +The Permission corresponding to the 32 state fields associated with an account. #### Overrides diff --git a/docs/zkapps/tutorials/01-hello-world.mdx b/docs/zkapps/tutorials/01-hello-world.mdx index 3583f6742..f867af0d9 100644 --- a/docs/zkapps/tutorials/01-hello-world.mdx +++ b/docs/zkapps/tutorials/01-hello-world.mdx @@ -217,7 +217,7 @@ The smart contract called `Square` has one element of on-chain state named `num` 12 } ``` -zkApps can have up to eight fields of on-chain state. Each field stores up to 32 bytes (technically, 31.875 bytes or 255 bits) of arbitrary data. A later tutorial covers options for off-chain state. +zkApps can have up to 32 fields of on-chain state. Each field stores up to 32 bytes (technically, 31.875 bytes or 255 bits) of arbitrary data. A later tutorial covers options for off-chain state. Now, this code adds the `init` method to set up the initial state of the smart contract on deployment: diff --git a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina.mdx b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina.mdx index 56a836093..18a5031a9 100644 --- a/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina.mdx +++ b/docs/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina.mdx @@ -114,8 +114,8 @@ The second account update has the `'MyContract.myMethod()'` label. The update co Other fields in this account update are: - `publicKey` – the zkApp address (like other non-human-readable strings, this is truncated by `tx.toPretty()`) -- `update: { appState: [...] }` – shows how the method updates the on-chain state, using `this..set()`. The names and pretty types defined using `@state` are removed in this representation, showing a raw list of 8 field elements or `null` for state fields that aren't updated. -- `preconditions: { account: { state: [...] } }` – similar to the `update`, one entry per field of on-chain state for the preconditions created with `this..requireEquals()`. This example accepts transactions only if the first of the 8 state fields equals 0. The `null` values mean that no condition is set on the other 7 state fields. +- `update: { appState: [...] }` – shows how the method updates the on-chain state, using `this..set()`. The names and pretty types defined using `@state` are removed in this representation, showing a raw list of 32 field elements or `null` for state fields that aren't updated. +- `preconditions: { account: { state: [...] } }` – similar to the `update`, one entry per field of on-chain state for the preconditions created with `this..requireEquals()`. This example accepts transactions only if the first of the 32 state fields equals 0. The `null` values mean that no condition is set on the other 31 state fields. - `authorizationKind: 'Proof'` – indicates this account update must be authorized with a proof. Proof authorization is the default when calling a zkApp method, but not necessarily for other account updates. - `authorization: undefined` – the proof needed on this update isn't there yet. You learn how to add it in a minute. From 342a59e75c9bce9f5831fe4cf135eb70e7c58b7a Mon Sep 17 00:00:00 2001 From: Shigoto-dev19 Date: Wed, 4 Feb 2026 23:53:34 +0300 Subject: [PATCH 4/6] Update remaining "eight" on-chain state references to 32 for MIP-7 --- docs/zkapps/o1js/merkle-tree.mdx | 2 +- docs/zkapps/tutorials/anonymous-message-board.mdx | 2 +- docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx | 2 +- docs/zkapps/zkapp-development-frameworks.mdx | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/zkapps/o1js/merkle-tree.mdx b/docs/zkapps/o1js/merkle-tree.mdx index 215808389..76b2c28d9 100644 --- a/docs/zkapps/o1js/merkle-tree.mdx +++ b/docs/zkapps/o1js/merkle-tree.mdx @@ -41,7 +41,7 @@ you now have access to more data off-chain. Imagine a zkApp that manages a game with a leaderboard. The zkApp has a method to update a player's score if the player guesses a number correctly. After a player reaches a threshold score, the player can invoke another method to get a reward. Because you want many players to participate in the game, -you are drastically limited by how much data can be stored on-chain. You will quickly run out of on-chain space with eight or more participants. +you are drastically limited by how much data can be stored on-chain. You will quickly run out of on-chain space with 32 or more participants. A possible solution to that problem is to use the power of Merkle trees, store the public keys of each player and their corresponding scores off-chain, and reference the keys in the smart contract. diff --git a/docs/zkapps/tutorials/anonymous-message-board.mdx b/docs/zkapps/tutorials/anonymous-message-board.mdx index c074df09f..b53a34d76 100644 --- a/docs/zkapps/tutorials/anonymous-message-board.mdx +++ b/docs/zkapps/tutorials/anonymous-message-board.mdx @@ -168,7 +168,7 @@ This code serves as the scaffolding for the rest of the tutorial and contains a ### Define on-chain state -Every Mina smart contract includes eight on-chain state variables that each store almost 256 bits of information. In more complex smart contracts, these state variables can store commitments to off-chain storage (for example, commitments for the hash of a file, the root of a Merkle tree, and so on). +Every Mina smart contract includes 32 on-chain state variables that each store almost 256 bits of information. In more complex smart contracts, these state variables can store commitments to off-chain storage (for example, commitments for the hash of a file, the root of a Merkle tree, and so on). For simplicity, this tutorial stores everything on-chain. diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx index 8f20abfd5..520a268e6 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/permissions.mdx @@ -30,7 +30,7 @@ Permissions live on-chain, which means they are a part of the account representa There are 13 different types of permissions that you can access and adjust to guard a zkApp account: -- `editState`: The permission describing how the zkApp account's eight on-chain state fields are allowed to be manipulated. +- `editState`: The permission describing how the zkApp account's 32 on-chain state fields are allowed to be manipulated. - `send`: The permission corresponding to the ability to send transactions from this account. For example, this permission determines whether someone can send a transaction to transfer MINA from this particular account. diff --git a/docs/zkapps/zkapp-development-frameworks.mdx b/docs/zkapps/zkapp-development-frameworks.mdx index 86cfa86c2..35b4cd013 100644 --- a/docs/zkapps/zkapp-development-frameworks.mdx +++ b/docs/zkapps/zkapp-development-frameworks.mdx @@ -42,7 +42,7 @@ There are some key considerations when choosing to build a zkApp with o1js on Mi - zkApps are subject to protocol throughput limitations. - At present, zkApps that require support for multiple concurrent users require specific architecture to avoid race conditions: - - Where more than the eight on-chain field elements are required to manage state, and access to that state is not shared between users, the experimental [Offchain Storage API](/zkapps/writing-a-zkapp/feature-overview/offchain-storage) offers a solution. + - Where more than the 32 on-chain field elements are required to manage state, and access to that state is not shared between users, the experimental [Offchain Storage API](/zkapps/writing-a-zkapp/feature-overview/offchain-storage) offers a solution. - Where concurrent access to _shared global state_ is required, the required architecture is available **out of the box** when using the Protokit framework to build your zkApp as an zkApp-chain (L2). There is currently no easy-to-use equivalent for shared state in o1js L1 contracts. Start here: From d87649bc4576a6cf1311104a6ddc345723ea0d59 Mon Sep 17 00:00:00 2001 From: Shigoto-dev19 Date: Thu, 5 Feb 2026 00:17:03 +0300 Subject: [PATCH 5/6] Fix MIP-9 account update limits and remaining MIP-6/MIP-7 references --- docs/mesa-upgrade/mesa-upgrade-overview.mdx | 6 +++--- docs/node-operators/staking-service-guidelines.mdx | 2 +- .../writing-a-zkapp/feature-overview/offchain-storage.mdx | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/mesa-upgrade/mesa-upgrade-overview.mdx b/docs/mesa-upgrade/mesa-upgrade-overview.mdx index 10947fca4..cc4d92f57 100644 --- a/docs/mesa-upgrade/mesa-upgrade-overview.mdx +++ b/docs/mesa-upgrade/mesa-upgrade-overview.mdx @@ -115,9 +115,9 @@ Mesa replaces the cost-based model with a simpler **segment-count model**. Each This means: -- **Up to 16 proof-based account updates** per transaction (previously ~6) -- **Up to 16 signed-single account updates** per transaction -- **Up to 32 signature-based account updates** if all are paired (16 pairs) +- **Up to 15 proof-based account updates** per transaction (previously ~5) +- **Up to 16 signed-single account updates** per transaction (including fee payer) +- **Up to 32 signature-based account updates** if all are paired (16 pairs, one including the fee payer) - Any combination where `proof_segments + signed_single_segments + signed_pair_segments <= 16` This enables fitting more account updates into one transaction, whether by multiple calls or interactions with zkApps, or more logic in your zkApp including cross-calls with other zkApps within one zkApp method. diff --git a/docs/node-operators/staking-service-guidelines.mdx b/docs/node-operators/staking-service-guidelines.mdx index c18679e73..b292a967f 100644 --- a/docs/node-operators/staking-service-guidelines.mdx +++ b/docs/node-operators/staking-service-guidelines.mdx @@ -11,7 +11,7 @@ This document aims to explain the different components that you should think abo ## Staking Rewards -The coinbase reward for producing a block is 720 tokens. +The coinbase reward for producing a block is 360 MINA. ## Dumping Staking Ledgers diff --git a/docs/zkapps/writing-a-zkapp/feature-overview/offchain-storage.mdx b/docs/zkapps/writing-a-zkapp/feature-overview/offchain-storage.mdx index c9dc85458..6a9d04cc0 100644 --- a/docs/zkapps/writing-a-zkapp/feature-overview/offchain-storage.mdx +++ b/docs/zkapps/writing-a-zkapp/feature-overview/offchain-storage.mdx @@ -29,7 +29,7 @@ Offchain storage is currently an experimental feature and is subject to change i One of Mina's unique features is its succinctness, both in computation and storage. To prevent state bloat and maintain Mina's efficiency and verifiability, we use offchain storage solutions for handling large volumes of data. -In a previous section, we introduced the concept of on-chain Values. Since Mina currently only supports a total of 8 on-chain Field elements, we need to leverage offchain storage to extend that capacity. +In a previous section, we introduced the concept of on-chain Values. Since Mina currently only supports a total of 32 on-chain Field elements, we need to leverage offchain storage to extend that capacity. This approach maintains a provably secure connection between the on-chain smart contract and the off-chain data, such as that stored in an archive node. ## Design From 6ab475b8fbd2ee6545011885b7b75c8c801df402 Mon Sep 17 00:00:00 2001 From: Shigoto-dev19 Date: Thu, 5 Feb 2026 15:23:43 +0300 Subject: [PATCH 6/6] Trigger Vercel rebuild