The Iota Improvement Proposal (IIP) Book

iip: 5
title: Move View Functions
description: A standardized interface for application-specific queries to on-chain state
author: Levente Pap (@lzpap) , Mirko Zichichi (@miker83z) 
discussions-to: https://github.com/iotaledger/IIPs/discussions/18
status: Draft
type: Standards Track
layer: Interface
created: 2025-07-22
requires: None

Abstract

This proposal introduces a standardized interface for enabling ergonomic and application-specific queries to on-chain state. Move view functions are developer defined on-chain read API that can be easily queried off-chain without requiring transaction signing or state mutation (based on the Ethereum's Solidity view function feature concept). The proposal is made to improve developer productivity and simplifying access to on-chain data through RPC, CLI, and SDK interfaces.

Motivation

Currently, developers must write a significant amount of custom client-side logic to inspect on-chain data. This often involves multiple layers of fetching object IDs, deserializing raw bytes, and navigating dynamic fields just to reach an information stored within a Move object. While tools like dev-inspect or dry-run exist, they suffer from limitations such as complexity in usage and difficulty in decoding return values.

This proposal aims to address the following developer pain points:

• Being forced to understand the logic of a Move data structure and then how to map that to RPC calls in order to fetch a piece of data, e.g., getting nested object ids.
• Some data structures cannot easily be accessed through current RPC calls because of the way they use dynamic fields, e.g., Bag and Table data structures.
• Using dev-inspect can become complicated because the function return values the developer gets are BCS bytes and then these need to be parsed, assuming the return type is known.

Specification

This proposal defines a developer interface to support Move View Functions. The following is a list of specifications related to its implementation:

• A View Function is a function in a Move module with a return type that does not alter the state of the ledger, i.e., when using the Move View Function interface no transactions are submitted to the network for their inclusion into the ledger.
• Move View Functions are callable via at least one new RPC method that supports type parameters and function arguments.
• The use of such interface MUST NOT require signature checks, i.e., invoking a Move View Function that takes as input an Owned Object MUST be made possible to anyone and not only to the owner of such object.
• The use of such interface MUST NOT require the usage of a gas coin; spam attacks SHOULD be dealt with at the RPC level and not at the execution level; this is because the Move View Function does not alter the state of the ledger and thus cannot deduce gas.
• Returned results MUST be resolved, i.e., the Move types deserialized, and then formatted in JSON.
• Must be integrated into the SDKs and the CLI.

The following specifies the proposed developer interfaces.

iota_view JSON-RPC method

Executes a Move View Function. Which allows for nearly any Move call for a function with a return type and with any arguments. The function's result values are provided and decoded using the appropriate Move type.

Parameters

Result

Example

The following example can be taken as a reference for the API model.

Request:

{
  "method": "iota_view",
  "params": {
    "functionName": "0x5e7a300e640f645a4030aeb507c7be16909e6fa9711e7ca2d4397bbd967d5c50::auction::get_auction_metadata",
    "typeArgs": [],
    "arguments": [
      "auc.iota",
      "0x31deb8cbd320867089d52c37fed2d443520aac0fc5a957de1f64f9135b83f42b"
    ]
  }
}

Response:

{
  "results": [
    "start": "447575403174913",
    "end": "447576324774913",
    "address": "0xc9f649324694c0c18c6278c3a81945fb3ef0c9b91f21dd5b6a4364447ee348df",
    "value": "500000000"
  ]
}

view GraphQL RPC query

A new GraphQL read query is added to the IOTA GraphQL RPC interface with the following structure:

view(
  functionName: String!
  typeArguments: [String]
  arguments: [String]
): ViewResults!

Example

Query:

view(
  functionName: "0x5e7a300e640f645a4030aeb507c7be16909e6fa9711e7ca2d4397bbd967d5c50::auction::get_auction_metadata"
  typeArgs: []
  arguments: [ "auc.iota", "0x31deb8cbd320867089d52c37fed2d443520aac0fc5a957de1f64f9135b83f42b"]
) {
  errors
  results {
    json
  }
}

Response:

{
  "data": {
    "view": {
      "results": {
        "start": "447575403174913",
        "end": "447576324774913",
        "address": "0xc9f649324694c0c18c6278c3a81945fb3ef0c9b91f21dd5b6a4364447ee348df",
        "value": "500000000"
      }
    }
  }
}

Rationale

The implementation of the developer interface specified above entails no required changes to the Move language. Such an interface can be implemented as a JSON or GraphQL RPC backend that relies on the existence of a dev-inspect gRPC call to an IOTA full node.

This means that function_name allows to fetch a Move View Function from a bytecode stored in an on-chain package. Then the Move type layout of the function parameters and return values can be determined. Finally, a dev-inspect Move Call can be constructed and executed using the type_args and arguments parameters and then its return values can be resolved.

However, a future IIP could specify how to make the on-chain read API explicit (e.g., adding a view function annotation to the Move language such as in the Aptos view function)).

Backwards Compatibility

This proposal is fully backwards compatible. In that case of a combination of this IIP with another IIP specifying an explicit on-chain read API, the developer interface proposed in here could be limited only to that explicit API.

Test Cases

The new developer interface will need to be extensively tested.

Reference Implementation

There is no reference implementation at the time of writing this IIP.

Copyright

Copyright and related rights waived via CC0.