docs: add docs and renaming by zkfrov · Pull Request #16 · defi-wonderland/aztec-immutables-macro

zkfrov · 2026-02-11T14:29:00Z

Description

Rename macro library: initializerless → constants
Rename macro file: constants.nr → macro.nr
Rename contract: schnorr_constants_account_contract → schnorr_initializerless_account_contract
Update all Nargo.toml dependencies and workspace members to match new names
Update all use initializerless::constants → use constants::constants across contracts
Rewrite README with full usage guide, how-it-works explanation, and project structure

Signed-off-by: frov <frov@wonderland.xyz>

paperclip-minim · 2026-02-11T20:50:06Z

+## Overview

-## Features
+On Aztec, contracts that need immutable values — such as an account contract's signing public key — must currently use an initializer function that writes to private storage (e.g. `SinglePrivateImmutable`). This requires a constructor transaction, note delivery for setup, and initialization checks on subsequent function calls.


Suggested change

On Aztec, contracts that need immutable values — such as an account contract's signing public key — must currently use an initializer function that writes to private storage (e.g. `SinglePrivateImmutable`). This requires a constructor transaction, note delivery for setup, and initialization checks on subsequent function calls.

On Aztec, contracts that need immutable values — such as an account contract's signing public key — must currently use an initializer function that writes to private storage (e.g. `SinglePrivateImmutable`). This requires an initialization transaction, note delivery for setup, and initialization checks on subsequent function calls.

paperclip-minim · 2026-02-11T20:52:20Z

-<dl>
-  <dt>Sample Noir contract</dt>
-  <dd>Basic Counter contract demonstrating private-to-public execution patterns and owner access control.</dd>
+The `#[constants]` macro offers a different approach: constants are encoded into the contract's `salt`, which is part of the address derivation. At runtime, constants are loaded from capsule storage and verified against the salt committed in the contract address. The constants are cryptographically fixed to the contract address.


Suggested change

The `#[constants]` macro offers a different approach: constants are encoded into the contract's `salt`, which is part of the address derivation. At runtime, constants are loaded from capsule storage and verified against the salt committed in the contract address. The constants are cryptographically fixed to the contract address.

The `#[constants]` macro offers a different approach: constants are committed-to in the contract's address. At runtime, constants are loaded from capsule storage and verified against their commitment in the address.

I don't think an overview should go into implementation details

paperclip-minim · 2026-02-11T20:55:20Z


-  <dt>Aztec development setup</dt>
-  <dd>Pre-configured Aztec workspace with Noir contract compilation and TypeScript artifact generation.</dd>
+The first use case is an **initializerless Schnorr account contract** that stores its signing public key as a constant, removing the need for an initializer entirely.


Suggested change

The first use case is an **initializerless Schnorr account contract** that stores its signing public key as a constant, removing the need for an initializer entirely.

This repo includes an **initializerless Schnorr account contract** as an example use case.

paperclip-minim · 2026-02-11T20:57:21Z


-**Option 1: Automatic**
-Just run the tests and the sandbox will be handled automatically:
+**Verification (Noir):**


Suggested change

**Verification (Noir):**

**Reconstruction and verification (Noir):**

paperclip-minim · 2026-02-11T20:59:38Z

-yarn test
+```toml
+[dependencies]
+constants = { path = "../constants" }


Shouldn't we have an absolute path? e.g. poseidon in noir-protocol-circuits:
poseidon = { tag = "v0.2.3", git = "https://github.com/noir-lang/poseidon" }

paperclip-minim · 2026-02-11T21:01:36Z

-aztec start --sandbox  # Start manually in separate terminal
-yarn test              # Run tests against existing sandbox
-```
+## Usage


IIUC we also need to explicitly incorporate the capsule to transactions, right? whether it's on a TX-basis or just one setup at some point. If so, it should be documented here as well.

# 🤖 Linear Closes AZT-XXX # Description This branch introduces the **`#[immutables]` macro pattern** for Aztec Noir contracts — a mechanism that allows contracts to store immutable values committed via the contract's salt, eliminating the need for an initializer transaction. It includes the Noir library, example contracts, a full TypeScript SDK, tests, benchmarks, and CI infrastructure. ## Noir Library & Contracts (PRs #8, #16, #19, #27) - **`#[immutables]` comptime macro** (`src/nr/immutables/src/macro.nr`) that generates: - `Serialize` / `Deserialize` implementations - `Immutables::init(context)` — loads from capsule and verifies against `instance.salt` - `Immutables::init_unconstrained(context)` — unconstrained load without verification - Salt derivation: `salt = poseidon2_hash([actual_salt, ...serialized_immutables])` - **`immutables_contract`** — Demo contract with both immutables and mutable storage (mixed usage) - **`schnorr_initializerless_account_contract`** — Account contract using the initializerless pattern (signing key committed via salt, no initializer needed) - **`schnorr_account_contract`** — Standard Schnorr account with initializer-based key storage (baseline for comparison) - Noir TXE test scaffolding (most tests disabled pending [aztec-packages#16656](AztecProtocol/aztec-packages#16656) — TXE doesn't support custom salt) - Upgraded to Aztec `v4.0.0-devnet.1-patch.0` ## TypeScript SDK (PR #9) - **`src/ts/immutables/`** — Generic utilities for deploying any contract using `#[immutables]`: - `computeContractSalt(actualSalt, serializedImmutables)` - `createImmutablesCapsule(address, actualSalt, fields)` - `deployWithImmutables(wallet, artifact, fields, options?)` - Supports both published (on-chain) and unpublished (PXE-only) deployment - **`src/ts/schnorr-initializerless-account/`** — Account contract integration: - `SchnorrInitializerlessAccountContract` (implements `AccountContract` interface) - `SchnorrInitializerlessAuthWitnessProvider` (Schnorr signature creation) - `registerInitializerlessAccount(wallet, options?)` — one-call deployment + wallet registration - `computeSchnorrAccountAddress(signingKey, options?)` — pre-compute address before deployment ## Tests & Benchmarks (PR #9) | File | Description | |------|-------------| | `schnorr-initializerless-account.test.ts` | 12 tests: deploy + read key, different keys/salts → different addresses, wrong capsule/actualSalt rejection, published + unpublished variants | | `immutables-contract.test.ts` | Published/unpublished deploy, wrong capsule rejection, mixed usage with initializer | | `e2e.test.ts` | End-to-end with Dripper FPC: initializerless account receives private tokens, transfers, balance checks vs standard SchnorrAccount | | `account.benchmark.ts` | Benchmark suite for account contract operations | ## Documentation & CI (PRs #16, #19) - Full README rewrite with usage guide, how-it-works explanation, capsule documentation, and project structure - CI workflows for PR checks, pre-release publishing, and baseline tracking  ## Summary by CodeRabbit * **New Features** * Immutables macro and initializerless immutables deployment workflow; Schnorr account variants; TypeScript SDK for artifact introspection, serialization, address precomputation, and deploy helpers; new account benchmarks. * **Documentation** * README rewritten around immutables pattern, deployment/verification guides and examples. * **Tests** * Comprehensive end-to-end test suites for immutables and Schnorr account flows. * **Chores** * Removed legacy counter examples; CI/workflow reorganization; package rebranding; updated pre-commit formatter and expanded .gitignore.  --------- Signed-off-by: frov <frov@wonderland.xyz> Co-authored-by: Paperclip Minimizer <minim@wonderland.xyz> Co-authored-by: Weißer Hase <84595958+wei3erHase@users.noreply.github.com> Co-authored-by: Weißer Hase <wei3erHase@protonmail.com>

zkfrov added 20 commits January 30, 2026 16:05

feat: add initializerless constant contracts

4c054dc

feat: add constants macro

1f6187f

chore: bump nargo toml aztec import version

749e197

chore: rename constants functions to init and init_unconstrained

5364e02

refactor: use context instead of address as input

3f79a52

refactor: remove to_public_key from macro

f6b741a

feat: remove unnecessary check

8e3bd3d

feat: remove empty struct check

2890d18

feat: use derive_serialize_if_not_implemented in macro

326286d

feat: validate against salt instead of initialization hash

a94b82e

feat: derive a random number for the constants slot

e305036

feat: use public key struct

81e50c8

chore: update comments on constants contract

46f17c6

ci: add counter tests again

b6bb3ef

ci: fix aztec version error

f8e1348

chore: upgrade to v4.0.0-nightly.20260204

29db317

feat: implement derive_deserialize_if_not_implemented

f478855

feat: derive_deserialize correct implementation

cf59635

ci: test workflow

4f9148c

docs: add docs and renaming

db6a95e

zkfrov mentioned this pull request Feb 11, 2026

feat: nr contracts #8

Merged

Base automatically changed from feat/nr-contracts to feat/constant-account February 11, 2026 14:32

Merge branch 'feat/constant-account' into docs/add-documentation

a6a6cf3

Signed-off-by: frov <frov@wonderland.xyz>

wei3erHase approved these changes Feb 11, 2026

View reviewed changes

zkfrov merged commit 94f319a into feat/constant-account Feb 11, 2026
2 of 3 checks passed

zkfrov deleted the docs/add-documentation branch February 11, 2026 15:17

paperclip-minim reviewed Feb 11, 2026

View reviewed changes

claude Bot added the claude-code-assisted label Feb 12, 2026

zkfrov mentioned this pull request Mar 3, 2026

feat: immutables macro #28

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

docs: add docs and renaming#16

docs: add docs and renaming#16
zkfrov merged 21 commits into
feat/constant-accountfrom
docs/add-documentation

zkfrov commented Feb 11, 2026 •

edited

Loading

Uh oh!

Uh oh!

paperclip-minim Feb 11, 2026

Uh oh!

paperclip-minim Feb 11, 2026

Uh oh!

paperclip-minim Feb 11, 2026

Uh oh!

paperclip-minim Feb 11, 2026

Uh oh!

paperclip-minim Feb 11, 2026

Uh oh!

paperclip-minim Feb 11, 2026

Uh oh!

paperclip-minim Feb 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

	On Aztec, contracts that need immutable values — such as an account contract's signing public key — must currently use an initializer function that writes to private storage (e.g. `SinglePrivateImmutable`). This requires a constructor transaction, note delivery for setup, and initialization checks on subsequent function calls.
	On Aztec, contracts that need immutable values — such as an account contract's signing public key — must currently use an initializer function that writes to private storage (e.g. `SinglePrivateImmutable`). This requires an initialization transaction, note delivery for setup, and initialization checks on subsequent function calls.

	The `#[constants]` macro offers a different approach: constants are encoded into the contract's `salt`, which is part of the address derivation. At runtime, constants are loaded from capsule storage and verified against the salt committed in the contract address. The constants are cryptographically fixed to the contract address.
	The `#[constants]` macro offers a different approach: constants are committed-to in the contract's address. At runtime, constants are loaded from capsule storage and verified against their commitment in the address.

	The first use case is an initializerless Schnorr account contract that stores its signing public key as a constant, removing the need for an initializer entirely.
	This repo includes an initializerless Schnorr account contract as an example use case.

	Verification (Noir):
	Reconstruction and verification (Noir):

Conversation

zkfrov commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

Uh oh!

paperclip-minim Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

paperclip-minim Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

paperclip-minim Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

paperclip-minim Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

paperclip-minim Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

paperclip-minim Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

paperclip-minim Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

zkfrov commented Feb 11, 2026 •

edited

Loading