feat(move): Add custom attributes #9453

miker83z · 2025-11-27T11:00:50Z

Description of change

This PR cherry picks 2 commits in common to enable authenticator and move view attributes at the move level.
Changes:

Added a generic FlavoredAttribute which can then allow us to define new attributes within the iota_mode compiler part.
Introduces a new protocol feature flag (iota_metadata_module_bytes) to allow the insertion of metadata in the serialized compiled modules (bytecode). This kind of operation was disabled before this PR, with the flag no_extraneous_module_bytes. Instead, iota_metadata_module_bytes allows to fill this metadata field during the execution of build_from_resolution_graph. At the module deserializer level, the only performed check is that metadata have only 1 field and the metadata key is hardcoded. During the execution of the iota-verifier, the metadata value is checked for having well formed metadata struct (later authenticate and view functions checks will be performed here).

Release Notes

…e attr logic into iota_mode (#9187) # Description of change Added a generic FlavoredAttribute which can then allow us to define new attributes within the iota_mode compiler part. ## Links to any relevant issues Fixes #9186 ## How the change has been tested - [ ] Basic tests (linting, compilation, formatting, unit/integration tests) - [ ] Patch-specific tests (correctness, functionality coverage) - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] I have checked that new and existing unit tests pass locally with my changes

vercel · 2025-11-27T11:00:54Z

The latest updates on your projects. Learn more about Vercel for GitHub.

6 Skipped Deployments

Project	Deployment	Preview	Updated (UTC)
apps-backend	Ignored	Preview	Dec 2, 2025 0:10am
apps-ui-kit	Ignored	Preview	Dec 2, 2025 0:10am
iota-evm-bridge	Ignored	Preview	Dec 2, 2025 0:10am
iota-multisig-toolkit	Ignored	Preview	Dec 2, 2025 0:10am
rebased-explorer	Ignored	Preview	Dec 2, 2025 0:10am
wallet-dashboard	Ignored	Preview	Dec 2, 2025 0:10am

thibault-martinez

Approving crates/iota-open-rpc/spec/openrpc.json

…ata during package build (#9137) This PR introduces a new protocol feature flag to allow the insertion of metadata in the serialized compiled modules (bytecode). This was operation was disabled before this PR, with the flag `no_extraneous_module_bytes`. This allows to fill this metadata field during the execution of `build_from_resolution_graph`. At the module deserializer level, the only performed check is that metadata have only 1 field and the metadata key is hardcoded. During the execution of the iota-verifier, the metadata value is checked for having well formed metadata struct (later authenticate and view functions checks will be performed here). Fixes #9135 - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes

lzpap · 2025-11-27T17:25:58Z

crates/iota-protocol-config/src/lib.rs

                    cfg.feature_flags
                        .consensus_commit_transactions_only_for_traversed_headers = true;
+                    if chain != Chain::Mainnet && chain != Chain::Testnet {
+                        cfg.feature_flags.iota_metadata_module_bytes = true;


@miker83z do we want to enable this already on devnet/alphanet?

Yes, just alphanet for now. We can cherrypick the squashed commit of this PR into develop and include it in the next release. This would allow the move view attribute to be be implemented more easily, independently from anything else.

Then, I'd wait the enabling of either the view attribute or authenticator attribute before enabling iota metadata also on devnet.

There is no differentiation between Alphanet and Devnet, both are "unknown" Chains

bingyanglin

Approved the files owned by the node team.

alexsporn · 2025-11-28T07:43:15Z

crates/iota-protocol-config/src/lib.rs

+    // If true, it allows metadata bytes indexed with the iota key in a compiled module
+    // This flag is used to provide the correct MoveVM configuration for clients.
+    #[serde(skip_serializing_if = "is_false")]
+    iota_metadata_module_bytes: bool,


I understand that it is because it is metadata on the iota flavor of Move, but why do we need to write iota here in the config?

Thoralf-M · 2025-11-28T07:57:13Z

crates/iota-types/src/move_package.rs

+/// The list of iota attribute types recognized by the compiler.
+#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Serialize, Deserialize)]
+pub enum IotaAttribute {
+    // Attribute(Attribute),


Why is this an empty enum? Is it even needed then? Or if you want to populate it in the future, then maybe it should have #[non_exhaustive]?

It is populated in the next PR #9461

crates/iota-protocol-config/src/lib.rs

) # Description of change This PR introduces the creation of a Package Metadata immutable object during a package publishing/upgrade. This allows to use such metadata to create `AuthenticatorInfoV1` instances for accounts. [Internal AA architecture document](https://iotafoundation.atlassian.net/wiki/x/EoBOng). Description: - every time a function uses the `#[authenticator]` annotation, the node’s publish/upgrade execution tries to create a `PackageMetadata` immutable object. - a new set of functions in the `iota-verifier` crate implement the checking of the requirements for a package metadata to be valid; the information for such validation is extracted from the package bytecode (see #9453) - `iota-verifier::verify_authenticate_func_v1` checks the correctness of the declared authenticate() function (that was previously annotated with #[authenticator]) - once the PackageMetadata immutable object is created, then the framework method `create_auth_info_v1` can be used as the only way to create an `AuthenticatorInfoV1` instance. - the `AuthenticatorInfoV1` struct includes the fields to uniquely identify a function on-chain: package id, module name, function name. - An Account object is an object with a dynamic field being a `AuthenticatorInfoV1`. - Then, to any user-created object, an `AuthenticatorInfoV1` can be “attached“. The only requirement is that the AuthenticatorInfoV1<T> is compatible with T, where T is exactly the type of the object set to become an Account. ## How the change has been tested - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes ### Release Notes - [x] Protocol: Add the publish_package_metadata. This enables the creation of an immutable object at publish/upgrade time when some known attributes (e.g., the authenticator function attribute) are found in the source code. - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API: --------- Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com> Co-authored-by: Pavlo Botnar <pavlo.botnar@gmail.com>

This PR cherry picks 2 commits in common to enable authenticator and move view attributes at the move level. Changes: 1. Added a generic FlavoredAttribute which can then allow us to define new attributes within the iota_mode compiler part. 2. Introduces a new protocol feature flag (iota_metadata_module_bytes) to allow the insertion of metadata in the serialized compiled modules (bytecode). This kind of operation was disabled before this PR, with the flag no_extraneous_module_bytes. Instead, iota_metadata_module_bytes allows to fill this metadata field during the execution of build_from_resolution_graph. At the module deserializer level, the only performed check is that metadata have only 1 field and the metadata key is hardcoded. During the execution of the iota-verifier, the metadata value is checked for having well formed metadata struct (later authenticate and view functions checks will be performed here). - [x] Protocol: Added metadata_in_module_bytes flag to allow the insertion of IOTA specific metadata in the serialized compiled modules (bytecode). - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:

) This PR introduces the creation of a Package Metadata immutable object during a package publishing/upgrade. This allows to use such metadata to create `AuthenticatorInfoV1` instances for accounts. [Internal AA architecture document](https://iotafoundation.atlassian.net/wiki/x/EoBOng). Description: - every time a function uses the `#[authenticator]` annotation, the node’s publish/upgrade execution tries to create a `PackageMetadata` immutable object. - a new set of functions in the `iota-verifier` crate implement the checking of the requirements for a package metadata to be valid; the information for such validation is extracted from the package bytecode (see #9453) - `iota-verifier::verify_authenticate_func_v1` checks the correctness of the declared authenticate() function (that was previously annotated with - once the PackageMetadata immutable object is created, then the framework method `create_auth_info_v1` can be used as the only way to create an `AuthenticatorInfoV1` instance. - the `AuthenticatorInfoV1` struct includes the fields to uniquely identify a function on-chain: package id, module name, function name. - An Account object is an object with a dynamic field being a `AuthenticatorInfoV1`. - Then, to any user-created object, an `AuthenticatorInfoV1` can be “attached“. The only requirement is that the AuthenticatorInfoV1<T> is compatible with T, where T is exactly the type of the object set to become an Account. - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes - [x] Protocol: Add the publish_package_metadata. This enables the creation of an immutable object at publish/upgrade time when some known attributes (e.g., the authenticator function attribute) are found in the source code. - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API: --------- Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com> Co-authored-by: Pavlo Botnar <pavlo.botnar@gmail.com>

This PR cherry picks 2 commits in common to enable authenticator and move view attributes at the move level. Changes: 1. Added a generic FlavoredAttribute which can then allow us to define new attributes within the iota_mode compiler part. 2. Introduces a new protocol feature flag (iota_metadata_module_bytes) to allow the insertion of metadata in the serialized compiled modules (bytecode). This kind of operation was disabled before this PR, with the flag no_extraneous_module_bytes. Instead, iota_metadata_module_bytes allows to fill this metadata field during the execution of build_from_resolution_graph. At the module deserializer level, the only performed check is that metadata have only 1 field and the metadata key is hardcoded. During the execution of the iota-verifier, the metadata value is checked for having well formed metadata struct (later authenticate and view functions checks will be performed here). - [x] Protocol: Added metadata_in_module_bytes flag to allow the insertion of IOTA specific metadata in the serialized compiled modules (bytecode). - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:

) This PR introduces the creation of a Package Metadata immutable object during a package publishing/upgrade. This allows to use such metadata to create `AuthenticatorInfoV1` instances for accounts. [Internal AA architecture document](https://iotafoundation.atlassian.net/wiki/x/EoBOng). Description: - every time a function uses the `#[authenticator]` annotation, the node’s publish/upgrade execution tries to create a `PackageMetadata` immutable object. - a new set of functions in the `iota-verifier` crate implement the checking of the requirements for a package metadata to be valid; the information for such validation is extracted from the package bytecode (see #9453) - `iota-verifier::verify_authenticate_func_v1` checks the correctness of the declared authenticate() function (that was previously annotated with - once the PackageMetadata immutable object is created, then the framework method `create_auth_info_v1` can be used as the only way to create an `AuthenticatorInfoV1` instance. - the `AuthenticatorInfoV1` struct includes the fields to uniquely identify a function on-chain: package id, module name, function name. - An Account object is an object with a dynamic field being a `AuthenticatorInfoV1`. - Then, to any user-created object, an `AuthenticatorInfoV1` can be “attached“. The only requirement is that the AuthenticatorInfoV1<T> is compatible with T, where T is exactly the type of the object set to become an Account. - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes - [x] Protocol: Add the publish_package_metadata. This enables the creation of an immutable object at publish/upgrade time when some known attributes (e.g., the authenticator function attribute) are found in the source code. - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API: --------- Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com> Co-authored-by: Pavlo Botnar <pavlo.botnar@gmail.com>

This PR cherry picks 2 commits in common to enable authenticator and move view attributes at the move level. Changes: 1. Added a generic FlavoredAttribute which can then allow us to define new attributes within the iota_mode compiler part. 2. Introduces a new protocol feature flag (iota_metadata_module_bytes) to allow the insertion of metadata in the serialized compiled modules (bytecode). This kind of operation was disabled before this PR, with the flag no_extraneous_module_bytes. Instead, iota_metadata_module_bytes allows to fill this metadata field during the execution of build_from_resolution_graph. At the module deserializer level, the only performed check is that metadata have only 1 field and the metadata key is hardcoded. During the execution of the iota-verifier, the metadata value is checked for having well formed metadata struct (later authenticate and view functions checks will be performed here). - [x] Protocol: Added metadata_in_module_bytes flag to allow the insertion of IOTA specific metadata in the serialized compiled modules (bytecode). - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API:

) This PR introduces the creation of a Package Metadata immutable object during a package publishing/upgrade. This allows to use such metadata to create `AuthenticatorInfoV1` instances for accounts. [Internal AA architecture document](https://iotafoundation.atlassian.net/wiki/x/EoBOng). Description: - every time a function uses the `#[authenticator]` annotation, the node’s publish/upgrade execution tries to create a `PackageMetadata` immutable object. - a new set of functions in the `iota-verifier` crate implement the checking of the requirements for a package metadata to be valid; the information for such validation is extracted from the package bytecode (see #9453) - `iota-verifier::verify_authenticate_func_v1` checks the correctness of the declared authenticate() function (that was previously annotated with - once the PackageMetadata immutable object is created, then the framework method `create_auth_info_v1` can be used as the only way to create an `AuthenticatorInfoV1` instance. - the `AuthenticatorInfoV1` struct includes the fields to uniquely identify a function on-chain: package id, module name, function name. - An Account object is an object with a dynamic field being a `AuthenticatorInfoV1`. - Then, to any user-created object, an `AuthenticatorInfoV1` can be “attached“. The only requirement is that the AuthenticatorInfoV1<T> is compatible with T, where T is exactly the type of the object set to become an Account. - [x] Basic tests (linting, compilation, formatting, unit/integration tests) - [x] Patch-specific tests (correctness, functionality coverage) - [x] I have added tests that prove my fix is effective or that my feature works - [x] I have checked that new and existing unit tests pass locally with my changes - [x] Protocol: Add the publish_package_metadata. This enables the creation of an immutable object at publish/upgrade time when some known attributes (e.g., the authenticator function attribute) are found in the source code. - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: - [ ] REST API: --------- Co-authored-by: Valerii Reutov <valeriy.reutov@gmail.com> Co-authored-by: Pavlo Botnar <pavlo.botnar@gmail.com>

# Description of change Enables Account Abstraction core features at the protocol level. [Internal AA architecture document](https://iotafoundation.atlassian.net/wiki/x/EoBOng). Main protocol changes: - feat(move): Add custom attributes #9453 - added a generic FlavoredAttribute which can then allow us to define new attributes within the iota_mode Move compiler part; - allow the insertion of specific metadata in the serialized compiled modules, i.e., bytecode (protocol feature flag `metadata_in_module_bytes`). - feat(execution): create a package metadata object at publish time #9461 - every time a function uses the `#[authenticator]` annotation, the node’s publish/upgrade execution tries to create a `PackageMetadata` immutable object; - a new set of functions in the `iota-verifier` crate implement the checking of the requirements for a package metadata to be valid; - once the PackageMetadata immutable object is created, then the framework method `create_auth_function_ref_v1` can be used as the only way to create an `AuthenticatorFunctionRefV1` instance. - the `AuthenticatorFunctionRefV1` struct includes the fields to uniquely identify a function on-chain: package id, module name, function name. - An Account object is an object with a dynamic field being a `AuthenticatorFunctionRefV1`. - feat: Add the MoveAuthenticator generic signature variant and enable AA transactions #9492 - introduced a new iota type to represent a new `GenericSignature` variant, that is the `MoveAuthenticator` type, and a execution path to authenticate an Account being the sender of a TX. - The `MoveAuthenticator` type has a unique field which is `call_args`; this is a vector of `CallArg` working similarly to the `ProgrammableTransactionBlock` inputs. - The `MoveAuthenticator` is used to pass the inputs to the move call indicated by the `AuthenticatorFunctionRefV1` found attached to the Account object. - This authentication job is performed by the Validator, which: (1) loads `MoveAuthenticator` input objects at a specific version; (2) then, executes the `authenticate()` function referenced by `AuthenticatorFunctionRefV1`, having no effects to store to the ledger.

miker83z requested review from a team as code owners November 27, 2025 11:00

iota-ci added sc-platform Issues related to the Smart Contract Platform group. vm-language Issues related to the VM & Language Team labels Nov 27, 2025

thibault-martinez approved these changes Nov 27, 2025

View reviewed changes

miker83z changed the base branch from vm-lang/aa-auth/8805-beta-feature-branch to vm-lang/aa-auth/7901-alpha-feature-branch November 27, 2025 12:45

miker83z force-pushed the vm-lang/cherry-pick-for-move-view branch from 0ee0fb8 to aea6522 Compare November 27, 2025 12:46

lzpap reviewed Nov 27, 2025

View reviewed changes

miker83z changed the base branch from vm-lang/aa-auth/7901-alpha-feature-branch to vm-lang/aa-auth/8805-beta-feature-branch November 27, 2025 19:15

bingyanglin approved these changes Nov 28, 2025

View reviewed changes

alexsporn reviewed Nov 28, 2025

View reviewed changes

Thoralf-M reviewed Nov 28, 2025

View reviewed changes

muXxer reviewed Nov 28, 2025

View reviewed changes

crates/iota-protocol-config/src/lib.rs Outdated Show resolved Hide resolved

refactor(protocol): rename to metadata_in_module_bytes

2ba7b55

miker83z requested review from alexsporn and muXxer December 1, 2025 09:58

valeriyr approved these changes Dec 1, 2025

View reviewed changes

miker83z mentioned this pull request Dec 1, 2025

feat(execution): create a package metadata object at publish time #9461

Merged

12 tasks

muXxer approved these changes Dec 2, 2025

View reviewed changes

move new flag to protocol v17

632955c

miker83z merged commit 0080b31 into vm-lang/aa-auth/8805-beta-feature-branch Dec 2, 2025
42 checks passed

miker83z deleted the vm-lang/cherry-pick-for-move-view branch December 2, 2025 12:59

miker83z mentioned this pull request Jan 19, 2026

feat: Account Abstraction beta #9586

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(move): Add custom attributes #9453

feat(move): Add custom attributes #9453

Uh oh!

miker83z commented Nov 27, 2025 •

edited

Loading

Uh oh!

vercel bot commented Nov 27, 2025 •

edited

Loading

Uh oh!

thibault-martinez left a comment

Uh oh!

lzpap Nov 27, 2025

Uh oh!

miker83z Nov 27, 2025

Uh oh!

alexsporn Nov 28, 2025

Uh oh!

bingyanglin left a comment •

edited

Loading

Uh oh!

alexsporn Nov 28, 2025

Uh oh!

miker83z Dec 1, 2025

Uh oh!

Thoralf-M Nov 28, 2025

Uh oh!

miker83z Dec 1, 2025

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

feat(move): Add custom attributes #9453

feat(move): Add custom attributes #9453

Uh oh!

Conversation

miker83z commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of change

Release Notes

Uh oh!

vercel bot commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thibault-martinez left a comment

Choose a reason for hiding this comment

Uh oh!

lzpap Nov 27, 2025

Choose a reason for hiding this comment

Uh oh!

miker83z Nov 27, 2025

Choose a reason for hiding this comment

Uh oh!

alexsporn Nov 28, 2025

Choose a reason for hiding this comment

Uh oh!

bingyanglin left a comment • 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!

alexsporn Nov 28, 2025

Choose a reason for hiding this comment

Uh oh!

miker83z Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

Thoralf-M Nov 28, 2025

Choose a reason for hiding this comment

Uh oh!

miker83z Dec 1, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

miker83z commented Nov 27, 2025 •

edited

Loading

vercel bot commented Nov 27, 2025 •

edited

Loading

bingyanglin left a comment •

edited

Loading