feat(sol): vk hashing #16015

Maddiaa0 · 2025-07-26T19:37:54Z

Overview

Perform vk hashing in the solidity verifier

Takes a different approach to the traditional verifiers.
As the vk is fixed ahead of time, we hash it and include it in the precompiled contract, therefore it is preprocessed
and does not need to be recomputed by the verifier.

Maddiaa0 · 2025-07-26T19:38:11Z

feat(sol): apply vk hashing to optimized contract #16020
feat(sol): vk hashing #16015 👈 (View in Graphite)
next

This stack of pull requests is managed by Graphite. Learn more about stacking.

Maddiaa0 · 2025-07-26T19:39:37Z

barretenberg/cpp/src/barretenberg/flavor/ultra_keccak_flavor.hpp

-            transcript.add_to_hash_buffer(domain_separator + "vk_pub_inputs_offset", this->pub_inputs_offset);
-            return 0;
+            // This hash contains a hash of the entire vk - including all of the elements
+            const fr hash = this->hash();


this->hash includes the hashes that i removed here + the hashing of the precomputed commitments

lucasxia01 · 2025-07-29T01:18:34Z

barretenberg/cpp/src/barretenberg/dsl/acir_proofs/honk_contract.hpp


    struct VerificationKey {
+        // Hash of all of the field elements in the verification key
+        uint256 vkHash;


not a fan of putting vk hash in here

also why is it a uint256 and not Fr?

would you perfer it as a constant at the top of the file?

uint256 as it doesnt need to be reduced its just a constant

lucasxia01 · 2025-07-29T01:30:09Z

barretenberg/sol/src/honk/keys/RecursiveHonkVerificationKey.sol

            t3: Honk.G1Point({
-                x: uint256(0x15642d62fc17d119ba4afb77ab424e0a771b5bbb501c75790a1a4e2906931045),
-                y: uint256(0x21cea98314ec6efc5f8f1f648f42a7a5c1396036397af54a729801cc1c37d4e2)
+                x: uint256(0x1800723660742a70c0cc9a984e30274444a587c93d9f4742a9b96cd3572365e1),


why is it always t3 changing

this will no longer be checked in to version control, but not sure tbh

yeah suspicious because no circuit is being changed

theyre gone now

lucasxia01 · 2025-07-29T01:34:49Z

barretenberg/cpp/src/barretenberg/ultra_honk/ultra_transcript.test.cpp

-            manifest_expected.add_entry(round, "vk_log_circuit_size", frs_per_uint32);
-            manifest_expected.add_entry(round, "vk_num_public_inputs", frs_per_uint32);
-            manifest_expected.add_entry(round, "vk_pub_inputs_offset", frs_per_uint32);
+            manifest_expected.add_entry(round, "vk_hash", 1);


ideally not magic 1

ah, i see frs_per_fr is just one, ill update to that

barretenberg/cpp/src/barretenberg/ultra_honk/ultra_transcript.test.cpp

lucasxia01 · 2025-07-29T05:22:23Z

barretenberg/cpp/src/barretenberg/flavor/flavor.hpp

+    fr hash() const
    {
-        fr vk_hash = crypto::Poseidon2<crypto::Poseidon2Bn254ScalarFieldParams>::hash(this->to_field_elements());
+        fr vk_hash = Transcript::hash(this->to_field_elements());


its a little backwards that the vk hash is dependent on the transcript hm

would prefer just overriding this in the keccak class for now

why do you think so? the hash function used is defined in the transcript, so i think it makes sense

unless we pull the hash function to be defined in the flavor, then template it into the transcript + others?

because the hash of the vk or whatever object isn't fundamentally dependent on the hash we're using for Fiat-Shamir

i get you, ill leave it as keccak

Discussion with lucas: correct function is to define hash function in flavor - but is fine as it is - ISSUE

AztecProtocol/barretenberg#1498

lucasxia01 · 2025-07-29T22:45:37Z

barretenberg/sol/src/honk/BaseZKHonkVerifier.sol


    uint256 immutable $N;
    uint256 immutable $LOG_N;
+    uint256 immutable $VK_HASH;


why didn't we make the rest of the vk a constant as well? just confused about the inconsistency

it could be done, but as constants can only be value types so we wouldnt be able to store it in a struct, which makes it easier to read for this reference implementation

i suppose it makes alot of sense in the optimized version to move to writing a constant each time, rather than using memory for it.

lucasxia01

Thanks for doing this

@benesjan

commit eb94d3a Merge: f847091 3b76348 Author: AztecBot <tech@aztecprotocol.com> Date: Mon Aug 4 05:45:06 2025 +0000 Merge branch 'next' into merge-train/barretenberg commit 3b76348 Author: Lasse Herskind <16536249+LHerskind@users.noreply.github.com> Date: Mon Aug 4 06:03:02 2025 +0100 chore: address comments (#16175) Please read [contributing guidelines](CONTRIBUTING.md) and remove this line. For audit-related pull requests, please use the [audit PR template](?expand=1&template=audit.md). commit f847091 Merge: a86bcc3 b0affa7 Author: AztecBot <tech@aztecprotocol.com> Date: Sun Aug 3 22:08:04 2025 +0000 Merge branch 'next' into merge-train/barretenberg commit b0affa7 Author: Lasse Herskind <16536249+LHerskind@users.noreply.github.com> Date: Sun Aug 3 22:26:43 2025 +0100 chore: updated fmt settings foundry.toml (#16155) Updated the `foundry.toml` to also wrap the comments and use the default line_length of 120 instead of the previous 100. Threw some thousands separators in there as well for constant values. ```toml [fmt] line_length = 120 tab_width = 2 variable_override_spacing=false wrap_comments = true number_underscore = "thousands" override_spacing = false ``` commit a86bcc3 Merge: c7a5799 3ded0f6 Author: AztecBot <tech@aztecprotocol.com> Date: Sun Aug 3 20:41:47 2025 +0000 Merge branch 'next' into merge-train/barretenberg commit c7a5799 Merge: fd73d0e 935a8fa Author: AztecBot <tech@aztecprotocol.com> Date: Sun Aug 3 20:11:19 2025 +0000 Merge branch 'next' into merge-train/barretenberg commit 3ded0f6 Author: Jan Beneš <janbenes1234@gmail.com> Date: Sun Aug 3 21:56:09 2025 +0200 chore: minor fixes and docs improvements in governance (#16039) When doing my internal review of governance contracts I stumbled upon plenty of small and uncontroversial issues with which it didn't really make sense to clutter my review document. --------- Co-authored-by: LHerskind <16536249+LHerskind@users.noreply.github.com> commit fd73d0e Merge: e2b45d5 99e70e6 Author: AztecBot <tech@aztecprotocol.com> Date: Sun Aug 3 19:29:46 2025 +0000 Merge branch 'next' into merge-train/barretenberg commit 935a8fa Author: Maddiaa <47148561+Maddiaa0@users.noreply.github.com> Date: Sun Aug 3 20:16:22 2025 +0100 feat(sol): vk hashing (#16015) Perform vk hashing in the solidity verifier Takes a different approach to the traditional verifiers. As the vk is fixed ahead of time, we hash it and include it in the precompiled contract, therefore it is preprocessed and does not need to be recomputed by the verifier. commit 99e70e6 Author: Lasse Herskind <16536249+LHerskind@users.noreply.github.com> Date: Sun Aug 3 19:46:27 2025 +0100 chore!: depositAmount and minimumStake naming (#16148) Addressing feedback from @benesjan. Also using his prompt idea to see how well it works. --- This PR refactors validator staking terminology throughout the Aztec codebase to improve clarity and better reflect the purpose of key staking parameters. The main changes involve renaming `depositAmount` to `activationThreshold` and `minimumStake` to `ejectionThreshold`, along with related library and method renames. - **`depositAmount` → `activationThreshold`**: The amount of tokens required to activate a validator and join the validator set - **`minimumStake` → `ejectionThreshold`**: The minimum token balance below which a validator is ejected from the active set - **Solidity Contracts**: Updated all references in `Rollup.sol`, `IStaking.sol`, `GSE.sol`, and related contracts - **Libraries**: - `UserLib` → `CheckpointedUintLib` (more descriptive name for checkpoint management) - `DelegationLib` → `StakeDelegationLib` (clearer purpose indication) - **Methods**: `finaliseHelper()` → `finaliseWithdraw()` in GSE contract for better clarity - Updated environment variables: - `AZTEC_DEPOSIT_AMOUNT` → `AZTEC_ACTIVATION_THRESHOLD` - `AZTEC_MINIMUM_STAKE` → `AZTEC_EJECTION_THRESHOLD` - Updated all configuration files, test constants, and deployment scripts - Updated CLI reference documentation to reflect new parameter names - Updated all code comments to use the new terminology 1. **Improved Clarity**: The new names clearly indicate the purpose of each parameter - one for entering the validator set, one for being removed from it 2. **Better Developer Experience**: Developers can immediately understand what these thresholds represent without needing additional context 3. **Consistency**: Uniform terminology across the entire codebase reduces confusion 4. **Future-Proof**: The new names are more generic and adaptable to potential future staking mechanism changes ⚠️ **This is a breaking change** that affects: 1. **Environment Variables**: Any deployment or configuration using the old environment variable names (`AZTEC_DEPOSIT_AMOUNT`, `AZTEC_MINIMUM_STAKE`) must be updated 2. **Contract Interfaces**: External systems calling `getDepositAmount()`, `getMinimumStake()`, or `finaliseHelper()` must update to use the new method names 3. **Configuration Files**: Any JSON/YAML configuration files using the old parameter names need updates 4. **Deployment Scripts**: Custom deployment scripts referencing the old names will need modification - Replace `depositAmount` with `activationThreshold` in all configurations - Replace `minimumStake` with `ejectionThreshold` in all configurations - Update contract calls: - `getDepositAmount()` → `getActivationThreshold()` - `getMinimumStake()` → `getEjectionThreshold()` - `finaliseHelper()` → `finaliseWithdraw()` commit e2b45d5 Author: AztecBot <tech@aztecprotocol.com> Date: Fri Aug 1 20:40:41 2025 +0000 [empty] Start merge-train. Choo choo. commit 5d75421 Author: Aztec Bot <49558828+AztecBot@users.noreply.github.com> Date: Fri Aug 1 21:02:38 2025 +0100 feat: merge-train/barretenberg (#16170) See [merge-train-readme.md](https://github.com/AztecProtocol/aztec-packages/blob/next/.github/workflows/merge-train-readme.md). BEGIN_COMMIT_OVERRIDE chore: civc tests refactor (#16159) END_COMMIT_OVERRIDE --------- Co-authored-by: AztecBot <tech@aztecprotocol.com> Co-authored-by: maramihali <mara@aztec-labs.com> commit 9ab0377 Author: Maddiaa <47148561+Maddiaa0@users.noreply.github.com> Date: Fri Aug 1 16:19:44 2025 +0100 chore(sol): remove unused param in relations.sol (#16166) Fixes a compiler warning commit 0ab7472 Author: Aztec Bot <49558828+AztecBot@users.noreply.github.com> Date: Fri Aug 1 16:02:34 2025 +0100 feat: merge-train/barretenberg (#16153) See [merge-train-readme.md](https://github.com/AztecProtocol/aztec-packages/blob/next/.github/workflows/merge-train-readme.md). BEGIN_COMMIT_OVERRIDE chore: add a `PG_TAIL` proof type and queue type (#16156) END_COMMIT_OVERRIDE --------- Co-authored-by: AztecBot <tech@aztecprotocol.com> Co-authored-by: Khashayar Barooti <khashayar@aztecprotocol.com> Co-authored-by: Suyash Bagad <suyash@aztecprotocol.com> Co-authored-by: federicobarbacovi <171914500+federicobarbacovi@users.noreply.github.com> Co-authored-by: maramihali <mara@aztecprotocol.com> Co-authored-by: Jonathan Hao <jonathan@aztec-labs.com> commit eccd655 Author: ludamad <adam.domurad@gmail.com> Date: Fri Aug 1 10:18:11 2025 -0400 chore(release): aztec-nr releases like l1-contracts (#16123) Just overwrite the git contents and tag it / push to branch. Doesn't attempt to keep history commit 82bb4d8 Author: Santiago Palladino <santiago@aztecprotocol.com> Date: Fri Aug 1 11:17:11 2025 -0300 feat: Validators invalidate invalid blocks (#16120) We expect proposers to invalidate the previous block if it is invalid, but if they fail to do so, validators will eventually do it, prioritizing the committee members and then any validator whatsoever. This commit includes other fixes: - If a proposer cannot build a block due to not enough txs, it still tries to invalidate the previous one. - The archiver keeps track of the earliest (not latest) invalid block it has seen, so the sequencer can use this info to invalidate the earliest one. Builds on top of #16067 commit b18c823 Author: josh crites <critesjosh@gmail.com> Date: Fri Aug 1 09:49:18 2025 -0400 chore(docs): Update testnet info (#16163) Updates the testnet contract and version info in docs/docs, to be backported to master so that this info is correct when new releases are cut. Also sets the default testnet version to be published to be 1.2.0 commit e8bfa98 Author: Álvaro Rodríguez <sirasistant@gmail.com> Date: Fri Aug 1 14:14:17 2025 +0200 feat(avm)!: Tree opcodes fail in static context (#16158) Small PR to make emit notehash, emit nullifier and sstore fail on static contexts

@benesjan

Addressing feedback from @benesjan. Also using his prompt idea to see how well it works. --- This PR refactors validator staking terminology throughout the Aztec codebase to improve clarity and better reflect the purpose of key staking parameters. The main changes involve renaming `depositAmount` to `activationThreshold` and `minimumStake` to `ejectionThreshold`, along with related library and method renames. - **`depositAmount` → `activationThreshold`**: The amount of tokens required to activate a validator and join the validator set - **`minimumStake` → `ejectionThreshold`**: The minimum token balance below which a validator is ejected from the active set - **Solidity Contracts**: Updated all references in `Rollup.sol`, `IStaking.sol`, `GSE.sol`, and related contracts - **Libraries**: - `UserLib` → `CheckpointedUintLib` (more descriptive name for checkpoint management) - `DelegationLib` → `StakeDelegationLib` (clearer purpose indication) - **Methods**: `finaliseHelper()` → `finaliseWithdraw()` in GSE contract for better clarity - Updated environment variables: - `AZTEC_DEPOSIT_AMOUNT` → `AZTEC_ACTIVATION_THRESHOLD` - `AZTEC_MINIMUM_STAKE` → `AZTEC_EJECTION_THRESHOLD` - Updated all configuration files, test constants, and deployment scripts - Updated CLI reference documentation to reflect new parameter names - Updated all code comments to use the new terminology 1. **Improved Clarity**: The new names clearly indicate the purpose of each parameter - one for entering the validator set, one for being removed from it 2. **Better Developer Experience**: Developers can immediately understand what these thresholds represent without needing additional context 3. **Consistency**: Uniform terminology across the entire codebase reduces confusion 4. **Future-Proof**: The new names are more generic and adaptable to potential future staking mechanism changes ⚠️ **This is a breaking change** that affects: 1. **Environment Variables**: Any deployment or configuration using the old environment variable names (`AZTEC_DEPOSIT_AMOUNT`, `AZTEC_MINIMUM_STAKE`) must be updated 2. **Contract Interfaces**: External systems calling `getDepositAmount()`, `getMinimumStake()`, or `finaliseHelper()` must update to use the new method names 3. **Configuration Files**: Any JSON/YAML configuration files using the old parameter names need updates 4. **Deployment Scripts**: Custom deployment scripts referencing the old names will need modification - Replace `depositAmount` with `activationThreshold` in all configurations - Replace `minimumStake` with `ejectionThreshold` in all configurations - Update contract calls: - `getDepositAmount()` → `getActivationThreshold()` - `getMinimumStake()` → `getEjectionThreshold()` - `finaliseHelper()` → `finaliseWithdraw()` feat(sol): vk hashing (#16015) Perform vk hashing in the solidity verifier Takes a different approach to the traditional verifiers. As the vk is fixed ahead of time, we hash it and include it in the precompiled contract, therefore it is preprocessed and does not need to be recomputed by the verifier. chore: minor fixes and docs improvements in governance (#16039) When doing my internal review of governance contracts I stumbled upon plenty of small and uncontroversial issues with which it didn't really make sense to clutter my review document. --------- Co-authored-by: LHerskind <16536249+LHerskind@users.noreply.github.com> chore: updated fmt settings foundry.toml (#16155) Updated the `foundry.toml` to also wrap the comments and use the default line_length of 120 instead of the previous 100. Threw some thousands separators in there as well for constant values. ```toml [fmt] line_length = 120 tab_width = 2 variable_override_spacing=false wrap_comments = true number_underscore = "thousands" override_spacing = false ``` chore: address comments (#16175) Please read [contributing guidelines](CONTRIBUTING.md) and remove this line. For audit-related pull requests, please use the [audit PR template](?expand=1&template=audit.md). chore: invert check (#16181) Looks like this condition should have been inverted. [Nightly CI logs](https://github.com/AztecProtocol/aztec-packages/actions/runs/16712826743/job/47300588722) ``` 03:18:35 + case "$cmd" in 03:18:35 + release 03:18:35 + semver check v1.0.0-nightly.20250804 03:18:35 + echo_stderr 'Release tag must be a valid semver version. Found: v1.0.0-nightly.20250804' 03:18:35 + echo Release tag must be a valid semver version. Found: v1.0.0-nightly.20250804 03:18:35 Release tag must be a valid semver version. Found: v1.0.0-nightly.20250804 03:18:35 + exit 1 ``` chore: remove `uint` (#16062) Removed `uint` module from `stdlib`. Had to change two modules that used `uint`: 1. `edcsa`: an ecdsa signature contains a byte `v` and we were using `uint8` to represent it in circuits. Replaced that with `byte_array` (of size 1). 2. `keccak`: variable length keccak (i.e., the number of bytes being hashed is a circuit-variable) was using `uint32` to represent `num_bytes`. We are not using this version of keccak anywhere so its better to get rid of than to maintain/audit. feat(bb): allow for different transcript types depending on the flavor (#16017) This change changes the transcript type in the solidity verifier case to be a uint256 instead of serialising as field elements It should reduce the size of the proof by 2368 bytes. This significantly reduces hashing costs + calldata costs, and should amount to a gas savings in the region of 50k This pr just performs the plumbing into bb that makes these changes, and does not apply the changes - changing the TranscriptType to uint256_t and does not make the changes to solidity. Expect this in a follow on **Note: still needs a cleanup but leaving this here for review from others on the approach** chore: remove `decompose_into_bits()` function from `field_t` class (#15795) Since we're removing the merkle membership circuit implementation from cpp code, we no longer use the function `decompose_into_bits()` in the `field_t` class. Best to remove it instead of maintaining. chore: Standardise native public input handling (#16050) Public inputs in `stdlib` are handled via the special public input mechanisms: we have classes (`KernelIO`, `DefaultIO`, `HidingKernelIO`, `RollupIO`) that set public inputs, reconstruct them, create defaults, etc. Native public inputs have a similar mechanism, but the mechanism has many hacks built-in as native structures are used in more extensively than their `stdlib` counterparts (e.g., we use `field` also to construct the base/scalar field of `secp256k1`, which we never need to deserialise from public inputs). This PR standardises usage of native public inputs by creating a structure similar to the one used in `stdlib`: we define a `PublicInputComponent` class that works as a wrapper around classes that can be deserialised from the public inputs, and we use this wrapper class to reconstruct special public inputs (pairing points, IPA claims, etc.). To use the class, we make choices about how elements that are not currently used in circuit should be serialised. This pertains to base/scalar fields of `secp256k1` and `secp256r1` (and therefore to affine points on these curves). For consistency with the base field of `BN254`, we set `PUBLIC_INPUTS_SIZE = 4` for an element in each of these fields. This PR also cleans up the usage of the constants `PAIRING_POINTS_SIZE` and `IPA_CLAIM_SIZE`, as they can now be extracted from the respective classes `PairingPoints` and `OpeningClaim<Curve>` where `Curve` is `Grumpkin` (either native or `stdlib`) Closes AztecProtocol/barretenberg#1478 --------- Co-authored-by: AztecBot <tech@aztecprotocol.com> Co-authored-by: Suyash Bagad <suyash@aztecprotocol.com> Co-authored-by: Jonathan Hao <jonathan@aztec-labs.com> Co-authored-by: ledwards2225 <98505400+ledwards2225@users.noreply.github.com> Co-authored-by: sergei iakovenko <105737703+iakovenkos@users.noreply.github.com> Co-authored-by: ludamad <adam.domurad@gmail.com> Co-authored-by: Raju Krishnamoorthy <krishnamoorthy@gmail.com> Co-authored-by: notnotraju <raju@aztec-labs.com> Co-authored-by: Lucas Xia <lucasxia01@gmail.com> Co-authored-by: Khashayar Barooti <khashayar@aztecprotocol.com> Co-authored-by: Jean M <132435771+jeanmon@users.noreply.github.com> Co-authored-by: Alex Gherghisan <alexghr@users.noreply.github.com> Co-authored-by: Santiago Palladino <spalladino@users.noreply.github.com> Co-authored-by: Santiago Palladino <santiago@aztec-labs.com> Co-authored-by: ludamad <domuradical@gmail.com> Co-authored-by: maramihali <mara@aztecprotocol.com> Co-authored-by: Sarkoxed <75146596+Sarkoxed@users.noreply.github.com>

feat(sol): vk hashing

8ea60d6

Maddiaa0 commented Jul 26, 2025

View reviewed changes

Maddiaa0 added 5 commits July 26, 2025 19:42

chore: remove todo

740a92c

chore: add doc

8fef71b

chore: scripts/cop_to_cpp.sh

18f5dd5

fix: key consistency test

b2430f0

fix: ultra transcript test

04114b7

Maddiaa0 mentioned this pull request Jul 27, 2025

feat(sol): apply vk hashing to optimized contract #16020

Closed

lucasxia01 self-requested a review July 29, 2025 01:16

lucasxia01 reviewed Jul 29, 2025

View reviewed changes

barretenberg/cpp/src/barretenberg/ultra_honk/ultra_transcript.test.cpp Show resolved Hide resolved

lucasxia01 reviewed Jul 29, 2025

View reviewed changes

Maddiaa0 added 4 commits July 29, 2025 10:52

chore: remove magic number

3eed299

chore: move vk hash to const outside of struct

c897cde

Merge branch 'next' into md/hashing-vk-sol

fa38300

chore: update copy_to_cpp script

98c1bb4

lucasxia01 reviewed Jul 29, 2025

View reviewed changes

Maddiaa0 added 3 commits August 1, 2025 11:29

Merge branch 'next' into md/hashing-vk-sol

1325db6

review

b54e211

chore: document todo

e783e35

lucasxia01 approved these changes Aug 3, 2025

View reviewed changes

Maddiaa0 added this pull request to the merge queue Aug 3, 2025

Merged via the queue into next with commit 935a8fa Aug 3, 2025
5 checks passed

Maddiaa0 deleted the md/hashing-vk-sol branch August 3, 2025 20:10

This was referenced Aug 3, 2025

Add vk FS to solidity contract AztecProtocol/barretenberg#1427

Closed

feat!: vk hashing in solidity verifier #15071

Closed

feat(sol): vk hashing #16015

feat(sol): vk hashing #16015

Uh oh!

Conversation

Maddiaa0 commented Jul 26, 2025

Overview

Uh oh!

Maddiaa0 commented Jul 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Maddiaa0 Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Maddiaa0 Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucasxia01 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Maddiaa0 commented Jul 26, 2025 •

edited

Loading

Maddiaa0 Jul 29, 2025 •

edited

Loading

Maddiaa0 Jul 29, 2025 •

edited

Loading