Notes that deploy an Account via the ntx builder

[partylikeits1983]

Problem

A note cannot create an account. Today a network transaction executes against an account that already exists and consumes notes targeted at it. There is no note type that carries account data and has the ntx builder deploy that account.

This is a proposal for a note standard that carries the data for an account. The note holds everything the ntx builder needs to build a transaction that deploys that account. The note is self-contained. The ntx builder reads it, reconstructs the account, deploys it as a new account, and consumes the note in the same transaction. No further interaction from the creator.

This is a general capability, not tied to one source. Anything that can create a note can deploy an account: a Miden transaction, or an L1 transaction through the agglayer bridge.

Use cases

• Programmatic, network-driven account creation, similar to CREATE2 in the EVM: a note deterministically describes an account and the ntx builder deploys it.
• Faucet creation from a single note.
• A ready-deployed multisig from a single note.
• A ready-deployed wallet from a single note.
• A single L1 transaction through the agglayer bridge (bridgeMessage / bridgeAndCall) whose payload encodes a Miden account. The bridge produces the note on Miden, and the ntx builder deploys the account. One L1 transaction, one deployed Miden account.

Proposal

Add a network note type whose storage carries everything needed to deploy an account: a full serialized Account (the Serializable form of AccountCode + AccountStorage, plus account type, id version, and seed). The ntx builder deserializes the account from the note, validates it, deploys it as a new account (nonce 0, empty vault, valid seed), and consumes the note.

The protocol-side pieces this needs:

1. A new well-known network note type that carries serialized account data in NoteStorage. It is a public note and should be discoverable the same way other network notes are (see is_network_note and the NetworkAccountTarget attachment in crates/miden-standards/src/note/network_note.rs).
2. A constructor that builds an Account from the note storage and checks it against the new-account invariants the prologue already enforces (validate_new_account in asm/kernels/transaction/lib/prologue.masm: nonce 0, empty vault, valid seed). Account already implements Deserializable (crates/miden-protocol/src/account/mod.rs); AccountPatch (feat: Introduce AccountPatch and AccountVaultPatch #3010) is the absolute new-account state representation with code: Some(..).
3. The transaction that deploys the new account and consumes the note. The new account is the native account of its genesis transaction (nonce 0 -> 1 with seed), so the open design question is how the deploy and the note consumption are wired into one network transaction. Document the chosen execution model here.

Account encoding

Primary approach: full serialized account data in NoteStorage.

Constraint to resolve: NoteStorage holds at most MAX_NOTE_STORAGE_ITEMS = 1024 felts (~8 KB), and AccountCode is an Arc<MastForest> that can exceed this for non-trivial code. Fallback if the full code does not fit: encode a recipe of known standard component template ids plus init storage values, and reconstruct with AccountBuilder (crates/miden-protocol/src/account/builder/mod.rs). Faucet, multisig, and wallet are all standard components, so the recipe form covers those use cases at a fraction of the size. Decide whether to ship full-data, recipe, or both.

Fees

The note must fund the network transaction. The kernel deducts the fee from the executing account vault (compute_and_remove_fee in asm/kernels/transaction/lib/epilogue.masm), which for a network transaction is the network account, not the creator. So a deploy note needs a way to fund the fee on the network account's behalf.

The path here is not decided. It should follow whatever the network-note fee model lands on. One candidate is the FeeManager component from #2901, where the note carries a fee asset and calls pay_fee first (as BURN and CLAIM do). This also overlaps with the open question of separating note business logic from fee logic, discussed in #2968. Treat the fee path as an open question to resolve against those, not as settled.

Related

• standards: FeeManager account component for network accounts #2901 FeeManager account component for network accounts
• Separate business and fee logic for network accounts #2968 Separate business and fee logic for network accounts (discussion)
• Allow root-allowlisted tx scripts (enable tx expiration delta for network accounts) #3027 Allow root-allowlisted tx scripts for network accounts
• feat: Introduce AccountPatch and AccountVaultPatch #3010 AccountPatch / AccountVaultPatch

[mmagician]

The tricky part here is not how to encode the account data inside the Note, but rather, how the to-be-deployed account should signal its presence onchain. This is usually done through the consumption of a note.
So let's look at how the e2e flow could look like:

1. a user emits a CREATE2_INTENT network note
2. the ntx builder processes this note against some public network account. This could be a BuilderAccount, i.e. an account responsible for the programatic creation of other accounts
3. when BuilderAccount processes the CREATE2_INTENT note:
   a. it emits a new CREATE2 note, targeted at the NewAccount
   b. the ntx builder saves the details of NewAccount locally
4. CREATE2 note is then processed against NewAccount (likely in a new block)

This flow requires that 3b. has a special meaning inside the ntx builder, s.t.:

• ntx builder recognizes a BuilderAccount
• whenever a note is consumed by the builder account, apply special processing to this note, i.e. scrape its data, and save it as a new, "undeployed" local account

Then 4. is processed using the existing ntx rules

This is just one approach, there might be other simpler ones. In terms of complexity, it's relatively straightforward, but requires tying the ntx builder to another standard (which I think is ok, since ntx builder is already aware of the AuthNetworkAccount standard)

[bobbinth]

• a user emits a CREATE2_INTENT network note
• the ntx builder processes this note against some public network account. This could be a BuilderAccount, i.e. an account responsible for the programatic creation of other accounts
• when BuilderAccount processes the CREATE2_INTENT note:
  a. it emits a new CREATE2 note, targeted at the NewAccount
  b. the ntx builder saves the details of NewAccount locally
• CREATE2 note is then processed against NewAccount (likely in a new block)

I'm not sure this is needed. The NTX builder can recognize that a note is trying to create a new account and handle it differently from other network notes (the ones that are to be executed against an existing network account). Basically, there would be two separate paths in the NTX builder:

1. Regular network note.
2. Account-creating network note.

To make this distinction we could introduce a new attachment type - e.g., AccountConstructor - or maybe just reuse the existing NetworkAccountTarget attachment but add something like is_new flag to it.

In the longer term, it would be good to extend this model to be more "plug-in" based - i.e., we could install extensions in the node that would allow it to process different types of network notes using different logic.

[mmagician]

I think that is a good simplification 👍🏼

[PhilippGackstatter]

Basically, there would be two separate paths in the NTX builder:
1. Regular network note.
2. Account-creating network note.

Conceptually, the regular and the account-creation path seem pretty distinct, so I'd make this a separate attachment which should make it easier to reason about and code against (AccountConstructor takes the account-creation path, NetworkAccountTarget takes the regular path).

Constraint to resolve: NoteStorage holds at most MAX_NOTE_STORAGE_ITEMS = 1024 felts (~8 KB), and AccountCode is an Arc<MastForest> that can exceed this for non-trivial code. Fallback if the full code does not fit: encode a recipe of known standard component template ids plus init storage values

I think the fallback works in principle, but I'd avoid maintaining a template registry.

Another approach could be to provide the data of an account split across multiple AccountConstructor notes. The ntx builder would reassemble the full account data off-chain from the note storage and execute the account-creating transaction by consuming all of them (may or may not be necessary). One or all of the notes would check that the resulting account commitment is as expected, indicating that the ntx builder reassembled the account correctly.

This avoids a template registry and should allow for creation of even large accounts.

[mmagician]

Another approach could be to provide the data of an account split across multiple AccountConstructor notes. The ntx builder would reassemble the full account data off-chain from the note storage and execute the account-creating transaction by consuming all of them (may or may not be necessary).

I think this would introduce a ton of complexity on the ntx builder, who'd have to track (partial) lists of AccountConstructor notes.
But w/o a template registry, I think that's the only reasonable option.

[PhilippGackstatter]

I think this would introduce a ton of complexity on the ntx builder

It's not simple, but not sure it's a ton of complexity. Each note is marked with a x/n to make it relatively easy to see if all notes of a set are present or not.

Another approach that avoids multiple notes is to send the account data to the ntx builder via a side-channel to make it available. This doesn't have trust assumptions since the note itself would validate the account commitment. Has its own set of trade-offs. For instance, when ntx building is decentralized, would you need to send it to all ntx builders? But maybe in this case, each account would have an assigned ntx builder anyway.

Not an alternative to the general problem, but I think a similar approach that we use for creating public notes would also work for creating public network accounts. That is, we use the existing on-chain accounts as our registry. If an account on chain already has the same code commitment as the to-be-created account, the node doesn't need it sent again.

[partylikeits1983]

Small update on the fees part now that #2901 / #2968 have moved along. I don't think the deploy note needs anything special here. It's just a network note, so the fee goes in the NetworkAccountTarget attachment and the script calls pay_fee first like everything else. The new account starting with an empty vault isn't a problem either, the note brings the fee asset with it when it's consumed.

One nice side effect of @bobbinth's simplification above: if we end up adding an is_new flag next to the fee field, then everything the ntx builder needs to know about a network note lives in that one attachment, and it can tell deploy notes from regular ones without executing anything.

Still to decide: full serialized account vs component recipe (I'd start with the recipe, the 1024-felt cap makes the full version tight), and how the deploy + note consumption actually get wired into one network tx.

[mmagician]

full serialized account vs component recipe (I'd start with the recipe, the 1024-felt cap makes the full version tight)

what do you mean exactly, and how would each path work?

EDIT: nvm I found this in the top-most post

[bobbinth]

Still to decide: full serialized account vs component recipe (I'd start with the recipe, the 1024-felt cap makes the full version tight), and how the deploy + note consumption actually get wired into one network tx.

Could we also use attachment space to encode some of the account data? Overall, to create an account we need:

1. Initialize the storage.
2. Initialize the code.

If/when we implement #2982, the code part shouldn't take up that much space (will definitely fit into 8KB in the vast majority of cases).

As for storage, most accounts probably don't need to be initialized with too much data. I would assume around 8KB should suffice here too (and for this, we should be able to use the attachment space).