Addition of Starknet Appchain Info RPC Endpoint

đź“ś Development Proposals Starknet Technical Development
1

SNIP link: https://github.com/starknet-io/SNIPs/blob/main/SNIPS/snip-5.md

Simple Summary

This proposal suggests the implementation of a new RPC endpoint to retrieve relevant information concerning Starknet appchains.

Abstract

As Starknet appchains become increasingly integral to the Starknet ecosystem, the ability to conveniently retrieve data concerning a particular appchain has emerged as a critical requirement. This proposal outlines the design and rationale behind a new RPC endpoint that can provide such information. This endpoint will be leveraged by wallets and other applications to display relevant details about the appchain and facilitate interaction with it.

Motivation

The introduction of the Starknet Stack has enabled the creation of Starknet appchains, independent from the main Starknet chain, and used as platforms for application deployment and operation. It’s important to note that Starknet appchains aren’t exclusively Layer 2 (L2) chains and may not be entirely compatible with the public Starknet mainnet.

We need to clarify what kind of data we wish to expose concerning these appchains, which will enable seamless integration across all Starknet Stack tools, such as wallets, block explorers, and indexers.

The increasing shift towards a more modular design necessitates the categorization of an appchain and the disclosure of relevant information. This proposal serves to address this requirement. Broadly, an appchain can be classified based on:

  • Its identity as a Starknet Appchain (as opposed to public Starknet mainnet and testnets)
  • Its chosen settlement layer (e.g., Starknet mainnet, Ethereum, etc.)
  • The type of data availability solution it supports (e.g., Starknet mainnet, Ethereum (calldata / blob transactions), Celestia, Avail, etc.)
  • Its fee mechanism, i.e., does it utilize a custom token or the Starknet mainnet token? Does it support a custom fee market?

Specification

RPC Endpoint

The proposed endpoint name: starknet_appchainInfo.

OpenRPC specification:

{
   "name":"starknet_appchainInfo",
   "summary":"Returns information about the Starknet Appchain",
   "params":[],
   "result":{
      "name":"result",
      "description":"Details about the Appchain, if relevant",
      "schema":{
         "$ref":"#/components/schemas/APPCHAIN_INFO"
      }
   }
}

The schema for the APPCHAIN_INFO result will be as follows:

{
   "APPCHAIN_INFO":{
      "title":"Appchain Information",
      "type":"object",
      "properties":{
         "is_appchain":{
            "title":"Is Appchain",
            "type":"boolean"
         },
         "chain_id":{
            "title":"Chain ID",
            "$ref":"#/components/schemas/CHAIN_ID"
         },
         "fee_token_address":{
            "title":"Fee Token Address",
            "description":"The address of the fee token",
            "$ref":"#/components/schemas/FELT"
         },
         "settlement_layer":{
            "title":"Settlement Layer",
            "description":"Details about the settlement layer",
            "$ref":"#/components/schemas/SETTLEMENT_LAYER"
         },
         "data_availability_mode":{
            "title":"Data Availability Layer",
            "description":"Details about the Data Availability",
            "$ref":"#/components/schemas/DATA_AVAILABILITY"
         }
      }
   }
}

The schemas for SETTLEMENT_LAYER and DATA_AVAILABILITY will be defined at a later stage in the specification development process.

2

I suggest renaming the endpoint to “starknet_chainInfo” and the schema to “CHAIN_INFO” so it makes more sense when public Starknet implements it too.

3

Argent X already supports the addition of custom networks. The next version (5.7) that should be released in 1-2 weeks will deprecate the use of the sequencer and only rely on the RPC endpoints.

To add a custom network (e.g. and appchain) the extension will need:

  • network name
  • internal network id
  • chain id
  • rpc url
  • fee token address
  • Argent account classhash
  • (optional) explorer url
  • (optional) multicall contract address (to fetch token balances more efficiently)
4

thank you @juniset . For the RPC URL we cannot rely on this new endpoint since you need to know the RPC URL to be able to call it.
For network name, chain id, fee token address yes we can definitely have them in the rpc.
For the Argent account classhash we cannot add it in the spec since it’s specific to Argent.
For explorer url and multicall contract address I think they are too specific, not sure though, maybe we could add them as optional

5

thanks for the feedback, yes I think that makes sense. let see what people think about it

6

This looks good to me @abdel.1559 and is a great initiative

7

I second that proposition to rename the endpoint to “starknet_chainInfo”.