Artifact Content
Not logged in

Artifact e2f03d8d12f62c283352ab8c79c5a4a4655e109c:

<!DOCTYPE html>
<html lang="en">
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="description" content="Payments across payment networks">

    <title>Interledger Architecture | Interledger</title>

    <!-- Bootstrap core CSS -->
    <link href="../../css/bootstrap.min.css" rel="stylesheet">

    <!-- Custom styles -->
    <link href="../../css/monokai-sublime.css" rel="stylesheet">
    <link href="../../css/custom.css" rel="stylesheet">

    <!-- Google fonts -->
    <link href=',300,200,600,700|Droid+Sans+Mono|Titillium+Web:400,300,600' rel='stylesheet' type='text/css'>

    <!-- Font awesome -->
    <link rel="stylesheet" href="">

    <link href="../../assets/favicon.ico" rel="icon" type="image/x-icon">

    <!-- HTML5 shim and Respond.js for IE8 support of HTML5 elements and media queries -->
    <!--[if lt IE 9]>
      <script src=""></script>
      <script src=""></script>

  <body data-spy="scroll" data-target="#myScrollspy" data-offset="160" class="spec">

     <!-- navbar -->
      <nav class="navbar navbar-default navbar-fixed-top">
        <div class="container">
          <div class="navbar-header">
            <button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#navbar" aria-expanded="false" aria-controls="navbar">
              <span class="sr-only">Toggle navigation</span>
              <span class="icon-bar"></span>
              <span class="icon-bar"></span>
              <span class="icon-bar"></span>
            <a class="navbar-brand" href="../../index.html"><img class="logo" alt="interledger" src="../../assets/ilp_icon.png"/></a>
          <div id="navbar" class="navbar-collapse collapse">
            <ul class="nav navbar-nav">
              <li class="active"><a href="../../overview.html">Docs</a></li>
              <li><a href="../../community.html">Community</a></li>
              <li><a href="../../news.html">News</a></li>
            <ul class="nav navbar-nav navbar-right">
              <li><a target="_blank" href="">Github</a></li>

    <!-- docs overview section -->

    <div class="container docs-wrapper">
      <div class="row">
        <div id="sidebarContent">
          <nav class="col-sm-4" id="myScrollspy">
            <ul class="nav-fixed nav nav-sidebar">
              <div class="overview-back"><a href="../../overview.html"><i class="fa fa-angle-double-left" aria-hidden="true"></i> Back to Overview</a></div>
                <li class="nav-label">
                  <a href="draft-1.html">ILP-RFC 0001 Draft 1</a>
                  <a href="draft-1.html">Permalink to this Draft</a>
                  <a href="index.html">View the Latest Draft of ILP-RFC 0001</a>
                <li class="nav-label">
                  <a href="index.html#interledger-model">Interledger Model</a>
                  <a href="index.html#ledgers">Ledgers</a>
                  <a href="index.html#connectors">Connectors</a>
                  <a href="index.html#the-interledger">The Interledger</a>
                <li class="nav-label">
                  <a href="index.html#interledger-security">Interledger Security</a>
                  <a href="index.html#conditional-transfers">Conditional Transfers</a>
                  <a href="index.html#payment-flow">Payment Flow</a>
                  <a href="index.html#connector-risk-and-mitigation">Connector Risk and Mitigation</a>
                <li class="nav-label">
                  <a href="index.html#interledger-protocol-suite">Interledger Protocol Suite</a>
                  <a href="index.html#ledger-layer">Ledger Layer</a>
                  <a href="index.html#interledger-layer">Interledger Layer</a>
                  <a href="index.html#transport-layer">Transport Layer</a>
                  <a href="index.html#application-layer">Application Layer</a>
        <div class="col-sm-8 markdown-body">
          <h1 id="interledger-architecture">Interledger Architecture</h1>
<p class="intro">Interledger provides for secure payments across multiple assets on different ledgers. The architecture consists of a conceptual model for interledger payments, a mechanism for securing payments, and a suite of protocols that implement this design.</p>
<p>The <a href="index.html#interledger-layer">Interledger Protocol (ILP)</a> is the core of the Interledger protocol suite.</p>
<p>Colloquially the whole Interledger stack is sometimes referred to as &quot;ILP&quot;. Technically, however, the Interledger Protocol is only one layer in the stack.</p>
<p>The Interledger architecture is heavily inspired by the Internet architecture described in <a href="">RFC 1122</a>, <a href="">RFC 1123</a> and <a href="">RFC 1009</a>.</p>
<h2 id="interledger-model">Interledger Model</h2>
<p><img src="../shared/graphs/interledger-model.svg" alt="Interledger Model: Sender, Connectors, Ledgers, Receiver" class="img-responsive"></p>
<h3 id="ledgers">Ledgers</h3>
<p><em>Ledgers</em> are stateful systems that track the ownership of <em>assets</em>. Ledgers contain buckets of assets known as <em>accounts</em> and record <em>transfers</em> between them. Each account has a <em>balance</em>, which is the amount of the ledger&apos;s assets the account holds. Account balances may be positive or negative, representing assets or liabilities.</p>
<p><strong>In the Interledger model, a ledger only tracks a single asset, which may be a currency, stock, commodity, etc.</strong> One entity that maintains accounts denominated in multiple assets is described as having multiple ledgers.</p>
<p>A ledger may be operated by a single entity, as in the case of a bank, or it may be decentralized, as in the case of a blockchain or distributed ledger.</p>
<h3 id="connectors">Connectors</h3>
<p>A <em>connector</em> is a system that facilitates <em>payments</em> across different ledgers. Connectors generate revenue from Interledger payments while accepting some risk.</p>
<p>In the Interledger model, connectors are described as separate logical systems even though the same entity may operate a ledger and a connector.</p>
<p>A connector receives a local transfer on one ledger in exchange for making another local transfer on a different ledger. A single interledger payment may include multiple connectors and may traverse any number of ledgers.</p>
<p>If the ledgers represent different assets, the connectors set the exchange rate between the transfers. Connectors may generate revenue from the difference in value between incoming and outgoing transfers. Senders may request quotes from multiple connectors to determine the best price before sending a payment.</p>
<p>Connectors <em>peer</em> with one another to exchange information used to determine the best route for a payment.</p>
<p><strong>Interledger ensures that senders&apos; funds are safe throughout an multi-hop payment and cannot be stolen by faulty or malicious connectors (see <a href="index.html#interledger-security">Interledger Security</a>).</strong></p>
<h3 id="the-interledger">The Interledger</h3>
<p>The Interledger protocol suite may be used to transact across any ledgers and connectors, whether they are public or private. There is no single network that all parties must connect to to use these protocols.</p>
<p>&quot;The Interledger&quot; is a conceptual network made up of independent and diverse ledgers linked by connectors. Each account &quot;on the Interledger&quot; is part of a particular ledger, but they may transact with others by sending interledger payments through different ledgers and connectors. Like &quot;the Internet&quot;, the Interledger is not a single network but is comprised of multiple interconnected networks.</p>
<h2 id="interledger-security">Interledger Security</h2>
<p><strong>Interledger uses <em>conditional transfers</em> to secure payments across multiple hops and even through untrusted connectors.</strong> Senders are guaranteed cryptographic proof that the receiver got the payment or their money back, no matter how many ledgers and connectors are in between. Connectors take some risk, but this risk can be managed and is primarily based upon the connector&apos;s chosen ledgers and direct peers.</p>
<p><span class="show alert alert-info"><strong>Hint:</strong> Conditional transfers or <em>authorization holds</em> are the financial equivalent of a <a href="">two-phase commit</a>.</span></p>
<h3 id="conditional-transfers">Conditional Transfers</h3>
<p>Each local transfer is first <em>prepared</em> and then either <em>executed</em> or <em>rejected</em>. When a transfer is prepared, the ledger puts the funds of the source account on hold with a <em>cryptographic condition</em> and <em>timeout</em>. If the condition is fulfilled before the timeout, the transfer is executed and the funds are transferred. If the timeout is reached, the transfer expires and the ledger returns the funds to the source account automatically.</p>
<p>Inspired by the <a href="">Lightning Network</a>, Interledger uses the digest of the <a href="">SHA-256</a> hash function as the condition for transfers. The fulfillment is a valid 32-byte preimage for the hash specified when the transfer was prepared. Ledgers are responsible for validating fulfillments. <a href="index.html#transport-layer">Transport Layer</a> protocols are used by the sender and receiver to generate the condition for a particular payment.</p>
<p>To be fully Interledger-compatible, ledgers MUST support conditional transfers, though it is possible to send Interledger payments over a ledger that does not natively support the recommended features. See <a href="../0017-ledger-requirements.html">IL-RFC 17</a> for the full description and tiers of ledger requirements.</p>
<h3 id="payment-flow">Payment Flow</h3>
<p>In Interledger payments, all component transfers are prepared before any are executed. No funds are transferred, so none can be lost if a connector fails or attempts to redirect the payment.</p>
<p>When the <em>receiver</em> is notified of funds on hold for them, they submit the <em>fulfillment</em> of the cryptographic condition to claim their funds. Each connector uses the same fulfillment to claim their incoming transfer.</p>
<p>The timeout of each successive transfer is shorter than the previous one, giving each connector a window of time to deliver the fulfillment even if their outgoing transfer was executed at the last possible moment.</p>
<p>For more details on the flow, see the <a href="../0003-interledger-protocol.1.html">Interledger Protocol specification</a> and the <a href="../../interledger.pdf">Interledger whitepaper</a>.</p>
<p><span class="show alert alert-info"><strong>Note:</strong> Interledger only supports Universal mode as described in the whitepaper. Atomic mode can be used by adjacent subsets of participants in an Interledger payment if desired, but this is not part of the standard.</span></p>
<h3 id="connector-risk-and-mitigation">Connector Risk and Mitigation</h3>
<p>Interledger connectors accept some risk in exchange for the revenue they generate from facilitating payments. In the Interledger payment flow, connectors&apos; outgoing transfers are executed before their incoming transfers. After each connector is notified that the outgoing transfer has been executed, they have a window of time to deliver the fulfillment and execute the incoming transfer. Connectors that fail to deliver the fulfillment in time may lose money.</p>
<p>If some transfers in an Interledger payment are executed and others expire, the receiver will think the payment was completed but the sender may think the whole payment failed. Senders MAY retry payments that expire. If they do, they SHOULD use the same condition as the original payment. If the second attempt takes the same route, the connector that failed the first time can complete the payment by submitting the fulfillment without sending another outgoing transfer. Connectors should prefer senders (or aggregators of senders such as wallet services) and connectors that retry payments through the same route, because they increase the likelihood of completing such payments. Connectors may incentivize this behavior by offering better rates to parties known to retry failed payments through the same route.</p>
<p>Failing to deliver the fulfillment in time is the main risk connectors face and there are a number of additional strategies connectors should employ to mitigate and manage this risk. For more details, see <a href="../0018-connector-risk-mitigations.html">IL-RFC 18</a>.</p>
<h2 id="interledger-protocol-suite">Interledger Protocol Suite</h2>
<p>The Interledger stack is separated into four layers:</p>
<p><img src="../shared/graphs/protocol-suite.svg" alt="Interledger Protocol Suite" class="img-responsive"></p>
<h3 id="ledger-layer">Ledger Layer</h3>
<p>In order to facilitate transfers between accounts, ledgers must implement some API or protocol. This is called the ledger layer. There is a wide variety of ledger layer protocols, corresponding to the many different types of ledger.</p>
<p>See <a href="../0017-ledger-requirements.html">IL-RFC 17</a> for a full description of the ledger layer requirements.</p>
<p>Most implementations of Interledger use a plugin architecture to abstract the differences between different ledgers. For an example of this, see <a href="../0004-ledger-plugin-interface.1.html">IL-RFC 4</a>, which defines the interface for the Javascript implementation.</p>
<h3 id="interledger-layer">Interledger Layer</h3>
<p>The Interledger layer is responsible for facilitating payments across multiple ledgers. It is comprised of two key components that are used together: the Interledger Protocol (ILP) and the Interledger Quoting Protocol (ILQP).</p>
<p>The <a href="../0003-interledger-protocol.1.html">Interledger Protocol (ILP)</a> is the core of the Interledger stack and defines standard address and packet formats that instruct connectors where to send a payment.</p>
<p><a href="../0015-ilp-addresses.1.html">Interledger Addresses</a> provide a ledger-agnostic way to address ledgers and accounts. Interledger addresses are dot-separated strings that contain prefixes to group ledgers. An example address might look like:
<code></code> or <code>g.crypto.bitcoin.1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>.</p>
<p>When initiating an Interledger payment, the sender attaches an ILP packet to the local transfer to the connector. The packet is a binary message that includes the destination account, destination amount, and additional data for the receiver. The packet is relayed by connectors and attached to each transfer that comprises the payment. In some cases, ledger protocols may define alternative ways to communicate the packet.</p>
<p>The <a href="../0008-interledger-quoting-protocol.html">Interledger Quoting Protocol (ILQP)</a> defines how senders request quotes from connectors to determine the source or destination amount for an Interledger payment. Quoting is optional and senders MAY cache quotes and send repeated payments through the same connector.</p>
<h3 id="transport-layer">Transport Layer</h3>
<p>Transport layer protocols are end-to-end protocols used by the senders and receivers of Interledger payments to determine the payment condition and other details. The guarantees afforded to the sender vary depending on the type of transport protocol used.</p>
<p>There are currently two transport layer protocols:</p>
<li><p><a href="../0016-pre-shared-key.1.html">Pre-Shared Key (PSK)</a></p>
<p>  In Pre-Shared Key (PSK) protocol, the sender and receiver use a shared secret to generate the payment condition, authenticate the ILP packet, and encrypt application data. Using PSK, the sender is guaranteed that fulfillment of their transfer indicates the receiver got the payment, provided that no one aside from the sender and receiver have the secret and the sender did not submit the fulfillment.</p>
<p>  <strong>PSK is recommended for most use cases.</strong></p>
<li><p><a href="../0011-interledger-payment-request.1.html">Interledger Payment Request (IPR)</a></p>
<p>  In the Interledger Payment Request (IPR) protocol, the receiver generates the payment details and condition. The receiver does not share the secret used to generate the condition and fulfillment with the sender or anyone else, but the sender must ask the recipient to generate and share a condition before sending each payment. IPR is primarily useful for building non-repudiable application layer protocols, in which the sender&apos;s posession of the fulfillment proves to third parties that the sender has paid the receiver for a specific obligation.</p>
<h3 id="application-layer">Application Layer</h3>
<p>The application layer is the top layer of the Interledger protocol suite. Protocols on this layer are responsible for:</p>
<li>Destination account discovery</li>
<li>Destination amount negotiation</li>
<li>Transport protocol selection and communication of associated details, such as the shared secret or condition</li>
<li>Additional details to be communicated in ILP packet data</li>
<p>An example of an application layer protocol is the <a href="../0009-simple-payment-setup-protocol.1.html">Simple Payment Setup Protocol (SPSP)</a>.
SPSP uses Webfinger (<a href="">RFC 7033</a>) and an HTTPS-based protocol for communicating account, amount, and Pre-Shared Key details from the receiver to the sender.</p>


    </div> <!-- /container -->

      <div class="container">
        <div class="row">
          <div class="col-md-12">
            <div class="col-sm-4 col-xs-12">
              <p>Interledger Team</p>
            <div class="col-sm-4 col-xs-12">
              <p class="text-center">See list of <a target="_blank" href="">Contributors</a></p>
            <div class="col-sm-4 col-xs-12">
              <p class="pull-right">Documentation licensed under <a target="_blank" href="">CC BY 4.0.</a></p>

    <script src=""></script>
    <script src="../../js/bootstrap.min.js"></script>
      (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),

      ga('create', 'UA-68500608-1', 'auto');
      ga('send', 'pageview');

    <script src="../../js/highlight.pack.js"></script>