STAGE 1: Berkeley Test Network

(Day 1)

Goals:

• Successfully deploy and confirm correct functionality of a Berkeley-era zkApp before the hardfork, ensuring a clean reference point.

Runbook:

1. Bring a Representative zkApp:
   1. Deploy one real or minimal “production-like” zkApp that you own and have the ability to redeploy/upgrade.
   2. Ensure you control the fee payer private key and the zkApp account key(s) required for signing any upgrade transaction.
2. Deploy your zkApp (pre-MESA):
   1. Deploy the zkApp to the designated network before the hardfork height/time (details of the exact window will be provided).
   2. Save the following artifacts:
      1. zkApp public key
      2. Git commit used for deployment
      3. Build output and verification key (including hash)
      4. Transaction hash of the deployment transaction
3. Confirm zkApp functionality pre-hardfork:
   1. Submit at least one successful interaction (method call) before the hardfork.
   2. Record the following information:
      1. Transaction hash of the successful method call
      2. Expected state change (before and after, if any)
      3. Observed on-chain behaviour (screenshot, explorer link, etc.)

STAGE 2: Upgrade Mechanism Testing (UMT) testing

(Days 2 – end of Stage 2)

Goals:

• Confirm that the pre-hardfork zkApp fails as expected after the network forks to Mesa.

Runbook:

1. Wait for the Hardfork:
   1. Monitor the network until the hardfork to Mesa is complete. You will be able to find live updates in the #mesa-upgrade-testnet in Discord.
2. Attempt to Use the zkApp After the Fork (expected failure):
   1. After the network has forked to Mesa, attempt the exact same method interaction from Step 3 again.
   2. Expected outcome: The interaction should fail because the verification key is still Berkeley-compatible, not Mesa-compatible.
   3. Record the following information:
      1. Transaction hash of the (failed) method call (if broadcasted, otherwise screenshot of error messages)
      2. The error message observed

STAGE 3: Mesa Network Testing 

(Days 11 – end of Stage 3)

Goals:

• Validate the upgrade process and functionality. Successfully upgrade the zkApp using o1js 3.0 and confirm all functionality is restored post-upgrade.

Runbook:

1. Upgrade the zkApp (verification key update) using o1js 3.0:
   1. Upgrade your contract by compiling your existing code with o1js 3.0. (no code changes are expected). This produces a new Mesa-compatible verification key.
   2. Submit the verification key update transaction to the network for your zkApp account.
   3. Record the following information:
      1. Transaction hash of the upgrade transaction
      2. New verification key (including hash)
      3. If an error is encountered, share that instead.
2. Verify post-upgrade functionality:
   1. Re-run the exact same method interaction as in Step 3 and 5.
   2. Expected outcome: The interaction should now succeed, and the contract should behave as it did pre-hardfork.
   3. Record the following information:
      1. Transaction hash of the successful method call
      2. Observed state change (before and after, if any)

Phase 4: Reporting

1. Report results:
   1. Compile and share a comprehensive report of your findings using the provided template.

zkApp Name

The name of your application.

Description

A simplified description of the zkApp and its expected behavior.

zkApp Address

The public key of the zkApp account.

Github repository & commit

Link to the repository and the specific commit used for the initial deployment.

Pre-Hardfork Deploy TX Hash

Transaction hash of the initial zkApp deployment.

Pre-Hardfork Interaction TX Hash (Success)

Transaction hash of the successful method call before the hardfork.

Post-Hardfork Interaction TX Hash (Expected Failure)

Transaction hash of the failed method call after the hardfork.

Error Messages Observed

The error message returned during the expected failure.

Verification Key Upgrade TX Hash

Transaction hash of the successful verification key update.

Post-Upgrade Interaction TX Hash (Expected to Succeed)

Transaction hash of the successful method call after the upgrade.

Notes

Any additional notes, unexpected behavior, or unrelated observations.