Skip to content

fix: rename file names for IIP-9 and IIP-10 #39

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
lzpap merged 2 commits into from
Feb 25, 2026
Merged

fix: rename file names for IIP-9 and IIP-10 #39

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6c594da
fix: rename file names for IIP-9 and IIP-10
lzpap Feb 25, 2026
59795ba
fix references
lzpap Feb 25, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
0 iips/IIP-0009/iip-0009.md → iips/IIP-0009/IIP-0009.md
View file
Open in desktop
File renamed without changes.
8 changes: 4 additions & 4 deletions iips/IIP-0010/iip-0010.md → iips/IIP-0010/IIP-0010.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ Traditionally, answering these questions required either:

Possible use cases exploiting `PackageMetadata` could be:

1. Account Abstraction (planned) (see [IIP-0009](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0009/iip-0009.md)): Move code reads `PackageMetadata` to verify that a function is a valid authenticator and to obtain the account type it authenticates. This enables the `account` module to create `AuthenticatorInfoV1` instances that reference verified authenticator functions.
1. Account Abstraction (planned) (see [IIP-0009](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0009/IIP-0009.md)): Move code reads `PackageMetadata` to verify that a function is a valid authenticator and to obtain the account type it authenticates. This enables the `account` module to create `AuthenticatorInfoV1` instances that reference verified authenticator functions.
2. View Functions (planned) (see [IIP-0005](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0005/iip-0005.md)): Modules and clients can discover which functions are safe to call without state changes.
3. Capability Verification: Modules can verify package capabilities before granting access.
4. Function modifiers: Modules can parse functions of any package to check whether they are entry, private, etc.
Expand All @@ -64,7 +64,7 @@ The proposed Package Metadata model must adhere to the following constraints:

To support `PackageMetadata`, we propose to modify part of the Move compilation, part of the publish/upgrade execution and the addition of a new module to the iota-framework.

In the following, we are going to use the usage of Package Metadata within the IOTA Account Abstraction model (see [IIP-0009](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0009/iip-0009.md)), because that is a concrete use of the standard.
In the following, we are going to use the usage of Package Metadata within the IOTA Account Abstraction model (see [IIP-0009](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0009/IIP-0009.md)), because that is a concrete use of the standard.

```
┌─────────────────────────────────────────────────────────────────┐
Expand Down Expand Up @@ -138,7 +138,7 @@ When a publish or upgrade transaction is executed, the protocol takes over. This

##### Verification

During publish or upgrade, the protocol extracts `RuntimeModuleMetadata` from each module's bytecode using this the `IOTA_METADATA_KEY`, deserializes it, and verifies each attribute. For every attribute found, the protocol invokes the corresponding verifier. For authenticator attributes, for instance, this means calling `verify_authenticate_func_v1()`, which checks that the function has the correct visibility, parameter types, and return type (see [IIP-0009](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0009/iip-0009.md)).
During publish or upgrade, the protocol extracts `RuntimeModuleMetadata` from each module's bytecode using this the `IOTA_METADATA_KEY`, deserializes it, and verifies each attribute. For every attribute found, the protocol invokes the corresponding verifier. For authenticator attributes, for instance, this means calling `verify_authenticate_func_v1()`, which checks that the function has the correct visibility, parameter types, and return type (see [IIP-0009](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0009/IIP-0009.md)).

If any verification fails, the entire publish or upgrade transaction fails. User code cannot write to the `IOTA_METADATA_KEY` slot in a way that would bypass verification, because the verifier runs before execution completes, and any invalid metadata causes the transaction to fail.

Expand Down Expand Up @@ -308,7 +308,7 @@ Computing metadata IDs deterministically from package IDs means that any code, o

## Reference Implementation

Main PR against the develop branch: https://github.com/iotaledger/iota/pull/9586. See [IIP-0009](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0009/iip-0009.md).
Main PR against the develop branch: https://github.com/iotaledger/iota/pull/9586. See [IIP-0009](https://github.com/iotaledger/IIPs/blob/main/iips/IIP-0009/IIP-0009.md).

## Questions and Open Issues

Expand Down