



Secure Asset Transfer Protocol                            V. Ramakrishna
Internet-Draft                                                 V. Pandit
Intended status: Informational                              IBM Research
Expires: 19 September 2026                                      E. Abebe
                                                               Consensys
                                                               S. Nishad
                                                            K. Narayanam
                                                            IBM Research
                                                           18 March 2026


           Views and View Addresses for Secure Asset Transfer
               draft-ramakrishna-satp-views-addresses-07

Abstract

   With increasing use of DLT (distributed ledger technology) systems,
   including blockchain systems and networks, for virtual assets, there
   is a need for asset-related data and metadata to traverse system
   boundaries and link their respective business workflows.  Core
   requirements for such interoperation between systems are the
   abilities of these systems to project views of their assets to
   external parties, either individual agents or other systems, and the
   abilities of those external parties to locate and address the views
   they are interested in.  A view denotes the complete or partial state
   of a virtual asset, or the output of a function computed over the
   states of one or more assets, or locks or pledges made over assets
   for internal or external parties.  Systems projecting these views
   must be able to guard them using custom access control policies, and
   external parties consuming them must be able to verify them
   independently for authenticity, finality, and freshness.  The end-to-
   end protocol that allows an external party to request a view by an
   address and a DLT system to return a view in response must be DLT-
   neutral and mask the interior particularities and complexities of the
   DLT systems.  The view generation and verification modules at the
   endpoints must obey the native consensus logic of their respective
   systems.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://ietf-
   satp.github.io/draft-ramakrishna-satp-views-addresses/draft-
   ramakrishna-satp-views-addresses.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   ramakrishna-satp-views-addresses/.




Ramakrishna, et al.     Expires 19 September 2026               [Page 1]

Internet-Draft        SAT Views and View Addresses            March 2026


   Discussion of this document takes place on the Secure Asset Transfer
   Protocol Working Group mailing list (mailto:sat@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/sat/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/sat/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-satp/draft-ramakrishna-satp-views-addresses.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 19 September 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Assumptions and Principles  . . . . . . . . . . . . . . . . .   7
   4.  Ledger State Views and Proofs . . . . . . . . . . . . . . . .   7
     4.1.  Abstraction of Distributed Ledger States  . . . . . . . .   8
     4.2.  Distributed Ledger System Views . . . . . . . . . . . . .   9
     4.3.  Simple Views  . . . . . . . . . . . . . . . . . . . . . .  11



Ramakrishna, et al.     Expires 19 September 2026               [Page 2]

Internet-Draft        SAT Views and View Addresses            March 2026


     4.4.  Aggregate Views . . . . . . . . . . . . . . . . . . . . .  12
     4.5.  Complex or Processed Views  . . . . . . . . . . . . . . .  12
     4.6.  View Proofs . . . . . . . . . . . . . . . . . . . . . . .  12
   5.  Ledger State View Addresses . . . . . . . . . . . . . . . . .  13
   6.  Ledger State View Verification Policies . . . . . . . . . . .  17
   7.  Ledger State View Request . . . . . . . . . . . . . . . . . .  18
   8.  Ledger State View Access Control Policies . . . . . . . . . .  18
   9.  Related Open Issues . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Forms of proof  . . . . . . . . . . . . . . . . . . . . .  19
     9.2.  Temporal guarantees of view authenticity  . . . . . . . .  20
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     10.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   Blockchain systems, especially those of the permissioned variety, are
   a heterogeneous mix, fulfilling a diverse range of needs and built on
   several different DLT stacks that are not compatible with each other.
   Yet, in an interconnected world, the business processes running on
   each system cannot afford to remain isolated and the virtual assets
   they manage cannot afford to remain in siloes.  These systems must be
   interoperable so that assets can move, and their properties can be
   reflected across network boundaries, and so that business processes
   can span multiple systems.  Interoperability will, in effect, mimic a
   larger or scaled up, blockchain system composed of smaller blockchain
   systems without explicitly requiring those systems to coalesce.

   At the core of any cross-blockchain system transaction is the ability
   of a system to project a view of assets and associated data recorded
   on its ledger to external parties, be they individual agents or other
   blockchain systems.  On the reverse, a blockchain system must also
   have the ability to identify and address views of assets or
   associated data in another system, and further, to validate that view
   before its business process consumes it.  View projection,
   addressing, and consumption, must eliminate or minimize the role of
   third parties to avoid loss of data privacy, control over business
   process, or diminishment of autonomy.

   This document specifies formats for views and view addresses on
   distributed ledgers.  Similar to the notion of database views,
   distributed ledger views reflect what a given network wishes to
   expose to external parties, typically through scripts, as well as
   access control considerations.  In contrast to conventional
   databases, exposure and access control considerations must be decided
   through decentralized consensus.  Also, in contrast to a conventional
   database, the consumer of the view, who may be a DLT system, must be



Ramakrishna, et al.     Expires 19 September 2026               [Page 3]

Internet-Draft        SAT Views and View Addresses            March 2026


   able to independently validate it as the consensus view of the
   providing network.  Hence, a view incorporates the notion of a proof
   made against a claim.  The view address must encapsulate the view
   request, and optionally carry a policy that circumscribes the
   construction of proof.

   The protocol to communicate view requests and responses is beyond the
   scope of this draft and will be specified in a separate draft.

2.  Terminology

   The following are some terminology used in the current document:

   *  Blockchain system: Blockchains are distributed digital ledgers of
      cryptographically signed transactions that are grouped into
      blocks.  Each block is cryptographically linked to the previous
      one (making it tamper evident) after validation and undergoing a
      consensus decision.  As new blocks are added, older blocks become
      more difficult to modify (creating tamper resistance).  New blocks
      are replicated across copies of the ledger within the network, and
      any conflicts are resolved automatically using established rules
      [NIST].

   *  Blockchain network: This is a blockchain system that is built on a
      network of nodes that maintain a common shared copy of the
      blockchain using a consensus protocol.

   *  Distributed ledger technology (DLT) system: Technology that
      enables the operation and use of distributed ledgers, where the
      ledger is shared (replicated) across a set of DLT nodes and
      synchronized between the DLT nodes using a consensus mechanism
      [ISO].  Every blockchain system is also a DLT system, and so we
      will mostly use the latter term in this draft when discussing
      protocols for cross-system interactions.

   *  Distributed ledger network: This is a DLT system that is built on
      a network of nodes that maintain a shared copy of the ledger or
      portions of it on different subsets of nodes using a consensus
      protocol.

   *  Resource Domain: The collection of resources and entities
      participating within a blockchain or DLT system.  The domain
      denotes a boundary for permissible or authorized actions on
      resources.

   *  Interior Resources: The various interior protocols, data
      structures and cryptographic constructs that are a core part of a
      blockchain or DLT system.  Examples of interior resources include



Ramakrishna, et al.     Expires 19 September 2026               [Page 4]

Internet-Draft        SAT Views and View Addresses            March 2026


      the ledger (blocks of confirmed transaction data), public keys on
      the ledger, consensus protocol, incentive mechanisms, transaction
      propagation networks, etc.

   *  Exterior Resources: The various resources that are outside a
      blockchain or DLT system, and are not part of the operations of
      the system.  Examples include data located at third parties such
      as asset registries, ledgers of other blockchain/DLT systems, PKI
      infrastructures, etc.

   *  Nodes: The nodes of the blockchain or DLT system which form the
      peer-to-peer network, which collectively maintain the shared
      ledger in the system by following a consensus algorithm.

   *  Gateway nodes: The nodes of the blockchain or DLT system that are
      functionally capable of acting as a gateway in an asset transfer.
      A gateway node conforms to the Secure Asset Transfer Architecture
      [SATA] and implements the Secure Asset Transfer Protocol (SATP)
      [SATP].  Being a node on the blockchain/DLT system, a gateway has
      at least read access to the interior resources (e.g., ledger) of
      the blockchain.  Optionally, it may have write access to the
      ledger and also the ability to participate in the consensus
      mechanism deployed for the system.  Depending on the blockchain/
      DLT system implementation, some or all of the nodes may be
      gateway-capable.

   *  Clients: Entities are permitted to invoke smart contracts to read
      or update ledger state in a blockchain or DLT system.  They
      possess unique identities in the form of public keys.  In a
      permissioned system, identity certificates are issued by the
      system's internal providers (or certificate authorities).

   *  Wallets: Collection of client identities represented by public-
      private key pairs, and optionally certificate issued by a
      blockchain or DLT system's identity providers (or certificate
      authorities).

   *  Virtual Asset: A virtual asset is a digital representation of
      value that can be digitally traded, or transferred as defined by
      the FATF [FATF].

   *  Virtual Asset Service Provider (VASP): Legal entity handling
      virtual assets as defined by the FATF [FATF].

   *  Ledger state: A snapshot of the information held in a distributed
      shared ledger, typically (though not necessarily) as a set of
      blockchain or DLT system.  Examples of interior resources include
      key-and-value pairs.  This information includes records of virtual



Ramakrishna, et al.     Expires 19 September 2026               [Page 5]

Internet-Draft        SAT Views and View Addresses            March 2026


      assets and the state of business processes that are meaningful to
      the DLT system's participants and clients.  State elements and
      subsets may be scoped under the namespaces of given smart
      contracts, thereby being accessible only through invocations on
      those contracts.

   *  Smart contracts: Business workflows written in programming
      languages that manage the states of assets and business processes
      on a shared ledger in a DLT system.  These contracts constrain the
      ability of system clients to modify ledger state and embed guards
      around state elements.  Contracts can be invoked to read from, or
      write, to, a ledger.  They can be deployed on several system
      nodes, who must agree on a given ledger state update via a
      consensus protocol.

   *  Consensus protocol/mechanism: Process by which nodes agree on a
      ledger state update, typically (though not mandatorily) through a
      smart contract invocation.

   *  Local transaction: A transaction triggered by a client to update
      the ledger state in a blockchain or DLT system, typically (though
      not mandatorily) through a smart contract invocation.

   *  View: A projection of a blockchain or DLT system's ledger state
      for external consumption, i.e., for parties outside that system.
      This can be a single element, a subset of the state, or a function
      over a subset.

   *  View Address: A unique identifier or locator for a view into a
      blockchain or DLT system's ledger.  This is analogous to an HTTP
      URL.

   *  Source system: Blockchain or DLT system governing the ledger from
      which a view is produced.

   *  Destination system: System in which a view is consumed.  This can
      be a blockchain or DLT system.

   *  Remote system: Counterparty system in a view request-response
      protocol instance.  From the vantage point of the source system,
      this refers to the destination system, and vice versa.

   *  View requestor: Person or organization triggering a view request
      from a source network.







Ramakrishna, et al.     Expires 19 September 2026               [Page 6]

Internet-Draft        SAT Views and View Addresses            March 2026


   *  Proof: A data structure containing evidence linking a view to its
      source system's blockchain, or more generally, ledger.  The
      evidence may be probabilistic and in some cases cryptographically
      verifiable.

   *  Access/exposure policy: Set of rules governing the release of a
      view to an external party (i.e., outside the source system), held
      in consensus by nodes on the source system's ledger.

   *  Verification policy: Rules for validation of proofs associated
      with views maintained in a destination system.  If the destination
      system is a blockchain or DLT system, these rules are held in
      consensus by nodes on that system's ledger.

   *  View Request: A request for a made by an external party to a
      source blockchain or DLT system.  The external party may be a
      client in a destination blockchain or DLT system.  The request
      consists of a view address and various metadata, including
      optionally a verification policy.

   *  Asset locking or escrow: The conditional mechanism used within a
      blockchain or DLT system to make an asset temporarily unavailable
      for use by its owner.  The condition of the asset release can be
      based on a duration of time (e.g., hash time locks) or other
      parameters.

   Further terminology definitions can be found in [NIST] and [ISO].
   The term 'blockchain' and 'distributed ledger technology' (DLT) are
   used interchangeably in this document.

3.  Assumptions and Principles

   The addressing of a DLT system’s assets and asset-related data as
   well as the exposure of such data to a foreign DLT system assumes the
   presence of one or more gateways that are either part of the system
   or working on behalf of it.  These gateways are ultimately
   responsible for generating and interpreting both addresses and data,
   hiding any DLT- or network-specific protocol considerations from each
   other.  All DLT- and network-specific software artifacts that are
   exchanged among gateways will be encapsulated in generic (or DLT-
   neutral) software artifacts.  The gateways are assumed to be
   interoperable using a protocol that corresponds to the design
   principles of the Internet architecture.  The specification of this
   protocol is beyond the scope of this draft and will be described in a
   separate draft.

4.  Ledger State Views and Proofs




Ramakrishna, et al.     Expires 19 September 2026               [Page 7]

Internet-Draft        SAT Views and View Addresses            March 2026


4.1.  Abstraction of Distributed Ledger States

   A distributed ledger system maintains a set of ledgers, akin to
   databases.  Each such ledger is organized and addressable in a
   hierarchical namespace with the identifier of the distributed ledger
   system being the root.  A ledger is shared among a subset of members
   of the network that the system, which maintains the distributed
   ledger, is built on.  These subsets of members may overlap or be
   mutually exclusive, depending on the precepts of the given DLT, but
   for the purpose of this document, the distinction is not relevant.
   For example, the Hyperledger Fabric blockchain platform maintains a
   set of channels, where each channel is shared exclusively by a subset
   of members [Andr18].  In contrast, the Corda platform allows each
   data item to be shared by an arbitrary subset of members, in effect
   creating databases privy to mutually overlapping member sets
   [Hear19].  The Ethereum Mainnet has a dynamic group of members
   maintaining a single global ledger with open, or public, access.

   Each shared ledger within a system maintains a snapshot of the
   latest, or current, state, determined through consensus (or
   agreement) by the members sharing it.  In addition, a tamper-evident
   history of the current state, which can be a blockchain or any other
   form of a transaction log, is also maintained by the members sharing
   that database.  The state of the distributed ledger system as a whole
   is the union of states of the ledgers it comprises of.

   Finally, any data item within a ledger can be retrieved, or any
   processed data extracted, using its native logic and interfaces.  As
   a ledger is a traditional database in most respects, it supports
   extraction and processing the same way a database does.  For example,
   data in a SQL database can be extracted using record keys and schema
   attributes, whereas in a No-SQL database, data is extracted using
   knowledge of key value pairs and overlaid schema.  Just as views and
   stored procedures are used to extract information from a database,
   UTXO scripts (in Bitcoin [Naka08]) or smart contracts (in Ethereum
   [Ethe22], and several permissioned DLTs like Hyperledger Fabric and
   Corda) are used to extract information from a ledger.  An interface
   is provided to give the user the ability to query or update ledger
   data.  As UTXO scripts are just simple forms of smart contracts, we
   will assume in our abstraction that each ledger within a DLT system
   possesses a smart contract interface.










Ramakrishna, et al.     Expires 19 September 2026               [Page 8]

Internet-Draft        SAT Views and View Addresses            March 2026


4.2.  Distributed Ledger System Views

   A view into a distributed ledger system state is similar in concept
   to a traditional database view but has certain additional features
   because the backing state is maintained in a different way than state
   in a traditional database is.  Fundamentally, a DLT system view is
   information that is derived from that system's ledger.  We define it
   as an abstract representation of state projected from a ledger that
   is consumable by entities, who may or may not belong to the network
   or possess credentials to access raw ledger state.  Views are
   uniquely addressable within a DLT system.  A view can be static,
   i.e., referring to information derived from a point-in-time (or
   historical) state, or dynamic, i.e., referring to information derived
   from the current state.

   Semantically, a view represents the what and not the how, i.e., it
   projects information from a ledger but not the details of the process
   through which that information came into being.  This process has
   multiple facets, from the consensus and commitment protocols through
   which raw data was recorded on the ledger to the smart contract
   procedure through which information was extracted from the raw ledger
   data.  These procedures are specific to DLT implementations, which we
   wish to keep opaque from the cross-system communication
   infrastructure, specifically the systems' gateways.  This will allow
   the communication infrastructure to ignore details of ledger
   implementations while managing state when a view is communicated from
   a system to an external entity.  Therefore, we specify the view as a
   package with a generic structure, independent of a specific DLT
   implementation.  Internally, a view will contain data that has a DLT-
   specific representation, but we will leave the interpretation of this
   to modules internal to the systems.  In this document, we will
   specify the formats of the DLT-independent portions of a view that
   will be handled by the communication infrastructure and provide
   suggestive sample view contents for prominent DLTs.

   There is a caveat to the above definition, arising from a fundamental
   difference between a traditional database and a DLT system.  This is
   the fact that state in the former is maintained by a single authority
   whereas state in the latter is maintained collectively, and held in
   agreement, by a peer group of entities, each of which can fail or be
   malicious.  Therefore, a DLT system view is incomplete without an
   associated proof of it being derived from state agreed to by the
   group as a whole.  In practice, this does not require unanimity but
   rather enough representation from group members to overcome failure
   of individual peers' failures and to assure an external client that
   the system as a whole will not repudiate that view, in accordance
   with the consensus rules of the source ledger, at a later time.
   Theoretically, we can quantify the nature of this proof under certain



Ramakrishna, et al.     Expires 19 September 2026               [Page 9]

Internet-Draft        SAT Views and View Addresses            March 2026


   models.  If peers are susceptible only to crash failures, an
   agreement over state from more than 50% of the peers will qualify as
   sufficient proof.  If peers can be malicious, i.e., fail in Byzantine
   ways, a consistent state view is required from more than 2/3 of the
   peers.  More generally, the nature of proof, or determining what is
   sufficient, can be derived from the consensus mechanism used by the
   system.

   The proof associated with a view represents two things.  One is an
   assurance that the view is a group, or consensus, view of the ledger
   held by the DLT system as a whole.  The other is evidence of
   authenticity of the state projection that the view represents.  And
   though the construction of a proof is very DLT-specific, the notion
   that a proof may be supplied with a view can be embodied in a DLT-
   independent specification, thereby adhering to the principle of DLT
   opacity to the communication infrastructure.  Finally, proofs are
   also consistent with the "what, not how" principle because they
   certify that a view represents state at a given point in time and not
   the history of events that led to that state.

   Now we can look at the structure of a view in more detail.  At a high
   level, a view consists of the following:

   *  Request Id: a unique value corresponding to the request for a view
      made by an external entity to the DLT system.

   *  Data: ledger state projection, or derived information, with proof.

   *  Metadata: attributes of the payload used to unpack and interpret
      it.

   Data consists of the following:

   *  View Address: this is supplied by an external entity, and is the
      equivalent of a "getter function" that can be used to uniquely
      identify (or derive) projection into a DLT system state.

   *  Information: this is the actual ledger state projection.

   *  Schema: this described the Information data structure and can be
      used to unpack (or unmarshal) it.  It is optional if the ledger
      schema is well-known.

   *  Proof: This is a structure that validates the Information.  It is
      optional, though recommended for DLT system views.

   *  Proof Schema: this describes the Proof data structure.  It is
      optional if the proof schema is well-known.



Ramakrishna, et al.     Expires 19 September 2026              [Page 10]

Internet-Draft        SAT Views and View Addresses            March 2026


   Metadata consists of the following:

   *  View Type: this tells us whether the view is a singleton data
      item, a collection of data items, or a computation over data items
      that are part of the DLT system state.

   *  Protocol Type: this denotes a unique value associated with a given
      DLT protocol; e.g., Bitcoin, Ethereum, Hyperledger Fabric, Corda,
      Solana.

   *  Timestamp: this denotes the time at which the view was produced.

   *  Proof Type: this denotes the type, or category, of proof being
      supplied, e.g., Notarizations/certifications (also called proof of
      authority), Simplified Payment Verifications, Zero Knowledge
      Proof, Proof of Proof-of-Work.

   *  Serialization Format: this denotes the format used to serialize
      the view data, e.g., XML, JSON, protocol buffer.

   *  Commitments: these are commitments made on the view by authorities
      or infrastructure (e.g., the Ethereum Mainnet) external to the DLT
      system.

4.3.  Simple Views

   A simple DLT view is any unit of a database within a DLT system that
   is exposable through interfaces programmed over that database.  More
   concretely, any blockchain or smart contract system provides the
   ability to write scripts or procedures that can act on the raw ledger
   (database) data, accompanied by interfaces to trigger those scripts
   or procedures to query or update ledger state.  In such a system, a
   simple view is any information that can be obtained directly through
   an invocation of this interface, e.g., any transaction exposed by a
   smart contract deployed on a ledger within the system.

   In the DLT view structure specified earlier, the View Type within
   Metadata will be set to SIMPLE if such a view is requested by an
   external entity.  The content of the view address (described later in
   this draft) can be interpreted to know if the external entity is
   requesting a simple view.










Ramakrishna, et al.     Expires 19 September 2026              [Page 11]

Internet-Draft        SAT Views and View Addresses            March 2026


4.4.  Aggregate Views

   An aggregate DLT view is a collection of addressable units of
   databases within a DLT system.  In effect, it is an array of simple
   views, which can be derived through multiple invocations of different
   scripts or smart contract transactions acting on raw ledger data.  In
   the DLT view structure specified earlier, the View Type within
   Metadata will be set to AGGREGATE if such a view is requested by an
   external entity.  The content of the view address (described later in
   this draft) can be interpreted to know if the external entity is
   requesting an aggregate view.

4.5.  Complex or Processed Views

   A complex or processed DLT view is the output of a function computed
   over a set of addressable units of databases within a DLT system.  In
   effect, it is a function computed over an aggregate view.  In the DLT
   view structure specified earlier, the View Type within Metadata will
   be set to AGGREGATE if such a view is requested by an external
   entity.  The content of the view address (described later in this
   draft) can be interpreted to know if the external entity is
   requesting a complex view, and the function to be computed will also
   be specified in the view address.

4.6.  View Proofs

   Proof within a view must ratify the view’s contents as the consensus
   over a projection of ledger state by members of the DLT system.
   Because the projection of state is itself DLT-specific, though it can
   be wrapped in DLT-neutral structures as we have described earlier,
   the proof also takes DLT-specific shapes.  But we can list the set of
   attributes any proof must contain in abstract terms as follows:

   *  Association of response with request: a connection (ideally,
      cryptographically secure) between the request supplied in the view
      address with the ledger state projection as inferred by the source
      system.  For instance, this can take the form of a signature over
      a common structure consisting of both the request and the
      response.

   *  Authenticity of response: a connection (ideally, cryptographically
      secure) between a member generating a ledger state projection and
      its DLT system.  For instance, this can take the form of a
      certificate chain associating the signer with the DLT system’s
      membership authorities.  This is necessary for a permissioned DLT
      system and is optional for open (or permissionless) DLT systems.





Ramakrishna, et al.     Expires 19 September 2026              [Page 12]

Internet-Draft        SAT Views and View Addresses            March 2026


   *  Evidence of consensus: information showing that the view contents
      are agreed upon by the network as a whole.  For a permissioned DLT
      system, this typically implies that an identical and authentic
      ledger state projection must be provided by a large enough quorum
      of its members so that the view cannot be repudiated in the
      future.  In an open (or permissionless) system, this can simply be
      the portion of a mined block that shows why it belongs to the
      longest chain; i.e., proof-of work or succinct versions of it
      (like Proof-of-Proof-of-Work [Naka08], or PoPoW [Kiay16][Kiay17]).
      In any DLT system, such evidence can optionally pass a policy
      check, where the policy rule is supplied by the view requestor and
      typically embodies the consensus logic that led to the commitment
      of the ledger state projection being requested.

5.  Ledger State View Addresses

   To request a view from a DLT system, an external entity must be able
   to unambiguously specify the information it seeks in the form of a
   view address.  The use of the term “address” follows from the
   abstraction of a DLT system as a repository of data resources that
   can be retrieved and computed on.  A view address in blockchain or
   distributed ledger systems is equivalent to URLs [RFC1630] (for
   example, specified as an HTTP address [RFC2616]), which are used to
   address resources offered by Internet and World Wide Web servers
   [RFC1738].

   From a functional perspective, a view address can also be thought of
   as an interface over a “getter”, which is a standard software pattern
   used to fetch data values in a computer program.  The schematic
   representation of a getter is dependent on the protocol followed by
   the underlying distributed ledger system, but is conceptually
   abstracted away by the view address.  An external entity can create
   and manipulate a view address without understanding its semantics and
   usage, which are hidden by the DLT system.  This allows the system to
   use alternate representations for getters internally without
   requiring external entities to understand the implementations of
   these operators.  The view address states the “what” and not the
   “how”.

   A view address must be a globally unique identifier of a view on a
   distributed ledger system, because global interoperability is our
   goal.  Therefore, as with DNS addresses for Internet servers and URLs
   for World Wide Web resources, a view address is a hierarchical
   address, with different segments identifying units of decreasing size
   and increasing specificity in sequence.  The syntax is as follows:






Ramakrishna, et al.     Expires 19 September 2026              [Page 13]

Internet-Draft        SAT Views and View Addresses            March 2026


     address  = location-segment "/"
                ledger-segment "/"
                view-segment
                ; distributed-ledger-system/ledger/data-projection

   The location-segment provides identification and reachability
   information for the distributed ledger system.  The ledger-segment
   identifies a unique ledger within this system, and the view-segment
   identifies a view or state projection from that ledger.

   Decentralized ledger systems don’t have a single location as they are
   built on networks of peer nodes.  Maintainers of these systems may
   expose one or more endpoints for external entities to access views,
   which can be hosted on the network nodes themselves or on designated
   gateways.  Gateways form the communication infrastructure for cross-
   system interactions and can be deployed in different configurations:
   a single system may possess multiple gateways, or a single gateway
   may serve multiple systems.  Therefore, to formulate a view address,
   one needs to know the set of endpoints that lead to a given
   distributed ledger system and a unique identifier for the network
   that hosts that system.  In certain systems and gateways, an
   identifier that represents a set of endpoints can be used instead of
   explicitly enumerating those endpoints.  Also, if the specified set
   of endpoints is known to serve a single system, the network
   identifier can be omitted.  The syntax of the location-segment is as
   follows:

     location-segment  = gateway ["/" network-id]
     gateway           = endpoint *(";" endpoint) / name
     endpoint          = host [":" port]
     host              = hostname / IP-address
     port              = 1*DIGIT
     network-id        = name
     hostname          = name 1*("." name)
     name              = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-")
     IP-address        = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

   A single gateway serving a given distributed ledger system (network)
   can be represented as follows:

     location-segment  = gateway.trade.com:7542/trade-network
                         \____________________/ \___________/
                                    |                 |
                                 endpoint          network

   Multiple gateways serving a network can be represented as follows:





Ramakrishna, et al.     Expires 19 September 2026              [Page 14]

Internet-Draft        SAT Views and View Addresses            March 2026


   location-segment  = gateway1.trade.com:7542;   \
                       gateway2.trade.com:7542;   |--gateway (endpoints)
                       gateway3.trade.com:7542    /
                       /trade-network
                        \___________/
                              |
                           network

   Gateways serving a single well-known network can be represented as
   follows:

     location-segment  = gateway1.trade.com:7542;gateway2.trade.com:7542
                         \_____________________________________________/
                                                |
                                       gateway (endpoints)

   The ledger-segment names either the ledger, if that ledger has a
   distinct identifier within the system, or a procedure to access a
   ledger, which represents a common set of facts shared by a subset of
   members of the network that maintains the distributed ledger.  These
   subsets may overlap; i.e., certain nodes may maintain more than one
   ledger in the system.  The procedure name can take the form of an
   identifier that represents, say, a decentralized application spanning
   certain nodes, or an explicit enumeration of the identifiers of the
   nodes themselves.  The ledger segment syntax is as follows:

     ledger-segment = *1(
                         (ALPHA / "_")
                         1*(ALPHA / DIGIT / "_" / "-" / ";" / “:”)
                        )

   The ledger-segment can be blank if the distributed ledger system has
   a single ledger.  This is the norm in open blockchain systems like
   Bitcoin or the Ethereum Mainnet, and in private Ethereum-based
   systems like Quorum and Hyperledger Besu.

   Examples are as follows:














Ramakrishna, et al.     Expires 19 September 2026              [Page 15]

Internet-Draft        SAT Views and View Addresses            March 2026


     ledger-segment = trade-channel
                      \___________/
                            |
                       ledger name

     ledger-segment = paymentsDapp
                      \___________/
                            |
                    procedure/app name

     ledger-segment = paymentsDappNode1:9005;paymentsDappNode2:9005
                      \____________________/ \____________________/
                                 |                      |
                        procedure/app node     procedure/app node

   The view-segment uniquely identifies a view within a ledger.
   Features particular to a distributed ledger technology will determine
   how to encode this segment, but we can draw out common abstractions
   across DLTs to create a generic specification.  All such technologies
   offer a procedural interface to access and manipulate data, typically
   (but not always) in the form of a smart contract.  The exposed
   interface offers multiple functions to generate views based on the
   provided input.  Hence, we can specify the view-segment as being
   composed of a contract, a function, and a list of input arguments.
   In the most general case, a default contract may be assumed, and
   arguments may be unnecessary, and so these can be omitted.  The
   function, which can either be a procedural identifier, or a direct
   reference to a data item or collection of data items, or a
   programming instruction, must be specified.  The view-segment syntax
   is as follows:

     view-segment   = [contract-id] ":"
                      function-spec *(":" input-argument)
     contract-id    = (ALPHA / "_") 1*(ALPHA / DIGIT / "_")
     function-spec  = name
     input-argument = name
     name           = *HEXDIGIT ; hex-encoded ASCII string

   An example of a view-segment for a Hyperledger Fabric ledger is:

     view-segment   = trade-chaincode:getBillOfLading:bill-10012
                      \_____________/ \_____________/ \________/
                              |               |            |
                          contract         function     argument

   An example for a Corda ledger is:





Ramakrishna, et al.     Expires 19 September 2026              [Page 16]

Internet-Draft        SAT Views and View Addresses            March 2026


    view-segment   = :com.trade.dapp.flows.GetDocumentByTypeAndId:C:5
                      \_________________________________________/ \_/
                                           |                       |
                                        function               arguments

   An example of a complete view address is as follows:

     gw.trade.com:7542/traden/tradel/tradec:getBill:bill-10012
     \______________________/ \____/ \_______________________/
                 |               |                |
         location-segment  ledger-segment    view-segment

6.  Ledger State View Verification Policies

   A verification policy for a ledger state view is a set of rules that
   the proof within the view can be validated against (or filtered
   through).  The condition embedded within a rule can be arbitrary,
   though in practice, it should embody the process by which that
   ledger’s state was updated and consented to in a decentralized manner
   by the network of peers maintaining it.  In permissioned networks
   built on DLTs like Hyperledger Fabric or Corda, a policy typically
   requires evidence of attestations made by a sufficiently large, or
   representative, portion of the peer network maintaining the ledger.
   This takes the form of a set of signatures and is crucial to
   validating views generated by networks built on DLTs like Hyperledger
   Fabric and Corda.  In open networks, we can envision policies that
   require validation of the view data being derived from a block in the
   longest chain, for example.  But in this specification, we will
   consider only attestation-based policies and leave more general
   policies to future drafts.

   The structure of a verification policy is as follows:

   *  Security Domain: a unique identifier for the distributed ledger
      system (or network maintaining it) projecting the ledger state
      view.

   *  Rules: a set of rules, each governing the validation of artifacts
      exposed through a particular category of views within the Security
      Domain.

   Each Rule consists of the following:

   *  View Pattern: a regular expression that can match a set of views.

   *  Policy: a policy rule/filter governing all views that match View
      Pattern.




Ramakrishna, et al.     Expires 19 September 2026              [Page 17]

Internet-Draft        SAT Views and View Addresses            March 2026


   Each Policy consists of the following:

   *  Type: an identifier or flag denoting the type of this policy rule.
      For attestation-based policies, this should be set to “Signature”,
      and other identifiers can be created for other policy types in
      future drafts.

   *  Criteria: a Boolean expression with ANDs and ORs, where the
      principals consist of (1) the name of a DLT system unit/
      stakeholder (typically corresponding to a subset of nodes in the
      peer network), and (2) the number of signatures requires from this
      unit.

7.  Ledger State View Request

   A view request is a message sent to a distributed ledger system by
   any external entity.  It consists of the following:

   *  View Address: uniquely identifies the data sought by the
      requester.

   *  Verification Policy: indicates the proof criteria for the
      requested view.

8.  Ledger State View Access Control Policies

   An access control policy for a ledger state view is a set of rules
   governing the exposure of the view to an external entity.  Each rule
   maps a set of principals to a set of views.  The structure of an
   access control policy is as follows:

   *  Security Domain: a unique identifier for the entity (which can be
      a distributed ledger system itself) requesting a ledger state
      view.

   *  Rules: a set of rules, each governing access from some entity
      within Security Domain to artifacts exposed through a particular
      category of views.

   Each Rule consists of the following:

   *  Principal: a string that can match a set of subjects or
      principals, which can represents an individuals or an organization
      or a subgroup within an organization identified by role or
      attribute set (profile).

   *  Principal Type: a keyword that denotes the nature of the
      principal.  This can be one of the following:



Ramakrishna, et al.     Expires 19 September 2026              [Page 18]

Internet-Draft        SAT Views and View Addresses            March 2026


      -  PUBLIC-KEY: indicates that the principal is a public key
         associated with an individual member of the Security Domain.

      -  CA: indicates that the principal is a certification authority
         for an organization within the Security Domain.

      -  ROLE: indicates that the principal identifies a role within the
         Security Domain.

      -  ATTRIBUTE: indicates that the principal identifies a set of
         attributes, or a profile for a member, within the Security
         Domain.

      -  ‘*’: indicates that the principal can be any member of the
         Security Domain.  The Principal can be left blank in this case.

   *  Resource: a regular expression that can match a set of views,
      which identifies the objects governed by this rule.

   *  Read: a Boolean flag indicating whether this rule is currently
      active.

9.  Related Open Issues

   This draft provides a specification for views and how to addresses
   them.  It further describes a protocol whereby one system can request
   a view from another through gateways.  But there are several aspects
   of the end to-end process, which are extraneous to the data sharing
   protocol yet crucial to its successful completion.  Though detailed
   specifications of these are beyond the scope of this draft, we list
   them in this section for readers’ considerations.

9.1.  Forms of proof

   Though we have tried to be agnostic of the nature of the proof
   associated with a view in this draft, the data sharing protocol
   implicitly assumes that the proof takes the form of a quorum of
   digital signatures from parties belonging to a permissioned
   distributed ledger system.  But several other proof types can exist,
   each suitable to the type of system that is exporting a view and the
   technology stack and consensus mechanism it is built on
   [Naka08][Kiay16][Kiay17][PoS][PoET][PoA].









Ramakrishna, et al.     Expires 19 September 2026              [Page 19]

Internet-Draft        SAT Views and View Addresses            March 2026


9.2.  Temporal guarantees of view authenticity

   The view address as specified in this draft has no temporal
   component, implicitly conveying a request for the latest or
   “freshest” state projection from a shared ledger.  Even apart from
   expanding the specification of the view address to include, for
   example, an absolute or relative timestamp, we will need to augment
   the data sharing protocol with a mechanism to convey proof of
   temporal veracity of a view.  Work done on verifiable observation of
   shared ledgers using a public bulletin board [Abebe21] can be taken
   as the starting point for such a specification.

10.  References

10.1.  Normative References

   [FATF]     FATF, "International Standards on Combating Money
              Laundering and the Financing of Terrorism & Proliferation
              - The FATF Recommendations", October 2018,
              <http://www.fatf-
              gafi.org/publications/fatfrecommendations/documents/fatf-
              recommendations.html>.

   [ISO]      ISO, "Blockchain and distributed ledger technologies-
              Vocabulary (ISO:22739:2024)", January 2024,
              <https://www.iso.org/standard/82208.html>.

   [NIST]     Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
              Blockchain Technology Overview (NISTR-8202)", October
              2018, <https://doi.org/10.6028/NIST.IR.8202>.

   [RFC1630]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
              Unifying Syntax for the Expression of Names and Addresses
              of Objects on the Network as used in the World-Wide Web",
              RFC 1630, DOI 10.17487/RFC1630, June 1994,
              <https://www.rfc-editor.org/rfc/rfc1630>.

   [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
              Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
              December 1994, <https://www.rfc-editor.org/rfc/rfc1738>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616,
              DOI 10.17487/RFC2616, June 1999,
              <https://www.rfc-editor.org/rfc/rfc2616>.





Ramakrishna, et al.     Expires 19 September 2026              [Page 20]

Internet-Draft        SAT Views and View Addresses            March 2026


   [SATA]     Hardjono, T., Hargreaves, M., Smith, N., and V.
              Ramakrishna, "Secure Asset Transfer (SAT) Interoperability
              Architecture, IETF, draft-ietf-satp-architecture-09",
              February 2026, <https://datatracker.ietf.org/doc/draft-
              ietf-satp-architecture/>.

   [SATP]     Hargreaves, M., Hardjono, T., Belchior, R., Ramakrishna,
              V., and A. Chiriac, "Secure Asset Transfer Protocol (SATP)
              Core, IETF, draft-ietf-satp-core-13", March 2026,
              <https://datatracker.ietf.org/doc/draft-ietf-satp-core/>.

10.2.  Informative References

   [Abebe21]  Abebe, E., Hu, Y., Irvin, A., Karunamoorthy, D., Pandit,
              V., Ramakrishna, V., and J. Yu, "Verifiable Observation of
              Permissioned Ledgers (ICBC 2021)", May 2021,
              <https://arxiv.org/abs/2012.07339>.

   [Andr18]   Androulaki, E., Barger, A., Bortnikov, V., Cachin, C.,
              Christidis, K., De Caro, A., Enyeart, D., Ferris, C.,
              Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C.,
              Nguyen, B., Sethi, M., Singh, G., Smith, K., Sorniotti,
              A., Stathakopoulou, C., Vukolic, M., Weed Cocco, S., and
              J. Yellick, "Hyperledger Fabric: A Distributed Operating
              System for Permissioned Blockchains, EuroSys", January
              2018, <https://arxiv.org/abs/1801.10228>.

   [BVGC20]   Belchior, R., Vasconcelos, A., Guerreiro, S., and M.
              Correia, "A Survey on Blockchain Interoperability: Past,
              Present, and Future Trends", May 2020,
              <https://arxiv.org/abs/2005.14282v2>.

   [Clar88]   Clark, D., "The Design Philosophy of the DARPA Internet
              Protocols, ACM Computer Communication Review, Proc SIGCOMM
              88, vol. 18, no. 4, pp. 106-114", August 1988.

   [Ethe22]   "Ethereum whitepaper", September 2022,
              <https://ethereum.org/en/whitepaper/>.

   [Gray81]   Gray, J., "The Transaction Concept: Virtues and
              Limitations, in VLDB Proceedings of the 7th International
              Conference, Cannes, France, September 1981, pp. 144-154",
              September 1981.

   [Harer2022]
              Härer, F., "Towards Interoperability of Open and
              Permissionless Blockchains: A Cross-Chain Query Language,
              IEEE International Conference on e-Business Engineering



Ramakrishna, et al.     Expires 19 September 2026              [Page 21]

Internet-Draft        SAT Views and View Addresses            March 2026


              (ICEBE), Bournemouth, United Kingdom, 2022, pp. 190-197,
              doi: 10.1109/ICEBE55470.2022.00041", October 2022,
              <https://ieeexplore.ieee.org/document/10035048>.

   [Hear19]   Hearn, M. and R. G. Brown, "Corda: A Distributed Ledger",
              August 2019, <https://docs.r3.com/en/pdf/corda-technical-
              whitepaper.pdf>.

   [Herl19]   Herlihy, M., "Blockchains from a Distributed Computing
              Perspective, Communications of the ACM, vol. 62, no. 2,
              pp. 78-85", February 2019,
              <https://doi.org/10.1145/3209623>.

   [HLP19]    Hardjono, T., Lipton, A., and A. Pentland, "Towards an
              Interoperability Architecture for Blockchain Autonomous
              Systems, IEEE Transactions on Engineering Management",
              June 2019, <https://ieeexplore.ieee.org/document/8743548>.

   [HS2019]   Hardjono, T. and N. Smith, "Decentralized Trusted
              Computing Base for Blockchain Infrastructure Security,
              Frontiers Journal, Special Issue on Blockchain Technology,
              Vol. 2, No. 24", December 2019,
              <https://doi.org/10.3389/fbloc.2019.00024>.

   [Kiay16]   Kiayias, A., Lamprou, N., and A. Stouka, "Proofs of proofs
              of work with sublinear complexity, International
              Conference on Financial Cryptography and Data Security,
              pages 61–78, Springer", 2016.

   [Kiay17]   Kiayias, A., Miller, A., and D. Zindros, "Non-Interactive
              Proofs of Proof-of-Work, Cryptology ePrint Archive, Paper
              2017/963", September 2017,
              <https://eprint.iacr.org/2017/963>.

   [Naka08]   Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
              System, Decentralized Business Review", October 2008,
              <https://bitcoin.org/bitcoin.pdf>.

   [PoA]      Antolin, M., "What Is Proof-of-Authority? Understanding
              PoA Consensus Mechanisms, CoinDesk", June 2022,
              <https://www.coindesk.com/learn/what-is-proof-of-
              authority/>.

   [PoET]     Bowman, M., Das, D., Mandal, A., and H. Montgomery, "On
              Elapsed Time Consensus Protocols, Cryptology ePrint
              Archive, Paper 2021/086", 2021,
              <https://eprint.iacr.org/2021/086>.




Ramakrishna, et al.     Expires 19 September 2026              [Page 22]

Internet-Draft        SAT Views and View Addresses            March 2026


   [PoS]      "Proof-of-Stake (PoS) | ethereum.org", September 2022,
              <https://ethereum.org/en/developers/docs/consensus-
              mechanisms/pos/>.

   [SRC84]    Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
              in System Design, ACM Transactions on Computer Systems,
              vol. 2, no. 4, pp. 277-288", November 1984.

Authors' Addresses

   Venkatraman Ramakrishna
   IBM Research
   Email: vramakr2@in.ibm.com


   Vinayaka Pandit
   IBM Research
   Email: pvinayak@in.ibm.com


   Ermyas Abebe
   Consensys
   Email: ermyas.abebe@consensys.net


   Sandeep Nishad
   IBM Research
   Email: sandeep.nishad1@ibm.com


   Krishnasuri Narayanam
   IBM Research
   Email: knaraya3@in.ibm.com


















Ramakrishna, et al.     Expires 19 September 2026              [Page 23]
