Update docs to reflect all MESA and o1js 3.0 changes

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)

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
 
@@ -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
 
@@ -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
 
@@ -601,7 +601,7 @@ A command line tool that zkApp developers use to scaffold and deploy smart contr
 
 ### zkApp account
 
-A zkApp account is an account on the Mina blockchain where a zkApp smart contract is deployed. 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 zkApp account is an account on the Mina blockchain where a zkApp smart contract is deployed. 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
 

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
 

docs/mesa-upgrade/mesa-upgrade-overview.mdx

@@ -0,0 +1,133 @@
+---
+title: Mesa Upgrade Overview
+sidebar_label: Overview
+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
+  - 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-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).
+
+### 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 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.
+
+:::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).

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%.
 

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"

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.

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
 

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 <u>all</u> 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

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
 

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
 
@@ -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 (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.