# Settlement Architecture **URL:** \ **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:** 14
**Author:** ![adrianhopebailie](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.interledger.org/adrianhopebailie/32/31_2.png) [@adrianhopebailie](https://forum.interledger.org/u/adrianhopebailie)\ **Post date:** [May 10, 2019, 3:01pm UTC](https://forum.interledger.org/t/settlement-architecture/545/14 "2019-05-10T15:01:46Z")
Based on comments from @ekrenzke, @kincaid and @austin_king both here and on the other Ledger Adapter Interface thread, I think we should not try to abstract the Settlement Engine → Ledger Adaptor interface. 1. It’s complex and the complexity is probably not warranted at this time 2. It’s hard to get the abstraction right 3. Worst case scenario is that some code is re-used between different ledger specific settlement engines and this is extracted into stand-alone libraries As I said on that thread I’d advocate for standardising on the interface I proposed above as: > [@adrianhopebailie](#): > > Settlement Engine → Connector > > - getBalance (get the current balance of the clearing account, i.e. ILP balance) > - setBalance (update the current balance of the clearing account, apply a delta) > - sendData (send a message to the Settlement Engine on the peer) > - receiveData (accept a message from the Settlement Engine on the other peer) This can be optimised (now or when it’s deemed to be required) by supplementing `getBalance` with a `subscribeToBalanceChanges` that allows the SE to get a stream of balance updates from the connector instead of polling. I am confident that concerns about the volume of updates that will be sent can be alleviated using a debounced stream however I think this is a premature optimisation. --- _[View the full topic](https://forum.interledger.org/t/settlement-architecture/545)._