An easy-to-use, high-performance Interledger implementation written in Rust


Interledger implementation in Rust 💸 Documentation CircleCI rustc Rust Docker Image License


All crates require Rust 2018 edition and are tested on the following channels:

  • stable

Connecting to the Testnet

See the testnet instructions to quickly connect to the testnet with a bundle that includes the node and settlement engines.


Installation and Usage

To run the components by themselves (rather than the testnet-bundle), you can follow these instructions:

Using Docker


  • Docker


docker pull interledgerrs/ilp-node
docker pull interledgerrs/ilp-cli
docker pull interledgerrs/ilp-settlement-ethereum


# This runs the sender / receiver / router bundle
docker run -it interledgerrs/ilp-node

# This is a simple CLI for interacting with the node's HTTP API
docker run -it --rm interledgerrs/ilp-cli

# This includes the Ethereum Settlement Engines written in Rust
docker run -it interledgerrs/ilp-settlement-ethereum

Building From Source



# 1. Clone the repsitory and change the working directory
git clone && cd interledger-rs

# 2. Build interledger-rs (add `--release` to compile the release version, which is slower to compile but faster to run)
cargo build

You can find the Interledger Settlement Engines in a separate repository.


# This runs the ilp-node
cargo run --bin ilp-node -- # Put CLI args after the "--"

cargo run --bin ilp-cli -- # Put CLI args after the "--"

Append the --help flag to see available options.

See configuration for more details on how the node is configured.

Configuring Redis

We have some account settings such as amount_per_minute_limit or packets_per_minute_limit. In order to enable these options, you need to load the redis-cell module as follows. You don't need to load this module unless you use the rate-limit options.

# in your redis config file
# file will be found in crates/interledger-store/external
loadmodule /path/to/modules/

or you can specify an argument when you start up the redis instance as follows.

redis-server --loadmodule /path/to/modules/


See the examples for demos of Interledger functionality and how to use the implementation.


Contributions are very welcome and if you're interested in getting involved, see We're more than happy to answer questions and mentor you in making your first contributions to (even if you've never written in Rust before)!

  • Add time-based settlement to complement the threshold-based

    Add time-based settlement to complement the threshold-based

    Currently interledger-rs supports settling peer accounts whenever their balance goes over settle_threshold, settling for balance - settle_to and thus resetting the balance to settle_to. This PR adds a time-based method which works in addition to the existing threshold-based settlement. This feature allows driving the balance to settle_to later. The feature works with settle_threshold: if the balance goes over the threshold, a settlement is still fired off right away and any existing time-based settlement is cancelled.

    The feature works by adding a delay on each prepare for every peering account id which did not already have a delay. The delay duration is set through the --settle_every configuration option. When the delay expires, a path similar to threshold settlement is taken to settle the balances, but now the balance's relation to the threshold is ignored.

    The hot path of the prepare/fulfill processing in balance service is changed by addition of a non-blocking non-awaiting call to Sender::try_send, and on failing the send there is protection against flooding the logging by a non-awaited try to lock the mutex to log at most every minute. This guarding is because we don't anticipate running into issues with processing of the queue – the situtation should only arise when the node is badly overloaded, and in that case the logging should try not to make the bad situtation worse.

    In balance_service there's additionally minor refactoring to share the settle_or_rollback for threshold and time based approaches which involved a few lines moved.

    Note: In a cluster configuration where multiple nodes share a single database and database accounts, using this can result in many settlements.

    opened by koivunej 18
  • Incoming and outgoing tokens should match

    Incoming and outgoing tokens should match

    Right now the ilp_over_btp_outgoing_token has to be in the form username:password while the ilp_over_btp_incoming_token has to be in the form password. We should change it so both values can be exactly the same because it's way too confusing otherwise.

    We should also make sure the same applies to ilp_over_http

    duplicate enhancement 
    opened by emschwartz 18
  • Enables `` on CircleCI

    Enables `` on CircleCI

    A part of #198


    • This PR enables to be run on CircleCI.
      • Also if the branch is master and all tests have passed, it updates docker images on DockerHub. Also, tagged commit would be pushed, being tagged with the git tag name.
    • Because running docker command in containers requires docker-in-docker(dind), docker/run-md-test.dockerfile is based on circleci/buildpack-deps:latest-dind.
    • Also, dind requires another job because it requires another image, so the job is defined as test-md.
    • The setup_remote_docker command spins up a docker daemon in an outer machine. So we can't access it using curl localhost:xxxx which is used to test. In order to address this issue, ncat hack was used.
      • ncat -l -k -c "docker exec -i interledger-rs-node_a nc 7770" -p 7770 &
    • interledgerrs/settlement-engine repo is deprecated, using interledgerrs/settlement-engines instead because the name looked wrong.



    • I'm wondering this is better or not. Using Cargo.toml doesn't seem to be efficient.
      • cargo-cache-2-{{ checksum "Cargo.lock" }}-{{ .Branch }} (changing Cargo.toml to Cargo.lock)
      • We have to remove Cargo.lock from .gitignore to do this.
    opened by dora-gt 18
  • Update error handling in cli-app

    Update error handling in cli-app

    The cli app will panic in ws_account_payments_incoming for several legitimate use cases:

    • invalid URL
    • invalid URL protocol/scheme
    • ilp node not running

    This extends the module's Error enum, allowing the ? to gracefully report failures to the end user. Is this the style you prefer for error handling?

    A few other notes:

    • Refactored a nested match statement for readability, drawn from this clap example. The behavior should be the same.
    • Is there a more descriptive name for ClientErr, say, RequestErr?
    • Can socket.read_message().expect("Could not receive WebSocket message") occur in normal use?
    • Is there is a reasonable way to spin up an ilp node for testing runtime failures? There doesn't seem to be anything that actually exercises NodeClient::ws_account_payments_incoming().
    opened by KevinWMatthews 17
  • CLI Improvement

    CLI Improvement

    • Fixes
      • #171 Use gumdrop or structopt for CLI option parsing
      • #113 Fix --version flag in CLI
      • #206 Allow env vars to override config file values
      • #194 Make settlement-engine to take environmental values
      • #215 Add documentation for interledger node configuration
    • Version is obtained from crate's version
    • ~~Using structopt to reduce the complexity of the source.~~
    • ~~Using #[allow(clippy::large_enum_variant)] because options of account add command are too many. It may be difficult to fix this unless we make a patch to structopt~~


    • Ethereum settlement engine now doesn't accept key argument. Use private_key instead.
    • ~~Ethereum settlement engine now doesn't accept watch_incoming flag because it was a flag and default_value was true, which doesn't make sense and structopt considers it as an error. Instead I implemented without_incoming_watcher flag which disables incoming watcher.~~
      • ~~structopt: help: message: default_value is meaningless for bool~~
    • ~~node now doesn't accept ilp_address argument. Instead address argument or ILP_ADDRESS env var will be accepted.~~
    opened by dora-gt 17
  • Make `.md`s testable

    Make `.md`s testable

    I noticed that we made .mds runnable so we could even test it. It has a pro that if the documents go outdated, we will be able to notice that.

    That said, it will require more efforts, so... not now but sometime in the future.

    enhancement docs ci 
    opened by dora-gt 17
  • Replace numeric account IDs and configured ILP addresses with usernames and dynamically generated addresses

    Replace numeric account IDs and configured ILP addresses with usernames and dynamically generated addresses

    • [x] Replace numeric IDs in interledger-store-redis / the node with unique ids
    • [x] Add usernames to accounts as uid aliases
    • [x] Make SPSP payments work with usernames
    • [x] Add an auth method to the HTTP API that includes the username (HTTP Basic Auth, separate header, or JWT)
    • [x] Remove need for auth tokens to be globally unique
    • [x] Remove ilp_address from the Account (or make it optional, in which case if it is present it would override the automatically generated address)
    • [x] Handle ILDCP queries by appending a dot (.) and the username to the Node's ILP address
    • [x] Merge IldcpAccount trait into base Account trait and rename client_address method to ilp_address
    • [ ] Don't broadcast node's child accounts if their addresses start with the node's ILP address (if node example.a has an account for example.a.b, it should broadcast a route to example.a but not to example.a.b)

    Based on,, and

    feature developer-experience 
    opened by emschwartz 17
  • Improve key storage approach

    Improve key storage approach

    Right now, the Store is responsible for managing secret values like API keys (for authenticating with peers via HTTP or BTP). The Redis store uses encryption and hmac keys derived from a configured seed.

    This approach isn't great because:

    • It's not very secure (all of they key material is on the same machine)
    • The seed needs to be passed in as an environment variable (is that even a good approach?)
    • Cannot easily change the seed
    • Every store implementation needs to re-implement similar crypto functionality or import some shared code (this issue was inspired by @cjimison asking about the right way to approach this for

    Also, the keys should be included in the Account type in such a way that they are never logged. For example, they could have special types that implement Debug and Display but only print <redacted> or something like that.

    How should we improve the key storage? If necessary, we can also revisit the use of API keys (rather than more complex auth) if there is some decent solution that's more secure but not impossible to use.

    question feature security 
    opened by emschwartz 17
  • Connecting to the testnet

    Connecting to the testnet

    @wliu @emschwartz

    This is not actually working. Just playing with and figuring out what to do. automatically connects our local node to the Xpring test node.

    ./scripts/testnet/ -f -x -c -s -a -l

    (too many options lol)

    Questions and suggestions:

    • should accept some parameters so that we don't need to add our account to the Xpring side. For example, our ILP address and our endpoint URL.
    • should return their ILP address.
    • Can nodes handle SSL connections now? I'm not sure.
    opened by dora-gt 15
  • Settlement Engine Asset Scale

    Settlement Engine Asset Scale

    1. Should the asset scale conversion be done on the connector or on the engine? If we do it on the engine, it'd mean that each engine would have to implement that conversion properly, while we could do it on the operator once.

    2. How do we handle settlement amounts that are bigger than u64 in the store? Can occur in high granularity EVM transactions (Ether / ERC20 / any other Ethereum fork)

    cc @emschwartz @kincaidoneil @sappenin

    opened by gakonst 14
  • Make examples more consistent

    Make examples more consistent

    The Simple and Ethereum Settlement examples have slightly different styles and we should try to make them more consistent.

    Some of the notable differences:

    • The Simple example puts all of the commands in shell scripts while the Ethereum Settlement example puts the code in the README. The advantage of shell scripts is that they can be run directly, while the disadvantage is that it's less nice to read through them than reading the markdown README file. Having both means we need to make sure the code and README stay in sync, which is a bit annoying.
    • The Ethereum example gets the account balances directly from Redis while the other uses the HTTP API. We should definitely try to avoid calling the DB directly and instead encourage the use of the API, however it's slightly nicer to print the balance in line with the comment (as is done here) than to print the JSON {"balance":"100"} on the line after the comment.
    • The Ethereum example suggests opening 7 terminal windows to run the different services, while the scripts in the other example run the services as forked processes and write the logs to different files. Opening 7 terminal windows is pretty excessive so I'd lean towards only requiring one, though that does make it more difficult to watch different processes happen simultaneously.
    • The examples made in the settlement's are hard to read due to how the POST parameters are added. We should move these to a file / improve formatting What do you think? cc @gakonst @bstrie @dora-gt @pgarg-ripple
    opened by emschwartz 14
  • Maintenance Status

    Maintenance Status

    Hello @koivunej @KristianWahlroos @matdehaast @emschwartz @frnsskk

    Just wondering what the maintenance status of this project would be ?

    I have open issue here to detail analysis which came after our discussion around unicase:

    There is also concern around username comparison here to update unicase dependency:

    Unicase dependency problem - recommend bumping to 2.6.0:

    Would you like us to flag informational around that this crate is deprecated by unmaintained status and it may be also feasible to yank the old version of interledger-service that uses the old version of unicase ?

    This informational would gentle advice any downstream to be vary of using it - since I am not sure whether these published crates are supposed / intended to be used - but the decision would be yours as we generally don't file unmaintained advisories where the maintainer is reachable and either does not agree as to unmaintained status - we may file advisories where the project has been officially deprecated or confirmed by the maintainer(s) where it is feasible to advice any downstream users along as to the status.

    Thanks for the assistance !

    opened by pinkforest 1
  • CI: missing building of cargo-fuzz targets

    CI: missing building of cargo-fuzz targets

    Looking at the existing examples in serde/json for example, there probably is currently no supported way around installing cargo-fuzz on a nightly and just cargo fuzz build the targets under each crates/interledger-*/fuzz.

    Implementing this might be difficult for the caching, because these fuzz targets are not part of the workspace and have their own target/ directory, which might not work out of the box with the rust-cache action introduced in #732.

    Originally posted by @koivunej in

    ci good-first-issue build crate/interledger-stream crate/interledger-packet crate/interledger-ccp crate/interledger-btp 
    opened by koivunej 0
  • Refactoring of shared test support code

    Refactoring of shared test support code

    This was noticed while adding the benchmarks in #663 that the is copypasted all over. I do remember attempting to split it, the latest one being Since #729 will leave some FIXME and todo! related to these files, maybe they should be refactored into a single place before fixing.

    Marking this as good-first-issue because I seem to have made quite small commits which should be easy to follow/replicate.

    good-first-issue refactor 
    opened by koivunej 0
  • ilp-cli testnet setup command error

    ilp-cli testnet setup command error

    Deprecated Xpring API had an endpoint<assetCode> to create accounts on Xpring's side. ilp-cli testnet setup command was using this endpoint to create an account and peer with it to connect the testnet easily.


    But since Xpring rebranded as RippleX, API endpoints and responses changed with it. For now, I find out three things that need to change, in order to ilp-cli testnet setup command work.

    1. API endpoint, which changed from<assetCode> to Also, you should send a POST request instead of a GET request.

    2. The method to change the account asset. You should send a POST request to with a JSON payload, an object named assetCode in it to use an asset other than XRP. You can see the old method here:

    3. The XpringResponse struct, due to the change in the response format.

    • XpringResponse Struct:

    • Example response:

    "accountId": "user_w0vzjgqc",
    "accountRelationship": "CHILD",
    "assetCode": "XRP",
    "assetScale": 9,
    "maximumPacketAmount": null,
    "linkType": {},
    "connectionInitiator": true,
    "isInternal": false,
    "sendRoutes": true,
    "receiveRoutes": false,
    "balanceSettings": {
        "minBalance": null,
        "settleThreshold": null,
        "settleTo": 0
    "rateLimitSettings": {
        "maxPacketsPerSecond": null
    "settlementEngineDetails": null,
    "customSettings": {
        "ilpOverHttp.outgoing.url": "",
        "ilpOverHttp.incoming.auth_type": "SIMPLE",
        "ilpOverHttp.incoming.simple.auth_token": "ygV47wq8mvI0b",
        "ilpOverHttp.outgoing.simple.auth_token": "enc:gcpkms:connector:secret0:1:gs:CiQAxw4QhykCtBPYDxd7n91yo3FGmiIGbDQE8bN1c6Ft_4tYvRUSWACjdIaO5ZBq-W9sN7OiSr3o9Hb8uQBv68QTmd61EMCXMHuEa6uxrJZNM2ZHwkvhMEPgBfTH13EGUGkeSQfLMVlp9ZXyluiP-m0t1OJbDfUAE4qv0LBIhRY=",
        "ilpOverHttp.outgoing.auth_type": "SIMPLE"
    "parentAccount": false,
    "childAccount": true,
    "peerAccount": false,
    "peerOrParentAccount": false,
    "paymentPointer": "$"
    bug testnet 
    opened by omertoast 3
  • Stray printlns

    Stray printlns

    These should probably all be just error! outside tests and binary packages.

    Originally posted by @koivunej in

    good-first-issue refactor 
    opened by koivunej 0
Maintainers of the Interledger Rust implementation
An open source Rust high performance cryptocurrency trading API with support for multiple exchanges and language wrappers. written in rust(đŸĻ€) with ❤ī¸ - Rust Cryptocurrency Exchange Library An open source Rust high performance cryptocurrency trading API with support for multiple exchanges and

Crabby AI 4 Jan 9, 2023
An extremely high performance matching engine written in Rust.

Galois Introduction Galois is an extremely high performance matching engine written in Rust, typically used for the crypto currency exchange service.

UINB Tech 66 Jan 7, 2023
An easy-to-use generic trainer for Linux, written in Rust.

An easy-to-use generic trainer for Linux written in Rust, with basic memory hacking features. Use it for your games or applications where needed, there is also the tuxtraind daemon which will probe for processes and apply matching trainers automatically.

null 37 Aug 10, 2022
Simple to use CLI tool that makes encryption easy! Written in Rust.

?? eme: Encryption Made Easy an extremely simple AES-256 encryption tool written in Rust Usage: # To encrypt: eme --encrypt secret.png # To decrypt: e

null 5 Jan 3, 2023
An open source, high performance limit order book for the Seaport smart contracts. Implemented in Rust using ethers-rs, this offers a turnkey option for digital asset marketplaces.

Quay Quay is an open source, high performance backend for the Seaport smart contracts. The project is implemented in Rust, using Postgres as a storage

Valorem Labs Inc. 169 Jun 23, 2023
A high performance blockchain kernel for enterprise users.

English | įŽ€äŊ“中文 What is CITA CITA is a fast and scalable blockchain kernel for enterprises. CITA supports both native contract and EVM contract, by whi

CITAHub 1.3k Dec 22, 2022
High Performance Blockchain Deserializer

bitcoin-explorer bitcoin_explorer is an efficient library for reading bitcoin-core binary blockchain file as a database (utilising multi-threading). D

Congyu 18 Dec 22, 2022
A high performance blockchain kernel for enterprise users.

English | įŽ€äŊ“中文 What is CITA CITA is a fast and scalable blockchain kernel for enterprises. CITA supports both native contract and EVM contract, by whi

CITAHub 1.3k Dec 22, 2022
Glommio Messaging Framework (GMF) is a high-performance RPC system designed to work with the Glommio framework.

Glommio Messaging Framework (GMF) The GMF library is a powerful and innovative framework developed for facilitating Remote Procedure Calls (RPCs) in R

Mohsen Zainalpour 29 Jun 13, 2023
A high performance Remote Procedure Call system.

A high performance Remote Procedure Call (RPC) system. Usage Add this to your Cargo.toml file. [dependencies] frpc = { git = "

Nur 5 Jul 28, 2023
A high-performance, highly compatible EVM Inscriptions Indexer

Insdexer A high-performance, highly compatible EVM Inscriptions Indexer by Rust. An accessible and complete version of the documentation is available

null 105 Mar 17, 2024
Simple node and rust script to achieve an easy to use bridge between rust and node.js

Node-Rust Bridge Simple rust and node.js script to achieve a bridge between them. Only 1 bridge can be initialized per rust program. But node.js can h

Pure 5 Apr 30, 2023
egui: an easy-to-use immediate mode GUI in Rust that runs on both web and native

?? egui: an easy-to-use GUI in pure Rust ?? Click to run the web demo ?? egui is a simple, fast, and highly portable immediate mode GUI library for Ru

Cronus Diamond 7 Aug 13, 2022
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Cossack Labs 1.6k Dec 30, 2022
A modern, portable, easy to use crypto library.

Sodium is a new, easy-to-use software library for encryption, decryption, signatures, password hashing and more. It is a portable, cross-compilable, i

Frank Denis 10.7k Jan 3, 2023
An easy-to-use CLI tool to recover files from zfs snapshots

zfs-undelete an easy-to-use cli tool to recover files from zfs snapshots Usage Use zfs-undelete <file-to-restore>. Works for file and folders. By defa

null 9 Dec 15, 2022
Rusty Hog is a secret scanner built in Rust for performance, and based on TruffleHog which is written in Python.

Rusty Hog is a secret scanner built in Rust for performance, and based on TruffleHog which is written in Python. Rusty Hog provides the following bina

New Relic 306 Jan 4, 2023
SHA1: Rust vs. OpenSSL performance

SHA1: Rust vs. OpenSSL On an AMD Ryzen 7 3700X 8-Core Processor. Archlinux x86_64. Linux 5.15.5-arch1-1. Short = 8 bytes, long = 64 bytes and huge = 5

Fred Morcos 1 Dec 4, 2021
Rust DDC/CI high level library

ddc-enhanced-rs ddc-enhanced-rs is a cross platform Rust crate and Node package for controlling monitors with DDC/CI. Documentation Rust: https://docs

ThalusA 5 Oct 2, 2022