# Settlement Architecture

**URL:** <https://forum.interledger.org/t/settlement-architecture/545>\
**Category:** Implementations and SDKs\
**Tags:** settlement\
**Created:** [April 26, 2019, 2:59pm UTC](https://forum.interledger.org/t/settlement-architecture/545 "2019-04-26T14:59:15Z")\
**Posts on this page:** 1\
**Showing post:** 20

<div class="post-metadata">

**Author:** ![sappenin](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.interledger.org/sappenin/32/41_2.png) [@sappenin](https://forum.interledger.org/u/sappenin)\
**Post date:** [May 14, 2019, 2:30pm UTC](https://forum.interledger.org/t/settlement-architecture/545/20 "2019-05-14T14:30:37Z")

</div>

So where does that leave us? Reading through both this thread and the discussion in [Ledger Adaptor API](https://forum.interledger.org/t/ledger-adapter-api/553/12), it’s unclear to me where there’s consensus and where there is not.

Here’s how things appear to stand from may vantage point (I’m guessing I’ve missed a few things, or am possibly simply wrong in certain areas, so please chime-in if you disagree):

# Consensus

1. **Settlement Adaptor** : We want a non-Connector process that can interact with an underlying settlement system (e.g., Bitcoin, XRPL, etc) that does _not_ run in the Connector process. This will allow us to scale Connectors and Settlement systems independently. I’m calling this thing the _Settlement Adaptor_ (shout-out to @kincaid for [good rationale](https://forum.interledger.org/t/settlement-architecture/545/9) around why to drop the word “ledger” here).
2. **Settlement Engine** : We all agree that ILP-account balance-tracking (i.e., “when to settle based on the ILP credit balance”) should live in a `Settlement Engine`, but for now this component will just be an internal service/function of each Connector implementation.
  1. Based upon how implementations get built, it _may_ make sense in the future to extract this into a standalone system and/or shared-libraries, but this is out of scope for now.

3. **Connector/SE \<-\> SA Transport** : To aid adoption and for simplicity, we’re all OK with the Connector/SE communicating with the Settlement Adaptor using an HTTP+JSON API as a first-attempt. We _may_ explore other techniques later if it makes sense.
4. **Settlement Adaptor API Endpoints**
  1. `sendMoney`: When called by an external system (e.g., a Connector), instructs the Settlement Adaptor to send a payment via the underlying settlement system (e.g., XRPL).
  2. `getBalance`: Returns the current balance of the underlying settlement account (i.e. available liquidity for settlements).
  3. `sendData`: When called by an external system (e.g., a Connector), allows an ILP packet to be transmitted to the Settlement Adaptor for further processing, such as to exchange a Payment Channel claim.

5. **Connector/SE API Endpoints**
  1. `sendData`: Allows the local Settlement Adaptor to communicate with the _other_ Settlement Adaptor (used by the peer Connector) by transiting the local Connector using ILP link-layer technologies and `peer.settle.` addresses.
  2. `sendMoney`: Allows the Settlement Adaptor to indicate that a settlement payment was received on the underlying settlement system. For example, the account `123` received `10 XRP`. The Connector will react to this callback and update its balances appropriately.

# Open Questions

1. Are the above API endpoints correct?
2. If you get into a taxi cab, and ask the driver to drive backwards to your destination, will the cab driver owe you money?

---

_[View the full topic](https://forum.interledger.org/t/settlement-architecture/545)._